* without this many recipes which use e.g. edje_cc fail after last openssl
upgrade in oe-core with:
| /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/edje_cc: /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/../../lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/libeet.so.1)
| /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/edje_cc: /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/../../lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/./libecore_con.so.1)
| /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/edje_cc: /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/././libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/./libecore_con.so.1)
| /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/edje_cc: /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/../../lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/./libemile.so.1)
| /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/edje_cc: /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/././libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/./libemile.so.1)
| make[4]: *** [modules/ethumb/emotion/template.edj] Error 1
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
* Using "cp -a" leaks UID of user running the builds, causing
many QA warnings.
* See this thread for details:
http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112904.html
Dropped Lua patch as no ptest support exists in jethro
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Conflicts:
meta-oe/recipes-devtools/lua/lua_5.3.1.bb
* optional dependency added to efl in:
commit 664708b817ab0cdc7177df3743b5d9c9ab7dd2b0
Author: Carsten Haitzler (Rasterman) <raster@rasterman.com>
Date: Tue May 5 11:35:16 2015 +0900
Subject: eina - start a much improved eina dbug infra and have eina_log use it
* fixes:
efl-1.15.1: edje rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-input-evas rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: eo rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: libeet rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: efreet-trash rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-ipc rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: eina rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-x rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: emotion rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-imf-evas rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: libemotion rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: efl rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-input rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-file rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ethumb rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-con rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: evas rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: efreet-mime rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: eeze rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: libefreet rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: embryo rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-evas rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-imf rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: ecore-audio rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: eldbus rdepends on libunwind, but it isn't a build dependency? [build-deps]
efl-1.15.1: eio rdepends on libunwind, but it isn't a build dependency? [build-deps]
enjoy-0.1.0+gitrAUTOINC+aa8fec69e8: enjoy rdepends on libunwind, but it isn't a build dependency? [build-deps]
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
We update "lightmediascanner" to its latest version,
which also allows us to :
- remove mentions of former company (now dissolved)
and website (now migrated to GitHub) ;
- properly split all plugins into subpackages ;
- have a new plugin based on libav, "generic", which
we do not automatically enable because of the well-known
licensing restrictions of its parent package.
MP4 plugin is disabled, because it depends on the MP4v2
library, which we do not have.
ID3 plugin requires a patch, already sent to upstream :
https://github.com/profusion/lightmediascanner/pull/19
meta-openembedded's only dependent recipe, "enjoy", has
been verified with this change.
Signed-off-by: Manuel Bachmann <manuel.bachmann@iot.bzh>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
At least meta-fsl-arm supports either x11 or wayland - not both at the same
time - for their gpu blobs. Selecting x11 only does not build wayland-egl and
efl's configuration fails with:
| checking whether to enable Wayland Egl rendering backend... yes
| configure: error: Wayland Egl dependencies not found
| Configure failed. The contents of all config.log files follows to aid debugging
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* they weren't migrated from E_SVN to git and updated in ages, I'm not interested
in maintaining them and nobody else volunteered to fix it
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Allow EFL to build with Wayland support.
Allow EFL to build with EGL support (when combined with
Wayland support, it effectively achieves GL acceleration
under a Wayland compositor).
Signed-off-by: Manuel Bachmann <manuel.bachmann@iot.bzh>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* gcc-5.2 introduces strict-overflow, parentheses, logical-not-parentheses
* there is no development in webkit-efl fork, so I'm not going to spend
time fixing them in source
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The epeg tool was originally developed in the efl project
and was replaced by the evas package in efl long ago. The old,
unmaintained source code of epeg is still available from
an efl legacy repository https://svn.enlightenment.org/svn/e/OLD/.
Updates and improvements to epeg have been developed and collected
in a new github repository. This patch deletes the deprecated
package from the efl project and introduces a new recipe
that installs the updated epeg tool.
In the license file, one copyright line has been added which
indicates the authors of the tool.
Moreover, in the license text, one sentence has been removed
which elaborated on what is meant by "making the source code
available publicly". However, the license still remains
an MIT style license.
Signed-off-by: Andreas Baak <andreas.baak@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Support i686 without needing to duplicate the i586 over-ride.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Support i686 without needing to duplicate the i586 over-ride.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
According to README, it depends on oe-core and openembedded-layer
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* as reported by Pieter, it's usually pulled through gstreamer1.0 which
is enabled by default, but when disable it can fail to find Xdamage.h
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
