[OE-core] gcc-6: Add fix for missing no-PIE flags

[Stephen Arnold]

From: Stephen Arnold 

Fixes build on hardened PAX host with gcc-5 (linker error on relocs).
Completes no-PIE config by adding to ALL_* flags variables.
Borrowed from Gentoo gcc patches, tested on 2 hardened amd64 hosts.

Upstream-Status: Inappropriate [configuration]

Commited by: Gentoo Toolchain Project 
Signed-off-by: Stephen Arnold 
---
 meta/recipes-devtools/gcc/gcc-6.3.inc  |  1 +
 .../gcc/gcc-6.3/0054_all_nopie-all-flags.patch | 22 ++
 2 files changed, 23 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.3/0054_all_nopie-all-flags.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.3.inc 
b/meta/recipes-devtools/gcc/gcc-6.3.inc
index 0f1b88bea7..ce414720ce 100644
--- a/meta/recipes-devtools/gcc/gcc-6.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.3.inc
@@ -79,6 +79,7 @@ SRC_URI = "\
file://0046-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \

file://0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \
file://0048-sync-gcc-stddef.h-with-musl.patch \
+   file://0054_all_nopie-all-flags.patch \
${BACKPORTS} \
 "
 BACKPORTS = ""
diff --git a/meta/recipes-devtools/gcc/gcc-6.3/0054_all_nopie-all-flags.patch 
b/meta/recipes-devtools/gcc/gcc-6.3/0054_all_nopie-all-flags.patch
new file mode 100644
index 00..73ab9502dc
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.3/0054_all_nopie-all-flags.patch
@@ -0,0 +1,22 @@
+Need to pass NO_PIE_CFLAGS to ALL_* so gcc doesn't fail when
+we compile it with older gcc and pie.
+
+Upstream-Status: Inappropriate [configuration]
+
+Maintained by: Gentoo Toolchain Project 
+Signed-off-by: Stephen Arnold 
+
+--- a/gcc/Makefile.in  2015-06-25 19:18:12.0 +0200
 b/gcc/Makefile.in  2016-04-22 00:12:54.029178860 +0200
+@@ -991,10 +991,10 @@ ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@)
+ ALL_CPPFLAGS = $(INCLUDES) $(CPPFLAGS)
+
+ # This is the variable to use when using $(COMPILER).
+-ALL_COMPILERFLAGS = $(ALL_CXXFLAGS)
++ALL_COMPILERFLAGS = $(NO_PIE_CFLAGS) $(ALL_CXXFLAGS)
+
+ # This is the variable to use when using $(LINKER).
+-ALL_LINKERFLAGS = $(ALL_CXXFLAGS)
++ALL_LINKERFLAGS = $(NO_PIE_CFLAGS) $(ALL_CXXFLAGS)
+
+ # Build and host support libraries.
-- 
2.11.1

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

[OE-core] [meta-oe][PATCH v2] gcc-6.2: Add fix for missing no-PIE flags

[Stephen Arnold]

From: Stephen Arnold 

Fixes build on hardened PAX host with gcc-5 (linker error on relocs).
Completes no-PIE config by adding to ALL_* flags variables.
Borrowed from Gentoo gcc patches, tested on 2 hardened amd64 hosts.

Upstream-Status: Inappropriate [configuration]

Commited by: Gentoo Toolchain Project 
Signed-off-by: Stephen Arnold 
---
 meta/recipes-devtools/gcc/gcc-6.2.inc   |  1 +
 .../gcc/gcc-6.2/0054_all_nopie-all-flags.patch  | 17 +
 2 files changed, 18 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.2/0054_all_nopie-all-flags.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.2.inc 
b/meta/recipes-devtools/gcc/gcc-6.2.inc
index b118995e1d..1a50d3a0d4 100644
--- a/meta/recipes-devtools/gcc/gcc-6.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.2.inc
@@ -78,6 +78,7 @@ SRC_URI = "\
file://0045-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch \
file://0046-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \

file://0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \
+   file://0054_all_nopie-all-flags.patch \
${BACKPORTS} \
 "
 BACKPORTS = ""
diff --git a/meta/recipes-devtools/gcc/gcc-6.2/0054_all_nopie-all-flags.patch 
b/meta/recipes-devtools/gcc/gcc-6.2/0054_all_nopie-all-flags.patch
new file mode 100644
index 00..0e103cb1ee
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.2/0054_all_nopie-all-flags.patch
@@ -0,0 +1,17 @@
+We need to pass NO_PIE_CFLAGS to ALL_* so gcc doesn't fail when
+we compile it with older gcc and pie.
+
+--- a/gcc/Makefile.in  2015-06-25 19:18:12.0 +0200
 b/gcc/Makefile.in  2016-04-22 00:12:54.029178860 +0200
+@@ -991,10 +991,10 @@ ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@)
+ ALL_CPPFLAGS = $(INCLUDES) $(CPPFLAGS)
+
+ # This is the variable to use when using $(COMPILER).
+-ALL_COMPILERFLAGS = $(ALL_CXXFLAGS)
++ALL_COMPILERFLAGS = $(NO_PIE_CFLAGS) $(ALL_CXXFLAGS)
+
+ # This is the variable to use when using $(LINKER).
+-ALL_LINKERFLAGS = $(ALL_CXXFLAGS)
++ALL_LINKERFLAGS = $(NO_PIE_CFLAGS) $(ALL_CXXFLAGS)
+
+ # Build and host support libraries.
-- 
2.11.1

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

[OE-core] [meta-oe][PATCH] Add fix for missing no-PIE flags in gcc-6.2

[Stephen Arnold]

From: Stephen Arnold 

Fixes build on hardened PAX host with gcc-5 (linker error on relocs).
Completes no-PIE config by adding to ALL_* flags variables.
Borrowed from Gentoo gcc patches, tested on 2 hardened amd64 hosts.

Upstream-Status: Inappropriate [configuration]

Signed-off-by: Stephen Arnold 
---
 meta/recipes-devtools/gcc/gcc-6.2.inc   |  1 +
 .../gcc/gcc-6.2/0054_all_nopie-all-flags.patch  | 17 +
 2 files changed, 18 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.2/0054_all_nopie-all-flags.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.2.inc 
b/meta/recipes-devtools/gcc/gcc-6.2.inc
index b118995e1d..1a50d3a0d4 100644
--- a/meta/recipes-devtools/gcc/gcc-6.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.2.inc
@@ -78,6 +78,7 @@ SRC_URI = "\
file://0045-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch \
file://0046-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \

file://0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \
+   file://0054_all_nopie-all-flags.patch \
${BACKPORTS} \
 "
 BACKPORTS = ""
diff --git a/meta/recipes-devtools/gcc/gcc-6.2/0054_all_nopie-all-flags.patch 
b/meta/recipes-devtools/gcc/gcc-6.2/0054_all_nopie-all-flags.patch
new file mode 100644
index 00..0e103cb1ee
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.2/0054_all_nopie-all-flags.patch
@@ -0,0 +1,17 @@
+We need to pass NO_PIE_CFLAGS to ALL_* so gcc doesn't fail when
+we compile it with older gcc and pie.
+
+--- a/gcc/Makefile.in  2015-06-25 19:18:12.0 +0200
 b/gcc/Makefile.in  2016-04-22 00:12:54.029178860 +0200
+@@ -991,10 +991,10 @@ ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@)
+ ALL_CPPFLAGS = $(INCLUDES) $(CPPFLAGS)
+
+ # This is the variable to use when using $(COMPILER).
+-ALL_COMPILERFLAGS = $(ALL_CXXFLAGS)
++ALL_COMPILERFLAGS = $(NO_PIE_CFLAGS) $(ALL_CXXFLAGS)
+
+ # This is the variable to use when using $(LINKER).
+-ALL_LINKERFLAGS = $(ALL_CXXFLAGS)
++ALL_LINKERFLAGS = $(NO_PIE_CFLAGS) $(ALL_CXXFLAGS)
+
+ # Build and host support libraries.
-- 
2.11.1

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

[OE-core] [PATCH] RfC: Incomplete morty toolchain config (gcc-6.2 in poky and oe-core)

[Stephen Arnold]

Above toolchain breaks in both possible sets of metadata on hardened host
(hardened amd64 profile with PAX kernel).  This issue does not occur on
krogoth or older branches with 5.4 or previous gcc versions.

Rolling back to 5.4 toolchain in morty results in random build failures
from the kernel killing gcc processes:

[122053.140618] PAX: terminating task:
/home/sarnold/foss-boundary-morty/oe-core/build-nitrogen6x/tmp-glibc/sysroots/x86_64-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/5.4.0/cc1plus(cc1plus):7943,
uid/euid: 1002/1002, PC

The 6.2 toolchain build error (failure to link gcov/other due to relocs) is
caused by incomplete no-PIE flags not being included in ALL* flag
variables, which is fixed in the attached Gentoo patch.

I've tested it on two build machines with both oe-core and poky builds and
both the toolchain and PAX are happy now.  I would highly recommend fixing
the no-PIE config; I probably have time to extract a patch and mail it
as-is, otherwise I'm fine if someone else fixes it.

Steve
We need to pass NO_PIE_CFLAGS to ALL_* so gcc don't fail when
we compile it with older gcc and pie.

--- a/gcc/Makefile.in	2015-06-25 19:18:12.0 +0200
+++ b/gcc/Makefile.in	2016-04-22 00:12:54.029178860 +0200
@@ -991,10 +991,10 @@ ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@)
 ALL_CPPFLAGS = $(INCLUDES) $(CPPFLAGS)
 
 # This is the variable to use when using $(COMPILER).
-ALL_COMPILERFLAGS = $(ALL_CXXFLAGS)
+ALL_COMPILERFLAGS = $(NO_PIE_CFLAGS) $(ALL_CXXFLAGS)
 
 # This is the variable to use when using $(LINKER).
-ALL_LINKERFLAGS = $(ALL_CXXFLAGS)
+ALL_LINKERFLAGS = $(NO_PIE_CFLAGS) $(ALL_CXXFLAGS)
 
 # Build and host support libraries.
 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [krogoth][meta-python]][PATCH v2] python-evdev: add setup.py patch

[Stephen Arnold]

From: Steve Arnold 

This currently works (randomly) when BUILD_HOST headers are a close
enough match, but fails as soon as they differ, due to static header
include paths in setup.py.  This patch adds a path check for the
STAGING_INC dir and makes it use the right headers.

Upstream-Status: Inappropriate, bitbake configuration-specific (upstream
needs a generic cross-compile fix).

Also includes DEPENDS/RDEPENDS from Tim and small doc package instead of
empty dev package.

Signed-off-by: Steve Arnold 
---
 .../python/python-evdev/use-sysroot-headers.patch  | 24 +++
 .../recipes-devtools/python/python-evdev_0.6.0.bb  | 28 ++
 2 files changed, 48 insertions(+), 4 deletions(-)
 create mode 100644 
meta-python/recipes-devtools/python/python-evdev/use-sysroot-headers.patch

diff --git 
a/meta-python/recipes-devtools/python/python-evdev/use-sysroot-headers.patch 
b/meta-python/recipes-devtools/python/python-evdev/use-sysroot-headers.patch
new file mode 100644
index 000..ce62bfc
--- /dev/null
+++ b/meta-python/recipes-devtools/python/python-evdev/use-sysroot-headers.patch
@@ -0,0 +1,24 @@
+--- a/setup.py 2016-10-01 10:00:11.491758891 -0700
 b/setup.py 2016-10-01 10:01:45.045089476 -0700
