Re: [oe] OE/Yocto developer survey

[Christian Ege]

> Hi,
>
> I'd like to get some feedback on the following questions -- feel free
> to respond to list, or directly to me, and I'll withhold your
> name/company from any results.
>
> I would like to collect feedback until 2015-11-02, and will summarize
> the results after that.
>
> My goal with this survey is to get a sense for best practices and what
> is most commonly used among Yocto/OE developers so I can better advise
> clients using Yocto/OE.  Hopefully this will also generate some
> interesting discussions.
>
> How long have you been using OE?  __3 years___
>
> How do you use OE/Yocto?
> [X] product development
> [X] hobby/research/education/yocto core developer, etc
>
> What distro do you use?
> [X] Poky
> [  ] Angstrom
> [X] nodistro or custom
>
> How do you organize multiple git repos?
> [X] Git submodules
> [  ] Repo
> [X] Other
>
> What packaging system?
> [X] OPKG
> [  ] RPM
> [  ] Other
>
> What GUI toolkits?
> [X] Qt
> [  ] Gtk
> [  ] EFL
> [  ] HTML5/JS
> [  ] Other
>
> What init system?
> [X] systemd
> [X] sysvinit
> [  ] busybox init
> [  ] Other
>
> What libc?
> [X] glibc
> [  ] uclibc
> [  ] musl
> [  ] Other
>
> How do you develop custom applications?
> [  ] application-SDK
> [  ] devshell
> [  ] develop on PC, test on target
> [X] bitbake  -c populate_sdk
>
> What language do you primarily use for custom applications?
> [X] C
> [X] C++
> [  ] Python
> [  ] Javascript
> [X] Lua
> [  ] Other
>
> What do you use for Continuous Integration?
> [  ] Buildbot
> [X] Jenkins
> [  ] Other
>
> Do you use any any of the tooling projects
> (https://www.yoctoproject.org/tools-resources/projects) such as ADT,
> Hob, Toaster, etc?
>
> __NONE_
>
> Reasons or explanations are appreciated, and please feel free to
> include additional choices/information you think are relevant.
>
> Thanks,
> Cliff
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel



-- 
http://ch.ege.io/
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH v3] gerbil: Visualization and analysis tool for hyperspectral images

[Ricardo Ribalda Delgado]

New recipe

Signed-off-by: Ricardo Ribalda Delgado 
---

v3: So I think we have got into the root of why it failed.

There was a capitalization error on the cmake file.

I have posted the change to upstream and they have merged it
(btw extremely fast, thanks ypnos).

Hope this time it also builds on on your test system.

Sorry again for the inconveniences, and thanks for your work!

 meta-oe/recipes-graphics/gerbil/gerbil_git.bb | 30 +++
 1 file changed, 30 insertions(+)
 create mode 100644 meta-oe/recipes-graphics/gerbil/gerbil_git.bb

diff --git a/meta-oe/recipes-graphics/gerbil/gerbil_git.bb 
b/meta-oe/recipes-graphics/gerbil/gerbil_git.bb
new file mode 100644
index ..cad67d01c724
--- /dev/null
+++ b/meta-oe/recipes-graphics/gerbil/gerbil_git.bb
@@ -0,0 +1,30 @@
+DESCRIPTION = "Generic framework for visualization and analysis of 
multispectral and hyperspectral data that strives to both bring new innovations 
in analysis capabilities and be of use in a wide range of hyperspectral data 
applications"
+HOMEPAGE = "http://gerbilvis.org/;
+LICENSE = "GPLv3"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=d32239bcb673463ab874e80d47fae504"
+DEPENDS = "boost qt4-x11-free tbb opencv libglu virtual/libgl"
+SRCREV = "b5cc1dc05b89c6c0d5190f0a49a18a77526fffa9"
+
+SRC_URI = "git://github.com/gerbilvis/gerbil.git"
+
+S = "${WORKDIR}/git"
+
+inherit distutils-base cmake qt4x11
+
+export EXTRA_OECMAKE = "\
+-DQT_MOC_EXECUTABLE=${OE_QMAKE_MOC} \
+-DQT_UIC_EXECUTABLE=${OE_QMAKE_UIC} \
+-DQT_RCC_EXECUTABLE=${OE_QMAKE_RCC} \
+"
+
+do_configure() {
+# Ensure we get the cmake configure and not qmake
+cmake_do_configure
+}
+do_install() {
+install -d ${D}${bindir}
+install -m 755 bin/gerbil ${D}${bindir}/
+install -m 755 bin/qgerbil ${D}${bindir}/
+}
+
+RDEPENDS_${PN} += "qt4-x11-free"
-- 
2.6.1

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

Re: [oe] OE/Yocto developer survey

[Marc Reilly]

Hi Cliff,

On Monday, October 26, 2015 03:18:54 PM Cliff Brake wrote:
> Hi,
> 
> I'd like to get some feedback on the following questions -- feel free
> to respond to list, or directly to me, and I'll withhold your
> name/company from any results.
> 
> I would like to collect feedback until 2015-11-02, and will summarize
> the results after that.
> 
> My goal with this survey is to get a sense for best practices and what
> is most commonly used among Yocto/OE developers so I can better advise
> clients using Yocto/OE.  Hopefully this will also generate some
> interesting discussions.
> 
> How long have you been using OE?  _3 years
> 
> How do you use OE/Yocto?
> [ x] product development
> [  ] hobby/research/education/yocto core developer, etc
> 
> What distro do you use?
> [  ] Poky
> [x ] Angstrom
> [x ] nodistro or custom
> 
> How do you organize multiple git repos?
> [  ] Git submodules
> [  ] Repo
> [x ] Other
> 
> What packaging system?
> [ x ] OPKG
> [  ] RPM
> [  ] Other
> 
> What GUI toolkits?
> [ x ] Qt
> [  ] Gtk
> [  ] EFL
> [  ] HTML5/JS
> [  ] Other
> 
> What init system?
> [ x ] systemd
> [  ] sysvinit
> [  ] busybox init
> [  ] Other
> 
> What libc?
> [ x ] glibc
> [  ] uclibc
> [  ] musl
> [  ] Other
> 
> How do you develop custom applications?
> [ x ] application-SDK
> [  ] devshell
> [x  ] develop on PC, test on target
> [  ] Other
> 
> What language do you primarily use for custom applications?
> [  ] C
> [ x ] C++
> [  ] Python
> [  ] Javascript
> [  ] Lua
> [  ] Other
> 
> What do you use for Continuous Integration?
> [  ] Buildbot
> [ x ] Jenkins
> [  ] Other
> 
> Do you use any any of the tooling projects
> (https://www.yoctoproject.org/tools-resources/projects) such as ADT,
> Hob, Toaster, etc?
> 
> ___

None.

We've not modified our initial product image for a few years now, apart from 
our specific app, so I haven't had any time to play with these newer tools.


HTH,

Cheers,
Marc

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

Re: [oe] [yocto] OE/Yocto developer survey

[Alex J Lennon]

On 26/10/2015 19:18, Cliff Brake wrote:
> Hi,
>
> I'd like to get some feedback on the following questions -- feel free
> to respond to list, or directly to me, and I'll withhold your
> name/company from any results.
>
> I would like to collect feedback until 2015-11-02, and will summarize
> the results after that.
>
> My goal with this survey is to get a sense for best practices and what
> is most commonly used among Yocto/OE developers so I can better advise
> clients using Yocto/OE.  Hopefully this will also generate some
> interesting discussions.
>
> How long have you been using OE?  _
>
> How do you use OE/Yocto?
> [X ] product development
> [X ] hobby/research/education/yocto core developer, etc
>
> What distro do you use?
> [X ] Poky
> [  ] Angstrom
> [  ] nodistro or custom
>
> How do you organize multiple git repos?
> [  ] Git submodules
> [  ] Repo
> [X ] Other
>
> What packaging system?
> [  ] OPKG
> [X ] RPM
> [X ] Other
>
> What GUI toolkits?
> [  ] Qt
> [  ] Gtk
> [  ] EFL
> [X ] HTML5/JS
> [X ] Other
>
> What init system?
> [  ] systemd
> [X ] sysvinit
> [  ] busybox init
> [  ] Other
>
> What libc?
> [X ] glibc
> [  ] uclibc
> [  ] musl
> [  ] Other
>
> How do you develop custom applications?
> [  ] application-SDK
> [X ] devshell
> [X ] develop on PC, test on target
> [X ] Other
>
> What language do you primarily use for custom applications?
> [X ] C
> [  ] C++
> [  ] Python
> [  ] Javascript
> [  ] Lua
> [X ] Other
>

Visual Studio C# .NET + Mono

> What do you use for Continuous Integration?
> [  ] Buildbot
> [  ] Jenkins
> [X ] Other
>
> Do you use any any of the tooling projects
> (https://www.yoctoproject.org/tools-resources/projects) such as ADT,
> Hob, Toaster, etc?

No

> ___
>
> Reasons or explanations are appreciated, and please feel free to
> include additional choices/information you think are relevant.
>
> Thanks,
> Cliff

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

Re: [oe] [PATCH 1/1] snort: fix m4 causes out of memory during configure [ LIN8-299 ]

[Ioan-Adrian Ratiu]

On Tue, 27 Oct 2015 09:54:07 +
"Li, Zhiquan"  wrote:

> I need to evaluate the possibility to upgrade the snort recipe to >2.9.7, 
> because upgrade to > 2.9.7, some patches will not work anymore and the daq 
> recipe also need to be upgraded to 2.0.4 at least. The side-effect is 
> uncertainty.
>

What exactly do you mean by "patches will not work anymore"?.
Do you mean thy do not apply on >2.9.7? AFAIK two of those
patches are not needed in 2.9.7.6 (fixed upstream), the others
just need refreshing.
 
> From: Ioan-Adrian Ratiu [adrian.ra...@ni.com]
> Sent: Monday, October 26, 2015 6:49 PM
> To: Li, Zhiquan
> Cc: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCH 1/1] snort: fix m4 causes out of memory during 
> configure [ LIN8-299 ]
> 
> On Fri, 23 Oct 2015 18:07:35 +0800
> Zhiquan Li  wrote:
> 
> > Issue: LIN8-299
> >
> > There is an incorrect m4_define() in configure.in which will result in an
> > infinite recursion, and it doesn't make sense, since snort 2.9.7 it has been
> > commented out. We follow this solution to fix it.
> >
> > Upstream-Status: Backport
> >
> > (LOCAL REV: NOT UPSTREAM) -- Sent to oe-devel on 20151023
> >
> > Signed-off-by: Zhiquan Li 
> > ---
> >  .../snort/snort/m4-oom-during-configure.patch   | 21 
> > +
> >  .../recipes-connectivity/snort/snort_2.9.6.0.bb | 16 +++-
> >  2 files changed, 24 insertions(+), 13 deletions(-)
> >  create mode 100644 
> > meta-networking/recipes-connectivity/snort/snort/m4-oom-during-configure.patch
> >
> > diff --git 
> > a/meta-networking/recipes-connectivity/snort/snort/m4-oom-during-configure.patch
> >  
> > b/meta-networking/recipes-connectivity/snort/snort/m4-oom-during-configure.patch
> > new file mode 100644
> > index 000..2250611
> > --- /dev/null
> > +++ 
> > b/meta-networking/recipes-connectivity/snort/snort/m4-oom-during-configure.patch
> > @@ -0,0 +1,21 @@
> > +Upstream-Status: Backport
> > +
> > +There is an incorrect m4_define() in configure.in which will result in an
> > +infinite recursion, and it doesn't make sense, since snort 2.9.7 it has 
> > been
> > +commented out. We follow this solution to fix it.
> > +
> 
> Doesn't it make more sense to upgrade the snort recipe to >2.9.7 than
> backporting this fix?
> 
> > +Signed-off-by: Zhiquan Li 
> > +
> > +--- a/configure.in   2015-10-22 13:58:50.743367251 +0800
> >  b/configure.in   2015-10-22 13:59:13.855366117 +0800
> > +@@ -1100,8 +1100,8 @@
> > + # Define PKG_CHECK_MODULES if it doesnt already exist.
> > + #file_ This prevents './configure' from erroring on machines that dont 
> > have
> > + # 'pkgconfig' installed.
> > +-m4_ifdef([PKG_CHECK_MODULES],[], [m4_define([PKG_CHECK_MODULES],
> > +- [echo "PKG_CHECK_MODULES not defined"])])
> > ++#m4_ifdef([PKG_CHECK_MODULES],[], [m4_define([PKG_CHECK_MODULES],
> > ++# [echo "PKG_CHECK_MODULES not defined"])])
> > +
> > + if test "x$enable_rzb_saac" = "xyes"; then
> > + AC_CHECK_PROG(PKG_CONFIG,pkg-config,yes)
> > diff --git a/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb 
> > b/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb
> > index 66653c6..65dc524 100644
> > --- a/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb
> > +++ b/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb
> > @@ -6,19 +6,6 @@ LIC_FILES_CHKSUM = 
> > "file://COPYING;md5=78fa8ef966b48fbf9095e13cc92377c5"
> >
> >  DEPENDS = "libpcap libpcre daq libdnet util-linux"
> >
> > -# Blacklist:
> > -#
> > -# http://errors.yoctoproject.org/Errors/Details/8936/
> > -#
> > -# snort failure is again very nasty, because it's m4 which eats all
> > -# available memory and swap before it's killed by OOM killer.
> > -#
> > -# Luckily it always picked m4
> > -#
> > -# [Wed Feb 18 19:00:51 2015] Out of memory: Kill process 28522 (m4) score 
> > 961 or sacrifice child
> > -# [Wed Feb 18 19:10:51 2015] Out of memory: Kill process 45228 (m4) score 
> > 958 or sacrifice child
> > -# ...
> > -PNBLACKLIST[snort] ?= "BROKEN: autotools processing causes OOM condition 
> > on configure"
> >
> >  SRC_URI = " ${GENTOO_MIRROR}/${BP}.tar.gz;name=tarball \
> >  file://snort.init \
> > @@ -26,6 +13,7 @@ SRC_URI = " ${GENTOO_MIRROR}/${BP}.tar.gz;name=tarball \
> >  file://disable-dap-address-space-id.patch \
> >  file://0001-libpcap-search-sysroot-for-headers.patch \
> >  file://not-hardcoded-libdir.patch \
> > +file://m4-oom-during-configure.patch \
> >  "
> >
> >  SRC_URI[tarball.md5sum] = "18111f6de3989ca89add36077a7c2659"
> > @@ -45,6 +33,8 @@ EXTRA_OECONF = " \
> >   --disable-static-daq \
> >   --with-dnet-includes=${STAGING_INCDIR} \
> >   --with-dnet-libraries=${STAGING_LIBDIR} \
> > + --with-libpcre-includes=${STAGING_INCDIR} \
> > + 

Re: [oe] OE/Yocto developer survey

[Andrei Gherzan]

--
Andrei Gherzan


On Mon, Oct 26, 2015 at 8:18 PM, Cliff Brake  wrote:
> Hi,
>
> I'd like to get some feedback on the following questions -- feel free
> to respond to list, or directly to me, and I'll withhold your
> name/company from any results.
>
> I would like to collect feedback until 2015-11-02, and will summarize
> the results after that.
>
> My goal with this survey is to get a sense for best practices and what
> is most commonly used among Yocto/OE developers so I can better advise
> clients using Yocto/OE.  Hopefully this will also generate some
> interesting discussions.
>
> How long have you been using OE?  __4__
>
> How do you use OE/Yocto?
> [ X] product development
> [ X] hobby/research/education/yocto core developer, etc
>
> What distro do you use?
> [ X] Poky
> [  ] Angstrom
> [ X] nodistro or custom
>
> How do you organize multiple git repos?
> [  ] Git submodules
> [ X] Repo
> [  ] Other
>
> What packaging system?
> [  ] OPKG
> [ X] RPM
> [  ] Other
>
> What GUI toolkits?
> [ X] Qt
> [  ] Gtk
> [  ] EFL
> [  ] HTML5/JS
> [  ] Other
>
> What init system?
> [ X] systemd
> [ X] sysvinit
> [  ] busybox init
> [  ] Other
>
> What libc?
> [ X] glibc
> [  ] uclibc
> [  ] musl
> [  ] Other
>
> How do you develop custom applications?
> [  ] application-SDK
> [  ] devshell
> [ X] develop on PC, test on target
> [  ] Other
>
> What language do you primarily use for custom applications?
> [ X] C
> [  ] C++
> [ X] Python
> [  ] Javascript
> [  ] Lua
> [  ] Other
>
> What do you use for Continuous Integration?
> [  ] Buildbot
> [ X] Jenkins
> [  ] Other
>
> Do you use any any of the tooling projects
> (https://www.yoctoproject.org/tools-resources/projects) such as ADT,
> Hob, Toaster, etc?
>
> _no
>
> Reasons or explanations are appreciated, and please feel free to
> include additional choices/information you think are relevant.
>
> Thanks,
> Cliff
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] qtmultimedia + qt5.3.2 + yocto dizzy

[Stefano Gurrieri]

I also think that maybe some Gstreamer plugin missing.
But, having a look at my image recipe everything seems installed.
In attach, you can find my image recipe.
According to you, what missing?

Thanks a lot for your help.
Kind regards,
Stefano

2015-10-26 17:32 GMT+01:00 Stephano Cetola :

> On 10/23, Stefano Gurrieri wrote:
> > Hi Stephano,
> > thanks for your fast reply.
> >
> > I tried to follow this link, but without success.
> > Specifically, I tried to add:
> >
> > PACKAGECONFIG_append_pn-qtmultimedia= " gstreamer010" in my local.conf
> >
> > and I've added this part of code in qtmultimedia.inc recipe:
> >
> > do_configure_prepend() { # disable openal test if it isn't enabled by
> > PACKAGECONFIG sed -i 's/^qtCompileTest(openal)/OE_OPENAL_ENABLED:
> > qtCompileTest(openal)/g' ${S}/qtmultimedia.pro # disable gstreamer-0.10
> > test if it isn't enabled by PACKAGECONFIG sed -i 's/^\( *\)qtCompileTest(
> > gstreamer)/\1OE_GSTREAMER010_ENABLED:qtCompileTest(gstreamer) {/g' ${S}
> > /qtmultimedia.pro}
> > and removed patches:
> >
> > SRC_URI += "\
> > file://0001-Initial-porting-effort-to-GStreamer-1.0.patch \
> >
>  file://0002-qtmultimedia.pro-Respect-OE_GSTREAMER_ENABLED-OE_GST.patch \
> > "
> >
> > present in my original qtmultimedia.inc file.
> >
> > Then I bake my qt5-custom-image successfully. Now, on my target, in
> > /usr/lib/qt5/plugins/mediaservice, I see:
> > libgstaudiodecoder.so  libgstcamerabin.so  libgstmediacapture.so
> > libgstmediaplayer.so
> >
> > but when I try to run (for example) videowidget application or player
> > application, I see these error:
> >
> > GStreamer-CRITICAL **: gst_object_ref_sink: assertion 'G_IS_OBJECT
> > (object)' failed
>
> Hmmm, I have never seen this error. Sounds like some Gstreamer plugins
> may be missing.
>
> Have a look at this custom image:
>
> http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
>
> I have used that in the past to successfully test video. Perhaps there
> are some packages in that image that you are missing. Hope this helps.
>
>
> >
> >
> > Could you help me?
> > Thanks a lot.
> > Stefano
> >
> > 2015-10-22 22:47 GMT+02:00 Stephano Cetola :
> >
> > > Ciao Stefano,
> > >
> > > Take a look at this thread:
> > >
> > > https://community.freescale.com/message/391750#391750
> > >
> > > You are missing libgstmediaplayer.so. That link should help get you
> > > the right packages installed.
> > >
> > >
> > >
> > > On Thu, Oct 22, 2015 at 7:23 AM, Stefano Gurrieri
> > >  wrote:
> > > > Goodmorning,
> > > > I tried to compile Qt5.3.2 in my Yocto dizzy successfully etc…
> > > > … but when I try to run (on my target based on iMX6) a videowidget
> > > > application or player application… I always have the same error:
> > > > defaultServiceProvider::requestService(): no service found for -
> > > > "org.qt-project.qt.mediaplayer"
> > > > and I can’t to see a video. In /usr/lib/qt5/plugins/mediaservice I’ve
> > > only
> > > > libqtmedia_audioengine.so library. Missing gstreamer multimedia
> service
> > > > plugins?
> > > >
> > > > Could you please help me?
> > > >
> > > > Thanks a lot.
> > > > --
> > > > ___
> > > > Openembedded-devel mailing list
> > > > Openembedded-devel@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > > --
> > > ___
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > >
> > --
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
SYSTEMD_INSTALL = " \
systemd \
systemd-compat-units \
systemd-speed-hacks \
udev-systemd \
rsyslog-systemd \
"

SYSV_INSTALL = " \
udev \
sysvinit \
initscripts \
"

COMMON_INSTALL = " \
base-files \
base-passwd \
busybox \
${@base_contains("MACHINE_FEATURES", "systemd", "${SYSTEMD_INSTALL}", 
"${SYSV_INSTALL}", d)} \
packagegroup-fsl-gstreamer \
packagegroup-base \
"

