Re: [OE-core] [PATCH] gdk-pixbuf: Ensure gdk-pixbuf-native dependencies are correct with linuxstdbase
On Tuesday 02 October 2012 01:09:18 Richard Purdie wrote:
Without this change, anything using linuxstdbase would incorrectly
try and pull in X dependencies.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb index 82a7eaa..8d18b87
100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb
@@ -35,6 +35,7 @@ EXTRA_OECONF = \
X11DEPENDS = --without-x11
X11DEPENDS_linuxstdbase = ${@base_contains('DISTRO_FEATURES', 'x11',
'--with-x11', '--without-x11', d)} +X11
DEPENDS_virtclass-native = --without-x11
PACKAGES =+ ${PN}-xlib
Thanks, FYI this fixes [YOCTO #3154].
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] [oe-core][PATCH 00/10] qt4: upgrade to 4.8.3 and cleanup
On Tue, Oct 02, 2012 at 01:26:37AM +0200, Martin Jansa wrote:
On Mon, Oct 01, 2012 at 04:31:08PM +0200, Martin Jansa wrote:
On Sun, Sep 30, 2012 at 10:18:18PM +0200, Martin Jansa wrote:
On Fri, Sep 28, 2012 at 06:43:09PM +0200, Martin Jansa wrote:
On Thu, Sep 27, 2012 at 12:27:05AM +0200, Martin Jansa wrote:
Please test on more architectures.
I've tested complete qt4-native + qt4-free-x11 on armv4t.
And only do_patch for nativesdk-qt4-tools, qt-mobility-*,
qt4-embedded.
I've finished testing qt4-free-x11 on armv7a, x86_64 and armv5te +
qt-mobility-x11 on armv4t and armv7a.
Only python-pyqt_4.8.4.bb from meta-oe is failing with that, probably
needs to be updated to 4.9.2 or something like that.
This seems to be caused by missing webkit support in qt4-4.8.3.
python-pyqt-4.9.4 and 4.9.5 fails the same.
Configure ignores -webkit and says that webkit won't be built I've found
some bug reports upstream but those were resolved by forcing xrender
support which doesn't help in our case..
Found it, jansa/qt4-4.8.3 updated and 4.8.3 now added with negative D_P
instead of replacing 4.8.1, will send v2 tonight.
Here is buildhistory log when whole patchset is applied without defining
P_P.
https://github.com/shr-distribution/buildhistory/commit/0e0245527626b77d7913c3b44976eab478c04ca5
https://github.com/shr-distribution/buildhistory/commit/56385ad686ab9591460d3be4d3eb13b4beddc45e
note that there are few changes, because before PR bump it was built
with gcc 4.7.1.0+git1+d07e24f4ab59f264d68d21838795349faab5dede not
4.7.2.
Here is even better buildhistory log without that gcc change:
https://github.com/shr-distribution/buildhistory/commit/bb6444238bb6dc72b51c24a7dcf5d9b197d60edc
https://github.com/shr-distribution/buildhistory/commit/aed142b2ab93fcdcdf316a667d5bcdde741d27e7
Can it go in, now?
Cheers,
And here are branches (oe-core-4.8.1, oe-core-4.8.3) with all patches applied
https://github.com/shr-project/qt
Cheers,
Cheers,
Should I resend only 4.8.1 cleanup without adding 4.8.3 or with 4.8.3
having negative D_P?
Cheers,
The following changes since commit
938d07871bedd91f0d95ed6fe338ecbfafa5ebfe:
busybox: Fix misplaced quote (2012-09-26 18:28:17 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib jansa/qt4-4.8.3
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/qt4-4.8.3
Martin Jansa (10):
qt4-tools-nativesdk.inc: rename to nativesdk-qt4-tools.inc
qt4: use releases.qt-project.org instead of get.qt.nokia.com
qt4: rename qt-4.8.1 to qt4-4.8.1 to match other .inc and .bb
qt4.inc: move more options to separate variables
qt-mobility: move qt-mobility patches to separate dir
qt4: move patches from files to qt4-4.8.1
qt4: drop patches not used in any recipe
qt4: replace all local patches with git patches with headers
qt4: PR bumps
qt4: upgrade to 4.8.3
meta/recipes-qt/qt4/files/0004-no-qmake.patch | 27 --
meta/recipes-qt/qt4/files/0008-qt-lib-infix.patch | 41 --
.../qt4/files/blacklist-diginotar-certs.diff | 95
--
.../recipes-qt/qt4/files/compile.test-lflags.patch | 17
meta/recipes-qt/qt4/files/fix-config-tests.patch | 38 -
...tools-nativesdk.inc = nativesdk-qt4-tools.inc} | 18 ++--
meta/recipes-qt/qt4/nativesdk-qt4-tools_4.8.1.bb | 8 --
meta/recipes-qt/qt4/nativesdk-qt4-tools_4.8.3.bb | 8 ++
.../qt4/qt-4.8.1/fix_conflicting_types.patch | 29 ---
meta/recipes-qt/qt4/qt-4.8.1/gcc47-fix.patch | 35
meta/recipes-qt/qt4/qt-4.8.1/qmake_cxx_eval.patch | 22 -
...stvideoconnector-fixed-buffers-allocation.patch | 0
...nnecessary-rpaths-from-qml_device-example.patch | 0
.../{files = qt-mobility-1.2.0}/gcc-scope.patch | 0
.../qt-mobility-configure.patch| 0
.../qt-mobility-no-opengl.patch| 0
meta/recipes-qt/qt4/qt-mobility_1.2.0.inc | 3 +-
.../recipes-qt/qt4/{qt-4.8.1.inc = qt4-4.8.3.inc} | 41 +-
...-allow-to-set-qt.conf-from-the-outside-u.patch} | 28 +--
...ty_qws-fix-build-with-old-kernel-headers.patch} | 21 -
...03-webkit2-set-OUTPUT_DIR-value-if-empty.patch} | 21 -
...make-is-already-built-in-qt4-tools-native.patch | 29 +++
...-set-LFLAGS-to-pick-up-zlib-from-staging.patch} | 24 --
...e-OE_QMAKE_-values-to-specify-Qt-utility.patch} | 26 --
...const-usage-that-causes-compile-failure-.patch} | 26 --
...low-building-a-separate-qmake-for-the-ta.patch} | 20 +++--
...-fix-source-file-references-in-qmake.pri.patch} | 15 ++--
Re: [OE-core] [PATCH] binutils-crossdk: Fix interp size expansion
On 10/02/2012 10:33 AM, Khem Raj wrote:
i need to check it with 1 more case. Please hold on for applying it. I
welcome testing
On Mon, Oct 1, 2012 at 10:36 PM, Khem Raj raj.k...@gmail.com wrote:
Currently for sdk binutils we expand the size of .interp
section to 0x1000 assuming that its at the beginning of
the linker map but there may be program header before that
so actually we want to add 0x1000 - sizeof(.interp) section
to current location and not assign is absolutely to 0x1000
Why does it matter if there is another program header before .interp?
The .interp section should start at the end of the previous section.
This fixes errors like
built in linker script:11 cannot move location counter backwards (from
00401054 to 00401000)
This error usually means that the data inside that section exceeds the
allocated size of the section. Assuming .interp section is the first,
the linker is trying to squeeze 0x1054 bytes in a 0x1000 bytes section.
And that is kind of weird. We might be missing something here...
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../binutils/binutils-crosssdk_2.22.bb |2 +-
.../binutils/binutils/relocatable_sdk.patch| 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb
b/meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb
index c936549..d3c25b6 100644
--- a/meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb
+++ b/meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb
@@ -2,7 +2,7 @@ require binutils-cross_${PV}.bb
inherit crosssdk
-PR = r1
+PR = r2
PROVIDES = virtual/${TARGET_PREFIX}binutils-crosssdk
diff --git a/meta/recipes-devtools/binutils/binutils/relocatable_sdk.patch
b/meta/recipes-devtools/binutils/binutils/relocatable_sdk.patch
index 33f9e68..4a2494a 100644
--- a/meta/recipes-devtools/binutils/binutils/relocatable_sdk.patch
+++ b/meta/recipes-devtools/binutils/binutils/relocatable_sdk.patch
@@ -7,16 +7,16 @@ by the relocating script.
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
-Index: binutils-2.22/ld/scripttempl/elf.sc
+Index: git/ld/scripttempl/elf.sc
===
binutils-2.22.orig/ld/scripttempl/elf.sc
-+++ binutils-2.22/ld/scripttempl/elf.sc
-@@ -116,7 +116,7 @@ if test -n ${COMMONPAGESIZE}; then
+--- git.orig/ld/scripttempl/elf.sc 2012-10-01 21:42:18.729294685 -0700
git/ld/scripttempl/elf.sc 2012-10-01 22:26:35.149173335 -0700
+@@ -125,7 +125,7 @@
DATA_SEGMENT_RELRO_END=. = DATA_SEGMENT_RELRO_END
(${SEPARATE_GOTPLT-0}, .);
fi
if test -z ${INITIAL_READONLY_SECTIONS}${CREATE_SHLIB}; then
- INITIAL_READONLY_SECTIONS=.interp ${RELOCATING-0} : { *(.interp)
}
-+ INITIAL_READONLY_SECTIONS=.interp ${RELOCATING-0} : { *(.interp);
. = 0x1000; }
++ INITIAL_READONLY_SECTIONS=.interp ${RELOCATING-0} : { *(.interp);
. = (. 0x1000) + 0x1000; }
This line confuses me. You will have here an .interp size of 0x1000 or
0x2000. Is this the intent?
Thanks,
Laurentiu
fi
if test -z $PLT; then
IPLT=.iplt ${RELOCATING-0} : { *(.iplt) }
--
1.7.9.5
___
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] rootfs_ipk, image: Add debug capture support
If ${IMAGE_BUILD_DEBUG} is set, construct a parallel tree containing
the debug data for the packages that have been installed in the
rootfs, then tar it up and deploy it alongside the rootfs images.
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/classes/image.bbclass |9 +
meta/classes/rootfs_ipk.bbclass | 15 +++
meta/conf/bitbake.conf |1 +
3 files changed, 25 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index ab212b3..c82fba1 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -445,3 +445,12 @@ do_package_write_deb[noexec] = 1
do_package_write_rpm[noexec] = 1
addtask rootfs before do_build
+
+fakeroot do_capture_debug() {
+ if [ ${IMAGE_BUILD_DEBUG} = 1 -a -n ${IMAGE_ROOTFS_DBG} -a -d
${IMAGE_ROOTFS_DBG} ]; then
+ tar czf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.debug.tar.gz -C
${IMAGE_ROOTFS_DBG} .
+ [ ${IMAGE_NAME} == ${IMAGE_LINK_NAME} ] || ln -sf
${IMAGE_NAME}.debug.tar.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.debug.tar.gz
+ fi
+}
+
+addtask capture_debug before do_build after do_rootfs
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index 46e8d60..e4e74dd 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -9,6 +9,8 @@ EXTRAOPKGCONFIG ?=
ROOTFS_PKGMANAGE = opkg opkg-collateral ${EXTRAOPKGCONFIG}
ROOTFS_PKGMANAGE_BOOTSTRAP = run-postinsts
+IMAGE_BUILD_DEBUG ?= 0
+
do_rootfs[depends] += opkg-native:do_populate_sysroot
opkg-utils-native:do_populate_sysroot
do_rootfs[recrdeptask] += do_package_write_ipk
@@ -17,6 +19,7 @@ do_rootfs[lockfiles] += ${WORKDIR}/ipk.lock
IPKG_ARGS = -f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite
# The _POST version also works when constructing the matching SDK
IPKG_ARGS_POST = -f ${IPKGCONF_TARGET} -o $INSTALL_ROOTFS_IPK
--force-overwrite
+IPKG_ARGS_DBG = -f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS_DBG}
--force-overwrite
OPKG_PREPROCESS_COMMANDS = package_update_index_ipk;
package_generate_ipkg_conf
@@ -88,6 +91,18 @@ fakeroot rootfs_ipk_do_rootfs () {
fi
fi
+ if [ ${IMAGE_BUILD_DEBUG} = 1 -a -n ${IMAGE_ROOTFS_DBG} ]; then
+ all_pkgs=`opkg-cl ${IPKG_ARGS} list-installed | awk '{ print $1
}'`
+ [ ${IMAGE_ROOTFS_DBG} -ef ${IMAGE_ROOTFS} ] || rm -rf
${IMAGE_ROOTFS_DBG}
+ mkdir -p ${IMAGE_ROOTFS_DBG}${opkglibdir}
+ opkg-cl ${IPKG_ARGS_DBG} update
+ for p in $all_pkgs; do
+ if [ `opkg-cl ${IPKG_ARGS_DBG} info $p-dbg` != ];
then
+ opkg-cl ${IPKG_ARGS_DBG} --nodeps install $p-dbg
+ fi
+ done
+ fi
+
install -d ${IMAGE_ROOTFS}/${sysconfdir}
echo ${BUILDNAME} ${IMAGE_ROOTFS}/${sysconfdir}/version
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 87351e0..66152fe 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -399,6 +399,7 @@ STAGING_KERNEL_DIR = ${STAGING_DIR_HOST}/usr/src/kernel
##
IMAGE_ROOTFS = ${WORKDIR}/rootfs
+IMAGE_ROOTFS_DBG = ${IMAGE_ROOTFS}.debug
IMAGE_BASENAME = ${PN}
IMAGE_NAME = ${IMAGE_BASENAME}-${MACHINE}-${DATETIME}
IMAGE_LINK_NAME = ${IMAGE_BASENAME}-${MACHINE}
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] galago: remove
Galago has been replaced with Telepathy and Folks, and has been unmaintained for
years.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../galago/galago-daemon_0.5.1.bb | 18
.../galago/libgalago-0.5.2/mkdir.patch | 29
.../galago/libgalago-0.5.2/pkgconfig.patch | 16 ---
.../recipes-connectivity/galago/libgalago_0.5.2.bb | 29
.../packagegroups/packagegroup-sdk-gmae.inc|2 --
5 files changed, 94 deletions(-)
delete mode 100644 meta/recipes-connectivity/galago/galago-daemon_0.5.1.bb
delete mode 100644 meta/recipes-connectivity/galago/libgalago-0.5.2/mkdir.patch
delete mode 100644
meta/recipes-connectivity/galago/libgalago-0.5.2/pkgconfig.patch
delete mode 100644 meta/recipes-connectivity/galago/libgalago_0.5.2.bb
diff --git a/meta/recipes-connectivity/galago/galago-daemon_0.5.1.bb
b/meta/recipes-connectivity/galago/galago-daemon_0.5.1.bb
deleted file mode 100644
index 81a367d..000
--- a/meta/recipes-connectivity/galago/galago-daemon_0.5.1.bb
+++ /dev/null
@@ -1,18 +0,0 @@
-SUMMARY = Desktop presence framework
-DESCRIPTION = Galago is a desktop presence framework, designed to transmit
presence information between programs.
-HOMEPAGE = http://www.galago-project.org/;
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
-DEPENDS = libgalago dbus glib-2.0
-
-SRC_URI =
http://www.galago-project.org/files/releases/source/${BPN}/${BPN}-${PV}.tar.gz
-
-SRC_URI[md5sum] = fdb81f938f86f380b127158ebb542279
-SRC_URI[sha256sum] =
db42a0d1d0f8b069ea5ac1203207f9178f25ac1367f4910bd48547f5be1db4c2
-
-EXTRA_OECONF = --disable-binreloc --disable-check --disable-tests
-
-FILES_${PN} += ${datadir}/dbus-1/services/
-
-inherit autotools pkgconfig gettext
-
diff --git a/meta/recipes-connectivity/galago/libgalago-0.5.2/mkdir.patch
b/meta/recipes-connectivity/galago/libgalago-0.5.2/mkdir.patch
deleted file mode 100644
index 4f18686..000
--- a/meta/recipes-connectivity/galago/libgalago-0.5.2/mkdir.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: libgalago-0.5.2/po/Makefile.in.in
-===
libgalago-0.5.2.orig/po/Makefile.in.in 2006-06-06 09:59:17.0
+0100
-+++ libgalago-0.5.2/po/Makefile.in.in 2009-08-19 20:31:56.0 +0100
-@@ -29,7 +29,7 @@
- INSTALL = @INSTALL@
- INSTALL_DATA = @INSTALL_DATA@
- MKINSTALLDIRS = @MKINSTALLDIRS@
--mkinstalldirs = $(SHELL) `case $(MKINSTALLDIRS) in /*) echo
$(MKINSTALLDIRS) ;; *) echo $(MKINSTALLDIRS) ;; esac`
-+mkinstalldirs = $(MKINSTALLDIRS)
-
- CC = @CC@
- GMSGFMT = @GMSGFMT@
-Index: libgalago-0.5.2/configure.ac
-===
libgalago-0.5.2.orig/configure.ac 2009-08-19 20:30:56.0 +0100
-+++ libgalago-0.5.2/configure.ac 2009-08-19 20:31:28.0 +0100
-@@ -157,6 +157,9 @@
-
- AC_SUBST(CFLAGS)
-
-+MKINSTALLDIRS=mkdir -p
-+AC_SUBST(MKINSTALLDIRS)
-+
- dnl
- dnl # Output the Makefiles
- dnl
diff --git a/meta/recipes-connectivity/galago/libgalago-0.5.2/pkgconfig.patch
b/meta/recipes-connectivity/galago/libgalago-0.5.2/pkgconfig.patch
deleted file mode 100644
index 6fbf552..000
--- a/meta/recipes-connectivity/galago/libgalago-0.5.2/pkgconfig.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: libgalago-0.5.2/libgalago.pc.in
-===
libgalago-0.5.2.orig/libgalago.pc.in 2006-05-17 08:53:26.0
+0100
-+++ libgalago-0.5.2/libgalago.pc.in2008-03-19 22:34:16.0 +
-@@ -6,6 +6,7 @@
- Name: libgalago
- Description: Galago Association/Presence Communication Library
- Version: @VERSION@
--Libs: -L${libdir} -lgalago @PACKAGE_LIBS@
--Cflags: -I${includedir} @PACKAGE_CFLAGS@
-+Requires: dbus-1 glib-2.0 dbus-glib-1
-+Libs: -L${libdir} -lgalago
-+Cflags: -I${includedir}
-
diff --git a/meta/recipes-connectivity/galago/libgalago_0.5.2.bb
b/meta/recipes-connectivity/galago/libgalago_0.5.2.bb
deleted file mode 100644
index 2071952..000
--- a/meta/recipes-connectivity/galago/libgalago_0.5.2.bb
+++ /dev/null
@@ -1,29 +0,0 @@
-SUMMARY = Desktop presence framework
-DESCRIPTION = Galago is a desktop presence framework, designed to transmit
presence information between programs.
-HOMEPAGE = http://www.galago-project.org/;
-LICENSE = LGPLv2.1+
-LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34 \
-
file://libgalago/galago.h;endline=21;md5=141785cb9ec62067398dda136a7bb401
-
-DEPENDS = dbus glib-2.0 dbus-glib
-
-SRC_URI =
[OE-core] [PATCH v2] sanity.bbclass: Fix invalid test for network error
The test for network error in sanity.bbclass was negated. Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com --- meta/classes/sanity.bbclass |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index e2095dd..f2e9a74 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -174,7 +174,7 @@ def check_sanity_tmpdir_change(tmpdir, data): # Check that we can fetch from various network transports errmsg = check_connectivity(data) testmsg = testmsg + check_connectivity(data) -return testmsg, errmsg == +return testmsg, errmsg != def check_sanity_version_change(data): # Sanity checks to be done when SANITY_VERSION changes -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 7/8] OECore license fixes: meta/*
On Wed, 2011-12-07 at 11:34 -0800, Beth Flanagan wrote: From: Elizabeth Flanagan elizabeth.flana...@intel.com This is a quick audit of only the most obviously wrong licenses found within OECore. These fixes fall into four areas: - LICENSE field had incorrect format so that the parser choked - LICENSE field has a license with no version - LICENSE field was actually incorrect - LICENSE field has an imaginary license that didn't exist [...] diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.6.bb b/meta/recipes-extended/bzip2/bzip2_1.0.6.bb index f5b9ac1..14cd240 100644 --- a/meta/recipes-extended/bzip2/bzip2_1.0.6.bb +++ b/meta/recipes-extended/bzip2/bzip2_1.0.6.bb @@ -4,9 +4,9 @@ Huffman coding. Compression is generally considerably better than that achieved LZ77/LZ78-based compressors, and approaches the performance of the PPM family of statistical compressors. HOMEPAGE = http://www.bzip.org/; SECTION = console/utils -LICENSE = bzip2 +LICENSE = BSD-4-Clause This (and the corresponding change to busybox) doesn't seem quite right. Although it is true that the bzip2 licence does have four clauses and is approximately BSD-ish, these four clauses are not actually the same as the ones in the traditional 4-clause BSD licence. The four clauses that the bzip2 licence actually has are (to quote LICENSE): 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 3. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 4. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. Whereas, the four clauses from the original BSD are: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the organization. 4. Neither the name of the organization nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. Clauses 1 and 4 are clearly the same thing (or very nearly identical) but clauses 2 and 3 are significantly different in both wording and intent. In particular the bzip2 license contains no equivalent to the objectionable advertising clause. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libdrm: Remove Cairo dependency
On Mon, 2012-10-01 at 13:04 +0100, Burton, Ross wrote: On 1 October 2012 13:02, Martin Jansa martin.ja...@gmail.com wrote: shouldn't we disable that example explicitly, so that the output is not different when cairo gets built before libdrm? The test (tests/modetest/) is noinst, so the output doesn't actually change. Shouldn't we just disable the things to gain a small bit of build speed if they don't matter? :) 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] libdrm: Remove Cairo dependency
On 2 October 2012 11:56, Richard Purdie richard.pur...@linuxfoundation.org wrote: Shouldn't we just disable the things to gain a small bit of build speed if they don't matter? :) That means carrying a patch and the maintenance burden when upgrading. I'm not entirely sure you'll notice all ten lines of Cairo code being compiled if cairo happens to be installed when libdrm2 builds. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] opkg-native: remove spurious dependency on curl-native
On Mon, 2012-10-01 at 16:52 +0100, Phil Blundell wrote: All variants of opkg are currently configured --disable-curl so there seems no point in depending on it. Signed-off-by: Phil Blundell ph...@gnu.org --- meta/recipes-devtools/opkg/opkg.inc |2 -- 1 file changed, 2 deletions(-) diff --git a/meta/recipes-devtools/opkg/opkg.inc b/meta/recipes-devtools/opkg/opkg.inc index 10cd9d8..28cc6a6 100644 --- a/meta/recipes-devtools/opkg/opkg.inc +++ b/meta/recipes-devtools/opkg/opkg.inc @@ -7,8 +7,6 @@ BUGTRACKER = http://code.google.com/p/opkg/issues/list; LICENSE = GPLv2+ LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ file://src/opkg-cl.c;beginline=1;endline=20;md5=321f658c3f6b6c832e25c8850b5dffba -DEPENDS_virtclass-native = curl-native -DEPENDS_virtclass-nativesdk = nativesdk-curl I merged this and took the reminder to remove the opkg-nogpg recipe since the main opkg recipe also has gpg disabled these days... 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] libdrm: Remove Cairo dependency
On Tue, 2012-10-02 at 11:58 +0100, Burton, Ross wrote: On 2 October 2012 11:56, Richard Purdie richard.pur...@linuxfoundation.org wrote: Shouldn't we just disable the things to gain a small bit of build speed if they don't matter? :) That means carrying a patch and the maintenance burden when upgrading. I'm not entirely sure you'll notice all ten lines of Cairo code being compiled if cairo happens to be installed when libdrm2 builds. I don't feel strongly about it but it sounds like the kind of thing it would be useful to switch off and upstream would probably take such a 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] rootfs_ipk, image: Add debug capture support
On Tue, 2012-10-02 at 10:20 +0100, Phil Blundell wrote:
If ${IMAGE_BUILD_DEBUG} is set, construct a parallel tree containing
the debug data for the packages that have been installed in the
rootfs, then tar it up and deploy it alongside the rootfs images.
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/classes/image.bbclass |9 +
meta/classes/rootfs_ipk.bbclass | 15 +++
meta/conf/bitbake.conf |1 +
3 files changed, 25 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index ab212b3..c82fba1 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -445,3 +445,12 @@ do_package_write_deb[noexec] = 1
do_package_write_rpm[noexec] = 1
addtask rootfs before do_build
+
+fakeroot do_capture_debug() {
+ if [ ${IMAGE_BUILD_DEBUG} = 1 -a -n ${IMAGE_ROOTFS_DBG} -a -d
${IMAGE_ROOTFS_DBG} ]; then
+ tar czf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.debug.tar.gz -C
${IMAGE_ROOTFS_DBG} .
+ [ ${IMAGE_NAME} == ${IMAGE_LINK_NAME} ] || ln -sf
${IMAGE_NAME}.debug.tar.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.debug.tar.gz
+ fi
+}
+
+addtask capture_debug before do_build after do_rootfs
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index 46e8d60..e4e74dd 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -9,6 +9,8 @@ EXTRAOPKGCONFIG ?=
ROOTFS_PKGMANAGE = opkg opkg-collateral ${EXTRAOPKGCONFIG}
ROOTFS_PKGMANAGE_BOOTSTRAP = run-postinsts
+IMAGE_BUILD_DEBUG ?= 0
+
do_rootfs[depends] += opkg-native:do_populate_sysroot
opkg-utils-native:do_populate_sysroot
do_rootfs[recrdeptask] += do_package_write_ipk
@@ -17,6 +19,7 @@ do_rootfs[lockfiles] += ${WORKDIR}/ipk.lock
IPKG_ARGS = -f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite
# The _POST version also works when constructing the matching SDK
IPKG_ARGS_POST = -f ${IPKGCONF_TARGET} -o $INSTALL_ROOTFS_IPK
--force-overwrite
+IPKG_ARGS_DBG = -f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS_DBG}
--force-overwrite
OPKG_PREPROCESS_COMMANDS = package_update_index_ipk;
package_generate_ipkg_conf
@@ -88,6 +91,18 @@ fakeroot rootfs_ipk_do_rootfs () {
fi
fi
+ if [ ${IMAGE_BUILD_DEBUG} = 1 -a -n ${IMAGE_ROOTFS_DBG} ]; then
+ all_pkgs=`opkg-cl ${IPKG_ARGS} list-installed | awk '{ print $1
}'`
+ [ ${IMAGE_ROOTFS_DBG} -ef ${IMAGE_ROOTFS} ] || rm -rf
${IMAGE_ROOTFS_DBG}
+ mkdir -p ${IMAGE_ROOTFS_DBG}${opkglibdir}
+ opkg-cl ${IPKG_ARGS_DBG} update
+ for p in $all_pkgs; do
+ if [ `opkg-cl ${IPKG_ARGS_DBG} info $p-dbg` != ];
then
+ opkg-cl ${IPKG_ARGS_DBG} --nodeps install $p-dbg
+ fi
+ done
+ fi
+
install -d ${IMAGE_ROOTFS}/${sysconfdir}
echo ${BUILDNAME} ${IMAGE_ROOTFS}/${sysconfdir}/version
Hasn't Paul added a general mechanism for doing this so we could add
this feature a level higher so that it could be used by all packaging
formats?
I'm a little concerned that the different backends are getting totally
different sets of features at this point. In some cases we have very
good reasons for it but that doesn't appear to be the case here.
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] rootfs_ipk, image: Add debug capture support
On Tue, 2012-10-02 at 12:12 +0100, Richard Purdie wrote: Hasn't Paul added a general mechanism for doing this so we could add this feature a level higher so that it could be used by all packaging formats? Ah, possibly. I'll have a look. Can you give me a pointer to the mechanism you were thinking of? thanks p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rootfs_ipk, image: Add debug capture support
On Tue, 2012-10-02 at 12:15 +0100, Phil Blundell wrote: On Tue, 2012-10-02 at 12:12 +0100, Richard Purdie wrote: Hasn't Paul added a general mechanism for doing this so we could add this feature a level higher so that it could be used by all packaging formats? Ah, possibly. I'll have a look. Can you give me a pointer to the mechanism you were thinking of? Something like IMAGE_FEATURES += dbg-pkgs should trigger the addition of dbg packages. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] opkg: Convert select-higher-version option to prefer-arch-to-version
This converts the option to maintain the existing behaviour unless the option is
specified. We do specify the option during the builds themselves to ensure what
the users expects is built.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index 019bd7c..4bf1b10 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -139,7 +139,7 @@ package_install_internal_ipk() {
mkdir -p ${target_rootfs}${localstatedir}/lib/opkg/
- local ipkg_args=-f ${conffile} -o ${target_rootfs} --force-overwrite
--force_postinstall
+ local ipkg_args=-f ${conffile} -o ${target_rootfs} --force-overwrite
--force_postinstall --prefer-arch-to-version
opkg-cl ${ipkg_args} update
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index 46e8d60..9d716fb 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -14,9 +14,9 @@ do_rootfs[recrdeptask] += do_package_write_ipk
do_rootfs[lockfiles] += ${WORKDIR}/ipk.lock
-IPKG_ARGS = -f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite
+IPKG_ARGS = -f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite
--prefer-arch-to-version
# The _POST version also works when constructing the matching SDK
-IPKG_ARGS_POST = -f ${IPKGCONF_TARGET} -o $INSTALL_ROOTFS_IPK
--force-overwrite
+IPKG_ARGS_POST = -f ${IPKGCONF_TARGET} -o $INSTALL_ROOTFS_IPK
--force-overwrite --prefer-arch-to-version
OPKG_PREPROCESS_COMMANDS = package_update_index_ipk;
package_generate_ipkg_conf
diff --git a/meta/recipes-devtools/opkg/opkg/0008-select_higher_version.patch
b/meta/recipes-devtools/opkg/opkg/0008-select_higher_version.patch
index 46d11b0..a9b039c 100644
--- a/meta/recipes-devtools/opkg/opkg/0008-select_higher_version.patch
+++ b/meta/recipes-devtools/opkg/opkg/0008-select_higher_version.patch
@@ -1,12 +1,9 @@
-Add the --select-higher-version option
+Add the --prefer-arch-to-version option
If there were more than one candidate which had the same pkg name in the
candidate list, for example, the same pkg with different versions, then
it would use the last one which was the highest version one in the past,
-but it will use the higher arch priority one now.
-
-Add the --select-higher-version option to let it use the higher
-version package when enabled. the default is no.
+but it will use the higher arch priority when this option is specified.
Upstream-Status: Pending
@@ -24,7 +21,7 @@ diff --git a/libopkg/opkg_conf.h b/libopkg/opkg_conf.h
int force_removal_of_essential_packages;
int force_postinstall;
int force_remove;
-+ int select_higher_version;
++ int prefer_arch_to_version;
int check_signature;
int nodeps; /* do not follow dependencies */
char *offline_root;
@@ -44,7 +41,7 @@ diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
+ break;
+ }
+ /* Respect to the arch priorities when given alternatives */
-+ if (good_pkg_by_name !conf-select_higher_version) {
++ if (good_pkg_by_name conf-prefer_arch_to_version) {
+ if (matching-arch_priority =
good_pkg_by_name-arch_priority) {
+ good_pkg_by_name = matching;
+ opkg_msg(DEBUG, %s %s wins by priority.\n,
@@ -64,7 +61,7 @@ diff --git a/src/opkg-cl.c b/src/opkg-cl.c
ARGS_OPT_FORCE_SPACE,
ARGS_OPT_FORCE_POSTINSTALL,
ARGS_OPT_FORCE_REMOVE,
-+ ARGS_OPT_SELECT_HIGHER_VERSION,
++ ARGS_OPT_PREFER_ARCH_TO_VERSION,
ARGS_OPT_ADD_ARCH,
ARGS_OPT_ADD_DEST,
ARGS_OPT_NOACTION,
@@ -72,8 +69,8 @@ diff --git a/src/opkg-cl.c b/src/opkg-cl.c
{force_postinstall, 0, 0, ARGS_OPT_FORCE_POSTINSTALL},
{force-remove, 0, 0, ARGS_OPT_FORCE_REMOVE},
{force_remove, 0, 0, ARGS_OPT_FORCE_REMOVE},
-+ {select-higher-version, 0, 0, ARGS_OPT_SELECT_HIGHER_VERSION},
-+ {select_higher_version, 0, 0, ARGS_OPT_SELECT_HIGHER_VERSION},
++ {prefer-arch-to-version, 0, 0, ARGS_OPT_PREFER_ARCH_TO_VERSION},
++ {prefer-arch-to-version, 0, 0, ARGS_OPT_PREFER_ARCH_TO_VERSION},
{noaction, 0, 0, ARGS_OPT_NOACTION},
{download-only, 0, 0, ARGS_OPT_DOWNLOAD_ONLY},
{nodeps, 0, 0, ARGS_OPT_NODEPS},
@@ -81,8 +78,8 @@ diff --git a/src/opkg-cl.c b/src/opkg-cl.c
case ARGS_OPT_FORCE_REMOVE:
conf-force_remove = 1;
break;
-+ case ARGS_OPT_SELECT_HIGHER_VERSION:
-+ conf-select_higher_version = 1;
++ case ARGS_OPT_PREFER_ARCH_TO_VERSION:
++ conf-prefer_arch_to_version = 1;
+ break;
case ARGS_OPT_NODEPS:
conf-nodeps = 1;
@@ -91,8 +88,8 @@ diff --git a/src/opkg-cl.c b/src/opkg-cl.c
[OE-core] [PATCH] scripts/oe-buildenv-internal: Ensure we detect the SDK/ADT and error out
The SDK/ADT may ship with a python installed which may not have all the modules need for a bitbake build. We should therefore detect if its already present in the environment and error out in this case, asking the user to use a clean environment. This also removes the potential for any other conflict between the two. [YOCTO #2979] Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index 32c0ba0..01fffba 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -24,6 +24,11 @@ if [ -z $OEROOT ]; then return 1 fi +if [ ! -z $OECORE_SDK_VERSION ]; then +echo 2 Error: The OE SDK/ADT was detected as already being present in this shell environment. Please use a clean shell when sourcing this environment script. +return 1 +fi + if [ x$BDIR = x ]; then if [ x$1 = x ]; then BDIR=build ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf: Add chrpath-native to ASSUME_PROVIDED
We assume chrpath is provided natively so it should be listed in
ASSUME_PROVIDED.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index e168ef1..c049b29 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -161,6 +161,7 @@ DATETIME = ${DATE}${TIME}
# its own in staging
ASSUME_PROVIDED = \
bzip2-native \
+chrpath-native \
git-native \
grep-native \
diffstat-native \
@@ -170,6 +171,7 @@ ASSUME_PROVIDED = \
tar-native \
virtual/libintl-native \
+# gzip-native should be listed above?
##
# Package default variables.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gzip: The native version should provide gzip-replacement-native
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-extended/gzip/gzip_1.5.bb
b/meta/recipes-extended/gzip/gzip_1.5.bb
index 7a811e2..2c6917d 100644
--- a/meta/recipes-extended/gzip/gzip_1.5.bb
+++ b/meta/recipes-extended/gzip/gzip_1.5.bb
@@ -2,6 +2,7 @@ require gzip.inc
PR = r0
+PROVIDES_append_virtclass-native = gzip-replacement-native
NATIVE_PACKAGE_PATH_SUFFIX = /${PN}
BBCLASSEXTEND = native
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] chrpath: We should provide chrpath-replacement-native and install into a native specific directory
chrpath is assumed to be provided by the build host system. This means
we need to provide a replacement version and install into a specific directory
to avoid races.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-devtools/chrpath/chrpath_0.14.bb
b/meta/recipes-devtools/chrpath/chrpath_0.14.bb
index 679f1aa..bb9b4b6 100644
--- a/meta/recipes-devtools/chrpath/chrpath_0.14.bb
+++ b/meta/recipes-devtools/chrpath/chrpath_0.14.bb
@@ -20,4 +20,7 @@ inherit autotools
# relocatable, so use the one we've just built
CHRPATH_BIN_virtclass-native = ${S}/chrpath
+PROVIDES_append_virtclass-native = chrpath-replacement-native
+NATIVE_PACKAGE_PATH_SUFFIX = /${PN}
+
BBCLASSEXTEND = native nativesdk
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] nativesdk.bbclass: Ensure we have chrpath =0.14
Versions earlier than 0.14 can't cope with 32 bit binaries on a 64 bit
system and vice versa. This results in problems for certain SDKMACHINE
combinations on certain hosts. By ensuring we build
chrpath-replacement-native we avoid this problems and the binaries work
correctly.
[YOCTO #3161]
[YOCTO #3201]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 3334817..e2971d1 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -16,6 +16,13 @@ CLASSOVERRIDE = class-nativesdk
PACKAGE_ARCH = ${SDK_ARCH}-nativesdk
PACKAGE_ARCHS = ${SDK_PACKAGE_ARCHS}
+#
+# We need chrpath = 0.14 to ensure we can deal with 32 and 64 bit
+# binaries
+#
+DEPENDS_append = chrpath-replacement-native
+EXTRANATIVEPATH += chrpath-native
+
STAGING_DIR_HOST = ${STAGING_DIR}/${MULTIMACH_HOST_SYS}
STAGING_DIR_TARGET = ${STAGING_DIR}/${MULTIMACH_TARGET_SYS}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rootfs_ipk, image: Add debug capture support
On Tue, Oct 2, 2012 at 8:38 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2012-10-02 at 12:15 +0100, Phil Blundell wrote: On Tue, 2012-10-02 at 12:12 +0100, Richard Purdie wrote: Hasn't Paul added a general mechanism for doing this so we could add this feature a level higher so that it could be used by all packaging formats? Ah, possibly. I'll have a look. Can you give me a pointer to the mechanism you were thinking of? Something like IMAGE_FEATURES += dbg-pkgs should trigger the addition of dbg packages. Or IMAGE_FEATURES += dbg-img ;-) -- 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
Re: [OE-core] [PATCH] rootfs_ipk, image: Add debug capture support
On Tue, 2012-10-02 at 12:38 +0100, Richard Purdie wrote: On Tue, 2012-10-02 at 12:15 +0100, Phil Blundell wrote: On Tue, 2012-10-02 at 12:12 +0100, Richard Purdie wrote: Hasn't Paul added a general mechanism for doing this so we could add this feature a level higher so that it could be used by all packaging formats? Ah, possibly. I'll have a look. Can you give me a pointer to the mechanism you were thinking of? Something like IMAGE_FEATURES += dbg-pkgs should trigger the addition of dbg packages. Ah yes, I see it. It looks like that will cause the debug packages to go into the rootfs itself, rather than a parallel tree, but I guess I can probably arrange to fish them back out again before the image is built. thanks p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rootfs_ipk, image: Add debug capture support
On Tue, Oct 2, 2012 at 10:51 AM, Phil Blundell ph...@gnu.org wrote: On Tue, 2012-10-02 at 10:42 -0300, Otavio Salvador wrote: Or IMAGE_FEATURES += dbg-img ;-) Where is that implemented? I couldn't find any obvious reference to dbg-img in any classes. Sorry by cause a missunderstanding ... I was just pointing to a possible new feature you could add. -- 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
Re: [OE-core] [PATCH] rootfs_ipk, image: Add debug capture support
On 10/02/12 15:53, Otavio Salvador wrote: On Tue, Oct 2, 2012 at 10:51 AM, Phil Blundell ph...@gnu.org wrote: On Tue, 2012-10-02 at 10:42 -0300, Otavio Salvador wrote: Or IMAGE_FEATURES += dbg-img ;-) Where is that implemented? I couldn't find any obvious reference to dbg-img in any classes. Sorry by cause a missunderstanding ... I was just pointing to a possible new feature you could add. that feature is already implemented though, in dbg-pkgs. If you don't mean dbg-img should do something other/more than what dbg-pkgs does? - Martin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rootfs_ipk, image: Add debug capture support
On Tue, Oct 2, 2012 at 10:52 AM, Martin Ertsås mert...@cisco.com wrote: On 10/02/12 15:53, Otavio Salvador wrote: On Tue, Oct 2, 2012 at 10:51 AM, Phil Blundell ph...@gnu.org wrote: On Tue, 2012-10-02 at 10:42 -0300, Otavio Salvador wrote: Or IMAGE_FEATURES += dbg-img ;-) Where is that implemented? I couldn't find any obvious reference to dbg-img in any classes. Sorry by cause a missunderstanding ... I was just pointing to a possible new feature you could add. that feature is already implemented though, in dbg-pkgs. If you don't mean dbg-img should do something other/more than what dbg-pkgs does? To build a separated tar with the symbols, not on the image itself. -- 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
Re: [OE-core] [PATCH] rootfs_ipk, image: Add debug capture support
On 10/02/12 15:59, Otavio Salvador wrote: On Tue, Oct 2, 2012 at 10:52 AM, Martin Ertsås mert...@cisco.com wrote: On 10/02/12 15:53, Otavio Salvador wrote: On Tue, Oct 2, 2012 at 10:51 AM, Phil Blundell ph...@gnu.org wrote: On Tue, 2012-10-02 at 10:42 -0300, Otavio Salvador wrote: Or IMAGE_FEATURES += dbg-img ;-) Where is that implemented? I couldn't find any obvious reference to dbg-img in any classes. Sorry by cause a missunderstanding ... I was just pointing to a possible new feature you could add. that feature is already implemented though, in dbg-pkgs. If you don't mean dbg-img should do something other/more than what dbg-pkgs does? To build a separated tar with the symbols, not on the image itself. With only the symbols? Or a separate image with symbols, side by side with the stripped one? In the later case you could just add a export IMAGE_BASENAME = my-dbg-image in the image recipe. If you mean with only the symbols I don't think we have any features for that right now. - Martin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rootfs_ipk, image: Add debug capture support
On Tue, Oct 2, 2012 at 10:57 AM, Martin Ertsås mert...@cisco.com wrote: On 10/02/12 15:59, Otavio Salvador wrote: On Tue, Oct 2, 2012 at 10:52 AM, Martin Ertsås mert...@cisco.com wrote: On 10/02/12 15:53, Otavio Salvador wrote: On Tue, Oct 2, 2012 at 10:51 AM, Phil Blundell ph...@gnu.org wrote: On Tue, 2012-10-02 at 10:42 -0300, Otavio Salvador wrote: Or IMAGE_FEATURES += dbg-img ;-) Where is that implemented? I couldn't find any obvious reference to dbg-img in any classes. Sorry by cause a missunderstanding ... I was just pointing to a possible new feature you could add. that feature is already implemented though, in dbg-pkgs. If you don't mean dbg-img should do something other/more than what dbg-pkgs does? To build a separated tar with the symbols, not on the image itself. With only the symbols? Or a separate image with symbols, side by side with the stripped one? In the later case you could just add a export IMAGE_BASENAME = my-dbg-image in the image recipe. If you mean with only the symbols I don't think we have any features for that right now. I thought it being side by side. -- 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
Re: [OE-core] [PATCH] xserver-xorg: Remove RCONFLICTS against xserver-xorg
On 09/28/2012 06:31 AM, Otavio Salvador wrote:
When merging the xserver-xorg fix the to use RDEPENDS in
xserver-xorg-module-exa the RCONFLICTS has not been removed by
mistake. This drops the RCONFLICTS to properly fix it.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
.../recipes-graphics/xorg-xserver/xserver-xorg.inc |1 -
.../xorg-xserver/xserver-xorg_1.11.2.bb|2 +-
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 9b474de..bea0252 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -66,7 +66,6 @@ PACKAGES =+ ${PN}-security-policy \
RRECOMMENDS_${PN} += ${PN}-security-policy xkeyboard-config rgb
xserver-xf86-config
RDEPENDS_${PN}-xvfb += xkeyboard-config
-RCONFLICTS_${PN}-module-exa = ${PN} ( ${EXTENDPKGV})
RDEPENDS_${PN}-module-exa = ${PN} (= ${EXTENDPKGV})
FILES_${PN} = ${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards
${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so
${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt
${datadir}/X11/xorg.conf.d
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.11.2.bb
b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.11.2.bb
index 2512fb2..a219f81 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.11.2.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.11.2.bb
@@ -10,4 +10,4 @@ SRC_URI += file://crosscompile.patch \
SRC_URI[md5sum] = 8796fff441e5435ee36a72579008af24
SRC_URI[sha256sum] =
fa415decf02027ca278b06254ccfbcceba2a83c2741405257ebf749da4a73cf2
-PR = r9
+PR = r10
Merged into OE-Core
Sorry about the original mis-merge!
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xorg: Remove RCONFLICTS against xserver-xorg
On Tue, Oct 2, 2012 at 11:47 AM, Saul Wold s...@linux.intel.com wrote: Merged into OE-Core Sorry about the original mis-merge! Thanks by merging both changes. mis-merge happens, good we found it fast :) -- 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
[OE-core] [PATCH] libart-lgpl: add art_config.h for mipsel
Fixes: WARNING: Unable to get checksum for libart-lgpl SRC_URI entry art_config.h: file could not be found which otherwise happens during parsing, even if libart-lgpl isn't being built. Signed-off-by: Phil Blundell ph...@gnu.org --- meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h diff --git a/meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h b/meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h new file mode 100644 index 000..b0e74ad --- /dev/null +++ b/meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h @@ -0,0 +1,10 @@ +/* Automatically generated by gen_art_config.c */ + +#define ART_SIZEOF_CHAR 1 +#define ART_SIZEOF_SHORT 2 +#define ART_SIZEOF_INT 4 +#define ART_SIZEOF_LONG 4 + +typedef unsigned char art_u8; +typedef unsigned short art_u16; +typedef unsigned int art_u32; -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3] opkg: fix version constraints in conflicts, depends, replaces
On 10/01/2012 04:41 AM, Martin Jansa wrote:
* http://code.google.com/p/opkg/issues/detail?id=94
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../0009-pkg_depends-fix-version-constraints.patch | 188 +
...depends-fix-version_constraints_satisfied.patch | 37
meta/recipes-devtools/opkg/opkg_svn.bb | 4 +-
3 files changed, 228 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/opkg/opkg/0009-pkg_depends-fix-version-constraints.patch
create mode 100644
meta/recipes-devtools/opkg/opkg/0010-pkg_depends-fix-version_constraints_satisfied.patch
Merged into OE-Core
Thanks
Sau!
diff --git
a/meta/recipes-devtools/opkg/opkg/0009-pkg_depends-fix-version-constraints.patch
b/meta/recipes-devtools/opkg/opkg/0009-pkg_depends-fix-version-constraints.patch
new file mode 100644
index 000..f7aa4ea
--- /dev/null
+++
b/meta/recipes-devtools/opkg/opkg/0009-pkg_depends-fix-version-constraints.patch
@@ -0,0 +1,188 @@
+From b93ce2249751e0d90dab38e91691a6e9f33c3512 Mon Sep 17 00:00:00 2001
+From: Martin Jansa martin.ja...@gmail.com
+Date: Sat, 29 Sep 2012 11:38:03 +0200
+Subject: [PATCH 09/10] pkg_depends: fix version constraints
+
+* factor parsing version constraint to str_to_constraint and use that
+ from pkg (pkg_version_satisfied) and also pkg_depends (parseDepends)
+* fix constraint_to_str(), for EARLIER and LATER it was using '' and
+ '' which is parsed later as EARLIER_EQUAL and LATER_EQUAL
+* show notice when deprecated '' or '' is used
+
+Upstream-Status: Submitted
+http://code.google.com/p/opkg/issues/detail?id=94
+
+Signed-off-by: Martin Jansa martin.ja...@gmail.com
+---
+ libopkg/pkg.c | 36 +++--
+ libopkg/pkg_depends.c | 73 +--
+ libopkg/pkg_depends.h | 1 +
+ 3 files changed, 59 insertions(+), 51 deletions(-)
+
+diff --git a/libopkg/pkg.c b/libopkg/pkg.c
+index 255c673..1e98b9c 100644
+--- a/libopkg/pkg.c
b/libopkg/pkg.c
+@@ -968,28 +968,24 @@ pkg_version_satisfied(pkg_t *it, pkg_t *ref, const char
*op)
+ int r;
+
+ r = pkg_compare_versions(it, ref);
++ char *op2 = op;
++ enum version_constraint constraint = str_to_constraint(op2);
+
+- if (strcmp(op, =) == 0 || strcmp(op, ) == 0) {
+-return r = 0;
+- }
+-
+- if (strcmp(op, =) == 0 || strcmp(op, ) == 0) {
+-return r = 0;
+- }
+-
+- if (strcmp(op, ) == 0) {
+-return r 0;
+- }
+-
+- if (strcmp(op, ) == 0) {
+-return r 0;
+- }
+-
+- if (strcmp(op, =) == 0) {
+-return r == 0;
++ switch (constraint)
++ {
++ case EARLIER_EQUAL:
++ return r = 0;
++ case LATER_EQUAL:
++ return r = 0;
++ case EARLIER:
++ return r 0;
++ case LATER:
++ return r 0;
++ case EQUAL:
++ return r == 0;
++ case NONE:
++ opkg_msg(ERROR, Unknown operator: %s.\n, op);
+ }
+-
+- opkg_msg(ERROR, Unknown operator: %s.\n, op);
+ return 0;
+ }
+
+diff --git a/libopkg/pkg_depends.c b/libopkg/pkg_depends.c
+index a72eed7..3dd8240 100644
+--- a/libopkg/pkg_depends.c
b/libopkg/pkg_depends.c
+@@ -781,7 +781,7 @@ constraint_to_str(enum version_constraint c)
+ case NONE:
+ return ;
+ case EARLIER:
+- return ;
++ return ;
+ case EARLIER_EQUAL:
+ return = ;
+ case EQUAL:
+@@ -789,12 +789,51 @@ constraint_to_str(enum version_constraint c)
+ case LATER_EQUAL:
+ return = ;
+ case LATER:
+- return ;
++ return ;
+ }
+
+ return ;
+ }
+
++enum version_constraint
++str_to_constraint(char **str)
++{
++ if(!strncmp(*str, , 2)){
++ *str += 2;
++ return EARLIER;
++ }
++ else if(!strncmp(*str, =, 2)){
++ *str += 2;
++ return EARLIER_EQUAL;
++ }
++ else if(!strncmp(*str, =, 2)){
++ *str += 2;
++ return LATER_EQUAL;
++ }
++ else if(!strncmp(*str, , 2)){
++ *str += 2;
++ return LATER;
++ }
++ else if(!strncmp(*str, =, 1)){
++ *str += 1;
++ return EQUAL;
++ }
++ /* should these be here to support deprecated designations; dpkg does */
++ else if(!strncmp(*str, , 1)){
++ *str += 1;
++ opkg_msg(NOTICE, Deprecated version constraint '' was used with the same
meaning as '='. Use '' for EARLIER constraint.\n);
++ return EARLIER_EQUAL;
++ }
++ else if(!strncmp(*str, , 1)){
++ *str += 1;
++ opkg_msg(NOTICE, Deprecated version constraint '' was used with the same
meaning as '='. Use '' for LATER constraint.\n);
++ return LATER_EQUAL;
++ }
++ else {
++ return NONE;
++ }
++}
++
+ /*
+ * Returns a printable string for pkg's
Re: [OE-core] [PATCH] opkg: Don't call sync() when installing into an offline root
On 09/29/2012 05:20 AM, Phil Blundell wrote:
Even when installing onto a live target system, calling sync() during
package installation is of somewhat questionable benefit. But calling
it on the build host during rootfs construction is certainly useless and
can cause I/O to stall for several seconds on even a moderately sized
host which is clearly not desirable.
(From a patch originally by Mike Crowe.)
Signed-off-by: Phil Blundell ph...@gnu.org
---
.../opkg/opkg/opkg-no-sync-offline.patch | 18 ++
meta/recipes-devtools/opkg/opkg_svn.bb |3 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-devtools/opkg/opkg/opkg-no-sync-offline.patch
diff --git a/meta/recipes-devtools/opkg/opkg/opkg-no-sync-offline.patch
b/meta/recipes-devtools/opkg/opkg/opkg-no-sync-offline.patch
new file mode 100644
index 000..b1b3453
--- /dev/null
+++ b/meta/recipes-devtools/opkg/opkg/opkg-no-sync-offline.patch
@@ -0,0 +1,18 @@
+When installing into an offline root, calling sync() is pointless and just
+hurts performance. Don't let's do that.
+
+Signed-off-by: Phil Blundell ph...@gnu.org
+Upstream-Status: Pending
+
+--- a/libopkg/opkg_cmd.c 2011-09-08 10:53:07.0 +0100
b/libopkg/opkg_cmd.c 2011-10-04 10:45:22.278615584 +0100
+@@ -64,7 +64,8 @@ write_status_files_if_changed(void)
+ opkg_msg(INFO, Writing status file.\n);
+ opkg_conf_write_status_files();
+ pkg_write_changed_filelists();
+-sync();
++if (!conf-offline_root)
++sync();
+ } else {
+ opkg_msg(DEBUG, Nothing to be done.\n);
+ }
diff --git a/meta/recipes-devtools/opkg/opkg_svn.bb
b/meta/recipes-devtools/opkg/opkg_svn.bb
index 820a224..f206cd5 100644
--- a/meta/recipes-devtools/opkg/opkg_svn.bb
+++ b/meta/recipes-devtools/opkg/opkg_svn.bb
@@ -9,6 +9,7 @@ SRC_URI =
svn://opkg.googlecode.com/svn;module=trunk;protocol=http \
file://0006-detect-circular-dependencies.patch \
file://0007-merge-newpkg-provides-even-when-oldpkg-provides-exis.patch \
file://0008-select_higher_version.patch \
+ file://opkg-no-sync-offline.patch \
S = ${WORKDIR}/trunk
@@ -16,4 +17,4 @@ S = ${WORKDIR}/trunk
SRCREV = 633
PV = 0.1.8+svnr${SRCPV}
-PR = ${INC_PR}.4
+PR = ${INC_PR}.5
Merged into OE-Core (with additional PR bump)
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 7/8] OECore license fixes: meta/*
On Tue, Oct 2, 2012 at 3:46 AM, Phil Blundell ph...@gnu.org wrote: This (and the corresponding change to busybox) doesn't seem quite right. Although it is true that the bzip2 licence does have four clauses and is approximately BSD-ish, these four clauses are not actually the same as the ones in the traditional 4-clause BSD licence. That's correct, thanks for the catch. When I was going through these, I relied on a lot on what others had listed the package as. OBS lists it as BSD (3 clause I believe). Gentoo lists it as bzip2. I dislike having singular licenses but in this case, due to clause 2 and 3, the correct path here is to change it back to bzip2, add the bzip2 text to the license directory and then email the bzip2 developers and ask them if BSD-4-clause is appropriate or not. I'll do that today. -b The four clauses that the bzip2 licence actually has are (to quote LICENSE): 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 3. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 4. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. Whereas, the four clauses from the original BSD are: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the organization. 4. Neither the name of the organization nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. Clauses 1 and 4 are clearly the same thing (or very nearly identical) but clauses 2 and 3 are significantly different in both wording and intent. In particular the bzip2 license contains no equivalent to the objectionable advertising clause. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Elizabeth Flanagan Yocto Project Build and Release ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gypsy: package removed from meta
Removed package from meta/recipes-connectivity and also all the dependencies
reffering to it.
Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com
---
meta-yocto/conf/distro/include/maintainers.inc |1 -
.../distro/include/poky-floating-revisions.inc |1 -
meta/recipes-connectivity/gypsy/files/fixups.patch | 21 -
meta/recipes-connectivity/gypsy/gypsy.inc | 15
meta/recipes-connectivity/gypsy/gypsy_0.9.bb | 24
meta/recipes-connectivity/gypsy/gypsy_git.bb | 18 ---
.../packagegroups/packagegroup-sdk-gmae.inc|1 -
7 files changed, 81 deletions(-)
delete mode 100644 meta/recipes-connectivity/gypsy/files/fixups.patch
delete mode 100644 meta/recipes-connectivity/gypsy/gypsy.inc
delete mode 100644 meta/recipes-connectivity/gypsy/gypsy_0.9.bb
delete mode 100644 meta/recipes-connectivity/gypsy/gypsy_git.bb
diff --git a/meta-yocto/conf/distro/include/maintainers.inc
b/meta-yocto/conf/distro/include/maintainers.inc
index 38b6974..288557b 100644
--- a/meta-yocto/conf/distro/include/maintainers.inc
+++ b/meta-yocto/conf/distro/include/maintainers.inc
@@ -225,7 +225,6 @@ RECIPE_MAINTAINER_pn-guile = Bogdan Marinescu
bogdan.a.marine...@intel.com
RECIPE_MAINTAINER_pn-gupnp = Radu Moisan radu.moi...@intel.com
RECIPE_MAINTAINER_pn-gupnp-av = Cristian Iorga cristian.io...@intel.com
RECIPE_MAINTAINER_pn-gupnp-tools = Cristian Iorga cristian.io...@intel.com
-RECIPE_MAINTAINER_pn-gypsy = Cristian Iorga cristian.io...@intel.com
RECIPE_MAINTAINER_pn-gzip = Scott Garman scott.a.gar...@intel.com
RECIPE_MAINTAINER_pn-hal = Saul Wold s...@linux.intel.com
RECIPE_MAINTAINER_pn-hal-info = Saul Wold s...@linux.intel.com
diff --git a/meta-yocto/conf/distro/include/poky-floating-revisions.inc
b/meta-yocto/conf/distro/include/poky-floating-revisions.inc
index af8ef11..6f6ee90 100644
--- a/meta-yocto/conf/distro/include/poky-floating-revisions.inc
+++ b/meta-yocto/conf/distro/include/poky-floating-revisions.inc
@@ -45,7 +45,6 @@ SRCREV_pn-xvideo-tests ?= ${AUTOREV}
SRCREV_pn-clutter ?= ${AUTOREV}
SRCREV_pn-clutter-gst ?= ${AUTOREV}
SRCREV_pn-gaku ?= ${AUTOREV}
-SRCREV_pn-gypsy ?= ${AUTOREV}
#SRCREV_pn-webkit-gtk ?= ${AUTOREV}
SRCREV_pn-aaina ?= ${AUTOREV}
SRCREV_pn-clutter-cairo ?= ${AUTOREV}
diff --git a/meta/recipes-connectivity/gypsy/files/fixups.patch
b/meta/recipes-connectivity/gypsy/files/fixups.patch
deleted file mode 100644
index de4d92e..000
--- a/meta/recipes-connectivity/gypsy/files/fixups.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
- docs/reference/Makefile.am |2 ++
- 1 file changed, 2 insertions(+)
-
gypsy.orig/docs/reference/Makefile.am
-+++ gypsy/docs/reference/Makefile.am
-@@ -81,10 +81,12 @@ expand_content_files=
- # e.g. GTKDOC_LIBS=$(top_builddir)/gtk/$(gtktargetlib)
-
- INCLUDES=-I$(top_srcdir) $(GYPSY_CFLAGS)
- GTKDOC_LIBS=$(top_builddir)/gypsy/libgypsy.la $(GYPSY_LIBS)
-
-+EXTRA_DIST =
-+CLEANFILES =
- # This includes the standard gtk-doc make rules, copied by gtkdocize.
- include $(top_srcdir)/gtk-doc.make
-
- # Other files to distribute
- # e.g. EXTRA_DIST += version.xml.in
diff --git a/meta/recipes-connectivity/gypsy/gypsy.inc
b/meta/recipes-connectivity/gypsy/gypsy.inc
deleted file mode 100644
index 0c1735e..000
--- a/meta/recipes-connectivity/gypsy/gypsy.inc
+++ /dev/null
@@ -1,15 +0,0 @@
-SUMMARY = GPS Multiplexing Daemon
-DESCRIPTION = Gypsy is a GPS multiplexing daemon which allows \
-multiple clients to access GPS data from multiple GPS sources \
-concurrently. Gypsy also hides the details of parsing NMEA from the \
-client applications, passing the data as simple values for the clients \
-to use.
-LICENSE = GPLv2.0 LGPLv2.1
-SECTION = x11
-DEPENDS = glib-2.0 dbus bluez4 dbus-glib
-
-inherit autotools pkgconfig gtk-doc
-
-EXTRA_OECONF += --with-distro=debian
-
-FILES_${PN} += /usr/share/dbus-1/services/
diff --git a/meta/recipes-connectivity/gypsy/gypsy_0.9.bb
b/meta/recipes-connectivity/gypsy/gypsy_0.9.bb
deleted file mode 100644
index 51207c9..000
--- a/meta/recipes-connectivity/gypsy/gypsy_0.9.bb
+++ /dev/null
@@ -1,24 +0,0 @@
-SUMMARY = GPS Multiplexing Daemon
-DESCRIPTION = Gypsy is a GPS multiplexing daemon which allows \
-multiple clients to access GPS data from multiple GPS sources \
-concurrently. Gypsy also hides the details of parsing NMEA from the \
-client applications, passing the data as simple values for the clients \
-to use.
-LICENSE = GPLv2+ LGPLv2+
-LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
-file://COPYING.lib;md5=7fbc338309ac38fefcd64b04bb903e34 \
-
file://src/main.c;beginline=1;endline=25;md5=3fe64e27e61b289b77383a54a982cbdd \
-
file://gypsy/gypsy-time.h;beginline=1;endline=24;md5=06432ea19a7b6607428d04d9dadc37fd
-
-SECTION = x11
-DEPENDS = glib-2.0 dbus bluez4 dbus-glib
[OE-core] [PATCH] gypsy: moved to meta-oe/recipes-connectivty
Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com
---
...gypsy-m4-directory-missing-from-structure.patch | 23
.../recipes-connectivity/gypsy/files/fixups.patch | 21 ++
meta-oe/recipes-connectivity/gypsy/gypsy.inc | 15 +
meta-oe/recipes-connectivity/gypsy/gypsy_git.bb| 19
4 files changed, 78 insertions(+)
create mode 100644
meta-oe/recipes-connectivity/gypsy/files/0001-gypsy-m4-directory-missing-from-structure.patch
create mode 100644 meta-oe/recipes-connectivity/gypsy/files/fixups.patch
create mode 100644 meta-oe/recipes-connectivity/gypsy/gypsy.inc
create mode 100644 meta-oe/recipes-connectivity/gypsy/gypsy_git.bb
diff --git
a/meta-oe/recipes-connectivity/gypsy/files/0001-gypsy-m4-directory-missing-from-structure.patch
b/meta-oe/recipes-connectivity/gypsy/files/0001-gypsy-m4-directory-missing-from-structure.patch
new file mode 100644
index 000..5cb491b
--- /dev/null
+++
b/meta-oe/recipes-connectivity/gypsy/files/0001-gypsy-m4-directory-missing-from-structure.patch
@@ -0,0 +1,23 @@
+From 472c465dad27f79e8340e99c9f68cdfa9d2b1809 Mon Sep 17 00:00:00 2001
+From: Andrei Dinu andrei.adrianx.d...@intel.com
+Date: Tue, 2 Oct 2012 16:36:12 +0300
+Subject: [PATCH] gypsy : m4 directory missing from structure
+
+gypsy won't compile without the m4/ directory, so i created it.
+
+Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com
+---
+ m4/.gitignore |1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 m4/.gitignore
+
+diff --git a/m4/.gitignore b/m4/.gitignore
+new file mode 100644
+index 000..72e8ffc
+--- /dev/null
b/m4/.gitignore
+@@ -0,0 +1 @@
++*
+--
+1.7.9.5
+
diff --git a/meta-oe/recipes-connectivity/gypsy/files/fixups.patch
b/meta-oe/recipes-connectivity/gypsy/files/fixups.patch
new file mode 100644
index 000..de4d92e
--- /dev/null
+++ b/meta-oe/recipes-connectivity/gypsy/files/fixups.patch
@@ -0,0 +1,21 @@
+Upstream-Status: Inappropriate [configuration]
+
+---
+ docs/reference/Makefile.am |2 ++
+ 1 file changed, 2 insertions(+)
+
+--- gypsy.orig/docs/reference/Makefile.am
gypsy/docs/reference/Makefile.am
+@@ -81,10 +81,12 @@ expand_content_files=
+ # e.g. GTKDOC_LIBS=$(top_builddir)/gtk/$(gtktargetlib)
+
+ INCLUDES=-I$(top_srcdir) $(GYPSY_CFLAGS)
+ GTKDOC_LIBS=$(top_builddir)/gypsy/libgypsy.la $(GYPSY_LIBS)
+
++EXTRA_DIST =
++CLEANFILES =
+ # This includes the standard gtk-doc make rules, copied by gtkdocize.
+ include $(top_srcdir)/gtk-doc.make
+
+ # Other files to distribute
+ # e.g. EXTRA_DIST += version.xml.in
diff --git a/meta-oe/recipes-connectivity/gypsy/gypsy.inc
b/meta-oe/recipes-connectivity/gypsy/gypsy.inc
new file mode 100644
index 000..0c1735e
--- /dev/null
+++ b/meta-oe/recipes-connectivity/gypsy/gypsy.inc
@@ -0,0 +1,15 @@
+SUMMARY = GPS Multiplexing Daemon
+DESCRIPTION = Gypsy is a GPS multiplexing daemon which allows \
+multiple clients to access GPS data from multiple GPS sources \
+concurrently. Gypsy also hides the details of parsing NMEA from the \
+client applications, passing the data as simple values for the clients \
+to use.
+LICENSE = GPLv2.0 LGPLv2.1
+SECTION = x11
+DEPENDS = glib-2.0 dbus bluez4 dbus-glib
+
+inherit autotools pkgconfig gtk-doc
+
+EXTRA_OECONF += --with-distro=debian
+
+FILES_${PN} += /usr/share/dbus-1/services/
diff --git a/meta-oe/recipes-connectivity/gypsy/gypsy_git.bb
b/meta-oe/recipes-connectivity/gypsy/gypsy_git.bb
new file mode 100644
index 000..15f6c9b
--- /dev/null
+++ b/meta-oe/recipes-connectivity/gypsy/gypsy_git.bb
@@ -0,0 +1,19 @@
+require gypsy.inc
+
+DEFAULT_PREFERENCE = -1
+
+SRCREV = be8c9c382d2d1d37b51d29b0843045121ec90213
+PV = 0.8+git${SRCPV}
+PR = r2
+
+S = ${WORKDIR}/git
+
+LICENSE = GPLv2+ LGPLv2+
+LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
+file://COPYING.lib;md5=7fbc338309ac38fefcd64b04bb903e34 \
+
file://src/main.c;beginline=1;endline=25;md5=3fe64e27e61b289b77383a54a982cbdd \
+
file://gypsy/gypsy-time.h;beginline=1;endline=24;md5=06432ea19a7b6607428d04d9dadc37fd
+
+SRC_URI = git://anongit.freedesktop.org/gypsy;protocol=git \
+ file://fixups.patch \
+ file://0001-gypsy-m4-directory-missing-from-structure.patch
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] galago: remove
On 10/02/2012 02:43 AM, Ross Burton wrote:
Galago has been replaced with Telepathy and Folks, and has been unmaintained for
years.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../galago/galago-daemon_0.5.1.bb | 18
.../galago/libgalago-0.5.2/mkdir.patch | 29
.../galago/libgalago-0.5.2/pkgconfig.patch | 16 ---
.../recipes-connectivity/galago/libgalago_0.5.2.bb | 29
.../packagegroups/packagegroup-sdk-gmae.inc|2 --
5 files changed, 94 deletions(-)
delete mode 100644 meta/recipes-connectivity/galago/galago-daemon_0.5.1.bb
delete mode 100644
meta/recipes-connectivity/galago/libgalago-0.5.2/mkdir.patch
delete mode 100644
meta/recipes-connectivity/galago/libgalago-0.5.2/pkgconfig.patch
delete mode 100644 meta/recipes-connectivity/galago/libgalago_0.5.2.bb
Merged into OE-Core
Thanks
Sau!
diff --git a/meta/recipes-connectivity/galago/galago-daemon_0.5.1.bb
b/meta/recipes-connectivity/galago/galago-daemon_0.5.1.bb
deleted file mode 100644
index 81a367d..000
--- a/meta/recipes-connectivity/galago/galago-daemon_0.5.1.bb
+++ /dev/null
@@ -1,18 +0,0 @@
-SUMMARY = Desktop presence framework
-DESCRIPTION = Galago is a desktop presence framework, designed to transmit
presence information between programs.
-HOMEPAGE = http://www.galago-project.org/;
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
-DEPENDS = libgalago dbus glib-2.0
-
-SRC_URI =
http://www.galago-project.org/files/releases/source/${BPN}/${BPN}-${PV}.tar.gz
-
-SRC_URI[md5sum] = fdb81f938f86f380b127158ebb542279
-SRC_URI[sha256sum] =
db42a0d1d0f8b069ea5ac1203207f9178f25ac1367f4910bd48547f5be1db4c2
-
-EXTRA_OECONF = --disable-binreloc --disable-check --disable-tests
-
-FILES_${PN} += ${datadir}/dbus-1/services/
-
-inherit autotools pkgconfig gettext
-
diff --git a/meta/recipes-connectivity/galago/libgalago-0.5.2/mkdir.patch
b/meta/recipes-connectivity/galago/libgalago-0.5.2/mkdir.patch
deleted file mode 100644
index 4f18686..000
--- a/meta/recipes-connectivity/galago/libgalago-0.5.2/mkdir.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: libgalago-0.5.2/po/Makefile.in.in
-===
libgalago-0.5.2.orig/po/Makefile.in.in 2006-06-06 09:59:17.0
+0100
-+++ libgalago-0.5.2/po/Makefile.in.in 2009-08-19 20:31:56.0 +0100
-@@ -29,7 +29,7 @@
- INSTALL = @INSTALL@
- INSTALL_DATA = @INSTALL_DATA@
- MKINSTALLDIRS = @MKINSTALLDIRS@
--mkinstalldirs = $(SHELL) `case $(MKINSTALLDIRS) in /*) echo $(MKINSTALLDIRS) ;; *)
echo $(MKINSTALLDIRS) ;; esac`
-+mkinstalldirs = $(MKINSTALLDIRS)
-
- CC = @CC@
- GMSGFMT = @GMSGFMT@
-Index: libgalago-0.5.2/configure.ac
-===
libgalago-0.5.2.orig/configure.ac 2009-08-19 20:30:56.0 +0100
-+++ libgalago-0.5.2/configure.ac 2009-08-19 20:31:28.0 +0100
-@@ -157,6 +157,9 @@
-
- AC_SUBST(CFLAGS)
-
-+MKINSTALLDIRS=mkdir -p
-+AC_SUBST(MKINSTALLDIRS)
-+
- dnl
- dnl # Output the Makefiles
- dnl
diff --git a/meta/recipes-connectivity/galago/libgalago-0.5.2/pkgconfig.patch
b/meta/recipes-connectivity/galago/libgalago-0.5.2/pkgconfig.patch
deleted file mode 100644
index 6fbf552..000
--- a/meta/recipes-connectivity/galago/libgalago-0.5.2/pkgconfig.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: libgalago-0.5.2/libgalago.pc.in
-===
libgalago-0.5.2.orig/libgalago.pc.in 2006-05-17 08:53:26.0
+0100
-+++ libgalago-0.5.2/libgalago.pc.in2008-03-19 22:34:16.0 +
-@@ -6,6 +6,7 @@
- Name: libgalago
- Description: Galago Association/Presence Communication Library
- Version: @VERSION@
--Libs: -L${libdir} -lgalago @PACKAGE_LIBS@
--Cflags: -I${includedir} @PACKAGE_CFLAGS@
-+Requires: dbus-1 glib-2.0 dbus-glib-1
-+Libs: -L${libdir} -lgalago
-+Cflags: -I${includedir}
-
diff --git a/meta/recipes-connectivity/galago/libgalago_0.5.2.bb
b/meta/recipes-connectivity/galago/libgalago_0.5.2.bb
deleted file mode 100644
index 2071952..000
--- a/meta/recipes-connectivity/galago/libgalago_0.5.2.bb
+++ /dev/null
@@ -1,29 +0,0 @@
-SUMMARY = Desktop presence framework
-DESCRIPTION = Galago is a desktop presence framework, designed to transmit
presence information between programs.
-HOMEPAGE = http://www.galago-project.org/;
-LICENSE = LGPLv2.1+
-LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34 \
-
file://libgalago/galago.h;endline=21;md5=141785cb9ec62067398dda136a7bb401
-
-DEPENDS =
Re: [OE-core] [PATCH] gypsy: package removed from meta
On 2 October 2012 16:25, Andrei Dinu andrei.adrianx.d...@intel.com wrote: Removed package from meta/recipes-connectivity and also all the dependencies reffering to it. This patch should be split into two - one touching meta and the other touching meta-yocto (because the real repositories are oe-core for meta/ and meta-yocto for meta-yocto/). Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 10/10] libx11.inc: fix build issues for older CentOS distros
On Fri, Sep 28, 2012 at 10:03 AM, Matthew McClintock m...@freescale.com wrote: On Fri, Sep 28, 2012 at 9:52 AM, Burton, Ross ross.bur...@intel.com wrote: On 28 September 2012 02:33, Matthew McClintock m...@freescale.com wrote: Fixes these sorts of issues present on older gcc (CentOS 5.x in this case) | cc1: error: unrecognized command line option -Werror=implicit | cc1: error: unrecognized command line option -Werror=nonnull Took me a minute to realise why this happens. This happens when cross-building because although configure is checking that the flags it uses are supported by the compiler, it's only doing that for the cross and not the host compiler. Right? (upstream bug alert) Yea, I suppose the the host compiler should be checked by autotools if it supports these warning flags. Should this block applying this patch to oe-core or will there be upstream fixes before 1.3? -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 10/10] libx11.inc: fix build issues for older CentOS distros
On 2 October 2012 16:50, McClintock Matthew-B29882 b29...@freescale.com wrote: Yea, I suppose the the host compiler should be checked by autotools if it supports these warning flags. Should this block applying this patch to oe-core or will there be upstream fixes before 1.3? This is the right fix for the short term, fixing upstream is more complicated because they have the pain of Solaris to deal with. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Revert initrd: Spawn an emergency shell when something goes wrong
This had nowhere near enough testing...
This reverts commit ffb6928f5783e5202d9849c3a185e29be1d41c63.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-core/initrdscripts/files/init-live.sh | 11 ---
1 file changed, 11 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh
b/meta/recipes-core/initrdscripts/files/init-live.sh
index 2639308..5682fd1 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -2,17 +2,6 @@
PATH=/sbin:/bin:/usr/sbin:/usr/bin
-emergency_shell()
-{
-echo Bug in initramfs /init detected. Dropping to a shell. Good luck!
-echo
-sh
-}
-trap emergency_shell 0 2
-
-# exit immediately if a command fails
-set -e
-
ROOT_MOUNT=/rootfs/
ROOT_IMAGE=rootfs.img
MOUNT=/bin/mount
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 7/8] OECore license fixes: meta/*
On Tue, 2012-10-02 at 08:16 -0700, Flanagan, Elizabeth wrote: On Tue, Oct 2, 2012 at 3:46 AM, Phil Blundell ph...@gnu.org wrote: This (and the corresponding change to busybox) doesn't seem quite right. Although it is true that the bzip2 licence does have four clauses and is approximately BSD-ish, these four clauses are not actually the same as the ones in the traditional 4-clause BSD licence. That's correct, thanks for the catch. When I was going through these, I relied on a lot on what others had listed the package as. OBS lists it as BSD (3 clause I believe). Gentoo lists it as bzip2. I dislike having singular licenses but in this case, due to clause 2 and 3, the correct path here is to change it back to bzip2, add the bzip2 text to the license directory and then email the bzip2 developers and ask them if BSD-4-clause is appropriate or not. I'll do that today. If you're going to ask the maintainers about varying the license wording, it might be better to ask for BSD-3-Clause rather than the 4-clause one. Having it licensed under terms which include the advertising clause would be a bit of a pain. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] chrpath: We should provide chrpath-replacement-native and install into a native specific directory
Docs need to be updated, there was also a build warning if it was not
installed - did that get removed too?
-M
On Tue, Oct 2, 2012 at 8:13 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
chrpath is assumed to be provided by the build host system. This means
we need to provide a replacement version and install into a specific directory
to avoid races.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-devtools/chrpath/chrpath_0.14.bb
b/meta/recipes-devtools/chrpath/chrpath_0.14.bb
index 679f1aa..bb9b4b6 100644
--- a/meta/recipes-devtools/chrpath/chrpath_0.14.bb
+++ b/meta/recipes-devtools/chrpath/chrpath_0.14.bb
@@ -20,4 +20,7 @@ inherit autotools
# relocatable, so use the one we've just built
CHRPATH_BIN_virtclass-native = ${S}/chrpath
+PROVIDES_append_virtclass-native = chrpath-replacement-native
+NATIVE_PACKAGE_PATH_SUFFIX = /${PN}
+
BBCLASSEXTEND = native nativesdk
___
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] chrpath: We should provide chrpath-replacement-native and install into a native specific directory
On Tue, 2012-10-02 at 16:22 +, McClintock Matthew-B29882 wrote: Docs need to be updated, there was also a build warning if it was not installed - did that get removed too? You still need chrpath installed, this just avoids a different set of problems in nativesdk and corrected ASSUME_PROVIDED. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Andrei Gherzan : busybox: Package hwclock.sh initscript separately
On Thu, Sep 27, 2012 at 10:52:31PM +0200, Martin Jansa wrote:
On Fri, Aug 17, 2012 at 05:09:34PM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: b97e37e1444ef32e7837dcc79e3fad36c4284b65
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=b97e37e1444ef32e7837dcc79e3fad36c4284b65
Author: Andrei Gherzan and...@gherzan.ro
Date: Fri Aug 17 00:15:15 2012 +0300
busybox: Package hwclock.sh initscript separately
We package this separately to be able to pull this in only if this makes
sense for the MACHINE.
Signed-off-by: Andrei Gherzan and...@gherzan.ro
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/busybox/busybox.inc |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 78239a2..5a5b383 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -14,15 +14,16 @@ SECTION = base
export EXTRA_CFLAGS = ${CFLAGS}
export EXTRA_LDFLAGS = ${LDFLAGS}
-PACKAGES =+ ${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
+PACKAGES =+ ${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock
FILES_${PN}-httpd = ${sysconfdir}/init.d/busybox-httpd /srv/www
FILES_${PN}-syslog = ${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf*
FILES_${PN}-mdev = ${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf
FILES_${PN}-udhcpd = ${sysconfdir}/init.d/busybox-udhcpd
FILES_${PN}-udhcpc = ${sysconfdir}/udhcpc.d ${datadir}/udhcpc
+FILES_${PN}-hwclock = ${sysconfdir}/init.d/hwclock.sh
-INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
+INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock
INITSCRIPT_NAME_${PN}-httpd = busybox-httpd
INITSCRIPT_NAME_${PN}-syslog = syslog
Missing
INITSCRIPT_NAME_${PN}-hwclock = hwclock.sh
?
Did you test it?
Here it fails like this:
Configuring busybox-hwclock.
usage: update-rc.d [-n] [-f] [-r root] basename remove
update-rc.d [-n] [-r root] [-s] basename defaults [NN | sNN kNN]
update-rc.d [-n] [-r root] [-s] basename start|stop NN runlvl
[runlvl] [...] .
-n: not really
-f: force
-v: verbose
-r: alternate root path (default is /)
-s: invoke start methods if appropriate to current runlevel
Collected errors:
* pkg_run_script: package busybox-hwclock postinst script returned status
1.
* opkg_configure: busybox-hwclock.postinst returned 1.
And indeed it's broken:
SHR root@qemux86-64 ~ $ cat /var/lib/opkg/info/busybox-hwclock.postinst
#!/bin/sh
if test x$D != x; then
OPT=-r $D
else
OPT=-s
fi
update-rc.d $OPT ${INITSCRIPT_NAME} defaults
Cheers,
Fixed now in master
Module: openembedded-core.git
Branch: master
Commit: 43b4ffc11874803db37c43b521ce27c51c677c8b
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=43b4ffc11874803db37c43b521ce27c51c677c8b
Author: Richard Purdie richard.pur...@linuxfoundation.org
Date: Tue Oct 2 17:24:08 2012 +0100
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf: Add CCACHE_DISABLE to BS_HASHBASE_WHITELIST
If CCACHE is in the whitelist then CCACHE_DISABLE probably should be too.
Signed-off-by: Mike Crowe m...@mcrowe.com
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/conf/bitbake.conf |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index e168ef1..e813fec 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -765,7 +765,7 @@ BB_CONSOLELOG ?=
${LOG_DIR}/cooker/${MACHINE}/${DATETIME}.log
# Setup our default hash policy
BB_SIGNATURE_HANDLER ?= OEBasicHash
-BB_HASHBASE_WHITELIST ?= TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR
SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER
FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST PRSERV_PORT
PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE CCACHE_DIR
EXTERNAL_TOOLCHAIN CCACHE
+BB_HASHBASE_WHITELIST ?= TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR
SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER
FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST PRSERV_PORT
PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE CCACHE_DIR
EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE
BB_HASHCONFIG_WHITELIST ?= ${BB_HASHBASE_WHITELIST} DATE TIME SESSION_MANAGER
DBUS_SESSION_BUS_ADDRESS SSH_AGENT_PID XDG_SESSION_COOKIE SSH_AUTH_SOCK
XAUTHORITY PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS PARALLEL_MAKE
BB_NUMBER_THREADS
BB_SIGNATURE_EXCLUDE_FLAGS ?= doc defaultval _append _prepend deps depends
lockfiles type vardepsexclude \
vardeps vardepvalue file-checksums python func
task export unexport noexec \
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] e2fsprogs: Don't install findfs
This binary is provided by util-linux nowadays. Fixes:
WARNING: The recipe is trying to install files into a shared area when those
files already exist. Those files are:
/fast/jenkins/workspace/.../tmp-eglibc/sysroots/x86_64-linux/sbin/findfs
Signed-off-by: Phil Blundell p...@pbcl.net
---
(Not very clear what it was doing in the tune2fs package in the first place
since it doesn't really have anything to do with that program.)
meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.1.bb |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.1.bb
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.1.bb
index 3869c34..5d62ea0 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.1.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.1.bb
@@ -1,6 +1,6 @@
require e2fsprogs.inc
-PR = r3
+PR = r4
SRC_URI += file://fallocate.patch \
file://acinclude.m4 \
@@ -32,6 +32,7 @@ do_install () {
rm -f ${D}${base_libdir}/pkgconfig/blkid.pc
rm -f ${D}${base_sbindir}/blkid
rm -f ${D}${base_sbindir}/fsck
+ rm -f ${D}${base_sbindir}/findfs
}
do_install_append () {
@@ -50,7 +51,7 @@ PACKAGES =+ libcomerr libss libe2p libext2fs
FILES_e2fsprogs-e2fsck = ${base_sbindir}/e2fsck ${base_sbindir}/fsck.ext*
FILES_e2fsprogs-mke2fs = ${base_sbindir}/mke2fs ${base_sbindir}/mkfs.ext*
${sysconfdir}/mke2fs.conf
-FILES_e2fsprogs-tune2fs = ${base_sbindir}/tune2fs ${base_sbindir}/e2label
${base_sbindir}/findfs
+FILES_e2fsprogs-tune2fs = ${base_sbindir}/tune2fs ${base_sbindir}/e2label
FILES_e2fsprogs-badblocks = ${base_sbindir}/badblocks
FILES_libcomerr = ${base_libdir}/libcom_err.so.*
FILES_libss = ${base_libdir}/libss.so.*
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes: Update to use corrected bb.utils.explode_dep_versions2 API
On 10/1/12 7:10 PM, Richard Purdie wrote:
The bb.utils.explode_dep_versions function has issues where dependency
information
can be lost. The API doesn't support maintaining the correct information so this
changes to use a new function which correctly handles the data.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/libc-common.bbclass b/meta/classes/libc-common.bbclass
index dc32c81..0f49936 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -29,14 +29,7 @@ python populate_packages_prepend () {
d.setVar('PKG_'+bpn+'-dev', 'libc6-dev')
d.setVar('PKG_'+bpn+'-dbg', 'libc6-dbg')
# For backward compatibility with old -dbg package
-
-def add_dep(var, dep):
-deps = bb.utils.explode_dep_versions(d.getVar(var + '_' + bpn, True) or
)
-if not dep in deps:
-deps[dep] =
-d.setVar(var + '_' + bpn, bb.utils.join_deps(deps,
commasep=False))
-
-add_dep('RPROVIDES', 'libc-dbg')
-add_dep('RCONFLICTS', 'libc-dbg')
-add_dep('RREPLACES', 'libc-dbg')
+d.appendVar('RPROVIDES_' + bpn + '-dbg', ' libc-dbg')
+d.appendVar('RCONFLICTS_' + bpn + '-dbg', ' libc-dbg')
+d.appendVar('RREPLACES_' + bpn + '-dbg', ' libc-dbg')
}
The above is almost the same as the original code. The problem with appendVar
is that then you get duplicate entries. With the new code, I know we won't get
exceptions, but do we really want the duplicates?
Everything else looks good.
--Mark
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] chrpath: We should provide chrpath-replacement-native and install into a native specific directory
On Tue, Oct 2, 2012 at 11:29 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2012-10-02 at 16:22 +, McClintock Matthew-B29882 wrote: Docs need to be updated, there was also a build warning if it was not installed - did that get removed too? You still need chrpath installed, this just avoids a different set of problems in nativesdk and corrected ASSUME_PROVIDED. You still need it installed on your host? -M 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] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
Let me preface this by I have read the patch set.. Martin asked me to comment
on
the items below...
On 9/27/12 3:37 AM, Martin Jansa wrote:
On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
includes its tune*.inc, but it's easy for DISTRO to say it wants
OPTDEFAULTTUNE for some packages or always (if they don't want to
share built packages between xscale and arm926ejs).
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/bitbake.conf | 1 +
meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
meta/conf/machine/include/tune-xscale.inc| 3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9b41749..e433fcb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -95,6 +95,7 @@ HOST_LD_ARCH = ${TARGET_LD_ARCH}
HOST_AS_ARCH = ${TARGET_AS_ARCH}
HOST_EXEEXT =
+OPTDEFAULTTUNE ??= ${DEFAULTTUNE}
TUNE_ARCH ??= INVALID
TUNE_CCARGS ??=
TUNE_LDARGS ??=
As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
or in meaning and we need to find a better solution. I'm therefore not
keen on this change.
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?
I've been an advocate for a while that the processor optimization (CCARGS)
does
make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to
do
this. It allows each tune to set something to tell people what that binary
is
really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
The only concern I have with that is:
+ARMPKGSFX_CPU = ${@bb.utils.contains(TUNE_FEATURES, arm926ejs,
-arm926ejs, , d)}
That probably should be a .= instead of just '='. That way if the user loads
multiple compatible tunes the right ARMPKGSFX_CPU will be used.
(Alternatively
using the overrides would work as well for this.. i.e.
ARMPKGSFX_CPU_tune-arm926ejs instead...
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is
fine as well, and it was designed to be overriden.. but again the .= or
-tune_... syntax should be used...
I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
While changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
ARMPKGARCH = ${ARMPKGARCH_tune-${DEFAULTTUNE}}
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like this TUNE_PKGARCH
(${ARMPKGARCH_tune-armv5te}te).).
This makes whole
TUNE_PKGARCH =
${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
Cheers,
Anyway, my point in this is I like having the stuff unique, but we need to be
sure that you can specify more then one tune file during a build w/o clashes.
I also still think this is a distro packaging issue and should be solved
by the distro, even if that means more complexity there. That is the
right place for this particular complexity IMO. I'm happy to support
that from the core but not in something as user visible and confusing as
this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.
I really don't have a strong opinion on this either way. I know for the
stuff
I've done in the past (not oe-based) we've just manually configured (the
equivalent of the distro conf) with the information on the handful of items
that
people wanted optimized the most... eglibc, openssl, mysql/posgresql...
otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via
package
specific overrides in the distro file should be fine.. if it's more then 10
(typically) then we need to start looking for another approach.
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = $@{...} where ... is check for something set by the BSP
(or
elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-pn = ${OPTDEFAULTTUNE}
and then everything can be encapsulated into the distro file (and distro
BSPs).
The downside of this approach is that it's
Re: [OE-core] [PATCH] classes: Update to use corrected bb.utils.explode_dep_versions2 API
On Tue, 2012-10-02 at 12:20 -0500, Mark Hatle wrote:
On 10/1/12 7:10 PM, Richard Purdie wrote:
The bb.utils.explode_dep_versions function has issues where dependency
information
can be lost. The API doesn't support maintaining the correct information so
this
changes to use a new function which correctly handles the data.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/libc-common.bbclass
b/meta/classes/libc-common.bbclass
index dc32c81..0f49936 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -29,14 +29,7 @@ python populate_packages_prepend () {
d.setVar('PKG_'+bpn+'-dev', 'libc6-dev')
d.setVar('PKG_'+bpn+'-dbg', 'libc6-dbg')
# For backward compatibility with old -dbg package
-
-def add_dep(var, dep):
-deps = bb.utils.explode_dep_versions(d.getVar(var + '_' + bpn,
True) or )
-if not dep in deps:
-deps[dep] =
-d.setVar(var + '_' + bpn, bb.utils.join_deps(deps,
commasep=False))
-
-add_dep('RPROVIDES', 'libc-dbg')
-add_dep('RCONFLICTS', 'libc-dbg')
-add_dep('RREPLACES', 'libc-dbg')
+d.appendVar('RPROVIDES_' + bpn + '-dbg', ' libc-dbg')
+d.appendVar('RCONFLICTS_' + bpn + '-dbg', ' libc-dbg')
+d.appendVar('RREPLACES_' + bpn + '-dbg', ' libc-dbg')
}
The above is almost the same as the original code. The problem with
appendVar
is that then you get duplicate entries. With the new code, I know we won't
get
exceptions, but do we really want the duplicates?
Everything else looks good.
Its not really an error to have duplicates in the field. I'm fine with
avoiding it where it makes sense but I don't like adding too much
runtime cost or complexity.
In the above case it will get filtered out later anyway so I'm not
really bothered by it and prefer the simpler syntax.
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] chrpath: We should provide chrpath-replacement-native and install into a native specific directory
On Tue, 2012-10-02 at 17:30 +, McClintock Matthew-B29882 wrote: On Tue, Oct 2, 2012 at 11:29 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2012-10-02 at 16:22 +, McClintock Matthew-B29882 wrote: Docs need to be updated, there was also a build warning if it was not installed - did that get removed too? You still need chrpath installed, this just avoids a different set of problems in nativesdk and corrected ASSUME_PROVIDED. You still need it installed on your host? Correct, it gets used for native sstate for example. I've tried to remove this before and you get stuck in circular dependencies which I decided weren’t worth the pain. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On 10/2/12 1:43 PM, Martin Jansa wrote:
On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
Let me preface this by I have read the patch set.. Martin asked me to comment on
the items below...
On 9/27/12 3:37 AM, Martin Jansa wrote:
On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
includes its tune*.inc, but it's easy for DISTRO to say it wants
OPTDEFAULTTUNE for some packages or always (if they don't want to
share built packages between xscale and arm926ejs).
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/bitbake.conf | 1 +
meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
meta/conf/machine/include/tune-xscale.inc| 3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9b41749..e433fcb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -95,6 +95,7 @@ HOST_LD_ARCH = ${TARGET_LD_ARCH}
HOST_AS_ARCH = ${TARGET_AS_ARCH}
HOST_EXEEXT =
+OPTDEFAULTTUNE ??= ${DEFAULTTUNE}
TUNE_ARCH ??= INVALID
TUNE_CCARGS ??=
TUNE_LDARGS ??=
As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
or in meaning and we need to find a better solution. I'm therefore not
keen on this change.
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?
I've been an advocate for a while that the processor optimization (CCARGS) does
make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to do
this. It allows each tune to set something to tell people what that binary is
really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
The only concern I have with that is:
+ARMPKGSFX_CPU = ${@bb.utils.contains(TUNE_FEATURES, arm926ejs,
-arm926ejs, , d)}
That probably should be a .= instead of just '='. That way if the user loads
multiple compatible tunes the right ARMPKGSFX_CPU will be used. (Alternatively
using the overrides would work as well for this.. i.e.
ARMPKGSFX_CPU_tune-arm926ejs instead...
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is
fine as well, and it was designed to be overriden.. but again the .= or
-tune_... syntax should be used...
I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
While changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
ARMPKGARCH = ${ARMPKGARCH_tune-${DEFAULTTUNE}}
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like this TUNE_PKGARCH
(${ARMPKGARCH_tune-armv5te}te).).
This makes whole
TUNE_PKGARCH =
${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
I've clarified with RP on this. Tune values are not a 'true' override because
of evaluation time of overrides. We want the DEFAULTTUNE to be changeable
during the build process to allow multilibs, alternative configurations, etc.
So in the tunes to do override-like implementations, you will need:
ARMPKGARCH = ${ARMPKGARCH_tune-${DEFAULTTUNE}}
and then in each tune fragment:
ARMPKGARCH_tune-foo = bar
--Mark
Cheers,
Anyway, my point in this is I like having the stuff unique, but we need to be
sure that you can specify more then one tune file during a build w/o clashes.
I also still think this is a distro packaging issue and should be solved
by the distro, even if that means more complexity there. That is the
right place for this particular complexity IMO. I'm happy to support
that from the core but not in something as user visible and confusing as
this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.
I really don't have a strong opinion on this either way. I know for the stuff
I've done in the past (not oe-based) we've just manually configured (the
equivalent of the distro conf) with the information on the handful of items that
people wanted optimized the most... eglibc, openssl, mysql/posgresql...
otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package
specific overrides in the distro file should be fine.. if it's more then 10
(typically) then we need to start looking for another approach.
I'd almost suggest in the distro file you could
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On Tue, Oct 02, 2012 at 03:36:16PM -0500, Mark Hatle wrote:
On 10/2/12 1:43 PM, Martin Jansa wrote:
On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
Let me preface this by I have read the patch set.. Martin asked me to
comment on
the items below...
On 9/27/12 3:37 AM, Martin Jansa wrote:
On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
includes its tune*.inc, but it's easy for DISTRO to say it wants
OPTDEFAULTTUNE for some packages or always (if they don't want to
share built packages between xscale and arm926ejs).
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/bitbake.conf | 1 +
meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
meta/conf/machine/include/tune-xscale.inc| 3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9b41749..e433fcb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -95,6 +95,7 @@ HOST_LD_ARCH = ${TARGET_LD_ARCH}
HOST_AS_ARCH = ${TARGET_AS_ARCH}
HOST_EXEEXT =
+OPTDEFAULTTUNE ??= ${DEFAULTTUNE}
TUNE_ARCH ??= INVALID
TUNE_CCARGS ??=
TUNE_LDARGS ??=
As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
or in meaning and we need to find a better solution. I'm therefore not
keen on this change.
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?
I've been an advocate for a while that the processor optimization (CCARGS)
does
make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach
to do
this. It allows each tune to set something to tell people what that
binary is
really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
The only concern I have with that is:
+ARMPKGSFX_CPU = ${@bb.utils.contains(TUNE_FEATURES, arm926ejs,
-arm926ejs, , d)}
That probably should be a .= instead of just '='. That way if the user
loads
multiple compatible tunes the right ARMPKGSFX_CPU will be used.
(Alternatively
using the overrides would work as well for this.. i.e.
ARMPKGSFX_CPU_tune-arm926ejs instead...
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This
is
fine as well, and it was designed to be overriden.. but again the .= or
-tune_... syntax should be used...
I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
While changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
ARMPKGARCH = ${ARMPKGARCH_tune-${DEFAULTTUNE}}
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like this TUNE_PKGARCH
(${ARMPKGARCH_tune-armv5te}te).).
This makes whole
TUNE_PKGARCH =
${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
I've clarified with RP on this. Tune values are not a 'true' override
because
of evaluation time of overrides. We want the DEFAULTTUNE to be changeable
during the build process to allow multilibs, alternative configurations, etc.
So in the tunes to do override-like implementations, you will need:
ARMPKGARCH = ${ARMPKGARCH_tune-${DEFAULTTUNE}}
and then in each tune fragment:
ARMPKGARCH_tune-foo = bar
Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top
in that repo
--Mark
Cheers,
Anyway, my point in this is I like having the stuff unique, but we need to
be
sure that you can specify more then one tune file during a build w/o
clashes.
I also still think this is a distro packaging issue and should be solved
by the distro, even if that means more complexity there. That is the
right place for this particular complexity IMO. I'm happy to support
that from the core but not in something as user visible and confusing as
this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.
I really don't have a strong opinion on this either way. I know for the
stuff
I've done in the past (not oe-based) we've just manually configured (the
equivalent of the distro conf) with the information on the handful of
items that
people wanted optimized the most...
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On 10/2/12 3:38 PM, Martin Jansa wrote:
On Tue, Oct 02, 2012 at 03:36:16PM -0500, Mark Hatle wrote:
On 10/2/12 1:43 PM, Martin Jansa wrote:
On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
Let me preface this by I have read the patch set.. Martin asked me to comment on
the items below...
On 9/27/12 3:37 AM, Martin Jansa wrote:
On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
includes its tune*.inc, but it's easy for DISTRO to say it wants
OPTDEFAULTTUNE for some packages or always (if they don't want to
share built packages between xscale and arm926ejs).
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/bitbake.conf | 1 +
meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
meta/conf/machine/include/tune-xscale.inc| 3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9b41749..e433fcb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -95,6 +95,7 @@ HOST_LD_ARCH = ${TARGET_LD_ARCH}
HOST_AS_ARCH = ${TARGET_AS_ARCH}
HOST_EXEEXT =
+OPTDEFAULTTUNE ??= ${DEFAULTTUNE}
TUNE_ARCH ??= INVALID
TUNE_CCARGS ??=
TUNE_LDARGS ??=
As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
or in meaning and we need to find a better solution. I'm therefore not
keen on this change.
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?
I've been an advocate for a while that the processor optimization (CCARGS) does
make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to do
this. It allows each tune to set something to tell people what that binary is
really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
The only concern I have with that is:
+ARMPKGSFX_CPU = ${@bb.utils.contains(TUNE_FEATURES, arm926ejs,
-arm926ejs, , d)}
That probably should be a .= instead of just '='. That way if the user loads
multiple compatible tunes the right ARMPKGSFX_CPU will be used. (Alternatively
using the overrides would work as well for this.. i.e.
ARMPKGSFX_CPU_tune-arm926ejs instead...
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is
fine as well, and it was designed to be overriden.. but again the .= or
-tune_... syntax should be used...
I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
While changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
ARMPKGARCH = ${ARMPKGARCH_tune-${DEFAULTTUNE}}
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like this TUNE_PKGARCH
(${ARMPKGARCH_tune-armv5te}te).).
This makes whole
TUNE_PKGARCH =
${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
I've clarified with RP on this. Tune values are not a 'true' override because
of evaluation time of overrides. We want the DEFAULTTUNE to be changeable
during the build process to allow multilibs, alternative configurations, etc.
So in the tunes to do override-like implementations, you will need:
ARMPKGARCH = ${ARMPKGARCH_tune-${DEFAULTTUNE}}
and then in each tune fragment:
ARMPKGARCH_tune-foo = bar
Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top
in that repo
Ya, I agree a bit ugly.. but I do think it's reasonable in this case.
--Mark
--Mark
Cheers,
Anyway, my point in this is I like having the stuff unique, but we need to be
sure that you can specify more then one tune file during a build w/o clashes.
I also still think this is a distro packaging issue and should be solved
by the distro, even if that means more complexity there. That is the
right place for this particular complexity IMO. I'm happy to support
that from the core but not in something as user visible and confusing as
this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.
I really don't have a strong opinion on this either way. I know for the stuff
I've done in the past (not oe-based) we've just manually configured (the
equivalent of the distro conf) with the information on the handful of items that
people wanted optimized the most... eglibc, openssl, mysql/posgresql...
otherwise folks don't seem to care, and
[OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
* When building with 24 bitbake threads on my system I observed
errors like the following:
| configure.ac:199: error: LT_LANG: unsupported language: Go
|
tmpdir/work/armv7a-vfp-neon-oe-linux-gnueabi/libtool-2.4.2-r3.0/libtool-2.4.2/aclocal-copy/libtool.m4:768:
LT_LANG is expanded from...
| configure.ac:199: the top level
| autom4te: m4 failed with exit status: 1
* This could be found by doing a clean build. If a build had
already been performed then often just cleaning the libtool
package and rebuilding it would resolve the issue.
* Adding a DEPENDS on libtool-cross resolves this issue with a
clean build.
* Bump the PR
Signed-off-by: Chase Maupin chase.mau...@ti.com
---
meta/recipes-devtools/libtool/libtool_2.4.2.bb |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/libtool/libtool_2.4.2.bb
b/meta/recipes-devtools/libtool/libtool_2.4.2.bb
index a2eb4ea..f376b67 100644
--- a/meta/recipes-devtools/libtool/libtool_2.4.2.bb
+++ b/meta/recipes-devtools/libtool/libtool_2.4.2.bb
@@ -1,6 +1,8 @@
require libtool-${PV}.inc
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
+
+DEPENDS += libtool-cross
#
# We want the results of libtool-cross preserved - don't stage anything
ourselves.
--
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] [for-denzil][PATCH] libtool: Add missing DEPENDS on libtool-cross
* When building with 24 bitbake threads on my system I observed
errors like the following:
| configure.ac:199: error: LT_LANG: unsupported language: Go
|
tmpdir/work/armv7a-vfp-neon-oe-linux-gnueabi/libtool-2.4.2-r3.0/libtool-2.4.2/aclocal-copy/libtool.m4:768:
LT_LANG is expanded from...
| configure.ac:199: the top level
| autom4te: m4 failed with exit status: 1
* This could be found by doing a clean build. If a build had
already been performed then often just cleaning the libtool
package and rebuilding it would resolve the issue.
* Adding a DEPENDS on libtool-cross resolves this issue with a
clean build.
* Bump the PR
Signed-off-by: Chase Maupin chase.mau...@ti.com
---
meta/recipes-devtools/libtool/libtool_2.4.2.bb |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/libtool/libtool_2.4.2.bb
b/meta/recipes-devtools/libtool/libtool_2.4.2.bb
index a2eb4ea..f376b67 100644
--- a/meta/recipes-devtools/libtool/libtool_2.4.2.bb
+++ b/meta/recipes-devtools/libtool/libtool_2.4.2.bb
@@ -1,6 +1,8 @@
require libtool-${PV}.inc
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
+
+DEPENDS += libtool-cross
#
# We want the results of libtool-cross preserved - don't stage anything
ourselves.
--
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] sstate: Add detail to shared area warning
[YOCTO #3191]
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/sstate.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 03f083e..ca50483 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -158,7 +158,7 @@ def sstate_install(ss, d):
if realmatch:
match.append(f)
if match:
-bb.warn(The recipe is trying to install files into a shared area when
those files already exist. Those files are:\n %s % \n .join(match))
+bb.warn(The %s recipe is trying to install files into a shared area
when those files already exist (please fix %s). Those files are:\n %s %
(d.getVar('PN', True), d.getVar('FILE', True), \n .join(match)))
# Write out the manifest
f = open(manifest, w)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sstate: Add detail to shared area warning
On Tue, 2012-10-02 at 15:00 -0700, Saul Wold wrote:
-bb.warn(The recipe is trying to install files into a shared area
when those files already exist. Those files are:\n %s % \n
.join(match))
+bb.warn(The %s recipe is trying to install files into a shared area
when those files already exist (please fix %s). Those files are:\n %s %
(d.getVar('PN', True), d.getVar('FILE', True), \n .join(match)))
That seems potentially misleading: the file that needs fixing isn't
necessarily the one that triggers this warning. What would be ideal
would be to have it output the names of all recipes that have tried to
stage the files in question so that the user can make an informed
decision about which one ought to be putting them there.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sstate: Add detail to shared area warning
On 10/02/2012 03:00 PM, Phil Blundell wrote:
On Tue, 2012-10-02 at 15:00 -0700, Saul Wold wrote:
-bb.warn(The recipe is trying to install files into a shared area when those files
already exist. Those files are:\n %s % \n .join(match))
+bb.warn(The %s recipe is trying to install files into a shared area when those files
already exist (please fix %s). Those files are:\n %s % (d.getVar('PN', True),
d.getVar('FILE', True), \n .join(match)))
That seems potentially misleading: the file that needs fixing isn't
necessarily the one that triggers this warning. What would be ideal
would be to have it output the names of all recipes that have tried to
stage the files in question so that the user can make an informed
decision about which one ought to be putting them there.
True enough, but we don't have that information at that time, but it
gives more information than we had before, as to which recipe was adding
the files, I guess if I change the wording to something like
verify or check?
Sau!
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sstate: Add detail to shared area warning
On Tue, 2012-10-02 at 15:06 -0700, Saul Wold wrote:
On 10/02/2012 03:00 PM, Phil Blundell wrote:
On Tue, 2012-10-02 at 15:00 -0700, Saul Wold wrote:
-bb.warn(The recipe is trying to install files into a shared area
when those files already exist. Those files are:\n %s % \n
.join(match))
+bb.warn(The %s recipe is trying to install files into a shared
area when those files already exist (please fix %s). Those files are:\n
%s % (d.getVar('PN', True), d.getVar('FILE', True), \n .join(match)))
That seems potentially misleading: the file that needs fixing isn't
necessarily the one that triggers this warning. What would be ideal
would be to have it output the names of all recipes that have tried to
stage the files in question so that the user can make an informed
decision about which one ought to be putting them there.
True enough, but we don't have that information at that time, but it
gives more information than we had before, as to which recipe was adding
the files, I guess if I change the wording to something like
verify or check?
Yeah, sounds good.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sstate: Add detail to shared area warning
On Tue, Oct 02, 2012 at 11:00:53PM +0100, Phil Blundell wrote:
On Tue, 2012-10-02 at 15:00 -0700, Saul Wold wrote:
-bb.warn(The recipe is trying to install files into a shared area
when those files already exist. Those files are:\n %s % \n
.join(match))
+bb.warn(The %s recipe is trying to install files into a shared
area when those files already exist (please fix %s). Those files are:\n
%s % (d.getVar('PN', True), d.getVar('FILE', True), \n .join(match)))
That seems potentially misleading: the file that needs fixing isn't
necessarily the one that triggers this warning. What would be ideal
would be to have it output the names of all recipes that have tried to
stage the files in question so that the user can make an informed
decision about which one ought to be putting them there.
Maybe something like master.list was before
http://git.openembedded.org/openembedded-core/commit/?id=603daf343ad3f18c8adb799e3625ae2a18d94f56
with added recipe name, but that doesn't detect files already
stored in sysroot directly from do_configure/do_compile etc like RP
suspects python recipe is doing in this case.
And yes it does, to use that to compile own extensions later.
do_compile:
install -d ${STAGING_INCDIR}/python${PYTHON_MAJMIN}/
install -d ${STAGING_LIBDIR}/python${PYTHON_MAJMIN}/config/
install -m 0644 pyconfig.h ${STAGING_INCDIR}/python${PYTHON_MAJMIN}/
install -m 0644 Makefile
${STAGING_LIBDIR}/python${PYTHON_MAJMIN}/config/
..
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sstate: Add detail to shared area warning
On Tue, 2012-10-02 at 23:00 +0100, Phil Blundell wrote:
On Tue, 2012-10-02 at 15:00 -0700, Saul Wold wrote:
-bb.warn(The recipe is trying to install files into a shared area
when those files already exist. Those files are:\n %s % \n
.join(match))
+bb.warn(The %s recipe is trying to install files into a shared
area when those files already exist (please fix %s). Those files are:\n
%s % (d.getVar('PN', True), d.getVar('FILE', True), \n .join(match)))
That seems potentially misleading: the file that needs fixing isn't
necessarily the one that triggers this warning. What would be ideal
would be to have it output the names of all recipes that have tried to
stage the files in question so that the user can make an informed
decision about which one ought to be putting them there.
*if* you can get that information. The python recipe is poking things
into the sysroot outside the knowledge of sstate, then triggering a
warning. We have no way to know who put files there if it wasn't done
through sstate.
This isn't to say we shouldn't improve the message and use the sstate
manifests to find any culprits, just that we can't find an answer in all
cases.
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] sstate: Add detail to shared area warning
On Wed, 2012-10-03 at 00:11 +0200, Martin Jansa wrote:
On Tue, Oct 02, 2012 at 11:00:53PM +0100, Phil Blundell wrote:
On Tue, 2012-10-02 at 15:00 -0700, Saul Wold wrote:
-bb.warn(The recipe is trying to install files into a shared
area when those files already exist. Those files are:\n %s % \n
.join(match))
+bb.warn(The %s recipe is trying to install files into a shared
area when those files already exist (please fix %s). Those files are:\n
%s % (d.getVar('PN', True), d.getVar('FILE', True), \n .join(match)))
That seems potentially misleading: the file that needs fixing isn't
necessarily the one that triggers this warning. What would be ideal
would be to have it output the names of all recipes that have tried to
stage the files in question so that the user can make an informed
decision about which one ought to be putting them there.
Maybe something like master.list was before
http://git.openembedded.org/openembedded-core/commit/?id=603daf343ad3f18c8adb799e3625ae2a18d94f56
with added recipe name, but that doesn't detect files already
We can list any sstate manifest files (tmp/sstate-control) also adding
that file which may or may not have a listing of it. We might as well
just grep those files and print matches.
We are not going back to a master.list file, its a performance headache.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qt4: Avoid circular dependencies with multilib
Without this, circular dependencies are found when attempting to build
multilib versions of qt4 (or bitbake world in a multilib enabled build).
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/qt4e.bbclass b/meta/classes/qt4e.bbclass
index 05c24ef..de2a68d 100644
--- a/meta/classes/qt4e.bbclass
+++ b/meta/classes/qt4e.bbclass
@@ -1,4 +1,5 @@
-DEPENDS_prepend = ${@[qt4-embedded , ][(d.getVar('PN', True)[:12] ==
'qt4-embedded')]}
+QT4EDEPENDS ?= qt4-embedded
+DEPENDS_prepend = ${QT4EDEPENDS}
inherit qmake2
diff --git a/meta/classes/qt4x11.bbclass b/meta/classes/qt4x11.bbclass
index 52190f4..b06e15d 100644
--- a/meta/classes/qt4x11.bbclass
+++ b/meta/classes/qt4x11.bbclass
@@ -1,4 +1,5 @@
-DEPENDS_prepend = ${@base_contains(PROVIDES, qt4-x11, , qt4-x11 , d)}
+QT4DEPENDS ?= qt4-x11
+DEPENDS_prepend = ${QT4DEPENDS}
inherit qmake2
diff --git a/meta/recipes-qt/qt4/qt4-embedded.inc
b/meta/recipes-qt/qt4/qt4-embedded.inc
index 53eb652..965c66e 100644
--- a/meta/recipes-qt/qt4/qt4-embedded.inc
+++ b/meta/recipes-qt/qt4/qt4-embedded.inc
@@ -4,6 +4,7 @@ HOMEPAGE = http://qt.nokia.com;
DEPENDS += directfb tslib
INC_PR = r48
+QT4EDEPENDS =
QT_BASE_LIB ?= libqt-embedded
# Set necessary variables in the profile
diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
b/meta/recipes-qt/qt4/qt4-x11-free.inc
index 0ae74f7..70ee9b0 100644
--- a/meta/recipes-qt/qt4/qt4-x11-free.inc
+++ b/meta/recipes-qt/qt4/qt4-x11-free.inc
@@ -5,6 +5,7 @@ HOMEPAGE = http://qt.nokia.com;
SECTION = x11/libs
DEPENDS += virtual/libgl virtual/libx11 fontconfig libxft libxext libxrender
libxrandr libxcursor
PROVIDES += qt4-x11
+QT4DEPENDS =
INC_PR = r46
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Change bzip2 to a less generic license
The license for bzip2 is not quite BSD. I have an email out to the maintainer to see if we can utilize a common BSD license (or something else) however, for now, we should revert bzip2 back to a special license. As busybox also utilizes a lightly modified bzip2, this also effects busybox. The following changes since commit 8609051d8d4f9fa565eb48418a87fa0048613374: bitbake.conf: Add CCACHE_DISABLE to BS_HASHBASE_WHITELIST (2012-10-02 18:12:48 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib eflanagan/bzip http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/bzip Elizabeth Flanagan (1): bzip2 and busybox: Incorrect LICENSE meta/recipes-core/busybox/busybox.inc |3 +-- meta/recipes-extended/bzip2/bzip2_1.0.6.bb |2 +- 2 files changed, 2 insertions(+), 3 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sstate: Add detail to shared area warning
On Tue, Oct 2, 2012 at 5:22 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2012-10-03 at 00:11 +0200, Martin Jansa wrote:
On Tue, Oct 02, 2012 at 11:00:53PM +0100, Phil Blundell wrote:
On Tue, 2012-10-02 at 15:00 -0700, Saul Wold wrote:
-bb.warn(The recipe is trying to install files into a shared
area when those files already exist. Those files are:\n %s % \n
.join(match))
+bb.warn(The %s recipe is trying to install files into a shared
area when those files already exist (please fix %s). Those files are:\n
%s % (d.getVar('PN', True), d.getVar('FILE', True), \n
.join(match)))
That seems potentially misleading: the file that needs fixing isn't
necessarily the one that triggers this warning. What would be ideal
would be to have it output the names of all recipes that have tried to
stage the files in question so that the user can make an informed
decision about which one ought to be putting them there.
Maybe something like master.list was before
http://git.openembedded.org/openembedded-core/commit/?id=603daf343ad3f18c8adb799e3625ae2a18d94f56
with added recipe name, but that doesn't detect files already
We can list any sstate manifest files (tmp/sstate-control) also adding
that file which may or may not have a listing of it. We might as well
just grep those files and print matches.
We are not going back to a master.list file, its a performance headache.
I had to do this manually recently, so this error would be very useful ;)
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bitbake.conf: Add CCACHE_DISABLE to BS_HASHBASE_WHITELIST
On 10/02/2012 09:22 AM, Mike Crowe wrote:
If CCACHE is in the whitelist then CCACHE_DISABLE probably should be too.
Signed-off-by: Mike Crowe m...@mcrowe.com
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/conf/bitbake.conf |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index e168ef1..e813fec 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -765,7 +765,7 @@ BB_CONSOLELOG ?=
${LOG_DIR}/cooker/${MACHINE}/${DATETIME}.log
# Setup our default hash policy
BB_SIGNATURE_HANDLER ?= OEBasicHash
-BB_HASHBASE_WHITELIST ?= TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR SSTATE_DIR
THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER FILESPATH
STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST PRSERV_PORT PRSERV_DUMPDIR
PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE
+BB_HASHBASE_WHITELIST ?= TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR SSTATE_DIR
THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER FILESPATH
STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST PRSERV_PORT PRSERV_DUMPDIR
PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE
CCACHE_DISABLE
BB_HASHCONFIG_WHITELIST ?= ${BB_HASHBASE_WHITELIST} DATE TIME SESSION_MANAGER
DBUS_SESSION_BUS_ADDRESS SSH_AGENT_PID XDG_SESSION_COOKIE SSH_AUTH_SOCK XAUTHORITY
PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS PARALLEL_MAKE BB_NUMBER_THREADS
BB_SIGNATURE_EXCLUDE_FLAGS ?= doc defaultval _append _prepend deps depends
lockfiles type vardepsexclude \
vardeps vardepvalue file-checksums python func
task export unexport noexec \
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 00/10] qt4: upgrade to 4.8.3 and cleanup
On 09/26/2012 03:27 PM, Martin Jansa wrote:
Please test on more architectures.
I've tested complete qt4-native + qt4-free-x11 on armv4t.
And only do_patch for nativesdk-qt4-tools, qt-mobility-*, qt4-embedded.
The following changes since commit 938d07871bedd91f0d95ed6fe338ecbfafa5ebfe:
busybox: Fix misplaced quote (2012-09-26 18:28:17 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib jansa/qt4-4.8.3
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/qt4-4.8.3
Martin Jansa (10):
qt4-tools-nativesdk.inc: rename to nativesdk-qt4-tools.inc
qt4: use releases.qt-project.org instead of get.qt.nokia.com
qt4: rename qt-4.8.1 to qt4-4.8.1 to match other .inc and .bb
qt4.inc: move more options to separate variables
qt-mobility: move qt-mobility patches to separate dir
qt4: move patches from files to qt4-4.8.1
qt4: drop patches not used in any recipe
qt4: replace all local patches with git patches with headers
qt4: PR bumps
qt4: upgrade to 4.8.3
Merged into OE-Core
with updated patch 10/10
Thanks
Sau!
meta/recipes-qt/qt4/files/0004-no-qmake.patch | 27 --
meta/recipes-qt/qt4/files/0008-qt-lib-infix.patch | 41 --
.../qt4/files/blacklist-diginotar-certs.diff | 95 --
.../recipes-qt/qt4/files/compile.test-lflags.patch | 17
meta/recipes-qt/qt4/files/fix-config-tests.patch | 38 -
...tools-nativesdk.inc = nativesdk-qt4-tools.inc} | 18 ++--
meta/recipes-qt/qt4/nativesdk-qt4-tools_4.8.1.bb | 8 --
meta/recipes-qt/qt4/nativesdk-qt4-tools_4.8.3.bb | 8 ++
.../qt4/qt-4.8.1/fix_conflicting_types.patch | 29 ---
meta/recipes-qt/qt4/qt-4.8.1/gcc47-fix.patch | 35
meta/recipes-qt/qt4/qt-4.8.1/qmake_cxx_eval.patch | 22 -
...stvideoconnector-fixed-buffers-allocation.patch | 0
...nnecessary-rpaths-from-qml_device-example.patch | 0
.../{files = qt-mobility-1.2.0}/gcc-scope.patch | 0
.../qt-mobility-configure.patch| 0
.../qt-mobility-no-opengl.patch| 0
meta/recipes-qt/qt4/qt-mobility_1.2.0.inc | 3 +-
.../recipes-qt/qt4/{qt-4.8.1.inc = qt4-4.8.3.inc} | 41 +-
...-allow-to-set-qt.conf-from-the-outside-u.patch} | 28 +--
...ty_qws-fix-build-with-old-kernel-headers.patch} | 21 -
...03-webkit2-set-OUTPUT_DIR-value-if-empty.patch} | 21 -
...make-is-already-built-in-qt4-tools-native.patch | 29 +++
...-set-LFLAGS-to-pick-up-zlib-from-staging.patch} | 24 --
...e-OE_QMAKE_-values-to-specify-Qt-utility.patch} | 26 --
...const-usage-that-causes-compile-failure-.patch} | 26 --
...low-building-a-separate-qmake-for-the-ta.patch} | 20 +++--
...-fix-source-file-references-in-qmake.pri.patch} | 15 ++--
...ck-to-not-use-the-pg_config-of-the-host-.patch} | 25 --
.../0011-freetype-host-includes.patch} | 20 +++--
.../0012-Add-2bpp-support.patch} | 76 ++---
.../0013-configure-add-crossarch-option.patch} | 36
...ions-fix-phony-translation-linking-error.patch} | 19 +++--
...configure-add-nostrip-for-debug-packages.patch} | 15 +++-
...sure-we-identify-the-compiler-as-g-in-co.patch} | 27 --
...re-make-pulseaudio-a-configurable-option.patch} | 17 ++--
...es-for-gcc-4.7.0-particularly-on-qemux86.patch} | 45 ++
...019-webkit-disable-the-fuse-ld-gold-flag.patch} | 23 --
.../qt4/{qt-4.8.1 = qt4-4.8.3}/g++.conf | 0
.../qt4/{qt-4.8.1 = qt4-4.8.3}/linux.conf | 0
meta/recipes-qt/qt4/{files = qt4-4.8.3}/qte.sh| 0
meta/recipes-qt/qt4/qt4-embedded.inc | 2 +-
...qt4-embedded_4.8.1.bb = qt4-embedded_4.8.3.bb} | 4 +-
meta/recipes-qt/qt4/qt4-native.inc | 10 +--
meta/recipes-qt/qt4/qt4-native_4.8.1.bb| 12 ---
meta/recipes-qt/qt4/qt4-native_4.8.3.bb| 8 ++
meta/recipes-qt/qt4/qt4-x11-free.inc | 2 +-
...qt4-x11-free_4.8.1.bb = qt4-x11-free_4.8.3.bb} | 4 +-
meta/recipes-qt/qt4/qt4.inc| 19 -
48 files changed, 427 insertions(+), 529 deletions(-)
delete mode 100644 meta/recipes-qt/qt4/files/0004-no-qmake.patch
delete mode 100644 meta/recipes-qt/qt4/files/0008-qt-lib-infix.patch
delete mode 100644 meta/recipes-qt/qt4/files/blacklist-diginotar-certs.diff
delete mode 100644 meta/recipes-qt/qt4/files/compile.test-lflags.patch
delete mode 100644 meta/recipes-qt/qt4/files/fix-config-tests.patch
rename meta/recipes-qt/qt4/{qt4-tools-nativesdk.inc =
nativesdk-qt4-tools.inc} (83%)
delete mode 100644 meta/recipes-qt/qt4/nativesdk-qt4-tools_4.8.1.bb
create mode 100644 meta/recipes-qt/qt4/nativesdk-qt4-tools_4.8.3.bb
delete mode 100644 meta/recipes-qt/qt4/qt-4.8.1/fix_conflicting_types.patch
delete mode 100644 meta/recipes-qt/qt4/qt-4.8.1/gcc47-fix.patch
delete mode
Re: [OE-core] [PATCH] libdrm: Remove Cairo dependency
On 10/01/2012 04:56 AM, Ross Burton wrote:
From: Daniel Stone dan...@fooishbar.org
This causes a build loop, when DRM depends on Cairo depends on Mesa
depends on DRM. We can safely remove it as it's only one libdrm example
program which uses Cairo, which we won't be needing. At least it's not
worth the build loop.
Signed-off-by: Daniel Stone dan...@fooishbar.org
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/drm/libdrm.inc |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/drm/libdrm.inc
b/meta/recipes-graphics/drm/libdrm.inc
index 5ddab85..cc09791 100644
--- a/meta/recipes-graphics/drm/libdrm.inc
+++ b/meta/recipes-graphics/drm/libdrm.inc
@@ -9,9 +9,9 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://xf86drm.c;beginline=9;endline=32;md5=c8a3b961af7667c530816761e949dc71
SRC_URI = http://dri.freedesktop.org/libdrm/libdrm-${PV}.tar.bz2;
PROVIDES = drm
-DEPENDS = libpthread-stubs udev cairo
+DEPENDS = libpthread-stubs udev
-INC_PR = r2
+INC_PR = r3
#libpciaccess is required starting from libdrm 2.4.26
DEPENDS += libpciaccess
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Revert initrd: Spawn an emergency shell when something goes wrong
On 10/02/2012 08:56 AM, Ross Burton wrote:
This had nowhere near enough testing...
This reverts commit ffb6928f5783e5202d9849c3a185e29be1d41c63.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-core/initrdscripts/files/init-live.sh | 11 ---
1 file changed, 11 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh
b/meta/recipes-core/initrdscripts/files/init-live.sh
index 2639308..5682fd1 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -2,17 +2,6 @@
PATH=/sbin:/bin:/usr/sbin:/usr/bin
-emergency_shell()
-{
-echo Bug in initramfs /init detected. Dropping to a shell. Good luck!
-echo
-sh
-}
-trap emergency_shell 0 2
-
-# exit immediately if a command fails
-set -e
-
ROOT_MOUNT=/rootfs/
ROOT_IMAGE=rootfs.img
MOUNT=/bin/mount
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Fix invalid test for network error
On 10/01/2012 07:17 AM, Bogdan Marinescu wrote: The test for network error in sanity.bbclass was negated. Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com --- meta/classes/sanity.bbclass |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index e2095dd..f2e9a74 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -174,7 +174,7 @@ def check_sanity_tmpdir_change(tmpdir, data): # Check that we can fetch from various network transports errmsg = check_connectivity(data) testmsg = testmsg + check_connectivity(data) -return testmsg, errmsg == +return testmsg, errmsg != def check_sanity_version_change(data): # Sanity checks to be done when SANITY_VERSION changes Merged into OE-Core with update subject Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libpcap: add dependency on libnl
On 10/01/2012 09:20 AM, Ross Burton wrote:
libpcap uses libnl on Linux to support sniffing mac80211 devices, which could be
useful.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-connectivity/libpcap/libpcap.inc |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc
b/meta/recipes-connectivity/libpcap/libpcap.inc
index 7d4e841..5381ef0 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -8,12 +8,12 @@ SECTION = libs/network
LICENSE = BSD
LIC_FILES_CHKSUM = file://LICENSE;md5=1d4b0366557951c84a94fabe3529f867 \
file://pcap.h;beginline=1;endline=34;md5=8d6cf7e17d5745010d633e30bc529ea9
-DEPENDS = flex-native bison-native
+DEPENDS = flex-native bison-native libnl
PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'bluetooth', 'bluetooth',
'', d)}
PACKAGECONFIG[bluetooth] = --enable-bluetooth,--disable-bluetooth,bluez4
-INC_PR = r2
+INC_PR = r3
SRC_URI = http://www.tcpdump.org/release/libpcap-${PV}.tar.gz;
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libart-lgpl: add art_config.h for mipsel
On 10/02/2012 08:02 AM, Phil Blundell wrote: Fixes: WARNING: Unable to get checksum for libart-lgpl SRC_URI entry art_config.h: file could not be found which otherwise happens during parsing, even if libart-lgpl isn't being built. Signed-off-by: Phil Blundell ph...@gnu.org --- meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h diff --git a/meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h b/meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h new file mode 100644 index 000..b0e74ad --- /dev/null +++ b/meta/recipes-gnome/gnome/libart-lgpl/mipsel/art_config.h @@ -0,0 +1,10 @@ +/* Automatically generated by gen_art_config.c */ + +#define ART_SIZEOF_CHAR 1 +#define ART_SIZEOF_SHORT 2 +#define ART_SIZEOF_INT 4 +#define ART_SIZEOF_LONG 4 + +typedef unsigned char art_u8; +typedef unsigned short art_u16; +typedef unsigned int art_u32; Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][denzil] openjade-native: fix undefined Getopts error, use std namespace
From: Dennis Lan dennis.y...@gmail.com
Using Gentoo Linux as the build host, it fails without this patch
Use Getopt::Std in place of getopts.pl.
https://bugs.gentoo.org/show_bug.cgi?id=420083
which following error:
/usr/bin/perl -w ./../msggen.pl -l jstyleModule InterpreterMessages.msg
/usr/bin/perl -w ./../msggen.pl -l jstyleModule DssslAppMessages.msg
Undefined subroutine main::Getopts called at ./../msggen.pl line 22.
make[2]: *** [InterpreterMessages.h] Error 2
make[2]: *** Waiting for unfinished jobs
Undefined subroutine main::Getopts called at ./../msggen.pl line 22.
make[2]: *** [DssslAppMessages.h] Error 2
(from OE-Core rev 169a89b10817b742c063fcd76721e4dbbcca6199)
Signed-off-by: Dennis Lan dennis.y...@gmail.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
.../openjade/openjade-1.3.2/msggen.pl.patch| 44
.../openjade/openjade-native_1.3.2.bb |3 +-
2 files changed, 46 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/openjade/openjade-1.3.2/msggen.pl.patch
diff --git a/meta/recipes-devtools/openjade/openjade-1.3.2/msggen.pl.patch
b/meta/recipes-devtools/openjade/openjade-1.3.2/msggen.pl.patch
new file mode 100644
index 000..b47fd46
--- /dev/null
+++ b/meta/recipes-devtools/openjade/openjade-1.3.2/msggen.pl.patch
@@ -0,0 +1,44 @@
+commit fcc5b94f118495b1a467edcda6c6f631691c3f69
+Author: Dennis Lan dennis.y...@gmail.com
+Date: Tue Jul 3 09:25:42 2012 +0800
+
+openjade: fix undefined Getopts error, use std namespace
+
+Using Gentoo Linux as the build host, it fails without this patch
+Use Getopt::Std in place of getopts.pl.
+
+Upstream-Status: Inappropriate [no upstream]
+Original-Author-By: Mike Gilbert flop...@gentoo.org
+Signed-off-by: Dennis Lan dennis.y...@gmail.com
+
+diff --git a/msggen.pl b/msggen.pl
+index 0c33968..2ee3f66 100644
+--- a/msggen.pl
b/msggen.pl
+@@ -4,6 +4,7 @@
+ # See the file COPYING for copying permission.
+
+ use POSIX;
++use Getopt::Std;
+
+ # Package and version.
+ $package = 'openjade';
+@@ -18,8 +19,7 @@ $gen_c = 0;
+ undef $opt_l;
+ undef $opt_p;
+ undef $opt_t;
+-do 'getopts.pl';
+-Getopts('l:p:t:');
++getopts('l:p:t:');
+ $module = $opt_l;
+ $pot_file = $opt_p;
+
+@@ -72,7 +72,7 @@ while (DEF) {
+ else {
+ $field[0] =~ /^[IWQXE][0-9]$/ || error(invalid first field);;
+ $type[$num] = substr($field[0], 0, 1);
+- $argc = int(substr($field[0], 1, 1));
++ $argc = substr($field[0], 1, 1);
+ }
+ $nargs[$num] = $argc;
+ $field[1] =~ /^[a-zA-Z_][a-zA-Z0-9_]+$/ || error(invalid tag);
diff --git a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
index 5b29c1f..a539c35 100644
--- a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
+++ b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
@@ -7,13 +7,14 @@ SECTION = base
LICENSE = BSD
LIC_FILES_CHKSUM = file://COPYING;md5=641ff1e4511f0a87044ad42f87cb1045
-PR = r4
+PR = r5
DEPENDS = opensp-native sgml-common-native
RDEPENDS_${PN} = sgml-common-native
SRC_URI = ${SOURCEFORGE_MIRROR}/openjade/openjade-${PV}.tar.gz \
file://makefile.patch \
+ file://msggen.pl.patch \
file://reautoconf.patch \
file://user-declared-default-constructor.patch
--
1.7.8.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][denzil] openssl: add deprecated and unmaintained find.pl from perl-5.14 to fix perlpath.pl
From: Martin Jansa martin.ja...@gmail.com
* openembedded-core/meta/recipes-connectivity/openssl/openssl.inc
*
* is using perlpath.pl:
*
* do_configure () {
* cd util
* perl perlpath.pl ${STAGING_BINDIR_NATIVE}
* ...
*
* and perlpath.pl is using find.pl:
* openssl-1.0.0i/util/perlpath.pl:
* #!/usr/local/bin/perl
* #
* # modify the '#!/usr/local/bin/perl'
* # line in all scripts that rely on perl.
* #
*
* require find.pl;
* ...
*
* which was removed in perl-5.16.0 and marked as deprecated and
* unmaintained in 5.14 and older:
* /tmp/usr/lib/perl5/5.14.2/find.pl:
* warn Legacy library @{[(caller(0))[6]]} will be removed from the Perl
* core distribution in the next major release. Please install it from the
* CPAN distribution Perl4::CoreLibs. It is being used at @{[(caller)[1]]},
* line @{[(caller)[2]]}.\n;
*
* # This library is deprecated and unmaintained. It is included for
* # compatibility with Perl 4 scripts which may use it, but it will be
* # removed in a future version of Perl. Please use the File::Find module
* # instead.
(from OE-Core rev c09bf5d177a7ecd2045ef7e13fff4528137a9775)
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../openssl/openssl-1.0.0i/find.pl | 54 ++
.../recipes-connectivity/openssl/openssl_1.0.0i.bb | 7 ++-
2 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-connectivity/openssl/openssl-1.0.0i/find.pl
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0i/find.pl
b/meta/recipes-connectivity/openssl/openssl-1.0.0i/find.pl
new file mode 100644
index 000..8e1b42c
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl-1.0.0i/find.pl
@@ -0,0 +1,54 @@
+warn Legacy library @{[(caller(0))[6]]} will be removed from the Perl core
distribution in the next major release. Please install it from the CPAN
distribution Perl4::CoreLibs. It is being used at @{[(caller)[1]]}, line
@{[(caller)[2]]}.\n;
+
+# This library is deprecated and unmaintained. It is included for
+# compatibility with Perl 4 scripts which may use it, but it will be
+# removed in a future version of Perl. Please use the File::Find module
+# instead.
+
+# Usage:
+# require find.pl;
+#
+# find('/foo','/bar');
+#
+# sub wanted { ... }
+# where wanted does whatever you want. $dir contains the
+# current directory name, and $_ the current filename within
+# that directory. $name contains $dir/$_. You are cd'ed
+# to $dir when the function is called. The function may
+# set $prune to prune the tree.
+#
+# For example,
+#
+# find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune
+#
+# corresponds to this
+#
+# sub wanted {
+# /^\.nfs.*$/
+# (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_))
+# int(-M _) 7
+# unlink($_)
+# ||
+# ($nlink || (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)))
+# $dev 0
+# ($prune = 1);
+# }
+#
+# Set the variable $dont_use_nlink if you're using AFS, since AFS cheats.
+
+use File::Find ();
+
+*name = *File::Find::name;
+*prune = *File::Find::prune;
+*dir = *File::Find::dir;
+*topdir= *File::Find::topdir;
+*topdev= *File::Find::topdev;
+*topino= *File::Find::topino;
+*topmode = *File::Find::topmode;
+*topnlink = *File::Find::topnlink;
+
+sub find {
+File::Find::find(\wanted, @_);
+}
+
+1;
diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb
b/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb
index ca15a38..c233ba1 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb
@@ -6,7 +6,7 @@ DEPENDS += ocf-linux
CFLAG += -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
-PR = ${INC_PR}.2
+PR = ${INC_PR}.3
LIC_FILES_CHKSUM = file://LICENSE;md5=f9a8f968107345e0b75aa8c2ecaa7ec8
@@ -29,6 +29,7 @@ SRC_URI += file://configure-targets.patch \
file://debian/no-symbolic.patch \
file://debian/debian-targets.patch \
file://openssl_fix_for_x32.patch \
+file://find.pl \
SRC_URI[md5sum] = b4df9c11af454fd68178c85a1d5f328f
@@ -43,3 +44,7 @@ FILES_${PN}-engines = ${libdir}/ssl/engines/*.so
${libdir}/engines
FILES_${PN}-engines-dbg = ${libdir}/ssl/engines/.debug
PARALLEL_MAKEINST =
+
+do_configure_prepend() {
+ cp ${WORKDIR}/find.pl ${S}/util/find.pl
+}
--
1.7.12
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] linux-yocto-custom: Clarify defconfig usage
It is necessary to supply file://defconfig to the SRC_URI when using a defconfig (it is not implicitly understood as the commentary might currently suggest). Signed-off-by: Darren Hart dvh...@linux.intel.com CC: Bruce Ashfield bruce.ashfi...@windriver.com --- meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb index 1f0b3a2..4115d2f 100644 --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb @@ -13,7 +13,8 @@ # # You must also provide a Linux kernel configuration. The most direct # method is to copy your .config to files/defconfig in your layer, -# in the same directory as the bbappend. +# in the same directory as the bbappend and add file://defconfig to +# your SRC_URI. # # To use the yocto kernel tooling to generate a BSP configuration # using modular configuration fragments, see the yocto-bsp and -- 1.7.11.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-yocto-custom: Clarify defconfig usage
On 12-10-03 12:36 AM, Darren Hart wrote: It is necessary to supply file://defconfig to the SRC_URI when using a defconfig (it is not implicitly understood as the commentary might currently suggest). Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com Signed-off-by: Darren Hartdvh...@linux.intel.com CC: Bruce Ashfieldbruce.ashfi...@windriver.com --- meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb index 1f0b3a2..4115d2f 100644 --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb @@ -13,7 +13,8 @@ # # You must also provide a Linux kernel configuration. The most direct # method is to copy your .config to files/defconfig in your layer, -# in the same directory as the bbappend. +# in the same directory as the bbappend and add file://defconfig to +# your SRC_URI. # # To use the yocto kernel tooling to generate a BSP configuration # using modular configuration fragments, see the yocto-bsp and ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