+@@ -65,10 +65,17 @@
+ 
+ #-
+ def create_ecodes():
+-headers = [
+-'/usr/include/linux/input.h',
+-'/usr/include/linux/input-event-codes.h',
+-]
++
++if not os.path.lexists(os.path.expandvars('$STAGING_INCDIR')):
++headers = [
++'/usr/include/linux/input.h',
++'/usr/include/linux/input-event-codes.h',
++]
++else:
++headers = [
++os.path.expandvars('$STAGING_INCDIR/linux/input.h'),
++os.path.expandvars('$STAGING_INCDIR/linux/input-event-codes.h'),  
 
++]
+ 
+ headers = [header for header in headers if os.path.isfile(header)]
+ if not headers:
diff --git a/meta-python/recipes-devtools/python/python-evdev_0.6.0.bb 
b/meta-python/recipes-devtools/python/python-evdev_0.6.0.bb
index e52..152206a 100644
--- a/meta-python/recipes-devtools/python/python-evdev_0.6.0.bb
+++ b/meta-python/recipes-devtools/python/python-evdev_0.6.0.bb
@@ -4,9 +4,29 @@ SECTION = "devel/python"
 LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=18debddbb3f52c661a129724a883a8e2"
 
-SRC_URI = "https://github.com/gvalkov/python-evdev/archive/v${PV}.zip";
+SRC_URI = "file://use-sysroot-headers.patch"
 
-SRC_URI[md5sum] = "24e4ffa98e338b535eae44d91d609005"
-SRC_URI[sha256sum] = 
"61f6893d80da87a995e5781c74d22a39448b1b32004ffac2f31817017709be04"
+SRC_URI[md5sum] = "294ac2997bd419d56b9451511536f9f4"
+SRC_URI[sha256sum] = 
"c0e1410cc88eaa6a016baeafb2acb1274d36a057944143b59e94f36bb482"
 
-inherit setuptools
+inherit pypi setuptools
+
+DEPENDS_${PN} += "\
+${PYTHON_PN}-ctypes \
+"
+
+RDEPENDS_${PN} += "\
+${PYTHON_PN}-ctypes \
+${PYTHON_PN}-fcntl \
+${PYTHON_PN}-io \
+${PYTHON_PN}-shell \
+${PYTHON_PN}-stringold \
+"
+
+do_install_append() {
+# note the full docs require Sphinx to build them
+install -d ${D}${datadir}/doc/${BPN}/
+install -m 0644 ${S}/README.rst ${D}${datadir}/doc/${PN}/
+}
+
+PACKAGES = "${PN}-doc ${PN} ${PN}-dbg"
-- 
2.9.3

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

[OE-core] [krogoth][meta-python]][PATCH] python-evdev: add setup.py patch to make sure it uses sysroot headers

[Stephen Arnold]

From: Steve Arnold 

This currently works (randomly) when BUILD_HOST headers are a close
enough match, but fails as soon as they differ, due to static header
include paths in setup.py.  This patch adds a path check for the
STAGING_INC dir and makes it use the right headers.

Also includes DEPENDS/RDEPENDS from Tim and small doc package instead of
empty dev package.

Signed-off-by: Steve Arnold 
---
 .../python/python-evdev/use-sysroot-headers.patch  | 24 +++
 .../recipes-devtools/python/python-evdev_0.6.0.bb  | 28 ++
 2 files changed, 48 insertions(+), 4 deletions(-)
 create mode 100644 
meta-python/recipes-devtools/python/python-evdev/use-sysroot-headers.patch

diff --git 
a/meta-python/recipes-devtools/python/python-evdev/use-sysroot-headers.patch 
b/meta-python/recipes-devtools/python/python-evdev/use-sysroot-headers.patch
new file mode 100644
index 000..ce62bfc
--- /dev/null
+++ b/meta-python/recipes-devtools/python/python-evdev/use-sysroot-headers.patch
@@ -0,0 +1,24 @@
+--- a/setup.py 2016-10-01 10:00:11.491758891 -0700
 b/setup.py 2016-10-01 10:01:45.045089476 -0700
+@@ -65,10 +65,17 @@
+ 
+ #-
+ def create_ecodes():
+-headers = [
+-'/usr/include/linux/input.h',
+-'/usr/include/linux/input-event-codes.h',
+-]
++
++if not os.path.lexists(os.path.expandvars('$STAGING_INCDIR')):
++headers = [
++'/usr/include/linux/input.h',
++'/usr/include/linux/input-event-codes.h',
++]
++else:
++headers = [
++os.path.expandvars('$STAGING_INCDIR/linux/input.h'),
++os.path.expandvars('$STAGING_INCDIR/linux/input-event-codes.h'),  
 
++]
+ 
+ headers = [header for header in headers if os.path.isfile(header)]
+ if not headers:
diff --git a/meta-python/recipes-devtools/python/python-evdev_0.6.0.bb 
b/meta-python/recipes-devtools/python/python-evdev_0.6.0.bb
index e52..152206a 100644
--- a/meta-python/recipes-devtools/python/python-evdev_0.6.0.bb
+++ b/meta-python/recipes-devtools/python/python-evdev_0.6.0.bb
@@ -4,9 +4,29 @@ SECTION = "devel/python"
 LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=18debddbb3f52c661a129724a883a8e2"
 
-SRC_URI = "https://github.com/gvalkov/python-evdev/archive/v${PV}.zip";
+SRC_URI = "file://use-sysroot-headers.patch"
 
-SRC_URI[md5sum] = "24e4ffa98e338b535eae44d91d609005"
-SRC_URI[sha256sum] = 
"61f6893d80da87a995e5781c74d22a39448b1b32004ffac2f31817017709be04"
+SRC_URI[md5sum] = "294ac2997bd419d56b9451511536f9f4"
+SRC_URI[sha256sum] = 
"c0e1410cc88eaa6a016baeafb2acb1274d36a057944143b59e94f36bb482"
 
-inherit setuptools
+inherit pypi setuptools
+
+DEPENDS_${PN} += "\
+${PYTHON_PN}-ctypes \
+"
+
+RDEPENDS_${PN} += "\
+${PYTHON_PN}-ctypes \
+${PYTHON_PN}-fcntl \
+${PYTHON_PN}-io \
+${PYTHON_PN}-shell \
+${PYTHON_PN}-stringold \
+"
+
+do_install_append() {
+# note the full docs require Sphinx to build them
+install -d ${D}${datadir}/doc/${BPN}/
+install -m 0644 ${S}/README.rst ${D}${datadir}/doc/${PN}/
+}
+
+PACKAGES = "${PN}-doc ${PN} ${PN}-dbg"
-- 
2.9.3

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

Re: [OE-core] Crazy display

[Stephen Arnold]

I do mostly remote screen sessions (on gentoo host, sometimes
ubuntu/debian vm) and occasional local terminal (xfce term but remote
could be console only).  The fact that I have not seen this once is
just *weird* (and I'm pretty damn good about hitting the annoying
bits).

Steve

On Mon, Oct 3, 2016 at 10:05 AM, Paul Eggleton
 wrote:
> On Fri, 16 Sep 2016 10:00:12 Paul Eggleton wrote:
>> On Thu, 15 Sep 2016 22:51:47 Richard Purdie wrote:
>> > On Fri, 2016-09-16 at 08:41 +1200, Paul Eggleton wrote:
>> > > On Thu, 15 Sep 2016 22:26:09 Gary Thomas wrote:
>> > > > On 2016-09-15 22:12, Burton, Ross wrote:
>> > > > > On 15 September 2016 at 21:03, Paul Eggleton
>> > >
>> > > mailto:paul.eggle...@linux.intel.com>
>> > >
>> > > > wrote:
>> > > > > Are you guys perhaps using the same terminal application?
>> > > > >
>> > > > > Using screen
>> > > > >
>> > > > > / tmux / anything similar? (I'm using screen here and haven't
>> > > > > experienced problems though.)
>> > > > >
>> > > > > I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
>> > > > > screen/tmux/etc.
>> > > >
>> > > > Pretty much the same for me - just SSH in an xterm window.
>> > >
>> > > Hmm, I'm still no closer then.
>> > >
>> > > Does it just start happening at some point in the middle of a build?
>> > > Or right
>> > > from the start?
>> >
>> > Seems to happen at various points during the build. Looks like bad
>> > timing of console updates so can happen at any point, I'd see evidence
>> > its happened multiple times in a given build.
>>
>> This is bizarre. Clearly something is different between your systems and
>> mine :/
>
> I just wanted to check particularly with Gary and Ross - since the following
> pseudo fix went in, are you still seeing this problem?
>
>  
> http://cgit.openembedded.org/openembedded-core/commit/?id=efd0b0f604f9f498b9c20bc9a25708c493aa4f4a
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> ___
> 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 v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

Sorry, I kinda needed something that worked.  I'll go back to slacking now...

Steve

On Mon, Aug 8, 2016 at 5:58 AM, Burton, Ross  wrote:
> Hi Fan, you're now added to the repo too.  Progress looks good!
>
> Ross
>
> On 3 August 2016 at 02:42, Fan Xin  wrote:
>>
>>
>>
>> On 2016年08月03日 10:12, Stephen Arnold wrote:
>>>
>>> sorry, you missed a couple of replies I guess...
>>>
>>> It's in the Ross repo now:
>>>
>>> https://github.com/rossburton/meta-printing
>>>
>>> Steve
>>>
>>
>> Hey, Ross
>>
>> If possible, please also add me.
>> Thanks.
>>
>> Fan
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

sorry, you missed a couple of replies I guess...

It's in the Ross repo now:

https://github.com/rossburton/meta-printing

Steve

On Tue, Aug 2, 2016 at 5:59 PM, Fan Xin  wrote:
>
> On 2016年08月03日 02:33, Stephen Arnold wrote:
>>
>> Hey, don't keep all the fun to yourself  :P
>>
>> Let's take a look at the recipes and marge the best bits together; I
>> think I have an update on my end after getting some feedback with a
>> zebra label printer.
>>
>> Fan, can you push/post your recipes somewhere today?  Feel free to
>> fork meta-small-arm-extra and we can take a look at merging.
>>
>> Steve
>>
>
> I have pushed my recipes at here:
>
> https://github.com/fan-xin/meta-printing
>
> I checked meta-small-arm-extra but did not find what could be merged from my
> recipe.
>
> I wonder where the cups-filters and qpdf recipe files should be put. In cups
> folder or separate folder ?
>
> Fan
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

On Tue, Aug 2, 2016 at 12:23 PM, Burton, Ross  wrote:
[snip]
> In a desperate attempt to keep the ball rolling I propose this repo as a
> starting point:
>
> https://github.com/rossburton/meta-printing
>
> It's basically a new layer containing foomatic, ghostscript and cups from
> oe-core.  Obviously this shouldn't be the final resting place, but its
> somewhere where we can start before deciding where it should reside.  If
> anyone wants commit access then just say.
>
> Ross

Okay, please add me...

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

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

Hey, don't keep all the fun to yourself  :P

Let's take a look at the recipes and marge the best bits together; I
think I have an update on my end after getting some feedback with a
zebra label printer.

Fan, can you push/post your recipes somewhere today?  Feel free to
fork meta-small-arm-extra and we can take a look at merging.

Steve

On Mon, Aug 1, 2016 at 11:48 PM, Fan Xin  wrote:
>
>
> On 2016年08月02日 02:24, Burton, Ross wrote:
>>
>>
>> On 1 August 2016 at 18:22, Stephen Arnold > <mailto:stephen.arnol...@gmail.com>> wrote:
>>
>> That's actually not a bad idea, but I need to crank out another
>> abstract today (the deadline for special session snuck up on me).  We
>> kinda needed this for a project, but I think a tiny print server is
>> always useful.  What's your plan?
>>
>>
>> Well my plan was:
>>
>> 1) say that someone should create meta-printing
>> 2) watch someone create meta-printing
>> 3) delete everything printing related in oe-core
>>
>> I can help a bit on (2) I guess...  Fan Xin, would you or anyone else at
>> Fujitsu (as you clearly have interest here) be able to help?
>
>
> Yes, Of course. Actually I am very pleased to do this.
> I am afraid I can not do it very well, but I will try my best.
>
> Fan
>
> --
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

Trying to remember what my dad said about "Ask a silly question..."

Steve