IMAGE_FEATURES += "ssh-server-openssh splash "

do_rootfs[depends] += "virtual/kernel:do_populate_sysroot"

inherit core-image


qt5-custom-image.bb
Description: Binary data
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 1/1] snort: fix m4 causes out of memory during configure [ LIN8-299 ]

[Li, Zhiquan]

I need to evaluate the possibility to upgrade the snort recipe to >2.9.7, 
because upgrade to > 2.9.7, some patches will not work anymore and the daq 
recipe also need to be upgraded to 2.0.4 at least. The side-effect is 
uncertainty.

From: Ioan-Adrian Ratiu [adrian.ra...@ni.com]
Sent: Monday, October 26, 2015 6:49 PM
To: Li, Zhiquan
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] [PATCH 1/1] snort: fix m4 causes out of memory during 
configure [ LIN8-299 ]

On Fri, 23 Oct 2015 18:07:35 +0800
Zhiquan Li  wrote:

> Issue: LIN8-299
>
> There is an incorrect m4_define() in configure.in which will result in an
> infinite recursion, and it doesn't make sense, since snort 2.9.7 it has been
> commented out. We follow this solution to fix it.
>
> Upstream-Status: Backport
>
> (LOCAL REV: NOT UPSTREAM) -- Sent to oe-devel on 20151023
>
> Signed-off-by: Zhiquan Li 
> ---
>  .../snort/snort/m4-oom-during-configure.patch   | 21 
> +
>  .../recipes-connectivity/snort/snort_2.9.6.0.bb | 16 +++-
>  2 files changed, 24 insertions(+), 13 deletions(-)
>  create mode 100644 
> meta-networking/recipes-connectivity/snort/snort/m4-oom-during-configure.patch
>
> diff --git 
> a/meta-networking/recipes-connectivity/snort/snort/m4-oom-during-configure.patch
>  
> b/meta-networking/recipes-connectivity/snort/snort/m4-oom-during-configure.patch
> new file mode 100644
> index 000..2250611
> --- /dev/null
> +++ 
> b/meta-networking/recipes-connectivity/snort/snort/m4-oom-during-configure.patch
> @@ -0,0 +1,21 @@
> +Upstream-Status: Backport
> +
> +There is an incorrect m4_define() in configure.in which will result in an
> +infinite recursion, and it doesn't make sense, since snort 2.9.7 it has been
> +commented out. We follow this solution to fix it.
> +

Doesn't it make more sense to upgrade the snort recipe to >2.9.7 than
backporting this fix?

> +Signed-off-by: Zhiquan Li 
> +
> +--- a/configure.in   2015-10-22 13:58:50.743367251 +0800
>  b/configure.in   2015-10-22 13:59:13.855366117 +0800
> +@@ -1100,8 +1100,8 @@
> + # Define PKG_CHECK_MODULES if it doesnt already exist.
> + #file_ This prevents './configure' from erroring on machines that dont have
> + # 'pkgconfig' installed.
> +-m4_ifdef([PKG_CHECK_MODULES],[], [m4_define([PKG_CHECK_MODULES],
> +- [echo "PKG_CHECK_MODULES not defined"])])
> ++#m4_ifdef([PKG_CHECK_MODULES],[], [m4_define([PKG_CHECK_MODULES],
> ++# [echo "PKG_CHECK_MODULES not defined"])])
> +
> + if test "x$enable_rzb_saac" = "xyes"; then
> + AC_CHECK_PROG(PKG_CONFIG,pkg-config,yes)
> diff --git a/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb 
> b/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb
> index 66653c6..65dc524 100644
> --- a/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb
> +++ b/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb
> @@ -6,19 +6,6 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=78fa8ef966b48fbf9095e13cc92377c5"
>
>  DEPENDS = "libpcap libpcre daq libdnet util-linux"
>
> -# Blacklist:
> -#
> -# http://errors.yoctoproject.org/Errors/Details/8936/
> -#
> -# snort failure is again very nasty, because it's m4 which eats all
> -# available memory and swap before it's killed by OOM killer.
> -#
> -# Luckily it always picked m4
> -#
> -# [Wed Feb 18 19:00:51 2015] Out of memory: Kill process 28522 (m4) score 
> 961 or sacrifice child
> -# [Wed Feb 18 19:10:51 2015] Out of memory: Kill process 45228 (m4) score 
> 958 or sacrifice child
> -# ...
> -PNBLACKLIST[snort] ?= "BROKEN: autotools processing causes OOM condition on 
> configure"
>
>  SRC_URI = " ${GENTOO_MIRROR}/${BP}.tar.gz;name=tarball \
>  file://snort.init \
> @@ -26,6 +13,7 @@ SRC_URI = " ${GENTOO_MIRROR}/${BP}.tar.gz;name=tarball \
>  file://disable-dap-address-space-id.patch \
>  file://0001-libpcap-search-sysroot-for-headers.patch \
>  file://not-hardcoded-libdir.patch \
> +file://m4-oom-during-configure.patch \
>  "
>
>  SRC_URI[tarball.md5sum] = "18111f6de3989ca89add36077a7c2659"
> @@ -45,6 +33,8 @@ EXTRA_OECONF = " \
>   --disable-static-daq \
>   --with-dnet-includes=${STAGING_INCDIR} \
>   --with-dnet-libraries=${STAGING_LIBDIR} \
> + --with-libpcre-includes=${STAGING_INCDIR} \
> + --with-libpcre-libraries=${STAGING_INCDIR} \
>   "
>
>  # if you want to disable it, you need to patch configure.in first

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

