[oe] [meta-python][PATCH 3/3] python-dateutil: add native BBCLASSEXTEND
Signed-off-by: Joshua Lock
---
meta-python/recipes-devtools/python/python-dateutil.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-python/recipes-devtools/python/python-dateutil.inc
b/meta-python/recipes-devtools/python/python-dateutil.inc
index e230f15dd..8cc2373cd 100644
--- a/meta-python/recipes-devtools/python/python-dateutil.inc
+++ b/meta-python/recipes-devtools/python/python-dateutil.inc
@@ -21,3 +21,5 @@ RDEPENDS_${PN}_class-target = "\
${PYTHON_PN}-six \
${PYTHON_PN}-stringold \
"
+
+BBCLASSEXTEND = "native"
--
2.21.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-python][PATCH 2/3] python-attrs: add native BBCLASSEXTEND
Signed-off-by: Joshua Lock
---
meta-python/recipes-devtools/python/python-attrs.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-python/recipes-devtools/python/python-attrs.inc
b/meta-python/recipes-devtools/python/python-attrs.inc
index 1f767ba19..bd0f7ee2c 100644
--- a/meta-python/recipes-devtools/python/python-attrs.inc
+++ b/meta-python/recipes-devtools/python/python-attrs.inc
@@ -12,3 +12,5 @@ RDEPENDS_${PN}_class-target += " \
${PYTHON_PN}-crypt \
${PYTHON_PN}-ctypes \
"
+
+BBCLASSEXTEND = "native"
--
2.21.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-python][PATCH 1/3] python-cffi: add missing RDEPENDS on pycparser
pycparser is a dependency as listed in the installation docs:
https://cffi.readthedocs.io/en/release-1.12/installation.html
Signed-off-by: Joshua Lock
---
meta-python/recipes-devtools/python/python-cffi.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-python/recipes-devtools/python/python-cffi.inc
b/meta-python/recipes-devtools/python/python-cffi.inc
index d86306bac..818d23815 100644
--- a/meta-python/recipes-devtools/python/python-cffi.inc
+++ b/meta-python/recipes-devtools/python/python-cffi.inc
@@ -10,6 +10,7 @@ SRC_URI[sha256sum] =
"041c81822e9f84b1d9c401182e174996f0bae9991f33725d059b771744
RDEPENDS_${PN}_class-target = " \
${PYTHON_PN}-ctypes \
${PYTHON_PN}-io \
+${PYTHON_PN}-pycparser \
${PYTHON_PN}-shell \
"
--
2.21.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] remove True option to getVar calls
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
Signed-off-by: Joshua Lock <joshua.g.l...@intel.com>
---
meta-efl/recipes-efl/efl/edje-fpu.inc| 2 +-
.../lightmediascanner/lightmediascanner_0.5.1.bb | 2 +-
meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb| 2 +-
meta-gnome/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb | 4 ++--
.../recipes-bsp/images/initramfs-kexecboot-klibc-image.bb| 2 +-
meta-initramfs/recipes-bsp/kexecboot/kexecboot-cfg_0.2.bb| 2 +-
meta-initramfs/recipes-devtools/klibc/klcc-cross_2.0.4.bb| 4 ++--
meta-multimedia/recipes-connectivity/rygel/rygel_0.28.2.bb | 4 ++--
meta-networking/recipes-filter/ebtables/ebtables_2.0.10-4.bb | 4 ++--
meta-networking/recipes-kernel/netmap/netmap-modules_git.bb | 6 +++---
.../recipes-support/memcached/memcached_1.4.17.bb| 2 +-
meta-oe/classes/breakpad.bbclass | 6 +++---
meta-oe/classes/gitpkgv.bbclass | 4 ++--
meta-oe/classes/gitver.bbclass | 4 ++--
meta-oe/classes/machine_kernel_pr.bbclass| 2 +-
meta-oe/classes/socorro-syms.bbclass | 8
meta-oe/recipes-benchmark/glmark2/glmark2_git.bb | 2 +-
meta-oe/recipes-connectivity/usbmuxd/usbmuxd_git.bb | 2 +-
meta-oe/recipes-core/fakeroot/fakeroot-native_1.18.4.bb | 2 +-
meta-oe/recipes-core/llvm/llvm.inc | 2 +-
meta-oe/recipes-core/proxy-libintl/proxy-libintl_20100902.bb | 2 +-
meta-oe/recipes-core/toybox/toybox_0.7.1.bb | 4 ++--
meta-oe/recipes-devtools/geany/geany-plugins_1.28.bb | 2 +-
meta-oe/recipes-devtools/nodejs/nodejs_4.6.1.bb | 2 +-
meta-oe/recipes-devtools/tcltk/tk_8.6.6.bb | 2 +-
meta-oe/recipes-devtools/yajl/yajl_2.1.0.bb | 2 +-
meta-oe/recipes-extended/rsyslog/rsyslog_8.22.0.bb | 12 ++--
meta-oe/recipes-graphics/tesseract/tesseract-lang_git.bb | 2 +-
meta-oe/recipes-multimedia/libopus/libopus_1.1.2.bb | 4 ++--
meta-oe/recipes-navigation/navit/navit-fpu.inc | 2 +-
meta-oe/recipes-support/atop/atop_2.2.3.bb | 2 +-
meta-oe/recipes-support/fltk/fltk_1.3.3.bb | 2 +-
meta-oe/recipes-support/libftdi/libftdi_1.3.bb | 2 +-
meta-oe/recipes-support/libssh/libssh_0.7.3.bb | 2 +-
meta-oe/recipes-support/ne10/ne10_1.2.1.bb | 4 ++--
meta-oe/recipes-support/opencv/opencv_2.4.bb | 4 ++--
meta-oe/recipes-support/opencv/opencv_3.1.bb | 4 ++--
meta-oe/recipes-support/openldap/openldap_2.4.44.bb | 2 +-
meta-oe/recipes-support/opensync/wbxml2_0.10.8.bb| 2 +-
meta-oe/recipes-support/poco/poco_1.7.5.bb | 4 ++--
meta-oe/recipes-support/poppler/poppler_0.48.0.bb| 2 +-
meta-oe/recipes-support/postgresql/postgresql.inc| 8
meta-oe/recipes-support/syslog-ng/syslog-ng.inc | 10 +-
meta-python/classes/pypi.bbclass | 8
44 files changed, 78 insertions(+), 78 deletions(-)
diff --git a/meta-efl/recipes-efl/efl/edje-fpu.inc
b/meta-efl/recipes-efl/efl/edje-fpu.inc
index 3f2aacf..32a6daf 100644
--- a/meta-efl/recipes-efl/efl/edje-fpu.inc
+++ b/meta-efl/recipes-efl/efl/edje-fpu.inc
@@ -1,6 +1,6 @@
def get_edje_fpu_setting(bb, d):
-if d.getVar('TARGET_FPU', 1) in [ 'soft' ]:
+if d.getVar('TARGET_FPU') in [ 'soft' ]:
return "--enable-fixed-point"
return ""
diff --git
a/meta-efl/recipes-multimedia/lightmediascanner/lightmediascanner_0.5.1.bb
b/meta-efl/recipes-multimedia/lightmediascanner/lightmediascanner_0.5.1.bb
index 9870fac..d8c6dbb 100644
--- a/meta-efl/recipes-multimedia/lightmediascanner/lightmediascanner_0.5.1.bb
+++ b/meta-efl/recipes-multimedia/lightmediascanner/lightmediascanner_0.5.1.bb
@@ -57,6 +57,6 @@ python populate_packages_prepend () {
pkgs = []
pkgs += do_split_packages(d, oe.path.join(lms_libdir, "plugins"),
'^(.*)\.so$', d.expand('${PN}-plugin-%s'), 'LightMediaScanner plugin for %s',
prepend=True, extra_depends=d.expand('${PN}'))
-metapkg = d.getVar('PN', True) + '-meta'
+metapkg = d.getVar('PN') + '-meta'
d.setVar('RDEPENDS_' + metapkg, ' '.join(pkgs))
}
diff --git a/meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb
b/meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb
index 5052b36..ec17c75 100644
--- a/meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb
+++ b/meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb
@@ -111,7 +111,7 @@ python populate_packages_prepend (
[oe] [PATCH 0/4] Fido pull request
Please consider the following fixes for inclusion in the Fido branch.
- libpcre security fix not required in jethro or master because the newer
version they carry isn't affected
- backport a fix for some memory leaks in rpmresolve
- backport a fix for kernel.bbclass which already exists in jethro & master
- remove a stray tzdata file, this change isn't required for jethro or master as
the file isn't present in those branches
The following changes since commit 4dea3e7b9a0041e7359981e68c561e7de8ad3ae5:
dpkg: Security fix CVE-2015-0860 (2016-02-07 17:22:53 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib joshuagl/fido-next
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/fido-next
Armin Kuster (1):
libpcre: Security fixes and package update.
Mariano Lopez (1):
rpmresolve.c: Fix unfreed pointers that keep DB opened
Markus Lehtonen (1):
kernel.bbclass: do not mv/link sources when externalsrc enabled
Martin Jansa (1):
tzdata: remove 2015d version
meta/classes/kernel.bbclass| 10 +++---
meta/recipes-devtools/rpm/rpmresolve/rpmresolve.c | 10 ++
meta/recipes-extended/tzdata/tzdata_2015d.bb | 6 --
.../libpcre/{libpcre_8.36.bb => libpcre_8.38.bb} | 7 +++
4 files changed, 16 insertions(+), 17 deletions(-)
delete mode 100644 meta/recipes-extended/tzdata/tzdata_2015d.bb
rename meta/recipes-support/libpcre/{libpcre_8.36.bb => libpcre_8.38.bb} (91%)
--
2.5.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH v2] poppler-data: install CMap resources for CJK glyph support
Please don't merge this.
On 01/12/15 20:56, Joshua Lock wrote:
CID-keyed fonts, as commonly used to support pictographic East
Asian character sets require Character Maps which unidirectionally
map character codes (i.e. Unicode encoding) to CID (the glyphs in
the font face).
Without a CMap poppler isn't able to correctly PDF files in
Chinese, Japanese or Korean without embedded fonts.
This change installs a copy of the Identity files from Adobe's
CMap Resources[1] based on a similar change in Fedora's
poppler-data[2][3].
1. https://github.com/adobe-type-tools/cmap-resources
2.
http://pkgs.fedoraproject.org/cgit/poppler-data.git/tree/poppler-data.spec#n18
3. https://bugzilla.redhat.com/show_bug.cgi?id=842351
Signed-off-by: Joshua Lock <joshua.l...@collabora.co.uk>
---
meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
index 4f55e9f..fb8f43d 100644
--- a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
+++ b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
@@ -1,5 +1,7 @@
-SUMMARY = "Poppler is a PDF rendering library based on the xpdf-3.0 code base"
-LICENSE = "Adobe"
+SUMMARY = "Encoding files for Poppler"
+DESCRIPTION = "Encoding files for use with poppler that enable poppler to \
+ correctly render CJK and Cyrrilic."
+LICENSE = "BSD & GPLv2 & GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=4870b98343f0bbb25fa43b9d2ba59448 \
file://COPYING.adobe;md5=63c6a8a9df204c00461fa5f163d8a663
\
file://COPYING.gpl2;md5=751419260aa954499f7abaabaa882bbe \
@@ -7,15 +9,22 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=4870b98343f0bbb25fa43b9d2ba59448 \
inherit allarch
-SRC_URI = "http://poppler.freedesktop.org/${BP}.tar.gz;
+INHIBIT_DEFAULT_DEPS = "1"
+
+SRC_URI = "http://poppler.freedesktop.org/${BP}.tar.gz \
+
https://github.com/adobe-type-tools/cmap-resources/raw/master/cmapresources_identity-0.zip;name=cmap;
This raw URI isn't safe to use and the .zip is no longer present in the
master branch of the repository.
A colleague is in the process of working up an improved version of this
patch with a safer URI.
SRC_URI[md5sum] = "636a8f2b9f6df9e7ced8ec0946961eaf"
SRC_URI[sha256sum] =
"e752b0d88a7aba54574152143e7bf76436a7ef51977c55d6bd9a48dccde3a7de"
+SRC_URI[cmap.md5sum] = "32aab2e25655e475dd58a50479270f91"
+SRC_URI[cmap.sha256sum] =
"3a3b591b7153588a77d1304bcefc1781750a36811cebae03680c85882765f515"
do_compile() {
}
do_install() {
oe_runmake install DESTDIR=${D}
+install -d ${D}${datadir}/poppler/cMap
+install -m644 ${WORKDIR}/cmapresources_identity-0/CMap/Identity-*
${D}${datadir}/poppler/cMap/
}
FILES_${PN} += "${datadir}"
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] poppler-data: install CMap resources for CJK glyph support
On 01/12/15 20:24, Joshua Lock wrote:
CID-keyed fonts, as commonly used to support pictographic East
Asian character sets require Character Maps which unidirectionally
map character codes (i.e. Unicode encoding) to CID (the glyphs in
the font face).
Without a CMap poppler isn't able to correctly PDF files in
Chinese, Japanese or Korean without embedded fonts.
This change installs a copy of the Identity files from Adobe's
CMap Resources[1] based on a similar change in Fedora's
poppler-data[2][3].
1. https://github.com/adobe-type-tools/cmap-resources
2.
http://pkgs.fedoraproject.org/cgit/poppler-data.git/tree/poppler-data.spec#n18
3. https://bugzilla.redhat.com/show_bug.cgi?id=842351
Signed-off-by: Joshua Lock <joshua.l...@collabora.co.uk>
---
meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
index 4f55e9f..5a3f086 100644
--- a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
+++ b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
@@ -1,5 +1,6 @@
SUMMARY = "Poppler is a PDF rendering library based on the xpdf-3.0 code base"
-LICENSE = "Adobe"
+DESCRIPTION = ""
+LICENSE = "BSD && GPLv2 && GPLv3+"
The LICENSE field is incorrect and I didn't fill out description, I'll
fix those and send a v2.
Apologies,
Joshua
LIC_FILES_CHKSUM = "file://COPYING;md5=4870b98343f0bbb25fa43b9d2ba59448 \
file://COPYING.adobe;md5=63c6a8a9df204c00461fa5f163d8a663
\
file://COPYING.gpl2;md5=751419260aa954499f7abaabaa882bbe \
@@ -7,15 +8,22 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=4870b98343f0bbb25fa43b9d2ba59448 \
inherit allarch
-SRC_URI = "http://poppler.freedesktop.org/${BP}.tar.gz;
+INHIBIT_DEFAULT_DEPS = "1"
+
+SRC_URI = "http://poppler.freedesktop.org/${BP}.tar.gz \
+
https://github.com/adobe-type-tools/cmap-resources/raw/master/cmapresources_identity-0.zip;name=cmap;
SRC_URI[md5sum] = "636a8f2b9f6df9e7ced8ec0946961eaf"
SRC_URI[sha256sum] =
"e752b0d88a7aba54574152143e7bf76436a7ef51977c55d6bd9a48dccde3a7de"
+SRC_URI[cmap.md5sum] = "32aab2e25655e475dd58a50479270f91"
+SRC_URI[cmap.sha256sum] =
"3a3b591b7153588a77d1304bcefc1781750a36811cebae03680c85882765f515"
do_compile() {
}
do_install() {
oe_runmake install DESTDIR=${D}
+install -d ${D}${datadir}/poppler/cMap
+install -m644 ${WORKDIR}/cmapresources_identity-0/CMap/Identity-*
${D}${datadir}/poppler/cMap/
}
FILES_${PN} += "${datadir}"
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH v2] poppler-data: install CMap resources for CJK glyph support
CID-keyed fonts, as commonly used to support pictographic East
Asian character sets require Character Maps which unidirectionally
map character codes (i.e. Unicode encoding) to CID (the glyphs in
the font face).
Without a CMap poppler isn't able to correctly PDF files in
Chinese, Japanese or Korean without embedded fonts.
This change installs a copy of the Identity files from Adobe's
CMap Resources[1] based on a similar change in Fedora's
poppler-data[2][3].
1. https://github.com/adobe-type-tools/cmap-resources
2.
http://pkgs.fedoraproject.org/cgit/poppler-data.git/tree/poppler-data.spec#n18
3. https://bugzilla.redhat.com/show_bug.cgi?id=842351
Signed-off-by: Joshua Lock <joshua.l...@collabora.co.uk>
---
meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
index 4f55e9f..fb8f43d 100644
--- a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
+++ b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
@@ -1,5 +1,7 @@
-SUMMARY = "Poppler is a PDF rendering library based on the xpdf-3.0 code base"
-LICENSE = "Adobe"
+SUMMARY = "Encoding files for Poppler"
+DESCRIPTION = "Encoding files for use with poppler that enable poppler to \
+ correctly render CJK and Cyrrilic."
+LICENSE = "BSD & GPLv2 & GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=4870b98343f0bbb25fa43b9d2ba59448 \
file://COPYING.adobe;md5=63c6a8a9df204c00461fa5f163d8a663 \
file://COPYING.gpl2;md5=751419260aa954499f7abaabaa882bbe \
@@ -7,15 +9,22 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=4870b98343f0bbb25fa43b9d2ba59448 \
inherit allarch
-SRC_URI = "http://poppler.freedesktop.org/${BP}.tar.gz;
+INHIBIT_DEFAULT_DEPS = "1"
+
+SRC_URI = "http://poppler.freedesktop.org/${BP}.tar.gz \
+
https://github.com/adobe-type-tools/cmap-resources/raw/master/cmapresources_identity-0.zip;name=cmap;
SRC_URI[md5sum] = "636a8f2b9f6df9e7ced8ec0946961eaf"
SRC_URI[sha256sum] =
"e752b0d88a7aba54574152143e7bf76436a7ef51977c55d6bd9a48dccde3a7de"
+SRC_URI[cmap.md5sum] = "32aab2e25655e475dd58a50479270f91"
+SRC_URI[cmap.sha256sum] =
"3a3b591b7153588a77d1304bcefc1781750a36811cebae03680c85882765f515"
do_compile() {
}
do_install() {
oe_runmake install DESTDIR=${D}
+install -d ${D}${datadir}/poppler/cMap
+install -m644 ${WORKDIR}/cmapresources_identity-0/CMap/Identity-*
${D}${datadir}/poppler/cMap/
}
FILES_${PN} += "${datadir}"
--
2.4.3
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] poppler-data: install CMap resources for CJK glyph support
CID-keyed fonts, as commonly used to support pictographic East
Asian character sets require Character Maps which unidirectionally
map character codes (i.e. Unicode encoding) to CID (the glyphs in
the font face).
Without a CMap poppler isn't able to correctly PDF files in
Chinese, Japanese or Korean without embedded fonts.
This change installs a copy of the Identity files from Adobe's
CMap Resources[1] based on a similar change in Fedora's
poppler-data[2][3].
1. https://github.com/adobe-type-tools/cmap-resources
2.
http://pkgs.fedoraproject.org/cgit/poppler-data.git/tree/poppler-data.spec#n18
3. https://bugzilla.redhat.com/show_bug.cgi?id=842351
Signed-off-by: Joshua Lock <joshua.l...@collabora.co.uk>
---
meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
index 4f55e9f..5a3f086 100644
--- a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
+++ b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
@@ -1,5 +1,6 @@
SUMMARY = "Poppler is a PDF rendering library based on the xpdf-3.0 code base"
-LICENSE = "Adobe"
+DESCRIPTION = ""
+LICENSE = "BSD && GPLv2 && GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=4870b98343f0bbb25fa43b9d2ba59448 \
file://COPYING.adobe;md5=63c6a8a9df204c00461fa5f163d8a663 \
file://COPYING.gpl2;md5=751419260aa954499f7abaabaa882bbe \
@@ -7,15 +8,22 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=4870b98343f0bbb25fa43b9d2ba59448 \
inherit allarch
-SRC_URI = "http://poppler.freedesktop.org/${BP}.tar.gz;
+INHIBIT_DEFAULT_DEPS = "1"
+
+SRC_URI = "http://poppler.freedesktop.org/${BP}.tar.gz \
+
https://github.com/adobe-type-tools/cmap-resources/raw/master/cmapresources_identity-0.zip;name=cmap;
SRC_URI[md5sum] = "636a8f2b9f6df9e7ced8ec0946961eaf"
SRC_URI[sha256sum] =
"e752b0d88a7aba54574152143e7bf76436a7ef51977c55d6bd9a48dccde3a7de"
+SRC_URI[cmap.md5sum] = "32aab2e25655e475dd58a50479270f91"
+SRC_URI[cmap.sha256sum] =
"3a3b591b7153588a77d1304bcefc1781750a36811cebae03680c85882765f515"
do_compile() {
}
do_install() {
oe_runmake install DESTDIR=${D}
+install -d ${D}${datadir}/poppler/cMap
+install -m644 ${WORKDIR}/cmapresources_identity-0/CMap/Identity-*
${D}${datadir}/poppler/cMap/
}
FILES_${PN} += "${datadir}"
--
2.4.3
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] xerces-c: enable a native variant with BBCLASSEXTEND
Signed-off-by: Joshua Lock <joshua.l...@collabora.co.uk>
---
meta-oe/recipes-devtools/xerces-c/xerces-c_3.1.2.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-oe/recipes-devtools/xerces-c/xerces-c_3.1.2.bb
b/meta-oe/recipes-devtools/xerces-c/xerces-c_3.1.2.bb
index 8699d6f..165cb55 100644
--- a/meta-oe/recipes-devtools/xerces-c/xerces-c_3.1.2.bb
+++ b/meta-oe/recipes-devtools/xerces-c/xerces-c_3.1.2.bb
@@ -37,3 +37,5 @@ FILES_libxerces-c-dev = "${libdir}/lib*.la \
FILES_xerces-c-samples = "${bindir}/*"
FILES_xerces-c-samples-dbg = "${bindir}/.debug/"
FILES_libxerces-c-staticdev = "${libdir}/lib*.a"
+
+BBCLASSEXTEND = "native"
--
2.1.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][master][fido][PATCH] gsoap: fix DEPENDS to prevent link failure for gsoap-native
With a fairly high number of threads I can reliably trigger the
following linker failure in gsoap-native:
| /usr/bin/ld: cannot find -ly
| collect2: error: ld returned 1 exit status
| Makefile:402: recipe for target 'soapcpp2' failed
Change the DEPENDS to include bison and let the BBCLASSEXTENDS
machinery fix DEPENDS for -native and -target variants, only
additonally adding gsoap-native to the DEPENDS for the target
recipe.
Signed-off-by: Joshua Lock <joshua.l...@collabora.co.uk>
---
meta-oe/recipes-support/gsoap/gsoap_2.8.12.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-support/gsoap/gsoap_2.8.12.bb
b/meta-oe/recipes-support/gsoap/gsoap_2.8.12.bb
index b5c3995..6da08ac 100644
--- a/meta-oe/recipes-support/gsoap/gsoap_2.8.12.bb
+++ b/meta-oe/recipes-support/gsoap/gsoap_2.8.12.bb
@@ -20,8 +20,8 @@ PARALLEL_MAKE = ""
EXTRA_OEMAKE_class-target = "SOAP=${STAGING_BINDIR_NATIVE}/soapcpp2"
-DEPENDS_class-target = "gsoap-native openssl zlib"
-DEPENDS_class-native = "flex-native"
+DEPENDS = "openssl zlib flex bison"
+DEPENDS_append_class-target = " gsoap-native"
do_install_append() {
install -d ${D}${libdir}
--
2.1.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] requires on own .bb file
On 16/04/12 01:42, Giuseppe Condorelli wrote: Hi all, I wrote a personal .bb file and added it on the meta-myproject tree. This .bb file requires a .inc file already available in the native oe-core meta directory. How can I include it into my .bb file? If I add requireblablabla.inc it fails because it is not able to found the given .inc file. In other words I need to copy it into the meta-myproject tree. The require line should be a path relative to a BBPATH entry. For e.g. if I wanted to use the dbus.inc I would: require recipes-core/dbus/dbus.inc Cheers, Joshua -- Joshua Lock Yocto Project Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][RFC 00/27] systemd / initmanager rework
On 07/02/12 07:55, Otavio Salvador wrote:
On Tue, Feb 7, 2012 at 13:12, Andreas Müller
schnitzelt...@googlemail.comwrote:
* These are my first python experiences - suggestions welcome.
* In local.conf (or in distro) the configuration variable INIT_MANAGER
selects
the initmanager to be build into an image. When changing the selection,
a build from scratch is required. INIT_MANAGER currently defaults to
systemd
(see image.bbclass and initmanager.bbclass)
* In systemd.bbclass debug messages were left in to have a better overview
what's going on.
* An additional patch series goes out for meta-angstrom.
* This is a huge RFC which might cause serious impacts. What I have already
detected after a build from scatch is that /var/lib/opkg is missing in the
image (although it can be found in libopkg.ipk). I will spend the next
days with my new friend buildhistory (thanks for this!!).
I've looked at your changes and they does seem to be a good base for
further work:
I agree, good job!
* The init system ought to be a DISTRO_FEATURE (as sysvinit ought to be too
IMO)
I know there's some disagreement with the suggestion that the init
system ought to be a DISTRO_FEATURE but my (admittedly uninformed)
opinion is that I can't see how we can avoid it.
It looks like systemd provides various interfaces and API's that
packages may or may not use and as more packages adopt these we're going
to need to be able to enable/disable more than just some unit
files/scripts for init support.
* I'd like to see sysvinit packages splitted onto ${PN}-sysvinit as well
Agreed. Do we need to think about the case where a systemd based system
might *need* an initscript (no units available) vs. when the -sysvinit
and -systemd packages both provide similar functionality?
Would it be desirable for the rootfs generation logic to be able to fall
back to an alternative initscript provider?
* I'd use rootfs generation to install ${PN}-${INIT_SYSTEM} packages for
packages being installed
Thoughts?
Cheers,
Joshua
--
Joshua Lock
Yocto Project Johannes factotum
Intel Open Source Technology Centre
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] Otavio Salvador : systemd.bbclass: depends on systemd
On 03/02/12 18:18, Khem Raj wrote:
On (04/02/12 03:00), Andreas Müller wrote:
Which recipes really depend on systemd during build? I know about
polkit, something else?
why not make it a globally selectable ?
so we can make sure that autoconf does not try to guess
but we tell it if systemd features should {en|dis}abled
explicitly and something like virtual/init-manager or something
since I think it has to coexist with sysvinit or upstart
whatever one chooses.
We should definitely do this, I've not had enough time to figure out. I
think it's going to have to be a distro level thing as so far as I can
tell we need to be able to:
o set the init system
o include certain packages
o potentially enable/disable configure flags
I've not had much opportunity to look into this yet but we need to be
certain whichever mechanism we enable works for systemd, sysvinit,
upstart, s6, whatever.
Cheers,
Joshua
--
Joshua Lock
Yocto Project Johannes factotum
Intel Open Source Technology Centre
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Recommended Ångström/oe-core image to start , for a graphic application ?
On 01/02/12 16:47, Ulf Samuelsson wrote: With openembedded classic, I have mostly been using derivatives of x11-gpe-image for demos. What is close to this image in functionaliy with Angstrom/openembedded core. Tried booting core-image-sato, but that did not even have a shell... Define shell? core-image-sato has a terminal emulator and the ash shell from busybox. Cheers, Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] How to prevent fetching?
On Wed, 2011-08-31 at 11:25 -0600, Dave Beal wrote: My company is using OE to develop the embedded Linux infrastructure of a medical device. The US government agency that approves such devices (FDA) requires that its source code be strictly controlled. We would like to configure our OE installation to prevent the fetching of new source code except when we explicitly allow it. Is there a way to accomplish this that doesn't require modifying all the individual .bb files? Is there a global configuration option that would prevent fetching? I've looked through the OE and Bitbake User Manuals, but haven't found an answer. If you're using relatively recent BitBake and your metadata uses fetch2 (I don't know if oe.dev does, but oe-core is using fetch2) you can set BB_NO_NETWORK=1 in a conf file somewhere. Regards, Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] How to prevent fetching?
On Wed, 2011-08-31 at 15:18 -0600, Dave Beal wrote: Thank you, Joshua. I don't know what you mean by if your metadata uses fetch2. Is fetch2 some python function? How would I know if I'm using it? Fetch2 is a Python module that's part of BitBake. It's used from the base_do_fetch() method of base.bbclass. You can see that OE.dev isn't using fetch2[1] but OE-Core is[2]. Joshua 1. http://git.openembedded.org/cgit.cgi/openembedded/tree/classes/base.bbclass#n99 2. http://git.openembedded.org/cgit.cgi/openembedded-core/tree/meta/classes/base.bbclass#n80 -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core][meta-oe] Problems on downloading sources (was [OE-core] Problems downloading xfwm4 4.8.1)
On Wed, 2011-07-20 at 00:38 +0200, Andreas Mueller wrote: On Monday, July 18, 2011 11:19:01 PM Andreas Mueller wrote: On Monday, July 18, 2011 11:10:55 PM you wrote: Ciao currently I am porting my local oe recipes for xfce-4.8 to oe-core. Everything seems fine so far - except xfwm4. This one drives me totally insane: If you check the fetch log attched and copy the first url into a browser it starts downloading without problems but oe complains. Could somebody please point me onto what is going wrong - if you need further information I'll send... I found a hook on what is going wrong - forget my prevoius mail - sorry fo the noise.. Sorry but my 'hook' was some late night crap. I attached what I did up to now. It is meta-xfce which should live in meta- openembedded. I checked on fresh tmp and without downloaded sources. For (at least) xfwm4 and xfce4-appfinder build fails when downloading sources. For xfce4- appfinder I get: ERROR: Function 'Fetcher failure for URL: 'http://archive.xfce.org/src/xfce/xfce4-appfinder/4.8/xfce4- appfinder-4.8.0.tar.bz2'. Unable to fetch URL http://archive.xfce.org/src/xfce/xfce4-appfinder/4.8/xfce4-appfinder-4.8.0.tar.bz2 from any source.' failed ERROR: Logfile of failure stored in: /home/Superandy/tmp/oe-core- eglibc/work/armv7a-angstrom-linux-gnueabi/xfce4-appfinder-4.8.0- r0/temp/log.do_fetch.30009 Log data follows: | NOTE: fetch http://archive.xfce.org/src/xfce/xfce4-appfinder/4.8/xfce4- appfinder-4.8.0.tar.bz2 | NOTE: fetch http://www.angstrom-distribution.org/unstable/sources/xfce4- appfinder-4.8.0.tar.bz2 | ERROR: Function 'Fetcher failure for URL: 'http://archive.xfce.org/src/xfce/xfce4-appfinder/4.8/xfce4- appfinder-4.8.0.tar.bz2'. Unable to fetch URL http://archive.xfce.org/src/xfce/xfce4-appfinder/4.8/xfce4-appfinder-4.8.0.tar.bz2 from any source.' failed NOTE: package xfce4-appfinder-4.8.0-r0: task do_fetch: Failed If I enter http://archive.xfce.org/src/xfce/xfce4-appfinder/4.8/xfce4- appfinder-4.8.0.tar.bz2 in my browser or perform wget manually, the source file is downloaded properly!! Could somebody please spend some time with the attachment and tell me what's going on here?? I'd guess it's Yocto #1256[1], namely that fetcher reports a download failure when only the SRC_URI checksums mismatched The idea is that the fetcher retries downloads a few times when the checksums do not match, unfortunately at the default log level this just looks like a fetch failure. Can you run bitbake with -DD and see if you can see a checksum error? Or just verify checksums by hand? Cheers, Joshua 1. http://bugzilla.pokylinux.org/show_bug.cgi?id=1256 -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Yocto Project and OE - Where now?
On Wed, 2011-01-19 at 10:12 +0100, Frans Meulenbroeks wrote: 2011/1/19 Graeme Gregory d...@xora.org.uk: I wholehearthy agree with the proposal that it is left to the package maintainers discretion. Wrt the GPLv2+ version. I suggest to reflect this in the name. E.g. you could have samba and samba-gplv2 (or perhaps samba-gplv2 and samba-gplv3). Then it immediately becomes obvious why there are two versions. Similarly with versions that became a lot fatter over time (which imho is a good reason to keep the old version). I am totally against this idea, it just makes a total mess of the namespace. We have the ability to put comments in bitbake files use it. I don't think there are that many recipes for which this is relevant, so the namespace clutter is limited. Comments in bb files may work equally well. Problem is that those comments are not written in the files. Surely that what the LICENSE field in the metadata is for? Aside: In Poky we have various features to ensure recipes have license information included, and functionality to blacklist packages of a certain license - these will doubtless be merged into oe-core too. Cheers, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Best practice to resolve dependency loops ?
On Fri, 2010-07-09 at 10:49 +0200, Andreas Mueller wrote: On Friday 09 July 2010 10:05:56 am Hauser, Wolfgang (external) wrote: What is the best practice to examine and solve such problems ? I would like to add an additional question: bitbake supports -g for dependency trees in dot syntax. What is the best tool to browse these files. I checked graphviz but this just paints complete unviewable posters. Is there e.g something like a dot to html converter aavialable? You can use the dependency explorer UI built into Bitbake: bitbake -g -u depexp some-task Cheers, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] Maintain compatability with Python 2.4
Hi,
I just found this patch lying around, I forgot to submit it here.
A user contacted me about requiring Python 2.5 features in
relocatable.bbclass when OE claims Python 2.4 support.
I wrote them this patch and haven't heard any complaints back so assume
it works as intended, however I haven't tested it much myself.
When I raised the Python 2.4 vs 2.5 issue a while back it seems the
consensus was to stick to 2.4 support as RHEL still uses it.
Anyone care to merge?
Thanks,
Joshua
--
Joshua Lock
Intel Open Source Technology Centre
From 72399a3064367c92fcb7fe832adca289de0c10b2 Mon Sep 17 00:00:00 2001
From: Joshua Lock j...@linux.intel.com
Date: Mon, 10 May 2010 17:01:35 +0100
Subject: [PATCH] relocatable.bbclass: don't use Python 2.5 features
str.partition() is a new method for Python 2.5, as we claim Pyhton 2.4 or
above is required in the wiki we shouldn't use methods which aren't available
in Python 2.4.
This patch adds a (horrible) method, string_after() to replace the use of
str.partition()
Signed-off-by: Joshua Lock j...@linux.intel.com
---
classes/relocatable.bbclass | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/classes/relocatable.bbclass b/classes/relocatable.bbclass
index eb5b9e6..cb82315 100644
--- a/classes/relocatable.bbclass
+++ b/classes/relocatable.bbclass
@@ -3,6 +3,11 @@ SYSROOT_PREPROCESS_FUNCS += relocatable_binaries_preprocess
CHRPATH_BIN ?= chrpath
PREPROCESS_RELOCATE_DIRS ?=
+def string_after(target, split):
+target = target.strip().lstrip()
+tmp = target[target.rfind(split):len(target)]
+return tmp[len(split):len(target)]
+
def process_dir (directory, d):
import subprocess as sub
import stat
@@ -44,7 +49,7 @@ def process_dir (directory, d):
continue
# Throw away everything other than the rpath list
-curr_rpath = err.partition(RPATH=)[2]
+curr_rpath = string_after(err, RPATH=)
#bb.note(Current rpath for %s is %s % (fpath, curr_rpath.strip()))
rpaths = curr_rpath.split(:)
new_rpaths = []
@@ -55,15 +60,12 @@ def process_dir (directory, d):
# If the rpath shares a root with base_prefix determine a new dynamic rpath from the
# base_prefix shared root
if rpath.find(basedir) != -1:
-depth = fpath.partition(basedir)[2].count('/')
-libpath = rpath.partition(basedir)[2].strip()
+depth = string_after(fpath, basedir).count('/')
+libpath = string_after(rpath, basedir).strip()
# otherwise (i.e. cross packages) determine a shared root based on the TMPDIR
-# NOTE: This will not work reliably for cross packages, particularly in the case
-# where your TMPDIR is a short path (i.e. /usr/poky) as chrpath cannot insert an
-# rpath longer than that which is already set.
else:
-depth = fpath.rpartition(tmpdir)[2].count('/')
-libpath = rpath.partition(tmpdir)[2].strip()
+depth = string_after(rpath, tmpdir).count('/')
+libpath = string_after(rpath, tmpdir).strip()
base = $ORIGIN
while depth 1:
@@ -74,7 +76,7 @@ def process_dir (directory, d):
# if we have modified some rpaths call chrpath to update the binary
if len(new_rpaths):
args = :.join(new_rpaths)
-#bb.note(Setting rpath for %s to %s %(fpath,args))
+#bb.note(Setting rpath for %s to %s %(fpath, args))
sub.call([cmd, '-r', args, fpath])
if perms:
--
1.6.6.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Supported Python version for OE?
On Tue, 2010-05-11 at 09:23 +0100, Martyn Welch wrote: Joshua Lock wrote: Hi, A question, (perhaps for the TSC?): What's the minimum Python version we want to support in OE? According to the wiki we support Python 2.4 and above but I wonder if people have any thoughts with regards to bumping it? I'd suggest that the better question to ask is: Which versions of which distros do we currently intend OE to work on? That's a good way to re-phrase it. Given that the revisions of Python for the following distributions are as follows: Ubuntu 10.04 LTS - 2.6.5 Ubuntu 8.04 LTS - 2.5.2 Debian lenny (stable) - 2.5.2 Debian squeeze (testing) - 2.5.3 Debian sid (unstable) - 2.5.4 Debian etch (oldstable) - 2.4.4 Fedora 12 - 2.6.2 Fedora 11 - 2.6 Fedora 10 - 2.5.2 Fedora 9 - 2.5.1 Fedora 8 - 2.5.1 Fedora 7 - 2.5 Fedora 6 - 2.4.3 RHEL6 (beta) - 2.6.2 RHEL5 - 2.4.3 OpenSUSE 11.2 - 2.6.2 OpenSUSE 11.1 - 2.6.0 OpenSUSE 11.0 - 2.5.2 This would suggest that using 2.5 features should be ok for the majority of people. My one area of concern would be those using RHEL. RHEL 6 isn't out yet and v.5 uses 2.4.3 - this wouldn't impact me, so I'm not overly fussed. Hmm, thanks for the data. I'm not overly fussed either but suspect that supporting RHEL5 is a desire for at least a while after RHEL6 comes out? The reason I ask is because I had a user contact me about using Python 2.5 features (str.partition) in relocatable.bbclass, I hadn't even noticed this and seems like not many others have but it's clearly affecting at least one person. I have a pretty trivial (if ugly) patch to work around this, but it raised an interesting question so I thought I'd ask that before sending the patch. The only other question I can think of is is there an advantage to using the Python 2.5 features?. Only that it's less code and that the code is more thoroughly tested. The patch was just what prompted me to question a Python 2.4 dependency. Thanks, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Supported Python version for OE?
Hi, A question, (perhaps for the TSC?): What's the minimum Python version we want to support in OE? According to the wiki we support Python 2.4 and above but I wonder if people have any thoughts with regards to bumping it? The reason I ask is because I had a user contact me about using Python 2.5 features (str.partition) in relocatable.bbclass, I hadn't even noticed this and seems like not many others have but it's clearly affecting at least one person. I have a pretty trivial (if ugly) patch to work around this, but it raised an interesting question so I thought I'd ask that before sending the patch. Cheers, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Request for branch merge
On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-04-10 17:33, Richard Purdie wrote: I've been aware that Poky and OE have been diverging slightly and I'd like to correct this. There are some patches that I've promised for a while too such as the rename from do_populate_staging - do_populate_sysroot. With some help from Joshua Lock, I have a branch I'd like to propose be merged into OE.dev: http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and my issue with chrpath, which only leaves the cross staging lamangler stuff to get fixed. I've just pushed an updated version of the tree with the recent Poky changes you have observed and a merge of the autotools.bbclass to get the lamangler stuff. It builds a console-image fine here but the testing hasn't been stringent as of yet. Cheers, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Request for branch merge
On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote: On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-04-10 17:33, Richard Purdie wrote: I've been aware that Poky and OE have been diverging slightly and I'd like to correct this. There are some patches that I've promised for a while too such as the rename from do_populate_staging - do_populate_sysroot. With some help from Joshua Lock, I have a branch I'd like to propose be merged into OE.dev: http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and my issue with chrpath, which only leaves the cross staging lamangler stuff to get fixed. Actually (and I'm OK with binconfig stuff being broken in the first merge) the problem with binconfig junk isn't the file contents, but the file location. staging-target-pkg will contain staging/host/usr/bin/target/foo-config. Which means using pstaging for a target pkg built on 32bit Linux fails when used on 64bit Linux. Not that I wouldn't mind seeing the binconfig stuff die, just saying it's a problem today :) Ah, hmm... yes. That is a problem. FWIW I don't think you'll get any arguments from the Poky team where the binconfig stuff to suffer an untimely demise! Cheers, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Request for branch merge
On Sat, 2010-04-03 at 09:23 +0200, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02-04-10 23:29, Richard Purdie wrote: On Fri, 2010-04-02 at 15:40 +0200, Koen Kooi wrote: While testing (rebased on top of this mornings OE, bitbake master) I'm getting messages like this: //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so: RPATH=/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so: new RPATH: $ORIGIN/../../../../usr/lib open: Permission denied elf_open: Invalid argument This looks like we're calling chrpath -l against a non-readable file, as Richard suggested. Unfortunately it's not the echoed path which is the problem, the path for which the open/elf_open warnings are triggered is not echoed... I've a patch to test the access to the file and temporarily set read and write permissions on it if needed. I'm just running this updated tree over a build of console-image now. Cheers, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] Joshua Lock : packaged-staging: enhancements from Poky for fetching and relocatability
On Tue, 2010-04-06 at 08:25 -0700, Chris Larson wrote: On Tue, Apr 6, 2010 at 8:09 AM, Tom Rini tom_r...@mentor.com wrote: On Tue, 2010-04-06 at 15:35 +0100, Joshua Lock wrote: On Thu, 2010-04-01 at 15:21 -0700, Tom Rini wrote: On Thu, 2010-04-01 at 13:44 +, git version control wrote: Module: openembedded.git Branch: rpurdie/work-in-progress Commit: ccbb586b3cfdc723ccad73dd71d85f6d41f0e6a3 URL: http://gitweb.openembedded.net/?p=openembedded.gita=commit;h=ccbb586b3cfdc723ccad73dd71d85f6d41f0e6a3 Author: Joshua Lock j...@linux.intel.com Date: Wed Mar 31 11:22:02 2010 +0100 packaged-staging: enhancements from Poky for fetching and relocatability Question. Do we really want to rename DEPLOY_DIR_PSTAGE to PSTAGE_DIR. Is that really a nomenclature change like that? I see it's still soft assign so outsideof TMPDIR can work still, so it's fine otherwise. Just checking. I changed the name because we now have two pstage directories and wanted the change to be apparent and I dropped the DEPLOY_ prefix as I moved the default location outside of the deploy dir. Does that seem reasonable? I think so, but I must be missing something. Are you talking about the dir where we assemble packages as the 2nd one? Or something else? Haven't made my coffee yet today... I haven't looked at the patches in a while, but from what I recall, he splits the dir where the pstage .ipk files go from the rest of the files that cluttered up DEPLOY_DIR_PSTAGE. I could be remembering incorrectly, of course (do that a *lot* :). My memory is recalling the same thing ;-) Cheers, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Request for branch merge
On Thu, 2010-04-01 at 10:37 -0600, Gary Thomas wrote:
On 04/01/2010 09:33 AM, Richard Purdie wrote:
I've been aware that Poky and OE have been diverging slightly and I'd
like to correct this. There are some patches that I've promised for a
while too such as the rename from do_populate_staging -
do_populate_sysroot.
With some help from Joshua Lock, I have a branch I'd like to propose be
merged into OE.dev:
http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
Not much luck with this I'm afraid.
Whoops, good old fashioned copy and paste error. The test build I ran
didn't trigger this... Sorry.
I just force pushed an amended tree.
Cheers,
Joshua
MACHINE=efika
DISTRO=angstrom-2008.1
ERROR:
'/local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb'
failed
NOTE: package shasum-native-1.0-r1: task do_qa_configure: Started
ERROR: Error in executing python function in:
/local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb
ERROR: Exception:type 'exceptions.NameError' Message:global name 'configs'
is not defined
ERROR: Printing the environment of the function
ERROR: 0021: else:
ERROR: 0022: gt = gettext
ERROR: 0023: deps = bb.utils.explode_deps(bb.data.getVar('DEPENDS', d,
True) or )
ERROR: 0024: if gt not in deps:
ERROR: 0025: for config in configs:
ERROR: 0026: gnu = grep \^[[:space:]]*AM_GNU_GETTEXT\ %s
/dev/null % config
ERROR: 0027: if os.system(gnu) == 0:
ERROR: 0028: bb.note(Gettext required but not in DEPENDS
for file %s.
ERROR: 0029:Missing inherit gettext? % config)
ERROR: Function do_qa_configure failed
NOTE: Task failed: ('function do_qa_configure failed',
'/local/Angstrom_BeagleBoard/tmp/work/i686-linux/shasum-native-1.0-r1/temp/log.do_qa_configure.24200')
ERROR: Logfile of failure stored in:
/local/Angstrom_BeagleBoard/tmp/work/i686-linux/shasum-native-1.0-r1/temp/log.do_qa_configure.24200
Log data follows:
| ERROR: Error in executing python function in:
/local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb
| ERROR: Exception:type 'exceptions.NameError' Message:global name
'configs' is not defined
| ERROR: Printing the environment of the function
| ERROR:0021: else:
| ERROR:0022: gt = gettext
| ERROR:0023: deps =
bb.utils.explode_deps(bb.data.getVar('DEPENDS', d, True) or )
| ERROR:0024: if gt not in deps:
| ERROR:0025: for config in configs:
| ERROR:0026: gnu = grep
\^[[:space:]]*AM_GNU_GETTEXT\ %s /dev/null % config
| ERROR:0027: if os.system(gnu) == 0:
| ERROR:0028: bb.note(Gettext required but not in
DEPENDS for file %s.
| ERROR:0029:Missing inherit gettext? % config)
| ERROR: Function do_qa_configure failed
NOTE: package shasum-native-1.0-r1: task do_qa_configure: Failed
ERROR: TaskFailed event exception, aborting
I tried this with bitbake-1.8.18 and the version from Poky mainline.
--
Joshua Lock
Intel Open Source Technology Centre
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] Fix packaged staging for cross packages
Hi Chris,
On Thu, 2010-03-04 at 13:42 -0600, Chris Larson wrote:
It looks like this does fix the problem, and good job in spotting the
problem, but this fix assumes that the basename of CROSS_DIR is
BASE_PACKAGE_ARCH. If that ever changes for whatever reason, it will break.
I'd suggest instead changing it to continue to copy the contents of the
dir, but to change the destination to match the destination used in the
postamble (${PSTAGE_TMPDIR_STAGE}/cross/${BASE_PACKAGE_ARCH}).
Thanks for the quick review, I've attached a modified patch to account
for potential changes in the base name of CROSS_DIR as suggested.
Regards,
Joshua
--
Joshua Lock
Intel Open Source Technology Centre
From f40c45b8cba055d698e22c2b7444bc21c5a47eb8 Mon Sep 17 00:00:00 2001
From: Joshua Lock j...@linux.intel.com
Date: Fri, 5 Mar 2010 08:23:39 +
Subject: [PATCH] packaged-staging: Fix packagaging of cross packages
packagedstaging_fastpath() was only copying the contents of CROSS_DIR to
PSTAGE_TMPDIR resulting in the folders contents being packaged and then
installed incorrectly at the top level of CROSS_DIR rather than in HOST_ARCH
specific sub directories.
This patch fixes that issue by copying the directory and its contents rather
than just the directory contents.
Signed-off-by: Joshua Lock j...@linux.intel.com
---
classes/packaged-staging.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/classes/packaged-staging.bbclass b/classes/packaged-staging.bbclass
index 1ede25c..f50ccad 100644
--- a/classes/packaged-staging.bbclass
+++ b/classes/packaged-staging.bbclass
@@ -289,7 +289,7 @@ packagedstaging_fastpath () {
mkdir -p ${PSTAGE_TMPDIR_STAGE}/staging/
mkdir -p ${PSTAGE_TMPDIR_STAGE}/cross/
cp -fpPR ${SYSROOT_DESTDIR}${STAGING_DIR}/* ${PSTAGE_TMPDIR_STAGE}/staging/ || /bin/true
- cp -fpPR ${SYSROOT_DESTDIR}${CROSS_DIR}/* ${PSTAGE_TMPDIR_STAGE}/cross/ || /bin/true
+ cp -fpPR ${SYSROOT_DESTDIR}${CROSS_DIR}/* ${PSTAGE_TMPDIR_STAGE}/cross/${BASE_PACKAGE_ARCH}/ || /bin/true
fi
}
--
1.6.6.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
