[oe] [meta-qt5][PATCH] qtwebkit: add packageconfig for qtmultimedia
Signed-off-by: Jonathan Liu net...@gmail.com
---
recipes-qt/qt5/qtwebkit.inc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/recipes-qt/qt5/qtwebkit.inc b/recipes-qt/qt5/qtwebkit.inc
index 90bd981..a6322cb 100644
--- a/recipes-qt/qt5/qtwebkit.inc
+++ b/recipes-qt/qt5/qtwebkit.inc
@@ -7,10 +7,11 @@ LIC_FILES_CHKSUM =
file://Source/WebCore/rendering/RenderApplet.h;endline=22;md
DEPENDS += qtbase qtdeclarative icu ruby-native sqlite3 glib-2.0 libxslt
-PACKAGECONFIG ??= gstreamer qtlocation qtsensors
+PACKAGECONFIG ??= gstreamer qtlocation qtmultimedia qtsensors
PACKAGECONFIG[gstreamer] = ,,gstreamer1.0 gstreamer1.0-plugins-base
PACKAGECONFIG[gstreamer010] = ,,gstreamer gst-plugins-base
PACKAGECONFIG[qtlocation] = ,,qtlocation
+PACKAGECONFIG[qtmultimedia] = ,,qtmultimedia
PACKAGECONFIG[qtsensors] = ,,qtsensors
do_configure_prepend() {
@@ -20,6 +21,8 @@ do_configure_prepend() {
sed -e 's/\s\(packagesExist(.*\gstreamer-0.10\.*)\)/
OE_GSTREAMER010_ENABLED:\1/' -i ${S}/Tools/qmake/mkspecs/features/features.prf
# disable qtlocation test if it isn't enabled by PACKAGECONFIG
sed -e 's/\s\(qtHaveModule(positioning)\)/ OE_QTLOCATION_ENABLED:\1/' -i
${S}/Tools/qmake/mkspecs/features/features.prf
+# disable qtmultimedia test if it isn't enabled by PACKAGECONFIG
+sed -e
's/(video):\(qtHaveModule(multimediawidgets)\)/(video):OE_QTMULTIMEDIA_ENABLED:\1/'
-i ${S}/Tools/qmake/mkspecs/features/features.prf
# disable qtsensors test if it isn't enabled by PACKAGECONFIG
sed -e 's/\s\(qtHaveModule(sensors)\)/ OE_QTSENSORS_ENABLED:\1/' -i
${S}/Tools/qmake/mkspecs/features/features.prf
}
@@ -27,6 +30,7 @@ do_configure_prepend() {
EXTRA_QMAKEVARS_PRE += ${@base_contains('PACKAGECONFIG', 'gstreamer',
'CONFIG+=OE_GSTREAMER_ENABLED', '', d)}
EXTRA_QMAKEVARS_PRE += ${@base_contains('PACKAGECONFIG', 'gstreamer010',
'CONFIG+=OE_GSTREAMER010_ENABLED', '', d)}
EXTRA_QMAKEVARS_PRE += ${@base_contains('PACKAGECONFIG', 'qtlocation',
'CONFIG+=OE_QTLOCATION_ENABLED', '', d)}
+EXTRA_QMAKEVARS_PRE += ${@base_contains('PACKAGECONFIG', 'qtmultimedia',
'CONFIG+=OE_QTMULTIMEDIA_ENABLED', '', d)}
EXTRA_QMAKEVARS_PRE += ${@base_contains('PACKAGECONFIG', 'qtsensors',
'CONFIG+=OE_QTSENSORS_ENABLED', '', d)}
# qtwebkit gets terribly big when linking with all debug info, disable by
default
--
1.9.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Quality of meta-oe metadata
On 30 March 2014 02:31, Martin Jansa martin.ja...@gmail.com wrote: Hi, sorry for longer e-mail, this is one of topic I would like to discuss on OEDAM (http://openembedded.org/wiki/OEDAM), but having some feedback and thoughts in advance will be very useful. As people can notice from my State of bitbake world e-mails or http://www.openembedded.org/wiki/Bitbake_World_Status we never had green builds. There are always 20+ failed tasks in those big builds and just reading the numbers isn't good indicator of quality, because sooner you break something in dependency tree, fewer recipes will be actually tested, so fewer failed tasks often means that something important is broken. There are IMHO at least 3 reasons for this depressing state: 1) Nobody is paid/dedicated to fix them, there is no company behind meta-oe layers, now SWAT team, not even dedicated maintainers to which I could send error from latest build and ask them to fix it before the end of week/month. Kudos to people who are sometimes sending patches for such issues! 2) There are a lot of changes and component upgrades in oe-core which sometimes aren't very straight-forward to adapt to and issues stay in meta-oe for months. I don't mean it's oe-core fault or that changes to oe-core should slow down just because meta-oe, especially when we cannot guarantee when it will be prepared for them (because of 1)). oe-core is trying to track latest stable versions, but meta-oe often contains very old versions and people upgrade to latest stable only the recipes they really care about, so it's not so surprising that 2 year old version of something isn't compatible with latest greatest freetype or some library like that. 3) OE releases work great and don't invalidate sstate signatures so often, so my feeling is that most developers and projects are just using releases and less and less people do CI. People will start complaining that something is broken in meta-oe only when they are upgrading their project from 1.5 to 1.6 when 1.6 is released and that could be too late for fixing meta-oe issues. What I'm trying to do with it: a) sending those e-mails and updating wiki, so that people can easily find if some build failure is common or something which happens only for them (something like oestats-client.bbclass page was providing in oe-classic) It also includes log of QA issues which are usually easy to fix and great way for new people to learn something about OE. b) trying to refuse all patches which cause new world issue (or new QA warn/err) - sometimes missed in logs, because it's often hidden by some other issue and hard to compare 40 issues from previous build with 38 from current. Also the issues are often triggered later by changes somewhere else... c) fixing build/qa issues in recipes I've never used or don't even have hardware to test - just based on assumption that something which builds is better than broken build, even when it can have some issues in runtime. d) contacting people who added the recipe which is now failing, often without reply for months even when I try it multiple times :/ e) moving to nonworking directory to mark it as known-to-be-broken, last resort for recipes where the fix is complicated and it's not known if someone is actually using it (because it was broken for months and nobody replied). + easy to find them, because they are still in repository (instead of git rm + revert when someone fixes it) - layer index probably doesn't find them, because nonworking directory level isn't in BBFILES, so maybe meta-broken or meta-nonworking would be better ? some recipes are broken just because their dependency is broken, what to do with such recipe, I usually just say that in commit message when I'm moving them to nonworking with their broken dep. What can we do better? How to motivate more people to do CI and send fixes? When we get to green state it will be easier to quickly spot new issues and easier to fix them, because it will be clear what's causing them. Are you discussing meta-oe alone here or all layers in meta-openembedded? I've got a few ideas thinking slightly outside the box, so these may or may not be workable: - It might help to try to split the layers down further and reduce the size of meta-oe (for example, create a meta-python layer for all the python libraries that aren't direct dependencies of something non-python in meta-oe) and then try get new maintainers for these sub-layers so that the workload is spread better. - We could create a new layer for unstable recipes which are 'use at your own risk'. That may be a good place for recipes which don't work on the jenkins builds but do work for some people and are in use (and so probably don't belong in nonworking). This is similar to the meta-broken or
Re: [oe] [OE-core] Quality of meta-oe metadata
On Sun, Mar 30, 2014 at 03:48:09PM +0100, Paul Barker wrote: Are you discussing meta-oe alone here or all layers in meta-openembedded? basically all of the layers which are included in my world builds, so it includes all layers in meta-openembedded, most from meta-smartphone, meta-browser, meta-qt5.. I've got a few ideas thinking slightly outside the box, so these may or may not be workable: - It might help to try to split the layers down further and reduce the size of meta-oe (for example, create a meta-python layer for all the python libraries that aren't direct dependencies of something non-python in meta-oe) and then try get new maintainers for these sub-layers so that the workload is spread better. Agreed I would be happy to accept patches creating meta-python layer, ideally sent by someone who will volunteer to maintain it. - We could create a new layer for unstable recipes which are 'use at your own risk'. That may be a good place for recipes which don't work on the jenkins builds but do work for some people and are in use (and so probably don't belong in nonworking). This is similar to the meta-broken or meta-nonworking layer idea but would take slightly more recipes in. The difference between meta-broken and meta-unstable from my POV is that, broken should be just temporary place and someone should eventually fix it, but if we move stuff to meta-unstable and stop testing it, then I fear that it will became just junkyard. If some recipe works fine for someone when building for arm, but triggers jenkins/world build issues for x86* then lets restrict it only for arm with comment which shows the error - that's better than moving it to broken or unstable. - It may be worth taking some aggressive action in sync with the upcoming oe-core release to get us to a green build, possibly by throwing things into meta-nonworking and meta-unstable layers. That may break a few people's builds, but the fix for them should just be to add the meta-unstable layer. If they're building against the master branch that should be tolerable and it won't affect anyone building from a released/stable branch until the next oe-core release in 6 months time. Once we have a green build it'll be much easier to QA patches and reject those which break the build. you mean being aggressive before or after creating the next-release branch? I would prefer to be aggressive before to have green builds in release branch. I don't have much time to give to fixing this myself as I'm busy with other projects. I do have idle computer time though so could run an automated build regularly (probably just a script and a cron job rather than buildbot/jenkins/etc). I won't be able to do a world build for every layer for multiple machines, but I should be able to do some subset. I may also be able to commandeer a spare server over the next few weeks. Is there any particular config which would be beneficial to build regularly? Doing big builds in different setups is of course useful, but right now I think we already have more logs than what we're processing. So I think that building not whole world, but those recipes which are regularly failing would be good start, if people cannot reproduce some issues which are shown in my jenkins builds we should compare the builds and narrow possible reasons (e.g. failing only with dash, failing only with some PACKAGECONFIG enabled or disabled). I'm trying to stay close to distroless config, but some tweaks are needed in order to have bigger test coverage (e.g. enabling some PACKAGECONFIGs which are disabled by default, but something requires them, or changing P_V to newer again because something else needs it, enabling gold, because it's more strict so it can catch more issues..) Jenkins builds are running almost non-stop (because it usually takes around 24 hours per architecture), so often when I want to debug the issue directly on that server in WORKDIR where it failed it's already gone from tmpfs and the workspace is already blocked by next build. 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] [OE-core] initial support for musl libc with OE/Yocto Project
On 30 March 2014 05:17, Khem Raj raj.k...@gmail.com wrote: On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker p...@paulbarker.me.uk wrote: On 26 March 2014 22:12, Burton, Ross ross.bur...@intel.com wrote: On 26 March 2014 22:04, Khem Raj raj.k...@gmail.com wrote: There were interest in other threads in having musl as an alternative to eglibc/uclibc that we already have in OE, in that direction I have poured in my on and off work and put it into a contrib tree Blimey Khem that was quick. :) Agreed! I wonder if it's worth splitting this out into its own layer though I thought about it and since class/conf changes that need to go in into OE-core first I kept it as it is (lazyness too). I think once the core support is available in OE-core we can spin the recipes into a layer of its own. (with fixes done via bbappends) so that it's easy for multiple people to contribute to. It would also mean it doesn't need rebasing onto master all the time. I'd definitely like to get involved with this. In particular I can ensure opkg (both current release and development branch) work with musl and see if some of my preferred software from meta-oe will build (vim, htop, etc). start with what we have. Once master opens up I would propose the needed changes to OE-core and spin a layer I did a quick 'bitbake -k core-image-minimal' to see what's currently failing. Full logs and config at http://www.paulbarker.me.uk/musl-build/ Build Configuration: BB_VERSION= 1.21.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-12.04 TARGET_SYS= arm-oe-linux-musleabi MACHINE = qemuarm DISTRO= nodistro DISTRO_VERSION= nodistro.0 TUNE_FEATURES = armv5 thumb dsp TARGET_FPU= soft meta = kraj/musl:faafa7022ed057d55c131c456d1bdd5dfa3d2517 Summary: 6 tasks failed: openembedded-core/meta/recipes-support/attr/attr_2.4.47.bb, do_compile openembedded-core/meta/recipes-devtools/python/python_2.7.3.bb, do_compile openembedded-core/meta/recipes-core/util-linux/util-linux_2.24.1.bb, do_compile openembedded-core/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb, do_compile openembedded-core/meta/recipes-core/busybox/busybox_1.22.1.bb, do_compile openembedded-core/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb, do_compile I can see for util-linux that we need to implement qsort_r(). Busybox probably just needs config changes: http://wiki.musl-libc.org/wiki/Building_Busybox glib is getting confused as both musl and libiconv provide iconv.h as warned: WARNING: The recipe libiconv is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/pbarker/musl-build/build/tmp-musl/sysroots/qemuarm/usr/include/iconv.h Matched in manifest-qemuarm-musl.populate_sysroot Please verify which package should provide the above files. We also have: WARNING: The recipe gettext is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/pbarker/musl-build/build/tmp-musl/sysroots/qemuarm/usr/include/libintl.h Matched in manifest-qemuarm-musl.populate_sysroot Please verify which package should provide the above files. WARNING: QA Issue: gettext: Files/directories were installed but not shipped /usr/lib/charset.alias Hope this helps, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Quality of meta-oe metadata
On 30 March 2014 16:14, Martin Jansa martin.ja...@gmail.com wrote: On Sun, Mar 30, 2014 at 03:48:09PM +0100, Paul Barker wrote: - We could create a new layer for unstable recipes which are 'use at your own risk'. That may be a good place for recipes which don't work on the jenkins builds but do work for some people and are in use (and so probably don't belong in nonworking). This is similar to the meta-broken or meta-nonworking layer idea but would take slightly more recipes in. The difference between meta-broken and meta-unstable from my POV is that, broken should be just temporary place and someone should eventually fix it, but if we move stuff to meta-unstable and stop testing it, then I fear that it will became just junkyard. If some recipe works fine for someone when building for arm, but triggers jenkins/world build issues for x86* then lets restrict it only for arm with comment which shows the error - that's better than moving it to broken or unstable. I agree with the worry that this could turn into a junkyard. The problem is, the junk is currently mixed in with the good recipes. - It may be worth taking some aggressive action in sync with the upcoming oe-core release to get us to a green build, possibly by throwing things into meta-nonworking and meta-unstable layers. That may break a few people's builds, but the fix for them should just be to add the meta-unstable layer. If they're building against the master branch that should be tolerable and it won't affect anyone building from a released/stable branch until the next oe-core release in 6 months time. Once we have a green build it'll be much easier to QA patches and reject those which break the build. you mean being aggressive before or after creating the next-release branch? I would prefer to be aggressive before to have green builds in release branch. That would probably make more sense. I don't have much time to give to fixing this myself as I'm busy with other projects. I do have idle computer time though so could run an automated build regularly (probably just a script and a cron job rather than buildbot/jenkins/etc). I won't be able to do a world build for every layer for multiple machines, but I should be able to do some subset. I may also be able to commandeer a spare server over the next few weeks. Is there any particular config which would be beneficial to build regularly? Doing big builds in different setups is of course useful, but right now I think we already have more logs than what we're processing. So I think that building not whole world, but those recipes which are regularly failing would be good start, if people cannot reproduce some issues which are shown in my jenkins builds we should compare the builds and narrow possible reasons (e.g. failing only with dash, failing only with some PACKAGECONFIG enabled or disabled). I'm trying to stay close to distroless config, but some tweaks are needed in order to have bigger test coverage (e.g. enabling some PACKAGECONFIGs which are disabled by default, but something requires them, or changing P_V to newer again because something else needs it, enabling gold, because it's more strict so it can catch more issues..) Jenkins builds are running almost non-stop (because it usually takes around 24 hours per architecture), so often when I want to debug the issue directly on that server in WORKDIR where it failed it's already gone from tmpfs and the workspace is already blocked by next build. Having a more focussed build would help but I can't really give any ability to debug it on the machine I run builds on and I don't really have time to debug much myself. It would literally just be a status and a set of logs for a different config. I think we need to prioritise what needs fixing first. I think doing a build of meta-oe only with no PACKAGECONFIG changes, disabling anything that requires PACKAGECONFIG changes, for qemuarm and qemux86 (and qemux86_64 if I have time) would be a good start to see what fails in that case. Then step out to further layers once meta-oe is green. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Quality of meta-oe metadata
On 30 March 2014 02:31, Martin Jansa martin.ja...@gmail.com wrote: There are always 20+ failed tasks in those big builds and just reading the numbers isn't good indicator of quality, because sooner you break something in dependency tree, fewer recipes will be actually tested, so fewer failed tasks often means that something important is broken. Sorry to double reply but had a thought on this one thing in particular. Is there any way to list recipes (or tasks) which weren't executed because a dependency failed? I know we see this at the start of the build if dependencies can't be satisfied, I'm thinking tasks with satisfied dependencies but then those dependencies fail. Being able to see that chain for each build may help us prioritise. It would also show whether a failure disappearing was due to the issue being fixed or the recipe no longer being attempted due to a new failure somewhere else. Thanks, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker p...@paulbarker.me.uk wrote: On 30 March 2014 05:17, Khem Raj raj.k...@gmail.com wrote: On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker p...@paulbarker.me.uk wrote: On 26 March 2014 22:12, Burton, Ross ross.bur...@intel.com wrote: On 26 March 2014 22:04, Khem Raj raj.k...@gmail.com wrote: There were interest in other threads in having musl as an alternative to eglibc/uclibc that we already have in OE, in that direction I have poured in my on and off work and put it into a contrib tree Blimey Khem that was quick. :) Agreed! I wonder if it's worth splitting this out into its own layer though I thought about it and since class/conf changes that need to go in into OE-core first I kept it as it is (lazyness too). I think once the core support is available in OE-core we can spin the recipes into a layer of its own. (with fixes done via bbappends) so that it's easy for multiple people to contribute to. It would also mean it doesn't need rebasing onto master all the time. I'd definitely like to get involved with this. In particular I can ensure opkg (both current release and development branch) work with musl and see if some of my preferred software from meta-oe will build (vim, htop, etc). start with what we have. Once master opens up I would propose the needed changes to OE-core and spin a layer I did a quick 'bitbake -k core-image-minimal' to see what's currently failing. Full logs and config at http://www.paulbarker.me.uk/musl-build/ Build Configuration: BB_VERSION= 1.21.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-12.04 TARGET_SYS= arm-oe-linux-musleabi MACHINE = qemuarm DISTRO= nodistro DISTRO_VERSION= nodistro.0 TUNE_FEATURES = armv5 thumb dsp TARGET_FPU= soft meta = kraj/musl:faafa7022ed057d55c131c456d1bdd5dfa3d2517 Summary: 6 tasks failed: openembedded-core/meta/recipes-support/attr/attr_2.4.47.bb, do_compile openembedded-core/meta/recipes-devtools/python/python_2.7.3.bb, do_compile openembedded-core/meta/recipes-core/util-linux/util-linux_2.24.1.bb, do_compile openembedded-core/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb, do_compile openembedded-core/meta/recipes-core/busybox/busybox_1.22.1.bb, do_compile openembedded-core/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb, do_compile I can see for util-linux that we need to implement qsort_r(). Busybox probably just needs config changes: http://wiki.musl-libc.org/wiki/Building_Busybox I already have local fix for busy box. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] xfconfig: use sysroot and target perl
On 12/07/13 17:29, Ulf Samuelsson wrote:
xfconf-4.10.0 does not use OE sysroot as is.
--with-sysroot=yes
will make configure run CC --print-sysroot
and use that.
Signed-off-by: Ulf Samuelsson u...@emagii.com
---
meta-xfce/recipes-xfce/xfconf/xfconf_4.10.0.bb |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta-xfce/recipes-xfce/xfconf/xfconf_4.10.0.bb
b/meta-xfce/recipes-xfce/xfconf/xfconf_4.10.0.bb
index 4ea2b88..6d5bf57 100644
--- a/meta-xfce/recipes-xfce/xfconf/xfconf_4.10.0.bb
+++ b/meta-xfce/recipes-xfce/xfconf/xfconf_4.10.0.bb
@@ -2,10 +2,14 @@ DESCRIPTION = Xfce configuration daemon and utilities
SECTION = x11/wm
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552
-DEPENDS = dbus-glib libxfce4util perl-native
+DEPENDS = dbus-glib libxfce4util perl
+PR=r1
inherit xfce
+EXTRA_OECONF += PERL=${STAGING_DIR_TARGET}/usr/bin/perl
+EXTRA_OECONF += --with-sysroot=yes
+
SRC_URI += file://0001-Simplify-checks.patch
SRC_URI[md5sum] = 4ed48150a03fb5f42b455494307b7f28
SRC_URI[sha256sum] =
175219a441cc7d0f210bbd1a3b0abba41598627cd9db27235811400c3e100576
This patch is causing the build to emit a QA warning:
xfconf-4.10.0: xfconf: configure was passed unrecognised options: --with-sysroot
Is this really the right option to supply for what you're trying to do?
http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20140329_001343.log/qa.log
On my machine this package builds with this option (--with-sysroot)
removed, but I realize that testing on one machine is probably not
sufficient.
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v5 2/2] packagegroup-qt5-toolchain-target: include all modules for development
On 13/03/2014 1:01 PM, Otavio Salvador wrote:
Hello,
On Wed, Mar 12, 2014 at 7:52 PM, Jonathan Liu net...@gmail.com wrote:
This adds the necessary target packages for development with all of the
Qt 5 modules.
Signed-off-by: Jonathan Liu net...@gmail.com
| Computing transaction...error: Can't install
qtwayland-dev-5.2.1+git0+573d0ee5ba-r0.0@cortexa9hf_vfp_neon: no
package provides qtwayland = 5.2.1+git0+573d0ee5ba-r0.0
|
| Saving cache...
|
| WARNING:
/home/otavio/hacking/customer/companytec/yocto/build/tmp/work/wandboard_solo-oel-linux-gnueabi/qsiv-demo-image/1.0-r0/temp/run.populate_sdk_image.29400:1
exit 1 from
| smart --data-dir=${target_rootfs}/var/lib/smart install -y
${pkgs_to_install}
| DEBUG: Python function do_populate_sdk finished
| ERROR: Function failed: populate_sdk_image (log file is located at
/home/otavio/hacking/customer/companytec/yocto/build/tmp/work/wandboard_solo-oel-linux-gnueabi/qsiv-demo-image/1.0-r0/temp/lo
Please fix this and test the combinations of enable/disable features.
They seem not well tested.
It looks like qtwayland is not being built properly in your configration.
Can you provide configuration and steps to reproduce this failure?
I have not had any luck in reproducing it.
Regards,
Jonathan
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-gnome][PATCH] libgnomecanvas: add 'intltool-native' DEPENDS
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org --- meta-gnome/recipes-gnome/libgnome/libgnomecanvas_2.30.3.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-gnome/recipes-gnome/libgnome/libgnomecanvas_2.30.3.bb b/meta-gnome/recipes-gnome/libgnome/libgnomecanvas_2.30.3.bb index 4a210a4..0f41bb6 100644 --- a/meta-gnome/recipes-gnome/libgnome/libgnomecanvas_2.30.3.bb +++ b/meta-gnome/recipes-gnome/libgnome/libgnomecanvas_2.30.3.bb @@ -5,7 +5,7 @@ SECTION = x11/gnome/libs inherit gnome -DEPENDS = gtk+ libglade libart-lgpl xineramaproto +DEPENDS = gtk+ libglade libart-lgpl xineramaproto intltool-native SRC_URI[archive.md5sum] = ffcbb719c671ff5cd86e59aeba8d0b92 SRC_URI[archive.sha256sum] = 859b78e08489fce4d5c15c676fec1cd79782f115f516e8ad8bed6abcb8dedd40 -- 1.9.0 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] gnuplot: upgrade to 4.6.5
From: Tim Orling ticot...@gmail.com
* automake patch from 4.4.4 is no longer needed
* PACKAGECONFIG for lua (lua term is only useful for LaTeX)
* linking problems with dlopen, etc. in lua loadlibs.c fixed
** this same problem was seen in jansa world builds for 4.4.4
** I am not able to replicate that error on 4.4.4
NOTE: qt is supported by this version, but I was not able to
figure out the configuration...
Signed-off-by: Tim Orling ticot...@gmail.com
---
.../gnuplot/gnuplot-4.4.4/automake-1.12.x.patch| 44 --
.../lua-loadlibs-configure-in-fix.patch| 16
.../{gnuplot-4.4.4 = gnuplot-4.6.5}/subdirs.patch | 0
meta-oe/recipes-extended/gnuplot/gnuplot.inc | 1 +
.../gnuplot/{gnuplot_4.4.4.bb = gnuplot_4.6.5.bb} | 8 ++--
5 files changed, 20 insertions(+), 49 deletions(-)
delete mode 100644
meta-oe/recipes-extended/gnuplot/gnuplot-4.4.4/automake-1.12.x.patch
create mode 100644
meta-oe/recipes-extended/gnuplot/gnuplot-4.6.5/lua-loadlibs-configure-in-fix.patch
rename meta-oe/recipes-extended/gnuplot/{gnuplot-4.4.4 =
gnuplot-4.6.5}/subdirs.patch (100%)
rename meta-oe/recipes-extended/gnuplot/{gnuplot_4.4.4.bb = gnuplot_4.6.5.bb}
(66%)
diff --git
a/meta-oe/recipes-extended/gnuplot/gnuplot-4.4.4/automake-1.12.x.patch
b/meta-oe/recipes-extended/gnuplot/gnuplot-4.4.4/automake-1.12.x.patch
deleted file mode 100644
index 51f703c..000
--- a/meta-oe/recipes-extended/gnuplot/gnuplot-4.4.4/automake-1.12.x.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-Upstream-Status: Backport
-
-It's fixed in 4.6 and 4.7(HEAD)
-
-http://sourceforge.net/tracker/?func=detailaid=3523591group_id=2055atid=102055
-
-diff -uNr gnuplot-4.4.4.orig/Makefile.am gnuplot-4.4.4/Makefile.am
gnuplot-4.4.4.orig/Makefile.am 2012-07-20 10:54:49.075828905 +0200
-+++ gnuplot-4.4.4/Makefile.am 2012-07-20 10:55:22.380831313 +0200
-@@ -1,5 +1,5 @@
- ## Process this file with automake to produce Makefile.in -*-Makefile-*-
--AUTOMAKE_OPTIONS = foreign 1.2h
-+AUTOMAKE_OPTIONS = foreign
-
- SUBDIRS = config m4 term src $(LISPDIR) man share
-
-diff -uNr gnuplot-4.4.4.orig/configure.in gnuplot-4.4.4/configure.in
gnuplot-4.4.4.orig/configure.in2011-09-02 06:09:40.0 +0200
-+++ gnuplot-4.4.4/configure.in 2012-07-20 10:55:53.289833224 +0200
-@@ -16,10 +16,11 @@
- dnl configure.in body
-
- dnl Compiler characteristics
--dnl Check for ANSI C prototypes, the const and inline keywords,
--dnl and ANSI style stringification
-+dnl Check for the const and inline keywords and ANSI style stringification
-+dnl automake 1.12 dropped support for AM_C_PROTOTYPES and ansi2knr
-+dnl But our code still tests for #ifdef PROTOTYPES, so define it here
-+AC_DEFINE(PROTOTYPES,1,[Automake 1.12 dropped support for building without
prototypes])
- AC_PROG_CC
--AM_C_PROTOTYPES
- AC_PROG_CPP
- AC_C_CONST
- AC_C_INLINE
-diff -uNr gnuplot-4.4.4.orig/src/Makefile.am gnuplot-4.4.4/src/Makefile.am
gnuplot-4.4.4.orig/src/Makefile.am 2010-10-06 06:53:16.0 +0200
-+++ gnuplot-4.4.4/src/Makefile.am 2012-07-20 10:56:02.376834548 +0200
-@@ -1,5 +1,5 @@
- ## Process this file with automake to produce Makefile.in -*-Makefile-*-
--AUTOMAKE_OPTIONS = ansi2knr foreign 1.2h
-+AUTOMAKE_OPTIONS = foreign
-
- # in the spirit of automake ...
- pkglibexecdir = $(libexecdir)/@PACKAGE@/@VERSION_MAJOR@
diff --git
a/meta-oe/recipes-extended/gnuplot/gnuplot-4.6.5/lua-loadlibs-configure-in-fix.patch
b/meta-oe/recipes-extended/gnuplot/gnuplot-4.6.5/lua-loadlibs-configure-in-fix.patch
new file mode 100644
index 000..23f2cd2
--- /dev/null
+++
b/meta-oe/recipes-extended/gnuplot/gnuplot-4.6.5/lua-loadlibs-configure-in-fix.patch
@@ -0,0 +1,16 @@
+Index: gnuplot-4.6.5/configure.in
+===
+--- gnuplot-4.6.5.orig/configure.in
gnuplot-4.6.5/configure.in
+@@ -690,6 +690,11 @@ if test ${with_lua} = yes ; then
+ fi
+
+ if test $with_lua != no; then
++dnl check for dlopen/dl to fix loadlibs link failure
++AC_CHECK_FUNC([dlopen], [],
++ AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS=-ldl))
++AC_SUBST(DLOPEN_LIBS)
++LUA_LIBS=$LUA_LIBS $DLOPEN_LIBS
+ TERMLIBS=$TERMLIBS $LUA_LIBS
+ CPPFLAGS=$CPPFLAGS $LUA_CFLAGS
+ else
diff --git a/meta-oe/recipes-extended/gnuplot/gnuplot-4.4.4/subdirs.patch
b/meta-oe/recipes-extended/gnuplot/gnuplot-4.6.5/subdirs.patch
similarity index 100%
rename from meta-oe/recipes-extended/gnuplot/gnuplot-4.4.4/subdirs.patch
rename to meta-oe/recipes-extended/gnuplot/gnuplot-4.6.5/subdirs.patch
diff --git a/meta-oe/recipes-extended/gnuplot/gnuplot.inc
b/meta-oe/recipes-extended/gnuplot/gnuplot.inc
index 96d6ee2..ab3ec3f 100644
--- a/meta-oe/recipes-extended/gnuplot/gnuplot.inc
+++ b/meta-oe/recipes-extended/gnuplot/gnuplot.inc
@@ -12,6 +12,7 @@ acpaths =
PACKAGECONFIG ??= cairo
PACKAGECONFIG[cairo] = --with-cairo,--without-cairo,cairo pango
+PACKAGECONFIG[lua] = --with-lua,--without-lua,lua
Re: [oe] [meta-perl][PATCH v2 01/10] libmodule-metadata-perl: add 1.000019
Yes. It updates the version built into perl. I will submit a patch with
insane skip.
--Tim
On Sun, Feb 2, 2014 at 10:51 PM, Tim Orling ticot...@gmail.com wrote:
[Description from CPAN]
This module provides a standard way to gather metadata about a .pm file
through (mostly) static analysis and (some) code execution. When
determining the version of a module, the $VERSION assignment is evaled,
as is traditional in the CPAN toolchain.
Signed-off-by: Tim Orling ticot...@gmail.com
---
.../libmodule/libmodule-metadata-perl_1.19.bb | 33
1 file changed, 33 insertions(+)
create mode 100644 meta-perl/recipes-perl/libmodule/
libmodule-metadata-perl_1.19.bb
diff --git a/meta-perl/recipes-perl/libmodule/
libmodule-metadata-perl_1.19.bb b/meta-perl/recipes-perl/libmodule/
libmodule-metadata-perl_1.19.bb
new file mode 100644
index 000..668f0c4
--- /dev/null
+++ b/meta-perl/recipes-perl/libmodule/libmodule-metadata-perl_1.19.bb
@@ -0,0 +1,33 @@
+SUMMARY = Module::Metadata - Gather package and POD information from
perl module files
+DESCRIPTION = This module provides a standard way to gather metadata
about \
+a .pm files through (mostly) static analysis and (some) code execution.
When \
+determining the version of a module, the $VERSION assignment is eval-ed,
as \
+is traditional in the CPAN toolchain.
+SECTION = libs
+
+HOMEPAGE = http://search.cpan.org/~ether/Module-Metadata/;
+
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM =
file://README;beginline=185;endline=190;md5=e1b24eebe5d819b40bb68ad06b72d3ee
+
+SRC_URI =
http://search.cpan.org/CPAN/authors/id/E/ET/ETHER/Module-Metadata-${PV}.tar.gz
+SRC_URI[md5sum] = 838ecf97f7daff79e0f81e104a6be823
+SRC_URI[sha256sum] =
5afca94dc0213608101ad519eb1b25133cdc9e44c2a053a45a5a59422c2ee554
+
+S = ${WORKDIR}/Module-Metadata-${PV}
+
+inherit cpan
+
+RDEPENDS_${PN} = perl-module-io-file \
+ perl-module-data-dumper \
+ perl-module-extutils-makemaker \
+ perl-module-file-spec \
+ perl-module-version \
+ perl-module-exporter \
+ perl-module-carp \
+ perl-module-test-more \
+ perl-module-file-temp \
+ perl-module-file-path \
+
+
+BBCLASSEXTEND = native
--
1.7.9.5
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] utouch-evemu: force serial build
My build always fails if allowed to build in parallel:
| make[2]: *** No rule to make target `evemu-record.1', needed by `all-am'.
Stop.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
meta-oe/recipes-support/utouch/utouch-evemu_git.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-oe/recipes-support/utouch/utouch-evemu_git.bb
b/meta-oe/recipes-support/utouch/utouch-evemu_git.bb
index 0efe79e..1dd5a86 100644
--- a/meta-oe/recipes-support/utouch/utouch-evemu_git.bb
+++ b/meta-oe/recipes-support/utouch/utouch-evemu_git.bb
@@ -13,3 +13,5 @@ SRCREV = 9752b50e922572e4cd214ac45ed95e4ee410fe24
PV = 1.0.5+git${SRCPV}
S = ${WORKDIR}/git/
+
+PARALLEL_MAKE =
--
1.9.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-perl][PATCH v2 08/10] libmodule-build-tiny-perl: add 0.030
On 03/31/2014 11:35 AM, Tim Orling wrote:
Yes, -perl is missing. Didn't quite fix the Debian-izing of that
recipe :)
I will submit a patch.
--Tim
BTW, I did not create the info for the Readme for the layer. With
these 10 recipes, about 14 more I have in the wings and about 80 I am
working on that Paul has pointed me to (from Emil), that Readme is
going to get VERY long. Do we want to maintain the practice or ...?
Don't get me wrong, it is helpful.
Yes, any README for the practice is welcomed, there is a README in
meta-perl/,
if yours is very long, you could put it in the involved recipes dir or
summarize it to take an simple example to add to meta-perl/README.
//Hongxu
On Fri, Mar 28, 2014 at 11:24 PM, Hongxu Jia hongxu@windriver.com
mailto:hongxu@windriver.com wrote:
On 02/03/2014 02:51 PM, Tim Orling wrote:
[Description from CPAN]
Many Perl distributions use a Build.PL file instead of a
Makefile.PL file to drive distribution configuration, build,
test and
installation. Traditionally, Build.PL uses Module::Build as
the underlying
build system. This module provides a simple, lightweight,
drop-in replacement.
Signed-off-by: Tim Orling ticot...@gmail.com
mailto:ticot...@gmail.com
---
.../libmodule/libmodule-build-tiny-perl_0.030.bb
http://libmodule-build-tiny-perl_0.030.bb | 54
1 file changed, 54 insertions(+)
create mode 100644
meta-perl/recipes-perl/libmodule/libmodule-build-tiny-perl_0.030.bb
http://libmodule-build-tiny-perl_0.030.bb
diff --git
a/meta-perl/recipes-perl/libmodule/libmodule-build-tiny-perl_0.030.bb
http://libmodule-build-tiny-perl_0.030.bb
b/meta-perl/recipes-perl/libmodule/libmodule-build-tiny-perl_0.030.bb
http://libmodule-build-tiny-perl_0.030.bb
new file mode 100644
index 000..fadd9c7
--- /dev/null
+++
b/meta-perl/recipes-perl/libmodule/libmodule-build-tiny-perl_0.030.bb
http://libmodule-build-tiny-perl_0.030.bb
@@ -0,0 +1,54 @@
+SUMMARY = Module::Build::Tiny - A tiny replacement for
Module::Build
+DESCRIPTION = Many Perl distributions use a Build.PL file
instead of a \
+Makefile.PL file to drive distribution configuration, build,
test and \
+installation. Traditionally, Build.PL uses Module::Build as
the underlying \
+build system. This module provides a simple, lightweight,
drop-in replacement. \
+Whereas Module::Build has over 6,700 lines of code; this
module has less than \
+120, yet supports the features needed by most distributions.
+SECTION = libs
+
+HOMEPAGE = http://search.cpan.org/~leont/Module-Build-Tiny/
http://search.cpan.org/%7Eleont/Module-Build-Tiny/
+
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM =
file://LICENSE;md5=aaca61412962cf972aec0cdad99d0a84
+
+DEPENDS = libextutils-config-native
libextutils-helpers-native libextutils-installpaths-native
+
Hi Tim,
Not found 'libextutils-config-native libextutils-helpers-native
libextutils-installpaths-native',
Is '*-perl-*' missing ?
$ bitbake libmodule-build-tiny-perl
Loading cache: 100%
|#|
ETA: 00:00:00
Loaded 1243 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'libextutils-config-native' (but
/home/jiahongxu/yocto/meta-openembedded/meta-perl/recipes-perl/libmodule/libmodule-build-tiny-perl_0.030.bb
http://libmodule-build-tiny-perl_0.030.bb DEPENDS on or
otherwise requires it). Close matches:
libextutils-config-perl-native
libextutils-config-perl
libextutils-cppguess-perl-native
ERROR: Required build target 'libmodule-build-tiny-perl' has no
buildable providers.
Missing or unbuildable dependency chain was:
['libmodule-build-tiny-perl', 'libextutils-config-native']
Hi Paul Tim,
Sorry for the late reply, the inaccurate email fillter
rules caused me missing the meta-perl mail, I have fixed it,
and put them as prior.
//Hongxu
+SRC_URI =
http://search.cpan.org/CPAN/authors/id/L/LE/LEONT/Module-Build-Tiny-${PV}.tar.gz
http://search.cpan.org/CPAN/authors/id/L/LE/LEONT/Module-Build-Tiny-$%7BPV%7D.tar.gz
+SRC_URI[md5sum] = 1c54bf4c602eec87f98950314699402e
+SRC_URI[sha256sum] =
dfd418ad0e8290cf645ab11be209a1bf6865e5a562c5a1592da99d5fd24718a8
+
+S = ${WORKDIR}/Module-Build-Tiny-${PV}
+
+inherit cpan_build
+
+do_install () {
+