[oe] [meta-qt5] qtbluetooth not building against bluez

[michael]

I'm using qtbluetooth (qtconnectivity_git.bb) and noticed that it builds 
some kind of empty dummy library.
I then tried building in verbose mode: "bitbake -v qtconnectivity" and 
got the following message in the log:
"Unsupported Bluetooth platform, will not build a working QtBluetooth 
library.

Either no Qt D-Bus found or no BlueZ headers."

My solution was to add
  EXTRA_QMAKEVARS_PRE += "CONFIG+=config_bluez"
to
  recipes-qt/qt5/qtconnectivity_git.bb

after that it worked as expected.
I'm unsure if it's the right thing to do though.

I'm working with yocto 1.8 fido but also checked the master branch which 
doesn't seem to have anything changed related to qtconnectivity.

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

Re: [oe] checking if a patch was approved

[Ivan Sergio Borgonovo]

On 10/27/2015 08:12 AM, Nicolas Dechesne wrote:

On Tue, Oct 27, 2015 at 12:12 AM, Ivan Sergio Borgonovo
 wrote:

I saw many patch passing by and I submitted a couple about
meta-toolchain-qt5.
I didn't see any message from Otavio or Martin "approving" a patches.

How can I check if it was approved other than pulling from the repo/checking
github?

Or if there is no place to check... consider this a ping ;)



all commits are published on
openembedded-comm...@lists.openembedded.org mailing list, and in


thanks, actually my commit was for meta-qt5.
But still I haven't seen any feedback on this mailing list to guess if 
the commit was actually approved or not.


I haven't seen any "approval" feedback even for other commits. Maybe 
because the patches submitted were coming from known developers and the 
assumption is that if there is no request to fix something the patches 
are going to be queued to be committed by default.


I'm really not asking for any special attention, I just would like to 
know what I've to expect and check if I did the right thing and if I've 
to do anything else to see my patch committed.


Martin Jansa actually noticed a first revision of my patch and gave some 
feedback to fix stuff and things have been fixed (hopefully) and I 
submitted a second release.


thanks

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

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

Re: [oe] checking if a patch was approved

[Otavio Salvador]

On Tue, Oct 27, 2015 at 8:40 AM, Ivan Sergio Borgonovo
 wrote:
> On 10/27/2015 08:12 AM, Nicolas Dechesne wrote:
>>
>> On Tue, Oct 27, 2015 at 12:12 AM, Ivan Sergio Borgonovo
>>  wrote:
>>>
>>> I saw many patch passing by and I submitted a couple about
>>> meta-toolchain-qt5.
>>> I didn't see any message from Otavio or Martin "approving" a patches.
>>>
>>> How can I check if it was approved other than pulling from the
>>> repo/checking
>>> github?
>>>
>>> Or if there is no place to check... consider this a ping ;)
>
>
>> all commits are published on
>> openembedded-comm...@lists.openembedded.org mailing list, and in
>
>
> thanks, actually my commit was for meta-qt5.
> But still I haven't seen any feedback on this mailing list to guess if the
> commit was actually approved or not.
>
> I haven't seen any "approval" feedback even for other commits. Maybe because
> the patches submitted were coming from known developers and the assumption
> is that if there is no request to fix something the patches are going to be
> queued to be committed by default.
>
> I'm really not asking for any special attention, I just would like to know
> what I've to expect and check if I did the right thing and if I've to do
> anything else to see my patch committed.
>
> Martin Jansa actually noticed a first revision of my patch and gave some
> feedback to fix stuff and things have been fixed (hopefully) and I submitted
> a second release.

This is indeed a common issue and there are different answers for it.

For the layers I am actively acting as commited (meta-fsl-*,
meta-java, meta-browser) I send the email when I do merges. For
meta-qt5 Martin merges the patches for test in the -next branches. If
it is inside it, it is a good chance of it being applied in next
merge, or feedback will be given.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] checking if a patch was approved

[Martin Jansa]

On Tue, Oct 27, 2015 at 11:37:36AM +, Paul Eggleton wrote:
> On Tuesday 27 October 2015 08:12:48 Nicolas Dechesne wrote:
> > On Tue, Oct 27, 2015 at 12:12 AM, Ivan Sergio Borgonovo
> >  wrote:
> > > I saw many patch passing by and I submitted a couple about
> > > meta-toolchain-qt5.
> > > I didn't see any message from Otavio or Martin "approving" a patches.
> > > 
> > > How can I check if it was approved other than pulling from the
> > > repo/checking github?
> > > 
> > > Or if there is no place to check... consider this a ping ;)
> > 
> > all commits are published on
> > openembedded-comm...@lists.openembedded.org mailing list, and in
> > general you see when it's pushed in master-next, then in master.. i
> > have a mail filter that checks my name there.. it's the poor man
> > solution.. but it works. Note that the email trigger has been broken
> > for 2 weeks.. but i suspect this is a temporary issue that should be
> > fixed..
> 
> FWIW there are a small number of us working on improving patchwork so that 
> we're able to rely upon the results it shows as being the outstanding patches 
> in the queue and potentially even send email notifications to submitters (opt-
> in). I'd also like to go a step further and trigger some automatic validation 
> on patches. At the moment we're trying to figure out if we're able to spend 
> the 
> time working on this in the next development cycle.

Paul: do you know what's wrong with git hooks triggering
openembedded-commits e-mails? Or maybe it's the ML itself, but there
was no e-mail in last month. I've pinged Michael on IRC twice (+CC here)

http://lists.openembedded.org/pipermail/openembedded-commits/2015-September/thread.html

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


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

Re: [oe] checking if a patch was approved

[Paul Eggleton]

On Tuesday 27 October 2015 13:00:16 Martin Jansa wrote:
> On Tue, Oct 27, 2015 at 11:37:36AM +, Paul Eggleton wrote:
> > On Tuesday 27 October 2015 08:12:48 Nicolas Dechesne wrote:
> > > On Tue, Oct 27, 2015 at 12:12 AM, Ivan Sergio Borgonovo
> > > 
> > >  wrote:
> > > > I saw many patch passing by and I submitted a couple about
> > > > meta-toolchain-qt5.
> > > > I didn't see any message from Otavio or Martin "approving" a patches.
> > > > 
> > > > How can I check if it was approved other than pulling from the
> > > > repo/checking github?
> > > > 
> > > > Or if there is no place to check... consider this a ping ;)
> > > 
> > > all commits are published on
> > > openembedded-comm...@lists.openembedded.org mailing list, and in
> > > general you see when it's pushed in master-next, then in master.. i
> > > have a mail filter that checks my name there.. it's the poor man
> > > solution.. but it works. Note that the email trigger has been broken
> > > for 2 weeks.. but i suspect this is a temporary issue that should be
> > > fixed..
> > 
> > FWIW there are a small number of us working on improving patchwork so that
> > we're able to rely upon the results it shows as being the outstanding
> > patches in the queue and potentially even send email notifications to
> > submitters (opt- in). I'd also like to go a step further and trigger some
> > automatic validation on patches. At the moment we're trying to figure out
> > if we're able to spend the time working on this in the next development
> > cycle.
> 
> Paul: do you know what's wrong with git hooks triggering
> openembedded-commits e-mails? Or maybe it's the ML itself, but there
> was no e-mail in last month. I've pinged Michael on IRC twice (+CC here)
> 
> http://lists.openembedded.org/pipermail/openembedded-commits/2015-September/
> thread.html

I don't, I'm afraid - I don't have access to that infrastructure. I hope 
Michael can shed some light.

Cheers,
Paul

-- 

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

Re: [oe] checking if a patch was approved

[Martin Jansa]

On Tue, Oct 27, 2015 at 11:40:58AM +0100, Ivan Sergio Borgonovo wrote:
> On 10/27/2015 08:12 AM, Nicolas Dechesne wrote:
> > On Tue, Oct 27, 2015 at 12:12 AM, Ivan Sergio Borgonovo
> >  wrote:
> >> I saw many patch passing by and I submitted a couple about
> >> meta-toolchain-qt5.
> >> I didn't see any message from Otavio or Martin "approving" a patches.
> >>
> >> How can I check if it was approved other than pulling from the 
> >> repo/checking
> >> github?
> >>
> >> Or if there is no place to check... consider this a ping ;)
> 
> > all commits are published on
> > openembedded-comm...@lists.openembedded.org mailing list, and in
> 
> thanks, actually my commit was for meta-qt5.
> But still I haven't seen any feedback on this mailing list to guess if 
> the commit was actually approved or not.
> 
> I haven't seen any "approval" feedback even for other commits. Maybe 
> because the patches submitted were coming from known developers and the 
> assumption is that if there is no request to fix something the patches 
> are going to be queued to be committed by default.
> 
> I'm really not asking for any special attention, I just would like to 
> know what I've to expect and check if I did the right thing and if I've 
> to do anything else to see my patch committed.

meta-oe and meta-qt5 patches are managed in Patchwork as described here:
http://www.openembedded.org/wiki/Patchwork

You can see the status here.

> Martin Jansa actually noticed a first revision of my patch and gave some 
> feedback to fix stuff and things have been fixed (hopefully) and I 
> submitted a second release.

I've noticed second revision as well, it's in master-next, but it
haven't finished even the automated jenkins build yet and because I
don't use qt5 SDK I was hoping that someone else will review them as
well. There are 2 formal issues, I've fixed commit message summary to
match our guidelines:
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

But both are also missing SOB line, please confirm that I can add your
SOB or resend both patches with SOB (and commit message from
master-next).

Regards,

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


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

Re: [oe] checking if a patch was approved

[Paul Eggleton]

On Tuesday 27 October 2015 08:12:48 Nicolas Dechesne wrote:
> On Tue, Oct 27, 2015 at 12:12 AM, Ivan Sergio Borgonovo
>  wrote:
> > I saw many patch passing by and I submitted a couple about
> > meta-toolchain-qt5.
> > I didn't see any message from Otavio or Martin "approving" a patches.
> > 
> > How can I check if it was approved other than pulling from the
> > repo/checking github?
> > 
> > Or if there is no place to check... consider this a ping ;)
> 
> all commits are published on
> openembedded-comm...@lists.openembedded.org mailing list, and in
> general you see when it's pushed in master-next, then in master.. i
> have a mail filter that checks my name there.. it's the poor man
> solution.. but it works. Note that the email trigger has been broken
> for 2 weeks.. but i suspect this is a temporary issue that should be
> fixed..

FWIW there are a small number of us working on improving patchwork so that 
we're able to rely upon the results it shows as being the outstanding patches 
in the queue and potentially even send email notifications to submitters (opt-
in). I'd also like to go a step further and trigger some automatic validation 
on patches. At the moment we're trying to figure out if we're able to spend the 
time working on this in the next development cycle.

Cheers,
Paul

-- 

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

Re: [oe] [meta-qt5] qtbluetooth not building against bluez

[Martin Jansa]

On Tue, Oct 27, 2015 at 11:51:44AM +0100, mich...@losert.org wrote:
> I'm using qtbluetooth (qtconnectivity_git.bb) and noticed that it builds 
> some kind of empty dummy library.
> I then tried building in verbose mode: "bitbake -v qtconnectivity" and 
> got the following message in the log:
> "Unsupported Bluetooth platform, will not build a working QtBluetooth 
> library.
> Either no Qt D-Bus found or no BlueZ headers."
> 
> My solution was to add
>EXTRA_QMAKEVARS_PRE += "CONFIG+=config_bluez"
> to
>recipes-qt/qt5/qtconnectivity_git.bb

Someone else send patch for this:
http://patchwork.openembedded.org/patch/105501/

I've asked him to resend with proper commit message, author and SOB, but
haven't seen v2.

But there is also first line in this do_configure_prepend, which should
take care of respecting PACKAGECONFIG values, we should check why it
doesn't work anymore and fix the root-cause instead of reintroducing

EXTRA_QMAKEVARS_PRE += "${@base_contains('PACKAGECONFIG', 'bluez4', 
'CONFIG+=OE_BLUEZ_ENABLED', '', d)}"

do_configure_prepend() {
export QMAKE_CACHE_EVAL="CONFIG+=${EXTRA_OECONF}"
# disable bluez test if it isn't enabled by PACKAGECONFIG
sed -i 's/^qtCompileTest(bluez)/OE_BLUEZ_ENABLED:qtCompileTest(bluez)/g' 
${S}/qtconnectivity.pro
}

Can you please look into that?

> after that it worked as expected.
> I'm unsure if it's the right thing to do though.
> 
> I'm working with yocto 1.8 fido but also checked the master branch which 
> doesn't seem to have anything changed related to qtconnectivity.
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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

Re: [oe] [OE-core] State of bitbake world, Failed tasks 2015-10-26

