The autobuilder picked up cairo having a dependency on glib-2.0. Added glib-2.0 to DEPENDS.
(From OE-Core rev: 65010151368c255bef7b2aefc47de48f658cf15b)
Signed-off-by: Beth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add more detailed SUMMARY and DESCRIPTIONS to various graphics and
graphics related components. I've recently gotten question from users
what something is, or why it was needed.. this should go a long way toward
answering those questions.
Many of the descriptions were taken directly from the upstream location,
where one was not available the Debian packages were consulted for
information.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
For these recipes the dependencies listed in RDEPENDS and RRECOMMENDS only apply to ${PN}
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
several chagnes are made:
- hardcoded_libtool.patch is removed, because the code (dolt logic) it
applys to have been removed. dolt is originally introduced to
accelerate libtool, it is later removed by commit 9de25a0297c due to
libtool is fast enough. so this patch can be removed too.
- explicitly specify the package name as libcairo2. In 1.8.10, the debian
rename hook (meta/classes/debian.bbclass:debian_package_name_hook )
will automatically rename the package to libcairo2. When upgrade to
1.10.0, the name changes to cairo, because the package contains not
only library, but also bin executable. This name change will cause
dependency failure to thos package which depends on libcairo-1.8.10.
so it is necessary to keep name as libcairo2 by explicitly specifing.
- specify extra package: libcairo-gobject2, libcairo-script-interpreter2
and cairo-perf-utils. it is newly added in 1.10.0. The name schema is
from Debian.
Signed-off-by: Yu Ke <ke.yu@intel.com>
Having one monolithic packages directory makes it hard to find things
and is generally overwhelming. This commit splits it into several
logical sections roughly based on function, recipes.txt gives more
information about the classifications used.
The opportunity is also used to switch from "packages" to "recipes"
as used in OpenEmbedded as the term "packages" can be confusing to
people and has many different meanings.
Not all recipes have been classified yet, this is just a first pass
at separating things out. Some packages are moved to meta-extras as
they're no longer actively used or maintained.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Beth Flanagan
Mark Hatle
Yu Ke
Koen Kooi
Saul Wold
Richard Purdie