On Mon, Aug 1, 2016 at 10:24 AM, Burton, Ross  wrote:
>
> On 1 August 2016 at 18:22, Stephen Arnold 
> wrote:
>>
>> That's actually not a bad idea, but I need to crank out another
>> abstract today (the deadline for special session snuck up on me).  We
>> kinda needed this for a project, but I think a tiny print server is
>> always useful.  What's your plan?
>
>
> Well my plan was:
>
> 1) say that someone should create meta-printing
> 2) watch someone create meta-printing
> 3) delete everything printing related in oe-core
>
> I can help a bit on (2) I guess...  Fan Xin, would you or anyone else at
> Fujitsu (as you clearly have interest here) be able to help?
>
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

That's actually not a bad idea, but I need to crank out another
abstract today (the deadline for special session snuck up on me).  We
kinda needed this for a project, but I think a tiny print server is
always useful.  What's your plan?

Steve

On Mon, Aug 1, 2016 at 10:16 AM, Burton, Ross  wrote:
> Hi,
>
> On 1 August 2016 at 18:13, Stephen Arnold 
> wrote:
>>
>> Thanks, our timing is great (since I just did the same thing on
>> Saturday but didn't send anything to the list yet).  Still have some
>> testing to do to see if it actually works; recipes are here:
>>
>> https://github.com/sarnold/meta-small-arm-extra/commits/master
>
>
> Literally ten minutes ago I was wondering if there was any interest in
> ripping the obviously broken CUPS/ghostscript/etc out of oe-core and into a
> meta-printing layer that someone could actually maintain.  Would you be
> interested in that?
>
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

Thanks, our timing is great (since I just did the same thing on
Saturday but didn't send anything to the list yet).  Still have some
testing to do to see if it actually works; recipes are here:

https://github.com/sarnold/meta-small-arm-extra/commits/master

On Mon, Aug 1, 2016 at 4:01 AM, Fan Xin  wrote:
> The foomatic-filters community is inactive and foomatic-filter package is 
> unmaintained.
> (http://www.gossamer-threads.com/lists/gentoo/user/288184)
>
> The foomatic-rips is moved from foomatic-filters to cups-filters and
> maintained by cups-filters according to the cups-filter's NEWS.
> (http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/NEWS)
>
> Signed-off-by: Fan Xin 
> ---
>  .../cups-filters-1.8.2-disable-ijs.patch   | 65 
> ++
>  .../foomatic/cups-filters_1.8.3.bb | 34 +++
>  .../packagegroups/packagegroup-core-lsb.bb |  2 +-
>  3 files changed, 100 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
>  create mode 100644 meta/recipes-extended/foomatic/cups-filters_1.8.3.bb
>
> diff --git 
> a/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
>  
> b/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
> new file mode 100644
> index 000..0a0a6ad
> --- /dev/null
> +++ 
> b/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
> @@ -0,0 +1,65 @@
> +=== modified file 'Makefile.am'
> +--- Makefile.am2016-02-10 15:16:33 +
>  Makefile.am2016-03-02 20:46:26 +
> +@@ -490,7 +490,6 @@
> +   bannertopdf \
> +   commandtoescpx \
> +   commandtopclx \
> +-  pdftoijs \
> +   sys5ippprinter \
> +   pdftops \
> +   pdftoraster \
> +@@ -499,6 +498,10 @@
> +   texttopdf \
> +   urftopdf \
> +   rastertopdf
> ++if ENABLE_IJS
> ++pkgfilter_PROGRAMS += \
> ++  pdftoijs
> ++endif
> + if ENABLE_GHOSTSCRIPT
> + pkgfilter_PROGRAMS += \
> +   gstoraster
> +@@ -846,9 +849,12 @@
> +   ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd \
> +   ppd/Generic-PDF_Printer-PDF.ppd \
> +   ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd \
> +-  ppd/HP-PhotoSmart_Pro_B8300-hpijs-pdftoijs.ppd \
> +   ppd/Ricoh-PDF_Printer-PDF.ppd \
> +   ppd/textonly.ppd
> ++if ENABLE_IJS
> ++ppd_DATA += \
> ++  ppd/HP-PhotoSmart_Pro_B8300-hpijs-pdftoijs.ppd
> ++endif
> + if ENABLE_GHOSTSCRIPT
> + ppd_DATA += \
> +   ppd/pxlcolor.ppd \
> +=== modified file 'configure.ac'
> +--- configure.ac   2016-02-11 13:59:52 +
>  configure.ac   2016-03-02 21:18:05 +
> +@@ -443,7 +443,7 @@
> + ])
> + PKG_CHECK_MODULES([FREETYPE], [freetype2], [AC_DEFINE([HAVE_FREETYPE_H], 
> [1], [Have FreeType2 include files])])
> + PKG_CHECK_MODULES([FONTCONFIG], [fontconfig >= 2.0.0])
> +-PKG_CHECK_MODULES([IJS], [ijs])
> ++PKG_CHECK_MODULES([IJS], [ijs], [have_ijs=yes], [have_ijs=no])
> + PKG_CHECK_MODULES([POPPLER], [poppler >= 0.18])
> + PKG_CHECK_MODULES([ZLIB], [zlib])
> + AC_DEFINE([HAVE_LIBZ], [], [Define that we use zlib])
> +@@ -489,6 +489,15 @@
> +   [enable_ghostscript="$enableval"],
> +   [enable_ghostscript=yes]
> + )
> ++AC_ARG_ENABLE([ijs],
> ++  [AS_HELP_STRING([--disable-ijs], [Disable filters using IJS.])],
> ++  [enable_ijs="$enableval"],
> ++  [enable_ijs=yes]
> ++)
> ++AS_IF([test "x$enable_ijs" = "xyes" -a "x$have_ijs" != "xyes"], [
> ++   AC_MSG_ERROR([IJS not found, but requested.])
> ++])
> ++AM_CONDITIONAL(ENABLE_IJS, test "x$enable_ijs" = "xyes")
> + AC_ARG_WITH([pdftops],
> +   [AS_HELP_STRING([--with-pdftops=value], [Set which pdftops to use 
> (gs,pdftops,pdftocairo,acroread,hybrid).])],
> +   [with_pdftops="$withval"],
> +
> diff --git a/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb 
> b/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb
> new file mode 100644
> index 000..4eef7ef
> --- /dev/null
> +++ b/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb
> @@ -0,0 +1,34 @@
> +SUMMARY = "OpenPrinting printer support - filters"
> +DESCRIPTION = "CUPS is a standards-based, open source printing system \
> +developed by Apple Inc. for Mac OS® X and other UNIX®-like operating 
> systems. \
> +CUPS uses the Internet Printing Protocol ("IPP") and provides System V and \
> +Berkeley command-line interfaces, a web interface, and a C API to manage 
> printers \
> +and print jobs. \
> + \
> +This package consists of filters used by the printer spoolers \
> +to convert the incoming PostScript data into the printer's native \
> +format using a printer-specific, but spooler-independent PPD file. \
> +"
> +
> +DEPENDS += "cups tiff lcms freetype fontconfig poppler qpdf"
> +PR = "r0"
> +
> +LICENSE = "GPLv2 & LGPLv2 & MIT & GPLv2+ & GPLv3"
> +LIC_FILES_CHKSUM = 
> "file://${WORKDIR}/cups-filters-${PV}/COPYING;md5=d420e185486344da617655384835093

Re: [OE-core] [PATCH] Replace foomatic-filters with cups-filters

[Stephen Arnold]

No answer to this?  cups-filters would be kinda important for actual
printing, especially since the existing ghostscript/cups/poppler
packages have all been gutted of anything called *toraster.  The
current state (on krogoth at least) is completely broken; is there
something on another branch somewhere?  If so, I can't see it with
google...

Steve

On Fri, Apr 22, 2016 at 4:47 AM, Burton, Ross  wrote:
>
> On 21 April 2016 at 06:05, Fan Xin  wrote:
>>
>> +cups-filters \
>
>
> What recipe provides this package?
>
> Ross
>
> --
> ___
> 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 v4] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

The fuse-ld=bfd flag is not in the v4 patch, can you go back and try
the most recent one on the list?

Thanks...