[Martin Jansa]

On Mon, Oct 26, 2015 at 11:49:18PM +0100, Andreas Müller wrote:
> On Mon, Oct 26, 2015 at 9:47 PM, Martin Jansa  wrote:
> 
> > === common (2) ===
> > * /meta-openembedded/meta-oe/recipes-graphics/gerbil/gerbil_git.bb, 
> > do_compile
> > * /openembedded-core/meta/recipes-graphics/libsdl2/libsdl2_2.0.3.bb, 
> > do_compile
> ^ Hope I find time for this one. What DISTRO features were set: x11 and 
> wayland?

yes, both are in

OE qemuarm@ ~/oe/world/shr-core $ grep ^DISTRO_FEATURES= env.libsdl2 
DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia usbgadget 
usbhost wifi xattr nfs zeroconf pci 3g nfc x11 ipv4 ipv6 libc-backtrace 
libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt   
libc-crypt-ufc libc-db-aliases libc-envz 
libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse 
 libc-getlogin libc-idn libc-inet-anl libc-libm libc-locales 
libc-locale-code libc-memusage libc-nis libc-nsswitch libc-rcmd 
libc-rtld-debug libc-spawn libc-streams libc-sunrpc 
  libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar 
libc-posix-regexp libc-posix-regexp-glibc
libc-posix-wchar-io ld-is-gold systemd opengl wayland pulseaudio bluez5"

OE qemuarm@ ~/oe/world/shr-core $ grep ^PACKAGECONFIG= env.libsdl2  
 
PACKAGECONFIG=" opengl alsa  pulseaudio wayland x11 "

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


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

Re: [oe] State of bitbake world, Failed tasks 2015-10-26

[Martin Jansa]

On Mon, Oct 26, 2015 at 09:47:16PM +0100, Martin Jansa wrote:
> === qemuarm (1) ===
> * /openembedded-core/meta/recipes-support/libunwind/libunwind_1.1.bb, 
> do_compile

I was checking this one today

../arm-oe-linux-gnueabi-libtool  --tag=CC   --mode=link 
arm-oe-linux-gnueabi-gcc  -march=armv5e -marm  -mthumb-interwork 
--sysroot=/home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemuarm  -O2 -pipe 
-g -feliminate-unused-debug-types -DAO_USE_PTHREAD_DEFS=1 -fexceptions -Wall 
-Wsign-compare  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fuse-ld=gold -o 
test-coredump-unwind test-coredump-unwind.o ../src/libunwind-coredump.la 
../src/libunwind-arm.la
arm-oe-linux-gnueabi-libtool: link: arm-oe-linux-gnueabi-gcc -march=armv5e 
-marm -mthumb-interwork 
--sysroot=/home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemuarm -O2 -pipe 
-g -feliminate-unused-debug-types -DAO_USE_PTHREAD_DEFS=1 -fexceptions -Wall 
-Wsign-compare -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fuse-ld=gold -o 
.libs/Lperf-simple Lperf-simple.o  ../src/.libs/libunwind.so -lc -lgcc_s
../src/.libs/libunwind.so: error: undefined reference to 'AO_pt_lock'
collect2: error: ld returned 1 exit status
make[1]: *** [Lperf-simple] Error 1

arm-oe-linux-gnueabi-libtool: link: arm-oe-linux-gnueabi-gcc -march=armv5e 
-marm -mthumb-interwork 
--sysroot=/home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemuarm -O2 -pipe 
-g -feliminate-unused-debug-types -DAO_USE_PTHREAD_DEFS=1 -fexceptions -Wall 
-Wsign-compare -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fuse-ld=gold -o 
.libs/Gperf-simple Gperf-simple.o  ../src/.libs/libunwind-arm.so 
/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5e-oe-linux-gnueabi/libunwind/1.1-r0/build/src/.libs/libunwind.so
 ../src/.libs/libunwind.so -lc -lgcc_s
../src/.libs/libunwind-arm.so: error: undefined reference to 'AO_pt_lock'
collect2: error: ld returned 1 exit status

...

Adding -latomic_ops works, but

* News for v0.98.3:

** Dont link against libatomic_ops for now.  Due to a packaging bug on
   Debian, linking against this library causes libunwind.so to get
   a dependency on libatomic_ops.so, which is not at all what we want.
   Fortunately, we don't have to link against that library on x86 or
   ia64 since the library is strictly needed only for platforms with
   poor atomic operation support.  Once the libatomic_ops package is fixed,
   we can re-enable linking against libatomic_ops.

and
#  AC_CHECK_LIB(atomic_ops, main)
is commented out in configure for all builds.

https://raw.githubusercontent.com/rdnetto/teapot-buildroot/master/package/libunwind/libunwind-02-Add-AO_REQUIRE_CAS-to-fix-build-on-ARM-v6.patch
fixes the issue in my builds, I'll send patch shortly, I wonder why YP 
autobuilder didn't catch this issue.

Regards,


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

Re: [oe] OE/Yocto developer survey

[Stephano Cetola]

On 10/26, Cliff Brake wrote:
> How long have you been using OE?  

~3 years

> How do you use OE/Yocto?
 [ X ] product development
 [ X ] hobby/research/education/yocto core developer, etc
 
> What distro do you use?
 [   ] Poky
 [   ] Angstrom
 [ X ] nodistro or custom (Based on Poky)
 
> How do you organize multiple git repos?
 [   ] Git submodules
 [ X ] Repo
 [ X ] Other (Customer Python scripts)
 
> What packaging system?
 [   ] OPKG
 [   ] RPM
 [ X ] Other (IPK)
 
> What GUI toolkits?
 [ X ] Qt
 [ X ] Gtk
 [   ] EFL
 [ X ] HTML5/JS
 [   ] Other
 
 Our clients develop in QML.

> What init system?
 [   ] systemd
 [ X ] sysvinit
 [ X ] busybox init
 [   ] Other
 
> What libc?
 [ X ] glibc
 [   ] uclibc
 [   ] musl
 [   ] Other
 
> How do you develop custom applications?
 [   ] application-SDK
 [ X ] devshell
 [ X ] develop on PC, test on target
 [   ] Other
 
> What language do you primarily use for custom applications?
 [ X ] C
 [ X ] C++
 [   ] Python
 [   ] Javascript
 [   ] Lua
 [   ] Other
 
 Qt for C++

> What do you use for Continuous Integration?
 [   ] Buildbot
 [ X ] Jenkins
 [   ] Other

Tried buildbot but it required too much customization for our small
team.

> Do you use any any of the tooling projects
> (https://www.yoctoproject.org/tools-resources/projects) such as ADT,
> Hob, Toaster, etc?
 
 No
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] "krb" fails to build, suspect GCC bug

[Martin Jansa]

On Sat, Sep 05, 2015 at 02:39:14PM +0200, Mike Looijmans wrote:
> I got this weird build failure from the "krb" package:
> 
> | make[3]: Entering directory 
> '/TOPDIR/build/tmp/work/mips32el-oe-linux/krb5/1.13.2-r0/krb5-1.13.2/src/lib/krb5/ccache'
> | mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32 
> --sysroot=/TOPDIR/build/tmp/sysroots/formuler1 -fPIC -DSHARED 
> -DHAVE_CONFIG_H  -I../../../include -I../../../include -I./ccapi -I. -I. 
>   -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE  -Os -pipe -g 
> -feliminate-unused-debug-types -DDESTRUCTOR_ATTR_WORKS=1 
> -I/TOPDIR/build/tmp/sysroots/formuler1/usr/include/et -Wall -Wcast-align 
> -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow 
> -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes 
> -Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function 
> -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas 
> -Wsign-compare -Werror=uninitialized -Werror=pointer-arith 
> -Werror=declaration-after-statement 
> -Werror-implicit-function-declaration -pthread -c cc_file.c -o 
> cc_file.so.o && mv -f cc_file.so.o cc_file.so
> | cc_file.c: In function 'fcc_next_cred':
> | cc_file.c:368:9: error: 'maxsize' may be used uninitialized in this 
> function [-Werror=maybe-uninitialized]
> |  ret = load_data(context, id, maxsize, buf);
> |  ^
> | cc_file.c:1091:12: note: 'maxsize' was declared here
> |  size_t maxsize;
> | ^
> | cc1: some warnings being treated as errors
> 
> Looking at the source, this doesn't make any sense at all. The 
> declaration of the variable isn't even in the same method body. And the 
> line it complains about is about the fifth time it passes that variable 
> to another method.
> 
> And working around it by initializing maxsize=0 just makes the compiler 
> choke on a similar situation elsewhere:
> | packet.c:50:67: error: 'id' may be used uninitialized in this function
> 
> 
> I suspect the problem here is GCC and not the krb code. Anyone seen this?

I've seen it today in my world builds, It seems to fail only when building with 
-Os.

I've seen similar issue in mdadm, also only with -Os.

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


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

Re: [oe] "krb" fails to build, suspect GCC bug

[Khem Raj]

On Tue, Oct 27, 2015 at 11:21 AM, Martin Jansa  wrote:
> On Sat, Sep 05, 2015 at 02:39:14PM +0200, Mike Looijmans wrote:
>> I got this weird build failure from the "krb" package:
>>
>> | make[3]: Entering directory
>> '/TOPDIR/build/tmp/work/mips32el-oe-linux/krb5/1.13.2-r0/krb5-1.13.2/src/lib/krb5/ccache'
>> | mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32
>> --sysroot=/TOPDIR/build/tmp/sysroots/formuler1 -fPIC -DSHARED
>> -DHAVE_CONFIG_H  -I../../../include -I../../../include -I./ccapi -I. -I.
>>   -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE  -Os -pipe -g
>> -feliminate-unused-debug-types -DDESTRUCTOR_ATTR_WORKS=1
>> -I/TOPDIR/build/tmp/sysroots/formuler1/usr/include/et -Wall -Wcast-align
>> -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow
>> -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes
>> -Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function
>> -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas
>> -Wsign-compare -Werror=uninitialized -Werror=pointer-arith
>> -Werror=declaration-after-statement
>> -Werror-implicit-function-declaration -pthread -c cc_file.c -o
>> cc_file.so.o && mv -f cc_file.so.o cc_file.so
>> | cc_file.c: In function 'fcc_next_cred':
>> | cc_file.c:368:9: error: 'maxsize' may be used uninitialized in this
>> function [-Werror=maybe-uninitialized]
>> |  ret = load_data(context, id, maxsize, buf);
>> |  ^
>> | cc_file.c:1091:12: note: 'maxsize' was declared here
>> |  size_t maxsize;
>> | ^
>> | cc1: some warnings being treated as errors
>>
>> Looking at the source, this doesn't make any sense at all. The
>> declaration of the variable isn't even in the same method body. And the
>> line it complains about is about the fifth time it passes that variable
>> to another method.
>>
>> And working around it by initializing maxsize=0 just makes the compiler
>> choke on a similar situation elsewhere:
>> | packet.c:50:67: error: 'id' may be used uninitialized in this function
>>
>>
>> I suspect the problem here is GCC and not the krb code. Anyone seen this?
>
> I've seen it today in my world builds, It seems to fail only when building 
> with -Os.
>
> I've seen similar issue in mdadm, also only with -Os.
>

is this regression ? or seen for first time?

> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] llvm: update 3.5.2 to have a sane ARM JIT for OpenJDK-8

[Jens Rehsack]

