* based on discussion in pndeprecated thread:
https://patchwork.openembedded.org/patch/137573/
update the messages to warn possible users that the
recipe will be removed before the end of the next development
cycle (before Yocto 2.4 is released).
* updated with:
sed -i 's/^\(PNBLACKLIST.*".*\)"/\1 - the recipe will be removed on 2017-09-01 unless the issue is fixed"/g' `git grep PNBLACKLIST | sed 's/:.*//g' | sort -u | xargs`
* then noticed couple recipes being blacklisted only based on
DISTRO_FEATURES, so removed those:
meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.17.bb
meta-oe/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb
meta-oe/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb
meta-oe/recipes-navigation/gypsy/gypsy.inc
meta-oe/recipes-navigation/navit/navit.inc
meta-oe/recipes-support/opensync/libsyncml_0.5.4.bb
* if it isn't fixed by this date, it's fair game to be removed
whenever someone gets around to i
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* I no longer use efl and don't plan to upgrade it to newer version
* someone else should step-up and start maintaining meta-efl
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Deleted bunch of patches which are not used anymore by any recipe.
Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Using ${PN} in URL's will get messed up in multi-lib configs, where
that can be expanded to things like lib32-${BPN}.
We should use ${BPN} instead.
Signed-off-by: Frederico Cadete <frederico.cadete@awtce.be>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* elementary doesn't seem to use poppler at all
* add PACKAGECONFIG for poppler in evas-generic-loaders and disable
it by default as ATM poppler is broken
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
They are no longer required to build python software.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
base_contains() is a compatibility wrapper and may warn in the future, so
replace all instances with bb.utils.contains().
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* 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>
* now it also fails to build again with;
webkit-efl/1_1.11.0-r0/ewebkit/Source/JavaScriptCore/profiler/ProfileNode.cpp:126:41: error: 'isnan' was not declared in this scope
adding cmath include could be enough, but this was last drop
of my patience
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Set CLEANBROKEN as the Makefile has no "clean" target.
Signed-off-by: Bob Ham <bob.ham@collabora.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* 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>