On Thu, Jun 23, 2016 at 7:29 PM, Ting Liu  wrote:
> Same issue on CentOS 6.7. Older gcc does not support -fuse-ld=bfd.
>
> -Ting
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
>> Of Robert Yang
>> Sent: Thursday, June 23, 2016 3:55 PM
>> To: Stephen Arnold ; Patches and
>> discussions about the oe-core layer > c...@lists.openembedded.org>
>> Subject: Re: [OE-core] [PATCH v4] qemu-native: set ld.bfd, fix cflags, and 
>> set
>> some environment vars
>>
>>
>> Hi, I got build errors on Ubuntu 12.04 with this patch:
>>
>> | DEBUG: Executing shell function do_configure
>> |
>> | ERROR: "gcc " cannot build an executable (is your linker broken?)
>>
>>
>> // Robert
>>
>> On 06/21/2016 09:18 AM, Stephen Arnold wrote:
>> > And I finally figured out git send-email no longer has a
>> > --subject-prefix= option so it looks like --compose and hand-edit the
>> > Subject line in the patch is the only way to increment the version.
>> >
>> > This is [PATCH v4] btw...
>> >
>> > Steve
>> >
>> > On Mon, Jun 20, 2016 at 5:54 PM, Stephen Arnold 
>> wrote:
>> >> The main thing is build failures with gold linker, but qemu is also a
>> >> little too aggressive at finding random tools on the build host, so
>> >> we also set the build env for qemu-native and make sure it doesn't
>> >> reset its own (hard-coded) cflags when we don't want it to.
>> >>
>> >> Signed-off-by: Stephen Arnold 
>> >>
>> >> The cflags patch was imported from Gentoo Portage and has been
>> >> manitained over several versions; this version was rebased against
>> >> upstream qemu git.
>> >>
>> >> Upstream-Status: Inappropriate
>> >>   - Patch addresses distribution maintenance and build environment
>> >> sanity.
>> >>
>> >> Signed-off-by: Stephen Arnold 
>> >> ---
>> >>   meta/recipes-devtools/qemu/qemu.inc| 11 ++--
>> >>   .../qemu/qemu/qemu-2.6.0-cflags.patch  | 31
>> ++
>> >>   meta/recipes-devtools/qemu/qemu_2.6.0.bb   |  1 +
>> >>   3 files changed, 41 insertions(+), 2 deletions(-)
>> >>   create mode 100644
>> >> meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
>> >>
>> >> diff --git a/meta/recipes-devtools/qemu/qemu.inc
>> >> b/meta/recipes-devtools/qemu/qemu.inc
>> >> index bf689bb..0a68f05 100644
>> >> --- a/meta/recipes-devtools/qemu/qemu.inc
>> >> +++ b/meta/recipes-devtools/qemu/qemu.inc
>> >> @@ -30,8 +30,10 @@ SRC_URI_append_class-native = "\
>> >>
>> >>   EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --
>> disable-werror  --disable-bluez --disable-libiscsi --with-system-pixman --
>> extra-cflags='${CFLAGS}'"
>> >>
>> >> -EXTRA_OECONF_class-nativesdk = "--target-
>> list=${@get_qemu_target_list(d)} --disable-werror \
>> >> -   "
>> >> +EXTRA_OECONF_class-nativesdk = "--target-
>> list=${@get_qemu_target_list(d)} --disable-werror"
>> >> +
>> >> +EXTRA_OEMAKE_append_class-native = "
>> LD="${TARGET_PREFIX}ld.bfd" AR="${AR}" OBJCOPY="${OBJCOPY}"
>> LDFLAGS="${LDFLAGS}""
>> >> +
>> >>   export LIBTOOL="${HOST_SYS}-libtool"
>> >>
>> >>   do_configure_prepend_class-native() { @@ -40,6 +42,11 @@
>> >> do_configure_prepend_class-native() {
>> >>  if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
>> >>  export
>> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
>> >>  fi
>> >> +
>> >> +   # Alter target makefiles to accept CFLAGS set via env
>> >> +   sed -i -r \
>> >> +   -e 's/^(C|OP_C|HELPER_C)FLAGS=/\1FLAGS+=/' \
>> >> +   "${S}"/Makefile "${S}"/Makefile.target
>> >>   }
>> >>
>> >>   KVMENABLE = "--enable-kvm"
>> >> diff --git a/meta/recipes-devtools/qem

Re: [OE-core] [PATCH v4] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

And I finally figured out git send-email no longer has a
--subject-prefix= option so it looks like --compose and hand-edit the
Subject line in the patch is the only way to increment the version.

This is [PATCH v4] btw...

Steve

On Mon, Jun 20, 2016 at 5:54 PM, Stephen Arnold  wrote:
> The main thing is build failures with gold linker, but qemu is also a
> little too aggressive at finding random tools on the build host, so we
> also set the build env for qemu-native and make sure it doesn't reset
> its own (hard-coded) cflags when we don't want it to.
>
> Signed-off-by: Stephen Arnold 
>
> The cflags patch was imported from Gentoo Portage and has been
> manitained over several versions; this version was rebased against
> upstream qemu git.
>
> Upstream-Status: Inappropriate
>  - Patch addresses distribution maintenance and build environment
>sanity.
>
> Signed-off-by: Stephen Arnold 
> ---
>  meta/recipes-devtools/qemu/qemu.inc| 11 ++--
>  .../qemu/qemu/qemu-2.6.0-cflags.patch  | 31 
> ++
>  meta/recipes-devtools/qemu/qemu_2.6.0.bb   |  1 +
>  3 files changed, 41 insertions(+), 2 deletions(-)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index bf689bb..0a68f05 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -30,8 +30,10 @@ SRC_URI_append_class-native = "\
>
>  EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror  
> --disable-bluez --disable-libiscsi --with-system-pixman 
> --extra-cflags='${CFLAGS}'"
>
> -EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
> --disable-werror \
> -   "
> +EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
> --disable-werror"
> +
> +EXTRA_OEMAKE_append_class-native = " LD="${TARGET_PREFIX}ld.bfd" AR="${AR}" 
> OBJCOPY="${OBJCOPY}" LDFLAGS="${LDFLAGS}""
> +
>  export LIBTOOL="${HOST_SYS}-libtool"
>
>  do_configure_prepend_class-native() {
> @@ -40,6 +42,11 @@ do_configure_prepend_class-native() {
> if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
> export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
> fi
> +
> +   # Alter target makefiles to accept CFLAGS set via env
> +   sed -i -r \
> +   -e 's/^(C|OP_C|HELPER_C)FLAGS=/\1FLAGS+=/' \
> +   "${S}"/Makefile "${S}"/Makefile.target
>  }
>
>  KVMENABLE = "--enable-kvm"
> diff --git a/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch 
> b/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
> new file mode 100644
> index 000..5b78edf
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
> @@ -0,0 +1,31 @@
> +From 5d29baaf7a8c09f2f97231116e0f396b0402b23d Mon Sep 17 00:00:00 2001
> +From: Steve Arnold 
> +Date: Sun, 19 Jun 2016 11:29:44 -0700
> +Subject: [PATCH] configure: remove hard-coded flags and let build env handle
> + it
> +
> +Apply distribution patch for handling debug and fortify source options.
> +
> +Signed-off-by: Steve Arnold 
> +---
> + configure | 4 
> + 1 file changed, 4 deletions(-)
> +
> +diff --git a/configure b/configure
> +index 10cb212..6f1b10c 100755
> +--- a/configure
>  b/configure
> +@@ -4539,10 +4539,6 @@ fi
> + if test "$gcov" = "yes" ; then
> +   CFLAGS="-fprofile-arcs -ftest-coverage -g $CFLAGS"
> +   LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS"
> +-elif test "$fortify_source" = "yes" ; then
> +-  CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS"
> +-elif test "$debug" = "no"; then
> +-  CFLAGS="-O2 $CFLAGS"
> + fi
> +
> + ##
> +--
> +2.8.1
> +
> diff --git a/meta/recipes-devtools/qemu/qemu_2.6.0.bb 
> b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> index e391326..62c509b 100644
> --- a/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> +++ b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> @@ -8,6 +8,7 @@ SRC_URI += 
> "file://configure-fix-Darwin-target-detection.patch \
>  file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
>  file://no-valgrind.patch \
>  file://pathlimit.patch \
> +file://qemu-2.5.0-cflags.patch \
> "
>  SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
>  SRC_URI[md5sum] = "ca3f70b43f093e33e9e014f144067f13"
> --
> 2.8.1
>
> --
> ___
> 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] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

The main thing is build failures with gold linker, but qemu is also a
little too aggressive at finding random tools on the build host, so we
also set the build env for qemu-native and make sure it doesn't reset
its own (hard-coded) cflags when we don't want it to.

Signed-off-by: Stephen Arnold 

The cflags patch was imported from Gentoo Portage and has been
manitained over several versions; this version was rebased against
upstream qemu git.

Upstream-Status: Inappropriate
 - Patch addresses distribution maintenance and build environment
   sanity.

Signed-off-by: Stephen Arnold 
---
 meta/recipes-devtools/qemu/qemu.inc| 11 ++--
 .../qemu/qemu/qemu-2.6.0-cflags.patch  | 31 ++
 meta/recipes-devtools/qemu/qemu_2.6.0.bb   |  1 +
 3 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index bf689bb..0a68f05 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -30,8 +30,10 @@ SRC_URI_append_class-native = "\
 
 EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror  
--disable-bluez --disable-libiscsi --with-system-pixman 
--extra-cflags='${CFLAGS}'"
 
-EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
--disable-werror \
-   "
+EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
--disable-werror"
+
+EXTRA_OEMAKE_append_class-native = " LD="${TARGET_PREFIX}ld.bfd" AR="${AR}" 
OBJCOPY="${OBJCOPY}" LDFLAGS="${LDFLAGS}""
+
 export LIBTOOL="${HOST_SYS}-libtool"
 
 do_configure_prepend_class-native() {
@@ -40,6 +42,11 @@ do_configure_prepend_class-native() {
if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
fi
+
+   # Alter target makefiles to accept CFLAGS set via env
+   sed -i -r \
+   -e 's/^(C|OP_C|HELPER_C)FLAGS=/\1FLAGS+=/' \
+   "${S}"/Makefile "${S}"/Makefile.target
 }
 
 KVMENABLE = "--enable-kvm"
diff --git a/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch 
b/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
new file mode 100644
index 000..5b78edf
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
@@ -0,0 +1,31 @@
+From 5d29baaf7a8c09f2f97231116e0f396b0402b23d Mon Sep 17 00:00:00 2001
+From: Steve Arnold 
+Date: Sun, 19 Jun 2016 11:29:44 -0700
+Subject: [PATCH] configure: remove hard-coded flags and let build env handle
+ it
+
+Apply distribution patch for handling debug and fortify source options.
+
+Signed-off-by: Steve Arnold 
+---
+ configure | 4 
+ 1 file changed, 4 deletions(-)
+
+diff --git a/configure b/configure
+index 10cb212..6f1b10c 100755
+--- a/configure
 b/configure
+@@ -4539,10 +4539,6 @@ fi
+ if test "$gcov" = "yes" ; then
+   CFLAGS="-fprofile-arcs -ftest-coverage -g $CFLAGS"
+   LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS"
+-elif test "$fortify_source" = "yes" ; then
+-  CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS"
+-elif test "$debug" = "no"; then
+-  CFLAGS="-O2 $CFLAGS"
+ fi
+ 
+ ##
+-- 
+2.8.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.6.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
index e391326..62c509b 100644
--- a/meta/recipes-devtools/qemu/qemu_2.6.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
@@ -8,6 +8,7 @@ SRC_URI += "file://configure-fix-Darwin-target-detection.patch \
 file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
 file://no-valgrind.patch \
 file://pathlimit.patch \
+file://qemu-2.5.0-cflags.patch \
"
 SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
 SRC_URI[md5sum] = "ca3f70b43f093e33e9e014f144067f13"
-- 
2.8.1

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

Re: [OE-core] [PATCH] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

Following this:

http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

and it still strips my " v3" from PATCH.  Is there another
document/prefix format I should be looking at?

Thanks, Steve

On Sun, Jun 19, 2016 at 12:40 PM, Stephen Arnold  wrote:
> The main thing is build failures with gold linker, but qemu is also
> a little too aggressive at finding random tools on the build host, so
> we also set the build env for qemu-native and make sure it doesn't
> reset its own (hard-coded) cflags when we don't want it to.
>
> Signed-off-by: Stephen Arnold 
>
> The cflags patch was imported from Gentoo Portage and has been
> manitained over several versions; this version was rebased against
> upstream qemu git.
>
> Upstream-Status: Inappropriate
>  - Patch addresses distribution maintenance and build environment
>sanity.
>
> Signed-off-by: Stephen Arnold 
> ---
>  meta/recipes-devtools/qemu/qemu.inc| 13 +++--
>  .../qemu/qemu/qemu-2.6.0-cflags.patch  | 31 
> ++
>  meta/recipes-devtools/qemu/qemu_2.6.0.bb   |  1 +
>  3 files changed, 43 insertions(+), 2 deletions(-)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index bf689bb..d5925fd 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -30,8 +30,12 @@ SRC_URI_append_class-native = "\
>
>  EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror  
> --disable-bluez --disable-libiscsi --with-system-pixman 
> --extra-cflags='${CFLAGS}'"
>
> -EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
> --disable-werror \
> -   "
> +EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
> --disable-werror"
> +
> +EXTRA_OEMAKE_append_class-native = " LD='${LD}' AR='${AR}' 
> OBJCOPY='${OBJCOPY}' LDFLAGS='${LDFLAGS}'"
> +
> +LDFLAGS_append_class-native = " -fuse-ld=bfd"
> +
>  export LIBTOOL="${HOST_SYS}-libtool"
>
>  do_configure_prepend_class-native() {
> @@ -40,6 +44,11 @@ do_configure_prepend_class-native() {
> if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
> export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
> fi
> +
> +   # Alter target makefiles to accept CFLAGS set via env
> +   sed -i -r \
> +   -e 's/^(C|OP_C|HELPER_C)FLAGS=/\1FLAGS+=/' \
> +   "${S}"/Makefile "${S}"/Makefile.target
>  }
>
>  KVMENABLE = "--enable-kvm"
> diff --git a/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch 
> b/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
> new file mode 100644
> index 000..5b78edf
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
> @@ -0,0 +1,31 @@
> +From 5d29baaf7a8c09f2f97231116e0f396b0402b23d Mon Sep 17 00:00:00 2001
> +From: Steve Arnold 
> +Date: Sun, 19 Jun 2016 11:29:44 -0700
> +Subject: [PATCH] configure: remove hard-coded flags and let build env handle
> + it
> +
> +Apply distribution patch for handling debug and fortify source options.
> +
> +Signed-off-by: Steve Arnold 
> +---
> + configure | 4 
> + 1 file changed, 4 deletions(-)
> +
> +diff --git a/configure b/configure
> +index 10cb212..6f1b10c 100755
> +--- a/configure
>  b/configure
> +@@ -4539,10 +4539,6 @@ fi
> + if test "$gcov" = "yes" ; then
> +   CFLAGS="-fprofile-arcs -ftest-coverage -g $CFLAGS"
> +   LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS"
> +-elif test "$fortify_source" = "yes" ; then
> +-  CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS"
> +-elif test "$debug" = "no"; then
> +-  CFLAGS="-O2 $CFLAGS"
> + fi
> +
> + ##
> +--
> +2.8.1
> +
> diff --git a/meta/recipes-devtools/qemu/qemu_2.6.0.bb 
> b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> index e391326..62c509b 100644
> --- a/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> +++ b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> @@ -8,6 +8,7 @@ SRC_URI += 
> "file://configure-fix-Darwin-target-detection.patch \
>  file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
>  file://no-valgrind.patch \
>  file://pathlimit.patch \
> +file://qemu-2.5.0-cflags.patch \
> "
>  SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
>  SRC_URI[md5sum] = "ca3f70b43f093e33e9e014f144067f13"
> --
> 2.8.1
>
> --
> ___
> 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] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

The main thing is build failures with gold linker, but qemu is also
a little too aggressive at finding random tools on the build host, so
we also set the build env for qemu-native and make sure it doesn't
reset its own (hard-coded) cflags when we don't want it to.

Signed-off-by: Stephen Arnold 

The cflags patch was imported from Gentoo Portage and has been
manitained over several versions; this version was rebased against
upstream qemu git.

Upstream-Status: Inappropriate
 - Patch addresses distribution maintenance and build environment
   sanity.

Signed-off-by: Stephen Arnold 
---
 meta/recipes-devtools/qemu/qemu.inc| 13 +++--
 .../qemu/qemu/qemu-2.6.0-cflags.patch  | 31 ++
 meta/recipes-devtools/qemu/qemu_2.6.0.bb   |  1 +
 3 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index bf689bb..d5925fd 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -30,8 +30,12 @@ SRC_URI_append_class-native = "\
 
 EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror  
--disable-bluez --disable-libiscsi --with-system-pixman 
--extra-cflags='${CFLAGS}'"
 
-EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
--disable-werror \
-   "
+EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
--disable-werror"
+
+EXTRA_OEMAKE_append_class-native = " LD='${LD}' AR='${AR}' 
OBJCOPY='${OBJCOPY}' LDFLAGS='${LDFLAGS}'"
+
+LDFLAGS_append_class-native = " -fuse-ld=bfd"
+
 export LIBTOOL="${HOST_SYS}-libtool"
 
 do_configure_prepend_class-native() {
@@ -40,6 +44,11 @@ do_configure_prepend_class-native() {
if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
fi
+
+   # Alter target makefiles to accept CFLAGS set via env
+   sed -i -r \
+   -e 's/^(C|OP_C|HELPER_C)FLAGS=/\1FLAGS+=/' \
+   "${S}"/Makefile "${S}"/Makefile.target
 }
 
 KVMENABLE = "--enable-kvm"
diff --git a/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch 
b/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
new file mode 100644
index 000..5b78edf
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/qemu-2.6.0-cflags.patch
@@ -0,0 +1,31 @@
+From 5d29baaf7a8c09f2f97231116e0f396b0402b23d Mon Sep 17 00:00:00 2001
+From: Steve Arnold 
+Date: Sun, 19 Jun 2016 11:29:44 -0700
+Subject: [PATCH] configure: remove hard-coded flags and let build env handle
+ it
+
+Apply distribution patch for handling debug and fortify source options.
+
+Signed-off-by: Steve Arnold 
+---
+ configure | 4 
+ 1 file changed, 4 deletions(-)
+
+diff --git a/configure b/configure
+index 10cb212..6f1b10c 100755
+--- a/configure
 b/configure
+@@ -4539,10 +4539,6 @@ fi
+ if test "$gcov" = "yes" ; then
+   CFLAGS="-fprofile-arcs -ftest-coverage -g $CFLAGS"
+   LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS"
+-elif test "$fortify_source" = "yes" ; then
+-  CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS"
+-elif test "$debug" = "no"; then
+-  CFLAGS="-O2 $CFLAGS"
+ fi
+ 
+ ##
+-- 
+2.8.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.6.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
index e391326..62c509b 100644
--- a/meta/recipes-devtools/qemu/qemu_2.6.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
@@ -8,6 +8,7 @@ SRC_URI += "file://configure-fix-Darwin-target-detection.patch \
 file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
 file://no-valgrind.patch \
 file://pathlimit.patch \
+file://qemu-2.5.0-cflags.patch \
"
 SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
 SRC_URI[md5sum] = "ca3f70b43f093e33e9e014f144067f13"
-- 
2.8.1

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

Re: [OE-core] [PATCH] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

.o): requires unsupported
dynamic reloc 11; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires unsupported
dynamic reloc 11; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires unsupported
dynamic reloc 11; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires unsupported
dynamic reloc 11; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires dynamic
R_X86_64_32 reloc against
'_ZN9__gnu_cxx24__concurrence_lock_errorD1Ev' which may overflow at
runtime; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires dynamic
R_X86_64_32 reloc against
'_ZN9__gnu_cxx26__concurrence_unlock_errorD1Ev' which may overflow at
runtime; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires dynamic
R_X86_64_PC32 reloc against 'malloc' which may overflow at runtime;
recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires unsupported
dynamic reloc 11; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires dynamic
R_X86_64_PC32 reloc against 'malloc' which may overflow at runtime;
recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires unsupported
dynamic reloc 11; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(eh_alloc.o): requires dynamic
R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(vterminate.o): requires dynamic
R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(vterminate.o): requires dynamic
R_X86_64_32 reloc against '_ZTISt9exception' which may overflow at
runtime; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(vterminate.o): requires dynamic
R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(pure.o): requires dynamic R_X86_64_32
reloc which may overflow at runtime; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(pure.o): requires dynamic R_X86_64_32
reloc which may overflow at runtime; recompile with -fPIC
| /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /usr/lib64/libstdc++.a(cp-demangle.o): requires unsupported
dynamic reloc 11; recompile with -fPIC
| collect2: error: ld returned 1 exit status
| Makefile:193: recipe for target 'qemu-system-arm' failed
| make[1]: *** [qemu-system-arm] Error 1
| Makefile:184: recipe for target 'subdir-arm-softmmu' failed
| make: *** [subdir-arm-softmmu] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (log file is located at
/home/sarnold/beagleboard-bsp/poky/build-newkern/tmp/work/x86_64-linux/qemu-native/2.5.0-r1/temp/log.do_compile.29916)
ERROR: Task 4 
(virtual:native:/home/sarnold/beagleboard-bsp/poky/meta/recipes-devtools/qemu/qemu_2.5.0.bb,
do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 187 tasks of which 185 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:
  
virtual:native:/home/sarnold/beagleboard-bsp/poky/meta/recipes-devtools/qemu/qemu_2.5.0.bb,
do_compile

On Wed, Jun 15, 2016 at 2:03 PM, Khem Raj  wrote:
> On Sun, Jun 12, 2016 at 6:09 PM, Stephen Arnold  wrote:
>> The main thing is build failures with gold linker, but qemu is also a
>> little too aggressive at finding random tools on the build host, so we
>> also set the build env for qemu-native and make sure it doesn't reset
>> its own (hard-coded) cflags when we don't want it to.
>>
>> Signed-off-by: Stephen Arnold 
>> ---
>>  meta/recipes-devtools/qemu/qemu.inc | 13 +++--
>>  meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.pa

Re: [OE-core] [PATCH] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

Okay, that wasn't supposed to cut off the v2 after PATCH...

Anyway, this is/was v2 for master branch (needs testing).

Steve

On Sun, Jun 12, 2016 at 6:09 PM, Stephen Arnold  wrote:
> The main thing is build failures with gold linker, but qemu is also a
> little too aggressive at finding random tools on the build host, so we
> also set the build env for qemu-native and make sure it doesn't reset
> its own (hard-coded) cflags when we don't want it to.
>
> Signed-off-by: Stephen Arnold 
> ---
>  meta/recipes-devtools/qemu/qemu.inc | 13 +++--
>  meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch | 13 +
>  meta/recipes-devtools/qemu/qemu_2.6.0.bb|  4 +++-
>  3 files changed, 27 insertions(+), 3 deletions(-)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index bf689bb..d5925fd 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -30,8 +30,12 @@ SRC_URI_append_class-native = "\
>
>  EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror  
> --disable-bluez --disable-libiscsi --with-system-pixman 
> --extra-cflags='${CFLAGS}'"
>
> -EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
> --disable-werror \
> -   "
> +EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
> --disable-werror"
> +
> +EXTRA_OEMAKE_append_class-native = " LD='${LD}' AR='${AR}' 
> OBJCOPY='${OBJCOPY}' LDFLAGS='${LDFLAGS}'"
> +
> +LDFLAGS_append_class-native = " -fuse-ld=bfd"
> +
>  export LIBTOOL="${HOST_SYS}-libtool"
>
>  do_configure_prepend_class-native() {
> @@ -40,6 +44,11 @@ do_configure_prepend_class-native() {
> if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
> export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
> fi
> +
> +   # Alter target makefiles to accept CFLAGS set via env
> +   sed -i -r \
> +   -e 's/^(C|OP_C|HELPER_C)FLAGS=/\1FLAGS+=/' \
> +   "${S}"/Makefile "${S}"/Makefile.target
>  }
>
>  KVMENABLE = "--enable-kvm"
> diff --git a/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch 
> b/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch
> new file mode 100644
> index 000..173394f
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch
> @@ -0,0 +1,13 @@
> +--- a/configure
>  b/configure
> +@@ -4468,10 +4468,6 @@ fi
> + if test "$gcov" = "yes" ; then
> +   CFLAGS="-fprofile-arcs -ftest-coverage -g $CFLAGS"
> +   LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS"
> +-elif test "$fortify_source" = "yes" ; then
> +-  CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS"
> +-elif test "$debug" = "no"; then
> +-  CFLAGS="-O2 $CFLAGS"
> + fi
> +
> + ##
> diff --git a/meta/recipes-devtools/qemu/qemu_2.6.0.bb 
> b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> index e391326..735d013 100644
> --- a/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> +++ b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
> @@ -8,7 +8,9 @@ SRC_URI += 
> "file://configure-fix-Darwin-target-detection.patch \
>  file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
>  file://no-valgrind.patch \
>  file://pathlimit.patch \
> -   "
> +file://qemu-2.5.0-cflags.patch \
> +"
> +
>  SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
>  SRC_URI[md5sum] = "ca3f70b43f093e33e9e014f144067f13"
>  SRC_URI[sha256sum] = 
> "c9ac4a651b273233d21b8bec32e30507cb9cce7900841febc330956a1a8434ec"
> --
> 2.8.1
>
> --
> ___
> 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] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

The main thing is build failures with gold linker, but qemu is also a
little too aggressive at finding random tools on the build host, so we
also set the build env for qemu-native and make sure it doesn't reset
its own (hard-coded) cflags when we don't want it to.

Signed-off-by: Stephen Arnold 
---
 meta/recipes-devtools/qemu/qemu.inc | 13 +++--
 meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch | 13 +
 meta/recipes-devtools/qemu/qemu_2.6.0.bb|  4 +++-
 3 files changed, 27 insertions(+), 3 deletions(-)
 create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index bf689bb..d5925fd 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -30,8 +30,12 @@ SRC_URI_append_class-native = "\
 
 EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror  
--disable-bluez --disable-libiscsi --with-system-pixman 
--extra-cflags='${CFLAGS}'"
 
-EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
--disable-werror \
-   "
+EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
--disable-werror"
+
+EXTRA_OEMAKE_append_class-native = " LD='${LD}' AR='${AR}' 
OBJCOPY='${OBJCOPY}' LDFLAGS='${LDFLAGS}'"
+
+LDFLAGS_append_class-native = " -fuse-ld=bfd"
+
 export LIBTOOL="${HOST_SYS}-libtool"
 
 do_configure_prepend_class-native() {
@@ -40,6 +44,11 @@ do_configure_prepend_class-native() {
if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
fi
+
+   # Alter target makefiles to accept CFLAGS set via env
+   sed -i -r \
+   -e 's/^(C|OP_C|HELPER_C)FLAGS=/\1FLAGS+=/' \
+   "${S}"/Makefile "${S}"/Makefile.target
 }
 
 KVMENABLE = "--enable-kvm"
diff --git a/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch 
b/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch
new file mode 100644
index 000..173394f
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch
@@ -0,0 +1,13 @@
+--- a/configure
 b/configure
+@@ -4468,10 +4468,6 @@ fi
+ if test "$gcov" = "yes" ; then
+   CFLAGS="-fprofile-arcs -ftest-coverage -g $CFLAGS"
+   LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS"
+-elif test "$fortify_source" = "yes" ; then
+-  CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS"
+-elif test "$debug" = "no"; then
+-  CFLAGS="-O2 $CFLAGS"
+ fi
+ 
+ ##
diff --git a/meta/recipes-devtools/qemu/qemu_2.6.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
index e391326..735d013 100644
--- a/meta/recipes-devtools/qemu/qemu_2.6.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.6.0.bb
@@ -8,7 +8,9 @@ SRC_URI += "file://configure-fix-Darwin-target-detection.patch \
 file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
 file://no-valgrind.patch \
 file://pathlimit.patch \
-   "
+file://qemu-2.5.0-cflags.patch \
+"
+
 SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
 SRC_URI[md5sum] = "ca3f70b43f093e33e9e014f144067f13"
 SRC_URI[sha256sum] = 
"c9ac4a651b273233d21b8bec32e30507cb9cce7900841febc330956a1a8434ec"
-- 
2.8.1

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

[OE-core] [PATCH] qemu-native: set ld.bfd, fix cflags, and set some environment vars

[Stephen Arnold]

The main thing is build failures with gold linker, but qemu is also a
little too aggressive at finding random tools on the build host, so we
also set the build env for qemu-native and make sure it doesn't reset
its own (hard-coded) cflags when we don't want it to.

Signed-off-by: Stephen Arnold 
---
 meta/recipes-devtools/qemu/qemu.inc | 13 +++--
 meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch | 13 +
 meta/recipes-devtools/qemu/qemu_2.5.0.bb|  1 +
 3 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 95fe66f..87c9f75 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -30,8 +30,12 @@ SRC_URI_append_class-native = "\
 
 EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror  
--disable-bluez --disable-libiscsi --with-system-pixman 
--extra-cflags='${CFLAGS}'"
 
-EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
--disable-werror \
-   "
+EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
--disable-werror"
+
+EXTRA_OEMAKE_append_class-native = " LD='${LD}' AR='${AR}' 
OBJCOPY='${OBJCOPY}' LDFLAGS='${LDFLAGS}'"
+
+LDFLAGS_append_class-native = " -fuse-ld=bfd"
+
 export LIBTOOL="${HOST_SYS}-libtool"
 
 do_configure_prepend_class-native() {
@@ -40,6 +44,11 @@ do_configure_prepend_class-native() {
if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
fi
+
+   # Alter target makefiles to accept CFLAGS set via env
+   sed -i -r \
+   -e 's/^(C|OP_C|HELPER_C)FLAGS=/\1FLAGS+=/' \
+   "${S}"/Makefile "${S}"/Makefile.target
 }
 
 KVMENABLE = "--enable-kvm"
diff --git a/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch 
b/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch
new file mode 100644
index 000..173394f
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/qemu-2.5.0-cflags.patch
@@ -0,0 +1,13 @@
+--- a/configure
 b/configure
+@@ -4468,10 +4468,6 @@ fi
+ if test "$gcov" = "yes" ; then
+   CFLAGS="-fprofile-arcs -ftest-coverage -g $CFLAGS"
+   LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS"
+-elif test "$fortify_source" = "yes" ; then
+-  CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS"
+-elif test "$debug" = "no"; then
+-  CFLAGS="-O2 $CFLAGS"
+ fi
+ 
+ ##
diff --git a/meta/recipes-devtools/qemu/qemu_2.5.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
index 03a6cbe..97ad743 100644
--- a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
@@ -16,6 +16,7 @@ SRC_URI += 
"file://configure-fix-Darwin-target-detection.patch \
 file://rng_remove_the_unused_request_cancellation_code.patch \
 
file://rng_move_request_queue_cleanup_from_RngEgd_to_RngBackend.patch \
 file://CVE-2016-2858.patch \
+file://qemu-2.5.0-cflags.patch \
"
 SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
 SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
-- 
2.8.1

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

Re: [OE-core] Aarch64 u-boot with gcc .5x

[Stephen Arnold]

I hit the same thing and ended up using their prebuilt bootloader to
get it up for testing.  There is a big C++ ABI change with gcc 5.x
(I've been using 5.3.0 for a while now) and the gold linker is much
less tolerant of underlinking than bfd is.  That said, their u-boot is
funky but not actually that old, and they also have a blob 1st-stage
that is only provided as a binary.

Their wiki:

http://odroid.com/dokuwiki/doku.php?id=en:c2_building_u-boot

says to checkout branch odroidc2-v2015.01 but I didn't dig into the
commit history to see when they last pulled from upstream.  The error
I get with 5.3.0 looks like their u-boot/include/linux stuff is just
way too old for gcc5 (since they're still using a 3.10 kernel fork
probably).  Their build also blows up with gcc-4.8 - can you say
brittle-hard-dep on gcc 4.9?

Steve

On Mon, Mar 28, 2016 at 11:20 AM, Otavio Salvador
 wrote:
> Hello Armin,
>
> On Mon, Mar 28, 2016 at 12:51 PM, akuster808  wrote:
>> I have an arm64 odroid c2 board.  If I build u-boot with the current OE
>> 5.3 gcc it hangs at kernel load time. If I use 4.9 gcc it works fine. A
>> 5.3 built kernel boots fine with a 4.9 built u-boot.
>>
>> The vendor supplied u-boot is hacked up and am leaning it that direction
>> as the culprit so I am looking for data points.
>>
>> Is anyone using a current u-boot with 5.3 gcc on an arm64 machine? if
>> so, any special tweaks to get that combo to work?
>
> I am using one ARM 64 SoC with GCC 5.2 at this moment and it works
> fine. What U-Boot version is the fork based on?
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
> --
> ___
> 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] Problems with perl 5.22

[Stephen Arnold]

As another point of information, I'm having similar issue with perl
5.22.1 on some arm boxes (native Gentoo builds) and even some odd
build differences between amd box and intel corei5 9 (I know,
weird...).

The issue I'm hitting is basically a horribly broken upstream
Configure script, and in my case it misdetects some libc functions as
"not available" and substitutes even more horribly broken replacement
functions.  Hacking the resulting config file *after* configure makes
it build successfully; seems to run okay but I'm not trying anything
like amanda to actually test it.

Like I said, it doesn't sound like your description but please
check/fix these two defines, or any others that are incorrect; this is
my ebuild post-configure hack:

sed -i \
-e "s|d_fork='undef'|d_fork='define'|" \
-e "s|d_memcpy='undef'|d_memcpy='define'|" \
"${S}"/config.sh

Steve

On Thu, Mar 10, 2016 at 8:00 AM, Gary Thomas  wrote:
> On 2016-03-10 16:54, Jens Rehsack wrote:
>>
>>
>>> Am 10.03.2016 um 06:13 schrieb Gary Thomas :
>>>
>>> I'm working on a package (amanda - the Advanced Maryland Archiving
>>> system) that is written heavily in perl with swig interfaces to C.
>>> This code ran great until the update to perl 5.22; it now dies a
>>> horrible death on almost every activity.  These failures seem to
>>> always be in the swig generated wrappers, but that may just be
>>> where most of the work gets done.
>>>
>>> I've narrowed this down to exactly the change to perl 5.22 from
>>> 5.20. Using bisect as well as experimentation (e.g. trying all
>>> the compiler combinations that have occurred since a last good
>>> version) and I can go from working to failing by only the change
>>> in perl.
>>>
>>> The interesting (scary) thing is that I've built amanda for my
>>> target natively on my board running debian, including perl 5.22.
>>> This means I can't say definitively  that perl 5.22 is the culprit
>>> as on debian it runs fine.  So, it's got something to do with the
>>> OE environment/porting/packaging of perl and not just the revision.
>>>
>>> I've also tested this on multiple architectures (ARM, PowerPC) with
>>> the same results - with perl 5.20 amanda works, with perl 5.22 it fails.
>>>
>>> I've compared the actual 5.22.1 sources used by OE-core and debian
>>> and they are subtly different, although I can't pinpoint any change
>>> that might be responsible.
>>>
>>> For the moment, I can just fall back to perl 5.20 for my target
>>> that needs to run amanda, but this isn't a real solution (e.g.
>>> in this state I can't propose my recipe to any layer as it's
>>> totally broken with the current OE-core).  I'd like to see this
>>> fixed but the amanda code (swig wrappers) are horribly complex
>>> which makes debugging quite the challenge, not to mention they
>>> may be about the only way to uncover the bug, whether it's in
>>> amanda or perl.
>>>
>>> Any suggestions on how to move forward?
>>
>>
>> Since I have no clue what's wrong and how it fails (backtrace
>> would point in some directions), several ideas might work:
>
>
> The problem here is that the failures happen in the swig generated
> files which are very difficult to debug (and don't really track
> in the -dbg packages)
>
>>
>> How clean is your build location (we realize that often between
>> updates some files remain in our target images until we wipe
>> tmp/ - cleansstate for image doesn't help ...)?
>
>
> 100% clean, I've started from scratch many times
>
>>
>> Did you prove the library path's of your *.so's? Perl does
>> almost everything within libperl.so - build against wrong version
>> causes in weird crashes (scan DBI mailing list for admin's
>> build issues of DBI on AIX/HP-UX ...).
>
>
> As I said, this all works fine when I build [from scratch] with
> perl-5.20 and not [from scratch] with perl 5.22
>
>>
>> Maybe share your recipe can help to reproduce the problem
>> elsewhere and debug locally.
>>
>
> I'd be happy to share, perhaps privately if you're inclined?
> It's a complicated setup and testing can be a bit tedious, but
> I'm happy for any help.
>
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> 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] [oe] Fwd: open source conference in Honduras needs Yocto Project/Openembedded/OpenHardware speaker

[Stephen Arnold]

Then I assume open source and related examples related to open
hardware?  Most of the "open" hardware I've got is still tied to
vendor blobs/forks; several specific machines have good mainline
kernel/u-boot support (with a few patches) but that's about as far as
things go, although some of the video support is in-work currently
(eg, rpi kms-vc4 kernel/mesa support).

Can you give some examples?  If I can make it, I would probably submit
something on using OpenEmbedded with some of the more "open" machines,
eg, RPi, BeagleBone, iMX/6, etc.  I've pledged on a couple of the
newer devices on kickstarter but I won't actually have any for a while
yet...

Steve

On Sat, Jun 13, 2015 at 6:05 PM, Diego Turcios  wrote:
> Hi Eduardo
> The event is a meeting of central American hackers, developers, open source
> activists, students and teachers.
>
> We expect from 70 - 120 people from central america. Plus local people
> (100-200) .
>
> My expectations is to start promoting open hardware in the region. Currently
> we have a strong feeling on free software and open source, but not on open
> hardware.
>
> For doing this, we need to start involving more open hardware projects on
> the region, how they work and involved all of this technology in the people.
>
> Thanks
> Diego
>
> El jun. 10, 2015 12:10 PM, "Eduardo Silva"  escribió:
>>
>> Hi Diego,
>>
>> I am available on those days. Would you please share more details/stats
>> about the attendees, expectations, others ?
>>
>> thanks
>>
>> On Mon, Jun 8, 2015 at 9:16 AM, Diego Turcios 
>> wrote:
>>>
>>> Hi Eduardo
>>> That sounds cool!
>>> The event is the 7 & 8 of August. It takes places on San Pedro Sula. If
>>> your agenda is available we can talk more.
>>>
>>> Please let me know
>>>
>>>
>>> 2015-06-04 21:50 GMT-06:00 Eduardo Silva :
>>>>
>>>> Hi Stephen and Diego,
>>>>
>>>> Our work is basically data collection from a end-to-end point of view
>>>> with Open Source tools that we develop and distribute. It covers embedded
>>>> (openembedded/yocto) and common system applications, the project involved
>>>> are:
>>>>
>>>> 1. Fluentd / http://fluentd.org : open source data collector
>>>> 2. Fluent Bit / http://fluentbit.io : open source data collector with a
>>>> strong focus in Embedded Linux
>>>> 3. Monkey Server / http://monkey-project.com : a scalable web server for
>>>> embedded linux and others.
>>>> 4. Duda I/O / http://duda.io: a web services framework for Linux and
>>>> embedded Linux.
>>>>
>>>> note: all projects are licensed under the Apache v2 License
>>>>
>>>> we have international experience, at the moment (in 1 hour) I will be
>>>> presenting at LinuxCon Japan:
>>>>
>>>>   http://sched.co/2mgz
>>>>
>>>> We can cover the travel costs, If you like the proposal I will only need
>>>> to re-check my schedule to validate availability. Please let me know if 
>>>> this
>>>> works.
>>>>
>>>> thanks for your time,
>>>>
>>>>
>>>>
>>>> On Thu, Jun 4, 2015 at 10:27 AM, Stephen Arnold
>>>>  wrote:
>>>>>
>>>>> That works if you have some travel
>>>>> coverage, unfortunately I just
>>>>> heard Diego is in the hospital (no details yet) so there may be a
>>>>> short delay in reply...
>>>>>
>>>>> They are very interested in open source (both hardware and software)
>>>>> so feel free to propose suitable topics (depends on what you've been
>>>>> working on recently I guess).  I was going to do Gentoo embedded but
>>>>> I'm not sure if I can even go yet...
>>>>>
>>>>> Steve
>>>>>
>>>>> On Tue, Jun 2, 2015 at 6:36 PM, Eduardo Silva 
>>>>> wrote:
>>>>> > HI Stephen,
>>>>> >
>>>>> > I just read on the OpenEmbedded List that you are looking for
>>>>> > candidates to
>>>>> > talk about Yocto or related technology.
>>>>> >
>>>>> > I work for the Open Source team at Treasure Data and we are a Linux
>>>>> > Foundation member. As I am based in Costa Rica I see a good chance to
>>>>> > participate.
>>>>> >
>>>>> &

Re: [OE-core] [oe] Fwd: open source conference in Honduras needs Yocto Project/Openembedded/OpenHardware speaker

[Stephen Arnold]

I can't (formally) speak for Diego, but that sounds awesome (I think
he will be happy).  The LinuxCon abstract looks promising, but I
better shutup and let DIego respond when's able to.

Thanks, and you're entirely welcome (and hopefully I can see it in person...)

Steve

On Thu, Jun 4, 2015 at 8:50 PM, Eduardo Silva  wrote:
> Hi Stephen and Diego,
>
> Our work is basically data collection from a end-to-end point of view with
> Open Source tools that we develop and distribute. It covers embedded
> (openembedded/yocto) and common system applications, the project involved
> are:
>
> 1. Fluentd / http://fluentd.org : open source data collector
> 2. Fluent Bit / http://fluentbit.io : open source data collector with a
> strong focus in Embedded Linux
> 3. Monkey Server / http://monkey-project.com : a scalable web server for
> embedded linux and others.
> 4. Duda I/O / http://duda.io: a web services framework for Linux and
> embedded Linux.
>
> note: all projects are licensed under the Apache v2 License
>
> we have international experience, at the moment (in 1 hour) I will be
> presenting at LinuxCon Japan:
>
>   http://sched.co/2mgz
>
> We can cover the travel costs, If you like the proposal I will only need to
> re-check my schedule to validate availability. Please let me know if this
> works.
>
> thanks for your time,
>
>
>
> On Thu, Jun 4, 2015 at 10:27 AM, Stephen Arnold 
> wrote:
>>
>> That works if you have some travel
>> coverage, unfortunately I just
>> heard Diego is in the hospital (no details yet) so there may be a
>> short delay in reply...
>>
>> They are very interested in open source (both hardware and software)
>> so feel free to propose suitable topics (depends on what you've been
>> working on recently I guess).  I was going to do Gentoo embedded but
>> I'm not sure if I can even go yet...
>>
>> Steve
>>
>> On Tue, Jun 2, 2015 at 6:36 PM, Eduardo Silva  wrote:
>> > HI Stephen,
>> >
>> > I just read on the OpenEmbedded List that you are looking for candidates
>> > to
>> > talk about Yocto or related technology.
>> >
>> > I work for the Open Source team at Treasure Data and we are a Linux
>> > Foundation member. As I am based in Costa Rica I see a good chance to
>> > participate.
>> >
>> > If you are interested let me know so we can discuss more in detail,
>> >
>> > thanks in advance,
>> >
>> >
>> > On Tue, Jun 2, 2015 at 4:59 PM, Philip Balister 
>> > wrote:
>> >>
>> >> Speaking opportunity in Honduras.
>> >>
>> >> Contact Steve, not me.
>> >>
>> >> Philip
>> >>
>> >>
>> >>  Forwarded Message 
>> >> Subject: [OE-core] open source conference in Honduras needs Yocto
>> >> Project/Openembedded/OpenHardware speaker
>> >> Date: Tue, 2 Jun 2015 14:45:22 -0700
>> >> From: Stephen Arnold 
>> >> To: Patches and discussions about the oe-core layer
>> >> 
>> >>
>> >> There seems to be plenty of room (only 2 or 3 speakers signed up so
>> >> far) and they'd love to have an "official" LF (or just embedded linux)
>> >> speaker.  I've been invited to speak, and they can cover the normal
>> >> fees/lodging/food for speakers (just not the travel costs, so I'm
>> >> still working things out with my wife...)
>> >>
>> >> http://ecsl2015.softwarelibre.ca/
>> >>
>> >> I guess I was hoping Linux Foundation (or member companies) had enough
>> >> support to maybe send an openembedded developer to speak as an
>> >> outreach sort of thing.
>> >>
>> >> Steve Arnold
>> >> aka nerdboy/mr_science
>> >> --
>> >> ___
>> >> Openembedded-core mailing list
>> >> Openembedded-core@lists.openembedded.org
>> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> ___
>> >> Openembedded-devel mailing list
>> >> openembedded-de...@lists.openembedded.org
>> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>> >
>> >
>> >
>> >
>> > --
>> > Eduardo Silva
>> >
>
>
>
>
> --
> Eduardo Silva
> Monkey Software
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] Fwd: open source conference in Honduras needs Yocto Project/Openembedded/OpenHardware speaker

