It's not necessary to specify the protocol parameter when it's the
default protocol for the fetcher, e.g. the default protocol for
git fetcher it git, "protocol=git" isn't needed.
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* fails without it:
| -- checking for module 'gstreamer-0.10'
| -- package 'gstreamer-0.10' not found
| -- checking for module 'gstreamer-base-0.10'
| -- package 'gstreamer-base-0.10' not found
| -- checking for module 'gstreamer-app-0.10'
| -- package 'gstreamer-app-0.10' not found
| -- checking for module 'gstreamer-audio-0.10'
| -- package 'gstreamer-audio-0.10' not found
| -- checking for module 'gstreamer-fft-0.10'
| -- package 'gstreamer-fft-0.10' not found
| -- checking for module 'gstreamer-interfaces-0.10'
| -- package 'gstreamer-interfaces-0.10' not found
| -- checking for module 'gstreamer-pbutils-0.10'
| -- package 'gstreamer-pbutils-0.10' not found
| -- checking for module 'gstreamer-video-0.10'
| -- package 'gstreamer-video-0.10' not found
| CMake Error at cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
| Could NOT find GStreamer (missing: GSTREAMER_INCLUDE_DIRS
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The examples apparently require compilation of .edc files to .edj
files using a program called edje_cc. I have no idea how the upstream
Makefile is supposed to work but it contains no such instructions and
errors out without this configure option.
Signed-off-by: Bob Ham <rah@settrans.net>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* harfbuzz is autodetected and can cause even edje_cc to fail,
this if from cpu.bb build:
| sysroots/x86_64-linux/usr/bin/edje_cc:
error while loading shared libraries: libharfbuzz.so.0: cannot open
shared object file: No such file or directory
| make[2]: *** [e-module-cpu.edj] Error 127
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* in preparation for merged source dir in efl.git I don't plan to support newer SRCREVs from subversion
* drop INC_PR and fold lib.inc into the recipe
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* to resolve following warning:
WARNING: lightmediascanner-0.4.4 is already registered as shlib provider for png.so, ignoring imlib2-loaders-1.4.5+svnr82070 trying to register the same
WARNING: lightmediascanner-0.4.4 is already registered as shlib provider for jpeg.so, ignoring imlib2-loaders-1.4.5+svnr82070 trying to register the same
WARNING: lightmediascanner-0.4.4 is already registered as shlib provider for id3.so, ignoring imlib2-loaders-1.4.5+svnr82070 trying to register the same
when fixes from https://bugzilla.yoctoproject.org/show_bug.cgi?id=4628
are included in build
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* efl and e17 modules are installed in different directories and nothing is going to
link with them -> no need to register them in shlibs providers
* see https://bugzilla.yoctoproject.org/show_bug.cgi?id=4628 for more
details about why this WARNING about multiple shlib providers was added
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* some builds were still failing to link DumpRenderTree
and nm revealed that another possible source of this reference is
CSSStyleSheet:
./src/lib/libwebcore_efl.so
U _ZNK7WebCore4Node10hasTagNameERKNS_13QualifiedNameE
./src/Source/WebCore/CMakeFiles/webcore_efl.dir/css/CSSStyleSheet.cpp.o
U _ZNK7WebCore4Node10hasTagNameERKNS_13QualifiedNameE
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Files enlightenment-0.17.2.1/ChangeLog and enlightenment-0.17.2.1-new/ChangeLog differ
Files enlightenment-0.17.2.1/NEWS and enlightenment-0.17.2.1-new/NEWS differ
Files enlightenment-0.17.2.1/po/ca.gmo and enlightenment-0.17.2.1-new/po/ca.gmo differ
Files enlightenment-0.17.2.1/po/ca.po and enlightenment-0.17.2.1-new/po/ca.po differ
Files enlightenment-0.17.2.1/po/eo.gmo and enlightenment-0.17.2.1-new/po/eo.gmo differ
Files enlightenment-0.17.2.1/po/eo.po and enlightenment-0.17.2.1-new/po/eo.po differ
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* This change is only aesthetic (unlike indentation in Python
tasks).
* Some recipes were using tabs.
* Some were using 8 spaces.
* Some were using mix or different number of spaces.
* Make them consistently use 4 spaces everywhere.
* Yocto styleguide advises to use tabs (but the only reason to keep
tabs is the need to update a lot of recipes). Lately this advice
was also merged into the styleguide on the OE wiki.
* Using 4 spaces in both types of tasks is better because it's less
error prone when someone is not sure if e.g.
do_generate_toolchain_file() is Python or shell task and also allows
to highlight every tab used in .bb, .inc, .bbappend, .bbclass as
potentially bad (shouldn't be used for indenting of multiline
variable assignments and cannot be used for Python tasks).
* Don't indent closing quote on multiline variables
we're quite inconsistent wheater it's first character on line
under opening quote or under first non-whitespace character in
previous line.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Acked-by: Koen Kooi <koen@dominion.thruhere.net>
Files old/evas-1.7.6.1/ChangeLog and new/evas-1.7.6.1/ChangeLog differ
Files old/evas-1.7.6.1/NEWS and new/evas-1.7.6.1/NEWS differ
Files old/evas-1.7.6.1/src/lib/engines/common/evas_font_ot.c and new/evas-1.7.6.1/src/lib/engines/common/evas_font_ot.c differ
Files old/evas-1.7.6.1/src/tests/evas_test_textblock.c and new/evas-1.7.6.1/src/tests/evas_test_textblock.c differ
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
| -- checking for module 'edbus>=1.1.0'
| -- package 'edbus>=1.1.0' not found
| -- checking for module 'eukit>=1.1.0'
| -- package 'eukit>=1.1.0' not found
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* edbus2 was merged in efl tree and moved to IN-EFL in r81826
there is important fix also in IN-EFL/edbus2
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Martin Jansa
Jackie Huang
Bob Ham
Paul Barker