Re: [OE-core] [RFC - Staticdev 2/2] systemtap: add sqlite3 to DEPENDS
On 06/27/2011 02:57 AM, Phil Blundell wrote: On Sat, 2011-06-25 at 21:36 -0700, Saul Wold wrote: -DEPENDS = elfutils +DEPENDS = elfutils sqlite3 No doubt this is a fine change but I didn't quite understand what it has to do with staticdev. Was this meant to be a separate patchset? Well yes it not directly related to staticdev, other than I found it, it is a seperate pull within the patch request, I can break this into 2 requests if needed. Sau! p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ 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] base.bbclass: show layer's branches/revisions in the banner info
Op 28 jun 2011, om 07:37 heeft Dexuan Cui het volgende geschreven:
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/classes/base.bbclass | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 119b052..4766c77 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -165,9 +165,21 @@ python base_eventhandler() {
note(msg)
if name.startswith(BuildStarted):
+ corebase = data.getVar(COREBASE, e.data, 1)
+ corelayers = [corebase + /meta, corebase + /meta-yocto]
+ layers = (data.getVar(BBLAYERS, e.data, 1) or ).split()
+ layers = [i for i in layers if i not in corelayers]
+ fmt_str = %-27s = \%s\
+ layer_branches = [fmt_str % (os.path.basename(i)+_BRANCH, \
+ base_get_metadata_git_branch(i, None).strip()) for i in
layers]
+ layer_revisions = [fmt_str % (os.path.basename(i)+_REVISION, \
+ base_get_metadata_git_revision(i, None)) for i in
layers]
bb.data.setVar( 'BB_VERSION', bb.__version__, e.data )
statusvars = ['BB_VERSION', 'METADATA_BRANCH',
'METADATA_REVISION', 'TARGET_ARCH', 'TARGET_OS', 'MACHINE', 'DISTRO',
'DISTRO_VERSION','TARGET_FPU']
- statuslines = [%-17s = \%s\ % (i, bb.data.getVar(i, e.data,
1) or '') for i in statusvars]
+ statuslines = [fmt_str % (i, bb.data.getVar(i, e.data, 1) or
'') for i in statusvars]
+ for i in range(len(layer_branches)):
+ statuslines.insert(3+2*i, layer_branches[i])
+ statuslines.insert(3+2*i+1, layer_revisions[i])
statusmsg = \nOE Build Configuration:\n%s\n %
'\n'.join(statuslines)
print statusmsg
I tried this patch and I get:
OE Build Configuration:
BB_VERSION = 1.13.1
METADATA_BRANCH = master
METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544
meta-angstrom_BRANCH= master
meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647
meta-oe_BRANCH = master
meta-oe_REVISION= 9e3f92d498a603c0e9eb8bf77d3476a21940
meta-efl_BRANCH = master
meta-efl_REVISION = 9e3f92d498a603c0e9eb8bf77d3476a21940
meta-gpe_BRANCH = master
meta-gpe_REVISION = 9e3f92d498a603c0e9eb8bf77d3476a21940
meta-gnome_BRANCH = master
meta-gnome_REVISION = 9e3f92d498a603c0e9eb8bf77d3476a21940
meta-texasinstruments_BRANCH = master
meta-texasinstruments_REVISION = 04f274735bfc4aab757d25490df52641523bad5e
meta-efikamx_BRANCH = master
meta-efikamx_REVISION = 70cff8742d629fd32463e3ef1bddb83f04d08dc5
meta-nslu2_BRANCH = master
meta-nslu2_REVISION = aaf918b85d7a8155d6e7c0ff042808346998fbea
meta-htc_BRANCH = master
meta-htc_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6
meta-nokia_BRANCH = master
meta-nokia_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6
meta-openmoko_BRANCH= master
meta-openmoko_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6
meta-palm_BRANCH= master
meta-palm_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6
meta-zaurus_BRANCH = master
meta-zaurus_REVISION= f37d05ca7450f85642cea0e43a75df10663bd8f6
meta-sugarbay_BRANCH= master
meta-sugarbay_REVISION = 50661bf038a34702f3aa139c3ea0d67fbb0ce5db
meta-crownbay_BRANCH= master
meta-crownbay_REVISION = 50661bf038a34702f3aa139c3ea0d67fbb0ce5db
meta-emenlow_BRANCH = master
meta-emenlow_REVISION = 50661bf038a34702f3aa139c3ea0d67fbb0ce5db
meta-fishriver_BRANCH = master
meta-fishriver_REVISION = 50661bf038a34702f3aa139c3ea0d67fbb0ce5db
meta-jasperforest_BRANCH= master
meta-jasperforest_REVISION = 50661bf038a34702f3aa139c3ea0d67fbb0ce5db
meta-n450_BRANCH= master
meta-n450_REVISION = 50661bf038a34702f3aa139c3ea0d67fbb0ce5db
meta-ettus_BRANCH = master
meta-ettus_REVISION = c34c30fa29f7ab484cc90efb9713325da8e01460
meta-openpandora_BRANCH = master
meta-openpandora_REVISION = edaf6e751f873ed7a82c1116d3d58b9a070052dc
meta-archos_BRANCH = master
meta-archos_REVISION= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = beagleboard
DISTRO = angstrom
DISTRO_VERSION = v2011.06-core
TARGET_FPU = hard
So it works as expected, but the output is a bit confusing. I have a few
(conflicting) suggestions:
1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.:
meta-archos branch = master
meta-archos revision=
[OE-core] [PATCH 0/3] Enable https pages for web brower, v2
From: Zhai Edwin edwin.z...@intel.com For accessing https web page, libsoup requres modules from glib-networking for TLS/SSL support. These patches add and install it. V2 modified according to Koen's comments: relocate the glib-networking, and no name in SRC_URI. Also upgrade tracking info for manual check recipes. The following changes since commit a1f79a7896b6411669b3ccada6204d2695e80fc5: runqueue.py: Add umask task control (2011-06-24 12:23:12 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib gzhai/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master Zhai Edwin (3): glib-networking: Add 2.28.7 as new recipe webkit-gtk: recommends glib-networking to access https web page distro-tracking: Update manual check date for puzzles, gpgme, x11vnc.. .../conf/distro/include/distro_tracking_fields.inc | 172 ++-- .../glib-networking/glib-networking_2.28.7.bb | 21 +++ meta/recipes-sato/webkit/webkit-gtk_svn.bb |3 + 3 files changed, 114 insertions(+), 82 deletions(-) create mode 100644 meta/recipes-core/glib-networking/glib-networking_2.28.7.bb ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] glib-networking: Add 2.28.7 as new recipe
From: Zhai Edwin edwin.z...@intel.com
glib-networking contains the implementations of certain GLib networking
features that cannot be implemented directly in GLib itself because of their
dependencies. TLS/SSL support is one of them, which is needed for accessing SSL
web page.
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
.../glib-networking/glib-networking_2.28.7.bb | 21
1 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-core/glib-networking/glib-networking_2.28.7.bb
diff --git a/meta/recipes-core/glib-networking/glib-networking_2.28.7.bb
b/meta/recipes-core/glib-networking/glib-networking_2.28.7.bb
new file mode 100644
index 000..64fff50
--- /dev/null
+++ b/meta/recipes-core/glib-networking/glib-networking_2.28.7.bb
@@ -0,0 +1,21 @@
+DESCRIPTION = glib-networking contains the implementations of certain GLib
networking features that cannot be implemented directly in GLib itself because
of their dependencies.
+HOMEPAGE = http://git.gnome.org/browse/glib-networking/;
+BUGTRACKER = http://bugzilla.gnome.org;
+
+LICENSE = LGPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7
+
+SECTION = libs
+DEPENDS = glib-2.0 gnutls
+
+PR = r0
+
+SRC_URI = ${GNOME_MIRROR}/${PN}/2.28/${PN}-${PV}.tar.bz2
+
+SRC_URI[md5sum] = c10e51571d03c10111a37bcd21fbf777
+SRC_URI[sha256sum] =
98bedfbd530c4b1b53c91025fe82290bafd289d249e4eb549c3b90d23a76021c
+
+inherit autotools pkgconfig
+
+FILES_${PN} += ${libdir}/gio/modules/libgio* ${datadir}/dbus-1/services/
+FILES_${PN}-dbg += ${libdir}/gio/modules/.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 2/3] webkit-gtk: recommends glib-networking to access https web page
From: Zhai Edwin edwin.z...@intel.com
[YOCTO #1037] got fixed
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
meta/recipes-sato/webkit/webkit-gtk_svn.bb |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-sato/webkit/webkit-gtk_svn.bb
b/meta/recipes-sato/webkit/webkit-gtk_svn.bb
index 6d134ad..c9ded4e 100644
--- a/meta/recipes-sato/webkit/webkit-gtk_svn.bb
+++ b/meta/recipes-sato/webkit/webkit-gtk_svn.bb
@@ -10,6 +10,9 @@ LIC_FILES_CHKSUM =
file://WebCore/rendering/RenderApplet.h;endline=22;md5=fb969
DEPENDS = enchant gnome-keyring libsoup-2.4 curl icu libxml2 cairo libxslt
libxt libidn gnutls gtk+ gstreamer gst-plugins-base flex-native gperf-native
perl-native-runtime sqlite3
DEPENDS_darwin8 = curl icu libxml2 cairo libxslt libidn gnutls gtk+ gstreamer
flex-native gperf-native perl-native-runtime sqlite3
+# To access ssl web pages
+RRECOMMENDS_${PN} += glib-networking
+
SRCREV_FORMAT = webcore-rwebkit
SRCREV = 72836
--
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 V4] gcc-4.5.1: share work directories
Fix configure and Makefile to read the defaults.h and t-oe from ${B},
so that the ${S} can be shared.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-devtools/gcc/gcc-4.5.1.inc|1 +
.../gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch | 57
2 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.5.1.inc
b/meta/recipes-devtools/gcc/gcc-4.5.1.inc
index b7d0265..76f9837 100644
--- a/meta/recipes-devtools/gcc/gcc-4.5.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.5.1.inc
@@ -57,6 +57,7 @@ SRC_URI = ${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
file://gcc-poison-parameters.patch \
file://GPLUSPLUS_INCLUDE_DIR_with_sysroot.patch \
file://COLLECT_GCC_OPTIONS.patch \
+ file://use-defaults.h-and-t-oe-in-B.patch \
SRC_URI_append_sh3 = file://sh3-installfix-fixheaders.patch;patch=1
diff --git
a/meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
b/meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
new file mode 100644
index 000..c93e6ca
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
@@ -0,0 +1,57 @@
+Upstream-Status: Pending
+
+Use the defaults.h in ${B} instead of ${S}, and t-oe in ${B}, so that
+the source can be shared between gcc-cross-initial,
+gcc-cross-intermediate, gcc-cross, gcc-runtime, and also the sdk build.
+---
+ gcc/Makefile.in |2 +-
+ gcc/configure|4 ++--
+ gcc/configure.ac |4 ++--
+ 3 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/gcc/Makefile.in b/gcc/Makefile.in
+index d91f93a..03ee2bd 100644
+--- a/gcc/Makefile.in
b/gcc/Makefile.in
+@@ -461,7 +461,7 @@ LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
+ TARGET_SYSTEM_ROOT = @TARGET_SYSTEM_ROOT@
+
+ xmake_file=@xmake_file@
+-tmake_file=@tmake_file@
++tmake_file=@tmake_file@ ./t-oe
+ TM_ENDIAN_CONFIG=@TM_ENDIAN_CONFIG@
+ TM_MULTILIB_CONFIG=@TM_MULTILIB_CONFIG@
+ TM_MULTILIB_EXCEPTIONS_CONFIG=@TM_MULTILIB_EXCEPTIONS_CONFIG@
+diff --git a/gcc/configure b/gcc/configure
+index f440fa2..dafb0c1 100755
+--- a/gcc/configure
b/gcc/configure
+@@ -10838,8 +10838,8 @@ for f in $tm_file; do
+tm_include_list=${tm_include_list} $f
+;;
+ defaults.h )
+- tm_file_list=${tm_file_list} \$(srcdir)/$f
+- tm_include_list=${tm_include_list} $f
++ tm_file_list=${tm_file_list} ./$f
++ tm_include_list=${tm_include_list} ./$f
+;;
+ * )
+tm_file_list=${tm_file_list} \$(srcdir)/config/$f
+diff --git a/gcc/configure.ac b/gcc/configure.ac
+index d003091..ba422e6 100644
+--- a/gcc/configure.ac
b/gcc/configure.ac
+@@ -1652,8 +1652,8 @@ for f in $tm_file; do
+tm_include_list=${tm_include_list} $f
+;;
+ defaults.h )
+- tm_file_list=${tm_file_list} \$(srcdir)/$f
+- tm_include_list=${tm_include_list} $f
++ tm_file_list=${tm_file_list} ./$f
++ tm_include_list=${tm_include_list} ./$f
+;;
+ * )
+tm_file_list=${tm_file_list} \$(srcdir)/config/$f
+--
+1.7.1
+
--
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 4/4 V4] gcc-4.6: share work directories
* Fix configure and Makefile to read the defaults.h and t-oe from ${B},
so that the ${S} can be shared.
* Change ${S} to the shared source directory.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-devtools/gcc/gcc-4.6.inc |5 +-
.../gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch | 80
2 files changed, 84 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc
b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 577e7f7..a012049 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -66,11 +66,14 @@ SRC_URI =
svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \
file://GPLUSPLUS_INCLUDE_DIR_with_sysroot.patch \
file://COLLECT_GCC_OPTIONS.patch \
file://volatile_access_backport.patch \
+ file://use-defaults.h-and-t-oe-in-B.patch \
SRC_URI_append_sh3 = file://sh3-installfix-fixheaders.patch;patch=1
-S = ${WORKDIR}/${BRANCH}
+#S = ${WORKDIR}/${BRANCH}
+S = ${TMPDIR}/work-shared/gcc-${PV}/${BRANCH}
+B = ${WORKDIR}/${BRANCH}/build.${HOST_SYS}.${TARGET_SYS}
# Language Overrides
FORTRAN =
diff --git
a/meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
b/meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
new file mode 100644
index 000..b4351ee
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
@@ -0,0 +1,80 @@
+Upstream-Status: Pending
+
+Use the defaults.h in ${B} instead of ${S}, and t-oe in ${B}, so that
+the source can be shared between gcc-cross-initial,
+gcc-cross-intermediate, gcc-cross, gcc-runtime, and also the sdk build.
+---
+ gcc/Makefile.in |2 +-
+ gcc/configure|4 ++--
+ gcc/configure.ac |4 ++--
+ gcc/mkconfig.sh |4 ++--
+ 4 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/gcc/Makefile.in b/gcc/Makefile.in
+index 7790915..3a0c34a 100644
+--- a/gcc/Makefile.in
b/gcc/Makefile.in
+@@ -463,7 +463,7 @@ LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
+ TARGET_SYSTEM_ROOT = @TARGET_SYSTEM_ROOT@
+
+ xmake_file=@xmake_file@
+-tmake_file=@tmake_file@
++tmake_file=@tmake_file@ ./t-oe
+ TM_ENDIAN_CONFIG=@TM_ENDIAN_CONFIG@
+ TM_MULTILIB_CONFIG=@TM_MULTILIB_CONFIG@
+ TM_MULTILIB_EXCEPTIONS_CONFIG=@TM_MULTILIB_EXCEPTIONS_CONFIG@
+diff --git a/gcc/configure b/gcc/configure
+index 82fa3e4..d4711b5 100755
+--- a/gcc/configure
b/gcc/configure
+@@ -11227,8 +11227,8 @@ for f in $tm_file; do
+tm_include_list=${tm_include_list} $f
+;;
+ defaults.h )
+- tm_file_list=${tm_file_list} \$(srcdir)/$f
+- tm_include_list=${tm_include_list} $f
++ tm_file_list=${tm_file_list} ./$f
++ tm_include_list=${tm_include_list} ./$f
+;;
+ * )
+tm_file_list=${tm_file_list} \$(srcdir)/config/$f
+diff --git a/gcc/configure.ac b/gcc/configure.ac
+index 844d8da..a960343 100644
+--- a/gcc/configure.ac
b/gcc/configure.ac
+@@ -1628,8 +1628,8 @@ for f in $tm_file; do
+tm_include_list=${tm_include_list} $f
+;;
+ defaults.h )
+- tm_file_list=${tm_file_list} \$(srcdir)/$f
+- tm_include_list=${tm_include_list} $f
++ tm_file_list=${tm_file_list} ./$f
++ tm_include_list=${tm_include_list} ./$f
+;;
+ * )
+tm_file_list=${tm_file_list} \$(srcdir)/config/$f
+diff --git a/gcc/mkconfig.sh b/gcc/mkconfig.sh
+index d56df8c..875d0f1 100644
+--- a/gcc/mkconfig.sh
b/gcc/mkconfig.sh
+@@ -77,7 +77,7 @@ if [ -n $HEADERS ]; then
+ if [ $# -ge 1 ]; then
+ echo '#ifdef IN_GCC' ${output}T
+ for file in $@; do
+- if test x$file = xdefaults.h; then
++ if test x$file = x./defaults.h; then
+ postpone_defaults_h=yes
+ else
+ echo # include \$file\ ${output}T
+@@ -103,7 +103,7 @@ esac
+
+ # If we postponed including defaults.h, add the #include now.
+ if test x$postpone_defaults_h = xyes; then
+-echo # include \defaults.h\ ${output}T
++echo # include \./defaults.h\ ${output}T
+ fi
+
+ # Add multiple inclusion protection guard, part two.
+--
+1.7.1
+
--
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 V4] bitbake: share source directory
This patch is derived from Richard, it is a quick proof of concept to
show how source code could be shared between recipes which use ${B} to
have a separate build directory compared to source directory ${S}.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
bitbake/lib/bb/build.py|4 ++--
bitbake/lib/bb/cache.py|3 +++
bitbake/lib/bb/runqueue.py | 10 ++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py
index f69464c..5c70309 100644
--- a/bitbake/lib/bb/build.py
+++ b/bitbake/lib/bb/build.py
@@ -383,10 +383,10 @@ def stamp_internal(taskname, d, file_name):
taskflagname = taskname.replace(_setscene, )
if file_name:
-stamp = d.stamp[file_name]
+stamp = d.stamp_base[file_name].get(taskflagname) or d.stamp[file_name]
extrainfo = d.stamp_extrainfo[file_name].get(taskflagname) or
else:
-stamp = d.getVar('STAMP', True)
+stamp = d.getVarFlag(taskflagname, 'stamp-base', True) or
d.getVar('STAMP', True)
file_name = d.getVar('BB_FILENAME', True)
extrainfo = d.getVarFlag(taskflagname, 'stamp-extra-info', True) or
diff --git a/bitbake/lib/bb/cache.py b/bitbake/lib/bb/cache.py
index 6c92a93..99d7395 100644
--- a/bitbake/lib/bb/cache.py
+++ b/bitbake/lib/bb/cache.py
@@ -124,6 +124,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
self.broken = self.getvar('BROKEN', metadata)
self.not_world = self.getvar('EXCLUDE_FROM_WORLD', metadata)
self.stamp = self.getvar('STAMP', metadata)
+self.stamp_base = self.flaglist('stamp-base', self.tasks, metadata)
self.stamp_extrainfo = self.flaglist('stamp-extra-info', self.tasks,
metadata)
self.packages_dynamic = self.listvar('PACKAGES_DYNAMIC', metadata)
self.depends = self.depvar('DEPENDS', metadata)
@@ -151,6 +152,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
cachedata.pkg_dp = {}
cachedata.stamp = {}
+cachedata.stamp_base = {}
cachedata.stamp_extrainfo = {}
cachedata.fn_provides = {}
cachedata.pn_provides = defaultdict(list)
@@ -183,6 +185,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
cachedata.pkg_pepvpr[fn] = (self.pe, self.pv, self.pr)
cachedata.pkg_dp[fn] = self.defaultpref
cachedata.stamp[fn] = self.stamp
+cachedata.stamp_base[fn] = self.stamp_base
cachedata.stamp_extrainfo[fn] = self.stamp_extrainfo
provides = [self.pn]
diff --git a/bitbake/lib/bb/runqueue.py b/bitbake/lib/bb/runqueue.py
index b801877..e1d32b7 100644
--- a/bitbake/lib/bb/runqueue.py
+++ b/bitbake/lib/bb/runqueue.py
@@ -105,6 +105,11 @@ class RunQueueScheduler(object):
if self.rq.runq_running[taskid] == 1:
continue
if self.rq.runq_buildable[taskid] == 1:
+fn =
self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[taskid]]
+taskname = self.rqdata.runq_task[taskid]
+stamp = bb.build.stampfile(taskname, self.rqdata.dataCache, fn)
+if stamp in self.rq.build_stamps.values():
+continue
return taskid
def next(self):
@@ -1009,6 +1014,7 @@ class RunQueueExecute:
self.runq_complete = []
self.build_pids = {}
self.build_pipes = {}
+self.build_stamps = {}
self.failed_fnids = []
def runqueue_process_waitpid(self):
@@ -1023,6 +1029,9 @@ class RunQueueExecute:
del self.build_pids[result[0]]
self.build_pipes[result[0]].close()
del self.build_pipes[result[0]]
+# self.build_stamps[result[0]] may not exist when use shared work
directory.
+if result[0] in self.build_stamps.keys():
+del self.build_stamps[result[0]]
if result[1] != 0:
self.task_fail(task, result[1]8)
else:
@@ -1330,6 +1339,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
self.build_pids[pid] = task
self.build_pipes[pid] = runQueuePipe(pipein, pipeout, self.cfgData)
+self.build_stamps[pid] = bb.build.stampfile(taskname,
self.rqdata.dataCache, fn)
self.runq_running[task] = 1
self.stats.taskActive()
if self.stats.active self.number_tasks:
--
1.7.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/3] glib-networking: Add 2.28.7 as new recipe
Op 28 jun 2011, om 11:11 heeft Phil Blundell het volgende geschreven:
On Tue, 2011-06-28 at 15:42 +0800, edwin.z...@intel.com wrote:
+SRC_URI = ${GNOME_MIRROR}/${PN}/2.28/${PN}-${PV}.tar.bz2
FYI, gnome.bbclass will do this for you and will also figure out the
2.28 part automatically.
THat will also drag in a ton of deps, gnomebase.bbclass in meta-oe does a
better job :)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] /build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/autom4te: build/tmp-angstrom_2010_x-eglibc/sysroot: bad interpreter:
On 06/27/11 17:47, Jonathan Cameron wrote: On 06/27/11 17:34, Jonathan Cameron wrote: Building a couple of different things today gave me an issue that boils down to the subject line. Latest issue was eglibc where do_populate_sysroot ended with. + autoconf /home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/autoconf: /home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/autom4te: /home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroot: bad interpreter: No such file or directory /home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/autoconf: line 501: /home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/autom4te: Success ERROR: Function 'do_siteconfig_gencache' failed (see /home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/eglibc-2.12-r15/temp/log.do_populate_sysroot.1218 for further information) Which is true. The directory is sysroots not systroot. I guess it could be a dead tmp issue so will try rebuilding from scratch overnight... It wasn't. Now getting the same error, on libtool native, but now with an apparently valid path.. Anyone have any other thoughts on what might have broken this? Missed wiping the caches, now looks like it might be working... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot-mkimage: bump version to 2011.03
Hi Darren, 28.06.2011 8:09, Darren Hart wrote: These look like good changes to me, with a couple of minor things needed: 1) Please submit the version change independently from the added patches to keep things functionally distinct. Hm.. Actually the new version won't build without the patches, so I think this should be addressed by a single commit. Maybe I should add a note on this in the commit message though... 2) The patch from you marked as Submitted: has this received any discussion on the u-boot list? Yes, it's already applied (with some cosmetic changes). I will repost my oe-core with the new versions of U-Boot patches. Please let me know if you still think these should be two separate commits. Regards, Ilya. ___ 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] base.bbclass: show layer's branches/revisions in the banner info
On Tuesday 28 June 2011 07:45:09 Koen Kooi wrote: So it works as expected, but the output is a bit confusing. I have a few (conflicting) suggestions: 1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.: meta-archos branch = master meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad 2) for the extra layers put branch and revision on a single line: meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad I'd go with option 2 over 1, personally - the list gets rather long on something like Angstrom, better to keep it short. 3) Move the revision info down, e..g OE Build Configuration: BB_VERSION = 1.13.1 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beagleboard DISTRO = angstrom DISTRO_VERSION = v2011.06-core TARGET_FPU = hard METADATA_BRANCH = master METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544 meta-angstrom_BRANCH= master meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647 etc. What do you think about that? Sounds good to me. 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/1] libc-locale: split locale handling from libc recipe.
On Tue, 2011-06-28 at 10:07 +0100, Phil Blundell wrote:
On Tue, 2011-06-28 at 08:51 +0800, Xu, Dongxiao wrote:
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Phil Blundell
Sent: Monday, June 27, 2011 4:58 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 1/1] libc-locale: split locale handling
from libc
recipe.
On Mon, 2011-06-27 at 16:37 +0800, Dongxiao Xu wrote:
-PACKAGES = ${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX}
nscd${PKGSUFFIX} ldd${PKGSUFFIX} localedef${PKGSUFFIX} libcidn ${PN}-utils
${PN}-pic ${PN}-dev eglibc-doc eglibc-locale libmemusage
libsegfault${PKGSUFFIX} eglibc-extra-nss eglibc-thread-db${PKGSUFFIX}
eglibc-pcprofile libsotruss${PKGSUFFIX}
-
-PACKAGES_DYNAMIC = \
- glibc-gconv-*${PKGSUFFIX} glibc-charmap-*
glibc-localedata-*
glibc-binary-localedata-* \
- eglibc-gconv-* eglibc-charmap-* eglibc-localedata-*
eglibc-binary-localedata-* \
- locale-base-*${PKGSUFFIX}
+PACKAGES = ${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX}
nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-utils ${PN}-pic ${PN}-dev
eglibc-doc
libcidn libmemusage libsegfault${PKGSUFFIX} eglibc-extra-nss
eglibc-thread-db${PKGSUFFIX} eglibc-pcprofile
You seem to have made a bunch of changes here that are not related to
locales.
What are those about?
They are locale related changes.
Locale related stuffs in the above PACKAGES and PACKAGES_DYNAMIC are moved
to eglibc-locale recipe.
Is libsotruss${PKGSUFFIX} (for example) really a locale related stuff?
It's not obvious to me what the connection is.
Dongxiao: What Phil is referring to here is that libsotruss${PKGSUFFIX}
disappeared from PACKAGES and that also ${libdir}/audit/.debug
disappeared from FILES_${PN}-dbg.
Specifically these changes came in as part of:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=77c2dd944db42e40cc8467e6bc5a175fed90c251
which I don't think your patch accounted for.
Since this patch has been around for a while and it otherwise looks
good, I've fixed up these couple of issues and merged it though.
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 V2 0/1] Removing hard coded libdir for libc locale generating
On Thu, 2011-06-23 at 21:43 +0800, Lianhao Lu wrote: V2: Use base_libdir instead of libdir for ldlibdir. V1: The patch replaces the hard coded libdir in package_do_split_gconvs() in libc-package.bbclass to meet the requirement of multilib. The following changes since commit b04ee632eb06650dde3e3ee8c4788a45cae0aa5e: Richard Purdie (1): multilib: First pass from RP are available in the git repository at: git://git.pokylinux.org/poky-contrib llu/ml http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=llu/ml Lianhao Lu (1): libc-package.bbclass: Replace hard coded libdir. 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] [PATCH 1/4 V4] bitbake: share source directory
On Tue, 2011-06-28 at 17:05 +0800, Robert Yang wrote:
This patch is derived from Richard, it is a quick proof of concept to
show how source code could be shared between recipes which use ${B} to
have a separate build directory compared to source directory ${S}.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
bitbake/lib/bb/build.py|4 ++--
bitbake/lib/bb/cache.py|3 +++
bitbake/lib/bb/runqueue.py | 10 ++
3 files changed, 15 insertions(+), 2 deletions(-)
Since this is a bitbake patch it should really have gone to the
bitbake-devel list. Its been posted around enough times for review
though so I've merged it into bitbake. I did massively reword the commit
message though to reflect what the changes mean from a bitbake
perspective.
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/1] libc-locale: split locale handling from libc recipe.
Op 28 jun 2011, om 13:07 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-28 at 10:07 +0100, Phil Blundell wrote:
On Tue, 2011-06-28 at 08:51 +0800, Xu, Dongxiao wrote:
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Phil Blundell
Sent: Monday, June 27, 2011 4:58 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 1/1] libc-locale: split locale handling from
libc
recipe.
On Mon, 2011-06-27 at 16:37 +0800, Dongxiao Xu wrote:
-PACKAGES = ${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX}
nscd${PKGSUFFIX} ldd${PKGSUFFIX} localedef${PKGSUFFIX} libcidn ${PN}-utils
${PN}-pic ${PN}-dev eglibc-doc eglibc-locale libmemusage
libsegfault${PKGSUFFIX} eglibc-extra-nss eglibc-thread-db${PKGSUFFIX}
eglibc-pcprofile libsotruss${PKGSUFFIX}
-
-PACKAGES_DYNAMIC = \
- glibc-gconv-*${PKGSUFFIX} glibc-charmap-* glibc-localedata-*
glibc-binary-localedata-* \
- eglibc-gconv-* eglibc-charmap-* eglibc-localedata-*
eglibc-binary-localedata-* \
- locale-base-*${PKGSUFFIX}
+PACKAGES = ${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX}
nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-utils ${PN}-pic ${PN}-dev eglibc-doc
libcidn libmemusage libsegfault${PKGSUFFIX} eglibc-extra-nss
eglibc-thread-db${PKGSUFFIX} eglibc-pcprofile
You seem to have made a bunch of changes here that are not related to
locales.
What are those about?
They are locale related changes.
Locale related stuffs in the above PACKAGES and PACKAGES_DYNAMIC are moved
to eglibc-locale recipe.
Is libsotruss${PKGSUFFIX} (for example) really a locale related stuff?
It's not obvious to me what the connection is.
Dongxiao: What Phil is referring to here is that libsotruss${PKGSUFFIX}
disappeared from PACKAGES and that also ${libdir}/audit/.debug
disappeared from FILES_${PN}-dbg.
Specifically these changes came in as part of:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=77c2dd944db42e40cc8467e6bc5a175fed90c251
which I don't think your patch accounted for.
Since this patch has been around for a while and it otherwise looks
good, I've fixed up these couple of issues and merged it though.
This breaks when using eglibc 2.12 :(
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc-locale: add missing 2.12 version
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-core/eglibc/eglibc-locale_2.12.bb | 58
1 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-core/eglibc/eglibc-locale_2.12.bb
diff --git a/meta/recipes-core/eglibc/eglibc-locale_2.12.bb
b/meta/recipes-core/eglibc/eglibc-locale_2.12.bb
new file mode 100644
index 000..ed6c099
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-locale_2.12.bb
@@ -0,0 +1,58 @@
+INHIBIT_DEFAULT_DEPS = 1
+LICENSE = LGPL
+
+BPN = eglibc
+
+do_fetch[noexec] = 1
+do_unpack[noexec] = 1
+do_patch[noexec] = 1
+do_configure[noexec] = 1
+do_compile[noexec] = 1
+
+# Binary locales are generated at build time if ENABLE_BINARY_LOCALE_GENERATION
+# is set. The idea is to avoid running localedef on the target (at first boot)
+# to decrease initial boot time and avoid localedef being killed by the OOM
+# killer which used to effectively break i18n on machines with 128MB RAM.
+
+# default to disabled
+ENABLE_BINARY_LOCALE_GENERATION ?= 0
+ENABLE_BINARY_LOCALE_GENERATION_pn-eglibc-locale-nativesdk = 0
+
+#enable locale generation on these arches
+# BINARY_LOCALE_ARCHES is a space separated list of regular expressions
+BINARY_LOCALE_ARCHES ?= arm.* i[3-6]86 x86_64 powerpc mips
+
+# set 1 to use cross-localedef for locale generation
+# set 0 for qemu emulation of native localedef for locale generation
+LOCALE_GENERATION_WITH_CROSS-LOCALEDEF = 1
+
+PR = r0
+
+PKGSUFFIX =
+PKGSUFFIX_virtclass-nativesdk = -nativesdk
+
+PACKAGES = eglibc-locale localedef${PKGSUFFIX}
+
+PACKAGES_DYNAMIC = locale-base-* \
+eglibc-gconv-* eglibc-charmap-* eglibc-localedata-*
eglibc-binary-localedata-* \
+glibc-gconv-*${PKGSUFFIX} glibc-charmap-*
glibc-localedata-* glibc-binary-localedata-*
+
+PROVIDES = virtual/libc-locale${PKGSUFFIX}
+
+RPROVIDES_eglibc-locale = glibc-locale
+
+FILES_eglibc-gconv = ${libdir}/gconv/*
+FILES_localedef${PKGSUFFIX} = ${bindir}/localedef
+
+do_install () {
+ cp -fpPR
${STAGING_INCDIR}/eglibc-locale-internal-${MULTIMACH_TARGET_SYS}/* ${D}
+ cp -fpPR ${D}/SUPPORTED ${WORKDIR}
+}
+
+DESCRIPTION_localedef = eglibc: compile locale definition files
+
+inherit libc-package
+
+do_install[depends] += virtual/libc${PKGSUFFIX}:do_populate_sysroot
+
+BBCLASSEXTEND = nativesdk
--
1.6.6.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/3] glib-networking: Add 2.28.7 as new recipe
Op 28 jun 2011, om 14:05 heeft Zhai, Edwin het volgende geschreven:
Koen Kooi wrote:
Op 28 jun 2011, om 11:11 heeft Phil Blundell het volgende geschreven:
On Tue, 2011-06-28 at 15:42 +0800, edwin.z...@intel.com wrote:
+SRC_URI = ${GNOME_MIRROR}/${PN}/2.28/${PN}-${PV}.tar.bz2
FYI, gnome.bbclass will do this for you and will also figure out the
2.28 part automatically.
THat will also drag in a ton of deps,
yes.
gnomebase.bbclass in meta-oe does a better job :)
There is no gnomebase.bbclass in yocto. I can sync with it in future.
I'll have a look at the differences between the oe-core classes and the meta-oe
ones, there were some hack involved when I merged the .dev versions into meta-oe
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] webkit-gtk: recommends glib-networking to access https web page
On Tue, 2011-06-28 at 20:08 +0800, Zhai, Edwin wrote: Koen Kooi wrote: Op 28 jun 2011, om 10:13 heeft Zhai, Edwin het volgende geschreven: In future, other recipes besides webkit-gtk may ask for glib-networking, maybe we can change it that time? What's your opinion? I'd either put it in the lib that uses it (soup) or the app that needs it (web-webkit), something in between is just confusing. Reasonable. I'd like to put it in libsoup. Actually, I think this sounds like a strong case to put it in web-webkit. My reasoning is that none of the other packages have the dependency, its really the use webkit makes of the libraries that is the requirement for the package... 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 2/3] webkit-gtk: recommends glib-networking to access https web page
Done. Commits @ same contrib tree. git://git.pokylinux.org/poky-contrib gzhai/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master Thanks, edwin Zhai, Edwin wrote: Koen Kooi wrote: Op 28 jun 2011, om 10:13 heeft Zhai, Edwin het volgende geschreven: In future, other recipes besides webkit-gtk may ask for glib-networking, maybe we can change it that time? What's your opinion? I'd either put it in the lib that uses it (soup) or the app that needs it (web-webkit), something in between is just confusing. Reasonable. I'd like to put it in libsoup. Thanks, edwin regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/7] useradd.bbclass: new class for managing user/group permissions
Hi Scott,
Sorry its taken me a while to get to this. Some comments below.
On Thu, 2011-06-02 at 16:50 -0700, Scott Garman wrote:
This class is to be used by recipes that need to set up specific
user/group accounts and set custom file/directory permissions.
Signed-off-by: Scott Garman scott.a.gar...@intel.com
---
meta/classes/useradd.bbclass | 163
++
1 files changed, 163 insertions(+), 0 deletions(-)
create mode 100644 meta/classes/useradd.bbclass
diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
new file mode 100644
index 000..3f07e5e
--- /dev/null
+++ b/meta/classes/useradd.bbclass
@@ -0,0 +1,163 @@
+USERADDPN ?= ${PN}
+
+# base-passwd-cross provides the default passwd and group files in the
+# target sysroot, and shadow-native provides the utilities needed to
+# add and modify user and group accounts
+DEPENDS_append = base-passwd shadow-native
+RDEPENDS_${USERADDPN}_append = base-passwd shadow
+
+PSEUDO=${STAGING_DIR_NATIVE}/usr/bin/pseudo
+export PSEUDO
For reference this can be done with:
export PSEUDO = ${STAGING_DIR_NATIVE}/usr/bin/pseudo
+PSEUDO_LOCALSTATEDIR=${STAGING_DIR_TARGET}/var/pseudo
+export PSEUDO_LOCALSTATEDIR
I'm a little bit puzzled at this point. This is changing the default
PSEUDO state directory to be one shared by many other users rather than
the default of the one in workdir. Is that really what you intend here?
I guess the question is whether we need to preserve these users in the
sysroot or whether preserving them for the install/package/package_write
cycle is enough.
Since tasks don't share the same pseudo context by default, I suspect
we're not preserving users for the sysroot anyhow?
+PSEUDO_PASSWD = ${STAGING_DIR_TARGET}
+export PSEUDO_PASSWD
Should we set this by default as part of the pseudo options in
bitbake.conf?
+useradd_preinst () {
+OPT=
+SYSROOT=
+
+if test x$D != x; then
+ # Installing into a sysroot
+ SYSROOT=${STAGING_DIR_TARGET}
+ OPT=--root ${STAGING_DIR_TARGET}
+
+ # Add groups and users defined for all recipe packages
+ GROUPADD_PARAM=${@get_all_cmd_params(d, 'group')}
+ USERADD_PARAM=${@get_all_cmd_params(d, 'user')}
+else
+ # Installing onto a target
+ PSEUDO=
+
+ # Add groups and users defined only for this package
+ GROUPADD_PARAM=${GROUPADD_PARAM}
+ USERADD_PARAM=${USERADD_PARAM}
+fi
+
+# Perform group additions first, since user additions may depend
+# on these groups existing
+if test x$GROUPADD_PARAM != x; then
+ echo Running groupadd commands...
+ # Invoke multiple instances of groupadd for parameter lists
+ # separated by ';'
+ opts=`echo $GROUPADD_PARAM | cut -d ';' -f 1`
+ remaining=`echo $GROUPADD_PARAM | cut -d ';' -f 2-`
+ while test x$opts != x; do
+ eval $PSEUDO groupadd -f $OPT $opts
If this task is already running under pseudo, do we specifically need to
run under pseudo here? Is it not already running under pseudo when
needed?
+ if test x$opts = x$remaining; then
+ break
+ fi
+ opts=`echo $remaining | cut -d ';' -f 1`
+ remaining=`echo $remaining | cut -d ';' -f 2-`
+ done
+fi
+
+if test x$USERADD_PARAM != x; then
+ echo Running useradd commands...
+ # Invoke multiple instances of useradd for parameter lists
+ # separated by ';'
+ opts=`echo $USERADD_PARAM | cut -d ';' -f 1`
+ remaining=`echo $USERADD_PARAM | cut -d ';' -f 2-`
+ while test x$opts != x; do
+ # useradd does not have a -f option, so we have to check if the
+ # username already exists manually
+ username=`echo $opts | awk '{ print $NF }'`
+ user_exists=`grep ^$username: $SYSROOT/etc/passwd || true`
+ if test x$user_exists = x; then
+ eval $PSEUDO useradd $OPT $opts
+ else
+ echo Note: username $username already exists, not
re-creating it
+ fi
+
+ if test x$opts = x$remaining; then
+ break
+ fi
+ opts=`echo $remaining | cut -d ';' -f 1`
+ remaining=`echo $remaining | cut -d ';' -f 2-`
+ done
+fi
+}
+
+useradd_sysroot () {
+ # Explicitly set $D since it isn't set to anything
+ # before do_install
+ D=${D}
+ useradd_preinst
+}
+
+useradd_sysroot_sstate () {
+ if [ ${BB_CURRENTTASK} = populate_sysroot_setscene ]
+ then
+ useradd_sysroot
+ fi
+}
+
+do_install[prefuncs] += useradd_sysroot
+SSTATEPOSTINSTFUNCS += useradd_sysroot_sstate
+
+# Recipe parse-time sanity checks
+def update_useradd_after_parse(d):
+ if bb.data.getVar('USERADD_PACKAGES', d) == None:
+ if bb.data.getVar('USERADD_PARAM', d) == None and
bb.data.getVar('GROUPADD_PARAM', d) == None:
+
Re: [OE-core] [Draft design][RFC] Running postinst at rootfs generation time
On Mon, 2011-06-27 at 23:11 -0500, Mark Hatle wrote: On 6/27/11 9:09 PM, Cui, Dexuan wrote: Hi all, below is an initial investigation about the task and we'll continue to further look into it. In poky we have 2 types of postinst scripts: one (type-1) can be (and has already been) run at rootfs generation time and the other (type-2) has to be delayed to the first-boot of target device. Type-2 makes target device's first-boot slow and it would be great if we can fix it and convert it to type-1. We can instrument a first-boot with minimal/sato first to see which postinstalls take the most time and then prioritise those ones to fix. I figurerd out a list of 33 recipes in total(recipes with the same name but with different versions are counted once) we possibly need to fix. For the recipes, we need try to find recipe-specific ways(use appropriately modified native utilities to generate caches, files, etc as necessary on the target filesystem). ... 1 recipe: prelink: we could propablly fix it, but I'm not sure yet. meta/recipes-devtools/prelink/prelink_git.bb There is nothing to do for the prelinker. The image-prelink.bbclass handles everything needed to prelink during image creation. The script is only there for on-target field upgrades. So you can remove this from your list. Mark, are you 100% sure about this? It looks like if we install prelink into an image it adds a post install which runs prelink -a on the target device at first boot. This would happen regardless of whether the cross prelinker did or did not prelink the image :/. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [Draft design][RFC] Running postinst at rootfs generation time
Hi Dexuan, On Tue, 2011-06-28 at 10:09 +0800, Cui, Dexuan wrote: Hi all, below is an initial investigation about the task and we'll continue to further look into it. In poky we have 2 types of postinst scripts: one (type-1) can be (and has already been) run at rootfs generation time and the other (type-2) has to be delayed to the first-boot of target device. Type-2 makes target device's first-boot slow and it would be great if we can fix it and convert it to type-1. We can instrument a first-boot with minimal/sato first to see which postinstalls take the most time and then prioritise those ones to fix. I figurerd out a list of 33 recipes in total(recipes with the same name but with different versions are counted once) we possibly need to fix. For the recipes, we need try to find recipe-specific ways(use appropriately modified native utilities to generate caches, files, etc as necessary on the target filesystem). Out of interest, how long were these different groups of postinstall taking on the target device? 11 recipes: these could be easily fixed if we add the properly-adjusted utilities adduser, addgroup, pwconv, etc. Scott is actually adding the utilites: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/useradd-rebasedid=99e54d9696104ed38ec1e3464e17aa1f9b8d98ac meta/recipes-devtools/distcc/distcc_2.18.3.bb meta/recipes-extended/cronie/cronie_1.4.7.bb meta/recipes-extended/at/at_3.1.12.bb:47 meta/recipes-support/hal/hal.inc:45 meta/recipes-core/dbus/dbus.inc:49 meta/recipes-connectivity/openssh/openssh_5.8p2.bb meta/recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb meta/recipes-graphics/x11-common/xserver-nodm-init.bb meta/recipes-multimedia/pulseaudio/pulseaudio.inc:87 meta/recipes-extended/shadow/shadow_4.1.4.3.bb:125 meta/classes/libc-package.bbclass We should definitely fix these now we have the user code. 6 recipes: these should be easily fixed since the scripts are not related to special native utilites. meta/recipes-extended/sudo/sudo.inc meta/recipes-extended/sysklogd/sysklogd.inc meta/classes/update-rc.d.bbclass meta/recipes-connectivity/ppp/ppp_2.4.5.bb meta/recipes-graphics/pango/pango.inc meta/recipes-gnome/gtk+/gtk+.inc 4 recipes: we may need to add gtk-update-icon-cache-native. meta/classes/gtk-icon-cache.bbclass meta/recipes-gnome/librsvg/librsvg_2.32.1.bb meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.22.1.bb meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc 3 recipes: need to add gconftool-2-native? meta/classes/gconf.bbclass meta/recipes-graphics/mutter/mutter.inc meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb I suspect this category and the once above (icon-cache) are the slowest on the target device? 3 recipes: dpkg --configure, opkg-cl configure: looks it's possible to fix them if we specify proper parematers? meta/recipes-devtools/dpkg/dpkg.inc meta/recipes-devtools/opkg/opkg_svn.bb meta/recipes-devtools/opkg/opkg_0.1.8.bb 1 recipe: prelink: we could propablly fix it, but I'm not sure yet. meta/recipes-devtools/prelink/prelink_git.bb 1 recipe: /etc/init.d/populate-volatile.sh update ; DBUSPID=`pidof dbus-daemon`: We can't fix this one. meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc The below 4 recipes need the related utilities and need more investigation. 1 recipe: update-modules meta/recipes-kernel/update-modules/update-modules_1.0.bb 1 recipe: systemctl meta/recipes-connectivity/avahi/avahi.inc 1 recipe: fc-cache meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb:37 1 recipe: gtk-query-immodules-2.0 meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb This looks like a good start to me but I'd be interested to see the relative lengths of time these postinstalls take... 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/3] glib-networking: Add 2.28.7 as new recipe
On Tue, 2011-06-28 at 15:42 +0800, edwin.z...@intel.com wrote: From: Zhai Edwin edwin.z...@intel.com glib-networking contains the implementations of certain GLib networking features that cannot be implemented directly in GLib itself because of their dependencies. TLS/SSL support is one of them, which is needed for accessing SSL web page. Signed-off-by: Zhai Edwin edwin.z...@intel.com --- .../glib-networking/glib-networking_2.28.7.bb | 21 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-core/glib-networking/glib-networking_2.28.7.bb I merged this patch but we should revisit the issue of the gnome bbclass files in a subsequent patch. 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] gcc-cross-kernel: update to match new toolchain sysroot layout
On Mon, 2011-06-27 at 18:56 +0200, Koen Kooi wrote:
The versioned gcc binary gets installed and the needed binutils symlinks are
made.
To make it fully work again the following is needed in kernel recipes/classes:
PATH_prepend = ${STAGING_BINDIR_TOOLCHAIN}.gcc-cross-kernel:
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
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] [PATCH 2/2] sanity: implement network connectivity test
On Sun, 2011-06-26 at 11:08 -0700, Khem Raj wrote: On 06/26/2011 10:37 AM, Joshua Lock wrote: On Sat, 2011-06-25 at 19:33 -0700, Khem Raj wrote: On 6/25/2011 5:53 PM, Saul Wold wrote: + # If no URI's set, fallback to some default ones we know of + if len(test_uris) == 0: + test_uris = [http://yoctoproject.org/about;, + https://eula-downloads.yoctoproject.org/crownbay/crownbay-bernard-5.0.0;, + git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD] + retval = imo this change is yocto specific doesnt belong to core Are you objecting to the feature (testing whether the fetchers can work on a newly configured tmpdir) or the implementation (using yoctoproject.org URI's)? the latter I'd just point out that this is a test URL and turning off a load of checks designed to improve usability just based on the test url seems a little counter-intuitive to improving new user usability of OE. 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/1] libc-locale: split locale handling from libc recipe.
On Tue, 2011-06-28 at 14:17 +0200, Koen Kooi wrote:
Op 28 jun 2011, om 13:07 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-28 at 10:07 +0100, Phil Blundell wrote:
Dongxiao: What Phil is referring to here is that libsotruss${PKGSUFFIX}
disappeared from PACKAGES and that also ${libdir}/audit/.debug
disappeared from FILES_${PN}-dbg.
Specifically these changes came in as part of:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=77c2dd944db42e40cc8467e6bc5a175fed90c251
which I don't think your patch accounted for.
Since this patch has been around for a while and it otherwise looks
good, I've fixed up these couple of issues and merged it though.
This breaks when using eglibc 2.12 :(
Sorry, I've pushed some cleanup to resolve that.
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 0/1] scripts: add PARALLEL_MAKE to BB_ENV_EXTRAWHITE
On Mon, 2011-06-27 at 14:11 -0700, Darren Hart wrote: The following changes since commit a1f79a7896b6411669b3ccada6204d2695e80fc5: runqueue.py: Add umask task control (2011-06-24 12:23:12 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dvhart/pm http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/pm Darren Hart (1): Add PARALLEL_MAKE to BB_ENV_EXTRAWHITE scripts/oe-buildenv-internal |2 +- 1 files changed, 1 insertions(+), 1 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] [PATCH] u-boot-mkimage: bump version to 2011.03
Hi Ilya, On 06/28/2011 02:57 AM, Ilya Yanok wrote: Hi Darren, 28.06.2011 8:09, Darren Hart wrote: These look like good changes to me, with a couple of minor things needed: 1) Please submit the version change independently from the added patches to keep things functionally distinct. Hm.. Actually the new version won't build without the patches, so I think this should be addressed by a single commit. Maybe I should add a note on this in the commit message though... Ah, that is unfortunate :/ 2) The patch from you marked as Submitted: has this received any discussion on the u-boot list? Yes, it's already applied (with some cosmetic changes). I will repost my oe-core with the new versions of U-Boot patches. Please let me know if you still think these should be two separate commits. Please update the upstream status on the new patch and resubmit as a single patch. Thanks! -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v2 PATCH 1/9] Remove support for building 2.4 kernels
Hi Anders,
All seems to work for me. For anyone just dropping these on OE, note there is
a local variable of kernel.bbclass that also needs updating as per this file
in meta-openembedded/meta-oe/
Signed-off-by: Anders Darander
anders-7ujn0b3lyz2sbku13z4...@public.gmane.org
---
meta/classes/kernel.bbclass | 12 ++--
meta/classes/module-base.bbclass |2 +-
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index fd27832..6bdfd3e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -73,9 +73,6 @@ KERNEL_ALT_IMAGETYPE ??=
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake include/linux/version.h CC=${KERNEL_CC} LD=${KERNEL_LD}
- if [ ${KERNEL_MAJOR_VERSION} != 2.6 ]; then
- oe_runmake dep CC=${KERNEL_CC} LD=${KERNEL_LD}
- fi
oe_runmake ${KERNEL_IMAGETYPE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD}
}
@@ -111,9 +108,7 @@ kernel_do_install() {
install -m 0644 vmlinux ${D}/boot/vmlinux-${KERNEL_VERSION}
[ -e Module.symvers ] install -m 0644 Module.symvers
${D}/boot/Module.symvers-${KERNEL_VERSION}
install -d ${D}/etc/modutils
- if [ ${KERNEL_MAJOR_VERSION} = 2.6 ]; then
- install -d ${D}/etc/modprobe.d
- fi
+ install -d ${D}/etc/modprobe.d
#
# Support for external module building - create a minimal copy of the
@@ -397,10 +392,7 @@ python populate_packages_prepend () {
# Write out any modconf fragment
modconf = bb.data.getVar('module_conf_%s' % basename, d, 1)
if modconf:
- if bb.data.getVar(KERNEL_MAJOR_VERSION, d, 1) ==
2.6:
- name = '%s/etc/modprobe.d/%s.conf' % (dvar,
basename)
- else:
- name = '%s/etc/modutils/%s.conf' % (dvar,
basename)
+ name = '%s/etc/modprobe.d/%s.conf' % (dvar, basename)
f = open(name, 'w')
f.write(%s\n % modconf)
f.close()
diff --git a/meta/classes/module-base.bbclass
b/meta/classes/module-base.bbclass
index c98bace..a7cf233 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -7,7 +7,7 @@ export CROSS_COMPILE = ${TARGET_PREFIX}
export KERNEL_VERSION =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}
export KERNEL_SOURCE =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-source')}
-KERNEL_OBJECT_SUFFIX = ${@[.o,
.ko][base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion') 2.6.0]}
+KERNEL_OBJECT_SUFFIX = .ko
KERNEL_CCSUFFIX =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ccsuffix')}
KERNEL_LDSUFFIX =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ldsuffix')}
KERNEL_ARSUFFIX =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-arsuffix')}
___
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] base.bbclass: show layer's branches/revisions in the banner info
On 6/28/11 1:45 AM, Koen Kooi wrote:
Op 28 jun 2011, om 07:37 heeft Dexuan Cui het volgende geschreven:
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/classes/base.bbclass | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 119b052..4766c77 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -165,9 +165,21 @@ python base_eventhandler() {
note(msg)
if name.startswith(BuildStarted):
+corebase = data.getVar(COREBASE, e.data, 1)
+corelayers = [corebase + /meta, corebase + /meta-yocto]
+layers = (data.getVar(BBLAYERS, e.data, 1) or ).split()
+layers = [i for i in layers if i not in corelayers]
+fmt_str = %-27s = \%s\
+layer_branches = [fmt_str % (os.path.basename(i)+_BRANCH, \
+base_get_metadata_git_branch(i, None).strip()) for i in
layers]
+layer_revisions = [fmt_str % (os.path.basename(i)+_REVISION, \
+base_get_metadata_git_revision(i, None)) for i in
layers]
bb.data.setVar( 'BB_VERSION', bb.__version__, e.data )
statusvars = ['BB_VERSION', 'METADATA_BRANCH',
'METADATA_REVISION', 'TARGET_ARCH', 'TARGET_OS', 'MACHINE', 'DISTRO',
'DISTRO_VERSION','TARGET_FPU']
-statuslines = [%-17s = \%s\ % (i, bb.data.getVar(i, e.data,
1) or '') for i in statusvars]
+statuslines = [fmt_str % (i, bb.data.getVar(i, e.data, 1) or
'') for i in statusvars]
+for i in range(len(layer_branches)):
+statuslines.insert(3+2*i, layer_branches[i])
+statuslines.insert(3+2*i+1, layer_revisions[i])
statusmsg = \nOE Build Configuration:\n%s\n %
'\n'.join(statuslines)
print statusmsg
I tried this patch and I get:
OE Build Configuration:
BB_VERSION = 1.13.1
METADATA_BRANCH = master
METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544
meta-angstrom_BRANCH= master
meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647
...
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = beagleboard
DISTRO = angstrom
DISTRO_VERSION = v2011.06-core
TARGET_FPU = hard
So it works as expected, but the output is a bit confusing. I have a few
(conflicting) suggestions:
1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.:
meta-archos branch = master
meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad
2) for the extra layers put branch and revision on a single line:
meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad
3) Move the revision info down, e..g
OE Build Configuration:
BB_VERSION = 1.13.1
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = beagleboard
DISTRO = angstrom
DISTRO_VERSION = v2011.06-core
TARGET_FPU = hard
METADATA_BRANCH = master
METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544
meta-angstrom_BRANCH= master
meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647
etc.
What do you think about that?
I think my preference is either 3 or a combination of 2 3.
To me the important bits are the configuration settings, followed by the
components that are being used as a secondary concern. It will all help in
debugging and issue, but if the target/distro isn't correct then it doesn't
matter what the rest is.
--Mark
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Heads Up: Bitbake minimum version change imminent
I just wanted to let people know that we have a minimum version of bitbake change imminent for OE-Core. I've already pushed the changes we need to bitbake for umask, shared work directory and multilib and updated its version to 1.13.2. I'm planning to merge patches to OE-Core which depend on these changes later this week (and bump the minimum version OE-Core requires at the same time). In case it isn't clear, I've been batching things up to try and ensure we only have to do this once for a variety of improvements :) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v2 PATCH 0/9] Linux 3.0 build support
On Mon, Jun 27, 2011 at 3:39 PM, Anders Darander and...@chargestorm.se wrote:
v2: Probably some more patches could be squashed together. There might also
  be more places that should be addressed in these patches.
  - Whitespace fixes
  - Updated module-init-tools to 3.16. I'm not applying the ignore*.patch
  (it didn't apply).
  - Do not provide virtual/*/depmod-2.6; just provide virtual/*/depmod.
  - Do only install as depmod.
  - Rearrange the order of some patches.
  - Added patches to clean up (partly) task-base, distro_tracking_fields.
  A few of the patches might be ready to pull, but the majority will need
  to be revised.
===
This work is unfinished and incomplete...
It is published in its current form both to get feedback, but also to aid
anyone else who is working on 3.0-support. If some of the patches are found to
be OK, it's fine to cherrypick them.
The series looks pretty good to me. I'm gearing up to complete the 3.0 carry
forward shortly, and I've applied these to my local tree to take them
for a spin.
Cheers,
Bruce
The kernel-related classes has been modified to build a 3.0 kernel. The
patches has been simplified by removing support for the 2.4-series. (The
latter was suggested in an older mail thread:
http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg02682.html
).
The patches has been tested on linux-yocto_2.6.37 and a hacked version using
the linux-yocto-dev repository (using a 3.0-rcX). The latest versions has only
been built for qemuarm, prior iterations has also been built for qemux86.
Finally, no work has been done on the libc-linux-headers classes and recipes.
/Anders
Please review the following changes for suitability for inclusion. If you have
any objections or suggestions for improvement, please respond to the patches.
If
you agree with the changes, please provide your Acked-by.
The following changes since commit 3aec2fa2df9aaa883feda0d7aed85e63d01398b9:
 qemuimagetest: update cvs and iptables to newer version for toolchain test
(2011-06-24 11:28:28 +0100)
are available in the git repository at:
 git://github.com/darander/oe-core kernel-3.0
 https://github.com/darander/oe-core/tree/kernel-3.0
Anders Darander (9):
 Remove support for building 2.4 kernels
 image¡kernel.bblass: do not use depmod-2.6
 modules-init-tools(-cross): update to 3.16
 module-init-tools-cross: do not install depmod as depmod-2.6
 kernel.bblass: remove get_kernelmajorversion
 modutils-initscripts: move recipe prior to modutils removal
 modutils: remove modutils
 task-base: remove modutils reference.
 distro_tracking_fields: remove modutils.
 meta/classes/image.bbclass             |   2 +-
 meta/classes/kernel.bbclass             |  22 ++
 meta/classes/linux-kernel-base.bbclass       |   8 --
 meta/classes/module-base.bbclass          |   2 +-
 .../conf/distro/include/distro_tracking_fields.inc |   8 +--
 meta/recipes-core/tasks/task-base.bb        |  22 +
 .../{modutils = module-init-tools}/files/PD.patch |   0
 .../files/modutils.sh                |   0
 .../module-init-tools-cross_3.12.bb         |  12 ---
 .../module-init-tools-cross_3.16.bb         |   8 ++
 .../module-init-tools/module-init-tools.inc     |   1 -
 ...nit-tools_3.12.bb = module-init-tools_3.16.bb} |   6 +-
 .../modutils-initscripts.bb             |   0
 meta/recipes-kernel/modutils/files/armeb.patch   |  16
 meta/recipes-kernel/modutils/files/configure.patch |  34 ---
 meta/recipes-kernel/modutils/files/gcc4.patch    |  93
 meta/recipes-kernel/modutils/files/lex.l.diff    |  35
 .../modutils/files/modutils-notest.patch      |  16
 .../modutils/files/program_prefix.patch       |  71 ---
 .../recipes-kernel/modutils/modutils-collateral.bb |  21 -
 .../modutils/modutils-cross/module.h.diff      |  35
 .../modutils/modutils-cross_2.4.27.bb        |  20
 meta/recipes-kernel/modutils/modutils_2.4.27.bb   |  93
 23 files changed, 25 insertions(+), 500 deletions(-)
 rename meta/recipes-kernel/{modutils = module-init-tools}/files/PD.patch
(100%)
 rename meta/recipes-kernel/{modutils = module-init-tools}/files/modutils.sh
(100%)
 delete mode 100644
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
 create mode 100644
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
 rename meta/recipes-kernel/module-init-tools/{module-init-tools_3.12.bb =
module-init-tools_3.16.bb} (87%)
 rename meta/recipes-kernel/{modutils =
module-init-tools}/modutils-initscripts.bb (100%)
 delete mode 100644 meta/recipes-kernel/modutils/files/armeb.patch
 delete mode 100644 meta/recipes-kernel/modutils/files/configure.patch
 delete mode 100644
Re: [OE-core] [PATCH 4/7] useradd.bbclass: new class for managing user/group permissions
On 6/28/11 8:04 AM, Richard Purdie wrote:
Hi Scott,
Sorry its taken me a while to get to this. Some comments below.
I think I know the answer to a few of the issues mentioned below. Scott can
correct me if I'm wrong.
On Thu, 2011-06-02 at 16:50 -0700, Scott Garman wrote:
This class is to be used by recipes that need to set up specific
user/group accounts and set custom file/directory permissions.
Signed-off-by: Scott Garman scott.a.gar...@intel.com
---
meta/classes/useradd.bbclass | 163
++
1 files changed, 163 insertions(+), 0 deletions(-)
create mode 100644 meta/classes/useradd.bbclass
diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
new file mode 100644
index 000..3f07e5e
--- /dev/null
+++ b/meta/classes/useradd.bbclass
@@ -0,0 +1,163 @@
+USERADDPN ?= ${PN}
+
+# base-passwd-cross provides the default passwd and group files in the
+# target sysroot, and shadow-native provides the utilities needed to
+# add and modify user and group accounts
+DEPENDS_append = base-passwd shadow-native
+RDEPENDS_${USERADDPN}_append = base-passwd shadow
+
+PSEUDO=${STAGING_DIR_NATIVE}/usr/bin/pseudo
+export PSEUDO
For reference this can be done with:
export PSEUDO = ${STAGING_DIR_NATIVE}/usr/bin/pseudo
+PSEUDO_LOCALSTATEDIR=${STAGING_DIR_TARGET}/var/pseudo
+export PSEUDO_LOCALSTATEDIR
I'm a little bit puzzled at this point. This is changing the default
PSEUDO state directory to be one shared by many other users rather than
the default of the one in workdir. Is that really what you intend here?
I guess the question is whether we need to preserve these users in the
sysroot or whether preserving them for the install/package/package_write
cycle is enough.
If we're populating the sysroot, we need to have a pseudo directory setup for it
so that we can run the adduser/group items. The new adduser/group require the
ability to chroot into a (pseudo) root. The above should only kick in while
working with sysroots.
Since tasks don't share the same pseudo context by default, I suspect
we're not preserving users for the sysroot anyhow?
Users are added/preserved within the sysroot /etc/passwd,group in the code.
There is a separate section that runs at sysroot population time that adds the
necessary users/groups... but as mentioned we need the chroot functionality to
do the settings. (The uid/gid of the files themselves doesn't matter in the
sysroot.)
+PSEUDO_PASSWD = ${STAGING_DIR_TARGET}
+export PSEUDO_PASSWD
Should we set this by default as part of the pseudo options in
bitbake.conf?
Yes, this likely should go into the bitbake.conf now. I believe it is in here
though for the same reason that the above was. It's needed during the sysroot
configuration and the way the utilities work when chrooted.
+useradd_preinst () {
+OPT=
+SYSROOT=
+
+if test x$D != x; then
+# Installing into a sysroot
+SYSROOT=${STAGING_DIR_TARGET}
+OPT=--root ${STAGING_DIR_TARGET}
+
+# Add groups and users defined for all recipe packages
+GROUPADD_PARAM=${@get_all_cmd_params(d, 'group')}
+USERADD_PARAM=${@get_all_cmd_params(d, 'user')}
+else
+# Installing onto a target
+PSEUDO=
+
+# Add groups and users defined only for this package
+GROUPADD_PARAM=${GROUPADD_PARAM}
+USERADD_PARAM=${USERADD_PARAM}
+fi
+
+# Perform group additions first, since user additions may depend
+# on these groups existing
+if test x$GROUPADD_PARAM != x; then
+echo Running groupadd commands...
+# Invoke multiple instances of groupadd for parameter lists
+# separated by ';'
+opts=`echo $GROUPADD_PARAM | cut -d ';' -f 1`
+remaining=`echo $GROUPADD_PARAM | cut -d ';' -f 2-`
+while test x$opts != x; do
+eval $PSEUDO groupadd -f $OPT $opts
If this task is already running under pseudo, do we specifically need to
run under pseudo here? Is it not already running under pseudo when
needed?
See answer below...
+if test x$opts = x$remaining; then
+break
+fi
+opts=`echo $remaining | cut -d ';' -f 1`
+remaining=`echo $remaining | cut -d ';' -f 2-`
+done
+fi
+
+if test x$USERADD_PARAM != x; then
+echo Running useradd commands...
+# Invoke multiple instances of useradd for parameter lists
+# separated by ';'
+opts=`echo $USERADD_PARAM | cut -d ';' -f 1`
+remaining=`echo $USERADD_PARAM | cut -d ';' -f 2-`
+while test x$opts != x; do
+# useradd does not have a -f option, so we have to check if the
+# username already exists manually
+username=`echo $opts | awk '{ print $NF }'`
+user_exists=`grep ^$username: $SYSROOT/etc/passwd || true`
+if test x$user_exists = x; then
+eval $PSEUDO useradd $OPT $opts
+else
+echo Note:
Re: [OE-core] [Draft design][RFC] Running postinst at rootfs generation time
On 6/28/11 8:15 AM, Richard Purdie wrote: On Mon, 2011-06-27 at 23:11 -0500, Mark Hatle wrote: On 6/27/11 9:09 PM, Cui, Dexuan wrote: Hi all, below is an initial investigation about the task and we'll continue to further look into it. In poky we have 2 types of postinst scripts: one (type-1) can be (and has already been) run at rootfs generation time and the other (type-2) has to be delayed to the first-boot of target device. Type-2 makes target device's first-boot slow and it would be great if we can fix it and convert it to type-1. We can instrument a first-boot with minimal/sato first to see which postinstalls take the most time and then prioritise those ones to fix. I figurerd out a list of 33 recipes in total(recipes with the same name but with different versions are counted once) we possibly need to fix. For the recipes, we need try to find recipe-specific ways(use appropriately modified native utilities to generate caches, files, etc as necessary on the target filesystem). ... 1 recipe: prelink: we could propablly fix it, but I'm not sure yet. meta/recipes-devtools/prelink/prelink_git.bb There is nothing to do for the prelinker. The image-prelink.bbclass handles everything needed to prelink during image creation. The script is only there for on-target field upgrades. So you can remove this from your list. Mark, are you 100% sure about this? It looks like if we install prelink into an image it adds a post install which runs prelink -a on the target device at first boot. This would happen regardless of whether the cross prelinker did or did not prelink the image :/. That is certainly not the intention of this code. If it does, it should be a fairly quick bug to fix -- and improve boot-time. (Of course, this only should be skipped if we've done image-prelink.bbclass.) I'll attempt to look into this shortly --Mark Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4 V4] Share gcc work directories
Hi Robert,
I just wanted to let you know that these look good, thanks.
I need to get the changes into bitbake for this first (along with the
umask and multilib changes), let that version sit for a vew days, them
bump the version requirement of OE-Core so we can then merge these
patches.
They will therefore merge and I'm happy with them but it will be a few
more days before that happens. The bitbake piece is now merged already.
Cheers,
Richard
On Tue, 2011-06-28 at 17:05 +0800, Robert Yang wrote:
Changes of V4:
* Change the definition of GLIBC_DYNAMIC_LINKER as Richard suggested.
e.g., the entries in the files that look like:
#define GLIBC_DYNAMIC_LINKER64 /lib64/ld-linux-x86-64.so.2
become
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
and we define SYSTEMLIBS_DIR in defaults.h.
NOTE, the round brackets:
#define GLIBC_DYNAMIC_LINKER64 (SYSTEMLIBS_DIR /ld-linux-x86-64.so.2)
doesn't work in in the following define:
#define LINUX_DYNAMIC_LINKER \
CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER)
so use:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
* Compare to V3, reduce two patches which are for gcc-crosssdk.inc and
gcc-cross-canadian which are not needed any more.
* Fix the conflicts(gcc-4.6.0 - gcc-4.6, and the ${BRANCH})
* Both tested 4.5.1 and 4.6:
$ bitbake meta-toolchain core-image-sato
$ runqemu qemurm
Also unpack the sdk to /opt and test to make sure the toolchain works well.
The following changes since commit a1f79a7896b6411669b3ccada6204d2695e80fc5:
runqueue.py: Add umask task control (2011-06-24 12:23:12 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib robert/share_gcc
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/share_gcc
Robert Yang (4):
bitbake: share source directory
Share gcc work directories
gcc-4.5.1: share work directories
gcc-4.6: share work directories
bitbake/lib/bb/build.py|4 +-
bitbake/lib/bb/cache.py|3 +
bitbake/lib/bb/runqueue.py | 10 +++
meta/recipes-devtools/gcc/gcc-4.5.1.inc|1 +
.../gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch | 57 ++
meta/recipes-devtools/gcc/gcc-4.6.inc |5 +-
.../gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch | 80
meta/recipes-devtools/gcc/gcc-common.inc | 32 +++-
meta/recipes-devtools/gcc/gcc-configure-common.inc | 48 +++-
meta/recipes-devtools/gcc/gcc-configure-cross.inc |4 +-
meta/recipes-devtools/gcc/gcc-crosssdk.inc |6 --
11 files changed, 218 insertions(+), 32 deletions(-)
create mode 100644
meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
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] base.bbclass: show layer's branches/revisions in the banner info
Mark Hatle wrote: On 6/28/11 1:45 AM, Koen Kooi wrote: Op 28 jun 2011, om 07:37 heeft Dexuan Cui het volgende geschreven: ... So it works as expected, but the output is a bit confusing. I have a few (conflicting) suggestions: 1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.: meta-archos branch = master meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad 2) for the extra layers put branch and revision on a single line: meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad 3) Move the revision info down, e..g OE Build Configuration: BB_VERSION = 1.13.1 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beagleboard DISTRO = angstrom DISTRO_VERSION = v2011.06-core TARGET_FPU = hard METADATA_BRANCH = master METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544 meta-angstrom_BRANCH= master meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647 etc. What do you think about that? I think my preference is either 3 or a combination of 2 3. To me the important bits are the configuration settings, followed by the components that are being used as a secondary concern. It will all help in debugging and issue, but if the target/distro isn't correct then it doesn't matter what the rest is. --Mark Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Please note I use a colon mark rather than a slash mark for better readabability since a branch name can contain colon. An output result in my side is: OE Build Configuration: BB_VERSION = 1.13.1 TARGET_ARCH = i586 TARGET_OS = linux MACHINE = qemux86 DISTRO = poky DISTRO_VERSION = 1.0+snapshot-20110628 TARGET_FPU = METADATA_BRANCH = dcui/banner_v2 METADATA_REVISION = 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 meta-sugarbay = dcui/test1:76d1178ba1a43cf6457c89717134aeb9f1275fae Please let me know if this new output looks ok. BTW, Koen, even with this v2 patch, the list looks still pretty long in your side. I noticed there are some layers with the same revision: e.g., meta-htc_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-nokia_BRANCH = master meta-nokia_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-openmoko_BRANCH= master meta-openmoko_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-palm_BRANCH= master meta-palm_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-zaurus_BRANCH = master meta-zaurus_REVISION= f37d05ca7450f85642cea0e43a75df10663bd8f6 I guess they actually belong to the same repo. In this case, maybe we can further improve the output format to: meta-htc,nokia,openmoko,palm,zaurus:f37d05ca7450f85642cea0e43a75df10663bd8f6 ? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] u-boot-mkimage: bump version to 2011.03
This patch changes u-boot-mkimage version to 2011.03. Unfortunately U-Boot 2011.03 release has some problems building tools from unconfigured tree, so this patch aslo includes the backported fixes. Signed-off-by: Ilya Yanok ya...@emcraft.com --- ...Drop-config.h-include-in-tools-imximage.h.patch | 39 + ...ove-LDSCRIPT-processing-to-the-top-level-.patch | 82 .../uboot/u-boot-mkimage-native_1.3.2.bb | 25 -- meta/recipes-bsp/uboot/u-boot-mkimage_2009.08.bb | 29 --- meta/recipes-bsp/uboot/u-boot-mkimage_2011.03.bb | 31 5 files changed, 152 insertions(+), 54 deletions(-) create mode 100644 meta/recipes-bsp/uboot/u-boot-mkimage-2011.03/0001-Drop-config.h-include-in-tools-imximage.h.patch create mode 100644 meta/recipes-bsp/uboot/u-boot-mkimage-2011.03/0002-config.mk-move-LDSCRIPT-processing-to-the-top-level-.patch delete mode 100644 meta/recipes-bsp/uboot/u-boot-mkimage-native_1.3.2.bb delete mode 100644 meta/recipes-bsp/uboot/u-boot-mkimage_2009.08.bb create mode 100644 meta/recipes-bsp/uboot/u-boot-mkimage_2011.03.bb diff --git a/meta/recipes-bsp/uboot/u-boot-mkimage-2011.03/0001-Drop-config.h-include-in-tools-imximage.h.patch b/meta/recipes-bsp/uboot/u-boot-mkimage-2011.03/0001-Drop-config.h-include-in-tools-imximage.h.patch new file mode 100644 index 000..f4b12ac --- /dev/null +++ b/meta/recipes-bsp/uboot/u-boot-mkimage-2011.03/0001-Drop-config.h-include-in-tools-imximage.h.patch @@ -0,0 +1,39 @@ +From ce56e089ddb51dbd81bb2c86b1646d77447afe39 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Lo=C3=AFc=20Minier?= loic.min...@linaro.org +Date: Thu, 3 Feb 2011 15:07:01 +0100 +Subject: Drop config.h include in tools/imximage.h +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Upstream-Status: Applied + +make tools-all should allow building tools such as mkimage and the new +imximage without any config, but imximage.c currently fails to build +with: +imximage.h:27:20: error: config.h: No such file or directory + +config.h is not needed in imximage.h nor in imximage.c, and imximage.h +is only included from imximage.c, so drop this include to fix the build. + +Signed-off-by: Lo�c Minier loic.min...@linaro.org +--- + tools/imximage.h |2 -- + 1 files changed, 0 insertions(+), 2 deletions(-) + +diff --git a/tools/imximage.h b/tools/imximage.h +index 38ca6be..d126a46 100644 +--- a/tools/imximage.h b/tools/imximage.h +@@ -24,8 +24,6 @@ + #ifndef _IMXIMAGE_H_ + #define _IMXIMAGE_H_ + +-#include config.h +- + #define MAX_HW_CFG_SIZE_V2 121 /* Max number of registers imx can set for v2 */ + #define MAX_HW_CFG_SIZE_V1 60 /* Max number of registers imx can set for v1 */ + #define APP_CODE_BARKER 0xB1 +-- +1.7.4.4 + diff --git a/meta/recipes-bsp/uboot/u-boot-mkimage-2011.03/0002-config.mk-move-LDSCRIPT-processing-to-the-top-level-.patch b/meta/recipes-bsp/uboot/u-boot-mkimage-2011.03/0002-config.mk-move-LDSCRIPT-processing-to-the-top-level-.patch new file mode 100644 index 000..c102691 --- /dev/null +++ b/meta/recipes-bsp/uboot/u-boot-mkimage-2011.03/0002-config.mk-move-LDSCRIPT-processing-to-the-top-level-.patch @@ -0,0 +1,82 @@ +From fd1b50c5ff9c288040abf5e78815151327d32e0e Mon Sep 17 00:00:00 2001 +From: Ilya Yanok ya...@emcraft.com +Date: Mon, 20 Jun 2011 12:45:37 + +Subject: config.mk: move LDSCRIPT processing to the top-level Makefile + +Upstream-Status: Applied + +LDSCRIPT is used only from the top-level Makefile and only when the +system is configured so we can move LDSCRIPT and CONFIG_SYS_LDSCRIPT +related logic into the top level Makefile and under configured condition +to avoid errors when building tools from unconfigured tree. + +Signed-off-by: Ilya Yanok ya...@emcraft.com +Acked-by: Mike Frysinger vap...@gentoo.org +--- + Makefile | 30 ++ + config.mk |8 + 2 files changed, 30 insertions(+), 8 deletions(-) + +diff --git a/Makefile b/Makefile +index ece91ab..358c410 100644 +--- a/Makefile b/Makefile +@@ -163,6 +163,36 @@ endif + # load other configuration + include $(TOPDIR)/config.mk + ++# If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use ++# that (or fail if absent). Otherwise, search for a linker script in a ++# standard location. ++ ++ifndef LDSCRIPT ++ #LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds.debug ++ ifdef CONFIG_SYS_LDSCRIPT ++ # need to strip off double quotes ++ LDSCRIPT := $(subst ,,$(CONFIG_SYS_LDSCRIPT)) ++ endif ++endif ++ ++ifndef LDSCRIPT ++ ifeq ($(CONFIG_NAND_U_BOOT),y) ++ LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds ++ ifeq ($(wildcard $(LDSCRIPT)),) ++ LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds ++ endif ++ endif ++ ifeq ($(wildcard $(LDSCRIPT)),) ++ LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds ++
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Op 28 jun 2011, om 16:52 heeft Cui, Dexuan het volgende geschreven: Mark Hatle wrote: On 6/28/11 1:45 AM, Koen Kooi wrote: Op 28 jun 2011, om 07:37 heeft Dexuan Cui het volgende geschreven: ... So it works as expected, but the output is a bit confusing. I have a few (conflicting) suggestions: 1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.: meta-archos branch = master meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad 2) for the extra layers put branch and revision on a single line: meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad 3) Move the revision info down, e..g OE Build Configuration: BB_VERSION = 1.13.1 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beagleboard DISTRO = angstrom DISTRO_VERSION = v2011.06-core TARGET_FPU = hard METADATA_BRANCH = master METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544 meta-angstrom_BRANCH= master meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647 etc. What do you think about that? I think my preference is either 3 or a combination of 2 3. To me the important bits are the configuration settings, followed by the components that are being used as a secondary concern. It will all help in debugging and issue, but if the target/distro isn't correct then it doesn't matter what the rest is. --Mark Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Could you in the future please base them on oe-core instead of poky? I just did 'git merge 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836' and git blew up. ___ 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] base.bbclass: show layer's branches/revisions in the banner info
Op 28 jun 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
On 6/28/11 1:45 AM, Koen Kooi wrote:
Op 28 jun 2011, om 07:37 heeft Dexuan Cui het volgende geschreven:
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/classes/base.bbclass | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 119b052..4766c77 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -165,9 +165,21 @@ python base_eventhandler() {
note(msg)
if name.startswith(BuildStarted):
+ corebase = data.getVar(COREBASE, e.data, 1)
+ corelayers = [corebase + /meta, corebase + /meta-yocto]
+ layers = (data.getVar(BBLAYERS, e.data, 1) or ).split()
+ layers = [i for i in layers if i not in corelayers]
+ fmt_str = %-27s = \%s\
+ layer_branches = [fmt_str % (os.path.basename(i)+_BRANCH, \
+ base_get_metadata_git_branch(i, None).strip()) for i in
layers]
+ layer_revisions = [fmt_str % (os.path.basename(i)+_REVISION, \
+ base_get_metadata_git_revision(i, None)) for i in
layers]
bb.data.setVar( 'BB_VERSION', bb.__version__, e.data )
statusvars = ['BB_VERSION', 'METADATA_BRANCH',
'METADATA_REVISION', 'TARGET_ARCH', 'TARGET_OS', 'MACHINE', 'DISTRO',
'DISTRO_VERSION','TARGET_FPU']
- statuslines = [%-17s = \%s\ % (i, bb.data.getVar(i, e.data,
1) or '') for i in statusvars]
+ statuslines = [fmt_str % (i, bb.data.getVar(i, e.data, 1) or
'') for i in statusvars]
+ for i in range(len(layer_branches)):
+ statuslines.insert(3+2*i, layer_branches[i])
+ statuslines.insert(3+2*i+1, layer_revisions[i])
statusmsg = \nOE Build Configuration:\n%s\n %
'\n'.join(statuslines)
print statusmsg
I tried this patch and I get:
OE Build Configuration:
BB_VERSION = 1.13.1
METADATA_BRANCH = master
METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544
meta-angstrom_BRANCH= master
meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647
...
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = beagleboard
DISTRO = angstrom
DISTRO_VERSION = v2011.06-core
TARGET_FPU = hard
So it works as expected, but the output is a bit confusing. I have a few
(conflicting) suggestions:
1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.:
meta-archos branch = master
meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad
2) for the extra layers put branch and revision on a single line:
meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad
3) Move the revision info down, e..g
OE Build Configuration:
BB_VERSION = 1.13.1
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = beagleboard
DISTRO = angstrom
DISTRO_VERSION = v2011.06-core
TARGET_FPU = hard
METADATA_BRANCH = master
METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544
meta-angstrom_BRANCH= master
meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647
etc.
What do you think about that?
I think my preference is either 3 or a combination of 2 3.
To me the important bits are the configuration settings, followed by the
components that are being used as a secondary concern. It will all help in
debugging and issue, but if the target/distro isn't correct then it doesn't
matter what the rest is.
The current patch outputs the following:
OE Build Configuration:
BB_VERSION = 1.13.2
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = beagleboard
DISTRO = angstrom
DISTRO_VERSION = v2011.06-core
TARGET_FPU = hard
METADATA_BRANCH = master
METADATA_REVISION = f1c2bfb82e0d11955cb8dc6b2f7aca9e291e1269
meta-angstrom = master:a3bb1d65ae008b32a20701f479dea59e8268f806
meta-oe = master:8a12ecca32766ecdceb72cae76e93f8aadcf3669
meta-efl= master:8a12ecca32766ecdceb72cae76e93f8aadcf3669
meta-gpe= master:8a12ecca32766ecdceb72cae76e93f8aadcf3669
meta-gnome = master:8a12ecca32766ecdceb72cae76e93f8aadcf3669
meta-texasinstruments = master:2e16e2fbd93bc00bc0a0afaf86975da7778eaa43
meta-efikamx= master:70cff8742d629fd32463e3ef1bddb83f04d08dc5
meta-nslu2 = master:aaf918b85d7a8155d6e7c0ff042808346998fbea
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Koen Kooi wrote: Op 28 jun 2011, om 16:52 heeft Cui, Dexuan het volgende geschreven: Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Could you in the future please base them on oe-core instead of poky? I just did 'git merge 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836' and git blew up. Sorry... but to basing them on oe-core, do I need the permission to push my commits to my own branch in git://git.openembedded.org/openembedded-core-contrib? I suppose so and I should put my public key somewhere into the server? Thanks, -- Dexuan ___ 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] base.bbclass: show layer's branches/revisions in the banner info
On Tue, 2011-06-28 at 23:21 +0800, Cui, Dexuan wrote: Sorry... but to basing them on oe-core, do I need the permission to push my commits to my own branch in git://git.openembedded.org/openembedded-core-contrib? I suppose so and I should put my public key somewhere into the server? You don't need to do that. You can just make a repo on github or gitorious (or your own server, or even one of the yocto hosts) and clone oe-core into it. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc-locale: fix localedef packaging
the ${PN} still needs some checking, since it will now inheriting the default
FILES_${PN}
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-core/eglibc/eglibc-locale.inc |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-locale.inc
b/meta/recipes-core/eglibc/eglibc-locale.inc
index ed6c099..fdc4fb4 100644
--- a/meta/recipes-core/eglibc/eglibc-locale.inc
+++ b/meta/recipes-core/eglibc/eglibc-locale.inc
@@ -26,12 +26,12 @@ BINARY_LOCALE_ARCHES ?= arm.* i[3-6]86 x86_64 powerpc mips
# set 0 for qemu emulation of native localedef for locale generation
LOCALE_GENERATION_WITH_CROSS-LOCALEDEF = 1
-PR = r0
+PR = r1
PKGSUFFIX =
PKGSUFFIX_virtclass-nativesdk = -nativesdk
-PACKAGES = eglibc-locale localedef${PKGSUFFIX}
+PACKAGES = localedef${PKGSUFFIX} glibc-locale
PACKAGES_DYNAMIC = locale-base-* \
eglibc-gconv-* eglibc-charmap-* eglibc-localedata-*
eglibc-binary-localedata-* \
--
1.6.6.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/1] base.bbclass: show layer's branches/revisions in the banner info
On 6/28/11 10:21 AM, Cui, Dexuan wrote: Koen Kooi wrote: Op 28 jun 2011, om 16:52 heeft Cui, Dexuan het volgende geschreven: Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Could you in the future please base them on oe-core instead of poky? I just did 'git merge 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836' and git blew up. Sorry... but to basing them on oe-core, do I need the permission to push my commits to my own branch in git://git.openembedded.org/openembedded-core-contrib? I suppose so and I should put my public key somewhere into the server? You can push oe-core (based) changes to the poky-contrib tree. Many of us do this regularly. I base my changes usually on oe-core, unless they contain poky specific code.. I push both types to the same poky-contrib repository (in different branches of course). (I also always avoid merge, and always use cherry-pick when pulling code from someone else's branches into my own..) --Mark Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ 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] base.bbclass: show layer's branches/revisions in the banner info
Mark Hatle wrote: On 6/28/11 10:21 AM, Cui, Dexuan wrote: Koen Kooi wrote: Op 28 jun 2011, om 16:52 heeft Cui, Dexuan het volgende geschreven: Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Could you in the future please base them on oe-core instead of poky? I just did 'git merge 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836' and git blew up. Sorry... but to basing them on oe-core, do I need the permission to push my commits to my own branch in git://git.openembedded.org/openembedded-core-contrib? I suppose so and I should put my public key somewhere into the server? You can push oe-core (based) changes to the poky-contrib tree. Many of us do this regularly. I base my changes usually on oe-core, unless they contain poky specific code.. I push both types to the same poky-contrib repository (in different branches of course). (I also always avoid merge, and always use cherry-pick when pulling code from someone else's branches into my own..) Thank Mark and Phil a lot for the explanation! I'll base my change to oe-core in future. Thanks, -- Dexuan ___ 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] base.bbclass: show layer's branches/revisions in the banner info
Op 28 jun 2011, om 17:33 heeft Mark Hatle het volgende geschreven: On 6/28/11 10:21 AM, Cui, Dexuan wrote: Koen Kooi wrote: Op 28 jun 2011, om 16:52 heeft Cui, Dexuan het volgende geschreven: Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Could you in the future please base them on oe-core instead of poky? I just did 'git merge 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836' and git blew up. Sorry... but to basing them on oe-core, do I need the permission to push my commits to my own branch in git://git.openembedded.org/openembedded-core-contrib? I suppose so and I should put my public key somewhere into the server? You can push oe-core (based) changes to the poky-contrib tree. Many of us do this regularly. I base my changes usually on oe-core, unless they contain poky specific code.. I push both types to the same poky-contrib repository (in different branches of course). (I also always avoid merge, and always use cherry-pick when pulling code from someone else's branches into my own..) I tend to do that as well, but I was paying attention to the yocto phone call instead of the console :) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc-locale: fix localedef packaging
On Tue, 2011-06-28 at 17:30 +0200, Koen Kooi wrote:
the ${PN} still needs some checking, since it will now inheriting the default
FILES_${PN}
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
I merged a different version of this which drops PN-locale and fixes
glibc too.
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] u-boot-mkimage: bump version to 2011.03
On Tue, 2011-06-28 at 16:54 +0200, Ilya Yanok wrote: This patch changes u-boot-mkimage version to 2011.03. Unfortunately U-Boot 2011.03 release has some problems building tools from unconfigured tree, so this patch aslo includes the backported fixes. Signed-off-by: Ilya Yanok ya...@emcraft.com 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] [Draft design][RFC] Running postinst at rootfs generation time
Beside the discussed changes, the postinst scripts should be executed in the dependency order. At the time, the scripts are executed in alphabetic order, which breaks the image generation if depended packages are not in alphabetic order. e.g. busybox and busybox subpackages (busybox-mdev). Regards Wolfgang Hauser ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tune files and knobs to turn
On 06/24/2011 04:54 AM, Koen Kooi wrote: Hi, We discussed tune files a bit during last nights TSC meeting and Khem had expressed the need before, so I'd like to get this discussion started by using armv7a as an example. For armv7a capable cores we have the following hardware features: * armv7a instruction set * thumb1 instruction set * thumb2 instruction set * VFP coprocessor * optional NEON coprocessor For the ABI we can choose the following: * softtp without hw support (e.g. no VFP instructions emitted, slow) * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast) * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw, incompatible with everything else And the extra knobs: * pure thumb1, no arm instructions (limited use) * thumb1/arm interworking * pure thumb2, no arm instructions * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage) In OE .dev we have the following vars: TARGET_FPU: switches between hw float and sw float, no reflection in package arch ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or 'armv7a-hardfp' as package arch ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch THUMB_INTERWORK: turns on interworking, no reflection in package arch (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU for armv7a and will generate slow code, angstrom does turn it on) oe-core tune-cortexa8.inc doesn't make use of these variables (unlike meta-texasinstruments) and does make use of the neon coprocessor, but still uses the softfp float-api: TARGET_CC_ARCH = -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize Seems like the oe-core tune files need to be synced up with vendor layers? -- Darren Khem and I would like to start building armv7a (and armv6) in pure thumb2 mode but we want to have the variables to turn those knobs make sense and be consistent. RP has expressed his desire to sort this all out before merging multilib. I'm sure x86/mips/ppc/etc have a similar need, so let's get this discussion started. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tune files and knobs to turn
Op 28 jun 2011, om 19:36 heeft Darren Hart het volgende geschreven: On 06/24/2011 04:54 AM, Koen Kooi wrote: Hi, We discussed tune files a bit during last nights TSC meeting and Khem had expressed the need before, so I'd like to get this discussion started by using armv7a as an example. For armv7a capable cores we have the following hardware features: * armv7a instruction set * thumb1 instruction set * thumb2 instruction set * VFP coprocessor * optional NEON coprocessor For the ABI we can choose the following: * softtp without hw support (e.g. no VFP instructions emitted, slow) * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast) * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw, incompatible with everything else And the extra knobs: * pure thumb1, no arm instructions (limited use) * thumb1/arm interworking * pure thumb2, no arm instructions * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage) In OE .dev we have the following vars: TARGET_FPU: switches between hw float and sw float, no reflection in package arch ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or 'armv7a-hardfp' as package arch ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch THUMB_INTERWORK: turns on interworking, no reflection in package arch (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU for armv7a and will generate slow code, angstrom does turn it on) oe-core tune-cortexa8.inc doesn't make use of these variables (unlike meta-texasinstruments) and does make use of the neon coprocessor, but still uses the softfp float-api: TARGET_CC_ARCH = -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize Don't confuse softfp calling conventions with softfloat! The above will still emit vfp and neon instructions if your set TARGET_FPU = hard regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tune files and knobs to turn
On 06/28/2011 10:38 AM, Koen Kooi wrote: Op 28 jun 2011, om 19:36 heeft Darren Hart het volgende geschreven: On 06/24/2011 04:54 AM, Koen Kooi wrote: Hi, We discussed tune files a bit during last nights TSC meeting and Khem had expressed the need before, so I'd like to get this discussion started by using armv7a as an example. For armv7a capable cores we have the following hardware features: * armv7a instruction set * thumb1 instruction set * thumb2 instruction set * VFP coprocessor * optional NEON coprocessor For the ABI we can choose the following: * softtp without hw support (e.g. no VFP instructions emitted, slow) * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast) * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw, incompatible with everything else And the extra knobs: * pure thumb1, no arm instructions (limited use) * thumb1/arm interworking * pure thumb2, no arm instructions * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage) In OE .dev we have the following vars: TARGET_FPU: switches between hw float and sw float, no reflection in package arch ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or 'armv7a-hardfp' as package arch ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch THUMB_INTERWORK: turns on interworking, no reflection in package arch (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU for armv7a and will generate slow code, angstrom does turn it on) oe-core tune-cortexa8.inc doesn't make use of these variables (unlike meta-texasinstruments) and does make use of the neon coprocessor, but still uses the softfp float-api: TARGET_CC_ARCH = -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize Don't confuse softfp calling conventions with softfloat! The above will still emit vfp and neon instructions if your set TARGET_FPU = hard Ah. So we would need to add something like: conf/distro/include/angstrom.inc:TARGET_FPU_armv7a ?= hard conf/distro/include/angstrom.inc:TARGET_FPU_armv7a-vfp ?= hard to something DISTRO specific (poky.conf or similar). It isn't clear to me why this is a distro policy decision instead of part of the tune include or the machine config itself. Can someone elaborate on why this goes where it does? Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tune files and knobs to turn
Op 28 jun 2011, om 21:13 heeft Darren Hart het volgende geschreven: On 06/28/2011 10:38 AM, Koen Kooi wrote: Op 28 jun 2011, om 19:36 heeft Darren Hart het volgende geschreven: On 06/24/2011 04:54 AM, Koen Kooi wrote: Hi, We discussed tune files a bit during last nights TSC meeting and Khem had expressed the need before, so I'd like to get this discussion started by using armv7a as an example. For armv7a capable cores we have the following hardware features: * armv7a instruction set * thumb1 instruction set * thumb2 instruction set * VFP coprocessor * optional NEON coprocessor For the ABI we can choose the following: * softtp without hw support (e.g. no VFP instructions emitted, slow) * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast) * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw, incompatible with everything else And the extra knobs: * pure thumb1, no arm instructions (limited use) * thumb1/arm interworking * pure thumb2, no arm instructions * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage) In OE .dev we have the following vars: TARGET_FPU: switches between hw float and sw float, no reflection in package arch ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or 'armv7a-hardfp' as package arch ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch THUMB_INTERWORK: turns on interworking, no reflection in package arch (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU for armv7a and will generate slow code, angstrom does turn it on) oe-core tune-cortexa8.inc doesn't make use of these variables (unlike meta-texasinstruments) and does make use of the neon coprocessor, but still uses the softfp float-api: TARGET_CC_ARCH = -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize Don't confuse softfp calling conventions with softfloat! The above will still emit vfp and neon instructions if your set TARGET_FPU = hard Ah. So we would need to add something like: conf/distro/include/angstrom.inc:TARGET_FPU_armv7a ?= hard conf/distro/include/angstrom.inc:TARGET_FPU_armv7a-vfp ?= hard to something DISTRO specific (poky.conf or similar). That won't work because FEED_ARCH/BASE_PACKAGE_ARCH isn't in overrides for oe-core/poky It isn't clear to me why this is a distro policy decision instead of part of the tune include or the machine config itself. Can someone elaborate on why this goes where it does? It isn't inherently hardware specific and might need to link to evil sourceless binaries from $evil_vendor and you want to be able to have your DISTRO control that knob. There are other usecases as well, but the evil vendor one is the most common. ___ 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] libc-locale: split locale handling from libc recipe.
Op 28 jun 2011, om 16:00 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-28 at 14:17 +0200, Koen Kooi wrote:
Op 28 jun 2011, om 13:07 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-28 at 10:07 +0100, Phil Blundell wrote:
Dongxiao: What Phil is referring to here is that libsotruss${PKGSUFFIX}
disappeared from PACKAGES and that also ${libdir}/audit/.debug
disappeared from FILES_${PN}-dbg.
Specifically these changes came in as part of:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=77c2dd944db42e40cc8467e6bc5a175fed90c251
which I don't think your patch accounted for.
Since this patch has been around for a while and it otherwise looks
good, I've fixed up these couple of issues and merged it though.
This breaks when using eglibc 2.12 :(
Sorry, I've pushed some cleanup to resolve that.
So after my shlib renaming patch I still can't build any image, since
locale-base-* has disappeared. Is there anything related to libc and
libc-locales this patch *didn't* break?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Building behind a firewall/proxy
All, For the Yocto 1.1 release we want to ease the pain of getting set up to build behind a firewall. I have a series of patches under development to run a one hit sanity test which tries to verify the user can fetch and in the case of failure point the user to a wiki page where we'd document common causes of fetch failures. We're also going to look at the site.conf file, which can be used to specify proxy settings and other site specific settings such MIRRORS, and ensure that it can easily be edited to help people get set up. It'd be great if people who operate behind a proxy/firewall can help us document the steps they had to take to work around this. Further if you have other ideas as to how we can help make this process less painful please let us know. Regards, Joshua -- Joshua Lock Yocto Project Johannes factotum 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] Building behind a firewall/proxy
Op 28 jun 2011, om 22:14 heeft Joshua Lock het volgende geschreven: All, For the Yocto 1.1 release we want to ease the pain of getting set up to build behind a firewall. I have a series of patches under development to run a one hit sanity test which tries to verify the user can fetch and in the case of failure point the user to a wiki page where we'd document common causes of fetch failures. We're also going to look at the site.conf file, which can be used to specify proxy settings and other site specific settings such MIRRORS, and ensure that it can easily be edited to help people get set up. It'd be great if people who operate behind a proxy/firewall can help us document the steps they had to take to work around this. Further if you have other ideas as to how we can help make this process less painful please let us know. This is what I'm using inside TI: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/setup-scripts/tree/oebb.sh?h=oe-core It grew organically, so grepping for 'proxy' is your best bet :) regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tune files and knobs to turn
On Fri, Jun 24, 2011 at 7:12 AM, Mark Hatle mark.ha...@windriver.com wrote: A few, what I suspect are corrections.  (I'm going to be a bit pedantic here.) On 6/24/11 6:54 AM, Koen Kooi wrote: Hi, We discussed tune files a bit during last nights TSC meeting and Khem had expressed the need before, so I'd like to get this discussion started by using armv7a as an example. For armv7a capable cores we have the following hardware features: * armv7a instruction set * thumb1 instruction set * thumb2 instruction set * VFP coprocessor * optional NEON coprocessor For the ABI we can choose the following: * softtp without hw support (e.g. no VFP instructions emitted, slow) * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast) * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw, incompatible with everything else Actually on ARM there are three ABIs possible but those are not it. OABI - softfp OABI - hardfp EABI OABI is probably something we should drop in this era. So we are left with a. EABI + soft float ( No hard fp at all) b. EABI + soft vfp ( Use softfloat calling convention but utilize hardfp instruction in code generation) c. EABI + hardfp ( use hardfp for parameter passing and use hard fp instructions as desrired) now with hardfp there could be that we use neon or we use vfp only. and in vfp there are two variants vfp-d16 and vfp-d32 there are some implementations of armv7 where neon is not part of SOC and some implement vfp-d16 and some vfp-d32. This greatly affects option b. and c. above in above case. a and b are compatible provided hardware supports neon/vfp but c. is not compatible and toolchain obviously needs to be configured for this as well unless we want this sort of things in multilib too. using neon also depends on machine features. So we need combination of machine features e.g. does it have neon does it implement vfpv3-d16 or d32 or no FPU at all then we need hardfloat ABI which is a distro feature I would say and is only enabled when underlying hardware support is found through machine features. So we need a switch to select if hardfp is desired. Thumb1 and thumb2 can be covered with passing right options globally to CC iow TARGET_CC_ARCH for most parts As far as I know nobody uses OABI anymore, and I doubt we should support it. The above are really instructions used within the ABI. And the extra knobs: * pure thumb1, no arm instructions (limited use) * thumb1/arm interworking * pure thumb2,  no arm instructions * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage) In OE .dev we have the following vars: TARGET_FPU: switches between hw float and sw float, no reflection in package arch ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or 'armv7a-hardfp' as package arch ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch THUMB_INTERWORK: turns on interworking, no reflection in package arch (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU for armv7a and will generate slow code, angstrom does turn it on) Khem and I would like to start building armv7a (and armv6) in pure thumb2 mode but we want to have the variables to turn those knobs make sense and be consistent. RP has expressed his desire to sort this all out before merging multilib. I'm sure x86/mips/ppc/etc have a similar need, so let's get this discussion started. Below is a quick step to capture what all I know of for various architectures, inluding ARM.  Note the tunings are where I'm a bit sketchy on some architectures.  (I think below also point out why I think this needs to be hierarchical..  so it's really easy to inherit common stuff, and override only the pieces you need to..  specifically the tunings.) Arch Family: ARM ABI: - EABI little endian - EABI big endian  - canonical os=linux-eabi  - library directory is lib CPU/ISA: - all use EABI  - traditional arm instructions  - thumb1, no arm instructions  - thumb1/arm, interworking  - thumb2, no arm instructions  - thumb2, interworking (note, our customers do use this.. I'm not sure how much though) Tunings: - armv4 (both big little endian) - armv5 (both big little endian) - armv5 + vfp - armv6 + vfp - armv7a + vfp + neon (supports thumb) (little endian) - armv7a + be8 (supports thumb) (big endian) --- Arch Family: IA32 ABI: - x86_32  - There is a soft-fp variant but it's not really used anymore  - hardfp  - defined as an LSB standard  - library directory is lib - x86_64  - hardfp only  - defined as an LSB standard  - library directory is lib64 - (x32)  - new experimental ABI  - library directory is libx32 CPU/ISA: - x86_32  - all use x86_32  - i586 - core2 - corei7 - x86_64  - only 64-bit chips supported - x32  - only 64-bit chips supported Tunings: - i586, i686, core2, etc.. - MMX, MMX2,
[OE-core] [PATCH v2] libc-{common, package}.bbclass: fix shlib renaming for the C library
Without this you'd end up with eglibc_2.12.ipk instead of libc6_2.12.ipk as
before
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/classes/libc-common.bbclass |8
meta/classes/libc-package.bbclass |7 +--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/meta/classes/libc-common.bbclass b/meta/classes/libc-common.bbclass
index bae0ace..a9ec5f1 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -21,3 +21,11 @@ def get_libc_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --without-fp
return
+# We want to do this indirection so that we can safely 'return'
+# from the called function even though we're prepending
+python populate_packages_prepend () {
+ if bb.data.getVar('DEBIAN_NAMES', d, 1):
+ bpn = bb.data.getVar('BPN', d, 1)
+ bb.data.setVar('PKG_'+bpn, 'libc6', d)
+ bb.data.setVar('PKG_'+bpn+'-dev', 'libc6-dev', d)
+}
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 4bc58c8..8e03f03 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -365,12 +365,7 @@ python package_do_split_gconvs () {
}
-# We want to do this indirection so that we can safely 'return'
-# from the called function even though we're prepending
python populate_packages_prepend () {
- if bb.data.getVar('DEBIAN_NAMES', d, 1):
- bpn = bb.data.getVar('BPN', d, 1)
- bb.data.setVar('PKG_'+bpn, 'libc6', d)
- bb.data.setVar('PKG_'+bpn+'-dev', 'libc6-dev', d)
bb.build.exec_func('package_do_split_gconvs', d)
}
+
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tune files and knobs to turn
On Tue, Jun 28, 2011 at 10:36 AM, Darren Hart dvh...@linux.intel.com wrote: On 06/24/2011 04:54 AM, Koen Kooi wrote: Hi, We discussed tune files a bit during last nights TSC meeting and Khem had expressed the need before, so I'd like to get this discussion started by using armv7a as an example. For armv7a capable cores we have the following hardware features: * armv7a instruction set * thumb1 instruction set * thumb2 instruction set * VFP coprocessor * optional NEON coprocessor For the ABI we can choose the following: * softtp without hw support (e.g. no VFP instructions emitted, slow) * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast) * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw,  incompatible with everything else And the extra knobs: * pure thumb1, no arm instructions (limited use) * thumb1/arm interworking * pure thumb2,  no arm instructions * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage) In OE .dev we have the following vars: TARGET_FPU: switches between hw float and sw float, no reflection in package arch ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or       'armv7a-hardfp' as package arch ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch THUMB_INTERWORK: turns on interworking, no reflection in package arch (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU  for armv7a and will generate slow code, angstrom does turn it on) oe-core tune-cortexa8.inc doesn't make use of these variables (unlike meta-texasinstruments) and does make use of the neon coprocessor, but still uses the softfp float-api: TARGET_CC_ARCH = -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize Seems like the oe-core tune files need to be synced up with vendor layers? Well for enabling hardfp its a fundamental decision and I guess using softfloat in oe-core is probably best choice and the floating point parameter passing ABI I am taking about we still use -mfpu=neon so gcc will still try to utilize it but -fno-tree-vectorize is going to subdue the use of neon intrs since gcc is disallowed to vectorize -- Darren Khem and I would like to start building armv7a (and armv6) in pure thumb2 mode but we want to have the variables to turn those knobs make sense and be consistent. RP has expressed his desire to sort this all out before merging multilib. I'm sure x86/mips/ppc/etc have a similar need, so let's get this discussion started. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc-locale: don't make versions go backwards after split from eglibc
eglibc was way beyond PR = r1 at the time of the split, so increase PR to make package upgrades work Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- meta/recipes-core/eglibc/eglibc-locale.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-core/eglibc/eglibc-locale.inc b/meta/recipes-core/eglibc/eglibc-locale.inc index 7c4b1d5..96f2d8a 100644 --- a/meta/recipes-core/eglibc/eglibc-locale.inc +++ b/meta/recipes-core/eglibc/eglibc-locale.inc @@ -26,7 +26,7 @@ BINARY_LOCALE_ARCHES ?= arm.* i[3-6]86 x86_64 powerpc mips # set 0 for qemu emulation of native localedef for locale generation LOCALE_GENERATION_WITH_CROSS-LOCALEDEF = 1 -PR = r1 +PR = r16 PKGSUFFIX = PKGSUFFIX_virtclass-nativesdk = -nativesdk -- 1.6.6.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [Draft design][RFC] Running postinst at rootfs generation time
On 06/27/2011 07:09 PM, Cui, Dexuan wrote: Hi all, below is an initial investigation about the task and we'll continue to further look into it. In poky we have 2 types of postinst scripts: one (type-1) can be (and has already been) run at rootfs generation time and the other (type-2) has to be delayed to the first-boot of target device. Type-2 makes target device's first-boot slow and it would be great if we can fix it and convert it to type-1. We can instrument a first-boot with minimal/sato first to see which postinstalls take the most time and then prioritise those ones to fix. I figurerd out a list of 33 recipes in total(recipes with the same name but with different versions are counted once) we possibly need to fix. For the recipes, we need try to find recipe-specific ways(use appropriately modified native utilities to generate caches, files, etc as necessary on the target filesystem). Dexuan, Great start on this list, can you break this down to what's sato and minimal. 11 recipes: these could be easily fixed if we add the properly-adjusted utilities adduser, addgroup, pwconv, etc. Scott is actually adding the utilites: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/useradd-rebasedid=99e54d9696104ed38ec1e3464e17aa1f9b8d98ac meta/recipes-devtools/distcc/distcc_2.18.3.bb meta/recipes-extended/cronie/cronie_1.4.7.bb meta/recipes-extended/at/at_3.1.12.bb:47 meta/recipes-support/hal/hal.inc:45 meta/recipes-core/dbus/dbus.inc:49 meta/recipes-connectivity/openssh/openssh_5.8p2.bb meta/recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb meta/recipes-graphics/x11-common/xserver-nodm-init.bb meta/recipes-multimedia/pulseaudio/pulseaudio.inc:87 meta/recipes-extended/shadow/shadow_4.1.4.3.bb:125 meta/classes/libc-package.bbclass As RP noted, the useradd code from Scott is very close to being pull, will you modify and test these recipes? Sau! 6 recipes: these should be easily fixed since the scripts are not related to special native utilites. meta/recipes-extended/sudo/sudo.inc meta/recipes-extended/sysklogd/sysklogd.inc meta/classes/update-rc.d.bbclass meta/recipes-connectivity/ppp/ppp_2.4.5.bb meta/recipes-graphics/pango/pango.inc meta/recipes-gnome/gtk+/gtk+.inc 4 recipes: we may need to add gtk-update-icon-cache-native. meta/classes/gtk-icon-cache.bbclass meta/recipes-gnome/librsvg/librsvg_2.32.1.bb meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.22.1.bb meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc 3 recipes: need to add gconftool-2-native? meta/classes/gconf.bbclass meta/recipes-graphics/mutter/mutter.inc meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb 3 recipes: dpkg --configure, opkg-cl configure: looks it's possible to fix them if we specify proper parematers? meta/recipes-devtools/dpkg/dpkg.inc meta/recipes-devtools/opkg/opkg_svn.bb meta/recipes-devtools/opkg/opkg_0.1.8.bb 1 recipe: prelink: we could propablly fix it, but I'm not sure yet. meta/recipes-devtools/prelink/prelink_git.bb 1 recipe: /etc/init.d/populate-volatile.sh update ; DBUSPID=`pidof dbus-daemon`: We can't fix this one. meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc The below 4 recipes need the related utilities and need more investigation. 1 recipe: update-modules meta/recipes-kernel/update-modules/update-modules_1.0.bb 1 recipe: systemctl meta/recipes-connectivity/avahi/avahi.inc 1 recipe: fc-cache meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb:37 1 recipe: gtk-query-immodules-2.0 meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tune files and knobs to turn
On Tue, Jun 28, 2011 at 12:13 PM, Darren Hart dvh...@linux.intel.com wrote: On 06/28/2011 10:38 AM, Koen Kooi wrote: Op 28 jun 2011, om 19:36 heeft Darren Hart het volgende geschreven: On 06/24/2011 04:54 AM, Koen Kooi wrote: Hi, We discussed tune files a bit during last nights TSC meeting and Khem had expressed the need before, so I'd like to get this discussion started by using armv7a as an example. For armv7a capable cores we have the following hardware features: * armv7a instruction set * thumb1 instruction set * thumb2 instruction set * VFP coprocessor * optional NEON coprocessor For the ABI we can choose the following: * softtp without hw support (e.g. no VFP instructions emitted, slow) * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast) * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw,  incompatible with everything else And the extra knobs: * pure thumb1, no arm instructions (limited use) * thumb1/arm interworking * pure thumb2,  no arm instructions * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage) In OE .dev we have the following vars: TARGET_FPU: switches between hw float and sw float, no reflection in package arch ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or       'armv7a-hardfp' as package arch ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch THUMB_INTERWORK: turns on interworking, no reflection in package arch (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU for armv7a and will generate slow code, angstrom does turn it on) oe-core tune-cortexa8.inc doesn't make use of these variables (unlike meta-texasinstruments) and does make use of the neon coprocessor, but still uses the softfp float-api: TARGET_CC_ARCH = -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize Don't confuse softfp calling conventions with softfloat! The above will still emit vfp and neon instructions if your set TARGET_FPU = hard Ah. So we would need to add something like: conf/distro/include/angstrom.inc:TARGET_FPU_armv7a ?= hard conf/distro/include/angstrom.inc:TARGET_FPU_armv7a-vfp ?= hard to something DISTRO specific (poky.conf or similar). It isn't clear to me why this is a distro policy decision instead of part of the tune include or the machine config itself. Can someone elaborate on why this goes where it does? adding to what Koen said. Its a different incompatible ABI hardfp binaries will not work on softfp root file system Since its a ABI changer its best left to distros to choose what ABI they would prefer but in oe-core we need to make provisions for that. Which we dont have at the moment. Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tune files and knobs to turn
On Tue, Jun 28, 2011 at 1:33 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 28 jun 2011, om 22:31 heeft Khem Raj het volgende geschreven: On Tue, Jun 28, 2011 at 10:36 AM, Darren Hart dvh...@linux.intel.com wrote: On 06/24/2011 04:54 AM, Koen Kooi wrote: Hi, We discussed tune files a bit during last nights TSC meeting and Khem had expressed the need before, so I'd like to get this discussion started by using armv7a as an example. For armv7a capable cores we have the following hardware features: * armv7a instruction set * thumb1 instruction set * thumb2 instruction set * VFP coprocessor * optional NEON coprocessor For the ABI we can choose the following: * softtp without hw support (e.g. no VFP instructions emitted, slow) * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast) * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw,  incompatible with everything else And the extra knobs: * pure thumb1, no arm instructions (limited use) * thumb1/arm interworking * pure thumb2,  no arm instructions * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage) In OE .dev we have the following vars: TARGET_FPU: switches between hw float and sw float, no reflection in package arch ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or       'armv7a-hardfp' as package arch ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch THUMB_INTERWORK: turns on interworking, no reflection in package arch (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU  for armv7a and will generate slow code, angstrom does turn it on) oe-core tune-cortexa8.inc doesn't make use of these variables (unlike meta-texasinstruments) and does make use of the neon coprocessor, but still uses the softfp float-api: TARGET_CC_ARCH = -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize Seems like the oe-core tune files need to be synced up with vendor layers? Well for enabling hardfp its a fundamental decision and I guess using softfloat in oe-core is probably best choice and the floating point parameter passing ABI I am taking about we still use -mfpu=neon so gcc will still try to utilize it but -fno-tree-vectorize is going to subdue the use of neon intrs since gcc is disallowed to vectorize Experience has shown that -fno-tree-vectorize generates faster code with gcc 4.5 :) Someday I will try to benchmark and find out whats going on for myself. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc-locale: fix localedef packaging
Op 28 jun 2011, om 18:11 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-28 at 17:30 +0200, Koen Kooi wrote:
the ${PN} still needs some checking, since it will now inheriting the
default FILES_${PN}
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
I merged a different version of this which drops PN-locale and fixes
glibc too.
From
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yoctoid=0d0e14cda2ddd881d09798b0e6edd8086aa9b6d9
+libc6 - libc6_dev;
So libc6 now depends on libc6-dev :(
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFH] Native SDK wirdness
Hi Otavio, Here's what I got when I tried the same command against my sdk tarball tar -tjf poky-eglibc-i686-i586-toolchain-gmae-1.0+snapshot-20110625.tar.bz2 |grep '\-gcc' tar: Record size = 16 blocks ./opt/poky/1.0+snapshot/sysroots/i586-poky-linux/usr/src/debug/glib-2.0-1_2.28.8-r1/glib-2.28.8/glib/gatomic-gcc.c ./opt/poky/1.0+snapshot/sysroots/i686-pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-gcc ./opt/poky/1.0+snapshot/sysroots/i686-pokysdk-linux/usr/lib/i586-poky-linux/gcc/i586-poky-linux/4.6.1/include/stdint-gcc.h ./opt/poky/1.0+snapshot/sysroots/i686-pokysdk-linux/usr/include/curl/typecheck-gcc.h Seems an issue with OE build? Cheers, Jessica -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Otavio Salvador Sent: Tuesday, June 28, 2011 9:28 AM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [RFH] Native SDK wirdness On Tue, Jun 28, 2011 at 13:16, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2011-06-28 at 11:56 -0300, Otavio Salvador wrote: I am probably doing something stupid but I couldn't figure it myself so I am looking for some help here. Basically I need to prepare a SDK for usage by our team mates to develop to our embedded OS. In theory I got most of it already done but when I build the meta-toolchain recipe the built sdk tarball lacks GCC and like. Any idea where I ought to look for a good example? Or any clue what I am doing wrong? Could you share a list of files from your toolchain tarball please? It certainly should contain a cross compiler... ~% tar -tjf oecore-i686-i586-toolchain-devel.tar.bz2| grep '\-gcc' ./usr/local/oecore-i686-i686/sysroots/i686-oesdk-linux/usr/include/curl/typecheck-gcc.h ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/include/curl/typecheck-gcc.h ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/ ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/qplatformdefs.h ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/qmake.conf ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/features/ ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/features/default_post.prf ~% I can provide the full list but it does seem to not include it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Building behind a firewall/proxy
On 06/28/2011 01:14 PM, Joshua Lock wrote: All, For the Yocto 1.1 release we want to ease the pain of getting set up to build behind a firewall. I have a series of patches under development to run a one hit sanity test which tries to verify the user can fetch and in the case of failure point the user to a wiki page where we'd document common causes of fetch failures. We're also going to look at the site.conf file, which can be used to specify proxy settings and other site specific settings such MIRRORS, and ensure that it can easily be edited to help people get set up. It'd be great if people who operate behind a proxy/firewall can help us document the steps they had to take to work around this. Further if you have other ideas as to how we can help make this process less painful please let us know. Is SOCKS5_PASSWD SOCKS5_USER in the default BB_ENV_EXTRAWHITE list atm? If not, it needs to be. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] shadow-native fix for useradd
Pseudo was recently changed so that when system() calls are made after a chroot(), the host binaries can no longer be found, breaking the system(mkdir -p) approach when useradd creates home directories. Instead, use mkdir(2) to create home directories with a helper function to ensure parent directories get created. This is a prerequisite fix needed for my useradd.bbclass changes (still pending until I address some of Richard's comments from this morning). The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib sgarman/mkdir-p-fix http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=sgarman/mkdir-p-fix Scott Garman (1): shadow-native: fix creation of home directories .../shadow/files/add_root_cmd_options.patch| 125 +++ 1 files changed, 98 insertions(+), 27 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On Jun 28, 2011, at 3:51 PM, Scott Garman scott.a.gar...@intel.com wrote: On 06/28/2011 03:41 PM, Khem Raj wrote: ERROR: Multiple .bb files are due to be built which each provide ssh (/home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-core/dropbear/dropbear_0.52.bb /home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-connectivity/openssh/openssh_5.8p2.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide sshd (/home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-core/dropbear/dropbear_0.52.bb /home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-connectivity/openssh/openssh_5.8p2.bb). This usually means one provides something the other doesn't and should. reason is that dropbear only provides ssh and sshd packages openssh provides a few more e.g. openssh-sftp-server which is demanded by some images and at same time wants dropbear to provide sshd and ssh Now both recipes are to be built but are in contention for providing ssh and sshd How to solve this problem. ? Are other packages that openssh provides strictly depending on ssh/sshd from openssh ? or will they work on any ssh/sshd ? If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish I've run into that and have been wondering how to resolve it as well. If there are currently existing images which are pulling in dropbear's ssh and sshd while using openssh's sftp-server, then that would imply they can work independently, even though that combo seems like an aggressive space optimization that I would tend to avoid. yes if you build console-image with angstrom you will see it wanting sftp-server and dr bear for rest of ssh needs Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC - Staticdev 1/2] multiple recipes converted to -staticdev packages
On 06/26/2011 12:34 AM, Koen Kooi wrote:
Op 26 jun 2011, om 06:36 heeft Saul Wold het volgende geschreven:
This commit adds a new base package ${PN}-staticdev to
bitbake.conf which pulls in the static *.a libraries as
a seperate package, it filters out the nonshared.a
libraries where appropriate.
Additional this commit adds a new libdev.bbclass which provides
a set of macros and variables to convert ${PN} to lib${PN},
which a number of recipes where then converted to use.
Can't that be merged into lib_package.bbclass?
I looked into this further, and I think that lib_package serves a
different purpose than libdev and it would be wrong to inherit from
lib_package.
lib_package seems to split out binaries from the core ${PN} package and
places them in ${PN}-bin. I did update it to move static libraries to
the -staticdev package.
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFH] Native SDK wirdness
On Jun 28, 2011, at 2:31 PM, Zhang, Jessica jessica.zh...@intel.com wrote: Hi Otavio, Here's what I got when I tried the same command against my sdk tarball tar -tjf poky-eglibc-i686-i586-toolchain-gmae-1.0+snapshot-20110625.tar.bz2 |grep '\-gcc' tar: Record size = 16 blocks ./opt/poky/1.0+snapshot/sysroots/i586-poky-linux/usr/src/debug/glib-2.0-1_2.28.8-r1/glib-2.28.8/glib/gatomic-gcc.c ./opt/poky/1.0+snapshot/sysroots/i686-pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-gcc ./opt/poky/1.0+snapshot/sysroots/i686-pokysdk-linux/usr/lib/i586-poky-linux/gcc/i586-poky-linux/4.6.1/include/stdint-gcc.h ./opt/poky/1.0+snapshot/sysroots/i686-pokysdk-linux/usr/include/curl/typecheck-gcc.h Seems an issue with OE build? Cheers, Jessica -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Otavio Salvador Sent: Tuesday, June 28, 2011 9:28 AM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [RFH] Native SDK wirdness On Tue, Jun 28, 2011 at 13:16, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2011-06-28 at 11:56 -0300, Otavio Salvador wrote: I am probably doing something stupid but I couldn't figure it myself so I am looking for some help here. Basically I need to prepare a SDK for usage by our team mates to develop to our embedded OS. In theory I got most of it already done but when I build the meta-toolchain recipe the built sdk tarball lacks GCC and like. Any idea where I ought to look for a good example? Or any clue what I am doing wrong? Could you share a list of files from your toolchain tarball please? It certainly should contain a cross compiler... ~% tar -tjf oecore-i686-i586-toolchain-devel.tar.bz2| grep '\-gcc' ./usr/local/oecore-i686-i686/sysroots/i686-oesdk-linux/usr/include/curl/typecheck-gcc.h ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/include/curl/typecheck-gcc.h ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/ ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/qplatformdefs.h ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/qmake.conf ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/features/ ./usr/local/oecore-i686-i586/sysroots/i586-oe-linux/usr/share/qt4/mkspecs/symbian/linux-gcce/features/default_post.prf ~% I can provide the full list but it does seem to not include it. What steps did u follow to build. Ant local patches -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On 06/29/2011 12:50 AM, Khem Raj wrote: On Jun 28, 2011, at 3:51 PM, Scott Garman scott.a.gar...@intel.com wrote: On 06/28/2011 03:41 PM, Khem Raj wrote: ERROR: Multiple .bb files are due to be built which each provide ssh (/home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-core/dropbear/dropbear_0.52.bb /home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-connectivity/openssh/openssh_5.8p2.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide sshd (/home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-core/dropbear/dropbear_0.52.bb /home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-connectivity/openssh/openssh_5.8p2.bb). This usually means one provides something the other doesn't and should. reason is that dropbear only provides ssh and sshd packages openssh provides a few more e.g. openssh-sftp-server which is demanded by some images and at same time wants dropbear to provide sshd and ssh Now both recipes are to be built but are in contention for providing ssh and sshd How to solve this problem. ? Are other packages that openssh provides strictly depending on ssh/sshd from openssh ? or will they work on any ssh/sshd ? If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish I've run into that and have been wondering how to resolve it as well. If there are currently existing images which are pulling in dropbear's ssh and sshd while using openssh's sftp-server, then that would imply they can work independently, even though that combo seems like an aggressive space optimization that I would tend to avoid. yes if you build console-image with angstrom you will see it wanting sftp-server and dr bear for rest of ssh needs sftp-server is just a really small ftp like program that gets run as the shell when sftp connects instead of ssh. It has no dependency on any openssh code or even openssl. This is the reason why the dropbear developer decided to just use it instead of writing his own exact work alike. I was the one that added it to Angstrom images as I really like to sftp out of the box. Graeme ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] multiple recipes converted to use -staticdev
This commit adds a new base package ${PN}-staticdev to
bitbake.conf which pulls in the static *.a libraries as
a seperate package, it filters out the nonshared.a
libraries where appropriate.
Additional this commit adds a new libdev.bbclass which provides
a set of macros and variables to convert ${PN} to lib${PN},
which a number of recipes where then converted to use.
PR bumps all around
The following changes since commit 8a5c20417d4d6bee6dd0bcdbeb8d4f9e0696a216:
[PATCH] u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:12 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/static
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/static
Saul Wold (1):
multiple recipes converted to -staticdev packages
meta/classes/lib_package.bbclass | 10 -
meta/classes/libdev.bbclass| 44
meta/conf/bitbake.conf |8 +++-
meta/recipes-bsp/pciutils/pciutils_3.1.7.bb|7 ++-
.../wireless-tools/wireless-tools_29.bb|9 +++-
meta/recipes-core/eglibc/eglibc-common.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|9 +++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb | 16
meta/recipes-core/glibc/glibc-package.inc |9 +++-
.../meta/external-csl-toolchain_2008q3-72.bb |8 ++-
meta/recipes-core/uclibc/uclibc.inc|9 +++-
meta/recipes-core/udev/udev-new.inc| 14 --
meta/recipes-core/udev/udev_164.bb |2 +-
meta/recipes-core/util-linux/util-linux.inc| 11 -
meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +-
.../binutils/binutils-cross-canadian_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils-cross.inc |2 +
.../binutils/binutils-cross_csl-arm-2008q1.bb |2 +-
.../binutils/binutils-crosssdk_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|9 +---
meta/recipes-devtools/binutils/binutils_2.21.bb|2 +-
meta/recipes-devtools/gcc/gcc-package-runtime.inc | 25 ---
meta/recipes-devtools/gcc/libgcc_4.6.bb|2 +-
meta/recipes-devtools/opkg/opkg_0.1.8.bb |8 ++-
meta/recipes-devtools/opkg/opkg_svn.bb |8 ++-
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 18
meta/recipes-extended/augeas/augeas.inc|7 +--
meta/recipes-extended/augeas/augeas_0.8.1.bb |2 +-
meta/recipes-extended/gamin/gamin_0.1.10.bb| 13 +-
.../tcp-wrappers/tcp-wrappers_7.6.bb |9 +++-
meta/recipes-graphics/cairo/cairo_1.10.2.bb|9 ++--
meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb |7 +--
meta/recipes-multimedia/liba52/liba52_0.7.4.bb |4 +-
meta/recipes-support/attr/acl_2.2.51.bb|2 +-
meta/recipes-support/attr/attr_2.4.46.bb |2 +-
meta/recipes-support/attr/ea-acl.inc | 16 +---
meta/recipes-support/curl/curl_7.21.6.bb | 17 +++-
meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb |5 +-
meta/recipes-support/sqlite/sqlite3.inc| 10 +
meta/recipes-support/sqlite/sqlite3_3.7.6.2.bb |2 +-
42 files changed, 204 insertions(+), 147 deletions(-)
create mode 100644 meta/classes/libdev.bbclass
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] systemtap: add sqlite3 to DEPENDS
Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-kernel/systemtap/systemtap_git.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb b/meta/recipes-kernel/systemtap/systemtap_git.bb index aeb87c8..f24c179 100644 --- a/meta/recipes-kernel/systemtap/systemtap_git.bb +++ b/meta/recipes-kernel/systemtap/systemtap_git.bb @@ -2,7 +2,7 @@ DESCRIPTION = SystemTap - script-directed dynamic tracing and performance analy LICENSE = GPLv2 LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f -DEPENDS = elfutils +DEPENDS = elfutils sqlite3 SRCREV = 4ab3a1863bf4f472acae7a809bf2b38d91658aa8 PR = r3 -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
This commit adds a new base package ${PN}-staticdev to
bitbake.conf which pulls in the static *.a libraries as
a seperate package, it filters out the nonshared.a
libraries where appropriate.
Additional this commit adds a new libdev.bbclass which provides
a set of macros and variables to convert ${PN} to lib${PN},
which a number of recipes where then converted to use.
PR bumps all around
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/lib_package.bbclass | 10 -
meta/classes/libdev.bbclass| 44
meta/conf/bitbake.conf |8 +++-
meta/recipes-bsp/pciutils/pciutils_3.1.7.bb|7 ++-
.../wireless-tools/wireless-tools_29.bb|9 +++-
meta/recipes-core/eglibc/eglibc-common.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|9 +++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb | 16
meta/recipes-core/glibc/glibc-package.inc |9 +++-
.../meta/external-csl-toolchain_2008q3-72.bb |8 ++-
meta/recipes-core/uclibc/uclibc.inc|9 +++-
meta/recipes-core/udev/udev-new.inc| 14 --
meta/recipes-core/udev/udev_164.bb |2 +-
meta/recipes-core/util-linux/util-linux.inc| 11 -
meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +-
.../binutils/binutils-cross-canadian_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils-cross.inc |2 +
.../binutils/binutils-cross_csl-arm-2008q1.bb |2 +-
.../binutils/binutils-crosssdk_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|9 +---
meta/recipes-devtools/binutils/binutils_2.21.bb|2 +-
meta/recipes-devtools/gcc/gcc-package-runtime.inc | 25 ---
meta/recipes-devtools/gcc/libgcc_4.6.bb|2 +-
meta/recipes-devtools/opkg/opkg_0.1.8.bb |8 ++-
meta/recipes-devtools/opkg/opkg_svn.bb |8 ++-
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 18
meta/recipes-extended/augeas/augeas.inc|7 +--
meta/recipes-extended/augeas/augeas_0.8.1.bb |2 +-
meta/recipes-extended/gamin/gamin_0.1.10.bb| 13 +-
.../tcp-wrappers/tcp-wrappers_7.6.bb |9 +++-
meta/recipes-graphics/cairo/cairo_1.10.2.bb|9 ++--
meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb |7 +--
meta/recipes-multimedia/liba52/liba52_0.7.4.bb |4 +-
meta/recipes-support/attr/acl_2.2.51.bb|2 +-
meta/recipes-support/attr/attr_2.4.46.bb |2 +-
meta/recipes-support/attr/ea-acl.inc | 16 +---
meta/recipes-support/curl/curl_7.21.6.bb | 17 +++-
meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb |5 +-
meta/recipes-support/sqlite/sqlite3.inc| 10 +
meta/recipes-support/sqlite/sqlite3_3.7.6.2.bb |2 +-
41 files changed, 203 insertions(+), 146 deletions(-)
create mode 100644 meta/classes/libdev.bbclass
diff --git a/meta/classes/lib_package.bbclass b/meta/classes/lib_package.bbclass
index 5ce8727..e8cbc25 100644
--- a/meta/classes/lib_package.bbclass
+++ b/meta/classes/lib_package.bbclass
@@ -5,6 +5,12 @@ FILES_${PN} = ${libexecdir} ${libdir}/lib*${SOLIBS} \
${base_libdir}/*${SOLIBS} \
${datadir}/${PN} ${libdir}/${PN}
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
- ${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
- ${datadir}/aclocal ${bindir}/*-config
+${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
+${datadir}/aclocal ${bindir}/*-config \
+${libdir}/*_nonshared.a
FILES_${PN}-bin = ${bindir}/* ${sbindir}/* /bin/* /sbin/*
+
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a',
'${staticdev_libs}', d)}
+
+
diff --git a/meta/classes/libdev.bbclass b/meta/classes/libdev.bbclass
new file mode 100644
index 000..d0aac2f
--- /dev/null
+++ b/meta/classes/libdev.bbclass
@@ -0,0 +1,44 @@
+#
+# This bbclass it a common case for lib${PN}*.a static libraries
+#
+
+SUMMARY_lib${PN}-dbg ?= ${SUMMARY} - Debugging files
+DESCRIPTION_lib${PN}-dbg ?= ${DESCRIPTION} \
+This package contains ELF symbols and related sources for debugging purposes.
+
+SUMMARY_lib${PN}-dev ?= ${SUMMARY} - Development files
+DESCRIPTION_lib${PN}-dev ?= ${DESCRIPTION} \
+This package contains symbolic links, header files, and \
+related items necessary for software development.
+
+SUMMARY_lib${PN}-doc ?= ${SUMMARY} - Documentation files
+DESCRIPTION_lib${PN}-doc ?= ${DESCRIPTION} This package contains
documentation.
+
+SUMMARY_lib${PN}-staticdev ?= ${SUMMARY} - Development files (Static
Libraries)
+DESCRIPTION_lib${PN}-staticdev?= ${DESCRIPTION} \
[OE-core] [PATCH] systemtap: add sqlite3 to DEPENDS
Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-kernel/systemtap/systemtap_git.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb b/meta/recipes-kernel/systemtap/systemtap_git.bb index aeb87c8..f24c179 100644 --- a/meta/recipes-kernel/systemtap/systemtap_git.bb +++ b/meta/recipes-kernel/systemtap/systemtap_git.bb @@ -2,7 +2,7 @@ DESCRIPTION = SystemTap - script-directed dynamic tracing and performance analy LICENSE = GPLv2 LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f -DEPENDS = elfutils +DEPENDS = elfutils sqlite3 SRCREV = 4ab3a1863bf4f472acae7a809bf2b38d91658aa8 PR = r3 -- 1.7.3.4 -- Sau! Saul Wold Yocto Component Wrangler @ Intel Yocto Project / Poky Build System ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] fontconfig: specify font directory in EXTRA_OECONF
On 06/27/2011 08:24 AM, Phil Blundell wrote:
since, otherwise, fontconfig's builtin default may not match ${datadir}.
Signed-off-by: Phil Blundellph...@gnu.org
---
.../fontconfig/fontconfig_2.8.0.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.8.0.bb
b/meta/recipes-graphics/fontconfig/fontconfig_2.8.0.bb
index ae0fef5..5381065 100644
--- a/meta/recipes-graphics/fontconfig/fontconfig_2.8.0.bb
+++ b/meta/recipes-graphics/fontconfig/fontconfig_2.8.0.bb
@@ -20,7 +20,7 @@ SECTION = libs
DEPENDS = expat freetype zlib
-PR = r1
+PR = r3
a nitpick though not wrong but should be r2
SRC_URI = http://fontconfig.org/release/fontconfig-${PV}.tar.gz \
file://fix-pkgconfig.patch \
@@ -45,7 +45,7 @@ inherit autotools pkgconfig
export HASDOCBOOK=no
-EXTRA_OECONF = --disable-docs --with-arch=${HOST_ARCH}
+EXTRA_OECONF = --disable-docs --with-arch=${HOST_ARCH}
--with-default-fonts=${datadir}/fonts
EXTRA_OEMAKE = FC_LANG=fc-lang FC_GLYPHNAME=fc-glyphname
# The tarball has some of the patched files as read only, which
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] dhcp: don't try to move files from ${sbindir} to ${base_sbindir} if they are the same
On 06/16/2011 06:27 AM, Phil Blundell wrote:
Signed-off-by: Phil Blundellph...@gnu.org
Acked-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-connectivity/dhcp/dhcp4.inc |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-connectivity/dhcp/dhcp4.inc
b/meta/recipes-connectivity/dhcp/dhcp4.inc
index 159ae89..885cc19 100644
--- a/meta/recipes-connectivity/dhcp/dhcp4.inc
+++ b/meta/recipes-connectivity/dhcp/dhcp4.inc
@@ -47,7 +47,9 @@ do_install_append () {
install -m 0644 ${WORKDIR}/dhcpd.conf ${D}${sysconfdir}/dhcp/dhcpd.conf
install -d ${D}${base_sbindir}/
- mv ${D}${sbindir}/dhclient ${D}${base_sbindir}/
+ if [ ${sbindir} != ${base_sbindir} ]; then
+ mv ${D}${sbindir}/dhclient ${D}${base_sbindir}/
+ fi
install -m 0755 ${S}/client/scripts/linux
${D}${base_sbindir}/dhclient-script
}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] dhcp: don't try to move files from ${sbindir} to ${base_sbindir} if they are the same
On 06/16/2011 06:27 AM, Phil Blundell wrote:
Signed-off-by: Phil Blundellph...@gnu.org
---
meta/recipes-connectivity/dhcp/dhcp4.inc |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-connectivity/dhcp/dhcp4.inc
b/meta/recipes-connectivity/dhcp/dhcp4.inc
index 159ae89..885cc19 100644
--- a/meta/recipes-connectivity/dhcp/dhcp4.inc
+++ b/meta/recipes-connectivity/dhcp/dhcp4.inc
@@ -47,7 +47,9 @@ do_install_append () {
install -m 0644 ${WORKDIR}/dhcpd.conf ${D}${sysconfdir}/dhcp/dhcpd.conf
install -d ${D}${base_sbindir}/
- mv ${D}${sbindir}/dhclient ${D}${base_sbindir}/
+ if [ ${sbindir} != ${base_sbindir} ]; then
+ mv ${D}${sbindir}/dhclient ${D}${base_sbindir}/
+ fi
install -m 0755 ${S}/client/scripts/linux
${D}${base_sbindir}/dhclient-script
}
Appears to be merged in OE-Core, just no email yet.
Consider this your Merged email! I think that RP is catching up Emails
may not have yet.
Sau!
___
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] base.bbclass: show layer's branches/revisions in the banner info
On 06/28/2011 04:07 AM, Paul Eggleton wrote: On Tuesday 28 June 2011 07:45:09 Koen Kooi wrote: So it works as expected, but the output is a bit confusing. I have a few (conflicting) suggestions: 1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.: meta-archos branch = master meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad 2) for the extra layers put branch and revision on a single line: meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad I'd go with option 2 over 1, personally - the list gets rather long on something like Angstrom, better to keep it short. I would say to do it uniformly and treat oe-core as one of layers too when emitting this info ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On 06/28/2011 04:53 PM, Graeme Gregory wrote: On 06/29/2011 12:50 AM, Khem Raj wrote: On Jun 28, 2011, at 3:51 PM, Scott Garmanscott.a.gar...@intel.com wrote: On 06/28/2011 03:41 PM, Khem Raj wrote: ERROR: Multiple .bb files are due to be built which each provide ssh (/home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-core/dropbear/dropbear_0.52.bb /home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-connectivity/openssh/openssh_5.8p2.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide sshd (/home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-core/dropbear/dropbear_0.52.bb /home/kraj/work/angstrom/sources/openembedded-core/meta/recipes-connectivity/openssh/openssh_5.8p2.bb). This usually means one provides something the other doesn't and should. reason is that dropbear only provides ssh and sshd packages openssh provides a few more e.g. openssh-sftp-server which is demanded by some images and at same time wants dropbear to provide sshd and ssh Now both recipes are to be built but are in contention for providing ssh and sshd How to solve this problem. ? Are other packages that openssh provides strictly depending on ssh/sshd from openssh ? or will they work on any ssh/sshd ? If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish I've run into that and have been wondering how to resolve it as well. If there are currently existing images which are pulling in dropbear's ssh and sshd while using openssh's sftp-server, then that would imply they can work independently, even though that combo seems like an aggressive space optimization that I would tend to avoid. yes if you build console-image with angstrom you will see it wanting sftp-server and dr bear for rest of ssh needs sftp-server is just a really small ftp like program that gets run as the shell when sftp connects instead of ssh. It has no dependency on any openssh code or even openssl. ok that solves my question about deps on ssh/ssh from openssh. So it seems we can refactor the openssh recipe This is the reason why the dropbear developer decided to just use it instead of writing his own exact work alike. I was the one that added it to Angstrom images as I really like to sftp out of the box. Graeme ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] webkit-gtk: recommends glib-networking to access https web page
Richard Purdie wrote: On Tue, 2011-06-28 at 20:08 +0800, Zhai, Edwin wrote: Koen Kooi wrote: Op 28 jun 2011, om 10:13 heeft Zhai, Edwin het volgende geschreven: In future, other recipes besides webkit-gtk may ask for glib-networking, maybe we can change it that time? What's your opinion? I'd either put it in the lib that uses it (soup) or the app that needs it (web-webkit), something in between is just confusing. Reasonable. I'd like to put it in libsoup. Actually, I think this sounds like a strong case to put it in web-webkit. My reasoning is that none of the other packages have the dependency, its really the use webkit makes of the libraries that is the requirement for the package... Yes, but other web browser may be used in future to introduce extra dependency. Anyway, this is just trade off, I'll re-send pull-request to put it under web-webkit, Thanks, edwin Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/7] useradd.bbclass: new class for managing user/group permissions
On 06/28/2011 06:04 AM, Richard Purdie wrote: Hi Scott, Sorry its taken me a while to get to this. Some comments below. Hi Richard, Thanks for the feedback. I'm hoping to get you a v2 pull request sometime tomorrow which incorporates some of your suggested changes. Mark gave good explanations on the points I will not be changing. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] glib-networking: Add 2.28.7 as new recipe
Koen said missing of gnomebase.bbclass may be introduced by some hacks in one merge. Richard Purdie wrote: On Tue, 2011-06-28 at 15:42 +0800, edwin.z...@intel.com wrote: From: Zhai Edwin edwin.z...@intel.com glib-networking contains the implementations of certain GLib networking features that cannot be implemented directly in GLib itself because of their dependencies. TLS/SSL support is one of them, which is needed for accessing SSL web page. Signed-off-by: Zhai Edwin edwin.z...@intel.com --- .../glib-networking/glib-networking_2.28.7.bb | 21 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-core/glib-networking/glib-networking_2.28.7.bb I merged this patch but we should revisit the issue of the gnome bbclass files in a subsequent patch. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] Fix prelink to avoid first boot script
In most cases the user will have the image-prelink enabled, which will prelink the target image at image creation time. If this is enabled we want to avoid prelinking at first boot. We do this by setting the script exit status to '0' if we detect we're on the host. Also fixes a small bug found in sstate.bbclass: do_cleansstate The following changes since commit 8a5c20417d4d6bee6dd0bcdbeb8d4f9e0696a216: [PATCH] u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:12 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/prelink http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/prelink Mark Hatle (2): sstate.bbclass: Fix an issue if the config changes prelink_git.bb: Only block the postinst script when no image-prelink meta/classes/sstate.bbclass |2 ++ meta/recipes-devtools/prelink/prelink_git.bb |6 -- 2 files changed, 6 insertions(+), 2 deletions(-) -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] sstate.bbclass: Fix an issue if the config changes
We need to check if we know of the task type, before we attempt
to process it. In order to reproduce the problem build with:
PACKAGE_CLASSES = package_ipk
Then change it to:
PACKAGE_CLASSES = package_rpm
Build again -- and then try bitbake -c cleansstate recipe
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/classes/sstate.bbclass |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 14c90ec..0daaf48 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -273,6 +273,8 @@ python sstate_cleanall() {
name = manifest.replace(manifest_pattern[:-1], )
namemap = d.getVar('SSTATETASKNAMES', True).split()
tasks = d.getVar('SSTATETASKS', True).split()
+ if name not in namemap:
+ continue
taskname = tasks[namemap.index(name)]
shared_state = sstate_state_fromvars(d, taskname[3:])
sstate_clean(shared_state, d)
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] prelink_git.bb: Only block the postinst script when no image-prelink
If image-prelink is being used, the system will automatically prelink
the target image. This avoids the need to run the postinst prelink
script at first boot. However, if the user has not enabled image
prelinking -- then we do enable the script to run on first boot.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-devtools/prelink/prelink_git.bb |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/prelink/prelink_git.bb
b/meta/recipes-devtools/prelink/prelink_git.bb
index b57c145..1b34e59 100644
--- a/meta/recipes-devtools/prelink/prelink_git.bb
+++ b/meta/recipes-devtools/prelink/prelink_git.bb
@@ -10,7 +10,7 @@ LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b
SRCREV = ac461e73b17253a4da25c5aafeac7193b553156c
PV = 1.0+git${SRCPV}
-PR = r3
+PR = r4
#
# The cron script attempts to re-prelink the system daily -- on
@@ -58,11 +58,13 @@ do_install_append () {
install -m 0644 ${WORKDIR}/macros.prelink
${D}${sysconfdir}/rpm/macros.prelink
}
+# If we're using mklibs-prelink, we want to skip this on the host side
+# but still do it if the package is installed on the target...
pkg_postinst_prelink() {
#!/bin/sh
if [ x$D != x ]; then
- exit 1
+ ${@base_contains('USER_CLASSES', 'image-prelink', 'exit 0', 'exit 1', d)}
fi
prelink -a
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] prelink_git.bb: Only block the postinst script when no image-prelink (v2)
[V2 - fix a small typo in the comment]
If image-prelink is being used, the system will automatically prelink
the target image. This avoids the need to run the postinst prelink
script at first boot. However, if the user has not enabled image
prelinking -- then we do enable the script to run on first boot.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-devtools/prelink/prelink_git.bb |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/prelink/prelink_git.bb
b/meta/recipes-devtools/prelink/prelink_git.bb
index b57c145..c653d4d 100644
--- a/meta/recipes-devtools/prelink/prelink_git.bb
+++ b/meta/recipes-devtools/prelink/prelink_git.bb
@@ -10,7 +10,7 @@ LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b
SRCREV = ac461e73b17253a4da25c5aafeac7193b553156c
PV = 1.0+git${SRCPV}
-PR = r3
+PR = r4
#
# The cron script attempts to re-prelink the system daily -- on
@@ -58,11 +58,13 @@ do_install_append () {
install -m 0644 ${WORKDIR}/macros.prelink
${D}${sysconfdir}/rpm/macros.prelink
}
+# If we're using image-prelink, we want to skip this on the host side
+# but still do it if the package is installed on the target...
pkg_postinst_prelink() {
#!/bin/sh
if [ x$D != x ]; then
- exit 1
+ ${@base_contains('USER_CLASSES', 'image-prelink', 'exit 0', 'exit 1', d)}
fi
prelink -a
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] wpa-supplicant: remove the 0.6.10 version.
Remove the 0.6.10 version since now 0.7.3 is the latest stable version. Signed-off-by: Dongxiao Xu dongxiao...@intel.com --- .../wpa-supplicant-0.6.10/99_wpa_supplicant|1 - .../wpa-supplicant-0.6.10/defaults-sane|8 - .../wpa-supplicant-0.6.10/defconfig-0.6.0-gnutls | 180 - .../wpa-supplicant-0.6.10/wpa-supplicant.sh| 85 --- .../wpa-supplicant-0.6.10/wpa_supplicant.conf | 690 .../wpa-supplicant-0.6.10/wpa_supplicant.conf-sane |7 - .../wpa-supplicant/wpa-supplicant-0.6.inc | 83 --- .../wpa-supplicant/wpa-supplicant_0.6.10.bb|4 - 8 files changed, 0 insertions(+), 1058 deletions(-) delete mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/99_wpa_supplicant delete mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defaults-sane delete mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defconfig-0.6.0-gnutls delete mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/wpa-supplicant.sh delete mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/wpa_supplicant.conf delete mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/wpa_supplicant.conf-sane delete mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.inc delete mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.6.10.bb diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/99_wpa_supplicant b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/99_wpa_supplicant deleted file mode 100644 index 6ff4dd8..000 --- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/99_wpa_supplicant +++ /dev/null @@ -1 +0,0 @@ -d root root 0700 /var/run/wpa_supplicant none diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defaults-sane b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defaults-sane deleted file mode 100644 index 67c4cbd..000 --- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defaults-sane +++ /dev/null @@ -1,8 +0,0 @@ -# Useful flags: -# -i ifname Interface (required, unless specified in config) -# -D driver Wireless Driver -# -d Debugging (-dd for more) -# -q Quiet (-qq for more) - -CONFIG=/etc/wpa_supplicant.conf -OPTIONS=-i eth1 -D wext diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defconfig-0.6.0-gnutls b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defconfig-0.6.0-gnutls deleted file mode 100644 index e907271..000 --- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defconfig-0.6.0-gnutls +++ /dev/null @@ -1,180 +0,0 @@ -# This file lists the configuration options that are used when building the -# hostapd binary. All lines starting with # are ignored. Configuration option -# lines must be commented out complete, if they are not to be included, i.e., -# just setting VARIABLE=n is not disabling that variable. -# -# This file is included in Makefile, so variables like CFLAGS and LIBS can also -# be modified from here. In most cass, these lines should use += in order not -# to override previous values of the variables. - -CFLAGS = $(TARGET_CFLAGS) -I../src/hostapd -I../src/utils -I../src/driver/modules -I../src/rsn_supp -I../src/common -I../src/crypto -I../src -I./ -Wall -MMD -LIBS = $(TARGET_LDFLAGS) - -# Driver interface for Host AP driver -CONFIG_DRIVER_HOSTAP=y - -# Driver interface for Agere driver -#CONFIG_DRIVER_HERMES=y -#CFLAGS += -I../../hcf -I../../include -I../../include/hcf - -# Driver interface for madwifi driver -#CONFIG_DRIVER_MADWIFI=y -#CFLAGS += -I../madwifi/wpa - -# Driver interface for Prism54 driver -#CONFIG_DRIVER_PRISM54=y - -# Driver interface for ndiswrapper -#CONFIG_DRIVER_NDISWRAPPER=y - -# Driver interface for Atmel driver -#CONFIG_DRIVER_ATMEL=y - -# Driver interface for Broadcom driver -#CONFIG_DRIVER_BROADCOM=y -#CFLAGS += -I/opt/WRT54GS/release/src/include - -# Driver interface for Intel ipw2100 driver -#CONFIG_DRIVER_IPW2100=y - -# Driver interface for generic Linux wireless extensions -CONFIG_DRIVER_WEXT=y - -# Driver interface for FreeBSD net80211 layer (e.g., Atheros driver) -#CONFIG_DRIVER_BSD=y -#CFLAGS += -I/usr/local/include -#LIBS += -L/usr/local/lib - -# Driver interface for development testing -#CONFIG_DRIVER_TEST=y - -# Driver interface for wired Ethernet drivers -CONFIG_DRIVER_WIRED=y - -# Enable IEEE 802.1X Supplicant (automatically included if any EAP method is -# included) -CONFIG_IEEE8021X_EAPOL=y - -# EAP-MD5 (automatically included if EAP-TTLS is enabled) -CONFIG_EAP_MD5=y - -# EAP-MSCHAPv2 (automatically included if EAP-PEAP is enabled) -CONFIG_EAP_MSCHAPV2=y - -# EAP-TLS -CONFIG_EAP_TLS=y - -# EAL-PEAP -CONFIG_EAP_PEAP=y - -# EAP-TTLS -CONFIG_EAP_TTLS=y - -#
[OE-core] [PATCH 1/6] connman: Upgrade to version 0.75
Enable ofono plugin.
Adopt some logic in meta-oe on connman plugin runtime dependency.
Remove the fix-shutdown-ap-disconnect.patch since the original logic no longer
exists.
Add Upstream-Status information for patches.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
.../connman-0.65/fix-shutdown-ap-disconnect.patch | 42
.../add_xuser_dbus_permission.patch|2 +
.../connman/{connman-0.65 = connman-0.75}/connman |0
.../{connman-0.65 = connman-0.75}/dbusperms.patch |2 +
meta/recipes-connectivity/connman/connman.inc | 14 ++-
.../connman/{connman_0.65.bb = connman_0.75.bb} |8 ++--
6 files changed, 20 insertions(+), 48 deletions(-)
delete mode 100644
meta/recipes-connectivity/connman/connman-0.65/fix-shutdown-ap-disconnect.patch
rename meta/recipes-connectivity/connman/{connman-0.65 =
connman-0.75}/add_xuser_dbus_permission.patch (94%)
rename meta/recipes-connectivity/connman/{connman-0.65 =
connman-0.75}/connman (100%)
rename meta/recipes-connectivity/connman/{connman-0.65 =
connman-0.75}/dbusperms.patch (91%)
rename meta/recipes-connectivity/connman/{connman_0.65.bb = connman_0.75.bb}
(74%)
diff --git
a/meta/recipes-connectivity/connman/connman-0.65/fix-shutdown-ap-disconnect.patch
b/meta/recipes-connectivity/connman/connman-0.65/fix-shutdown-ap-disconnect.patch
deleted file mode 100644
index a0ad099..000
---
a/meta/recipes-connectivity/connman/connman-0.65/fix-shutdown-ap-disconnect.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-Schedule delayed scan when being disconnected from an AP
-
-When being disconnected from an AP, a delayed scan is scheduled to make
-sure the AP is still there. wpa_supplicant removes a BSS from its bss list
-when it disappears from the scan results twice in a row.
-
-Author: Samuel Ortiz sa...@linux.intel.com
-Ported by Dongxiao Xu dongxiao...@intel.com
-
-diff -ruN connman-0.56-orig/plugins/supplicant.c
connman-0.56/plugins/supplicant.c
connman-0.56-orig/plugins/supplicant.c 2010-09-25 15:08:21.242927383
+0800
-+++ connman-0.56/plugins/supplicant.c 2010-09-25 15:12:46.346136858 +0800
-@@ -2184,6 +2184,15 @@
- scanning == TRUE ? started : finished);
- }
-
-+static gboolean delayed_scan(gpointer user_data)
-+{
-+ struct supplicant_task *task = user_data;
-+
-+ supplicant_scan(task-device);
-+
-+ return FALSE;
-+}
-+
- static void state_change(struct supplicant_task *task, DBusMessage *msg)
- {
- DBusError error;
-@@ -2277,7 +2286,13 @@
- task_connect(task);
- } else
- task-network = NULL;
-+ } else {
-+ if (task-state == WPA_DISCONNECTED)
-+ g_timeout_add_seconds(10, delayed_scan, task);
-+
-+ remove_network(task);
- }
-+
- break;
-
- default:
diff --git
a/meta/recipes-connectivity/connman/connman-0.65/add_xuser_dbus_permission.patch
b/meta/recipes-connectivity/connman/connman-0.75/add_xuser_dbus_permission.patch
similarity index 94%
rename from
meta/recipes-connectivity/connman/connman-0.65/add_xuser_dbus_permission.patch
rename to
meta/recipes-connectivity/connman/connman-0.75/add_xuser_dbus_permission.patch
index 787d49b..764c689 100644
---
a/meta/recipes-connectivity/connman/connman-0.65/add_xuser_dbus_permission.patch
+++
b/meta/recipes-connectivity/connman/connman-0.75/add_xuser_dbus_permission.patch
@@ -1,6 +1,8 @@
Some platform (like atom-pc) enables rootless X,
thus we need to add the xuser in the list.
+Upstream-Status: Inappropriate [configuration]
+
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
diff -ruN connman-0.65-orig/src/connman-dbus.conf
connman-0.65/src/connman-dbus.conf
diff --git a/meta/recipes-connectivity/connman/connman-0.65/connman
b/meta/recipes-connectivity/connman/connman-0.75/connman
similarity index 100%
rename from meta/recipes-connectivity/connman/connman-0.65/connman
rename to meta/recipes-connectivity/connman/connman-0.75/connman
diff --git a/meta/recipes-connectivity/connman/connman-0.65/dbusperms.patch
b/meta/recipes-connectivity/connman/connman-0.75/dbusperms.patch
similarity index 91%
rename from meta/recipes-connectivity/connman/connman-0.65/dbusperms.patch
rename to meta/recipes-connectivity/connman/connman-0.75/dbusperms.patch
index 100af03..c331654 100644
--- a/meta/recipes-connectivity/connman/connman-0.65/dbusperms.patch
+++ b/meta/recipes-connectivity/connman/connman-0.75/dbusperms.patch
@@ -1,3 +1,5 @@
+Upstream-Status: Inappropriate [configuration]
+
Index: git/src/connman-dbus.conf
===
--- git.orig/src/connman-dbus.conf 2009-05-26 00:34:35.0 +0100
diff --git a/meta/recipes-connectivity/connman/connman.inc
b/meta/recipes-connectivity/connman/connman.inc
index fb970ed..ccff573 100644
---
[OE-core] [PATCH 4/6] connman-gnome: Add 3G configuration support
Apply 3g.patch which add cellular config option in connman-gnome.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
.../connman/connman-gnome/3g.patch | 505
.../connman/connman-gnome_0.5.bb |8 +-
2 files changed, 510 insertions(+), 3 deletions(-)
create mode 100644 meta/recipes-connectivity/connman/connman-gnome/3g.patch
diff --git a/meta/recipes-connectivity/connman/connman-gnome/3g.patch
b/meta/recipes-connectivity/connman/connman-gnome/3g.patch
new file mode 100644
index 000..c73c1ea
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman-gnome/3g.patch
@@ -0,0 +1,505 @@
+commit 15852e826b0b47f577718ada4b68b63515387f4d
+Author: dongxiao dongxiao@dongxiao-osel.(none)
+Date: Wed Jun 1 14:56:16 2011 +0800
+
+connman-gnome: Add cellular network config option.
+
+Add cellular network config option in connman-gnome.
+
+Signed-off-by: Dongxiao Xu dongxiao...@intel.com
+
+diff --git a/common/connman-client.c b/common/connman-client.c
+index e907cc2..d6be363 100644
+--- a/common/connman-client.c
b/common/connman-client.c
+@@ -112,9 +112,10 @@ static void connman_client_init(ConnmanClient *client)
+ G_TYPE_STRING, /* address */
+ G_TYPE_STRING, /* netmask */
+ G_TYPE_STRING, /* gateway */
+- G_TYPE_BOOLEAN, /* gateway */
+- G_TYPE_BOOLEAN, /* gateway */
+- G_TYPE_BOOLEAN);/* gateway */
++ G_TYPE_BOOLEAN, /* ethernet enabled */
++ G_TYPE_BOOLEAN, /* wifi enabled */
++ G_TYPE_BOOLEAN, /* cellular enabled */
++ G_TYPE_BOOLEAN);/* offline */
+
+ g_object_set_data(G_OBJECT(priv-store),
+ State, g_strdup(unavailable));
+@@ -218,6 +219,7 @@ static gboolean device_filter(GtkTreeModel *model,
+ switch (type) {
+ case CONNMAN_TYPE_LABEL_ETHERNET:
+ case CONNMAN_TYPE_LABEL_WIFI:
++ case CONNMAN_TYPE_LABEL_CELLULAR:
+ case CONNMAN_TYPE_SYSCONFIG:
+ return TRUE;
+ }
+diff --git a/common/connman-client.h b/common/connman-client.h
+index 37e86d0..15fa098 100644
+--- a/common/connman-client.h
b/common/connman-client.h
+@@ -117,6 +117,7 @@ enum {
+
+ CONNMAN_COLUMN_ETHERNET_ENABLED,/* G_TYPE_STRING */
+ CONNMAN_COLUMN_WIFI_ENABLED,/* G_TYPE_STRING */
++ CONNMAN_COLUMN_CELLULAR_ENABLED,/* G_TYPE_STRING */
+ CONNMAN_COLUMN_OFFLINEMODE, /* G_TYPE_STRING */
+
+ _CONNMAN_NUM_COLUMNS
+@@ -132,6 +133,7 @@ enum {
+
+ CONNMAN_TYPE_LABEL_ETHERNET,
+ CONNMAN_TYPE_LABEL_WIFI,
++ CONNMAN_TYPE_LABEL_CELLULAR,
+ CONNMAN_TYPE_SYSCONFIG,
+
+ _CONNMAN_NUM_TYPE,
+diff --git a/common/connman-dbus.c b/common/connman-dbus.c
+index b5a635c..0f4e1db 100644
+--- a/common/connman-dbus.c
b/common/connman-dbus.c
+@@ -208,6 +208,8 @@ static const gchar *type2icon(guint type)
+ case CONNMAN_TYPE_WIFI:
+ case CONNMAN_TYPE_WIMAX:
+ return network-wireless;
++ case CONNMAN_TYPE_CELLULAR:
++ return network-cellular;
+ case CONNMAN_TYPE_BLUETOOTH:
+ return bluetooth;
+ }
+@@ -220,6 +222,7 @@ static void enabled_technologies_changed(GtkTreeStore
*store, GValue *value)
+ GtkTreeIter iter;
+ gboolean ethernet_enabled_prev, ethernet_enabled = FALSE;
+ gboolean wifi_enabled_prev, wifi_enabled = FALSE;
++ gboolean cellular_enabled_prev, cellular_enabled = FALSE;
+ gchar **tech = g_value_get_boxed (value);
+ guint i;
+
+@@ -227,10 +230,13 @@ static void enabled_technologies_changed(GtkTreeStore
*store, GValue *value)
+ return;
+
+ for (i = 0; i g_strv_length(tech); i++) {
++ DBG(technology: %s, *(tech+i));
+ if (g_str_equal(ethernet, *(tech + i)))
+ ethernet_enabled = TRUE;
+ else if (g_str_equal (wifi, *(tech + i)))
+ wifi_enabled = TRUE;
++ else if (g_str_equal (cellular, *(tech + i)))
++ cellular_enabled = TRUE;
+ }
+
+ get_iter_from_type(store, iter, CONNMAN_TYPE_LABEL_ETHERNET);
+@@ -246,6 +252,13 @@ static void enabled_technologies_changed(GtkTreeStore
*store, GValue *value)
+ if (wifi_enabled_prev != wifi_enabled)
+ gtk_tree_store_set(store, iter,
+ CONNMAN_COLUMN_WIFI_ENABLED,
wifi_enabled, -1);
++
++ get_iter_from_type(store, iter, CONNMAN_TYPE_LABEL_CELLULAR);
++ gtk_tree_model_get(GTK_TREE_MODEL(store), iter,
++ CONNMAN_COLUMN_CELLULAR_ENABLED,
cellular_enabled_prev, -1);
++ if (cellular_enabled_prev != cellular_enabled)
++
[OE-core] [PATCH 3/6] ofono: upgrade to version 0.50
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/conf/distro/include/default-versions.inc |4
meta/recipes-connectivity/ofono/ofono.inc |2 ++
meta/recipes-connectivity/ofono/ofono_0.45.bb |9 -
meta/recipes-connectivity/ofono/ofono_0.50.bb | 13 +
4 files changed, 15 insertions(+), 13 deletions(-)
delete mode 100644 meta/recipes-connectivity/ofono/ofono_0.45.bb
create mode 100644 meta/recipes-connectivity/ofono/ofono_0.50.bb
diff --git a/meta/conf/distro/include/default-versions.inc
b/meta/conf/distro/include/default-versions.inc
index 0abbd8f..377aba5 100644
--- a/meta/conf/distro/include/default-versions.inc
+++ b/meta/conf/distro/include/default-versions.inc
@@ -12,7 +12,3 @@ PREFERRED_VERSION_python-native ?= 2.6.6
# Force the older version of liberation-fonts until we fix the fontforge issue
PREFERRED_VERSION_liberation-fonts ?= 1.04
-
-
-
-
diff --git a/meta/recipes-connectivity/ofono/ofono.inc
b/meta/recipes-connectivity/ofono/ofono.inc
index ee3bc3e..4fc969c 100644
--- a/meta/recipes-connectivity/ofono/ofono.inc
+++ b/meta/recipes-connectivity/ofono/ofono.inc
@@ -15,5 +15,7 @@ INITSCRIPT_PARAMS = defaults 22
do_install_append() {
install -d ${D}${sysconfdir}/init.d/
install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
+ install -d ${D}${sysconfdir}/udev/rules.d/
+ install -m 0644 ${S}/plugins/97-ofono.rules ${D}${sysconfdir}/udev/rules.d/
}
diff --git a/meta/recipes-connectivity/ofono/ofono_0.45.bb
b/meta/recipes-connectivity/ofono/ofono_0.45.bb
deleted file mode 100644
index 4a8950f..000
--- a/meta/recipes-connectivity/ofono/ofono_0.45.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-require ofono.inc
-
-PR = r0
-
-SRC_URI = ${KERNELORG_MIRROR}/linux/network/ofono/${P}.tar.bz2 \
- file://ofono
-
-SRC_URI[md5sum] = 31dabb077e7592ba36913bd9d0c76b94
-SRC_URI[sha256sum] =
5541e832fb72c6c647b663e5ee55384a33efaee5a34c4544e3a16af94892f47e
diff --git a/meta/recipes-connectivity/ofono/ofono_0.50.bb
b/meta/recipes-connectivity/ofono/ofono_0.50.bb
new file mode 100644
index 000..eb82e39
--- /dev/null
+++ b/meta/recipes-connectivity/ofono/ofono_0.50.bb
@@ -0,0 +1,13 @@
+require ofono.inc
+
+PR = r0
+
+SRC_URI = ${KERNELORG_MIRROR}/linux/network/ofono/${P}.tar.bz2 \
+ file://ofono
+
+EXTRA_OECONF += \
+--enable-test \
+
+
+SRC_URI[md5sum] = b2656fd0bbf33f926fc86c1e8915d697
+SRC_URI[sha256sum] =
f8f8dd917847a007e4d441b949efc4d28dc3644526d5293016844c2536c65ff9
--
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/6 v4][PULL] 3G network support
Hi,
This is the 4th version of 3G patches, please help to review and pull.
Changes from v3:
1) Use DISTRO_FEATURE to handle the dependency of ofono.
2) Adopt ofono 0.50 version which could work with Ericsson modem.
(ofono's commit d99ca17 fixed the crash issue)
Thanks,
Dongxiao
The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065:
u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dxu4/ggg-v4
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/ggg-v4
Dongxiao Xu (6):
connman: Upgrade to version 0.75
wpa-supplicant: remove the 0.6.10 version.
ofono: upgrade to version 0.50
connman-gnome: Add 3G configuration support
initscript: Change some order of init scripts
task-base: add 3G into DISTRO_FEATURE
meta/conf/distro/include/default-distrovars.inc|2 +-
meta/conf/distro/include/default-versions.inc |4 -
.../connman-0.65/fix-shutdown-ap-disconnect.patch | 42 --
.../add_xuser_dbus_permission.patch|2 +
.../connman/{connman-0.65 = connman-0.75}/connman |0
.../{connman-0.65 = connman-0.75}/dbusperms.patch |2 +
.../connman/connman-gnome/3g.patch | 505 ++
.../connman/connman-gnome_0.5.bb |8 +-
meta/recipes-connectivity/connman/connman.inc | 14 +-
.../connman/{connman_0.65.bb = connman_0.75.bb} |8 +-
meta/recipes-connectivity/ofono/ofono.inc |2 +
meta/recipes-connectivity/ofono/ofono_0.45.bb |9 -
meta/recipes-connectivity/ofono/ofono_0.50.bb | 13 +
.../wpa-supplicant-0.6.10/99_wpa_supplicant|1 -
.../wpa-supplicant-0.6.10/defaults-sane|8 -
.../wpa-supplicant-0.6.10/defconfig-0.6.0-gnutls | 180 -
.../wpa-supplicant-0.6.10/wpa-supplicant.sh| 85 ---
.../wpa-supplicant-0.6.10/wpa_supplicant.conf | 690
.../wpa-supplicant-0.6.10/wpa_supplicant.conf-sane |7 -
.../wpa-supplicant/wpa-supplicant-0.6.inc | 83 ---
.../wpa-supplicant/wpa-supplicant_0.6.10.bb|4 -
meta/recipes-core/initscripts/initscripts_1.0.bb |6 +-
meta/recipes-core/tasks/task-base.bb | 16 +-
meta/recipes-core/udev/udev-new.inc|2 +-
meta/recipes-core/udev/udev_164.bb |2 +-
.../modutils/modutils-initscripts.bb |4 +-
26 files changed, 568 insertions(+), 1131 deletions(-)
delete mode 100644
meta/recipes-connectivity/connman/connman-0.65/fix-shutdown-ap-disconnect.patch
rename meta/recipes-connectivity/connman/{connman-0.65 =
connman-0.75}/add_xuser_dbus_permission.patch (94%)
rename meta/recipes-connectivity/connman/{connman-0.65 =
connman-0.75}/connman (100%)
rename meta/recipes-connectivity/connman/{connman-0.65 =
connman-0.75}/dbusperms.patch (91%)
create mode 100644 meta/recipes-connectivity/connman/connman-gnome/3g.patch
rename meta/recipes-connectivity/connman/{connman_0.65.bb = connman_0.75.bb}
(74%)
delete mode 100644 meta/recipes-connectivity/ofono/ofono_0.45.bb
create mode 100644 meta/recipes-connectivity/ofono/ofono_0.50.bb
delete mode 100644
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/99_wpa_supplicant
delete mode 100644
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defaults-sane
delete mode 100644
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/defconfig-0.6.0-gnutls
delete mode 100644
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/wpa-supplicant.sh
delete mode 100644
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/wpa_supplicant.conf
delete mode 100644
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.10/wpa_supplicant.conf-sane
delete mode 100644
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.6.inc
delete mode 100644
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.6.10.bb
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] task-base: add 3G into DISTRO_FEATURE
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/conf/distro/include/default-distrovars.inc |2 +-
meta/recipes-core/tasks/task-base.bb| 16 +++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/meta/conf/distro/include/default-distrovars.inc
b/meta/conf/distro/include/default-distrovars.inc
index 2cde46c..2f36f59 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -17,7 +17,7 @@ DISTRO_FEATURES_LIBC ?= ipv6 libc-backtrace libc-big-macros
libc-bsd libc-cxx-t
libc-utmp libc-utmpx libc-wordexp
libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc \
libc-posix-wchar-io
-DISTRO_FEATURES ?= alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs
zeroconf pci ${DISTRO_FEATURES_LIBC}
+DISTRO_FEATURES ?= alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs
zeroconf pci 3g ${DISTRO_FEATURES_LIBC}
IMAGE_FEATURES ?=
diff --git a/meta/recipes-core/tasks/task-base.bb
b/meta/recipes-core/tasks/task-base.bb
index a2a8925..3ff57ff 100644
--- a/meta/recipes-core/tasks/task-base.bb
+++ b/meta/recipes-core/tasks/task-base.bb
@@ -2,7 +2,7 @@ DESCRIPTION = Merge machine and distro options to create a
basic machine task/p
LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
-PR = r70
+PR = r71
inherit task
@@ -35,6 +35,7 @@ PACKAGES = ' \
\
${@base_contains(DISTRO_FEATURES, bluetooth,
task-base-bluetooth, , d)} \
${@base_contains(DISTRO_FEATURES, wifi, task-base-wifi, ,
d)} \
+${@base_contains(DISTRO_FEATURES, 3g, task-base-3g, , d)} \
${@base_contains(DISTRO_FEATURES, cramfs, task-base-cramfs,
, d)} \
${@base_contains(DISTRO_FEATURES, ipsec, task-base-ipsec,
, d)} \
${@base_contains(DISTRO_FEATURES, ipv6, task-base-ipv6, ,
d)} \
@@ -95,6 +96,7 @@ RDEPENDS_task-base = \
${@base_contains('COMBINED_FEATURES', 'usbhost', 'task-base-usbhost',
'',d)} \
${@base_contains('COMBINED_FEATURES', 'bluetooth', 'task-base-bluetooth',
'',d)} \
${@base_contains('COMBINED_FEATURES', 'wifi', 'task-base-wifi', '',d)} \
+${@base_contains('COMBINED_FEATURES', '3g', 'task-base-3g', '',d)} \
${@base_contains('COMBINED_FEATURES', 'uboot', 'task-base-uboot', '',d)} \
${@base_contains('COMBINED_FEATURES', 'redboot', 'task-base-redboot',
'',d)} \
${@base_contains('COMBINED_FEATURES', 'apex', 'task-base-apex', '',d)} \
@@ -114,10 +116,12 @@ RDEPENDS_task-base-extended = \
task-base \
${ADD_WIFI} \
${ADD_BT} \
+${ADD_3G} \
ADD_WIFI =
ADD_BT =
+ADD_3G =
python __anonymous () {
# If Distro want wifi and machine feature wifi/pci/pcmcia/usbhost (one of
them)
@@ -133,6 +137,9 @@ python __anonymous () {
if wifi in distro_features and not wifi in machine_features and
(pcmcia in machine_features or pci in machine_features or usbhost in
machine_features):
bb.data.setVar(ADD_WIFI, task-base-wifi, d)
+
+if 3g in distro_features and not 3g in machine_features and (pcmcia
in machine_features or pci in machine_features or usbhost in
machine_features):
+ bb.data.setVar(ADD_3G, task-base-3g, d)
}
#
@@ -339,6 +346,13 @@ RRECOMMENDS_task-base-wifi = \
kernel-module-aes-generic \
kernel-module-aes
+RDEPENDS_task-base-3g = \
+ofono
+
+RRECOMMENDS_task-base-3g = \
+kernel-module-cdc-acm \
+kernel-module-cdc-wdm
+
RRECOMMENDS_task-base-smbfs = \
kernel-module-cifs \
kernel-module-smbfs
--
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 5/6] initscript: Change some order of init scripts
Move udev script to execute ealier since module autoload needs it to
create device nodes.
Also move sysfs before udev which has dependency on it.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/recipes-core/initscripts/initscripts_1.0.bb |6 +++---
meta/recipes-core/udev/udev-new.inc|2 +-
meta/recipes-core/udev/udev_164.bb |2 +-
.../modutils/modutils-initscripts.bb |4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 48b65b9..9e535af 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -4,7 +4,7 @@ SECTION = base
PRIORITY = required
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
-PR = r126
+PR = r127
INHIBIT_DEFAULT_DEPS = 1
@@ -119,8 +119,8 @@ do_install () {
ln -sf ../init.d/bootmisc.sh
${D}${sysconfdir}/rcS.d/S55bootmisc.sh
# ln -sf ../init.d/urandom
${D}${sysconfdir}/rcS.d/S55urandom
# ln -sf ../init.d/finish.sh
${D}${sysconfdir}/rcS.d/S99finish.sh
- # udev will run at S04 if installed
- ln -sf ../init.d/sysfs.sh
${D}${sysconfdir}/rcS.d/S03sysfs.sh
+ ln -sf ../init.d/sysfs.sh
${D}${sysconfdir}/rcS.d/S02sysfs.sh
+ # udev will run at S03 if installed
ln -sf ../init.d/populate-volatile.sh
${D}${sysconfdir}/rcS.d/S37populate-volatile.sh
ln -sf ../init.d/devpts.sh
${D}${sysconfdir}/rcS.d/S38devpts.sh
if [ ${TARGET_ARCH} = arm ]; then
diff --git a/meta/recipes-core/udev/udev-new.inc
b/meta/recipes-core/udev/udev-new.inc
index 1b94f1b..4c4451f 100644
--- a/meta/recipes-core/udev/udev-new.inc
+++ b/meta/recipes-core/udev/udev-new.inc
@@ -40,7 +40,7 @@ PACKAGES =+ libgudev libgudev-dev libgudev-dbg
INITSCRIPT_PACKAGES = udev udev-cache
INITSCRIPT_NAME_udev = udev
-INITSCRIPT_PARAMS_udev = start 04 S .
+INITSCRIPT_PARAMS_udev = start 03 S .
INITSCRIPT_NAME_udev-cache = udev-cache
INITSCRIPT_PARAMS_udev-cache = start 36 S .
diff --git a/meta/recipes-core/udev/udev_164.bb
b/meta/recipes-core/udev/udev_164.bb
index 76fd907..567e62e 100644
--- a/meta/recipes-core/udev/udev_164.bb
+++ b/meta/recipes-core/udev/udev_164.bb
@@ -1,6 +1,6 @@
include udev-new.inc
-PR = r2
+PR = r3
SRC_URI[md5sum] = fddac2d54761ea34865af9467377ca9f
SRC_URI[sha256sum] =
c12e66280b5e1465f6587a8cfa47d7405c4caa7e52ce5dd13478d04f6ec05e5c
diff --git a/meta/recipes-kernel/modutils/modutils-initscripts.bb
b/meta/recipes-kernel/modutils/modutils-initscripts.bb
index 5ae34b4..89d38cf 100644
--- a/meta/recipes-kernel/modutils/modutils-initscripts.bb
+++ b/meta/recipes-kernel/modutils/modutils-initscripts.bb
@@ -4,10 +4,10 @@ LICENSE = PD
LIC_FILES_CHKSUM = file://LICENSE;md5=7bf87fc37976e93ec66ad84fac58c098
SRC_URI = file://modutils.sh \
file://PD.patch
-PR = r5
+PR = r6
INITSCRIPT_NAME = modutils.sh
-INITSCRIPT_PARAMS = start 2 S .
+INITSCRIPT_PARAMS = start 4 S .
inherit update-rc.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] MINUTES: OE-TSC meeting 23-Jun-2011
MINUTES: OE-TSC meeting 23-Jun-2011 Attendees: Richard, Tom, Khem, Koen, Mark, Stefan Notes: Jefro Agenda Action Items 01) choose a meeting chair stefan 02) new topics Discussion about more (or more complex) building before pushing changes to master (Tartarus) new features in OE-Core and bitbake changes needed to support them (RP) 03) action items from last week -- patches appearing on oe-dev, khem to send email regarding put stuff in meta-oe not done yet -- Tom to change strategy for maint branch, oe.dev master to oe-core/meta-oe/layer done -- promote devs to participate on oe-user - on agenda for next week done 04) TSC structure elections -- RP to send a note to board asking for status on prior message done, board has responded will start elections this week 05) Status updates - oe-core Saul out. RP: working code out there as a foundation for multilib which is great not so great was the backlog of patches, RP is almost through them complicated by Yocto infrastructure issues lack of testing is an issue - some discussion about adding testing to patches prior to commit Tom suggests that there is already a policy for updates, but some things came from sstate - lesson learned -- (all) think twice about pull requests RP: 1. multilib - there is a plan and rough code out there some bitbake changes and oe-core dependenies on those ok this cycle but we probably need to stop doing this and get better organised before 1.14 in October Changes + a bitbake min ver bump, warn people now 2. patterns email - current state of our core classes depressing full of horrible hacks for PACKAGE_ARCH, BASE_PACKAGE_ARCH... know how to clean it up but not how to do so without breaking backwards compatibility heirarchical definition of a arch - multilib - tune - BSP/machine mechanics easy, transition is hard multilib exposes a lot of design issues discuss in email fray has gotten all of the patches out to fix the majority of the permission/owners/group issues.. only thing remaining is symlink vs actualy directory ownership - bsp guidelines clarify - using layers for BSPs - metadata layer splitting - infrastructure melo having issues fallback github seems to have worked khem working on making libtirpc be a drop in replacement for glibc rpc but much work required RAW TRANSCRIPT 12:59 +Jefro sounds like a quorum: RP__ stefan_schmidt Tartarus koen khem 12:59 +stefan_schmidt lets wait some minutes for fray 13:00 +stefan_schmidt he was just out for getting lunch 13:00 *** fray is here now 13:00 +stefan_schmidt great 13:00 +stefan_schmidt chair? 13:01 +Jefro http://pastebin.com/bZfpaqvN is the agenda 13:01 +stefan_schmidt i can chair if nobody wants 13:01 +Jefro stefan_schmidt wins the chair going into round 2 13:01 +khem ok 13:01 +stefan_schmidt new topics anyone? 13:02 +stefan_schmidt (02) new topics) 13:02 +Tartarus Yeah, I think I have a new topic 13:02 +stefan_schmidt shot 13:02 +Tartarus Discussion about more (or more complex) building before pushing changes to master 13:02 +RP__ We should probably talk about new features in OE-Core and bitbake changes needed to support them 13:02 +Tartarus I'll also say maybe it's a bit of an over-react to the glibc thing 13:03 +RP__ Tartarus: Say when and I'll explain why I did that :) 13:03 +Tartarus Yeah, lets just talk about it when we get to it, that's all 13:03 +Tartarus All I've got for new topics 13:03 +RP__ I sent out that patterns in class hackery email 13:03 +stefan_schmidt that fits in 5 13:04 +stefan_schmidt so we put this in status updates 13:04 +stefan_schmidt any more topics? 13:04 +RP__ none here 13:04 +fray nothing here 13:05 +stefan_schmidt ok, closed 13:05 +stefan_schmidt 03) action items from last week 13:05 +Tartarus OK, for my AI I updated the wiki page and sent out the email (which noted that this is just spelling out the policy more clearly, it didn't say oe.dev only before, just relevant upstream) 13:05 +Tartarus So that's done. 13:05 +stefan_schmidt ok 13:06 +stefan_schmidt can be off list next week 13:06 *** Jefro notes 13:06 +khem my AR for oe-users is also done 13:06 +stefan_schmidt oe-user is also done as it got closed 13:06 +stefan_schmidt right :) 13:06 +khem list is r/o now well sort off 13:06 +stefan_schmidt with a notice posting to dev 13:06 +stefan_schmidt ok, not worth an AR any more 13:06 +stefan_schmidt can go off list as well 13:07 +stefan_schmidt khem: -- patches appearing on oe-dev, khem to send email regarding put stuff in meta-oe 13:07 +khem stefan_schmidt: I did not do that yet 13:07 +stefan_schmidt khem: ok, so this one we are keeping 13:07 +stefan_schmidt am I to fast? 13:07 +RP__ stefan_schmidt: no :) 13:07 +stefan_schmidt good 13:08 +khem although it means building/testing using oe-core 13:08 +stefan_schmidt 04) TSC structure elections 13:08 +RP__ For 04 I have a reply from the board saying they accepted our proposal and will be starting the election
[OE-core] [PATCH 0/1][PULL] Update manual check info in distro_checking_fields.inc
Hi Saul, This pull request update the manual check fields in distro_checking_fields.inc, Please help to review and pull. Thanks, Dongxiao The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dxu4/upgrade http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/upgrade Dongxiao Xu (1): distro_tracking: update some manual checking fields .../conf/distro/include/distro_tracking_fields.inc | 18 +++--- 1 files changed, 11 insertions(+), 7 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] distro_tracking: update some manual checking fields
linux-firmware minicom opkg dpkg wireless-tools libgsmd libsamplerate0 Signed-off-by: Dongxiao Xu dongxiao...@intel.com --- .../conf/distro/include/distro_tracking_fields.inc | 18 +++--- 1 files changed, 11 insertions(+), 7 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index e9594cf..8a13426 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -47,11 +47,12 @@ RECIPE_MAINTAINER_pn-libtimedate-perl = Nitin A Kamble nitin.a.kam...@intel.co DISTRO_PN_ALIAS_pn-libtimedate-perl = Debian=libtimedate-perl Ubuntu=libtimedate-perl RECIPE_STATUS_pn-linux-firmware = green -RECIPE_LATEST_VERSION_pn-linux-firmware = 40c0f950 +RECIPE_LATEST_VERSION_pn-linux-firmware = 97649b1e RECIPE_LATEST_RELEASE_DATE_pn-linux-firmware = 2010/12/01 RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-linux-firmware = n/a RECIPE_NO_OF_PATCHES_pn-linux-firmware = 0 RECIPE_LAST_UPDATE_pn-linux-firmware = Dec 30, 2010 +RECIPE_MANUAL_CHECK_DATE_pn-linux-firmware = Jun 29, 2011 RECIPE_MAINTAINER_pn-linux-firmware = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-logrotate = red @@ -85,7 +86,7 @@ RECIPE_NO_OF_PATCHES_pn-minicom=1 RECIPE_LATEST_RELEASE_DATE_pn-minicom=2010/12/20 RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-minicom=22 months RECIPE_LAST_UPDATE_pn-minicom = Nov 24, 2010 -RECIPE_MANUAL_CHECK_DATE_pn-minicom = Jan 30, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-minicom = Jun 29, 2011 RECIPE_MAINTAINER_pn-minicom = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-patch = green @@ -740,6 +741,7 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-opkg = 2 months RECIPE_LATEST_RELEASE_DATE_pn-opkg = 02/2010 RECIPE_COMMENTS_pn-opkg = RECIPE_LAST_UPDATE_pn-opkg = Jul 21, 2010 +RECIPE_MANUAL_CHECK_DATE_pn-opkg = Jun 29, 2011 RECIPE_MAINTAINER_pn-opkg = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-opkg_nogpg = green @@ -753,11 +755,12 @@ RECIPE_LAST_UPDATE_pn-opkg_nogpg = Jul 21, 2010 RECIPE_MAINTAINER_pn-opkg_nogpg = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-dpkg = green -RECIPE_LATEST_VERSION_pn-dpkg = 1.15.8.7 +RECIPE_LATEST_VERSION_pn-dpkg = 1.16.0.3 RECIPE_INTEL_SECTION_pn-dpkg = base utils -RECIPE_LATEST_RELEASE_DATE_pn-dpkg = 2010/12/20 -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-dpkg = 3 months +RECIPE_LATEST_RELEASE_DATE_pn-dpkg = 2011/05/04 +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-dpkg = 1 months RECIPE_LAST_UPDATE_pn-dpkg = Dec 30, 2010 +RECIPE_MANUAL_CHECK_DATE_pn-dpkg = Jun 29, 2011 RECIPE_MAINTAINER_pn-dpkg = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-opkg-utils = green @@ -2025,7 +2028,7 @@ RECIPE_NO_OF_PATCHES_pn-wireless-tools=3 RECIPE_LATEST_RELEASE_DATE_pn-wireless-tools=2007/09/18 RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-wireless-tools=18 months RECIPE_LAST_UPDATE_pn-wireless-tools = Oct 19, 2007 -RECIPE_MANUAL_CHECK_DATE_pn-wireless-tools = Jan 30, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-wireless-tools = Jun 29, 2011 RECIPE_MAINTAINER_pn-wireless-tools = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-bluez-dtl1-workaround=yellow # LICENSE double check @@ -2227,6 +2230,7 @@ RECIPE_LATEST_RELEASE_DATE_pn-libgsmd =2009/08/06 RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-libgsmd=n/a DISTRO_PN_ALIAS_pn-libgsmd = Fedora=gsm Ubuntu=libgsm Debian=libgsm Opensuse=libgsm RECIPE_LAST_UPDATE_pn-libgsmd = Nov 26, 2010 +RECIPE_MANUAL_CHECK_DATE_pn-libgsmd = Jun 29, 2011 RECIPE_MAINTAINER_pn-libgsmd = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-zeroconf = red @@ -2712,7 +2716,7 @@ RECIPE_STATUS_pn-libsamplerate0 = green DISTRO_PN_ALIAS_pn-libsamplerate0 = Meego=libsamplerate Fedora=libsamplerate OpenSuSE=libsamplerate Ubuntu=libsamplerate Mandriva=libsamplerate Debian=libsamplerate RECIPE_LATEST_VERSION_pn-libsamplerate0 = 0.1.7 RECIPE_LAST_UPDATE_pn-libsamplerate0 = Apr 26, 2011 -RECIPE_MANUAL_CHECK_DATE_pn-libsamplerate0 = Apr 26, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-libsamplerate0 = Jun 29, 2011 RECIPE_MAINTAINER_pn-libsamplerate0 = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-oprofileui = green -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