> Am 27.10.2015 um 21:15 schrieb Otavio Salvador 
> :
> 
> On Tue, Oct 27, 2015 at 6:04 PM, Jens Rehsack  wrote:
>> 
>> llvm introduced new JIT technology MCJIT with llvm 3.4 and fixes ARM in 3.5
>> (see 
>> http://llvm.org/releases/3.5.2/docs/ReleaseNotes.html#changes-to-the-arm-backend).
>> 
>> Ensure JIT is built with llvm
>> 
>> Signed-off-by: Jens Rehsack 
> 
> There is a patch to add LLVM 3.7[1]; I think this one can be dropped.
> 
> 1. http://patchwork.openembedded.org/patch/106281/

I'v seen this and I guarantee that OpenJDK-8 will fail heavily with llvm3.7 - 
the guys
put an end to an antiquated API's with each release, and OpenJDK's zeroshark 
uses lot's
of them.

Cheers
-- 
Jens Rehsack - rehs...@gmail.com

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

[oe] [meta-java][PATCH 3/4] cacao: fix broken build with existing workdir

[Jens Rehsack]

Cacao hast some weird configure script which fails heavily when run twice
in same build/work directory. Ensure clean rebuilds ...

Signed-off-by: Jens Rehsack 
---
 recipes-core/cacao/cacao_1.6.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/cacao/cacao_1.6.1.bb 
b/recipes-core/cacao/cacao_1.6.1.bb
index 6e2fb99..ae06b50 100644
--- a/recipes-core/cacao/cacao_1.6.1.bb
+++ b/recipes-core/cacao/cacao_1.6.1.bb
@@ -17,7 +17,7 @@ SRC_URI = 
"http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-
 SRC_URI[md5sum] = "2c18478404afd1cffdd15ad1e9d85a57"
 SRC_URI[sha256sum] = 
"eecc8bd1b528a028f43d9d1d0c06b97855bbf1d40e03826d911ebbc0b6971e12"
 
-inherit java autotools-brokensep update-alternatives pkgconfig 
distro_features_check
+inherit java autotools-brokensep update-alternatives pkgconfig 
distro_features_check rm_work
 
 REQUIRED_DISTRO_FEATURES = "x11"
 REQUIRED_DISTRO_FEATURES_class-native := ""
-- 
1.9.1

-- 
Jens Rehsack - rehs...@gmail.com

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

[oe] [meta-oe][PATCH] llvm: update 3.5.2 to have a sane ARM JIT for OpenJDK-8

[Jens Rehsack]

llvm introduced new JIT technology MCJIT with llvm 3.4 and fixes ARM in 3.5
(see 
http://llvm.org/releases/3.5.2/docs/ReleaseNotes.html#changes-to-the-arm-backend).

Ensure JIT is built with llvm

Signed-off-by: Jens Rehsack 
---
 meta-oe/recipes-core/llvm/llvm.inc |  9 +++-
 meta-oe/recipes-core/llvm/llvm3.3_3.3.bb   |  7 ++
 .../llvm/llvm3.5/arm_fenv_uclibc.patch | 14 
 meta-oe/recipes-core/llvm/llvm3.5_3.5.2.bb | 25 ++
 4 files changed, 49 insertions(+), 6 deletions(-)
 create mode 100644 meta-oe/recipes-core/llvm/llvm3.5/arm_fenv_uclibc.patch
 create mode 100644 meta-oe/recipes-core/llvm/llvm3.5_3.5.2.bb

diff --git a/meta-oe/recipes-core/llvm/llvm.inc 
b/meta-oe/recipes-core/llvm/llvm.inc
index 04c87aa..21aee3f 100644
--- a/meta-oe/recipes-core/llvm/llvm.inc
+++ b/meta-oe/recipes-core/llvm/llvm.inc
@@ -20,19 +20,15 @@
 DESCRIPTION = "The Low Level Virtual Machine"
 HOMEPAGE = "http://llvm.org;
 
-# 3-clause BSD-like
-# University of Illinois/NCSA Open Source License
-LICENSE = "NCSA"
-LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=d0a3ef0d3e0e8f5cf59e5ffc273ab1f8"
-
 DEPENDS = "libffi libxml2-native llvm-common"
 
 inherit perlnative pythonnative autotools
 
 LLVM_RELEASE = "${PV}"
 LLVM_DIR = "llvm${LLVM_RELEASE}"
+LLVM_SRC_EXT ?= "xz"
 
-SRC_URI = "http://llvm.org/releases/${PV}/llvm-${PV}.src.tar.gz;
+SRC_URI = "http://llvm.org/releases/${PV}/llvm-${PV}.src.tar.${LLVM_SRC_EXT};
 S = "${WORKDIR}/llvm-${PV}.src"
 
 LLVM_BUILD_DIR = "${WORKDIR}/llvm-${PV}.build"
@@ -42,6 +38,7 @@ EXTRA_OECONF += "--disable-assertions \
  --enable-debug-runtime \
  --disable-expensive-checks \
  --enable-bindings=none \
+ --enable-jit \
  --enable-keep-symbols \
  --enable-libffi \
  --enable-optimized \
diff --git a/meta-oe/recipes-core/llvm/llvm3.3_3.3.bb 
b/meta-oe/recipes-core/llvm/llvm3.3_3.3.bb
index 60a2221..2a82213 100644
--- a/meta-oe/recipes-core/llvm/llvm3.3_3.3.bb
+++ b/meta-oe/recipes-core/llvm/llvm3.3_3.3.bb
@@ -1,5 +1,12 @@
+LLVM_SRC_EXT ?= "gz"
+
 require llvm.inc
 
+# 3-clause BSD-like
+# University of Illinois/NCSA Open Source License
+LICENSE = "NCSA"
+LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=d0a3ef0d3e0e8f5cf59e5ffc273ab1f8"
+
 DEPENDS += "zlib"
 EXTRA_OECONF += "--enable-zlib"
 
diff --git a/meta-oe/recipes-core/llvm/llvm3.5/arm_fenv_uclibc.patch 
b/meta-oe/recipes-core/llvm/llvm3.5/arm_fenv_uclibc.patch
new file mode 100644
index 000..c3ae494
--- /dev/null
+++ b/meta-oe/recipes-core/llvm/llvm3.5/arm_fenv_uclibc.patch
@@ -0,0 +1,14 @@
+Index: llvm-2.9/include/llvm/Support/FEnv.h
+===
+--- llvm-2.9.orig/include/llvm/Support/FEnv.h  2010-11-29 20:44:50.0 
+0100
 llvm-2.9/include/llvm/Support/FEnv.h   2011-11-18 18:42:22.580161297 
+0100
+@@ -17,6 +17,9 @@
+ 
+ #include "llvm/Config/config.h"
+ #include 
++
++#undef HAVE_FENV_H
++
+ #ifdef HAVE_FENV_H
+ #include 
+ #endif
diff --git a/meta-oe/recipes-core/llvm/llvm3.5_3.5.2.bb 
b/meta-oe/recipes-core/llvm/llvm3.5_3.5.2.bb
new file mode 100644
index 000..7289b81
--- /dev/null
+++ b/meta-oe/recipes-core/llvm/llvm3.5_3.5.2.bb
@@ -0,0 +1,25 @@
+require llvm.inc
+
+# 3-clause BSD-like
+# University of Illinois/NCSA Open Source License
+LICENSE = "NCSA"
+LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d"
+
+DEPENDS += "zlib"
+EXTRA_OECONF += "--enable-zlib"
+
+SRC_URI_append_libc-uclibc = " file://arm_fenv_uclibc.patch "
+
+SRC_URI[md5sum] = "f5a4dc595f7e8bd23397684d0906d014"
+SRC_URI[sha256sum] = 
"44196156d5749eb4b4224fe471a29cc3984df92570a4a89fa859f7394fc0c575"
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[r600] = "--enable-experimental-targets=R600,,,"
+
+# Fails to build with thumb-1 (qemuarm)
+# | {standard input}: Assembler messages:
+# | {standard input}:22: Error: selected processor does not support Thumb mode 
`stmdb sp!,{r0,r1,r2,r3,lr}'
+# | {standard input}:31: Error: lo register required -- `ldmia 
sp!,{r0,r1,r2,r3,lr}'
+# | {standard input}:32: Error: lo register required -- `ldr pc,[sp],#4'
+# | make[3]: *** 
[/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/llvm3.3/3.3-r0/llvm-3.3.build/lib/Target/ARM/Release/ARMJITInfo.o]
 Error 1
+ARM_INSTRUCTION_SET = "arm"
-- 
1.9.1


-- 
Jens Rehsack - rehs...@gmail.com

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

[oe] [meta-oe][PATCH] rrdtool: fix compile error V2

[Jens Rehsack]

Since cpan.bbclass has evolved, the old wrapper simulation needs some adoption.
Use as much as possible from cpan.bbclass instead of copying code from there.

Signed-off-by: Jens Rehsack 
---
 meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb 
b/meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb
index 2c81d56..666ace9 100644
--- a/meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb
+++ b/meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb
@@ -15,7 +15,7 @@ SRC_URI = "\
 
 S = "${WORKDIR}/git"
 
-inherit autotools-brokensep gettext pythonnative perlnative python-dir 
cpan-base systemd
+inherit cpan autotools-brokensep gettext pythonnative python-dir systemd
 
 BBCLASSEXTEND = "native"
 
@@ -50,21 +50,13 @@ EXTRA_OECONF = " \
 --disable-rpath \
 "
 
-# don't use perl.real, this results in break issues with prebuilts since 
perl.real doesn't
-# know where the PERL5LIB is...
-# use wrapper perl instead
-EXTRA_OEMAKE = "PERL=${STAGING_BINDIR_NATIVE}/perl-native/perl 
FULLPERL=${STAGING_BINDIR_NATIVE}/perl-native/perl"
-
 export BUILD_SYS
 export HOST_SYS
 export STAGING_LIBDIR
 export STAGING_INCDIR
 
-# Env var which tells perl if it should use host (no) or target (yes) settings
-export PERLCONFIGTARGET = "${@is_target(d)}"
-export PERL_INC = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}/CORE"
-export PERL_LIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}"
-export PERL_ARCHLIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}"
+# emulate cpan_do_configure
+EXTRA_OEMAKE = ' PERL5LIB="${PERL_ARCHLIB}" '
 
 do_configure() {
 #fix the pkglib problem with newer automake
-- 
1.9.1

This is a V2 after rebasing oe/master

Error is here for a few days ... http://nopaste.linux-dev.org/?785761

-- 
Jens Rehsack - rehs...@gmail.com

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

[oe] [meta-java][PATCH 2/4] meta-java: rely on well known bootstrap-path

[Jens Rehsack]

Instead of potential circular depending virtual/javac-native (even this
recipe provides such a useable java-native), rely on well known path
via cacao-native to build up to icedtea7-native in reliable manner.

virtual/javac-native should be used by parts not belonging to the bootstrap
phase.

Signed-off-by: Jens Rehsack 
---
 classes/java-bootstrap-components.bbclass   | 7 +++
 classes/java-library.bbclass| 3 ++-
 recipes-core/ant/ant-native_1.8.1.bb| 2 +-
 recipes-core/cacao/cacao_1.6.1.bb   | 4 +++-
 recipes-core/classpath/classpath.inc| 4 ++--
 recipes-core/classpathx/gnujaf_1.1.1.bb | 2 +-
 recipes-core/classpathx/gnumail_1.1.2.bb| 2 +-
 recipes-core/classpathx/inetlib_1.1.1.bb| 2 +-
 recipes-core/ecj/ecj-bootstrap-native.bb| 2 +-
 recipes-core/ecj/libecj-bootstrap.inc   | 2 +-
 recipes-core/icedtea/icedtea7-native.inc| 2 +-
 recipes-core/jacl/jacl_1.4.1.bb | 2 +-
 recipes-core/jakarta-commons/commons-logging_1.1.1.bb   | 2 ++
 recipes-core/jakarta-commons/commons-net_1.4.1.bb   | 2 ++
 recipes-core/jakarta-libs/avalon-framework-api_4.3.bb   | 2 +-
 recipes-core/jakarta-libs/bsf_2.4.0.bb  | 2 +-
 recipes-core/jakarta-libs/log4j1.2_1.2.17.bb| 2 +-
 recipes-core/jakarta-libs/logkit_1.2.2.bb   | 2 +-
 recipes-core/jakarta-libs/oro_2.0.8.bb  | 2 +-
 recipes-core/jakarta-libs/poi_3.0.bb| 2 +-
 recipes-core/jakarta-libs/regexp_1.5.bb | 2 +-
 recipes-core/jamvm/jamvm.inc| 4 ++--
 recipes-core/jcraft/jsch_0.1.40.bb  | 2 +-
 recipes-core/jcraft/jzlib_1.0.7.bb  | 2 +-
 recipes-core/jdepend/jdepend_2.9.1.bb   | 2 +-
 recipes-core/jlex/jlex_1.2.6.bb | 2 +-
 recipes-core/junit/junit4_4.3.1.bb  | 4 +---
 recipes-core/junit/junit_3.8.2.bb   | 2 +-
 recipes-core/rhino/rhino_1.7r4.bb   | 2 +-
 recipes-core/servlet-api/servlet2.3_4.1.37.bb   | 4 +---
 recipes-core/servlet-api/servlet2.4_5.5.26.bb   | 2 --
 recipes-core/xalan-j/xalan-j_2.7.1.bb   | 2 +-
 recipes-core/xerces-j/xerces-j_2.11.0.bb| 6 +++---
 recipes-core/xml-commons/jaxp1.3_1.4.01.bb  | 4 +---
 recipes-core/xml-commons/xml-commons-resolver1.1_1.2.bb | 6 +++---
 recipes-core/xml-commons/xpp2_2.1.10.bb | 2 --
 recipes-core/xml-commons/xpp3_1.1.3.4.O.bb  | 2 --
 37 files changed, 51 insertions(+), 49 deletions(-)
 create mode 100644 classes/java-bootstrap-components.bbclass

diff --git a/classes/java-bootstrap-components.bbclass 
b/classes/java-bootstrap-components.bbclass
new file mode 100644
index 000..76e6b25
--- /dev/null
+++ b/classes/java-bootstrap-components.bbclass
@@ -0,0 +1,7 @@
+# This is to be used by recipes which rely on java-library.bbclass
+# infrastructure and their a *-native recipe are parts of the bootstrap
+# process
+# 
+
+DEPENDS_prepend_class-native = " ecj-bootstrap-native "
+DEPENDS_prepend_class-target = " virtual/javac-native "
diff --git a/classes/java-library.bbclass b/classes/java-library.bbclass
index 144cd2f..a192f14 100644
--- a/classes/java-library.bbclass
+++ b/classes/java-library.bbclass
@@ -35,7 +35,8 @@ def java_package_name(d):
 
 JPN ?= "${@java_package_name(d)}"
 
-DEPENDS_prepend = "virtual/javac-native fastjar-native "
+DEPENDS_prepend = " fastjar-native "
+DEPENDS_prepend_class-target = " virtual/javac-native "
 
 PACKAGES += "${JPN}"
 
diff --git a/recipes-core/ant/ant-native_1.8.1.bb 
b/recipes-core/ant/ant-native_1.8.1.bb
index 35b45d6..6cdbc80 100644
--- a/recipes-core/ant/ant-native_1.8.1.bb
+++ b/recipes-core/ant/ant-native_1.8.1.bb
@@ -11,7 +11,7 @@ SRC_URI = 
"http://archive.apache.org/dist/ant/source/apache-ant-${PV}-src.tar.gz
 
 S = "${WORKDIR}/apache-ant-${PV}"
 
-inherit java-library java-native
+inherit java-library java-native java-bootstrap-components
 
 DEPENDS = " \
jsch-native bsf-native xalan-j-native xerces-j-native \
diff --git a/recipes-core/cacao/cacao_1.6.1.bb 
b/recipes-core/cacao/cacao_1.6.1.bb
index f88293b..6e2fb99 100644
--- a/recipes-core/cacao/cacao_1.6.1.bb
+++ b/recipes-core/cacao/cacao_1.6.1.bb
@@ -7,7 +7,9 @@ SECTION  = "interpreters"
 DEPENDS_class-native = "zlib-native libtool-native ecj-initial-native 
fastjar-native classpath-native bdwgc-native"
 PROVIDES_class-native = "virtual/java-native"
 
-DEPENDS = "zlib libtool classpath virtual/javac-native bdwgc"
+DEPENDS_class-target = " virtual/javac-native "
+
+DEPENDS = "zlib libtool classpath bdwgc"
 RPROVIDES_${PN} = "java2-runtime"
 
 SRC_URI = 
"http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.xz
 \

[oe] [meta-java][PATCH 1/4] Avoid parse time errors due to dependency on x11, for distros without x11

[Jens Rehsack]

BitBake raises some errors when processing recipes that depend on x11
for distros that don't have x11 in DISTRO_FEATURES. To work around
that issue, REQUIRED_DISTRO_FEATURES = "x11" (from
distro_features_check.bbclass) has been set for the following recipes:

* cacao (_class-target)
* classpath (_class-target)
* jamvm (_class-target)
* openjdk-7-release

That makes BitBake skip those recipes during the cache generation
(they'd still be parsed, but ignored).

This patch improves the idea from Mario Domenech Goulart 


Signed-off-by: Jens Rehsack 
---
 recipes-core/cacao/cacao_1.6.1.bb | 1 +
 recipes-core/classpath/classpath.inc  | 4 +---
 recipes-core/classpath/classpath_0.99.bb  | 4 
 recipes-core/jamvm/jamvm.inc  | 4 +---
 recipes-core/jamvm/jamvm_git.bb   | 4 
 recipes-core/openjdk/openjdk-7_85b01-2.6.1.bb | 4 
 recipes-core/openjdk/openjdk-common.inc   | 4 +---
 7 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/recipes-core/cacao/cacao_1.6.1.bb 
b/recipes-core/cacao/cacao_1.6.1.bb
index 564dd1e..f88293b 100644
--- a/recipes-core/cacao/cacao_1.6.1.bb
+++ b/recipes-core/cacao/cacao_1.6.1.bb
@@ -18,6 +18,7 @@ SRC_URI[sha256sum] = 
"eecc8bd1b528a028f43d9d1d0c06b97855bbf1d40e03826d911ebbc0b6
 inherit java autotools-brokensep update-alternatives pkgconfig 
distro_features_check
 
 REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES_class-native := ""
 
 EXTRA_OECONF_class-native = "\
 --enable-debug \
diff --git a/recipes-core/classpath/classpath.inc 
b/recipes-core/classpath/classpath.inc
index 0f760fe..1bdfd78 100644
--- a/recipes-core/classpath/classpath.inc
+++ b/recipes-core/classpath/classpath.inc
@@ -7,9 +7,7 @@ LICENSE = "Classpath"
 
 PBN = "classpath"
 
-inherit autotools java gettext distro_features_check
-
-REQUIRED_DISTRO_FEATURES = "x11"
+inherit autotools java gettext
 
 DEPENDS = "virtual/javac-native fastjar-native zip-native gmp antlr-native 
gtk+ gconf libxtst file"
 
diff --git a/recipes-core/classpath/classpath_0.99.bb 
b/recipes-core/classpath/classpath_0.99.bb
index 8b3a6e3..6aa3baa 100644
--- a/recipes-core/classpath/classpath_0.99.bb
+++ b/recipes-core/classpath/classpath_0.99.bb
@@ -1,5 +1,9 @@
 require classpath.inc
 
+inherit distro_features_check
+
+REQUIRED_DISTRO_FEATURES = "x11"
+
 LIC_FILES_CHKSUM = "file://LICENSE;md5=92acc79f1f429143f4624d07b253702a"
 
 SRC_URI += " \
diff --git a/recipes-core/jamvm/jamvm.inc b/recipes-core/jamvm/jamvm.inc
index e00813e..5893cbc 100644
--- a/recipes-core/jamvm/jamvm.inc
+++ b/recipes-core/jamvm/jamvm.inc
@@ -21,9 +21,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/jamvm/jamvm-${PV}.tar.gz \
   "
 
 
-inherit java autotools update-alternatives pkgconfig distro_features_check
-
-REQUIRED_DISTRO_FEATURES = "x11"
+inherit java autotools update-alternatives pkgconfig
 
 # This uses 32 bit arm, so force the instruction set to arm, not thumb
 ARM_INSTRUCTION_SET = "arm"
diff --git a/recipes-core/jamvm/jamvm_git.bb b/recipes-core/jamvm/jamvm_git.bb
index 07eed6a..63364aa 100644
--- a/recipes-core/jamvm/jamvm_git.bb
+++ b/recipes-core/jamvm/jamvm_git.bb
@@ -3,6 +3,10 @@
 
 require jamvm.inc
 
+inherit distro_features_check
+
+REQUIRED_DISTRO_FEATURES = "x11"
+
 SRCREV = "ebd11bde0a97b57f0d18938c6b65468d3c932719"
 PV = "1.5.5+1.6.0-devel+git${SRCPV}"
 
diff --git a/recipes-core/openjdk/openjdk-7_85b01-2.6.1.bb 
b/recipes-core/openjdk/openjdk-7_85b01-2.6.1.bb
index 1ca3b08..e631c13 100644
--- a/recipes-core/openjdk/openjdk-7_85b01-2.6.1.bb
+++ b/recipes-core/openjdk/openjdk-7_85b01-2.6.1.bb
@@ -1,5 +1,9 @@
 require openjdk-7-release-85b01.inc
 
+inherit distro_features_check
+
+REQUIRED_DISTRO_FEATURES = "x11"
+
 PR = "${INC_PR}.1"
 
 SRC_URI[iced.md5sum] = "efac44117a94b9d3278988959e336e05"
diff --git a/recipes-core/openjdk/openjdk-common.inc 
b/recipes-core/openjdk/openjdk-common.inc
index e3e597a..dc26522 100644
--- a/recipes-core/openjdk/openjdk-common.inc
+++ b/recipes-core/openjdk/openjdk-common.inc
@@ -17,9 +17,7 @@ DEPENDS_append_libc-uclibc = " virtual/libiconv "
 # because structure sizes and/or alignment may differ.
 DEPENDS_append = " qemu-native "
 
-inherit java autotools gettext qemu pkgconfig distro_features_check
-
-REQUIRED_DISTRO_FEATURES = "x11"
+inherit java autotools gettext qemu pkgconfig
 
 # OpenJDK uses slightly different names for certain arches. We need to know
 #  this to create some files which are expected by the build.
-- 
1.9.1


-- 
Jens Rehsack - rehs...@gmail.com

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

Re: [oe] "krb" fails to build, suspect GCC bug

[Martin Jansa]

On Tue, Oct 27, 2015 at 08:57:42PM +0100, Martin Jansa wrote:
> On Tue, Oct 27, 2015 at 11:26:32AM -0700, Khem Raj wrote:
> > On Tue, Oct 27, 2015 at 11:21 AM, Martin Jansa  
> > wrote:
> > > On Sat, Sep 05, 2015 at 02:39:14PM +0200, Mike Looijmans wrote:
> > >> I got this weird build failure from the "krb" package:
> > >>
> > >> | make[3]: Entering directory
> > >> '/TOPDIR/build/tmp/work/mips32el-oe-linux/krb5/1.13.2-r0/krb5-1.13.2/src/lib/krb5/ccache'
> > >> | mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32
> > >> --sysroot=/TOPDIR/build/tmp/sysroots/formuler1 -fPIC -DSHARED
> > >> -DHAVE_CONFIG_H  -I../../../include -I../../../include -I./ccapi -I. -I.
> > >>   -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE  -Os -pipe -g
> > >> -feliminate-unused-debug-types -DDESTRUCTOR_ATTR_WORKS=1
> > >> -I/TOPDIR/build/tmp/sysroots/formuler1/usr/include/et -Wall -Wcast-align
> > >> -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow
> > >> -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes
> > >> -Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function
> > >> -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas
> > >> -Wsign-compare -Werror=uninitialized -Werror=pointer-arith
> > >> -Werror=declaration-after-statement
> > >> -Werror-implicit-function-declaration -pthread -c cc_file.c -o
> > >> cc_file.so.o && mv -f cc_file.so.o cc_file.so
> > >> | cc_file.c: In function 'fcc_next_cred':
> > >> | cc_file.c:368:9: error: 'maxsize' may be used uninitialized in this
> > >> function [-Werror=maybe-uninitialized]
> > >> |  ret = load_data(context, id, maxsize, buf);
> > >> |  ^
> > >> | cc_file.c:1091:12: note: 'maxsize' was declared here
> > >> |  size_t maxsize;
> > >> | ^
> > >> | cc1: some warnings being treated as errors
> > >>
> > >> Looking at the source, this doesn't make any sense at all. The
> > >> declaration of the variable isn't even in the same method body. And the
> > >> line it complains about is about the fifth time it passes that variable
> > >> to another method.
> > >>
> > >> And working around it by initializing maxsize=0 just makes the compiler
> > >> choke on a similar situation elsewhere:
> > >> | packet.c:50:67: error: 'id' may be used uninitialized in this function
> > >>
> > >>
> > >> I suspect the problem here is GCC and not the krb code. Anyone seen this?
> > >
> > > I've seen it today in my world builds, It seems to fail only when 
> > > building with -Os.
> > >
> > > I've seen similar issue in mdadm, also only with -Os.
> > >
> > 
> > is this regression ? or seen for first time?
> 
> krb5 fails to build like this with -Os at least since dizzy
> 
> mdadm failure:
> | raid6check.c: In function 'check_stripes':
> | raid6check.c:315:8: error: 'stripe_buf' may be used uninitialized in this 
> function [-Werror=maybe-uninitialized]
> |   char *stripe_buf;
> | ^
> | cc1: all warnings being treated as errors
> | make: *** [raid6check.o] Error 1
> | ERROR: oe_runmake failed
> 
> is newer (seen only in Jethro builds).
> 
> But maybe only because this is built in do_compile_ptest_base and ptest
> support was added in oe-core/jethro, it fails the same with gcc-5.2 and 
> gcc-4.9.

Quick grep in my last -Os world build shows 2 more recipes with
similar issue (smbnetfs is failing in krb5 dependency already):

physfs:
| physfs/2.0.3-r0/physfs-2.0.3/archivers/zip.c: In function 'ZIP_openArchive':
| physfs/2.0.3-r0/physfs-2.0.3/archivers/zip.c:944:19: error: 'data_start' may 
be used uninitialized in this function [-Werror=maybe-uninitialized]
|  entry->offset += ofs_fixup;
|^
| physfs/2.0.3-r0/physfs-2.0.3/archivers/zip.c:1116:19: note: 'data_start' was 
declared here
|  PHYSFS_uint32 data_start;
|^
| physfs/2.0.3-r0/physfs-2.0.3/archivers/zip.c: In function 'ZIP_openArchive':
| physfs/2.0.3-r0/physfs-2.0.3/archivers/zip.c:944:19: error: 'data_start' may 
be used uninitialized in this function [-Werror=maybe-uninitialized]
|  entry->offset += ofs_fixup;
|^
| physfs/2.0.3-r0/physfs-2.0.3/archivers/zip.c:1116:19: note: 'data_start' was 
declared here
|  PHYSFS_uint32 data_start;
|^
| cc1: all warnings being treated as errors

tvheadend:
| tvheadend/3.3-r0/git/src/serviceprobe.c: In function 'serviceprobe_thread':
| tvheadend/3.3-r0/git/src/serviceprobe.c:168:7: error: 's' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
|subscription_unsubscribe(s);
|^

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


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

Re: [oe] [meta-oe][PATCH] llvm: update 3.5.2 to have a sane ARM JIT for OpenJDK-8

[Otavio Salvador]

On Tue, Oct 27, 2015 at 6:21 PM, Jens Rehsack  wrote:
>
>> Am 27.10.2015 um 21:15 schrieb Otavio Salvador 
>> :
>>
>> On Tue, Oct 27, 2015 at 6:04 PM, Jens Rehsack  wrote:
>>>
>>> llvm introduced new JIT technology MCJIT with llvm 3.4 and fixes ARM in 3.5
>>> (see 
>>> http://llvm.org/releases/3.5.2/docs/ReleaseNotes.html#changes-to-the-arm-backend).
>>>
>>> Ensure JIT is built with llvm
>>>
>>> Signed-off-by: Jens Rehsack 
>>
>> There is a patch to add LLVM 3.7[1]; I think this one can be dropped.
>>
>> 1. http://patchwork.openembedded.org/patch/106281/
>
> I'v seen this and I guarantee that OpenJDK-8 will fail heavily with llvm3.7 - 
> the guys
> put an end to an antiquated API's with each release, and OpenJDK's zeroshark 
> uses lot's
> of them.

So we will need to figure how to deal with this. I see following options:

 - add needed llvm recipe in meta-java (I dislike this)
 - fix openjdk
 - update openjdk so it work with 3.7 (preferred)

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH] samba: add support for sysvinit via lsb-init-functions

[Jens Rehsack]

Since there're surely lot's of individual distibutions not moved to systemd,
allow sane samba start/stop with systemv anyway. Rely on lsb-init-functions
for improved control.

Signed-off-by: Jens Rehsack 
---
 meta-oe/recipes-connectivity/samba/samba_4.1.12.bb | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta-oe/recipes-connectivity/samba/samba_4.1.12.bb 
b/meta-oe/recipes-connectivity/samba/samba_4.1.12.bb
index 22c2bb4..0a04870 100644
--- a/meta-oe/recipes-connectivity/samba/samba_4.1.12.bb
+++ b/meta-oe/recipes-connectivity/samba/samba_4.1.12.bb
@@ -97,6 +97,11 @@ do_install_append() {
install -d ${D}${sysconfdir}/tmpfiles.d
echo "d ${localstatedir}/log/samba 0755 root root -" \
 > ${D}${sysconfdir}/tmpfiles.d/99-${BPN}.conf
+elif ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'true', 'false', 
d)}; then
+   install -d ${D}${sysconfdir}/init.d
+   install -m 0644 packaging/LSB/samba.sh ${D}${sysconfdir}/init.d
+   update-rc.d -r ${D} samba.sh start 20 3 5 .
+   update-rc.d -r ${D} samba.sh start 20 0 1 6 .
 fi
 
 install -d ${D}${sysconfdir}/samba
@@ -118,7 +123,9 @@ FILES_${PN} += "/run \
"
 
 SMB_SERVICE="${systemd_unitdir}/system/nmb.service 
${systemd_unitdir}/system/smb.service"
+SMB_SYSV="${sysconfdir}/init.d ${sysconfdir}/rc?.d"
 FILES_${PN} +="${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'${SMB_SERVICE}', '', d)}"
+FILES_${PN} +="${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 
'${SMB_SYSV}', '', d)}"
 
 FILES_${PN}-dbg += "${libdir}/samba/idmap/.debug/* \
 ${libdir}/samba/pdb/.debug/* \
-- 
1.9.1

