[OE-core] [PATCH 0/2] archiver.bbclass:Improve the usability for the archiver classes
From: Xiaofeng Yan xiaofeng@windriver.com The usability of the archiver classes can be improved, beyond the simple addition of default values for the variables. A user could well inherit just archiver rather than the individual useful classes, and not realize it will do nothing. The following changes since commit f28209d9d3c67203a2c7a2b25cacfe31643d1bfa: Kang Kai (1): cooker.py: terminate the Parser processes are available in the git repository at: git://git.pokylinux.org/poky-contrib xiaofeng/2472 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/2472 Xiaofeng Yan (2): archiver.bbclass: Improve the usability for the archiver classes local.conf.sample.extended: Change the usage about arhiver.bbclass meta-yocto/conf/local.conf.sample.extended | 31 --- meta/classes/archiver.bbclass |6 +++- 2 files changed, 22 insertions(+), 15 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] archiver.bbclass: Improve the usability for the archiver classes
From: Xiaofeng Yan xiaofeng@windriver.com
The usability of the archiver classes can be improved, beyond the
simple addition of default values for the variables. A user could
well inherit just archiver rather than the individual useful classes,
and not realize it will do nothing.
[YOCTO #2472]
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
meta/classes/archiver.bbclass |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index ac8aa95..582c565 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -6,8 +6,10 @@ ARCHIVE_EXCLUDE_FROM ?= .pc autom4te.cache
ARCHIVE_TYPE ?= TAR SRPM
DISTRO ?= poky
PATCHES_ARCHIVE_WITH_SERIES = 'TRUE'
-SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= 'logs_with_scripts'
-SOURCE_ARCHIVE_PACKAGE_TYPE ?= 'tar'
+SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= '${@d.getVarFlag('ARCHIVER_MODE',
'log_type') \
+if d.getVarFlag('ARCHIVER_MODE',
'log_type') != 'none' else 'logs_with_scripts'}'
+SOURCE_ARCHIVE_PACKAGE_TYPE ?= '${@d.getVarFlag('ARCHIVER_MODE','type') \
+ if d.getVarFlag('ARCHIVER_MODE',
'log_type')!= 'none' else 'tar'}'
def get_bb_inc(d):
'''create a directory script-logs including .bb and .inc file in
${WORKDIR}'''
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] local.conf.sample.extended: Change the usage about arhiver.bbclass
From: Xiaofeng Yan xiaofeng@windriver.com
Change the usage about arhiver.bbclass due to the improvement for
usability of archiver.bbclass
[YOCTO #2472]
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
meta-yocto/conf/local.conf.sample.extended | 31 ---
1 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/meta-yocto/conf/local.conf.sample.extended
b/meta-yocto/conf/local.conf.sample.extended
index b493094..66b94ad 100644
--- a/meta-yocto/conf/local.conf.sample.extended
+++ b/meta-yocto/conf/local.conf.sample.extended
@@ -184,20 +184,25 @@
# Archiving source code configuration
#
-# The following variables control which files to archive and the type to
archive to generate.
-# There are three basic class defintions of common operations that might be
desired and these
-# can be enabled by uncommenting one of the following lines:
-#
-# INHERIT += archive-original-source
-# INHERIT += archive-patched-source
-#INHERIT =+ archive-configured-source
-#
+# The following variables control which files to archive and
+# the type to archive to generate.
+# The content to archive
+# original:Copy source code package from downloads if existing.
+# Archive source code after do_unpack if not found in downloads
+# patched:Archive source code package after do_patch
+# configured: Archive source code package after do_configure
+# ARCHIVER_MODE[choices] = none original patched configured
# Type of archive:
-# SOURCE_ARCHIVE_PACKAGE_TYPE = 'srpm'
-#SOURCE_ARCHIVE_PACKAGE_TYPE ?= 'tar'
-#
+# ARCHIVER_MODE[type] = tar srpm
# Whether to include WORKDIR/temp, .bb and .inc files:
# 'logs_with_scripts' include WORKDIR/temp directory and .bb and .inc files
# 'logs' only include WORKDIR/temp
-# SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= 'logs'
-#SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= 'logs_with_scripts'
+# ARCHIVER_MODE[log_type] = logs logs_with_scripts
+# There are three basic class defintions of common operations
+# that might be desired and these can be enabled by
+# uncommenting five of the following lines:
+#ARCHIVER_MODE ?= original
+#ARCHIVER_MODE[type] ?= tar
+#ARCHIVER_MODE[log_type] ?= logs_with_scripts
+#ARCHIVER_CLASS = ${@'archive-${ARCHIVER_MODE}-source' if ARCHIVER_MODE !=
'none' else ''}
+#INHERIT += ${ARCHIVER_CLASS}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] generate-manifest-2.7.py: replace os.popen with os.unlink
The os.popen function would fail (more or less) silently if the executed program cannot be found, and here what we need is os.system not os.popen since it doesn't use the return value, use os.unlink() and ignore exceptions from it would be better as Chris suggested. [YOCTO #2454] Signed-off-by: Robert Yang liezhi.y...@windriver.com --- scripts/contrib/python/generate-manifest-2.7.py |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/scripts/contrib/python/generate-manifest-2.7.py b/scripts/contrib/python/generate-manifest-2.7.py index 7b43137..5c52724 100755 --- a/scripts/contrib/python/generate-manifest-2.7.py +++ b/scripts/contrib/python/generate-manifest-2.7.py @@ -149,7 +149,10 @@ class MakefileMaker: if __name__ == __main__: if len( sys.argv ) 1: -os.popen( rm -f ./%s % sys.argv[1] ) +try: +os.unlink(sys.argv[1]) +except Exception: +sys.exc_clear() outfile = file( sys.argv[1], w ) else: outfile = sys.stdout -- 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 v3] dbus: update to version 1.4.20
Unstable version 1.5.12 also supported
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
.../dbus/{dbus-1.4.16 = dbus-1.4.20}/dbus-1.init |0
.../dbus/{dbus-1.4.16 = dbus-1.4.20}/tmpdir.patch |0
meta/recipes-core/dbus/dbus-1.5.12/dbus-1.init | 121
meta/recipes-core/dbus/dbus-1.5.12/tmpdir.patch| 44 +++
meta/recipes-core/dbus/dbus_1.4.16.bb |7 --
meta/recipes-core/dbus/dbus_1.4.20.bb |6 +
meta/recipes-core/dbus/dbus_1.5.12.bb |9 ++
7 files changed, 180 insertions(+), 7 deletions(-)
rename meta/recipes-core/dbus/{dbus-1.4.16 = dbus-1.4.20}/dbus-1.init (100%)
rename meta/recipes-core/dbus/{dbus-1.4.16 = dbus-1.4.20}/tmpdir.patch (100%)
create mode 100644 meta/recipes-core/dbus/dbus-1.5.12/dbus-1.init
create mode 100644 meta/recipes-core/dbus/dbus-1.5.12/tmpdir.patch
delete mode 100644 meta/recipes-core/dbus/dbus_1.4.16.bb
create mode 100644 meta/recipes-core/dbus/dbus_1.4.20.bb
create mode 100644 meta/recipes-core/dbus/dbus_1.5.12.bb
diff --git a/meta/recipes-core/dbus/dbus-1.4.16/dbus-1.init
b/meta/recipes-core/dbus/dbus-1.4.20/dbus-1.init
similarity index 100%
rename from meta/recipes-core/dbus/dbus-1.4.16/dbus-1.init
rename to meta/recipes-core/dbus/dbus-1.4.20/dbus-1.init
diff --git a/meta/recipes-core/dbus/dbus-1.4.16/tmpdir.patch
b/meta/recipes-core/dbus/dbus-1.4.20/tmpdir.patch
similarity index 100%
rename from meta/recipes-core/dbus/dbus-1.4.16/tmpdir.patch
rename to meta/recipes-core/dbus/dbus-1.4.20/tmpdir.patch
diff --git a/meta/recipes-core/dbus/dbus-1.5.12/dbus-1.init
b/meta/recipes-core/dbus/dbus-1.5.12/dbus-1.init
new file mode 100644
index 000..4abc4cb
--- /dev/null
+++ b/meta/recipes-core/dbus/dbus-1.5.12/dbus-1.init
@@ -0,0 +1,121 @@
+#! /bin/sh
+### BEGIN INIT INFO
+# Provides: dbus
+# Required-Start:$remote_fs $syslog
+# Required-Stop: $remote_fs $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop: 1
+# Short-Description: D-Bus systemwide message bus
+# Description: D-Bus is a simple interprocess messaging system, used
+#for sending messages between applications.
+### END INIT INFO
+#
+# -*- coding: utf-8 -*-
+# Debian init.d script for D-BUS
+# Copyright © 2003 Colin Walters walt...@debian.org
+
+set -e
+
+DAEMON=/usr/bin/dbus-daemon
+NAME=dbus
+DAEMONUSER=messagebus
+PIDDIR=/var/run/dbus
+PIDFILE=$PIDDIR/pid
+UUIDDIR=/var/lib/dbus
+DESC=system message bus
+EVENTDIR=/etc/dbus-1/event.d
+
+test -x $DAEMON || exit 0
+
+# Source defaults file; edit that file to configure this script.
+ENABLED=1
+PARAMS=
+if [ -e /etc/default/dbus ]; then
+ . /etc/default/dbus
+fi
+
+test $ENABLED != 0 || exit 0
+
+start_it_up()
+{
+ if [ ! -d $PIDDIR ]; then
+mkdir -p $PIDDIR
+chown $DAEMONUSER $PIDDIR
+chgrp $DAEMONUSER $PIDDIR
+ fi
+ if [ -e $PIDFILE ]; then
+PIDDIR=/proc/$(cat $PIDFILE)
+if [ -d ${PIDDIR} -a $(readlink -f ${PIDDIR}/exe) = ${DAEMON} ]; then
+ echo $DESC already started; not starting.
+else
+ echo Removing stale PID file $PIDFILE.
+ rm -f $PIDFILE
+fi
+ fi
+
+ if [ ! -d $UUIDDIR ]; then
+mkdir -p $UUIDDIR
+chown $DAEMONUSER $UUIDDIR
+chgrp $DAEMONUSER $UUIDDIR
+ fi
+
+ dbus-uuidgen --ensure
+
+ echo -n Starting $DESC:
+ start-stop-daemon --start --quiet --pidfile $PIDFILE \
+--user $DAEMONUSER --exec $DAEMON -- --system $PARAMS
+ echo $NAME.
+ if [ -d $EVENTDIR ]; then
+ run-parts --arg=start $EVENTDIR
+ fi
+}
+
+shut_it_down()
+{
+ if [ -d $EVENTDIR ]; then
+ # TODO: --reverse when busybox supports it
+ run-parts --arg=stop $EVENTDIR
+ fi
+ echo -n Stopping $DESC:
+ start-stop-daemon --stop --quiet --pidfile $PIDFILE \
+--user $DAEMONUSER
+ # We no longer include these arguments so that start-stop-daemon
+ # can do its job even given that we may have been upgraded.
+ # We rely on the pidfile being sanely managed
+ # --exec $DAEMON -- --system $PARAMS
+ echo $NAME.
+ rm -f $PIDFILE
+}
+
+reload_it()
+{
+ echo -n Reloading $DESC config:
+ dbus-send --print-reply --system --type=method_call \
+--dest=org.freedesktop.DBus \
+/ org.freedesktop.DBus.ReloadConfig /dev/null
+ # hopefully this is enough time for dbus to reload it's config file.
+ echo done.
+}
+
+case $1 in
+ start)
+start_it_up
+ ;;
+ stop)
+shut_it_down
+ ;;
+ reload|force-reload)
+reload_it
+ ;;
+ restart)
+shut_it_down
+sleep 1
+start_it_up
+ ;;
+ *)
+echo Usage: /etc/init.d/$NAME {start|stop|restart|reload|force-reload}
2
+exit 1
+ ;;
+esac
+
+exit 0
diff --git a/meta/recipes-core/dbus/dbus-1.5.12/tmpdir.patch
b/meta/recipes-core/dbus/dbus-1.5.12/tmpdir.patch
new file mode 100644
index 000..bf086e1
--- /dev/null
+++ b/meta/recipes-core/dbus/dbus-1.5.12/tmpdir.patch
@@ -0,0 +1,44 @@
+From 5105fedd7fa13dadd2d0d864fb77873b83b79a4b Mon Sep 17 00:00:00 2001
+From: Koen Kooi
Re: [OE-core] target rpm build failure
Hi Khem, 2012/5/30 Khem Raj raj.k...@gmail.com On Wed, May 30, 2012 at 8:18 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: It fails on undefined reference to xmalloc, xcalloc, etc... that however are internally defined and used as wrapper for real malloc, etc... Please, can somebody try to build this package for me? are you using uclibc for system C library ? Yes, I do! ___ 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 v3] dbus: update to version 1.4.20
Op 31 mei 2012, om 11:17 heeft Radu Moisan het volgende geschreven: Unstable version 1.5.12 also supported This should be split into at least 2 seperate commits. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cpan.bbclass: Fix config error while patches to Makefile.PL
From: Xin Ouyang xin.ouy...@windriver.com
If there is a patch to Makefile.PL, a Makefile.PL but no Makefile
will be placed in ${B}/.pc/xxx.patch/ after do_patch.
And no Makefile will be generated for *this* Makefile.PL.
While do_configure, the original code tries to sed Makefiles
matching with each Makefile.PL in {B}, so this would fail.
Signed-off-by: Xin Ouyang xin.ouy...@windriver.com
---
meta/classes/cpan.bbclass |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/cpan.bbclass b/meta/classes/cpan.bbclass
index 587e688..2e9432c 100644
--- a/meta/classes/cpan.bbclass
+++ b/meta/classes/cpan.bbclass
@@ -23,6 +23,7 @@ cpan_do_configure () {
# Use find since there can be a Makefile generated for each
Makefile.PL
for f in `find -name Makefile.PL`; do
f2=`echo $f | sed -e 's/.PL//'`
+ test -f $f2 || continue
sed -i -e s:\(PERL_ARCHLIB = \).*:\1${PERL_ARCHLIB}: \
-e 's/perl.real/perl/' \
$f2
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [V2 2/2] buildhistory.bbclass: add pkg_pre/postinst/rm contents
A use-case would have been [1].
The following tests were performed:
* image from scratch with old buildhistory contents
* image from scratch with buildhistory contents from scratch
* decrement a PR for a test recipe and check if the message
'ERROR: Package version for xy went backwards' is displayed.
[1] http://patches.openembedded.org/patch/28841/
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
meta/classes/buildhistory.bbclass | 80 +++--
1 files changed, 50 insertions(+), 30 deletions(-)
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index d2d19ff..9c49bab 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -57,6 +57,10 @@ python buildhistory_emit_pkghistory() {
self.rrecommends =
self.files =
self.filelist =
+ self.preinst =
+ self.postinst =
+ self.prerm =
+ self.postrm =
# Should check PACKAGES here to see if anything removed
@@ -74,18 +78,19 @@ python buildhistory_emit_pkghistory() {
try:
for line in f:
lns = line.split('=')
- name = lns[0].strip()
- value = lns[1].strip( \t\r\n).strip('')
- if name == PE:
- rcpinfo.pe = value
- elif name == PV:
- rcpinfo.pv = value
- elif name == PR:
- rcpinfo.pr = value
- elif name == DEPENDS:
- rcpinfo.depends = value
- elif name == PACKAGES:
- rcpinfo.packages = value
+ if len(lns)==2:
+ name = lns[0].strip()
+ value = lns[1].strip(
\t\r\n).strip('')
+ if name == PE:
+ rcpinfo.pe = value
+ elif name == PV:
+ rcpinfo.pv = value
+ elif name == PR:
+ rcpinfo.pr = value
+ elif name == DEPENDS:
+ rcpinfo.depends = value
+ elif name == PACKAGES:
+ rcpinfo.packages = value
finally:
f.close()
return rcpinfo
@@ -96,24 +101,25 @@ python buildhistory_emit_pkghistory() {
try:
for line in f:
lns = line.split('=')
- name = lns[0].strip()
- value = lns[1].strip( \t\r\n).strip('')
- if name == PE:
- pkginfo.pe = value
- elif name == PV:
- pkginfo.pv = value
- elif name == PR:
- pkginfo.pr = value
- elif name == RDEPENDS:
- pkginfo.rdepends = value
- elif name == RRECOMMENDS:
- pkginfo.rrecommends = value
- elif name == PKGSIZE:
- pkginfo.size = long(value)
- elif name == FILES:
- pkginfo.files = value
- elif name == FILELIST:
- pkginfo.filelist = value
+ if len(lns)==2:
+ name = lns[0].strip()
+ value = lns[1].strip(
\t\r\n).strip('')
+ if name == PE:
+ pkginfo.pe = value
+ elif name == PV:
+ pkginfo.pv = value
+ elif name == PR:
+ pkginfo.pr = value
+ elif name == RDEPENDS:
+ pkginfo.rdepends = value
+ elif name == RRECOMMENDS:
+ pkginfo.rrecommends = value
[OE-core] [V2 1/2] buildhistory_analysis.py: ignore lines without '='
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
meta/lib/oe/buildhistory_analysis.py |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oe/buildhistory_analysis.py
b/meta/lib/oe/buildhistory_analysis.py
index 29dc4a9..2b4582e 100644
--- a/meta/lib/oe/buildhistory_analysis.py
+++ b/meta/lib/oe/buildhistory_analysis.py
@@ -167,9 +167,10 @@ def blob_to_dict(blob):
alines = blob.data_stream.read().splitlines()
adict = {}
for line in alines:
-splitv = [i.strip() for i in line.split('=',1)]
-if splitv.count 1:
-adict[splitv[0]] = splitv[1]
+if line.find(=) != -1:
+splitv = [i.strip() for i in line.split('=',1)]
+if splitv.count 1:
+adict[splitv[0]] = splitv[1]
return adict
--
1.7.6.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] target rpm build failure
2012/5/31 Giuseppe Condorelli giuseppe.condore...@gmail.com Hi Khem, 2012/5/30 Khem Raj raj.k...@gmail.com On Wed, May 30, 2012 at 8:18 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: It fails on undefined reference to xmalloc, xcalloc, etc... that however are internally defined and used as wrapper for real malloc, etc... Please, can somebody try to build this package for me? are you using uclibc for system C library ? Yes, I do! Is there some difference for uclibc? Please let me know. Cheers, Giuseppe ___ 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] cmd1.bbclass: Ensure ncurses is built and used for menuconfig tasks
Currently, the task just exits if something goes wrong. This adds the
ncurses-native dependency. It also adds a small delay before closing the
window so any messages displayed there can be seen.
Trying to get the kernel build system to correctly find and link with
our copy of ncurses is some kind of nightmare. I ended up having to add
it to HOST_LOADLIBES globally for this task which is rather nasty but I
couldn't find any other way.
[YOCTO #2513]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index d429188..bd25311 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -9,9 +9,15 @@ addtask configure after do_unpack do_patch before do_compile
inherit terminal
+OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES
+HOST_EXTRACFLAGS = ${BUILD_CFLAGS} ${BUILD_LDFLAGS}
+HOSTLDFLAGS = ${BUILD_LDFLAGS}
+HOST_LOADLIBES = -lncurses
+
python do_menuconfig() {
-oe_terminal(make menuconfig, '${PN} Configuration', d)
+oe_terminal(${SHELL} -c \make menuconfig; echo 'Pausing for 5
seconds'; sleep 5\, '${PN} Configuration', d)
}
+do_menuconfig[depends] += ncurses-native:do_populate_sysroot
do_menuconfig[nostamp] = 1
addtask menuconfig after do_configure
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] target rpm build failure
On Thu, May 31, 2012 at 5:35 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: Is there some difference for uclibc? Please let me know. opkg works well with uclibc based systems. Those functions are not implemented in uclibc I am sure it can be fixed by linking in other libs or may be creating one. However if you are not bound to rpm then I would suggest to use opkg in your local.conf set it PACKAGE_CLASSES = package_ipk -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] target rpm build failure
Thanks for the reply, unfortunately I depend from rpm, I need just rpm packages. So can you confirm the target rpm for uclibc is not building? Thanks again, Giuseppe 2012/5/31 Khem Raj raj.k...@gmail.com On Thu, May 31, 2012 at 5:35 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: Is there some difference for uclibc? Please let me know. opkg works well with uclibc based systems. Those functions are not implemented in uclibc I am sure it can be fixed by linking in other libs or may be creating one. However if you are not bound to rpm then I would suggest to use opkg in your local.conf set it PACKAGE_CLASSES = package_ipk -Khem ___ 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] target rpm build failure
On Thu, May 31, 2012 at 6:57 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: unfortunately I depend from rpm, I need just rpm packages. So can you confirm the target rpm for uclibc is not building? yes rpm needs to be patched for building on uclibc ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] opkg 0.1.8: respect to the arch when choose the alternatives
There is a bug if we:
1) bitbake core-image-sato-sdk MACHINE=qemux86
2) bitbake core-image-sato with MACHINE=crownbay
Then several pkgs in deploy/ipk/i586 would be installed to crownbay's
image even if there is one in deploy/ipk/core2 and we have set the
core2's priority higher than i586, when the version in deploy/ipk/i586 is
higher. This doesn't work for us, for example, what the crownbay need is
xserver-xorg-1.9.3, but it installs xserver-xorg-1.11.2.
This is caused by opkg's selecting mechanism, if there are more than one
candidates which have the same pkg name in the candidate list, for
example, the same pkg with different versions, then it will use the last
one which is the highest version in the list, this doesn't work for us,
it should respect to the arch priorities in such a case.
This is for both denzil and master branch.
[YOCTO #2360]
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../opkg/opkg/respect-to-arch.patch| 47
meta/recipes-devtools/opkg/opkg_0.1.8.bb |3 +-
meta/recipes-devtools/opkg/opkg_svn.bb |3 +-
3 files changed, 51 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-devtools/opkg/opkg/respect-to-arch.patch
diff --git a/meta/recipes-devtools/opkg/opkg/respect-to-arch.patch
b/meta/recipes-devtools/opkg/opkg/respect-to-arch.patch
new file mode 100644
index 000..6f4537f
--- /dev/null
+++ b/meta/recipes-devtools/opkg/opkg/respect-to-arch.patch
@@ -0,0 +1,47 @@
+pkg_hash.c: respect to the arch priorities when good_pkg_by_name
+
+If there are more than one candidates which have the same pkg name in
+the candidate list, for example, the same pkg with different versions,
+then it will use the last one which is the highest version in the list,
+it should respect to the arch priorities in such a case.
+
+Upstream Status: Pending
+
+Signed-off-by: Robert Yang liezhi.y...@windriver.com
+---
+ libopkg/pkg_hash.c | 18 +++---
+ 1 files changed, 15 insertions(+), 3 deletions(-)
+
+diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
+index a99cf6b..cc048c8 100644
+--- a/libopkg/pkg_hash.c
b/libopkg/pkg_hash.c
+@@ -376,10 +376,22 @@
pkg_hash_fetch_best_installation_candidate(abstract_pkg_t *apkg,
+ if (constraint_fcn(matching, cdata)) {
+ opkg_msg(DEBUG, Candidate: %s %s.\n,
+matching-name, matching-version) ;
+- good_pkg_by_name = matching;
++ /* Respect to the arch priorities when given alternatives */
++ if (good_pkg_by_name) {
++ if (matching-arch_priority =
good_pkg_by_name-arch_priority) {
++ good_pkg_by_name = matching;
++ opkg_msg(DEBUG, %s %s wins by priority.\n,
++ matching-name, matching-version) ;
++ } else
++ opkg_msg(DEBUG, %s %s wins by priority.\n,
++ good_pkg_by_name-name, good_pkg_by_name-version) ;
++ } else
++ good_pkg_by_name = matching;
+/* It has been provided by hand, so it is what user want */
+- if (matching-provided_by_hand == 1)
+-break;
++ if (matching-provided_by_hand == 1) {
++ good_pkg_by_name = matching;
++ break;
++ }
+ }
+ }
+
+--
+1.7.1
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.1.8.bb
b/meta/recipes-devtools/opkg/opkg_0.1.8.bb
index c206b37..09ff3b5 100644
--- a/meta/recipes-devtools/opkg/opkg_0.1.8.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.1.8.bb
@@ -3,6 +3,7 @@ require opkg.inc
SRC_URI = http://opkg.googlecode.com/files/opkg-${PV}.tar.gz \
file://add_vercmp.patch \
file://headerfix.patch \
+ file://respect-to-arch.patch \
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
diff --git a/meta/recipes-devtools/opkg/opkg_svn.bb
b/meta/recipes-devtools/opkg/opkg_svn.bb
index c07d393..890ed52 100644
--- a/meta/recipes-devtools/opkg/opkg_svn.bb
+++ b/meta/recipes-devtools/opkg/opkg_svn.bb
@@ -6,6 +6,7 @@ SRC_URI =
svn://opkg.googlecode.com/svn;module=trunk;proto=http \
file://fix_installorder.patch \
file://offline_postinstall.patch\
file://track_parents.patch \
+ file://respect-to-arch.patch \
S = ${WORKDIR}/trunk
@@ -13,4 +14,4 @@ S = ${WORKDIR}/trunk
SRCREV = 633
PV = 0.1.8+svnr${SRCPV}
-PR = ${INC_PR}.0
+PR = ${INC_PR}.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 0/1] V2 opkg 0.1.8: respect to the arch when choose the alternatives
* Changes of V2: - Add the test plan and more explanations in the cover letter as Saul suggested. * Test info (PACKAGE_CLASSES = package_ipk) - Test to make sure the bug has been fixed 1) bitbake core-image-sato-sdk with MACHINE=qemux86 2) bitbake core-image-sato with MACHINE=crownbay === Test result: Without this patch, the xserver-xorg-*_1.11.2-r3_i586.ipk would be install to the crownbay's image, this is incorrect since what crownbay needs are xserver-xorg*_1.9.3-r1.core2.ipk, the core2 pkgs would be installed correctly on crownbay's image. And check tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs, no i586 pkgs should be installed. - Test the upgrade (with nothing changed in the feeds) # opkg update 1) ./tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/opkg.conf \ -o /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/rootfs update # opkg upgrade 2) ./tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/opkg.conf \ -o /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/rootfs upgrade === Test result: Nothing to do though there are xserver-xorg-*_1.11.2-r3_i586.ipk which have a higher version than the installed xserver-xorg*_1.9.3-r1.core2.ipk, becuase the priority of i586 is lower than core2 in core2's image. - Test the installation # opkg remove 1) ./tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/opkg.conf \ -o /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/rootfs \ remove --force-depends xserver-xorg # opkg install 2) ./tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/opkg.conf \ -o /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/rootfs \ install xserver-xorg === Test result: The xserver-xorg_1.9.3-r1_core2.ipk will be installed, the reason is the same as the previous one * More explanations This patch only affects it's good_pkg_by_name behaviour, Here are its selecting priorities: (From high to low) 1, The pkg set manually 2, The good_pkg_by_name 3, The held pkg 4, Choose the higher arch one 5, Use the latest one If of them is matched, then the left ones would be ignored, for example, if the first one matches, others would be ignored. This patch affects the second one(good_by_pkg_name), what it did in the past: If there are both core2/pkg-1.0.apk and i586/pkg-1.1.apk match, it would use i586/pkg-1.1.apk since its version is higher and ignore the arch priorities, but we have set the arch priorities in opkg.conf clearly: arch i586 31 arch core2 41 What we need is core2/pkg-1.0.apk since we may set the specific pkg version for the board (for example, the xorg-server for crownbay), let it respect to the arch priorities in such a case. * Both rpm(fixed) and ipk have the similar issue, dpkg is OK. * TODO - In the following upgrade scene (with pkg changed in the feeds) # opkg remove 1) ./tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/opkg.conf \ -o /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/rootfs \ remove --force-depends xserver-xorg # Remove xserver-xorg_1.9.3-r1_core2.ipk to make # xserver-xorg_1.11.2-r3_i586.ipk install to the image. 2) mv tmp/deploy/ipk/core2/xserver-xorg_1.9.3-r1_core2.ipk tmp/bak/ # Run opkg-make-index to re-create the feeds 3) ./tmp/sysroots/i686-linux/usr/bin/opkg-make-index \ -r tmp/deploy/ipk/core2/Packages \ -p tmp/deploy/ipk/core2/Packages \ -m tmp/deploy/ipk/core2 # Install xserver-xorg_1.11.2-r3_i586.ipk 4) ./tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/opkg.conf \ -o /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/rootfs \ install xserver-xorg # Add xserver-xorg_1.9.3-r1_core2.ipk back to the feeds 5) mv tmp/bak/xserver-xorg_1.9.3-r1_core2.ipk tmp/deploy/ipk/core2/ # Run opkg-make-index to re-create the feeds 6) ./tmp/sysroots/i686-linux/usr/bin/opkg-make-index \ -r tmp/deploy/ipk/core2/Packages \ -p tmp/deploy/ipk/core2/Packages \ -m tmp/deploy/ipk/core2 # opkg update 7) ./tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/opkg.conf \ -o /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/rootfs update # opkg upgrade 8) ./tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ /path/to/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/opkg.conf \ -o
Re: [OE-core] target rpm build failure
On 2012-05-31 07:57, Giuseppe Condorelli wrote: Thanks for the reply, unfortunately I depend from rpm, I need just rpm packages. Why do you need RPM? So can you confirm the target rpm for uclibc is not building? Thanks again, Giuseppe 2012/5/31 Khem Raj raj.k...@gmail.com mailto:raj.k...@gmail.com On Thu, May 31, 2012 at 5:35 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com mailto:giuseppe.condore...@gmail.com wrote: Is there some difference for uclibc? Please let me know. opkg works well with uclibc based systems. Those functions are not implemented in uclibc I am sure it can be fixed by linking in other libs or may be creating one. However if you are not bound to rpm then I would suggest to use opkg in your local.conf set it PACKAGE_CLASSES = package_ipk -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] target rpm build failure
because the current distribution I manage (not oe based) is rpm based so in my intention I want to furnish (for a while) both installtion methods: via oe build system and via rpm (chrooted or similar). And to do the second I need to have the possibility to access to the dbpath oe build system manages during image cretion/installation. Adding package-management to IMAGE_FEATURES I'll have this available. But it includes also target rpm build (honestly I don't need it) that is failing. Have new suggestions? Many thanks, Giuseppe 2012/5/31 Gary Thomas g...@mlbassoc.com On 2012-05-31 07:57, Giuseppe Condorelli wrote: Thanks for the reply, unfortunately I depend from rpm, I need just rpm packages. Why do you need RPM? So can you confirm the target rpm for uclibc is not building? Thanks again, Giuseppe 2012/5/31 Khem Raj raj.k...@gmail.com mailto:raj.k...@gmail.com On Thu, May 31, 2012 at 5:35 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com mailto:giuseppe.condorelli@**gmail.comgiuseppe.condore...@gmail.com wrote: Is there some difference for uclibc? Please let me know. opkg works well with uclibc based systems. Those functions are not implemented in uclibc I am sure it can be fixed by linking in other libs or may be creating one. However if you are not bound to rpm then I would suggest to use opkg in your local.conf set it PACKAGE_CLASSES = package_ipk -- --**-- Gary Thomas | Consulting for the MLB Associates |Embedded world --**-- __**_ Openembedded-core mailing list Openembedded-core@lists.**openembedded.orgOpenembedded-core@lists.openembedded.org http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-corehttp://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] cmd1.bbclass: Ensure ncurses is built and used for menuconfig tasks
On 05/31/2012 06:29 AM, Richard Purdie wrote:
Currently, the task just exits if something goes wrong. This adds the
ncurses-native dependency. It also adds a small delay before closing the
window so any messages displayed there can be seen.
Trying to get the kernel build system to correctly find and link with
our copy of ncurses is some kind of nightmare. I ended up having to add
it to HOST_LOADLIBES globally for this task which is rather nasty but I
couldn't find any other way.
[YOCTO #2513]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index d429188..bd25311 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -9,9 +9,15 @@ addtask configure after do_unpack do_patch before do_compile
inherit terminal
+OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES
+HOST_EXTRACFLAGS = ${BUILD_CFLAGS} ${BUILD_LDFLAGS}
+HOSTLDFLAGS = ${BUILD_LDFLAGS}
+HOST_LOADLIBES = -lncurses
+
python do_menuconfig() {
-oe_terminal(make menuconfig, '${PN} Configuration', d)
+oe_terminal(${SHELL} -c \make menuconfig; echo 'Pausing for 5
seconds'; sleep 5\, '${PN} Configuration', d)
Perhaps only sleeping if menuconfig returns non-zero? This would avoid
the unnecessary lag after a successful menuconfig session.
--
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] [PATCH 1/1] opkg 0.1.8: respect to the arch when choose the alternatives
Op 31 mei 2012, om 16:13 heeft Robert Yang het volgende geschreven: There is a bug if we: 1) bitbake core-image-sato-sdk MACHINE=qemux86 2) bitbake core-image-sato with MACHINE=crownbay Then several pkgs in deploy/ipk/i586 would be installed to crownbay's image even if there is one in deploy/ipk/core2 and we have set the core2's priority higher than i586, when the version in deploy/ipk/i586 is higher. This doesn't work for us, for example, what the crownbay need is xserver-xorg-1.9.3, but it installs xserver-xorg-1.11.2. And this is working exactly as intended. Don't break opkg because your hardware driver situation sucks. So: NAK on this patch. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmd1.bbclass: Ensure ncurses is built and used for menuconfig tasks
On 12-05-31 09:29 AM, Richard Purdie wrote:
Currently, the task just exits if something goes wrong. This adds the
ncurses-native dependency. It also adds a small delay before closing the
window so any messages displayed there can be seen.
Trying to get the kernel build system to correctly find and link with
our copy of ncurses is some kind of nightmare. I ended up having to add
it to HOST_LOADLIBES globally for this task which is rather nasty but I
couldn't find any other way.
Agreed, and my much more limited knowledge of the options can't come
up with something different either.
Is there an option to move those flags to the kernel class, so they'd
only be set when it is in play ? That would at least isolate the data
a bit more. Alternatively there's the less palatable kernel specific
do_menuconfig option (ech).
Otherwise, no concerns or big comments from me.
Bruce
[YOCTO #2513]
Signed-off-by: Richard Purdierichard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index d429188..bd25311 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -9,9 +9,15 @@ addtask configure after do_unpack do_patch before do_compile
inherit terminal
+OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES
+HOST_EXTRACFLAGS = ${BUILD_CFLAGS} ${BUILD_LDFLAGS}
+HOSTLDFLAGS = ${BUILD_LDFLAGS}
+HOST_LOADLIBES = -lncurses
+
python do_menuconfig() {
-oe_terminal(make menuconfig, '${PN} Configuration', d)
+oe_terminal(${SHELL} -c \make menuconfig; echo 'Pausing for 5 seconds'; sleep
5\, '${PN} Configuration', d)
}
+do_menuconfig[depends] += ncurses-native:do_populate_sysroot
do_menuconfig[nostamp] = 1
addtask menuconfig after do_configure
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] target rpm build failure
On 5/31/12 9:47 AM, Giuseppe Condorelli wrote: because the current distribution I manage (not oe based) is rpm based so in my intention I want to furnish (for a while) both installtion methods: via oe build system and via rpm (chrooted or similar). And to do the second I need to have the possibility to access to the dbpath oe build system manages during image cretion/installation. Adding package-management to IMAGE_FEATURES I'll have this available. But it includes also target rpm build (honestly I don't need it) that is failing. Have new suggestions? uclibc and glibc are incompatible with each other from a binary perspective. I've not seen anyone distribution an RPM based uclibc distribution before. It's always been glibc based -- or some other package method on uclibc due to size and dependency requirements. If you really need rpm (on the target) with uclibc, you'll have to go through RPM and all of it's dependencies and patch them for uclibc. I'm happy to review the patches, and I don't see why they wouldn't be accepted into OE-core... but it wasn't the expectation when RPM functionality was added and tested. (ipkg was expected to be used with uclibc, or no package manager on the target.) --Mark Many thanks, Giuseppe 2012/5/31 Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com On 2012-05-31 07:57, Giuseppe Condorelli wrote: Thanks for the reply, unfortunately I depend from rpm, I need just rpm packages. Why do you need RPM? So can you confirm the target rpm for uclibc is not building? Thanks again, Giuseppe 2012/5/31 Khem Raj raj.k...@gmail.com mailto:raj.k...@gmail.com mailto:raj.k...@gmail.com mailto:raj.k...@gmail.com On Thu, May 31, 2012 at 5:35 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com mailto:giuseppe.condore...@gmail.com mailto:giuseppe.condorelli@__gmail.com mailto:giuseppe.condore...@gmail.com wrote: Is there some difference for uclibc? Please let me know. opkg works well with uclibc based systems. Those functions are not implemented in uclibc I am sure it can be fixed by linking in other libs or may be creating one. However if you are not bound to rpm then I would suggest to use opkg in your local.conf set it PACKAGE_CLASSES = package_ipk -- --__-- Gary Thomas | Consulting for the MLB Associates | Embedded world --__-- _ Openembedded-core mailing list Openembedded-core@lists.__openembedded.org mailto:Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/__cgi-bin/mailman/listinfo/__openembedded-core 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
[OE-core] [meta-xilinx] WARNING: QA Issue: bash shell scripts
Hi, I've found the following warnings while attempting to build linux-xilinx. How can I trace which package it's originating from and what can I do to fix it? WARNING: QA Issue: bash: Found a reference to /usr/ in /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/bash-4.2-r2/packages-split/bash/bin/bashbug WARNING: QA Issue: Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix Best regards, Elvis Dowson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-xilinx] WARNING: QA Issue: bash shell scripts
Hi, On May 31, 2012, at 7:38 PM, Elvis Dowson wrote: I've found the following warnings while attempting to build linux-xilinx. How can I trace which package it's originating from and what can I do to fix it? WARNING: QA Issue: bash: Found a reference to /usr/ in /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/bash-4.2-r2/packages-split/bash/bin/bashbug WARNING: QA Issue: Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix Sorry about that silly question, its originating from the bash-4.2 package. What should I do to fix it? Elvis Dowson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [meta-xilinx] libpcre_8.21.bb: IOError: invalid Python installation
Hi, I noticed a situation where, when I try to bitbake linux-xilinx, it fails a libpcre, because of an invalid python instalation. However, after doing a bitbake -c clean linux-xilinx libpcre, and then rebuilding libpcre, python-native gets staged correctly and the build succeeds. Shouldn't python-native get built correctly the first time around? My parallelism options as follows: BB_NUMBER_THREADS = 6 PARALLEL_MAKE = -j 6 Best regards, Elvis Dowson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [meta-xilinx] WARNING: linux-xilinx: No generic license file exists for: GPL in any provider
Hi, While attempting to build linux-xilinx, I get the following warning: WARNING: linux-xilinx: No generic license file exists for: GPL in any provider What should I do to fix this warning? Best regards, Elvis Dowson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [meta-xilinx] Generating device tree for building linux-xilinx kernel
Hi Adrian, When I attempt to build the linux-xilinx kernel, it doesn't find the device tree (*.dts) in the xilinx-ml507-update BSP project. Is the device tree supposed to be generated manually? If so, could you please tell me how to generate it? Best regards, Elvis Dowson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-xilinx] Generating device tree for building linux-xilinx kernel
That's a second process that you need todo with xilinx EDK to export and launch xilinx SDK from there create a new device tree project which will parse the mhs hardware descriptor file and from there generate the device tree according to the hwd settings... The only docs available to get to know how the SW/HW works are part of my thesis which can be found here: http://aalonso.wordpress.com/2011/11/08/thesis-documents/ Regards Adrian Alonso On Thu, May 31, 2012 at 3:28 PM, Elvis Dowson elvis.dow...@gmail.com wrote: Hi Adrian, When I attempt to build the linux-xilinx kernel, it doesn't find the device tree (*.dts) in the xilinx-ml507-update BSP project. Is the device tree supposed to be generated manually? If so, could you please tell me how to generate it? Best regards, Elvis Dowson -- Saludos Adrian Alonso http://aalonso.wordpress.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-xilinx] WARNING: QA Issue: bash shell scripts
On 5/31/12 12:40 PM, Elvis Dowson wrote: Hi, On May 31, 2012, at 7:38 PM, Elvis Dowson wrote: I've found the following warnings while attempting to build linux-xilinx. How can I trace which package it's originating from and what can I do to fix it? WARNING: QA Issue: bash: Found a reference to /usr/ in /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/bash-4.2-r2/packages-split/bash/bin/bashbug WARNING: QA Issue: Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix Sorry about that silly question, its originating from the bash-4.2 package. What should I do to fix it? It's just a warning you don't need to fix it. We're working on a fix for that right now.. the bashbug file is a shell script that adds /usr/bin to the path. This causes the QA warning to hit and complain that there may be references to /usr/bin items in the script. The warning is because things in /bin are assumed to be required for booting, and you may boot w/o /usr being mounted.. causing a potential problem. I can't see why bashbug would ever be used for booting, so this shouldn't be a problem. Right now, I expect we're going to fix the problem with a two step patch.. The first being to move bashbug from base_bindir to bindir, and the second to split it into a new package so that it's not always installed.. (it's only 7k or so.. but why even install it on an embedded system unless it's really needed.) --Mark Elvis Dowson ___ 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] [meta-xilinx] Generating device tree for building linux-xilinx kernel
Hi Adrian, On May 31, 2012, at 10:49 PM, Adrian Alonso wrote: That's a second process that you need todo with xilinx EDK to export and launch xilinx SDK from there create a new device tree project which will parse the mhs hardware descriptor file and from there generate the device tree according to the hwd settings... Perhaps these steps could be automated by modifying the meta-xilinx/classes/xilinx-kernel.bbclass file, so that the EDK gets invoked from the command line to parse the mhs file and create the dts file? Best regards, Elvis Dowson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-xilinx] Generating device tree for building linux-xilinx kernel
Yep that could be done, just need to dig on EDK to do it :) On Thu, May 31, 2012 at 3:56 PM, Elvis Dowson elvis.dow...@gmail.com wrote: Hi Adrian, On May 31, 2012, at 10:49 PM, Adrian Alonso wrote: That's a second process that you need todo with xilinx EDK to export and launch xilinx SDK from there create a new device tree project which will parse the mhs hardware descriptor file and from there generate the device tree according to the hwd settings... Perhaps these steps could be automated by modifying the meta-xilinx/classes/xilinx-kernel.bbclass file, so that the EDK gets invoked from the command line to parse the mhs file and create the dts file? Best regards, Elvis Dowson -- Saludos Adrian Alonso http://aalonso.wordpress.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Suggestion: Occasionally take --hash-style=gnu out of the linker
It occurred to me: In theory, it's a bug if a package is configured such that it does not actually request hash-style=gnu. In practice, though, the yocto toolchain is configured so that it's the default. Maybe there should be a periodic build or two that uses a compiler not configured that way, to flush out such packages? -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Suggestion: Occasionally take --hash-style=gnu out of the linker
On Thu, May 31, 2012 at 2:14 PM, Peter Seebach peter.seeb...@windriver.com wrote: In theory, it's a bug if a package is configured such that it does not actually request hash-style=gnu. In practice, though, the yocto toolchain is configured so that it's the default. Maybe there should be a periodic build or two that uses a compiler not configured that way, to flush out such packages? yes we tried that with classic OE for long time. it did not go much further than we changing the recipes to add it to compiler cmdline and subtle bugs. Right thing would be to fix the packages but its a significant task. Besides OE most of other distros use it as default so I dont think there will be many fixes upstreamed for respective packages. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5 v3] Uprev RPM to 5.4.9
Rebase of the v2 changes.
Re-disabled the test chunk.. this should resolve the hang problem a
few people have observed.
v2 message follows:
Berkley DB also gets upreved, and a new package ossp-uuid gets added to
the system.
This was -heavily- tested with and without zypper on IA, and PPC.
In addition a minor performance enhancement with a query operation was added.
The uprev also adds the capability of using PACKAGECONFIG settings to tailor
the behavior of RPM.
V2 changes:
Fix a problem with libuuid.so from util-linux would sometimes be linked into
the binary.
Also force libzypp, sat-solver and zypper to refresh via a PR bump.
The following changes since commit e3113827810e98eb1b012f0b280fb917199704c1:
webkit-gtk: Use glib as unicode backend to avoid browser crash (2012-05-30
17:37:58 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/rpm
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/rpm
Mark Hatle (5):
rpm: Upgrade RPM to 5.4.8 (db to 5.3.15)
rpm: Upgrade RPM to 5.4.9
ossp-uuid: Add oss-uuid package and RPM 5.4.9 integration
package_rpm: Add capability to directly query packageorigin
rpm: Bump PR numbers on componets that require RPM
meta/classes/package_rpm.bbclass | 18 +-
meta/classes/rootfs_rpm.bbclass| 22 +-
.../ossp-uuid/0001-Change-library-name.patch | 112 +
...erve-m-option-status-in-v-option-handling.patch | 55 +++
.../ossp-uuid/0003-Fix-whatis-entries.patch| 51 +++
.../ossp-uuid/0004-fix-data-uuid-from-string.patch | 36 ++
.../ossp-uuid/ossp-uuid/uuid-libtool.patch | 24 +
.../ossp-uuid/ossp-uuid/uuid-nostrip.patch | 16 +
meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb | 58 +++
.../rpm/rpm/fix_for_automake_1.11.2.patch | 54 ---
.../rpm/rpm/fprint-pointer-fix.patch | 35 --
.../rpm/rpm/remove-compiled-tests.patch| 443
meta/recipes-devtools/rpm/rpm/rpm-autoconf.patch | 22 -
meta/recipes-devtools/rpm/rpm/rpm-autogen.patch| 41 +--
meta/recipes-devtools/rpm/rpm/rpm-db-reduce.patch | 16 +-
.../recipes-devtools/rpm/rpm/rpm-log-auto-rm.patch | 12 +-
meta/recipes-devtools/rpm/rpm/rpm-lua.patch| 29 ++
.../rpm/rpm/rpm-no-perl-urpm.patch | 43 ++
meta/recipes-devtools/rpm/rpm/rpm-nofsync.patch| 36 --
meta/recipes-devtools/rpm/rpm/rpm-ossp-uuid.patch | 20 +
.../rpm/rpm/rpm-packageorigin.patch| 23 +
.../rpm/rpm/rpm-scriptletexechelper.patch | 33 +-
meta/recipes-devtools/rpm/rpm/rpmdeps-oecore.patch | 26 +-
.../rpm/{rpm_5.4.0.bb = rpm_5.4.9.bb} | 158
.../libzypp/libzypp/libzypp-rpm549.patch | 28 ++
meta/recipes-extended/libzypp/libzypp_git.bb |3 +-
meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +-
meta/recipes-extended/zypper/zypper_git.bb |2 +-
.../db/{db_5.1.19.bb = db_5.3.15.bb} |8 +-
29 files changed, 652 insertions(+), 774 deletions(-)
create mode 100644
meta/recipes-devtools/ossp-uuid/ossp-uuid/0001-Change-library-name.patch
create mode 100644
meta/recipes-devtools/ossp-uuid/ossp-uuid/0002-uuid-preserve-m-option-status-in-v-option-handling.patch
create mode 100644
meta/recipes-devtools/ossp-uuid/ossp-uuid/0003-Fix-whatis-entries.patch
create mode 100644
meta/recipes-devtools/ossp-uuid/ossp-uuid/0004-fix-data-uuid-from-string.patch
create mode 100644 meta/recipes-devtools/ossp-uuid/ossp-uuid/uuid-libtool.patch
create mode 100644 meta/recipes-devtools/ossp-uuid/ossp-uuid/uuid-nostrip.patch
create mode 100644 meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb
delete mode 100644 meta/recipes-devtools/rpm/rpm/fix_for_automake_1.11.2.patch
delete mode 100644 meta/recipes-devtools/rpm/rpm/fprint-pointer-fix.patch
delete mode 100644 meta/recipes-devtools/rpm/rpm/remove-compiled-tests.patch
delete mode 100644 meta/recipes-devtools/rpm/rpm/rpm-autoconf.patch
create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-lua.patch
create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-no-perl-urpm.patch
delete mode 100644 meta/recipes-devtools/rpm/rpm/rpm-nofsync.patch
create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-ossp-uuid.patch
create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-packageorigin.patch
rename meta/recipes-devtools/rpm/{rpm_5.4.0.bb = rpm_5.4.9.bb} (76%)
create mode 100644 meta/recipes-extended/libzypp/libzypp/libzypp-rpm549.patch
rename meta/recipes-support/db/{db_5.1.19.bb = db_5.3.15.bb} (93%)
--
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/5 v3] rpm: Upgrade RPM to 5.4.8 (db to 5.3.15)
RPM 5.4.8 requires db 5.3.x, so both are upgraded together.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/classes/rootfs_rpm.bbclass| 22 +-
.../rpm/rpm/fix_for_automake_1.11.2.patch | 54 ---
.../rpm/rpm/fprint-pointer-fix.patch | 35 --
.../rpm/rpm/remove-compiled-tests.patch| 443
meta/recipes-devtools/rpm/rpm/rpm-autoconf.patch | 22 -
meta/recipes-devtools/rpm/rpm/rpm-autogen.patch| 41 +--
meta/recipes-devtools/rpm/rpm/rpm-db-reduce.patch | 16 +-
.../recipes-devtools/rpm/rpm/rpm-log-auto-rm.patch | 12 +-
.../rpm/rpm/rpm-no-perl-urpm.patch | 43 ++
meta/recipes-devtools/rpm/rpm/rpm-nofsync.patch| 36 --
.../rpm/{rpm_5.4.0.bb = rpm_5.4.8.bb} | 44 ++-
.../db/{db_5.1.19.bb = db_5.3.15.bb} |8 +-
12 files changed, 106 insertions(+), 670 deletions(-)
delete mode 100644 meta/recipes-devtools/rpm/rpm/fix_for_automake_1.11.2.patch
delete mode 100644 meta/recipes-devtools/rpm/rpm/fprint-pointer-fix.patch
delete mode 100644 meta/recipes-devtools/rpm/rpm/remove-compiled-tests.patch
delete mode 100644 meta/recipes-devtools/rpm/rpm/rpm-autoconf.patch
create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-no-perl-urpm.patch
delete mode 100644 meta/recipes-devtools/rpm/rpm/rpm-nofsync.patch
rename meta/recipes-devtools/rpm/{rpm_5.4.0.bb = rpm_5.4.8.bb} (91%)
rename meta/recipes-support/db/{db_5.1.19.bb = db_5.3.15.bb} (93%)
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 9039b21..703fa15 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -66,24 +66,26 @@ fakeroot rootfs_rpm_do_rootfs () {
touch ${INSTALL_ROOTFS_RPM}${rpmlibdir}/log/log.01
cat ${INSTALL_ROOTFS_RPM}${rpmlibdir}/DB_CONFIG EOF
# Environment
-set_data_dir.
-set_create_dir .
-set_lg_dir ./log
-set_tmp_dir ./tmp
+set_data_dir .
+set_create_dir .
+set_lg_dir ./log
+set_tmp_dir ./tmp
+set_flags db_log_autoremove on
# -- thread_count must be = 8
-set_thread_count64
+set_thread_count 64
# Logging
# Memory Pool
-set_mp_mmapsize 268435456
+set_cachesize 0 1048576 0
+set_mp_mmapsize 268435456
# Locking
-set_lk_max_locks16384
-set_lk_max_lockers 16384
-set_lk_max_objects 16384
-mutex_set_max 163840
+set_lk_max_locks 16384
+set_lk_max_lockers 16384
+set_lk_max_objects 16384
+mutex_set_max 163840
# Replication
EOF
diff --git a/meta/recipes-devtools/rpm/rpm/fix_for_automake_1.11.2.patch
b/meta/recipes-devtools/rpm/rpm/fix_for_automake_1.11.2.patch
deleted file mode 100644
index bb0f7eb..000
--- a/meta/recipes-devtools/rpm/rpm/fix_for_automake_1.11.2.patch
+++ /dev/null
@@ -1,54 +0,0 @@
-Upstream-Status: Pending
-
-automake version 1.11.2 has made use of dir variables more strict.
-the use of pkglibdir with SCRIPTS DATA vars results in automake
-errors.
- This commits uses pkgdatadir pkgbindir vars instead of pkglibdir
-to avoid the strict check errors.
-
- This change also works with automake-1.11.1
-
-Errors fixed:
-Makefile.am:103: error: `pkglibdir' is not a legitimate directory for `DATA'
-scripts/Makefile.am:47: error: `pkglibdir' is not a legitimate directory for
`SCRIPTS'
-
-Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com
-2011/12/27
-
-Index: rpm-5.4.0/Makefile.am
-===
rpm-5.4.0.orig/Makefile.am
-+++ rpm-5.4.0/Makefile.am
-@@ -103,13 +103,13 @@ if WITH_PATH_VERSIONED
- done
- endif
-
--pkglibdir = @USRLIBRPM@
--pkglib_DATA = rpmpopt macros/macros macros/macros.rpmbuild cpuinfo.yaml
-+pkgdatadir = @USRLIBRPM@
-+pkgdata_DATA = rpmpopt macros/macros macros/macros.rpmbuild cpuinfo.yaml
-
--pkgbindir = $(pkglibdir)/bin
-+pkgbindir = $(pkgdatadir)/bin
- pkgbin_SCRIPTS = install-sh mkinstalldirs
-
--pkgcfgdir = $(pkglibdir)/macros.d
-+pkgcfgdir = $(pkgdatadir)/macros.d
- pkgcfg_DATA = \
- macros/cmake macros/java macros/libtool macros/mandriva macros/mono \
- macros/perl macros/pkgconfig macros/php macros/python macros/ruby \
-Index: rpm-5.4.0/scripts/Makefile.am
-===
rpm-5.4.0.orig/scripts/Makefile.am
-+++ rpm-5.4.0/scripts/Makefile.am
-@@ -45,8 +45,8 @@ all:
-
- bin_SCRIPTS = gendiff
-
--pkglibdir = @USRLIBRPM@
--pkglib_SCRIPTS = \
-+pkgbindir = @USRLIBRPM@
-+pkgbin_SCRIPTS = \
- brp-compress brp-python-bytecompile brp-java-gcjcompile \
- brp-strip brp-strip-comment-note brp-nobuildrootpath \
- brp-strip-shared brp-strip-static-archive brp-sparc64-linux \
diff --git a/meta/recipes-devtools/rpm/rpm/fprint-pointer-fix.patch
[OE-core] [PATCH 3/5 v3] ossp-uuid: Add oss-uuid package and RPM 5.4.9 integration
RPM 5.4.9 now strongly encourages you to have the ossp-uuid library available.
Add this recipe, and change RPM to use the uuid functionality.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
.../ossp-uuid/0001-Change-library-name.patch | 112
...erve-m-option-status-in-v-option-handling.patch | 55 ++
.../ossp-uuid/0003-Fix-whatis-entries.patch| 51 +
.../ossp-uuid/0004-fix-data-uuid-from-string.patch | 36 ++
.../ossp-uuid/ossp-uuid/uuid-libtool.patch | 24
.../ossp-uuid/ossp-uuid/uuid-nostrip.patch | 16 +++
meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb | 58 ++
meta/recipes-devtools/rpm/rpm/rpm-ossp-uuid.patch | 20
meta/recipes-devtools/rpm/rpm_5.4.9.bb | 11 ++-
9 files changed, 380 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-devtools/ossp-uuid/ossp-uuid/0001-Change-library-name.patch
create mode 100644
meta/recipes-devtools/ossp-uuid/ossp-uuid/0002-uuid-preserve-m-option-status-in-v-option-handling.patch
create mode 100644
meta/recipes-devtools/ossp-uuid/ossp-uuid/0003-Fix-whatis-entries.patch
create mode 100644
meta/recipes-devtools/ossp-uuid/ossp-uuid/0004-fix-data-uuid-from-string.patch
create mode 100644 meta/recipes-devtools/ossp-uuid/ossp-uuid/uuid-libtool.patch
create mode 100644 meta/recipes-devtools/ossp-uuid/ossp-uuid/uuid-nostrip.patch
create mode 100644 meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb
create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-ossp-uuid.patch
diff --git
a/meta/recipes-devtools/ossp-uuid/ossp-uuid/0001-Change-library-name.patch
b/meta/recipes-devtools/ossp-uuid/ossp-uuid/0001-Change-library-name.patch
new file mode 100644
index 000..a46e244
--- /dev/null
+++ b/meta/recipes-devtools/ossp-uuid/ossp-uuid/0001-Change-library-name.patch
@@ -0,0 +1,112 @@
+From: Piotr Roszatycki dex...@debian.org
+Date: Wed, 27 Jan 2010 16:53:11 +0100
+Subject: [PATCH] Change library name
+
+The soname was changed to ossp-uuid to prevend the name clash with e2fsprogs's
+uuid library.
+---
+ Makefile.in |6 +++---
+ perl/Makefile.PL | 12 ++--
+ php/config.m4|2 +-
+ uuid-config.in |2 +-
+ uuid.pc.in |4 ++--
+ 5 files changed, 13 insertions(+), 13 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index d28f4be..c2ba99d 100644
+--- a/Makefile.in
b/Makefile.in
+@@ -62,13 +62,13 @@ PERL= @PERL@
+ PHP = @PHP@
+ PG_CONFIG = @PG_CONFIG@
+
+-LIB_NAME= libuuid.la
++LIB_NAME= libossp-uuid.la
+ LIB_OBJS= uuid.lo uuid_md5.lo uuid_sha1.lo uuid_prng.lo uuid_mac.lo
uuid_time.lo uuid_ui64.lo uuid_ui128.lo uuid_str.lo
+
+-DCE_NAME= libuuid_dce.la
++DCE_NAME= libossp-uuid_dce.la
+ DCE_OBJS= uuid_dce.lo $(LIB_OBJS)
+
+-CXX_NAME= libuuid++.la
++CXX_NAME= libossp-uuid++.la
+ CXX_OBJS= uuid++.lo $(LIB_OBJS)
+
+ PRG_NAME= uuid
+diff --git a/perl/Makefile.PL b/perl/Makefile.PL
+index 92f4494..9c6fee6 100644
+--- a/perl/Makefile.PL
b/perl/Makefile.PL
+@@ -33,9 +33,9 @@ use Config;
+ use ExtUtils::MakeMaker;
+
+ # determine source directory
+-my ($srcdir) = map { my $d = $_; $d =~ s/\/libuuid\.la$//; $d }
+- grep { -f $_ } (../libuuid.la, glob(../*/libuuid.la))
+-or die no source directory found (where libuuid.la is located);
++my ($srcdir) = map { my $d = $_; $d =~ s/\/libossp-uuid\.la$//; $d }
++ grep { -f $_ } (../libossp-uuid.la,
glob(../*/libossp-uuid.la))
++or die no source directory found (where libossp-uuid.la is located);
+
+ # determine extra build options
+ my $compat = 0;
+@@ -47,15 +47,15 @@ WriteMakefile(
+ VERSION_FROM = 'uuid.pm',
+ ABSTRACT_FROM = 'uuid.pod',
+ PREREQ_PM = {},
+-LIBS = [ -L$srcdir/.libs -L$srcdir -luuid ],
++LIBS = [ -L$srcdir/.libs -L$srcdir -lossp-uuid ],
+ DEFINE= '',
+ INC = -I. -I$srcdir,
+ PM= { 'uuid.pm' = '$(INST_LIBDIR)/uuid.pm',
+'uuid.pod' = '$(INST_LIBDIR)/uuid.pod',
+($compat ? ('uuid_compat.pm' =
'$(INST_LIBDIR)/../Data/UUID.pm') : ()),
+($compat ? ('uuid_compat.pod' =
'$(INST_LIBDIR)/../Data/UUID.pod') : ()), },
+-MAN3PODS = { 'uuid.pod' = '$(INST_MAN3DIR)/OSSP::uuid.3',
+- ($compat ? ('uuid_compat.pod' =
'$(INST_MAN3DIR)/Data::UUID.3') : ()), },
++MAN3PODS = { 'uuid.pod' = '$(INST_MAN3DIR)/OSSP::uuid.3pm',
++ ($compat ? ('uuid_compat.pod' =
'$(INST_MAN3DIR)/Data::UUID.3pm') : ()), },
+ TYPEMAPS = [ 'uuid.tm' ],
+ test = { TESTS = 'uuid.ts' . ($compat ? ' uuid_compat.ts'
: '') },
+ NO_META = 1,
+diff --git a/php/config.m4 b/php/config.m4
+index 5091b96..969b457 100644
+--- a/php/config.m4
[OE-core] [PATCH 2/5 v3] rpm: Upgrade RPM to 5.4.9
Beside upreving RPM, add necessary integration pathces to libzypp.
Also change the configuration of RPM to support PACKAGECONFIG flags.
RPM is highly configurable, the default configuration is good for
minimal OE-Core use.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-devtools/rpm/rpm/rpm-lua.patch| 29 +
.../rpm/rpm/rpm-scriptletexechelper.patch | 33 +++---
meta/recipes-devtools/rpm/rpm/rpmdeps-oecore.patch | 26 ++---
.../rpm/{rpm_5.4.8.bb = rpm_5.4.9.bb} | 122 +---
.../libzypp/libzypp/libzypp-rpm549.patch | 28 +
meta/recipes-extended/libzypp/libzypp_git.bb |3 +-
6 files changed, 141 insertions(+), 100 deletions(-)
create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-lua.patch
rename meta/recipes-devtools/rpm/{rpm_5.4.8.bb = rpm_5.4.9.bb} (82%)
create mode 100644 meta/recipes-extended/libzypp/libzypp/libzypp-rpm549.patch
diff --git a/meta/recipes-devtools/rpm/rpm/rpm-lua.patch
b/meta/recipes-devtools/rpm/rpm/rpm-lua.patch
new file mode 100644
index 000..980e1b1
--- /dev/null
+++ b/meta/recipes-devtools/rpm/rpm/rpm-lua.patch
@@ -0,0 +1,29 @@
+Add support for cross compiling lua
+
+Signed-off-by: Mark Hatle mark.ha...@windriver.com
+
+diff -ur rpm-5.4.9.orig/configure.ac rpm-5.4.9/configure.ac
+--- rpm-5.4.9.orig/configure.ac2012-05-16 12:16:36.589813548 -0500
rpm-5.4.9/configure.ac 2012-05-16 12:26:01.070813518 -0500
+@@ -120,6 +120,9 @@
+
+ AC_PATH_PROG(AS, as, as)
+
++CC_FOR_BUILD=${CC_FOR_BUILD-\$(CC)}
++AC_SUBST(CC_FOR_BUILD)
++
+ dnl # GCC specifics
+ AC_PROG_GCC_TRADITIONAL
+ AC_ARG_ENABLE(build-pic,
+diff -ur rpm-5.4.9.orig/lua/Makefile.am rpm-5.4.9/lua/Makefile.am
+--- rpm-5.4.9.orig/lua/Makefile.am 2012-04-07 19:15:25.0 -0500
rpm-5.4.9/lua/Makefile.am 2012-05-16 12:26:19.556856688 -0500
+@@ -40,7 +40,7 @@
+
+ # --- bin2c doesn't need anything but a compiler
+ bin2c$(EXEEXT): bin2c.c
+- $(CC) -o $@ $
++ $(CC_FOR_BUILD) -o $@ $
+
+ liblua_la_SOURCES =
+ liblua_la_CFLAGS = @WITH_LUA_SUBDIR_DEF@
diff --git a/meta/recipes-devtools/rpm/rpm/rpm-scriptletexechelper.patch
b/meta/recipes-devtools/rpm/rpm/rpm-scriptletexechelper.patch
index e4db0e4..8a9e712 100644
--- a/meta/recipes-devtools/rpm/rpm/rpm-scriptletexechelper.patch
+++ b/meta/recipes-devtools/rpm/rpm/rpm-scriptletexechelper.patch
@@ -12,10 +12,11 @@ Upstream-Status: Pending
Signed-off-by: Mark Hatle mark.ha...@windriver.com
-diff -ur rpm-5.4.0.orig/lib/psm.c rpm-5.4.0/lib/psm.c
rpm-5.4.0.orig/lib/psm.c 2010-12-29 07:42:11.0 -0600
-+++ rpm-5.4.0/lib/psm.c2011-11-08 13:38:48.132791154 -0600
-@@ -792,6 +792,10 @@
+Index: rpm-5.4.9/lib/psm.c
+===
+--- rpm-5.4.9.orig/lib/psm.c
rpm-5.4.9/lib/psm.c
+@@ -801,6 +801,10 @@ static rpmRC runScript(rpmpsm psm, Heade
int xx;
int i;
@@ -26,23 +27,23 @@ diff -ur rpm-5.4.0.orig/lib/psm.c rpm-5.4.0/lib/psm.c
if (psm-sstates != NULL ix = 0 ix RPMSCRIPT_MAX)
ssp = psm-sstates + ix;
if (ssp != NULL)
-@@ -858,14 +862,29 @@
+@@ -867,14 +871,29 @@ assert(he-p.str != NULL);
(F_ISSET(psm, UNORDERED) ? a : ));
if (Phe-p.argv == NULL) {
-- argv = alloca(5 * sizeof(*argv));
+- argv = (const char **) alloca(5 * sizeof(*argv));
- argv[0] = /bin/sh;
- argc = 1;
-+ argv = alloca(7 * sizeof(*argv));
++ argv = (const char **) alloca(7 * sizeof(*argv));
+ argc = 0;
+} else {
-+ argv = alloca((Phe-c + 6) * sizeof(*argv));
++ argv = (const char **) alloca((Phe-c + 6) * sizeof(*argv));
+ argc = 0;
+}
+
+#ifdef RPM_VENDOR_POKY
+if (scriptletWrapper *scriptletWrapper) {
-+argv[argc++] = scriptletWrapper;
++ argv[argc++] = scriptletWrapper;
+ argv[argc] = rpmtsRootDir(ts);
+ if (!argv[argc] || !*argv[argc])
+ argv[argc] = /;
@@ -51,10 +52,10 @@ diff -ur rpm-5.4.0.orig/lib/psm.c rpm-5.4.0/lib/psm.c
+#endif
+
+if (Phe-p.argv == NULL) {
-+argv[argc++] = /bin/sh;
++ argv[argc++] = /bin/sh;
ldconfig_done = 0;
} else {
-- argv = alloca((Phe-c + 4) * sizeof(*argv));
+- argv = (const char **) alloca((Phe-c + 4) * sizeof(*argv));
- memcpy(argv, Phe-p.argv, Phe-c * sizeof(*argv));
- argc = Phe-c;
+ memcpy((argv + argc), Phe-p.argv, Phe-c * sizeof(*argv));
@@ -62,7 +63,7 @@ diff -ur rpm-5.4.0.orig/lib/psm.c rpm-5.4.0/lib/psm.c
ldconfig_done = (ldconfig_path !strcmp(argv[0], ldconfig_path)
? 1 : 0);
}
-@@ -916,7 +935,12 @@
+@@ -925,7 +944,12 @@ assert(he-p.str != NULL);
goto exit;
if (rpmIsDebug()
@@ -76,7 +77,7 @@ diff -ur rpm-5.4.0.orig/lib/psm.c rpm-5.4.0/lib/psm.c
{
static const char set_x[] = set -x\n;
nw = Fwrite(set_x, sizeof(set_x[0]), sizeof(set_x)-1, fd);
-@@
[OE-core] [PATCH 4/5 v3] package_rpm: Add capability to directly query packageorigin
Add functionality to RPM to directly query the packageorigin (path) from
the resolver database, instead of having to do this via an indirect method.
This results in a minor performance improvement.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/classes/package_rpm.bbclass | 18 +++---
.../rpm/rpm/rpm-packageorigin.patch| 23
meta/recipes-devtools/rpm/rpm_5.4.9.bb |3 +-
3 files changed, 34 insertions(+), 10 deletions(-)
create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-packageorigin.patch
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 35928ab..097fa12 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -130,12 +130,12 @@ resolve_package_rpm () {
shift
local pkg_name=
for solve in `cat ${conffile}`; do
- pkg_name=$(${RPM} -D _dbpath $solve -D __dbi_txn create
nofsync -q --yaml $@ | grep -i 'Packageorigin' | cut -d : -f 2)
- if [ -n $pkg_name ]; then
+ pkg_name=$(${RPM} -D _dbpath $solve -D __dbi_txn create
nofsync -q --qf %{packageorigin}\n $@ | grep -v is not installed || true)
+ if [ -n $pkg_name -a $pkg_name != (none) ]; then
+ echo $pkg_name
break;
fi
done
- echo $pkg_name
}
# rpm common command and options
@@ -401,9 +401,9 @@ package_install_internal_rpm () {
# Now that we have a solution, pull out a list of what to install...
echo Manifest: ${target_rootfs}/install/install.manifest
- ${RPM} -D _dbpath ${target_rootfs}/install -qa --yaml \
+ ${RPM} -D _dbpath ${target_rootfs}/install -qa --qf
%{packageorigin}\n \
-D __dbi_txn create nofsync private \
- | grep -i 'Packageorigin' | cut -d : -f 2
${target_rootfs}/install/install_solution.manifest
+${target_rootfs}/install/install_solution.manifest
touch ${target_rootfs}/install/install_multilib_solution.manifest
@@ -421,9 +421,9 @@ package_install_internal_rpm () {
# Now that we have a solution, pull out a list of what to
install...
echo Manifest:
${target_rootfs}/install/install_multilib.manifest
- ${RPM} -D _dbpath ${target_rootfs}/install -qa --yaml \
+ ${RPM} -D _dbpath ${target_rootfs}/install -qa --qf
%{packageorigin}\n \
-D __dbi_txn create nofsync private \
- | grep -i 'Packageorigin' | cut -d : -f 2
${target_rootfs}/install/install_multilib_solution.manifest
+
${target_rootfs}/install/install_multilib_solution.manifest
fi
@@ -478,9 +478,9 @@ EOF
-U --justdb --noscripts --notriggers --noparentdirs
--nolinktos --ignoresize \
${target_rootfs}/install/initial_install.manifest
- ${RPM} -D _dbpath ${target_rootfs}/initial -qa --yaml \
+ ${RPM} -D _dbpath ${target_rootfs}/initial -qa --qf
%{packageorigin}\n \
-D __dbi_txn create nofsync private \
- | grep -i 'Packageorigin' | cut -d : -f 2
${target_rootfs}/install/initial_solution.manifest
+${target_rootfs}/install/initial_solution.manifest
rpm_update_pkg
${target_rootfs}/install/initial_solution.manifest
diff --git a/meta/recipes-devtools/rpm/rpm/rpm-packageorigin.patch
b/meta/recipes-devtools/rpm/rpm/rpm-packageorigin.patch
new file mode 100644
index 000..3c6dad4
--- /dev/null
+++ b/meta/recipes-devtools/rpm/rpm/rpm-packageorigin.patch
@@ -0,0 +1,23 @@
+Add the ability to query the packageorigin
+
+Written by jbj at rpm5.org
+
+Signed-off-by: Mark Hatle mark.ha...@windriver.com
+
+Index: rpm-5.4.8/rpmdb/hdrfmt.c
+===
+--- rpm-5.4.8.orig/rpmdb/hdrfmt.c
rpm-5.4.8/rpmdb/hdrfmt.c
+@@ -2403,8 +2403,10 @@ static int pkgoriginTag(Header h, HE_t
+ int rc = 1;
+
+ he-tag = RPMTAG_PACKAGEORIGIN;
+-if (!headerGet(h, he, HEADERGET_NOEXTENSION)
+- (origin = headerGetOrigin(h)) != NULL)
++/* XXX two sources for tag data: what search precedence? */
++if (headerGet(h, he, HEADERGET_NOEXTENSION))
++ rc = 0;
++else if ((origin = headerGetOrigin(h)) != NULL)
+ {
+ he-t = RPM_STRING_TYPE;
+ he-p.str = xstrdup(origin);
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
index f2477a4..2fb5b97 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
@@ -43,7 +43,7 @@ LICENSE = LGPLv2.1
LIC_FILES_CHKSUM = file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1
DEPENDS = libpcre attr acl popt ossp-uuid file
-PR = r41
+PR = r42
# rpm2cpio is a shell script,
[OE-core] [PATCH 5/5 v3] rpm: Bump PR numbers on componets that require RPM
With the recent RPM uprev, libzypp, sat-solver and zypper should be
rebuilt to ensure they get the right BerkleyDB and rpmdb interfaces.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-extended/libzypp/libzypp_git.bb |2 +-
meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +-
meta/recipes-extended/zypper/zypper_git.bb |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-extended/libzypp/libzypp_git.bb
b/meta/recipes-extended/libzypp/libzypp_git.bb
index c5761d5..90ee8c4 100644
--- a/meta/recipes-extended/libzypp/libzypp_git.bb
+++ b/meta/recipes-extended/libzypp/libzypp_git.bb
@@ -11,7 +11,7 @@ DEPENDS = rpm boost curl libxml2 zlib sat-solver expat
openssl udev libproxy
S = ${WORKDIR}/git
SRCREV = 15b6c52260bbc52b3d8e585e271b67e10cc7c433
PV = 0.0-git${SRCPV}
-PR = r21
+PR = r22
SRC_URI = git://github.com/openSUSE/libzypp.git;protocol=git \
file://no-doc.patch \
diff --git a/meta/recipes-extended/sat-solver/sat-solver_git.bb
b/meta/recipes-extended/sat-solver/sat-solver_git.bb
index 9d8422f..b0382f6 100644
--- a/meta/recipes-extended/sat-solver/sat-solver_git.bb
+++ b/meta/recipes-extended/sat-solver/sat-solver_git.bb
@@ -8,7 +8,7 @@ DEPENDS = libcheck rpm zlib expat db
SRCREV = 0a7378d5f482f477a01cf1690d76871ab8bdcc32
PV = 0.0-git${SRCPV}
-PR = r13
+PR = r14
PARALLEL_MAKE=
diff --git a/meta/recipes-extended/zypper/zypper_git.bb
b/meta/recipes-extended/zypper/zypper_git.bb
index 56ccc86..0a1df5d 100644
--- a/meta/recipes-extended/zypper/zypper_git.bb
+++ b/meta/recipes-extended/zypper/zypper_git.bb
@@ -5,7 +5,7 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=3201406e350b39e05a82e28b5020f413
DEPENDS = libzypp augeas
-PR = r2
+PR = r3
SRCREV = 2c5bb6ceb99ecd950ef993e43d77bf0569ea0582
inherit cmake
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] target rpm build failure
On Thu, May 31, 2012 at 7:47 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: Have new suggestions? I found a bit of time and fixed rpm compilation on uclibc. Its only compiling though I don't know if it will run on target. Try it out. The patch is here http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/miscid=3b7ab8bbaca0c7ce122e897a11370dd215b0eddd This should get you going. Please test it out and I would prefer if you can also try it out on target and see if it really runs too. -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] systemtap build fails
Hi, I pulled today, started a build from scratch and ran into trouble with systemtap: ... | In file included from csclient.h:12:0, | from main.cxx:24: | cscommon.h:8:17: fatal error: ssl.h: No such file or directory | compilation terminated. | In file included from csclient.h:12:0, | from session.cxx:18: | cscommon.h:8:17: fatal error: ssl.h: No such file or directory | compilation terminated. | make[2]: *** [stap-session.o] Error 1 | make[2]: *** Waiting for unfinished jobs | make[2]: *** [stap-main.o] Error 1 | make[2]: Leaving directory `/home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r4/git' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r4/git' | make: *** [all] Error 2 | ERROR: oe_runmake failed ... I added --without-nss to EXTRA_OECONF and rebuild. Now stap-main.o and stap-session.o were build but now I get ... | modverify.c:28:21: fatal error: pk11pub.h: No such file or directory | compilation terminated. | make[3]: *** [staprun-modverify.o] Error 1 | make[3]: *** Waiting for unfinished jobs | ../../nsscommon.cxx:37:17: fatal error: ssl.h: No such file or directory | compilation terminated. | make[3]: *** [staprun-nsscommon.o] Error 1 | make[3]: Leaving directory `/home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r5/git/runtime/staprun' | make[2]: *** [all] Error 2 | make[2]: Leaving directory `/home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r5/git/runtime/staprun' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r5/git' | make: *** [all] Error 2 | ERROR: oe_runmake failed ... In config.log I find ... HAVE_NSS_TRUE='#' ... This is strange: In runtime/staprun/Makefile.am the failed files should be excluded from build ... if HAVE_NSS staprun_SOURCES += modverify.c ../../nsscommon.cxx staprun_CFLAGS += $(nss_CFLAGS) staprun_CXXFLAGS += $(nss_CFLAGS) staprun_LDADD += $(nss_LIBS) endif ... Seems HAVE_NSS_TRUE='#' has not reached runtime/staprun Any thoughts? Andreas ___ 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] opkg 0.1.8: respect to the arch when choose the alternatives
On 05/31/2012 11:01 PM, Koen Kooi wrote: Op 31 mei 2012, om 16:13 heeft Robert Yang het volgende geschreven: There is a bug if we: 1) bitbake core-image-sato-sdk MACHINE=qemux86 2) bitbake core-image-sato with MACHINE=crownbay Then several pkgs in deploy/ipk/i586 would be installed to crownbay's image even if there is one in deploy/ipk/core2 and we have set the core2's priority higher than i586, when the version in deploy/ipk/i586 is higher. This doesn't work for us, for example, what the crownbay need is xserver-xorg-1.9.3, but it installs xserver-xorg-1.11.2. And this is working exactly as intended. Don't break opkg because your hardware driver situation sucks. Hi Koen, Thanks for your great patient on this patch:-), I'm afraid that this is not working exactly as intended, since the rpm or dpkg doesn't have this issue. (I have fixed other issue for rpm, but not the same as this one, the xserver-xorg-1.9.3.rpm had installed correctly before the fix for rpm). and dpkg works well without any fix. I'm also glad that if we won't fix it. // Robert So: NAK on this 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] webkit-gtk: Use glib as unicode backend to avoid browser crash
On Wed, May 30, 2012 at 12:56:27PM -0600, Gary Thomas wrote: On 2012-05-30 10:40, Richard Purdie wrote: I've merged this however I'm not 100% happy with this as the final fix. I'd ask that: a) The bug remains open (re-prioritised appropriately) about the remaining issues that still exist in ICU b) We add something to the ICU recipe which stops it building when the endianess isn't correct (host matches target) so nobody can built it and have it not work. Why not accept my patch that provides a working dataset? I doubt Provideding a big binary in yocto website is not clean, but it should avoid potential side effect. that you're ever going to get the ICU folks interested to the point of fixing this correctly and this solves the problem without the [IMO undesirable] side effect of using different libraries on This is ultimate solution. I remember ICU community is not so active to do it. different architectures (for webkit-gtk). -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- best rgds, edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] RPM packaging issue?
Hi list, I was trying to build core-image-gtk-directfb and ended up with this error: Log data follows: | DEBUG: Executing shell function do_rootfs | ERROR: Function failed: do_rootfs (see /home/lau/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.4857 for further information) | Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/qemux86... | Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/i586... | Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/all... | Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/all... | Processing task-core-boot... | Processing module-init-tools... | Unable to find package module-init-tools (module-init-tools)! NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed module-init-tools is provided by kmod package and is in the RDEPENDS of task_base recipe. Then I tried to add module_init_tools to CORE_IMAGE_EXTRA_INSTALL and build core-image-minimal (just for testing), the same result. The interesting thing is that this didn't happen if the packaging format is ipk. Anybody know anything about this issue? Thanks, Laurentiu ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] More external toolchain fixes/improvements
From: Christopher Larson chris_lar...@mentor.com The following changes since commit e3113827810e98eb1b012f0b280fb917199704c1: webkit-gtk: Use glib as unicode backend to avoid browser crash (2012-05-30 17:37:58 +0100) are available in the git repository at: github:kergoth/oe-core toolchain Christopher Larson (3): external-sourcery: extract src and dest sysroot paths from gcc tcmode-external-sourcery: pass -msgxx-glibc for x86 external-sourcery-toolchain: forcibly create usr/lib .../distro/include/tcmode-external-sourcery.inc| 48 --- .../meta/external-sourcery-toolchain.bb| 25 +-- 2 files changed, 41 insertions(+), 32 deletions(-) -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] tcmode-external-sourcery: pass -msgxx-glibc for x86
From: Christopher Larson chris_lar...@mentor.com
This is needed to work around an issue with the toolchain search paths. It can
pick up the wrong features.h without it, it seems, even with the system32
symlink in the oe sysroot. Investigate this further in the future.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
.../distro/include/tcmode-external-sourcery.inc|7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/meta/conf/distro/include/tcmode-external-sourcery.inc
b/meta/conf/distro/include/tcmode-external-sourcery.inc
index d5abc16..834a4d9 100644
--- a/meta/conf/distro/include/tcmode-external-sourcery.inc
+++ b/meta/conf/distro/include/tcmode-external-sourcery.inc
@@ -56,11 +56,8 @@ EXTERNAL_TOOLCHAIN_SYSROOT ??= ${@exttc_run(d,
EXTERNAL_TOOLCHAIN_SYSROOT_CMD)}
# These bits are here temporarily to sidestep the need to use a separate set
# of tune files to pass the appropriate multilib selection arguments to the
# sourcery toolchain, as is needed to extract the sysroot content.
-CSL_MULTILIB_ARGS[i586] = -msgxx-glibc
-CSL_MULTILIB_ARGS[i686] = -msgxx-glibc
-CSL_MULTILIB_ARGS[core2] = -msgxx-glibc
-CSL_MULTILIB_ARGS[x86] = -msgxx-glibc
-CSL_MULTILIB_ARGS[x86-64] = -msgxx-glibc
+TUNE_CCARGS_append_x86 = -msgxx-glibc
+
CSL_MULTILIB_ARGS[ppce500] = -te500v1
CSL_MULTILIB_ARGS[ppce500mc] = -te500mc
CSL_MULTILIB_ARGS[ppce500v2] = -te500v2
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] external-sourcery-toolchain: forcibly create usr/lib
From: Christopher Larson chris_lar...@mentor.com
If the usr/lib directory doesn't exist, the toolchain can fail to even try to
find crti.o in a completely different directory. This causes a failure for the
case where baselib is lib64.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
.../meta/external-sourcery-toolchain.bb|6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/meta/external-sourcery-toolchain.bb
b/meta/recipes-core/meta/external-sourcery-toolchain.bb
index b67410b..74c82ec 100644
--- a/meta/recipes-core/meta/external-sourcery-toolchain.bb
+++ b/meta/recipes-core/meta/external-sourcery-toolchain.bb
@@ -24,7 +24,7 @@ PROVIDES += \
virtual/linux-libc-headers \
PV = ${CSL_VER_MAIN}
-PR = r6
+PR = r7
#SRC_URI =
http://www.codesourcery.com/public/gnu_toolchain/${CSL_TARGET_SYS}/arm-${PV}-${TARGET_PREFIX}i686-pc-linux-gnu.tar.bz2;
@@ -78,6 +78,10 @@ external_toolchain_sysroot_adjust() {
rm -f ${SYSROOT_DESTDIR}/$dest_sysroot
ln -s . ${SYSROOT_DESTDIR}/$dest_sysroot
fi
+
+ # If the usr/lib directory doesn't exist, the toolchain fails to even
+ # try to find crti.o in a completely different directory (usr/lib64)
+ install -d ${SYSROOT_DESTDIR}/usr/lib
}
PACKAGES =+ libgcc libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev
linux-libc-headers linux-libc-headers-dev gdbserver gdbserver-dbg
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] external-sourcery: extract src and dest sysroot paths from gcc
From: Christopher Larson chris_lar...@mentor.com
Rather than hardcoding the multilib path in a map, and hardcoding dest sysroot
symlink creation in a hook, now we just use -print-sysroot for both, and pass
the appropriate multilib args to the toolchain for particular tunes.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
.../distro/include/tcmode-external-sourcery.inc| 51 +---
.../meta/external-sourcery-toolchain.bb| 21 +++-
2 files changed, 40 insertions(+), 32 deletions(-)
diff --git a/meta/conf/distro/include/tcmode-external-sourcery.inc
b/meta/conf/distro/include/tcmode-external-sourcery.inc
index 79fef25..d5abc16 100644
--- a/meta/conf/distro/include/tcmode-external-sourcery.inc
+++ b/meta/conf/distro/include/tcmode-external-sourcery.inc
@@ -42,24 +42,39 @@ ENABLE_BINARY_LOCALE_GENERATION =
TOOLCHAIN_OPTIONS = --sysroot=${STAGING_DIR_HOST}
-# Translate to CodeSourcery's names for their optimized files in the toolchain
-def csl_target_core(d):
-coredata = {
-'armv7a-vfp-neon': 'armv7-a-neon',
-'i586': 'sgxx-glibc',
-'i686': 'sgxx-glibc',
-'core2': 'sgxx-glibc',
-'mips': 'mips32',
-'mipsel': 'el',
-'powerpc-nf': 'nof',
-'ppce500': 'te500v1',
-'ppce500mc': 'te500mc',
-'ppce500v2': 'te500v2',
-'ppce600': 'te600'
-}
-return coredata.get(d.getVar('TUNE_PKGARCH', True), '')
-
-CSL_TARGET_CORE ?= ${@csl_target_core(d)}
+# Point to the appropriate multilib sysroot from the external toolchain, whose
+# files will be extracted into the OE sysroot
+def exttc_run(d, cmd):
+try:
+return bb.process.run(cmd, shell=True, env={'PATH': d.getVar('PATH',
True)})[0].rstrip()
+except (OSError, bb.process.CmdError):
+return ''
+
+EXTERNAL_TOOLCHAIN_SYSROOT_CMD = ${TARGET_PREFIX}gcc ${TARGET_CC_ARCH}
-print-sysroot
+EXTERNAL_TOOLCHAIN_SYSROOT ??= ${@exttc_run(d,
EXTERNAL_TOOLCHAIN_SYSROOT_CMD)}
+
+# These bits are here temporarily to sidestep the need to use a separate set
+# of tune files to pass the appropriate multilib selection arguments to the
+# sourcery toolchain, as is needed to extract the sysroot content.
+CSL_MULTILIB_ARGS[i586] = -msgxx-glibc
+CSL_MULTILIB_ARGS[i686] = -msgxx-glibc
+CSL_MULTILIB_ARGS[core2] = -msgxx-glibc
+CSL_MULTILIB_ARGS[x86] = -msgxx-glibc
+CSL_MULTILIB_ARGS[x86-64] = -msgxx-glibc
+CSL_MULTILIB_ARGS[ppce500] = -te500v1
+CSL_MULTILIB_ARGS[ppce500mc] = -te500mc
+CSL_MULTILIB_ARGS[ppce500v2] = -te500v2
+CSL_MULTILIB_ARGS[ppce600] = -te600
+
+def csl_multilib_arg(d):
+argument = d.getVarFlag('CSL_MULTILIB_ARGS', d.getVar('DEFAULTTUNE', True)
or '')
+if argument:
+return argument
+else:
+return ''
+
+EXTERNAL_TOOLCHAIN_SYSROOT_CMD += ${@csl_multilib_arg(d)}
+
# Unfortunately, the CSL ia32 toolchain has non-prefixed binaries in its
# bindir (e.g. gcc, ld). To avoid this messing up our build, we avoid adding
diff --git a/meta/recipes-core/meta/external-sourcery-toolchain.bb
b/meta/recipes-core/meta/external-sourcery-toolchain.bb
index b8cb6d9..b67410b 100644
--- a/meta/recipes-core/meta/external-sourcery-toolchain.bb
+++ b/meta/recipes-core/meta/external-sourcery-toolchain.bb
@@ -24,7 +24,7 @@ PROVIDES += \
virtual/linux-libc-headers \
PV = ${CSL_VER_MAIN}
-PR = r5
+PR = r6
#SRC_URI =
http://www.codesourcery.com/public/gnu_toolchain/${CSL_TARGET_SYS}/arm-${PV}-${TARGET_PREFIX}i686-pc-linux-gnu.tar.bz2;
@@ -32,10 +32,7 @@ SRC_URI = file://SUPPORTED
do_install() {
# Use optimized files if available
- sysroot=${EXTERNAL_TOOLCHAIN}/${CSL_TARGET_SYS}/libc
- if [ -d $sysroot/${CSL_TARGET_CORE} ]; then
- sysroot=$sysroot/${CSL_TARGET_CORE}
- fi
+ sysroot=${EXTERNAL_TOOLCHAIN_SYSROOT}
cp -a $sysroot${base_libdir}/. ${D}${base_libdir}
cp -a $sysroot/etc/. ${D}${sysconfdir}
@@ -76,15 +73,11 @@ do_install() {
SYSROOT_PREPROCESS_FUNCS += external_toolchain_sysroot_adjust
external_toolchain_sysroot_adjust() {
- if [ -n ${CSL_TARGET_CORE} ]; then
- rm -f ${SYSROOT_DESTDIR}/${CSL_TARGET_CORE}
- ln -s . ${SYSROOT_DESTDIR}/${CSL_TARGET_CORE}
- fi
-
- if [ ${TUNE_PKGARCH} = i586 ]; then
- rm -f ${SYSROOT_DESTDIR}/system32
- ln -s . ${SYSROOT_DESTDIR}/system32
- fi
+ dest_sysroot=$(${CC} -print-sysroot | sed -e's,^${STAGING_DIR_HOST},,;
s,/$,,')
+ if [ -n $dest_sysroot ]; then
+ rm -f ${SYSROOT_DESTDIR}/$dest_sysroot
+ ln -s . ${SYSROOT_DESTDIR}/$dest_sysroot
+ fi
}
PACKAGES =+ libgcc libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev
linux-libc-headers linux-libc-headers-dev gdbserver gdbserver-dbg
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
Re: [OE-core] [PATCH 0/3] More external toolchain fixes/improvements
On Thu, May 31, 2012 at 7:00 PM, Christopher Larson kerg...@gmail.com wrote: are available in the git repository at: github:kergoth/oe-core toolchain Erm, forgot to correct the url, my git url insteadOf adjusts this. https://github.com/kergoth/oe-core toolchain ___ 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] external-sourcery: extract src and dest sysroot paths from gcc
On Thu, 31 May 2012 19:00:04 -0700 Christopher Larson kerg...@gmail.com wrote: +CSL_MULTILIB_ARGS[i586] = -msgxx-glibc +CSL_MULTILIB_ARGS[i686] = -msgxx-glibc +CSL_MULTILIB_ARGS[core2] = -msgxx-glibc +CSL_MULTILIB_ARGS[x86] = -msgxx-glibc +CSL_MULTILIB_ARGS[x86-64] = -msgxx-glibc +CSL_MULTILIB_ARGS[ppce500] = -te500v1 +CSL_MULTILIB_ARGS[ppce500mc] = -te500mc +CSL_MULTILIB_ARGS[ppce500v2] = -te500v2 +CSL_MULTILIB_ARGS[ppce600] = -te600 I would suggest that these be ?= assignments. Rationale: There is more than one Sourcery toolchain out there, and they sometimes differ in these. It'd be nice if a hypothetical vendor using a hypothetical custom variant of the Sourcery toolchain could use these configuration files with nothing more than a few variable assignments. :) I do quite like the cleanup. -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