[Stephen Arnold]

That works if you have some travel
coverage, unfortunately I just
heard Diego is in the hospital (no details yet) so there may be a
short delay in reply...

They are very interested in open source (both hardware and software)
so feel free to propose suitable topics (depends on what you've been
working on recently I guess).  I was going to do Gentoo embedded but
I'm not sure if I can even go yet...

Steve

On Tue, Jun 2, 2015 at 6:36 PM, Eduardo Silva  wrote:
> HI Stephen,
>
> I just read on the OpenEmbedded List that you are looking for candidates to
> talk about Yocto or related technology.
>
> I work for the Open Source team at Treasure Data and we are a Linux
> Foundation member. As I am based in Costa Rica I see a good chance to
> participate.
>
> If you are interested let me know so we can discuss more in detail,
>
> thanks in advance,
>
>
> On Tue, Jun 2, 2015 at 4:59 PM, Philip Balister  wrote:
>>
>> Speaking opportunity in Honduras.
>>
>> Contact Steve, not me.
>>
>> Philip
>>
>>
>>  Forwarded Message 
>> Subject: [OE-core] open source conference in Honduras needs Yocto
>> Project/Openembedded/OpenHardware speaker
>> Date: Tue, 2 Jun 2015 14:45:22 -0700
>> From: Stephen Arnold 
>> To: Patches and discussions about the oe-core layer
>> 
>>
>> There seems to be plenty of room (only 2 or 3 speakers signed up so
>> far) and they'd love to have an "official" LF (or just embedded linux)
>> speaker.  I've been invited to speak, and they can cover the normal
>> fees/lodging/food for speakers (just not the travel costs, so I'm
>> still working things out with my wife...)
>>
>> http://ecsl2015.softwarelibre.ca/
>>
>> I guess I was hoping Linux Foundation (or member companies) had enough
>> support to maybe send an openembedded developer to speak as an
>> outreach sort of thing.
>>
>> Steve Arnold
>> aka nerdboy/mr_science
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>>
>>
>> --
>> ___
>> Openembedded-devel mailing list
>> openembedded-de...@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
>
>
>
> --
> Eduardo Silva
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] open source conference in Honduras needs Yocto Project/Openembedded/OpenHardware speaker