-- 
Jens Rehsack - rehs...@gmail.com

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

Re: [oe] [meta-oe][PATCH] llvm: update 3.5.2 to have a sane ARM JIT for OpenJDK-8

[Otavio Salvador]

On Tue, Oct 27, 2015 at 6:04 PM, Jens Rehsack  wrote:
>
> llvm introduced new JIT technology MCJIT with llvm 3.4 and fixes ARM in 3.5
> (see 
> http://llvm.org/releases/3.5.2/docs/ReleaseNotes.html#changes-to-the-arm-backend).
>
> Ensure JIT is built with llvm
>
> Signed-off-by: Jens Rehsack 

There is a patch to add LLVM 3.7[1]; I think this one can be dropped.

1. http://patchwork.openembedded.org/patch/106281/

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] llvm: update 3.5.2 to have a sane ARM JIT for OpenJDK-8

[Martin Jansa]

On Tue, Oct 27, 2015 at 06:24:52PM -0200, Otavio Salvador wrote:
> On Tue, Oct 27, 2015 at 6:21 PM, Jens Rehsack  wrote:
> >
> >> Am 27.10.2015 um 21:15 schrieb Otavio Salvador 
> >> :
> >>
> >> On Tue, Oct 27, 2015 at 6:04 PM, Jens Rehsack  wrote:
> >>>
> >>> llvm introduced new JIT technology MCJIT with llvm 3.4 and fixes ARM in 
> >>> 3.5
> >>> (see 
> >>> http://llvm.org/releases/3.5.2/docs/ReleaseNotes.html#changes-to-the-arm-backend).
> >>>
> >>> Ensure JIT is built with llvm
> >>>
> >>> Signed-off-by: Jens Rehsack 
> >>
> >> There is a patch to add LLVM 3.7[1]; I think this one can be dropped.
> >>
> >> 1. http://patchwork.openembedded.org/patch/106281/
> >
> > I'v seen this and I guarantee that OpenJDK-8 will fail heavily with llvm3.7 
> > - the guys
> > put an end to an antiquated API's with each release, and OpenJDK's 
> > zeroshark uses lot's
> > of them.
> 
> So we will need to figure how to deal with this. I see following options:
> 
>  - add needed llvm recipe in meta-java (I dislike this)
>  - fix openjdk
>  - update openjdk so it work with 3.7 (preferred)

I don't mind having all 3 llvm versions in parallel until all this is
sorted out.

People can select the right one based on mesa version they are using and
3.8 for OpenJDK.

But I would appreciate this recipe rebased on top of Philip's (or vice
versa), because I don't have spare time to text it with newer mesa
Philip is using or with OpenJDK Jens is using.

