[OE-core] [PATCH 4/4] multilib.bbclass: add "pkg_postinst" and "pkg_postrm" as renaming elements
Add "pkg_postinst" and "pkg_postrm" as renaming elements, which fixes
missing post install/rm scripts in target image.
Signed-off-by: Dongxiao Xu
---
meta/classes/multilib.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 46c24e1..5976d5d 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -73,7 +73,7 @@ python __anonymous () {
d.setVar("PACKAGES", " ".join([row[1] for row in pkgs_mapping]))
for pkg_mapping in pkgs_mapping:
-for subs in ["FILES", "RDEPENDS", "RRECOMMENDS", "SUMMARY",
"DESCRIPTION", "RSUGGESTS", "RPROVIDES", "RCONFLICTS", "PKG", "ALLOW_EMPTY"]:
+for subs in ["FILES", "RDEPENDS", "RRECOMMENDS", "SUMMARY",
"DESCRIPTION", "RSUGGESTS", "RPROVIDES", "RCONFLICTS", "PKG", "ALLOW_EMPTY",
"pkg_postinst", "pkg_postrm"]:
d.renameVar("%s_%s" % (subs, pkg_mapping[0]), "%s_%s" % (subs,
pkg_mapping[1]))
map_dependencies("DEPENDS", d)
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] base-passwd: Use BPN in FILES paths
Use BPN instead of PN in FILES paths.
This fixes the login issue by /etc/passwd missing in multilib images.
Signed-off-by: Dongxiao Xu
---
.../recipes-core/base-passwd/base-passwd_3.5.22.bb | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb
b/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb
index a155b41..137512d 100644
--- a/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb
+++ b/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb
@@ -30,11 +30,11 @@ do_install () {
install -o root -g root -p -m 644 passwd.master
${D}${datadir}/base-passwd/
install -o root -g root -p -m 644 group.master
${D}${datadir}/base-passwd/
- install -d -m 755 ${D}${docdir}/${PN}
- install -p -m 644 debian/changelog ${D}${docdir}/${PN}/
- gzip -9 ${D}${docdir}/${PN}/*
- install -p -m 644 README ${D}${docdir}/${PN}/
- install -p -m 644 debian/copyright ${D}${docdir}/${PN}/
+ install -d -m 755 ${D}${docdir}/${BPN}
+ install -p -m 644 debian/changelog ${D}${docdir}/${BPN}/
+ gzip -9 ${D}${docdir}/${BPN}/*
+ install -p -m 644 README ${D}${docdir}/${BPN}/
+ install -p -m 644 debian/copyright ${D}${docdir}/${BPN}/
}
pkg_postinst_${PN} () {
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4][PULL] multilib: various fixes related with login, postinst, etc
Hi Richard, This pull request contains several multilib fixes addressing issues like login failure, missing postinst scripts, missing package files, etc. Please help to review and pull. Thanks, Dongxiao The following changes since commit 81aa4bfbde871af1d569b64499c34a315bf6218e: classes/sanity: enhance the network connectivity test (2011-08-25 08:49:12 -0700) are available in the git repository at: git://git.pokylinux.org/poky-contrib dxu4/ml http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/ml Dongxiao Xu (4): base-passwd: Use BPN in FILES paths bitbake.conf: Use BPN in FILES paths multilib.bbclass: Fix renaming logic for "FILES_", "RDEPENDS_", etc multilib.bbclass: add "pkg_postinst" and "pkg_postrm" as renaming elements meta/classes/multilib.bbclass | 18 -- meta/conf/bitbake.conf |4 ++-- .../recipes-core/base-passwd/base-passwd_3.5.22.bb | 10 +- 3 files changed, 15 insertions(+), 17 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] bitbake.conf: Use BPN in FILES paths
Use BPN instead of PN in FILES path to support multilib.
Signed-off-by: Dongxiao Xu
---
meta/conf/bitbake.conf |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index b309516..2a77483 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -261,7 +261,7 @@ FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/*
${libdir}/lib*${SOLIBS}
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* \
${base_libdir}/*${SOLIBS} \
-${datadir}/${PN} ${libdir}/${PN}/* \
+${datadir}/${BPN} ${libdir}/${BPN}/* \
${datadir}/pixmaps ${datadir}/applications \
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
${libdir}/bonobo/servers"
@@ -282,7 +282,7 @@ SECTION_${PN}-staticdev = "devel"
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
DOTDEBUG-dbg = "${bindir}/.debug ${sbindir}/.debug ${libexecdir}/.debug
${libdir}/.debug \
-${base_bindir}/.debug ${base_sbindir}/.debug ${base_libdir}/.debug
${libdir}/${PN}/.debug \
+${base_bindir}/.debug ${base_sbindir}/.debug ${base_libdir}/.debug
${libdir}/${BPN}/.debug \
${libdir}/matchbox-panel/.debug /usr/src/debug"
DEBUGFILEDIRECTORY-dbg = "/usr/lib/debug /usr/src/debug"
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] multilib.bbclass: Fix renaming logic for "FILES_", "RDEPENDS_", etc
In the orignal logic, the renaming will not work for "FILES_" if defined
variables as:
PACKAGES = "${PN}"
FILES_abc = "/usr/include/abc.h"
It is because ${PN} is "lib64-abc" so it will not be contained in
pkgrename.
This commit enumerates all element in PACKAGES, getting the original
packages and multilib packages, then doing renaming for "FILES_",
"RDEPENDS_", etc. This fixes a lot of missing files and incorrect
dependencies.
Signed-off-by: Dongxiao Xu
---
meta/classes/multilib.bbclass | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 571b7be..46c24e1 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -63,20 +63,18 @@ python __anonymous () {
newvar.append(extend_name(v))
d.setVar(varname, " ".join(newvar))
-pkgs = []
-pkgrename = {}
+pkgs_mapping = []
for pkg in (d.getVar("PACKAGES", True) or "").split():
if pkg.startswith(variant):
-pkgs.append(pkg)
+pkgs_mapping.append([pkg.split(variant + "-")[1], pkg])
continue
-pkgrename[pkg] = extend_name(pkg)
-pkgs.append(pkgrename[pkg])
+pkgs_mapping.append([pkg, extend_name(pkg)])
-if pkgrename:
-d.setVar("PACKAGES", " ".join(pkgs))
-for pkg in pkgrename:
-for subs in ["FILES", "RDEPENDS", "RRECOMMENDS", "SUMMARY",
"DESCRIPTION", "RSUGGESTS", "RPROVIDES", "RCONFLICTS", "PKG", "ALLOW_EMPTY"]:
-d.renameVar("%s_%s" % (subs, pkg), "%s_%s" % (subs,
pkgrename[pkg]))
+d.setVar("PACKAGES", " ".join([row[1] for row in pkgs_mapping]))
+
+for pkg_mapping in pkgs_mapping:
+for subs in ["FILES", "RDEPENDS", "RRECOMMENDS", "SUMMARY",
"DESCRIPTION", "RSUGGESTS", "RPROVIDES", "RCONFLICTS", "PKG", "ALLOW_EMPTY"]:
+d.renameVar("%s_%s" % (subs, pkg_mapping[0]), "%s_%s" % (subs,
pkg_mapping[1]))
map_dependencies("DEPENDS", d)
for pkg in (d.getVar("PACKAGES", True).split() + [""]):
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] how to use AUTOREV for a SVN repo in oe-core?
Hello,
I'm trying to figure out how AUTOREV is supposed to work these days
with oe-core. In the past, I would do something like:
SRCREV = "${AUTOREV}"
PV = "1.0+svnr${SRCREV}"
in my custom application recipes to always build the head of a SVN repo.
In OE classic, we have:
SRCPV = "${@bb.fetch.get_srcrev(d)}"
AUTOREV = "${SRCPV}"
In oe-core, we have:
AUTOREV = "${@bb.fetch2.get_autorev(d)}"
SRCPV = "${@bb.fetch2.get_srcrev(d)}"
in bitbake, we have:
def get_autorev(d):
# only not cache src rev in autorev case
if bb.data.getVar('BB_SRCREV_POLICY', d, True) != "cache":
bb.data.setVar('__BB_DONT_CACHE', '1', d)
return "AUTOINC"
def get_srcrev(d):
"""
Return the version string for the current package
(usually to be used as PV)
Most packages usually only have one SCM so we just pass on the call.
In the multi SCM case, we build a value based on SRCREV_FORMAT which must
have been set.
"""
scms = []
fetcher = Fetch(
Therefore, I get package names like the following with oe-core:
svs_1.0+svnrAUTOINC-r4_armv5te.ipk
In the OE classic days, AUTOINC would be replaced with the SVN revision.
And if I check in new changes to the SVN project, it does not rebuild.
What is the recommended way to create a recipe that always builds the
tip of source in a SVN repo?
Its interesting there is a change in oe-core from Feb 13 that switched
from fetch to fetch2:
commit a26163b8f5fc682e6ee4d597e5dd487485b180f5
Author: Saul Wold
Date: Sun Feb 13 23:57:59 2011 -0800
bitbake.conf: change revision fetching to use newer fetch2 code
Signed-off-by: Saul Wold
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index da50fe5..162c792 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -560,8 +560,8 @@ UPDATECOMMAND_cvs = "/usr/bin/env cvs -d${CVSROOT}
update -d -P ${CVSCOOPTS}"
UPDATECOMMAND_svn = "/usr/bin/env svn update ${SVNCOOPTS}"
SRCDATE = "${DATE}"
SRCREV = "INVALID"
-AUTOREV = "${@bb.fetch.get_autorev(d)}"
-SRCPV = "${@bb.fetch.get_srcrev(d)}"
+AUTOREV = "${@bb.fetch2.get_autorev(d)}"
+SRCPV = "${@bb.fetch2.get_srcrev(d)}"
SRC_URI = "file://${FILE}"
and the corresponding functions in fetch are:
def get_autorev(d):
return get_srcrev(d)
def get_srcrev(d):
So, before the above change, I would expect the OE classic behavior in oe-core.
Thanks,
Cliff
--
=
http://bec-systems.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] new feature? (for "DL_DIR")
I found that: for every vcs (e.g. git) package, except a directory in "git" or "git2", there is another file "*.tar.gz" in the downloads dir. but for my own package, e.g linux 2.6.35 for i.mx28, only the directory under "git2", I can't found the tar.gz file in downloads, why? On Fri, 2011-08-26 at 10:27 +0800, 倪庆亮 wrote: > thanks again, I have setup an internal package server (http), and the > client can use it in poky. > > but I have another problem for git svn( for the .gz .bz2 package, no > problem), the source code of the packages using git/svn/hg are > directories in the server, does the client can use it??? > > On Mon, 2011-08-22 at 15:56 +0800, 倪庆亮 wrote: > > Do we can assign all package be downloaded from the same path? > > > > I want setup one internal server to store the files in upstreamsources, > > and all developer's PC use it but not the original package address. > > > > -- > > Yi Qingliang > > 倪庆亮 > > > > Insigma > > > > > > -- > Yi Qingliang > 倪庆亮 > > Insigma > > -- Yi Qingliang 倪庆亮 Insigma ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] new feature? (for "DL_DIR")
thanks again, I have setup an internal package server (http), and the client can use it in poky. but I have another problem for git svn( for the .gz .bz2 package, no problem), the source code of the packages using git/svn/hg are directories in the server, does the client can use it??? On Mon, 2011-08-22 at 15:56 +0800, 倪庆亮 wrote: > Do we can assign all package be downloaded from the same path? > > I want setup one internal server to store the files in upstreamsources, > and all developer's PC use it but not the original package address. > > -- > Yi Qingliang > 倪庆亮 > > Insigma > > -- Yi Qingliang 倪庆亮 Insigma ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [OC-core][PATCH 1/1] qt4e-demo-image: Fix bug 999
From: Xiaofeng Yan
[YOCTO #999]
Copy metadata of qt4e-demo-image from OE for easy testing qt4embeded on
embedded platform.
This image was tested on qemuarm and can run program "qtdemoE".
Signed-off-by: Xiaofeng Yan
---
meta/recipes-qt/images/qt4e-demo-image.bb | 19 ++
meta/recipes-qt/tasks/task-qt4e.bb| 56 +
2 files changed, 75 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-qt/images/qt4e-demo-image.bb
create mode 100644 meta/recipes-qt/tasks/task-qt4e.bb
diff --git a/meta/recipes-qt/images/qt4e-demo-image.bb
b/meta/recipes-qt/images/qt4e-demo-image.bb
new file mode 100644
index 000..f2150ca
--- /dev/null
+++ b/meta/recipes-qt/images/qt4e-demo-image.bb
@@ -0,0 +1,19 @@
+LICENSE = "MIT"
+PR="r1"
+
+LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
+
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+DEPENDS += "task-qt4e"
+
+RDEPENDS_${PN} += " \
+ task-qt4e-base \
+ "
+
+IMAGE_INSTALL += "\
+ module-init-tools \
+ task-qt4e-base \
+"
+
+inherit core-image
+
diff --git a/meta/recipes-qt/tasks/task-qt4e.bb
b/meta/recipes-qt/tasks/task-qt4e.bb
new file mode 100644
index 000..c95c898
--- /dev/null
+++ b/meta/recipes-qt/tasks/task-qt4e.bb
@@ -0,0 +1,56 @@
+DESCRIPTION = "QT4 Embedded base Image Feed"
+PR = "r1"
+LICENSE = "MIT"
+
+LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
+
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+inherit task
+
+TOUCH = ' ${@base_contains("MACHINE_FEATURES", "touchscreen", "tslib
tslib-calibrate tslib-tests", "",d)}'
+
+PACKAGES += " \
+ ${PN}-base \
+"
+
+RDEPENDS_${PN}-base = " \
+ qt4-embedded \
+ libqt-embedded3support4 \
+ libqt-embeddedclucene4 \
+ libqt-embeddedcore4 \
+ libqt-embeddeddbus4 \
+ libqt-embeddedgui4 \
+ libqt-embeddedhelp4 \
+ libqt-embeddedmultimedia4 \
+ libqt-embeddednetwork4 \
+ libqt-embeddedscript4 \
+ libqt-embeddedscripttools4 \
+ libqt-embeddedsql4 \
+ libqt-embeddedsvg4 \
+ libqt-embeddedtest4 \
+ libqt-embeddedwebkit4 \
+ libqt-embeddedxml4 \
+ qt4-embedded-fonts-ttf-dejavu \
+ qt4-embedded-fonts-ttf-vera \
+ qt4-embedded-plugin-iconengine-svgicon \
+ qt4-embedded-plugin-imageformat-gif \
+ qt4-embedded-plugin-imageformat-ico \
+ qt4-embedded-plugin-imageformat-jpeg \
+ qt4-embedded-plugin-imageformat-mng \
+ qt4-embedded-plugin-imageformat-svg \
+ qt4-embedded-plugin-imageformat-tiff \
+ qt4-embedded-plugin-mousedriver-tslib \
+ qt4-embedded-plugin-phonon-backend-gstreamer \
+ qt4-embedded-plugin-script-dbus \
+ qt4-embedded-plugin-sqldriver-sqlite \
+ ${TOUCH} \
+qt4-embedded-demos \
+qt4-embedded-examples \
+qt-demo-init \
+qt4-embedded-assistant \
+"
+
+RRECOMMENDS_${PN}-base = " \
+ libqt-embeddedxmlpatterns4 \
+"
+
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] qt4e-demo-image: Fix bug 999
From: Xiaofeng Yan Hi Saul & Paul, I merged qt4e-base-image.bb to qt4e-demoo-image.bb according to your suggestion. If you have any suggestion, I will modify them again. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: xiaofeng/qt4e-demo-image Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/qt4e-demo-image Thanks, Xiaofeng Yan --- Xiaofeng Yan (1): qt4e-demo-image: Fix bug 999 meta/recipes-qt/images/qt4e-demo-image.bb | 19 ++ meta/recipes-qt/tasks/task-qt4e.bb| 56 + 2 files changed, 75 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-qt/images/qt4e-demo-image.bb create mode 100644 meta/recipes-qt/tasks/task-qt4e.bb ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [meta-ti PATCH 4/4] libgnomeprint: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
.../recipes-gnome/gnome/libgnomeprint_2.18.7.bb| 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
create mode 100644 meta-gnome/recipes-gnome/gnome/libgnomeprint_2.18.7.bb
diff --git a/meta-gnome/recipes-gnome/gnome/libgnomeprint_2.18.7.bb
b/meta-gnome/recipes-gnome/gnome/libgnomeprint_2.18.7.bb
new file mode 100644
index 000..57e7910
--- /dev/null
+++ b/meta-gnome/recipes-gnome/gnome/libgnomeprint_2.18.7.bb
@@ -0,0 +1,15 @@
+LICENSE = "GPL"
+SECTION = "x11/gnome/libs"
+
+DEPENDS = "libxml2 libgnomecups glib-2.0 pango libart-lgpl fontconfig popt
gnome-common"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+inherit pkgconfig gnome
+
+SRC_URI[archive.md5sum] = "d66b81ee8aa3b3a33f5efc9a47ce07e3"
+SRC_URI[archive.sha256sum] =
"8b34f81599423ef3da9c43775495da602f83cbbee069c9e760ffeae6aa4768e6"
+
+FILES_${PN}-dbg += "${libdir}/libgnomeprint/${PV}/modules/transports/.debug \
+ ${libdir}/libgnomeprint/${PV}/modules/.debug
${libdir}/libgnomeprint/${PV}/modules/*/.debug"
+
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [meta-ti PATCH 2/4] gtksourceview: Imported from OE classic
* Added LIC_FILES_CHKSUM
* Added virtual/gettext to DEPENDS
Signed-off-by: Joel A Fernandes
---
.../recipes-gnome/gtksourceview/files/acinclude.m4 | 90 ++
.../recipes-gnome/gtksourceview/files/gtk-doc.m4 | 53 ++
.../recipes-gnome/gtksourceview/files/gtk-doc.make | 173
.../gtksourceview/gtksourceview2_2.10.0.bb | 29
4 files changed, 345 insertions(+), 0 deletions(-)
create mode 100644 meta-gnome/recipes-gnome/gtksourceview/files/acinclude.m4
create mode 100644 meta-gnome/recipes-gnome/gtksourceview/files/gtk-doc.m4
create mode 100644 meta-gnome/recipes-gnome/gtksourceview/files/gtk-doc.make
create mode 100644
meta-gnome/recipes-gnome/gtksourceview/gtksourceview2_2.10.0.bb
diff --git a/meta-gnome/recipes-gnome/gtksourceview/files/acinclude.m4
b/meta-gnome/recipes-gnome/gtksourceview/files/acinclude.m4
new file mode 100644
index 000..53518fb
--- /dev/null
+++ b/meta-gnome/recipes-gnome/gtksourceview/files/acinclude.m4
@@ -0,0 +1,90 @@
+## this one is commonly used with AM_PATH_PYTHONDIR ...
+dnl AM_CHECK_PYMOD(MODNAME [,SYMBOL [,ACTION-IF-FOUND [,ACTION-IF-NOT-FOUND]]])
+dnl Check if a module containing a given symbol is visible to python.
+AC_DEFUN(AM_CHECK_PYMOD,
+[AC_REQUIRE([AM_PATH_PYTHON])
+py_mod_var=`echo $1['_']$2 | sed 'y%./+-%__p_%'`
+AC_MSG_CHECKING(for ifelse([$2],[],,[$2 in ])python module $1)
+AC_CACHE_VAL(py_cv_mod_$py_mod_var, [
+ifelse([$2],[], [prog="
+import sys
+try:
+import $1
+except ImportError:
+sys.exit(1)
+except:
+sys.exit(0)
+sys.exit(0)"], [prog="
+import $1
+$1.$2"])
+if $PYTHON -c "$prog" 1>&AC_FD_CC 2>&AC_FD_CC
+ then
+eval "py_cv_mod_$py_mod_var=yes"
+ else
+eval "py_cv_mod_$py_mod_var=no"
+ fi
+])
+py_val=`eval "echo \`echo '$py_cv_mod_'$py_mod_var\`"`
+if test "x$py_val" != xno; then
+ AC_MSG_RESULT(yes)
+ ifelse([$3], [],, [$3
+])dnl
+else
+ AC_MSG_RESULT(no)
+ ifelse([$4], [],, [$4
+])dnl
+fi
+])
+
+dnl a macro to check for ability to create python extensions
+dnl AM_CHECK_PYTHON_HEADERS([ACTION-IF-POSSIBLE], [ACTION-IF-NOT-POSSIBLE])
+dnl function also defines PYTHON_INCLUDES
+AC_DEFUN([AM_CHECK_PYTHON_HEADERS],
+[AC_REQUIRE([AM_PATH_PYTHON])
+AC_MSG_CHECKING(for headers required to compile python extensions)
+dnl deduce PYTHON_INCLUDES
+AC_ARG_WITH(python-includes,
+ [ --with-python-includes=DIR path to Python includes],
py_exec_prefix=$withval)
+if test x$py_exec_prefix != x; then
+PYTHON_INCLUDES="-I${py_exec_prefix}/include/python${PYTHON_VERSION}"
+else
+py_prefix=`$PYTHON -c "import sys; print sys.prefix"`
+py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"`
+PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
+if test "$py_prefix" != "$py_exec_prefix"; then
+ PYTHON_INCLUDES="$PYTHON_INCLUDES
-I${py_exec_prefix}/include/python${PYTHON_VERSION}"
+fi
+fi
+AC_SUBST(PYTHON_INCLUDES)
+dnl check if the headers exist:
+save_CPPFLAGS="$CPPFLAGS"
+CPPFLAGS="$CPPFLAGS $PYTHON_INCLUDES"
+AC_TRY_CPP([#include ],dnl
+[AC_MSG_RESULT(found)
+$1],dnl
+[AC_MSG_RESULT(not found)
+$2])
+CPPFLAGS="$save_CPPFLAGS"
+])
+
+dnl
+dnl JH_ADD_CFLAG(FLAG)
+dnl checks whether the C compiler supports the given flag, and if so, adds
+dnl it to $CFLAGS. If the flag is already present in the list, then the
+dnl check is not performed.
+AC_DEFUN([JH_ADD_CFLAG],
+[
+case " $CFLAGS " in
+*@<:@\ \ @:>@$1@<:@\ \ @:>@*)
+ ;;
+*)
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS $1"
+ AC_MSG_CHECKING([whether [$]CC understands $1])
+ AC_TRY_COMPILE([], [], [jh_has_option=yes], [jh_has_option=no])
+ AC_MSG_RESULT($jh_has_option)
+ if test $jh_has_option = no; then
+CFLAGS="$save_CFLAGS"
+ fi
+ ;;
+esac])
diff --git a/meta-gnome/recipes-gnome/gtksourceview/files/gtk-doc.m4
b/meta-gnome/recipes-gnome/gtksourceview/files/gtk-doc.m4
new file mode 100644
index 000..3ec4166
--- /dev/null
+++ b/meta-gnome/recipes-gnome/gtksourceview/files/gtk-doc.m4
@@ -0,0 +1,53 @@
+dnl -*- mode: autoconf -*-
+
+# serial 1
+
+dnl Usage:
+dnl GTK_DOC_CHECK([minimum-gtk-doc-version])
+AC_DEFUN([GTK_DOC_CHECK],
+[
+ AC_BEFORE([AC_PROG_LIBTOOL],[$0])dnl setup libtool first
+ AC_BEFORE([AM_PROG_LIBTOOL],[$0])dnl setup libtool first
+ dnl for overriding the documentation installation directory
+ AC_ARG_WITH(html-dir,
+AC_HELP_STRING([--with-html-dir=PATH], [path to installed docs]),,
+[with_html_dir='${datadir}/gtk-doc/html'])
+ HTML_DIR="$with_html_dir"
+ AC_SUBST(HTML_DIR)
+
+ dnl enable/disable documentation building
+ AC_ARG_ENABLE(gtk-doc,
+AC_HELP_STRING([--enable-gtk-doc],
+ [use gtk-doc to build documentation [default=no]]),,
+enable_gtk_doc=no)
+
+ have_gtk_doc=no
+ if test -z "$PKG_CONFIG"; then
+AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
+ fi
+ if test "$PKG_CONFIG" != "no" && $PKG_CONFIG --exists gtk-doc; then
+have_gtk_doc=yes
+ fi
+
+ dnl do we want to do a version check?
+ifelse([$1],[],,
+ [gtk_doc_min
[OE-core] [meta-ti PATCH 1/4] gedit: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
meta-gnome/recipes-gnome/gedit/gedit_2.30.0.bb | 24
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 meta-gnome/recipes-gnome/gedit/gedit_2.30.0.bb
diff --git a/meta-gnome/recipes-gnome/gedit/gedit_2.30.0.bb
b/meta-gnome/recipes-gnome/gedit/gedit_2.30.0.bb
new file mode 100644
index 000..64ea644
--- /dev/null
+++ b/meta-gnome/recipes-gnome/gedit/gedit_2.30.0.bb
@@ -0,0 +1,24 @@
+DESCRIPTION = "GNOME editor"
+SECTION = "x11/gnome"
+LICENSE = "GPLv2+"
+
+DEPENDS = "enchant gconf gnome-common gnome-doc-utils-native glib-2.0 gtk+
gtksourceview2 iso-codes virtual/gettext"
+RDEPENDS_${PN} += " gtksourceview2"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+PR = "r2"
+
+inherit gnome
+SRC_URI[archive.md5sum] = "aebd49797406fdde7b25624b71990860"
+SRC_URI[archive.sha256sum] =
"37598473372aab217e46f19726cff616ff0ea4121bbdbb170b4e264a4ca76690"
+
+EXTRA_OECONF = "--disable-scrollkeeper"
+
+do_configure_prepend () {
+ cp ${STAGING_DATADIR}/gnome-common/data/omf.make ${S}
+}
+
+FILES_${PN} += "${libdir}/gedit-2/plugin* ${datadir}/gedit-2"
+FILES_${PN}-dbg += "${libdir}/gedit-2/plugin-loaders/.debug
${libdir}/gedit-2/plugins/.debug"
+
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [meta-ti PATCH 3/4] libgnomecups: Imported from OE Classic
Signed-off-by: Joel A Fernandes
---
.../recipes-gnome/gnome/libgnomecups_0.2.3.bb | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
create mode 100644 meta-gnome/recipes-gnome/gnome/libgnomecups_0.2.3.bb
diff --git a/meta-gnome/recipes-gnome/gnome/libgnomecups_0.2.3.bb
b/meta-gnome/recipes-gnome/gnome/libgnomecups_0.2.3.bb
new file mode 100644
index 000..3f3ece1
--- /dev/null
+++ b/meta-gnome/recipes-gnome/gnome/libgnomecups_0.2.3.bb
@@ -0,0 +1,17 @@
+DESCRIPTION="Gnome Cups Manager"
+LICENSE="GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+PR ="r0"
+
+DEPENDS="glib-2.0 gtk+ pango cups intltool libgnomeui"
+
+inherit gnome pkgconfig
+
+do_compile_append () {
+ cp libgnomecups-1.0.pc libgnomecups-1.0.pc.old
+ sed 's:${STAGING_DIR_HOST}::' < libgnomecups-1.0.pc.old >
libgnomecups-1.0.pc
+}
+
+SRC_URI[archive.md5sum] = "dc4920c15c9f886f73ea74fbff0ae48b"
+SRC_URI[archive.sha256sum] =
"e130e80942b386de19a288a4c194ff3dbe9140315b31e982058c8bffbb6a1d29"
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [meta-ti PATCH] beagleboard-test-scripts: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
.../beagleboard/beagleboard-test-scripts_git.bb| 50
1 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 recipes-ti/beagleboard/beagleboard-test-scripts_git.bb
diff --git a/recipes-ti/beagleboard/beagleboard-test-scripts_git.bb
b/recipes-ti/beagleboard/beagleboard-test-scripts_git.bb
new file mode 100644
index 000..17c07d8
--- /dev/null
+++ b/recipes-ti/beagleboard/beagleboard-test-scripts_git.bb
@@ -0,0 +1,50 @@
+## Reminder: The correct spacing for a variable is FOO = "BAR" in : PR="r1"
+DESCRIPTION = "BeagleBoard test scripts"
+HOMEPAGE = "http://beagleboad.org/support";
+PR = "r7"
+
+
+SRC_URI = "git://github.com/joelagnel/validation-scripts.git;protocol=git \
+"
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM="file://gpl.txt;md5=5b122a36d0f6dc55279a0ebc69f3c60b"
+
+SRCREV = "4cc0b0442733c1cc1374267622245f5bd28cd4c2"
+S = "${WORKDIR}/git"
+
+inherit update-rc.d
+INITSCRIPT_NAME = "flash-nand-fs.sh"
+INITSCRIPT_PARAMS = "start 99 2 3 4 5 ."
+
+FILES_${PN} += "/boot/user.txt \
+ /boot/uEnv.txt \
+"
+
+do_install() {
+ TEST_FILES=" \
+testaudio \
+testcamera \
+testdsp \
+testedid \
+testled \
+testmem \
+testneon \
+testsvideo \
+testuserbtn \
+editbootscr \
+edituserscr \
+readgpio \
+ "
+ install -d ${D}/${bindir}
+ for i in ${TEST_FILES}; do
+install -m 0755 ${S}/${i} ${D}/${bindir}
+ done
+ # A script to flash NAND if the board has it, and if there is valid image to
flash on the SD Card.
+ # We also register it as an init script so that the SD Card auto-flashes to
NAND during boot.
+ install -d ${D}/${sysconfdir}/init.d/
+ install -m 0755 ${S}/flashing/flash-nand-fs.sh
${D}/${sysconfdir}/init.d/flash-nand-fs.sh
+ install -d ${D}/boot/
+ install -m 0755 ${S}/flashing/user.txt ${D}/boot/user.txt
+ install -m 0755 ${S}/flashing/uEnv.txt ${D}/boot/uEnv.txt
+}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH meta-oe 4/9] libdvdread: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
.../libdvdread/libdvdread_4.1.3-10.bb | 16
1 files changed, 16 insertions(+), 0 deletions(-)
create mode 100644 meta-oe/recipes-multimedia/libdvdread/libdvdread_4.1.3-10.bb
diff --git a/meta-oe/recipes-multimedia/libdvdread/libdvdread_4.1.3-10.bb
b/meta-oe/recipes-multimedia/libdvdread/libdvdread_4.1.3-10.bb
new file mode 100644
index 000..f17043b
--- /dev/null
+++ b/meta-oe/recipes-multimedia/libdvdread/libdvdread_4.1.3-10.bb
@@ -0,0 +1,16 @@
+DESCRIPTION = "DVD access multimeda library"
+SECTION = "libs/multimedia"
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+SRC_URI =
"git://git.debian-maintainers.org/git/daniel/${PN}.git;protocol=git;branch=debian"
+
+SRCREV = "e465b500c12be5b4c0b6918a9b98038611f66c57"
+S = "${WORKDIR}/git"
+
+inherit autotools lib_package binconfig pkgconfig
+
+do_unpackpost() {
+QUILT_PATCHES=debian/patches quilt push -a
+}
+
+addtask unpackpost after do_unpack before do_patch
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC meta-oe 2/2] gnome-system-monitor: Add dependency on gnome-icon-theme
Without this, the configure stage of this recipe fails as pkg-config cannot find the gnome-icon-theme package Signed-off-by: Joel A Fernandes --- .../gnome-system-monitor_2.28.2.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-gnome/recipes-gnome/gnome-system-monitor/gnome-system-monitor_2.28.2.bb b/meta-gnome/recipes-gnome/gnome-system-monitor/gnome-system-monitor_2.28.2.bb index 72ad32b..aa6731d 100644 --- a/meta-gnome/recipes-gnome/gnome-system-monitor/gnome-system-monitor_2.28.2.bb +++ b/meta-gnome/recipes-gnome/gnome-system-monitor/gnome-system-monitor_2.28.2.bb @@ -3,7 +3,7 @@ LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" SECTION = "x11/gnome" -DEPENDS = "libgtop gtkmm glibmm gnome-doc-utils libwnck gtk+ dbus-glib librsvg" +DEPENDS = "libgtop gtkmm glibmm gnome-doc-utils gnome-icon-theme libwnck gtk+ dbus-glib librsvg" inherit gnome SRC_URI[archive.md5sum] = "3f0bca9b0ebc7a365466851cd580d167" -- 1.7.0.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH meta-oe 9/9] xpext: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
.../recipes-multimedia/xpext/xpext/auxdir.patch| 13 +++
meta-oe/recipes-multimedia/xpext/xpext_1.0-5.bb| 23
2 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 meta-oe/recipes-multimedia/xpext/xpext/auxdir.patch
create mode 100644 meta-oe/recipes-multimedia/xpext/xpext_1.0-5.bb
diff --git a/meta-oe/recipes-multimedia/xpext/xpext/auxdir.patch
b/meta-oe/recipes-multimedia/xpext/xpext/auxdir.patch
new file mode 100644
index 000..da5841a
--- /dev/null
+++ b/meta-oe/recipes-multimedia/xpext/xpext/auxdir.patch
@@ -0,0 +1,13 @@
+--- configure.ac.old 2005-06-03 12:53:28.0 +0200
configure.ac 2005-06-03 12:54:29.0 +0200
+@@ -25,9 +25,9 @@
+
+ AC_PREREQ([2.57])
+ AC_INIT([spext], [1.0], [lauri.leukku...@nokia.com], spext)
++AC_CONFIG_AUX_DIR(.)
+ AM_INIT_AUTOMAKE([dist-bzip2])
+ AM_MAINTAINER_MODE
+-AC_CONFIG_AUX_DIR(.)
+
+ dnl PKG_CHECK_MODULES(FIXESEXT, fixesext)
+
diff --git a/meta-oe/recipes-multimedia/xpext/xpext_1.0-5.bb
b/meta-oe/recipes-multimedia/xpext/xpext_1.0-5.bb
new file mode 100644
index 000..e6c1a5d
--- /dev/null
+++ b/meta-oe/recipes-multimedia/xpext/xpext_1.0-5.bb
@@ -0,0 +1,23 @@
+PR = "r1"
+LICENSE= "MIT"
+DESCRIPTION = "X Server Nokia 770 extensions library"
+SECTION = "x11/libs"
+PRIORITY = "optional"
+DEPENDS = "virtual/libx11 libxext"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=db043791349ba57ad1169e1c92477cb6"
+
+SRC_URI =
"http://repository.maemo.org/pool/maemo/ossw/source/x/${PN}/${PN}_${PV}.tar.gz \
+ file://auxdir.patch;striplevel=0"
+S = "${WORKDIR}/xpext-1.0"
+
+inherit autotools pkgconfig
+
+do_configure_prepend () {
+ cd ${S}
+ chmod +x ./autogen.sh
+ ./autogen.sh
+}
+
+SRC_URI[md5sum] = "1b0cb67b6f2bd7c4abef17648b062896"
+SRC_URI[sha256sum] =
"a3b06f5188fd9effd0799ae31352b3cd65cb913b964e2c1a923ffa9d3c08abbe"
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH meta-oe 5/9] libdvdcss: Imported from OE classic, vlc depends on it
Signed-off-by: Joel A Fernandes
---
meta-oe/recipes-multimedia/vlc/libdvdcss_1.2.10.bb | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
create mode 100644 meta-oe/recipes-multimedia/vlc/libdvdcss_1.2.10.bb
diff --git a/meta-oe/recipes-multimedia/vlc/libdvdcss_1.2.10.bb
b/meta-oe/recipes-multimedia/vlc/libdvdcss_1.2.10.bb
new file mode 100644
index 000..1a0b7b8
--- /dev/null
+++ b/meta-oe/recipes-multimedia/vlc/libdvdcss_1.2.10.bb
@@ -0,0 +1,13 @@
+DESCRIPTION = "libdvdcss is a simple library designed for accessing DVDs like
a block device without having to bother about the decryption."
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+PR = "r1"
+
+SRC_URI =
"http://download.videolan.org/pub/libdvdcss/${PV}/libdvdcss-${PV}.tar.bz2";
+
+inherit autotools
+
+EXTRA_OECONF = " --disable-doc "
+
+SRC_URI[md5sum] = "ebd5370b79ac5a83e5c61b24a214cf74"
+SRC_URI[sha256sum] =
"2394a75013ab66b592d8c91d53529ede392bc9faee37fe279bd29b455eff2220"
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH meta-oe 2/9] faad2: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
meta-oe/recipes-multimedia/faad2/faad2_2.7.bb | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 meta-oe/recipes-multimedia/faad2/faad2_2.7.bb
diff --git a/meta-oe/recipes-multimedia/faad2/faad2_2.7.bb
b/meta-oe/recipes-multimedia/faad2/faad2_2.7.bb
new file mode 100644
index 000..e778432
--- /dev/null
+++ b/meta-oe/recipes-multimedia/faad2/faad2_2.7.bb
@@ -0,0 +1,23 @@
+DESCRIPTION = "Library for reading some sort of media format."
+SECTION = "libs"
+LICENSE = "LGPL"
+PRIORITY = "optional"
+
+inherit autotools
+
+SRC_URI =
"${SOURCEFORGE_MIRROR}/faac/faad2-src/faad2-${PV}/${PN}-${PV}.tar.bz2;name=faad2
\
+"
+
+SRC_URI[faad2.md5sum] = "4c332fa23febc0e4648064685a3d4332"
+SRC_URI[faad2.sha256sum] =
"14561b5d6bc457e825bfd3921ae50a6648f377a9396eaf16d4b057b39a3f63b5"
+
+PACKAGES =+ "libfaad libfaad-dev libmp4ff libmp4ff-dev"
+
+FILES_${PN} = "${bindir}/faad"
+
+FILES_libfaad = "${libdir}/libfaad.so.*"
+FILES_libfaad-dev = "${libdir}/libfaad.so ${libdir}/libfaad.la
${libdir}/libfaad.a ${includedir}/faad.h"
+
+FILES_libmp4ff = "${libdir}/libmp4ff.so.*"
+FILES_libmp4ff-dev = "${libdir}/libmp4ff.so ${libdir}/libmp4ff.la
${libdir}/libmp4ff.a ${includedir}/mp4ff.h"
+
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH meta-oe 8/9] xsp: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
.../recipes-multimedia/xsp/xsp/xsp-fix-pc.patch| 10 ++
meta-oe/recipes-multimedia/xsp/xsp_1.0.0-8.bb | 15 +++
2 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 meta-oe/recipes-multimedia/xsp/xsp/xsp-fix-pc.patch
create mode 100644 meta-oe/recipes-multimedia/xsp/xsp_1.0.0-8.bb
diff --git a/meta-oe/recipes-multimedia/xsp/xsp/xsp-fix-pc.patch
b/meta-oe/recipes-multimedia/xsp/xsp/xsp-fix-pc.patch
new file mode 100644
index 000..18bc67c
--- /dev/null
+++ b/meta-oe/recipes-multimedia/xsp/xsp/xsp-fix-pc.patch
@@ -0,0 +1,10 @@
+--- Xsp/xsp.pc.in~ 2009-01-07 13:06:07.0 +0100
Xsp/xsp.pc.in 2009-01-07 13:06:07.0 +0100
+@@ -6,5 +6,5 @@
+ Name: Xsp
+ Description: X Sputnik Library
+ Version: @PACKAGE_VERSION@
+-Cflags: -I${includedir} @XSP_CFLAGS@ @X_CFLAGS@
+-Libs: -L${libdir} -lXsp @XSP_LIBS@ @X_LIBS@
++Cflags: -I${includedir}
++Libs: -L${libdir} -lXsp -lX11
diff --git a/meta-oe/recipes-multimedia/xsp/xsp_1.0.0-8.bb
b/meta-oe/recipes-multimedia/xsp/xsp_1.0.0-8.bb
new file mode 100644
index 000..2bc3e83
--- /dev/null
+++ b/meta-oe/recipes-multimedia/xsp/xsp_1.0.0-8.bb
@@ -0,0 +1,15 @@
+PR = "r2"
+LICENSE= "MIT"
+DESCRIPTION = "X Server Nokia 770 extensions library"
+SECTION = "x11/libs"
+PRIORITY = "optional"
+DEPENDS = "virtual/libx11 libxext xpext"
+LIC_FILES_CHKSUM = "file://COPYING;md5=ea2bda168c508c7cd8afa567b2fcc549"
+SRC_URI =
"http://repository.maemo.org/pool/maemo/ossw/source/x/xsp/${PN}_${PV}.tar.gz \
+ file://xsp-fix-pc.patch"
+S = "${WORKDIR}/Xsp"
+
+inherit autotools pkgconfig
+
+SRC_URI[md5sum] = "2a0d8d02228d4cbd28b6e07bb7c17cf5"
+SRC_URI[sha256sum] =
"8b722b952b64841d996c70c3278499886c81bb5012991beed5f66f4158418f59"
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH meta-oe 1/9] schroedinger: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
.../schroedinger/gst-plugin-schroedinger_1.0.9.bb | 15 +++
.../schroedinger/schroedinger.inc | 19 +++
.../schroedinger/schroedinger/configure.ac.patch | 13 +
.../schroedinger/schroedinger_1.0.9.bb | 13 +
4 files changed, 60 insertions(+), 0 deletions(-)
create mode 100644
meta-oe/recipes-multimedia/schroedinger/gst-plugin-schroedinger_1.0.9.bb
create mode 100644 meta-oe/recipes-multimedia/schroedinger/schroedinger.inc
create mode 100644
meta-oe/recipes-multimedia/schroedinger/schroedinger/configure.ac.patch
create mode 100644
meta-oe/recipes-multimedia/schroedinger/schroedinger_1.0.9.bb
diff --git
a/meta-oe/recipes-multimedia/schroedinger/gst-plugin-schroedinger_1.0.9.bb
b/meta-oe/recipes-multimedia/schroedinger/gst-plugin-schroedinger_1.0.9.bb
new file mode 100644
index 000..0a95646
--- /dev/null
+++ b/meta-oe/recipes-multimedia/schroedinger/gst-plugin-schroedinger_1.0.9.bb
@@ -0,0 +1,15 @@
+require schroedinger.inc
+PR = "r0"
+
+DEPENDS += "gstreamer gst-plugins-base"
+
+SRC_URI[schroedingertargz.md5sum] = "d67ec48b7c506db8c8b49156bf409e60"
+SRC_URI[schroedingertargz.sha256sum] =
"345abcaa72ff0f2e9c1075e22f7141475ee4e6eea23a7f568b69ffc13cc1c723"
+
+S = "${WORKDIR}/schroedinger-${PV}"
+
+PACKAGES = "gst-plugin-schroedinger gst-plugin-schroedinger-dev
gst-plugin-schroedinger-dbg"
+FILES_gst-plugin-schroedinger += "${libdir}/gstreamer-0.10/libgstschro.so"
+FILES_gst-plugin-schroedinger-dev += "${libdir}/gstreamer-0.10/libgstschro.*"
+FILES_gst-plugin-schroedinger-dbg +=
"${libdir}/gstreamer-0.10/.debug/libgstschro.so"
+
diff --git a/meta-oe/recipes-multimedia/schroedinger/schroedinger.inc
b/meta-oe/recipes-multimedia/schroedinger/schroedinger.inc
new file mode 100644
index 000..386fc73
--- /dev/null
+++ b/meta-oe/recipes-multimedia/schroedinger/schroedinger.inc
@@ -0,0 +1,19 @@
+HOMEPAGE = "http://schrodinger.sourceforge.net/";
+LICENSE = "MPL GPL LGPL MIT"
+DEPENDS = "liboil orc-native orc"
+
+INC_PR = "r1"
+
+SRC_URI =
"http://www.diracvideo.org/download/schroedinger/${P}.tar.gz;name=schroedingertargz";
+SRC_URI += "file://configure.ac.patch"
+
+EXTRA_OECONF += "STAGING_DIR=${STAGING_DIR_NATIVE}"
+
+inherit autotools
+
+do_configure_append () {
+# Fix stupid libtool... handling.
+# rpath handling can't be disabled and the Makefile's can't be
regenerated..
+# (GNU sed required)
+sed -i s/^hardcode_libdir_flag_spec/#hardcode_libdir_flag_spec/
${S}/*-libtool
+}
diff --git
a/meta-oe/recipes-multimedia/schroedinger/schroedinger/configure.ac.patch
b/meta-oe/recipes-multimedia/schroedinger/schroedinger/configure.ac.patch
new file mode 100644
index 000..ac5e7ee
--- /dev/null
+++ b/meta-oe/recipes-multimedia/schroedinger/schroedinger/configure.ac.patch
@@ -0,0 +1,13 @@
+Index: schroedinger-1.0.9/configure.ac
+===
+--- schroedinger-1.0.9.orig/configure.ac
schroedinger-1.0.9/configure.ac
+@@ -54,7 +54,7 @@ if test "x${HAVE_ORC}" != xyes ; then
+ AC_ERROR([orc-0.4 >= $ORC_VER is required])
+ fi
+ SCHRO_PKG_DEPS="$SCHRO_PKG_DEPS orc-0.4 >= $ORC_VER"
+-ORCC=`$PKG_CONFIG --variable=orcc orc-0.4`
++ORCC=$STAGING_DIR`$PKG_CONFIG --variable=orcc orc-0.4`
+ AC_SUBST(ORCC)
+
+ AC_ARG_WITH([thread],
diff --git a/meta-oe/recipes-multimedia/schroedinger/schroedinger_1.0.9.bb
b/meta-oe/recipes-multimedia/schroedinger/schroedinger_1.0.9.bb
new file mode 100644
index 000..2994428
--- /dev/null
+++ b/meta-oe/recipes-multimedia/schroedinger/schroedinger_1.0.9.bb
@@ -0,0 +1,13 @@
+require schroedinger.inc
+
+PR = "${INC_PR}.0"
+
+inherit autotools
+
+SRC_URI[schroedingertargz.md5sum] = "d67ec48b7c506db8c8b49156bf409e60"
+SRC_URI[schroedingertargz.sha256sum] =
"345abcaa72ff0f2e9c1075e22f7141475ee4e6eea23a7f568b69ffc13cc1c723"
+
+PACKAGES =+ "gst-plugin-schroedinger-dbg gst-plugin-schroedinger-dev
gst-plugin-schroedinger"
+FILES_gst-plugin-schroedinger = "${libdir}/gstreamer-0.10/*.so"
+FILES_gst-plugin-schroedinger-dbg = "${libdir}/gstreamer-0.10/.debug"
+FILES_gst-plugin-schroedinger-dev = "${libdir}/gstreamer-0.10/*.*a"
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH meta-oe 6/9] vlc: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
vlc is not an mplayer depdency, but libdvdcss is an mplayer depedency and it is
included in the recipes/vlc directory in oe-classic. I have imported vlc as
well for completeness.
meta-oe/recipes-multimedia/vlc/vlc.inc| 61 +
meta-oe/recipes-multimedia/vlc/vlc_1.1.4.1.bb | 51 +
2 files changed, 112 insertions(+), 0 deletions(-)
create mode 100644 meta-oe/recipes-multimedia/vlc/vlc.inc
create mode 100644 meta-oe/recipes-multimedia/vlc/vlc_1.1.4.1.bb
diff --git a/meta-oe/recipes-multimedia/vlc/vlc.inc
b/meta-oe/recipes-multimedia/vlc/vlc.inc
new file mode 100644
index 000..0435e87
--- /dev/null
+++ b/meta-oe/recipes-multimedia/vlc/vlc.inc
@@ -0,0 +1,61 @@
+DESCRIPTION = "Video player and streamer - davinci edition"
+HOMEPAGE = "http://www.videolan.org";
+LICENSE = "GPL"
+PRIORITY = "optional"
+SECTION = "multimedia"
+
+DEPENDS = "libfribidi libtool hal gettext libgcrypt schroedinger
virtual/libsdl qt4-x11-free dbus libxml2 gnutls tremor faad2 ffmpeg flac \
+ ${@base_conditional('ENTERPRISE_DISTRO', '1', '', 'libmad libid3tag
liba52 mpeg2dec', d)}"
+
+INC_PR = "r4"
+
+SRC_URI =
"http://download.videolan.org/pub/videolan/vlc/${PV}/vlc-${PV}.tar.bz2";
+
+inherit autotools
+
+ARM_INSTRUCTION_SET = "arm"
+
+EXTRA_OECONF = "\
+ --enable-libtool \
+ --with-contrib \
+ --enable-run-as-root \
+ --disable-wxwidgets \
+ --enable-x11 --enable-xvideo \
+ --disable-screen --disable-caca \
+ --enable-httpd --enable-vlm \
+ --enable-freetype \
+ --enable-sdl \
+ --enable-png \
+ --enable-live555 --enable-tremor \
+ --enable-v4l2 --enable-v4l --disable-aa --enable-wma --disable-faad \
+ --enable-dbus \
+ --enable-hal \
+ --without-contrib \
+ --disable-opengl --disable-glx \
+ --enable-realrtsp \
+ ac_cv_path_MOC=${STAGING_BINDIR_NATIVE}/moc4 \
+ ac_cv_path_RCC=${STAGING_BINDIR_NATIVE}/rcc4 \
+ ac_cv_path_UIC=${STAGING_BINDIR_NATIVE}/uic4 \
+"
+
+
+do_configure() {
+ cp ${STAGING_DATADIR}/aclocal/libgcrypt.m4 ${S}/m4/
+ ./bootstrap
+ gnu-configize --force
+ libtoolize --force
+ #autoreconf --force -i
+ cp ${STAGING_DATADIR}/libtool/config.* ${S}/autotools/ || true
+ oe_runconf
+ rm config.log
+ sed -i -e s:-L/usr/lib:-L${STAGING_LIBDIR}/:g vlc-config
+ sed -i -e s:'$(MOC) $(DEFS) $(CPPFLAGS)':'$(MOC) $(DEFS)'\
-I${S}/include\ -DSYS_LINUX:g ${S}/modules/gui/qt4/Makefile
+}
+
+FILES_${PN} += "${bindir}/vlc \
+ ${datadir}/applications \
+ ${datadir}/vlc/ \
+ "
+
+FILES_${PN} += "${datadir}/icons"
+FILES_${PN}-dbg+= "${libdir}/vlc/*/.debug
${libdir}/vlc/plugins/*/.debug"
diff --git a/meta-oe/recipes-multimedia/vlc/vlc_1.1.4.1.bb
b/meta-oe/recipes-multimedia/vlc/vlc_1.1.4.1.bb
new file mode 100644
index 000..18297c9
--- /dev/null
+++ b/meta-oe/recipes-multimedia/vlc/vlc_1.1.4.1.bb
@@ -0,0 +1,51 @@
+# This recipe packages vlc as a library as well, so qt4 dependencies
+# can be avoided when ony the library is installed.
+# Would be cool if when newer vlc is added to OE and older ones are phased
+# out that could be made the default.
+
+require vlc.inc
+
+PR = "${INC_PR}.1"
+
+SRC_URI[md5sum] = "ce17c335b38b322949694313173fcd49"
+SRC_URI[sha256sum] =
"61c9ea30a17ea40c6ccbfd507026e5c83ad9e0691f221d3667c8e49696d7c2aa"
+
+# ffmpeg from git (library version => 52) is required
+# libtool-native must be >= 2.2.4
+DEPENDS += "libdvdcss libdvdread lua5.1-native lua5.1"
+RDEPENDS_${PN} += "lua5.1"
+
+EXTRA_OECONF += "\
+ --enable-dvdread \
+"
+
+LEAD_SONAME = "libvlc.so.5"
+
+PACKAGES =+ "libvlc-dbg libvlc-dev libvlc"
+
+FILES_libvlc-dev = "${libdir}/lib*.so"
+
+FILES_libvlc-dbg = "\
+ ${libdir}/.debug \
+ ${libdir}/vlc/meta_engine/.debug \
+ ${libdir}/vlc/audio_filter/.debug ${libdir}/vlc/audio_output/.debug \
+ ${libdir}/vlc/demux/.debug ${libdir}/vlc/control/.debug \
+ ${libdir}/vlc/gui/.debug ${libdir}/vlc/packetizer/.debug \
+ ${libdir}/vlc/audio_mixer/.debug ${libdir}/vlc/stream_out/.debug \
+ ${libdir}/vlc/mux/.debug ${libdir}/vlc/access/.debug \
+ ${libdir}/vlc/visualization/.debug ${libdir}/vlc/access_filter/.debug \
+ ${libdir}/vlc/access_output/.debug ${libdir}/vlc/video_output/.debug \
+ ${libdir}/vlc/services_discovery/.debug
${libdir}/vlc/video_chroma/.debug \
+ ${libdir}/vlc/video_codec/.debug ${libdir}/vlc/video_filter/.debug \
+ ${libdir}/vlc/misc/.debug ${libdir}/vlc/codec/.debug \
+ "
+
+FILES_libvlc = "${libdir}/lib*.so.*"
+
+FILES_${PN} += "${bindir}/vlc \
+ ${datadir}/applications \
+ ${datadir}/vlc/ \
+ "
+
+FILES_${PN}-dbg+= "${libdir}/vlc/*/.debug"
+
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openemb
[OE-core] [PATCH meta-oe 7/9] live555: Imported from OE classic
Signed-off-by: Joel A Fernandes
---
.../live555/files/config.linux-cross | 17 ++
meta-oe/recipes-multimedia/live555/live555.inc | 56
.../recipes-multimedia/live555/live555_20110314.bb | 10
3 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644 meta-oe/recipes-multimedia/live555/files/config.linux-cross
create mode 100644 meta-oe/recipes-multimedia/live555/live555.inc
create mode 100644 meta-oe/recipes-multimedia/live555/live555_20110314.bb
diff --git a/meta-oe/recipes-multimedia/live555/files/config.linux-cross
b/meta-oe/recipes-multimedia/live555/files/config.linux-cross
new file mode 100644
index 000..d1277da
--- /dev/null
+++ b/meta-oe/recipes-multimedia/live555/files/config.linux-cross
@@ -0,0 +1,17 @@
+COMPILE_OPTS = $(INCLUDES) -I. -O2 -DSOCKLEN_T=socklen_t
-DNO_STRSTREAM=1 -D_LARGEFILE_SOURCE=1
+C =c
+C_COMPILER = $(CC)
+C_FLAGS = $(COMPILE_OPTS)
+CPP = cpp
+CPLUSPLUS_COMPILER = $(CXX)
+CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall -DBSD=1
+OBJ = o
+LINK = $(CXX) -o
+LINK_OPTS =-L.
+CONSOLE_LINK_OPTS =$(LINK_OPTS)
+LIBRARY_LINK = $(LD) -o
+LIBRARY_LINK_OPTS =$(LINK_OPTS) -r -Bstatic
+LIB_SUFFIX = a
+LIBS_FOR_CONSOLE_APPLICATION =
+LIBS_FOR_GUI_APPLICATION =
+EXE =
diff --git a/meta-oe/recipes-multimedia/live555/live555.inc
b/meta-oe/recipes-multimedia/live555/live555.inc
new file mode 100644
index 000..f1e21dc
--- /dev/null
+++ b/meta-oe/recipes-multimedia/live555/live555.inc
@@ -0,0 +1,56 @@
+# live555 OE build file
+# Copyright (C) 2005, Koninklijke Philips Electronics NV. All Rights Reserved
+# Released under the MIT license (see packages/COPYING)
+
+DESCRIPTION = "LIVE555 Streaming Media libraries"
+HOMEPAGE = "http://live.com/";
+LICENSE = "LGPL"
+SECTION = "devel"
+
+INC_PR = "r2"
+
+URLV =
"${@bb.data.getVar('PV',d,1)[0:4]}.${@bb.data.getVar('PV',d,1)[4:6]}.${@bb.data.getVar('PV',d,1)[6:8]}"
+SRC_URI = "http://www.live555.com/liveMedia/public/live.${URLV}.tar.gz \
+ file://config.linux-cross"
+
+S = "${WORKDIR}/live"
+TARGET_CC_ARCH += "${LDFLAGS}"
+
+do_configure() {
+ cp ${WORKDIR}/config.linux-cross .
+ echo "COMPILE_OPTS+=" -fPIC "" >> config.linux-cross
+ ./genMakefiles linux-cross
+}
+
+do_compile() {
+ make
+}
+
+do_install() {
+ install -d ${D}${includedir}/BasicUsageEnvironment
+ install -d ${D}${includedir}/groupsock
+ install -d ${D}${includedir}/liveMedia
+ install -d ${D}${includedir}/UsageEnvironment
+ install -d ${D}${libdir}
+ cp -a ${S}/BasicUsageEnvironment/include/*.hh
${D}${includedir}/BasicUsageEnvironment/
+ cp -a ${S}/groupsock/include/*.h ${D}${includedir}/groupsock/
+ cp -a ${S}/groupsock/include/*.hh ${D}${includedir}/groupsock/
+ cp -a ${S}/liveMedia/include/*.hh ${D}${includedir}/liveMedia/
+ cp -a ${S}/UsageEnvironment/include/*.hh
${D}${includedir}/UsageEnvironment/
+ # Find all the headers
+ for i in $(find . -name "*.hh") $(find . -name "*.h") ; do
+ install ${i} ${D}${includedir}
+ done
+ cp ${S}/*/*.a ${D}${libdir}
+ install -d ${D}${bindir}
+ for i in MPEG2TransportStreamIndexer openRTSP playSIP sapWatch
testMPEG1or2AudioVideoToDarwin testMPEG1or2ProgramToTransportStream
testMPEG1or2Splitter testMPEG1or2VideoReceiver
testMPEG2TransportStreamTrickPlay testMPEG4VideoToDarwin testOnDemandRTSPServer
testRelay testAMRAudioStreamer testDVVideoStreamer testMP3Receiver
testMP3Streamer testMPEG1or2AudioVideoStreamer testMPEG1or2VideoStreamer
testMPEG2TransportStreamer testMPEG4VideoStreamer testWAVAudioStreamer
vobStreamer; do
+ install -m 0755 ${S}/testProgs/${i} ${D}${bindir}/
+ done
+ install -m 0755 ${S}/mediaServer/live555MediaServer ${D}${bindir}/
+}
+
+PACKAGES =+ " live555-openrtsp live555-playsip live555-mediaserver"
+FILES_${PN} = "${bindir}/sapWatch ${bindir}/testMPEG1or2AudioVideoToDarwin
${bindir}/testMPEG1or2ProgramToTransportStream ${bindir}/testMPEG1or2Splitter
${bindir}/testMPEG1or2VideoReceiver ${bindir}/testMPEG2TransportStreamTrickPlay
${bindir}/testMPEG4VideoToDarwin ${bindir}/testOnDemandRTSPServer
${bindir}/testRelay ${bindir}/testAMRAudioStreamer
${bindir}/testDVVideoStreamer ${bindir}/testMP3Receiver
${bindir}/testMP3Streamer ${bindir}/testMPEG1or2AudioVideoStreamer
${bindir}/testMPEG1or2VideoStreamer ${bindir}/testMPEG2TransportStreamer
${bindir}/testMPEG4VideoStreamer ${bindir}/testWAVAudioStreamer
${bindir}/vobStreamer ${bindir}/MPEG2TransportStreamIndexer"
+FILES_live555-openrtsp = "${bindir}/openRTSP"
+FILES_live555-playsip = "${bindir}/playSIP"
+FILES_live555-mediaserver = "${bindir}/live555MediaServer"
diff --git a/meta-oe/recipes-multimedia/live555/live555_20110314.bb
b/meta-oe/recipes-multimedia/live555/live555_201
Re: [OE-core] [PATCH 0/1] linux-yocto-rt: fix qemumips boot
On Thu, Aug 25, 2011 at 4:54 PM, Bruce Ashfield wrote: > Richard/Saul, > > Just a minor tweak of the -rt SRCREVs to pickup a fix > that we got overnight that enables qemumips to boot from the s/from/to/ But you knew what I meant. Bruce > prompt. > > > The following changes since commit 6c2b7beac3cd23ed44bd3e195c6360a0932876bf: > > classes/sanity: enhance the network connectivity test (2011-08-25 08:51:30 > -0700) > > are available in the git repository at: > git://git.pokylinux.org/poky-contrib zedd/kernel-oe > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-oe > > Bruce Ashfield (1): > linux-yocto-rt: qemumips: fix boot panic > > meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > -- > 1.7.4.1 > > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [bitbake-devel] Layer priorities influencing default version selection
On Thu, Aug 25, 2011 at 05:58:23PM +0100, Paul Eggleton wrote: > On Thursday 25 August 2011 16:56:28 you wrote: > > with layers we dont control policies of all the layers that may be used on > > top so fixing meta-oe does not solve problem completely and we can not ask > > for exclusive recipes. People would want to override the recipes from other > > layers. > > Generally, the less duplication we have across layers the better; if a > maintainer is duplicating a recipe they should have a very good reason to do > so. We can avoid some of this duplication by making it easier to figure out > where the right place for recipes is and doing everything we can encourage > people to get stuff merged there. I'm not convinced we are doing very well on > either count yet, but I expect this will improve over time. > > > bitbake could report the layer the recipe comes from which can make it > > evident or may be special command to inform the layer priorities. This will > > guide the users to diagnose the problems quickly and help developers to > > identify the issues faster. There could be a complete bill of recipes > > printed for a given target as well so if someone wants to check all > > the recipes that were built. > > I had not considered BitBake itself reporting these, that might be useful > especially in the case of errors (although the full path to the recipe is > already reported during the build, so you should be able to tell in most > cases > from that if you need to). Outputting a specific report of parsed recipes and > bbappends as part of the build also might be useful. > > FYI, bitbake-layers exists as a separate utility to answer a lot of these > kinds of questions, and recently has become a lot more powerful - I would > strongly recommend everyone check it out and if it's not able to report what > you want then please tell me and I'll try to make it do so. I already have a > few ideas for future improvements there which I will hopefully get time to > look into in the Yocto 1.2 cycle. > > > In any case I agree that problems should be fixed. However this does > > not scale to all layers and we can not police all the layers and we should > > not. We should try to make it possible for people to glue layers together > > without issues. > > How does merely being able to alter the priorities help here though? I could > begin to understand if you were asking for some way to blacklist individual > recipes in individual layers, but moving the priority of an entire layer is > likely to have much more of an effect than just obscuring a few errant > recipes > that you don't want. Well in this I agree with khem that it would be more consistent to use priority from bblayers.conf. You're right that changing priority of an entire layer is having too big impact, but whoever is writing his bblayers.conf has better information about what he needs/wants from particular layer then layer maintainer who has no clue in which layer stack his layer will end up. > We can't "police" all the layers, no. But if those who maintain that layer > can't respond to and resolve problems then they shouldn't be maintainers or > those layers can't be considered well-maintained. When you add a layer to > your > build you are placing some trust in the maintainer of that layer; it is up to > the maintainer to make sure they don't abuse that trust. And with priority in bblayers.conf I can say how much I trust him. my 2c Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] linux-yocto-rt: qemumips: fix boot panic
Fixes [YOCTO #1392] Updating the SRCREVs to pickup: [ mips/rt: convert cascade interrupt non threaded The preempt_rt kernel forces all irq interrupts to be threaded, but special interrupts can be excluded from this conversion. The cascade interrupt should be part of these exceptions. In this case, irq2 is initialized before "kthreadd" task, which converts irq interrupt to threaded. If this irq is threaded, the kernel calls "try_to_wake_up" function to wake up "kthreadd" task, but at that moment, "kthreadd" task has no been initialize and try_to_wake_up wakes up a NULL task. Signed-off-by: Liming Wang ] Signed-off-by: Bruce Ashfield --- meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb index 16daddf..2bee543 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb @@ -14,8 +14,8 @@ KBRANCH_qemuppc = "yocto/standard/preempt-rt/qemu-ppc32" LINUX_VERSION ?= "3.0.3" LINUX_KERNEL_TYPE = "preempt-rt" -SRCREV_machine ?= "67ce0924042a2faa12b71ac3e92175c789c32af6" -SRCREV_machine_qemuppc ?= "839638f4efda0c70c6f491161ab2c042f5bc3e66" +SRCREV_machine ?= "c86423d29c94525d18ef1c9b6c025f733c1e8252" +SRCREV_machine_qemuppc ?= "ccb47c9e8d85dc00ccd28bc6819d7769e2c11cb3" SRCREV_meta ?= "5b535279e61197cb194bb2dfceb8b7a04128387c" PR = "r0" -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] linux-yocto-rt: fix qemumips boot
Richard/Saul, Just a minor tweak of the -rt SRCREVs to pickup a fix that we got overnight that enables qemumips to boot from the prompt. The following changes since commit 6c2b7beac3cd23ed44bd3e195c6360a0932876bf: classes/sanity: enhance the network connectivity test (2011-08-25 08:51:30 -0700) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel-oe http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-oe Bruce Ashfield (1): linux-yocto-rt: qemumips: fix boot panic meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] kernel.bbclass: Find the kernel consistently.
On 08/25/2011 05:59 AM, Mike Crowe wrote:
Use KERNEL_OUTPUT variable to find the generated kernel image rather than
duplicating the existing path. This also means it can be overridden simply.
There are other places in kernel.bbclass that use the path vs
KERNEL_OUTPUT, is there a reason you did not change those also?
Sau!
Signed-off-by: Mike Crowe
---
meta/classes/kernel.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a2b10f2..04e673a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -476,7 +476,7 @@ KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}"
kernel_do_deploy() {
- install -m 0644 arch/${ARCH}/boot/${KERNEL_IMAGETYPE}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
+ install -m 0644 ${KERNEL_OUTPUT}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
fi
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [bitbake-devel] Layer priorities influencing default version selection
On Thursday 25 August 2011 16:56:28 you wrote: > with layers we dont control policies of all the layers that may be used on > top so fixing meta-oe does not solve problem completely and we can not ask > for exclusive recipes. People would want to override the recipes from other > layers. Generally, the less duplication we have across layers the better; if a maintainer is duplicating a recipe they should have a very good reason to do so. We can avoid some of this duplication by making it easier to figure out where the right place for recipes is and doing everything we can encourage people to get stuff merged there. I'm not convinced we are doing very well on either count yet, but I expect this will improve over time. > bitbake could report the layer the recipe comes from which can make it > evident or may be special command to inform the layer priorities. This will > guide the users to diagnose the problems quickly and help developers to > identify the issues faster. There could be a complete bill of recipes > printed for a given target as well so if someone wants to check all > the recipes that were built. I had not considered BitBake itself reporting these, that might be useful especially in the case of errors (although the full path to the recipe is already reported during the build, so you should be able to tell in most cases from that if you need to). Outputting a specific report of parsed recipes and bbappends as part of the build also might be useful. FYI, bitbake-layers exists as a separate utility to answer a lot of these kinds of questions, and recently has become a lot more powerful - I would strongly recommend everyone check it out and if it's not able to report what you want then please tell me and I'll try to make it do so. I already have a few ideas for future improvements there which I will hopefully get time to look into in the Yocto 1.2 cycle. > In any case I agree that problems should be fixed. However this does > not scale to all layers and we can not police all the layers and we should > not. We should try to make it possible for people to glue layers together > without issues. How does merely being able to alter the priorities help here though? I could begin to understand if you were asking for some way to blacklist individual recipes in individual layers, but moving the priority of an entire layer is likely to have much more of an effect than just obscuring a few errant recipes that you don't want. We can't "police" all the layers, no. But if those who maintain that layer can't respond to and resolve problems then they shouldn't be maintainers or those layers can't be considered well-maintained. When you add a layer to your build you are placing some trust in the maintainer of that layer; it is up to the maintainer to make sure they don't abuse that trust. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [bitbake-devel] Layer priorities influencing default version selection
On Thu, Aug 25, 2011 at 3:50 AM, Paul Eggleton wrote: >> >> In my opinion the layer priority for all kind of meta data should be >> consistent and selected using bblayers.conf > > So I've thought about this more, and I don't think it is a good idea, for two > reasons: > > 1) It increases the complexity by a huge amount. New users will have to > understand how to set the priorities, and if someone reports a problem, we now > not only need to know what layers they are using, we also need to know what > mangling of the priorities they might have done. We'd just be introducing more > potentially untested configurations (as if we don't have enough already.) with layers we dont control policies of all the layers that may be used on top so fixing meta-oe does not solve problem completely and we can not ask for exclusive recipes. People would want to override the recipes from other layers. bitbake could report the layer the recipe comes from which can make it evident or may be special command to inform the layer priorities. This will guide the users to diagnose the problems quickly and help developers to identify the issues faster. There could be a complete bill of recipes printed for a given target as well so if someone wants to check all the recipes that were built. > > 2) It just papers over real problems in meta-oe or any other layer you might > choose to use on top. As I said, if meta-oe has stuff in it that is not > working, it should be fixed or removed. Let's fix problems instead of finding > ways of ignoring them. > In any case I agree that problems should be fixed. However this does not scale to all layers and we can not police all the layers and we should not. We should try to make it possible for people to glue layers together without issues. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] classes/sanity: enhance the network connectivity test
On Thu, 2011-08-25 at 08:29 -0700, Joshua Lock wrote: > Switch to use the checkstatus fetcher API for the network connectivity test, > this has several advantages: > * we no longer print any messages to the console whilst the check is > being run > * we don't actually download anything, removing the need for tidy up and > making the code more concise > > Signed-off-by: Joshua Lock Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Enhance network connectivity sanity check
The patch header says it all, I've switched to using the checkstatus API of fetch2 to implement the network connectivity check. This adds a requirement for BitBake master as of yesterday if you want to sanity check a gainst git uri's. The following changes since commit 445d6426197579a9c0317498cc6919bb63e7f726: meta-toolchain/environment: Collected site config files in runtime. (2011-08-24 19:26:01 -0700) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib josh/connection-test http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/connection-test Joshua Lock (1): classes/sanity: enhance the network connectivity test meta/classes/sanity.bbclass | 14 ++ 1 files changed, 2 insertions(+), 12 deletions(-) -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] classes/sanity: enhance the network connectivity test
Switch to use the checkstatus fetcher API for the network connectivity test,
this has several advantages:
* we no longer print any messages to the console whilst the check is
being run
* we don't actually download anything, removing the need for tidy up and
making the code more concise
Signed-off-by: Joshua Lock
---
meta/classes/sanity.bbclass | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 16af029..cefe6a4 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -95,15 +95,9 @@ def check_connectivity(d):
network_enabled = not bb.data.getVar('BB_NO_NETWORK', d, True)
check_enabled = len(test_uris)
if check_enabled and network_enabled:
-data = bb.data.createCopy(d)
-bookmark = os.getcwd()
-dldir = bb.data.expand('${TMPDIR}/sanity', data)
-bb.data.setVar('DL_DIR', dldir, data)
-
try:
-fetcher = bb.fetch2.Fetch(test_uris, data)
-fetcher.download()
-fetcher.clean(test_uris)
+fetcher = bb.fetch2.Fetch(test_uris, d)
+fetcher.checkstatus()
except Exception:
# Allow the message to be configured so that users can be
# pointed to a support mechanism.
@@ -111,10 +105,6 @@ def check_connectivity(d):
if len(msg) == 0:
msg = "Failed to fetch test data from the network. Please
ensure your network is configured correctly.\n"
retval = msg
-finally:
-# Make sure we tidy up the cruft
-oe.path.remove(dldir)
-os.chdir(bookmark)
return retval
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] linux-yocto: update meta SRCREV to sync version strings
On Thu, 2011-08-25 at 00:36 -0400, Bruce Ashfield wrote: > During the update of the bitbake recipe's string to 3.0.3 the internal > version marker in the kernel stayed at v3.0. This meant that kernel > configuration auditing the constructed file couldn't be found and audit > warnings were thrown. This syncs all the recipes and get back to > clean configurations. > > Signed-off-by: Bruce Ashfield > --- > meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb |4 ++-- > meta/recipes-kernel/linux/linux-yocto_3.0.bb|2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] does it support mercurial?
On Thu, 2011-08-25 at 15:28 +0800, Ni Qingliang wrote: > It looks like the bitbake support 'hg' fetcher, but when building custom > package, it said need "mercurial-native", but there is no "mercurial" > package in recipes-devtools, of cause, I installed mercurial on host pc. > > Does anyone can confirm this problem??? You can add: ASSUME_PROVIDED += "mercurial-native" to local.conf to show you have installed mercurial and that bitbake should use it. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] libc-package bbclass: fix binary localedata dependency code
On Thu, 2011-08-25 at 10:24 +0100, Phil Blundell wrote:
> On Wed, 2011-08-24 at 20:32 +0200, Koen Kooi wrote:
> > diff --git a/meta/classes/libc-package.bbclass
> > b/meta/classes/libc-package.bbclass
> > index 0d5ce20..d3b33d6 100644
> > --- a/meta/classes/libc-package.bbclass
> > +++ b/meta/classes/libc-package.bbclass
> > @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
> > def output_locale_binary_rdepends(name, pkgname, locale, encoding):
> > m = re.match("(.*)_(.*)", name)
> > if m:
> > - libc_name = "%s.%s" % (m.group(1),
> > m.group(2).lower().replace("-",""))
> > + libc_name = "%s-%s" % (m.group(1),
> > m.group(2).lower().replace("-",""))
> > else:
> > libc_name = name
> > bb.data.setVar('RDEPENDS_%s' % pkgname,
> > legitimize_package_name('%s-binary-localedata-%s' \
>
> For what it's worth (probably not much), this is not quite the right
> fix. Joining with "." was correct; it was the splitting on "_" that was
> wrong. The right thing would be to put it back how it was before the
> glibc/eglibc merge commit, i.e. change the re to "(*.)\.(*.)" and leave
> the output pattern alone. That ought to fix your problem and also allow
> the encoding to be correctly canonicalised.
Can someone please send me the correct patch against master? :)
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] bug 1169 eglibc doesn't depend on gcc version correctly
On Wed, 2011-08-24 at 14:35 +0800, Robert Yang wrote: > Hi experts, > > There is a bug 1169: eglibc doesn't depend on gcc version correctly, > > The produce steps are: > > 1) In the first build dir(e.g, build_1), edit conf/local.conf: > SSTATE_DIR = /path/to/share_sstate > > $ bitbake meta-toolchain > > 2) In the second build dir(e.g, build_2), edit local.conf: > SSTATE_DIR = /path/to/share_sstate > SDKGCCVERSION="4.5.1" > GCCVERSION="4.5.1" > > $ bitbake meta-toolchain > > Then we will notice the error: > | error: Failed dependencies: > | libgcc1 >= 4.6.0 is needed by eglibc-utils-2.13-r1+svnr14157.armv5te > > The reason is a little complicated: > As we can see that eglibc's RDPENDS should have 'libgcc', but eglibc's > DEPENDS(not RDEPENDS) can't have libgcc, otherwise there would be loop > dependencies(since libgcc already DEPENDS on eglibc), this causes > eglibc.do_package can't detect that the version of libgcc or gcc > has been changed from 4.6 to 4.5.1, so it would mirror the > sstate-eglibc-xxx_package.tgz(which is stored by gcc 4.6) from the > SSTATE_DIR, and then it would do_package_write_rpm from the data > of sstate-eglibc-xxx_package.tgz, but the objdump can find that the > binary file depends on the special version of libgcc, and it would > write the data( libgcc1 >= 4.6.0) to eglibc.spec, but the current > version of libgcc is 4.5.1, so there would be dependencies error when > do_rootfs. > > I don't know how to fix this, maybe we should not mirror the tarball of > sstate-xxx_package.tgz(which is mirrored according to the DEPENDS) from the > SSTATE_DIR, but only mirror the tarball of sstate-xxx_deploy-rpm.tgz(which > is mirrored according to the RDEPENDS, the RDEPENDS is what the binary > rpm package really cares), the similar to ipk and deb. The sstate checksum of the sstate-eglibc-xxx_package.tgz package should have changed when the gcc version changed, such that it would repackage (based on updated data). I think the problem is that in the sstate code, we've assumed the toolchain is special and can change: BB_HASHTASK_WHITELIST ?= "(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)" and this may be a sign we should reconsider this. Alternatively we could hiighlight we simply don't support gcc version going backwards... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Adding TARGET_VECTOR
We have some packages like flac that are aware of vectorization that may or may not exist on a given processor. I was wondering if adding something like TARGET_VECTOR similar to TARGET_FPU made sense as a way for recipes to decide on how to set various vectorization flags if needed. I was looking at this mostly from the PPC side in which we have: TARGET_VECTOR = "" /* processor has no vector hw */ TARGET_VECTOR = "altivec" /* processor has AltiVec support */ TARGET_VECTOR = "spe" /* processor has signal processing engine support */ TARGET_VECTOR = "vsx" /* processor has Vector-Scalar Extension */ Not sure what makes sense for x86, ARM, or MIPS. - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] opkg-utils: ignore packages disapperaring filelist generation
Package files disappearing during index generation don't cause a fatal
error. Make package file disappearing during filelist generation also
a non-fatal error.
Signed-off-by: Dmitry Eremin-Solenikov
---
.../opkg-utils/no-ioerror-during-filelist.patch| 31
meta/recipes-devtools/opkg-utils/opkg-utils_svn.bb |3 +-
2 files changed, 33 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/opkg-utils/no-ioerror-during-filelist.patch
diff --git a/meta/recipes-devtools/opkg-utils/no-ioerror-during-filelist.patch
b/meta/recipes-devtools/opkg-utils/no-ioerror-during-filelist.patch
new file mode 100644
index 000..dc85cb6
--- /dev/null
+++ b/meta/recipes-devtools/opkg-utils/no-ioerror-during-filelist.patch
@@ -0,0 +1,31 @@
+From: Dmitry Eremin-Solenikov
+Subject: Ignore IOError errors while populating filelist
+Upstream-Status: Pending/Not-Applicable
+
+While populating Packages.filelist there is a possibility that the package file
+will disappear while reading. So ignore errors during filelist generation.
+
+
+Signed-off-by: Dmitry Eremin-Solenikov
+
+Index: opkg-utils/opkg-make-index
+===
+--- opkg-utils.orig/opkg-make-index2011-08-25 16:45:41.0 +0400
opkg-utils/opkg-make-index 2011-08-25 17:38:57.0 +0400
+@@ -197,7 +197,15 @@
+ names = packages.packages.keys()
+ names.sort()
+ for name in names:
+- for fn in packages[name].get_file_list():
++ try:
++ fnlist = packages[name].get_file_list()
++ except OSError, e:
++ sys.stderr.write(e)
++ continue
++ except IOError, e:
++ sys.stderr.write(e)
++ continue
++ for fn in fnlist:
+ (h,t) = os.path.split(fn)
+ if not t: continue
+ if not files.has_key(t): files[t] = name+':'+fn
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_svn.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_svn.bb
index fd2b5e6..7659465 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_svn.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_svn.bb
@@ -8,12 +8,13 @@ RDEPENDS_${PN} = "python"
RDEPENDS_${PN}_virtclass-native = ""
SRCREV = "4747"
PV = "0.1.8+svnr${SRCPV}"
-PR = "r4"
+PR = "r5"
SRC_URI = "svn://svn.openmoko.org/trunk/src/host/;module=opkg-utils;proto=http
\
file://index-ignore-filenotfound.patch \
file://mtime-int.patch \
file://add-license-field.patch \
+ file://no-ioerror-during-filelist.patch \
"
S = "${WORKDIR}/opkg-utils"
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] utils.bbclass: skip empty paths when handling FILESEXTRAPATHS
On Thu, Aug 25, 2011 at 2:18 AM, Phil Blundell wrote: > On Fri, 2011-08-19 at 15:11 -0700, Chris Larson wrote: >> But then, there's a tendency nowadays to avoid map/filter/etc, >> so that's probably not best :) > > Oh, is there? What's the objection to those constructs, out of > interest? I am quite fond of them myself. Good question, I'm not sure what the reasoning is. I've read multiple documents around discussing idiomatic python that seem to feel that they should generally be dropped in favor of comprehensions and generator expressions. But, using that for something like this just looks rather silly in my opinion: [foo for foo in bar if foo]. *shrug*. Personally, I'm quite a fan of the functional programming methodology, but I do think using the functional style too much in python code tends to result in code which is extremely dense, and therefore harder to read, just due to how the language is, whether you compose generator expressions and comprehensions or you use map/filter/etc. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] kernel.bbclass: Find the kernel consistently.
Use KERNEL_OUTPUT variable to find the generated kernel image rather than
duplicating the existing path. This also means it can be overridden simply.
Signed-off-by: Mike Crowe
---
meta/classes/kernel.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a2b10f2..04e673a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -476,7 +476,7 @@ KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}"
kernel_do_deploy() {
- install -m 0644 arch/${ARCH}/boot/${KERNEL_IMAGETYPE}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
+ install -m 0644 ${KERNEL_OUTPUT}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
fi
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] kernel.bbclass: support kernel image type of vmlinux.gz
Add support for a gzipped vmlinux kernel by specifying:
KERNEL_IMAGETYPE = "vmlinux.gz"
Signed-off-by: Mike Crowe
---
meta/classes/kernel.bbclass |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 04e673a..15e3518 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -75,10 +75,15 @@ EXTRA_OEMAKE = ""
KERNEL_ALT_IMAGETYPE ??= ""
+KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else
s)(bb.data.getVar('KERNEL_IMAGETYPE', d, 1))}"
+
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake include/linux/version.h CC="${KERNEL_CC}" LD="${KERNEL_LD}"
- oe_runmake ${KERNEL_IMAGETYPE} ${KERNEL_ALT_IMAGETYPE}
CC="${KERNEL_CC}" LD="${KERNEL_LD}"
+ oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC="${KERNEL_CC}" LD="${KERNEL_LD}"
+ if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = "${KERNEL_IMAGETYPE}"; then
+ gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > "${KERNEL_OUTPUT}"
+ fi
}
do_compile_kernelmodules() {
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [bitbake-devel] Layer priorities influencing default version selection
On Tuesday 02 August 2011 16:35:12 Khem Raj wrote: > On Aug 2, 2011, at 7:14 AM, Chris Larson wrote: > > On Tue, Aug 2, 2011 at 6:52 AM, Phil Blundell wrote: > >> Actually, to some extent I consider it a bit of a misfeature that the > >> layer priority is specified by the layer rather than by the user in > >> bblayers.conf, since this makes it harder to vary the stack-up order > >> without local hackery to the layer files. For example, meta-oe > >> currently sets itself to a higher priority than oe-core, but I've found > >> that it generally seems to suit me better if meta-oe is actually the > >> lower-priority layer. > > > > Agreed. It also means that the priority knowledge is split between > > layer.conf and bblayers.conf today, as config/class priority is > > determined by order of entries in BBLAYERS, whereas recipe priority is > > determined by layer.conf. > > In my opinion the layer priority for all kind of meta data should be > consistent and selected using bblayers.conf So I've thought about this more, and I don't think it is a good idea, for two reasons: 1) It increases the complexity by a huge amount. New users will have to understand how to set the priorities, and if someone reports a problem, we now not only need to know what layers they are using, we also need to know what mangling of the priorities they might have done. We'd just be introducing more potentially untested configurations (as if we don't have enough already.) 2) It just papers over real problems in meta-oe or any other layer you might choose to use on top. As I said, if meta-oe has stuff in it that is not working, it should be fixed or removed. Let's fix problems instead of finding ways of ignoring them. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] libc-package bbclass: fix binary localedata dependency code
On Wed, 2011-08-24 at 20:32 +0200, Koen Kooi wrote:
> diff --git a/meta/classes/libc-package.bbclass
> b/meta/classes/libc-package.bbclass
> index 0d5ce20..d3b33d6 100644
> --- a/meta/classes/libc-package.bbclass
> +++ b/meta/classes/libc-package.bbclass
> @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
> def output_locale_binary_rdepends(name, pkgname, locale, encoding):
> m = re.match("(.*)_(.*)", name)
> if m:
> - libc_name = "%s.%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> + libc_name = "%s-%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> else:
> libc_name = name
> bb.data.setVar('RDEPENDS_%s' % pkgname,
> legitimize_package_name('%s-binary-localedata-%s' \
For what it's worth (probably not much), this is not quite the right
fix. Joining with "." was correct; it was the splitting on "_" that was
wrong. The right thing would be to put it back how it was before the
glibc/eglibc merge commit, i.e. change the re to "(*.)\.(*.)" and leave
the output pattern alone. That ought to fix your problem and also allow
the encoding to be correctly canonicalised.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] utils.bbclass: skip empty paths when handling FILESEXTRAPATHS
On Fri, 2011-08-19 at 15:11 -0700, Chris Larson wrote: > But then, there's a tendency nowadays to avoid map/filter/etc, > so that's probably not best :) Oh, is there? What's the objection to those constructs, out of interest? I am quite fond of them myself. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] does it support mercurial?
It looks like the bitbake support 'hg' fetcher, but when building custom package, it said need "mercurial-native", but there is no "mercurial" package in recipes-devtools, of cause, I installed mercurial on host pc. Does anyone can confirm this problem??? -- Yi Qingliang 倪庆亮 Insigma ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