[Stephen Arnold]

There seems to be plenty of room (only 2 or 3 speakers signed up so
far) and they'd love to have an "official" LF (or just embedded linux)
speaker.  I've been invited to speak, and they can cover the normal
fees/lodging/food for speakers (just not the travel costs, so I'm
still working things out with my wife...)

http://ecsl2015.softwarelibre.ca/

I guess I was hoping Linux Foundation (or member companies) had enough
support to maybe send an openembedded developer to speak as an
outreach sort of thing.

Steve Arnold
aka nerdboy/mr_science
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] on current linux distros, what are potential candidates for ASSUME_PROVIDED?

[Stephen Arnold]

I would agree that for classroom purposes, some of the best time savers are
things like pre-fetching downloads to a local machine, pre-cloning kernel
repos, and shared cache.

Also, IIRC several of the course lab examples (in the LF Yocto course)
didn't quite work as expected (mostly kernel variables for some reason).  I
would probably recommend keeping things simple, as in teaching the config
fragment approach (as is done in the kernel lab training thing).  Can't
remember what the all the issues were exactly as I normally build off
master which gives me recurring deja vu, but keeping course materials
current is always an ongoing issue for me...

Just my $.02 ...

Steve

On Wed, Feb 25, 2015 at 12:41 AM, Robert P. J. Day 
wrote:

> On Wed, 25 Feb 2015, Richard Purdie wrote:
>
> > On Wed, 2015-02-25 at 03:25 -0500, Robert P. J. Day wrote:
> > >   for the sake of reducing build time in the classroom, what are some
> > > of the potential (and relatively safe) candidates to add to
> > > ASSUME_PROVIDED for a build from scratch?
> >
> > This path is fraught with danger to be honest. There are some things
> > which are "safe" like subversion and git but they don't make that much
> > difference to a build and there are not as many as you'd think.
> >
> > The biggest difference you can make is an sstate cache you share amongst
> > the pupils. The time is spent:
> >
> > a) building gcc
> > b) building libc
> > c) building gettext
> > d) building glib
> >
> > each of these is a bottle neck which then opens up a new set of targets
> > as none of them are ASSUME_PROVIDED material.
>
>   ok, fair enough.
>
> 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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] How to force patch application

[Stephen Arnold]

Yes, what I said previously:

1) disable current patch: add ";patch=0" to the end of the patch line in
SRC_URI
2a) add your patch to SRC_URI (if different than patch above)
2b) make your own do_patch() to apply the patch
2c) try this example for a way to supplement do_patch with your own
function:
meta-openembedded/meta-networking/recipes-support/netcat/
netcat-openbsd_1.105.bb
3) test it

Steve


On Thu, Aug 7, 2014 at 7:51 AM, Giuseppe Condorelli <
giuseppe.condore...@gmail.com> wrote:

> Hi Steve,
>
> thanks for the reply.
>
> The problem is that I need to force a patch application (like patch
> --force option) at my own risk.
> Do you see any solution?
> Giuseppe
>
>
> 2014-08-07 16:43 GMT+02:00 Stephen Arnold :
>
> Not sure if there's an easy way with quilt (check the quilt options) but a
>> relatively easy way would be to use your own patch routine (essentially
>> anything you want).  One thing you could do is disable the normal patch
>> application (add ";patch=0" to the end of the patch line in SRC_URI) and
>> then use your own do_patch to force it (if that's really what you want to
>> do).  I guess I would ask "why?" and if it were me I'd just reroll the
>> patch and fix it.  But I don't know what the real problem is, so...
>>
>> Steve
>>
>>
>>
>> On Thu, Aug 7, 2014 at 6:14 AM, Giuseppe Condorelli <
>> giuseppe.condore...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> please can I know if is it possible, using the do_patch routine,
>>> to force the application of a given patch?
>>> I mean, like the patch --force command.
>>>
>>> Please let me know, I tried w/o good result.
>>>
>>> Best Regards,
>>> Giuseppe
>>>
>>> --
>>> ___
>>> 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
>>
>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] How to force patch application

[Stephen Arnold]

Not sure if there's an easy way with quilt (check the quilt options) but a
relatively easy way would be to use your own patch routine (essentially
anything you want).  One thing you could do is disable the normal patch
application (add ";patch=0" to the end of the patch line in SRC_URI) and
then use your own do_patch to force it (if that's really what you want to
do).  I guess I would ask "why?" and if it were me I'd just reroll the
patch and fix it.  But I don't know what the real problem is, so...

Steve



On Thu, Aug 7, 2014 at 6:14 AM, Giuseppe Condorelli <
giuseppe.condore...@gmail.com> wrote:

> Hi All,
>
> please can I know if is it possible, using the do_patch routine,
> to force the application of a given patch?
> I mean, like the patch --force command.
>
> Please let me know, I tried w/o good result.
>
> Best Regards,
> Giuseppe
>
> --
> ___
> 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] libgcrypt workaround

[Stephen Arnold]

Yeah, I kinda suspected pkgconfig but I guess I was busy/distracted with
the biz stuff and didn't dig any deeper than the one recipe...  Sounds like
this patch won't be needed if the pc stuff is clean.

Steve


On Thu, Jul 17, 2014 at 10:34 AM, Tim Orling  wrote:

> Steve,
>
> That workaround fixes the problem, but I think there is something
> fundamentally wrong deeper in. Looks like the culprit is pkgconfig.patch
> for libgpg-error. Testing and will send patch.
>
>
> On Wed, Jul 16, 2014 at 6:47 PM, Stephen Arnold <
> stephen.arnol...@gmail.com> wrote:
>
>> OE-devs/Tim:
>>
>> Here's the basic recipe patch; not sure if I should submit it formally or
>> not.  Maybe a configure patch is preferred?  Feedback welcome.
>>
>> Thanks, Steve
>>
>> --
>> ___
>> 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] libgcrypt workaround

[Stephen Arnold]

OE-devs/Tim:

Here's the basic recipe patch; not sure if I should submit it formally or
not.  Maybe a configure patch is preferred?  Feedback welcome.

Thanks, Steve
diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc b/meta/recipes-support/libgcrypt/libgcrypt.inc
index bba4a79..bd4eedd 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt.inc
+++ b/meta/recipes-support/libgcrypt/libgcrypt.inc
@@ -22,11 +22,17 @@ inherit autotools-brokensep texinfo binconfig-disabled pkgconfig
 
 ASFLAGS="--divide"
 CPPFLAGS_append = " -DPIC -fPIC"
+
 EXTRA_OECONF = "--without-capabilities --disable-padlock-support"
 
 do_configure_prepend () {
 	# Else these could be used in prefernce to those in aclocal-copy
 	rm -f ${S}/m4/*.m4
+	export GPG_ERROR_LIBS="-L${STAGING_LIBDIR} -lgpg-error "
+}
+
+do_configure_prepend_class-native() {
+	export GPG_ERROR_LIBS="-L${STAGING_LIBDIR_NATIVE} -lgpg-error "
 }
 
 # libgcrypt.pc is added locally and thus installed here
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Creating a machine specific recipe for config file

[Stephen Arnold]

Actually, that's not bad either.  As long as the magic is documented, that
sounds pretty good too.

Steve



On Tue, May 27, 2014 at 1:44 PM, Christopher Larson wrote:

>
> On Tue, May 27, 2014 at 1:39 PM, Darren Hart wrote:
>
>> On 5/27/14, 11:35, "Saul Wold"  wrote:
>>
>> >
>> >Folks,
>> >
>> >We have had an open enhancement in the form of bugzilla #4011
>> >(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4011).
>> >
>> >I am currently working on this and want to get some feedback regarding
>> >the design, the below list of config files would move to one recipe in
>> >recipes-bsp, which will reduce the number of .bbappends that a BSP
>> >writer might need to create in order to customize the configuration of
>> >the BSP.
>> >
>> >Overall, my proposal is to move all the BSP related config files into
>> >one recipe directory tree. Create a recipe that can have a package or
>> >packages that are RRECOMMENDS on.
>> >
>> >We have 2 choices on the packaging side:
>> >
>> >1) 1 Package to rule them all (conffiles)
>> >   - RPROVIDES PN-conf
>> >   - conffile.bbclass
>> >   RRECOMMENDS = "${PN}-conf"
>> >   # Can be overriden in recipe
>> >   CONFFILES_conffiles ?= "${PN}.conf"
>> >   - Will provide files not needed on final image, small
>> > amount of extra space used.
>> >
>> >2) 1 package / conf file (${PN}-conf)
>> >   - exactly what's needed will be installed
>> >   - no needs for additional RPROVIDES
>> >   - More packaging overhead, package data might be bigger than actual
>> >contents!
>>
>> The status quo would suggest that Option 2 is more consistent with what
>> people expect of the build system. However, if we were to do this, one
>> might question why we should bother at all and not just leave it in the
>> hands of MACHINE-specific overrides for the packages we're configuring, as
>> is done today with alsa-state/asound.conf (for example).
>>
>> What was your idea here - to replace the MACHINE-specific config for these
>> packages - or to augment it with an optional mega-config package?
>>
>> I think it would help to provide a bit of background/motivation regarding
>> what exactly we're trying to accomplish with this. That would help me form
>> an opinion on 1 vs 2 anyway.
>
>
> A third option would be to create a class which examines a path or paths
> to a directory structure containing just the config files, and injects a
> custom function into PACKAGEFUNCS which overlays the bsp-specific default
> configs into the original packages, obeying BBPATH to reflect layer
> priorities. It'd essentially be the same as what's done today, just a
> possibly more convenient way to do it, from a BSP maintainer perspective,
> and wouldn't even be terribly complex, but it might be seen as too much
> magic :)
> --
> 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
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Creating a machine specific recipe for config file

[Stephen Arnold]

Package management overhead seems like a small-ish price for being able to
manage/coordinate custom configs with real depends.  Did I mention I like
2) better?

Steve


On Tue, May 27, 2014 at 11:35 AM, Saul Wold  wrote:

>
> Folks,
>
> We have had an open enhancement in the form of bugzilla #4011 (
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4011).
>
> I am currently working on this and want to get some feedback regarding the
> design, the below list of config files would move to one recipe in
> recipes-bsp, which will reduce the number of .bbappends that a BSP writer
> might need to create in order to customize the configuration of the BSP.
>
> Overall, my proposal is to move all the BSP related config files into one
> recipe directory tree. Create a recipe that can have a package or packages
> that are RRECOMMENDS on.
>
> We have 2 choices on the packaging side:
>
> 1) 1 Package to rule them all (conffiles)
>   - RPROVIDES PN-conf
>   - conffile.bbclass
>   RRECOMMENDS = "${PN}-conf"
>   # Can be overriden in recipe
>   CONFFILES_conffiles ?= "${PN}.conf"
>   - Will provide files not needed on final image, small
> amount of extra space used.
>
> 2) 1 package / conf file (${PN}-conf)
>   - exactly what's needed will be installed
>   - no needs for additional RPROVIDES
>   - More packaging overhead, package data might be bigger than actual
> contents!
>
> Currently the list of recipes/config files affected include:
>
>
> meta/recipes-bsp/pointercal/pointercal/*/pointercal
> meta/recipes-bsp/formfactor/files/*/machconfig
> meta/recipes-bsp/alsa-state/alsa-state/asound.conf
> meta/recipes-graphics/xorg-xserver/xserver-xf86-config/*/xorg.conf
> meta/recipes-bsp/keymaps/files/keymap.sh
> meta/recipes-graphics/xinput-calibrator/pointercal-xinput/
> pointercal.xinput
> meta/recipes-graphics/tslib/tslib/ts.conf
>
>
> Possibly also:
> meta/recipes-core/init-ifupdown/init-ifupdown-1.0
> meta/recipes-connectivity/connman/connman-conf
> meta/recipes-connectivity/bluez5/bluez5/bluetooth.conf
> meta/recipes-bsp/apmd/apmd-3.2.2-14/apmd_proxy.conf
>
> Comment, thoughts, ...
>
> Thanks
> --
> Sau!
>
> Saul Wold
> Yocto Component Wrangler @ Intel
> Yocto Project / Poky Build System
>
> --
> ___
> 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] OEDAM: OpenEmbedded Developers (Americas) Meeting

[Stephen Arnold]

And a special thanks to everyone for letting the Gentoo dev crash the
meeting.  The meeting *was* fun and educational (especially for me).  So
far both the community and technology have been a lot of fun getting custom
builds for various machines, as well as educational (is there an echo in
here? ;)

Thanks again, Steve  (aka mr_science)


On Mon, May 12, 2014 at 4:19 PM, Jeff Osier-Mixon  wrote:

> Meeting notes have been published on the OEDAM page:
>
> http://openembedded.org/wiki/OEDAM#Minutes
>
> Jefro takes the blame for typos and other reporting errors.
>
> On Wed, May 7, 2014 at 4:18 PM, Denys Dmytriyenko  wrote:
> > The OpenEmbedded Board of Directors would like to thank everyone who was
> able
> > to participate (either in person in Santa Clara or online) in our first
> OEDAM
> > OpenEmbedded Developers (Americas) Meeting on May 2nd and 3rd! The
> meeting was
> > a huge success and a lot of fun!
> >
> > We would also like to thank Ettus Research/NI for providing the
> premises, as
> > well as Jefro and the Yocto Project for sponsoring the event and
> providing
> > food!
> >
> > The meeting minutes should be published shortly.
> >
> > --
> > Denys
> >
> >
> > On Thu, Feb 20, 2014 at 07:03:24PM -0500, Philip Balister wrote:
> >> The OpenEmbedded Project is holding a developers meeting May 2-3,
> >> 2014, in Santa Clara, CA. This meeting is immediately after the Embedded
> >> Linux Conference North America. All active OpenEmbedded and Yocto
> >> Project developers are invited to attend.
> >>
> >> NOTE: this is a development meeting for the project itself, not a
> >> training session.
> >>
> >> May 2-3, 2014
> >> time TBD
> >>
> >> Ettus Research/National Instruments
> >> 4600 Patrick Henry Drive
> >> Santa Clara, CA 95054 USA
> >>
> >> Lunch will be provided on both days.
> >>
> >> For more information and to add yourself to the list of attendees, see
> >> the wiki page at
> >> http://openembedded.org/wiki/OEDAM
> >>
> >> Here are a couple of photos from 2009:
> >>
> >> http://www.flickr.com/photos/32615155@N00/sets/72157622653686647/
> >>
> >> I'd like to thank Jefro for help with this announcement. Any errors are
> >> mine though.
> >>
> >> Philip, OpenEmbedded eV Chair.
> >> ___
> >> 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
>
>
>
> --
> Jeff Osier-Mixon @Intel
> Yocto Project Community Manager http://yoctoproject.org
> --
> ___
> 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] Open Hardware Summit

[Stephen Arnold]

Howdy:

Just wondering if this has ever come across the official Yocto/OE radar
before.  The CfP includes software, which sounds like OpenEmbedded to me.
Submissions are due by 25th of May 2014:

http://2014.oshwa.org/participate/

Wish I would have found it sooner, but I can help write something up if
there's any interest.  And yes, I've had plenty of abstracts actually
accepted, believe it or not...

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