Regards,

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


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

Re: [oe] "krb" fails to build, suspect GCC bug

[Martin Jansa]

On Tue, Oct 27, 2015 at 11:26:32AM -0700, Khem Raj wrote:
> On Tue, Oct 27, 2015 at 11:21 AM, Martin Jansa  wrote:
> > On Sat, Sep 05, 2015 at 02:39:14PM +0200, Mike Looijmans wrote:
> >> I got this weird build failure from the "krb" package:
> >>
> >> | make[3]: Entering directory
> >> '/TOPDIR/build/tmp/work/mips32el-oe-linux/krb5/1.13.2-r0/krb5-1.13.2/src/lib/krb5/ccache'
> >> | mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32
> >> --sysroot=/TOPDIR/build/tmp/sysroots/formuler1 -fPIC -DSHARED
> >> -DHAVE_CONFIG_H  -I../../../include -I../../../include -I./ccapi -I. -I.
> >>   -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE  -Os -pipe -g
> >> -feliminate-unused-debug-types -DDESTRUCTOR_ATTR_WORKS=1
> >> -I/TOPDIR/build/tmp/sysroots/formuler1/usr/include/et -Wall -Wcast-align
> >> -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow
> >> -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes
> >> -Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function
> >> -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas
> >> -Wsign-compare -Werror=uninitialized -Werror=pointer-arith
> >> -Werror=declaration-after-statement
> >> -Werror-implicit-function-declaration -pthread -c cc_file.c -o
> >> cc_file.so.o && mv -f cc_file.so.o cc_file.so
> >> | cc_file.c: In function 'fcc_next_cred':
> >> | cc_file.c:368:9: error: 'maxsize' may be used uninitialized in this
> >> function [-Werror=maybe-uninitialized]
> >> |  ret = load_data(context, id, maxsize, buf);
> >> |  ^
> >> | cc_file.c:1091:12: note: 'maxsize' was declared here
> >> |  size_t maxsize;
> >> | ^
> >> | cc1: some warnings being treated as errors
> >>
> >> Looking at the source, this doesn't make any sense at all. The
> >> declaration of the variable isn't even in the same method body. And the
> >> line it complains about is about the fifth time it passes that variable
> >> to another method.
> >>
> >> And working around it by initializing maxsize=0 just makes the compiler
> >> choke on a similar situation elsewhere:
> >> | packet.c:50:67: error: 'id' may be used uninitialized in this function
> >>
> >>
> >> I suspect the problem here is GCC and not the krb code. Anyone seen this?
> >
> > I've seen it today in my world builds, It seems to fail only when building 
> > with -Os.
> >
> > I've seen similar issue in mdadm, also only with -Os.
> >
> 
> is this regression ? or seen for first time?

krb5 fails to build like this with -Os at least since dizzy

mdadm failure:
| raid6check.c: In function 'check_stripes':
| raid6check.c:315:8: error: 'stripe_buf' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
|   char *stripe_buf;
| ^
| cc1: all warnings being treated as errors
| make: *** [raid6check.o] Error 1
| ERROR: oe_runmake failed

is newer (seen only in Jethro builds).

But maybe only because this is built in do_compile_ptest_base and ptest
support was added in oe-core/jethro, it fails the same with gcc-5.2 and gcc-4.9.

> 
> > --
> > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
> >
> > --
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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

[oe] [meta-oe][PATCH] rrdtool: fix compile error

[Jens Rehsack]

Since cpan.bbclass has evolved, the old wrapper simulation needs some adoption.
Use as much as possible from cpan.bbclass instead of copying code from there.

Signed-off-by: Jens Rehsack 
---
 meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb 
b/meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb
index aba342b..7c75fab 100644
--- a/meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb
+++ b/meta-oe/recipes-extended/rrdtool/rrdtool_1.5.4.bb
@@ -15,7 +15,7 @@ SRC_URI = "\
 
 S = "${WORKDIR}/git"
 
-inherit autotools-brokensep gettext pythonnative perlnative python-dir 
cpan-base
+inherit cpan autotools-brokensep gettext pythonnative python-dir
 
 BBCLASSEXTEND = "native"
 
@@ -46,21 +46,13 @@ EXTRA_OECONF = " \
 --disable-rpath \
 "
 
-# don't use perl.real, this results in break issues with prebuilts since 
perl.real doesn't
-# know where the PERL5LIB is...
-# use wrapper perl instead
-EXTRA_OEMAKE = "PERL=${STAGING_BINDIR_NATIVE}/perl-native/perl 
FULLPERL=${STAGING_BINDIR_NATIVE}/perl-native/perl"
-
 export BUILD_SYS
 export HOST_SYS
 export STAGING_LIBDIR
 export STAGING_INCDIR
 
-# Env var which tells perl if it should use host (no) or target (yes) settings
-export PERLCONFIGTARGET = "${@is_target(d)}"
-export PERL_INC = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}/CORE"
-export PERL_LIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}"
-export PERL_ARCHLIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}"
+# emulate cpan_do_configure
+EXTRA_OEMAKE = ' PERL5LIB="${PERL_ARCHLIB}" '
 
 do_configure() {
 #fix the pkglib problem with newer automake
-- 
1.9.1

Error is here for a few days ... http://nopaste.linux-dev.org/?785761

-- 
Jens Rehsack - rehs...@gmail.com

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

Re: [oe] [meta-oe][PATCH] llvm: update 3.5.2 to have a sane ARM JIT for OpenJDK-8

[Jens Rehsack]

> Am 27.10.2015 um 21:24 schrieb Otavio Salvador 
> :
> 
> On Tue, Oct 27, 2015 at 6:21 PM, Jens Rehsack  wrote:
>> 
>>> Am 27.10.2015 um 21:15 schrieb Otavio Salvador 
>>> :
>>> 
>>> On Tue, Oct 27, 2015 at 6:04 PM, Jens Rehsack  wrote:
 
 llvm introduced new JIT technology MCJIT with llvm 3.4 and fixes ARM in 3.5
 (see 
 http://llvm.org/releases/3.5.2/docs/ReleaseNotes.html#changes-to-the-arm-backend).
 
 Ensure JIT is built with llvm
 
 Signed-off-by: Jens Rehsack 
>>> 
>>> There is a patch to add LLVM 3.7[1]; I think this one can be dropped.
>>> 
>>> 1. http://patchwork.openembedded.org/patch/106281/
>> 
>> I'v seen this and I guarantee that OpenJDK-8 will fail heavily with llvm3.7 
>> - the guys
>> put an end to an antiquated API's with each release, and OpenJDK's zeroshark 
>> uses lot's
>> of them.
> 
> So we will need to figure how to deal with this. I see following options:
> 
> - add needed llvm recipe in meta-java (I dislike this)
> - fix openjdk
> - update openjdk so it work with 3.7 (preferred)

I would prefer that, too - but we have to find a sponsor for that.

We also have the option to have an llvm3.5 for a while in meta-oe ;)

Cheers
-- 
Jens Rehsack - rehs...@gmail.com

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

Re: [oe] [meta-oe][PATCH] llvm: update 3.5.2 to have a sane ARM JIT for OpenJDK-8

[Jens Rehsack]

> Am 27.10.2015 um 21:32 schrieb Martin Jansa :
> 
> On Tue, Oct 27, 2015 at 06:24:52PM -0200, Otavio Salvador wrote:
>> On Tue, Oct 27, 2015 at 6:21 PM, Jens Rehsack  wrote:
>>> 
 Am 27.10.2015 um 21:15 schrieb Otavio Salvador 
 :
 
 On Tue, Oct 27, 2015 at 6:04 PM, Jens Rehsack  wrote:
> 
> llvm introduced new JIT technology MCJIT with llvm 3.4 and fixes ARM in 
> 3.5
> (see 
> http://llvm.org/releases/3.5.2/docs/ReleaseNotes.html#changes-to-the-arm-backend).
> 
> Ensure JIT is built with llvm
> 
> Signed-off-by: Jens Rehsack 
 
 There is a patch to add LLVM 3.7[1]; I think this one can be dropped.
 
 1. http://patchwork.openembedded.org/patch/106281/
>>> 
>>> I'v seen this and I guarantee that OpenJDK-8 will fail heavily with llvm3.7 
>>> - the guys
>>> put an end to an antiquated API's with each release, and OpenJDK's 
>>> zeroshark uses lot's
>>> of them.
>> 
>> So we will need to figure how to deal with this. I see following options:
>> 
>> - add needed llvm recipe in meta-java (I dislike this)
>> - fix openjdk
>> - update openjdk so it work with 3.7 (preferred)
> 
> I don't mind having all 3 llvm versions in parallel until all this is
> sorted out.
> 
> People can select the right one based on mesa version they are using and
> 3.8 for OpenJDK.
> 
> But I would appreciate this recipe rebased on top of Philip's (or vice
> versa), because I don't have spare time to text it with newer mesa
> Philip is using or with OpenJDK Jens is using.

Since OpenJDK waits for autoconf patch anyway, I'm happy to rebase my
patch when Philip's is in.

I'm also happy to try out how complex a move to 3.7 will be for openjdk-8 if
I find a tuit. I think, next week or so we'll make an initial decision
about our way to get a JVM with JIT support.

Cheers
-- 
Jens Rehsack - rehs...@gmail.com

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

Re: [oe] [meta-oe][PATCH] llvm: update 3.5.2 to have a sane ARM JIT for OpenJDK-8

[Philip Balister]

On 10/27/2015 01:21 PM, Jens Rehsack wrote:
> 
>> Am 27.10.2015 um 21:15 schrieb Otavio Salvador 
>> :
>>
>> On Tue, Oct 27, 2015 at 6:04 PM, Jens Rehsack  wrote:
>>>
>>> llvm introduced new JIT technology MCJIT with llvm 3.4 and fixes ARM in 3.5
>>> (see 
>>> http://llvm.org/releases/3.5.2/docs/ReleaseNotes.html#changes-to-the-arm-backend).
>>>
>>> Ensure JIT is built with llvm
>>>
>>> Signed-off-by: Jens Rehsack 
>>
>> There is a patch to add LLVM 3.7[1]; I think this one can be dropped.
>>
>> 1. http://patchwork.openembedded.org/patch/106281/
> 
> I'v seen this and I guarantee that OpenJDK-8 will fail heavily with llvm3.7 - 
> the guys
> put an end to an antiquated API's with each release, and OpenJDK's zeroshark 
> uses lot's
> of them.

We'll need the 3.7 series llvm to support llvmpipe in newer mesa. The
mesa update will happen after the release and I want to be ready.

As Martin notes, we are setup to support multiple llvm versions and it
looks like we need to.

Philip

> 
> Cheers
> 
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [PATCH][meta-oe] libx86-1: add the recipe

[rongqing.li]

From: Roy Li 

A library to provide support for making real-mode calls x86 calls. On
x86 hardware, vm86 mode is used. On other platforms, x86 emulation is
provided.

Signed-off-by: Roy Li 
---
 meta-oe/recipes-extended/libx86-1/libx86-1_1.1.bb | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 meta-oe/recipes-extended/libx86-1/libx86-1_1.1.bb

diff --git a/meta-oe/recipes-extended/libx86-1/libx86-1_1.1.bb 
b/meta-oe/recipes-extended/libx86-1/libx86-1_1.1.bb
new file mode 100644
index 000..7551e7d
--- /dev/null
+++ b/meta-oe/recipes-extended/libx86-1/libx86-1_1.1.bb
@@ -0,0 +1,20 @@
+SUMMARY = "x86 real-mode library"
+DESCRIPTION = "A library to provide support for making real-mode calls x86 
calls. On \
+x86 hardware, vm86 mode is used. On other platforms, x86 emulation is \
+provided."
+HOMEPAGE = "http://www.codon.org.uk/~mjg59/libx86/;
+LICENSE = "MIT & BSD-3-Clause"
+SECTION = "libs"
+LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=633af6c02e6f624d4c472d970a2aca53"
+
+SRC_URI = "http://www.codon.org.uk/~mjg59/libx86/downloads/${BPN}-${PV}.tar.gz;
+SRC_URI[md5sum] = "41bee1f8e22b82d82b5f7d7ba51abc2a"
+SRC_URI[sha256sum] = 
"5bf13104cb327472b5cb65643352a9138646becacc06763088d83001d832d048"
+
+BPN = "libx86"
+COMPATIBLE_HOST = '(x86_64|i.86).*-linux'
+
+export LIBDIR = "${libdir}"
+export BACKEND = "x86emu"
+
+inherit autotools-brokensep
-- 
1.9.1

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

[oe] [meta-oe][PATCH] lua5.1: Reintroduce and make it coexist with lua 5.3

[Khem Raj]

many modules still depend on lua5.1 and especially
luajit only supports 5.1 ABI as of now with no future
plans to move to later ABIs in sight.

This can now coexist with latest lua peacefully,
and also install a symlink to act default system wide
lua if someone choose to not install default lua ( 5.3 as of now)

Signed-off-by: Khem Raj 
---
 ...04-Fix-stack-overflow-in-vararg-functions.patch |  25 +
 .../lua/lua5.1/bitwise_operators.patch | 605 +
 meta-oe/recipes-devtools/lua/lua5.1/lua5.1.pc  |  11 +
 meta-oe/recipes-devtools/lua/lua5.1/luaorg_1.patch |  18 +
 meta-oe/recipes-devtools/lua/lua5.1/luaorg_2.patch |  44 ++
 .../lua/lua5.1/uclibc-pthread.patch|  13 +
 meta-oe/recipes-devtools/lua/lua5.1_5.1.5.bb   |  70 +++
 7 files changed, 786 insertions(+)
 create mode 100644 
meta-oe/recipes-devtools/lua/lua5.1/0004-Fix-stack-overflow-in-vararg-functions.patch
 create mode 100644 meta-oe/recipes-devtools/lua/lua5.1/bitwise_operators.patch
 create mode 100644 meta-oe/recipes-devtools/lua/lua5.1/lua5.1.pc
 create mode 100644 meta-oe/recipes-devtools/lua/lua5.1/luaorg_1.patch
 create mode 100644 meta-oe/recipes-devtools/lua/lua5.1/luaorg_2.patch
 create mode 100644 meta-oe/recipes-devtools/lua/lua5.1/uclibc-pthread.patch
 create mode 100644 meta-oe/recipes-devtools/lua/lua5.1_5.1.5.bb

diff --git 
a/meta-oe/recipes-devtools/lua/lua5.1/0004-Fix-stack-overflow-in-vararg-functions.patch
 
b/meta-oe/recipes-devtools/lua/lua5.1/0004-Fix-stack-overflow-in-vararg-functions.patch
new file mode 100644
index 000..b82eee4
--- /dev/null
+++ 
b/meta-oe/recipes-devtools/lua/lua5.1/0004-Fix-stack-overflow-in-vararg-functions.patch
@@ -0,0 +1,25 @@
+Upstream-Status: Backport
+
+Not needed in lua 5.3
+
+From: Enrico Tassi 
+Date: Tue, 26 Aug 2014 16:20:55 +0200
+Subject: Fix stack overflow in vararg functions
+
+---
+ src/ldo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/ldo.c b/src/ldo.c
+index d1bf786..30333bf 100644
+--- a/src/ldo.c
 b/src/ldo.c
+@@ -274,7 +274,7 @@ int luaD_precall (lua_State *L, StkId func, int nresults) {
+ CallInfo *ci;
+ StkId st, base;
+ Proto *p = cl->p;
+-luaD_checkstack(L, p->maxstacksize);
++luaD_checkstack(L, p->maxstacksize + p->numparams);
+ func = restorestack(L, funcr);
+ if (!p->is_vararg) {  /* no varargs? */
+   base = func + 1;
diff --git a/meta-oe/recipes-devtools/lua/lua5.1/bitwise_operators.patch 
b/meta-oe/recipes-devtools/lua/lua5.1/bitwise_operators.patch
new file mode 100644
index 000..4f0331e
--- /dev/null
+++ b/meta-oe/recipes-devtools/lua/lua5.1/bitwise_operators.patch
@@ -0,0 +1,605 @@
+diff -Nurd lua-5.1.5/src/lcode.c lua-5.1.5/src/lcode.c
+--- lua-5.1.5/src/lcode.c  2011-01-31 16:53:16.0 +0200
 lua-5.1.5/src/lcode.c  2012-11-28 21:12:23.958419501 +0200
+@@ -642,6 +642,17 @@
+ case OP_POW: r = luai_numpow(v1, v2); break;
+ case OP_UNM: r = luai_numunm(v1); break;
+ case OP_LEN: return 0;  /* no constant folding for 'len' */
++#if defined(LUA_BITWISE_OPERATORS)
++case OP_BOR: luai_logor(r, v1, v2); break;
++case OP_BAND: luai_logand(r, v1, v2); break;
++case OP_BXOR: luai_logxor(r, v1, v2);  break;
++case OP_BLSHFT: luai_loglshft(r, v1, v2); break;
++case OP_BRSHFT: luai_logrshft(r, v1, v2); break;
++case OP_BNOT: luai_lognot(r, v1); break;
++case OP_INTDIV:
++  if (v2 == 0) return 0;  /* do not attempt to divide by 0 */
++  r = luai_numintdiv(v1, v2); break;
++#endif
+ default: lua_assert(0); r = 0; break;
+   }
+   if (luai_numisnan(r)) return 0;  /* do not attempt to produce NaN */
+@@ -654,7 +665,11 @@
+   if (constfolding(op, e1, e2))
+ return;
+   else {
++#if defined(LUA_BITWISE_OPERATORS)
++int o2 = (op != OP_UNM && op != OP_LEN && op != OP_BNOT) ? 
luaK_exp2RK(fs, e2) : 0;
++#else
+ int o2 = (op != OP_UNM && op != OP_LEN) ? luaK_exp2RK(fs, e2) : 0;
++#endif
+ int o1 = luaK_exp2RK(fs, e1);
+ if (o1 > o2) {
+   freeexp(fs, e1);
+@@ -690,6 +705,14 @@
+   expdesc e2;
+   e2.t = e2.f = NO_JUMP; e2.k = VKNUM; e2.u.nval = 0;
+   switch (op) {
++#if defined(LUA_BITWISE_OPERATORS)
++case OPR_BNOT: {
++  if (e->k == VK)
++luaK_exp2anyreg(fs, e);  /* cannot operate on non-numeric constants */
++  codearith(fs, OP_BNOT, e, );
++  break;
++}
++#endif
+ case OPR_MINUS: {
+   if (!isnumeral(e))
+ luaK_exp2anyreg(fs, e);  /* cannot operate on non-numeric constants */
+@@ -770,6 +793,14 @@
+ case OPR_DIV: codearith(fs, OP_DIV, e1, e2); break;
+ case OPR_MOD: codearith(fs, OP_MOD, e1, e2); break;
+ case OPR_POW: codearith(fs, OP_POW, e1, e2); break;
++#if defined(LUA_BITWISE_OPERATORS)
++case OPR_BOR: codearith(fs, OP_BOR, e1, e2); break;
++case OPR_BAND: codearith(fs, OP_BAND, e1, e2); break;
++case OPR_BXOR: codearith(fs, OP_BXOR, e1, e2); break;

[oe] [PATCH][meta-oe] konkretcmpi: depend on swig-native

[Martin Jansa]

* otherwise it fails with:
  | CMake Error at 
sysroots/x86_64-linux/usr/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148
 (message):
  |   Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
* drop cmake-native, because it's already added by cmake.bbclass

Signed-off-by: Martin Jansa 
---
 meta-oe/recipes-extended/konkretcmpi/konkretcmpi_0.9.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-extended/konkretcmpi/konkretcmpi_0.9.2.bb 
b/meta-oe/recipes-extended/konkretcmpi/konkretcmpi_0.9.2.bb
index 5d016e7..1d8b0db 100644
--- a/meta-oe/recipes-extended/konkretcmpi/konkretcmpi_0.9.2.bb
+++ b/meta-oe/recipes-extended/konkretcmpi/konkretcmpi_0.9.2.bb
@@ -6,7 +6,7 @@ implementations for many of the provider operations."
 HOMEPAGE = "https://github.com/rnovacek/konkretcmpi;
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=f673270bfc350d9ce1efc8724c6c1873"
-DEPENDS = "swig sblim-cmpi-devel python cmake-native"
+DEPENDS = "swig-native sblim-cmpi-devel python"
 
 SRC_URI = "git://github.com/rnovacek/konkretcmpi.git \
file://konkretcmpi-0.9.2-fix-returning-instance-from-method.patch \
-- 
2.6.2

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