[oe] [PATCH][meta-perl] libxml-sax-writer-perl: add recipe
From: Roy Li rongqing...@windriver.com
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../libxml/libxml-sax-writer-perl_0.54.bb | 27
1 file changed, 27 insertions(+)
create mode 100644 meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
diff --git a/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
b/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
new file mode 100644
index 000..c7a24fc
--- /dev/null
+++ b/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
@@ -0,0 +1,27 @@
+SUMMARY = XML::SAX::Writer - SAX2 Writer
+DESCRIPTION = \
+XML::SAX::Writer helps to serialize SAX2 representations of XML documents to \
+strings, files, and other flat representations. It handles charset encodings, \
+XML escaping conventions, and so forth. It is still considered alpha, \
+although it has been put to limited use in settings such as XML::LibXML and \
+the AxKit XML Application Server. \
+
+SECTION = libs
+LICENSE = Artistic-1.0 | GPLv1+
+HOMEPAGE = http://search.cpan.org/dist/XML-SAX-Writer/;
+DEPENDS += libxml-filter-buffertext-perl-native
+RDEPENDS_${PN} += libxml-filter-buffertext-perl
+
+SRC_URI =
http://search.cpan.org/CPAN/authors/id/P/PE/PERIGRIN/XML-SAX-Writer-${PV}.tar.gz;
+SRC_URI[md5sum] = 383139d76418a82b9800dc4f8b568891
+SRC_URI[sha256sum] =
a1b4d959aed8f8337523c4cef4b431e56e619c795dc6f99a868548952101cf3d
+
+LIC_FILES_CHKSUM =
file://README;beginline=45;endline=46;md5=d41d8cd98f00b204e9800998ecf8427e
+
+S = ${WORKDIR}/XML-SAX-Writer-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
+
+PACKAGE_ARCH = all
--
1.7.10.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH][meta-perl] libxml-libxml-perl: add recipe
From: Roy Li rongqing...@windriver.com
This module is an interface to libxml2, providing XML and HTML parsers \
with DOM, SAX and XMLReader interfaces, a large subset of DOM Layer 3 \
interface and a XML::XPath-like interface to XPath API of libxml2. \
The module is split into several packages which are not described in this \
section; unless stated otherwise, you only need to use XML::LibXML; in \
your programs.
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../fix-CATALOG-conditional-compile.patch | 31 +++
.../using-DOCB-conditional.patch | 91
.../libxml/libxml-libxml-perl_2.0116.bb| 46 ++
3 files changed, 168 insertions(+)
create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl/using-DOCB-conditional.patch
create mode 100644 meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb
diff --git
a/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
new file mode 100644
index 000..1dd9fb3
--- /dev/null
+++
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
@@ -0,0 +1,31 @@
+[PATCH] Fix a compile error
+
+Upstream-Status: Pending
+
+Fix a compile error by conditional using 'catal' since catal
+is only defined when LIBXML_CATALOG_ENABLED is enabled.
+
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ LibXML.xs |2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/LibXML.xs b/LibXML.xs
+index 66da04b..45da681 100644
+--- a/LibXML.xs
b/LibXML.xs
+@@ -2777,9 +2777,11 @@ _default_catalog( self, catalog )
+ xmlCatalogPtr catal = INT2PTR(xmlCatalogPtr,SvIV(SvRV(catalog)));
+ #endif
+ INIT:
++#ifdef LIBXML_CATALOG_ENABLED
+ if ( catal == NULL ) {
+ croak( empty catalog\n );
+ }
++#endif
+ CODE:
+ warn( this feature is not implemented );
+ RETVAL = 0;
+--
+1.7.10.4
+
diff --git
a/meta-perl/recipes-perl/libxml/libxml-libxml-perl/using-DOCB-conditional.patch
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/using-DOCB-conditional.patch
new file mode 100644
index 000..d255ec7
--- /dev/null
+++
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/using-DOCB-conditional.patch
@@ -0,0 +1,91 @@
+[PATCH] Fix a compile error
+
+Upstream-Status: Pending
+
+by conditional using 'XML_DOCB_DOCUMENT_NODE' since it is only
+defined when LIBXML_DOCB_ENABLED is enabled in xmlversion.h.
+
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ LibXML.xs|9 +-
+ dom.c|2 +
+ perl-libxml-mm.c |4 +
+ 4 files changed, 678 insertions(+), 658 deletions(-)
+
+diff --git a/LibXML.xs b/LibXML.xs
+index b299ba4..66da04b 100644
+--- a/LibXML.xs
b/LibXML.xs
+@@ -5026,7 +5026,9 @@ addChild( self, nNode )
+ XSRETURN_UNDEF;
+ case XML_DOCUMENT_NODE :
+ case XML_HTML_DOCUMENT_NODE :
++#ifdef LIBXML_DOCB_ENABLED
+ case XML_DOCB_DOCUMENT_NODE :
++#endif
+ croak(addChild: HIERARCHY_REQUEST_ERR\n);
+ XSRETURN_UNDEF;
+ case XML_NOTATION_NODE :
+@@ -5286,7 +5288,9 @@ _toStringC14N(self, comments=0, xpath=PL_sv_undef,
exclusive=0, inc_prefix_list
+ if ( nodepath == NULL
+ self-type != XML_DOCUMENT_NODE
+ self-type != XML_HTML_DOCUMENT_NODE
++#ifdef LIBXML_DOCB_ENABLED
+ self-type != XML_DOCB_DOCUMENT_NODE
++#endif
+) {
+ if (comments)
+ nodepath = xmlStrdup( (const xmlChar *) (. | .//node() | .//@* |
.//namespace::*) );
+@@ -5297,7 +5301,10 @@ _toStringC14N(self, comments=0, xpath=PL_sv_undef,
exclusive=0, inc_prefix_list
+ if ( nodepath != NULL ) {
+ if ( self-type == XML_DOCUMENT_NODE
+ || self-type == XML_HTML_DOCUMENT_NODE
+- || self-type == XML_DOCB_DOCUMENT_NODE ) {
++#ifdef LIBXML_DOCB_ENABLED
++ || self-type == XML_DOCB_DOCUMENT_NODE
++#endif
++ ) {
+ refNode = xmlDocGetRootElement( self-doc );
+ }
+ if (SvOK(xpath_context)) {
+diff --git a/dom.c b/dom.c
+index 87eb61d..cbd391b 100644
+--- a/dom.c
b/dom.c
+@@ -654,7 +654,9 @@ domName(xmlNodePtr node) {
+
+ case XML_DOCUMENT_NODE :
+ case XML_HTML_DOCUMENT_NODE :
++#ifdef LIBXML_DOCB_ENABLED
+ case XML_DOCB_DOCUMENT_NODE :
++#endif
+ name = (const xmlChar *) #document;
+ break;
+
+diff --git a/perl-libxml-mm.c b/perl-libxml-mm.c
+index d162b06..7ac5436 100644
+--- a/perl-libxml-mm.c
b/perl-libxml-mm.c
+@@ -331,7 +331,9 @@ PmmNewNode(xmlNodePtr node)
+ switch ( node-type ) {
+ case XML_DOCUMENT_NODE:
+ case XML_HTML_DOCUMENT_NODE:
++#ifdef LIBXML_DOCB_ENABLED
+ case
Re: [oe] [PATCH][meta-perl] libxml-libxml-perl: add recipe
On 07/14/2014 02:12 PM, rongqing...@windriver.com wrote: +++ b/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb s/libxml-libxml-perl/libxml-perl/ How about rename the recipe with libxml-perl ? //Hongxu -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 2/2] libhugetlbfs: fix packaging
Libhugetlbs doesn't generate proper .so.X libs, only two .so files. Package
those in ${PN} and silence the resulting QA warning. This fixes:
ERROR: QA Issue: libhugetlbfs-tests rdepends on libhugetlbfs-dev
Signed-off-by: Koen Kooi koen.k...@linaro.org
---
meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
index af7ed3e..d3b64bf 100644
--- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
+++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
@@ -25,6 +25,7 @@ COMPATIBLE_HOST =
(x86_64|powerpc|powerpc64|aarch64).*-linux*
LIBARGS = LIB32=${baselib} LIB64=${baselib}
EXTRA_OEMAKE = 'ARCH=${TARGET_ARCH}' 'OPT=${CFLAGS}' 'CC=${CC}' ${LIBARGS}
V=1
+PARALLEL_MAKE_pn-${PN} =
CFLAGS += -fexpensive-optimizations -frename-registers -fomit-frame-pointer
-g0
TARGET_CC_ARCH += ${LDFLAGS}
@@ -46,12 +47,15 @@ do_install() {
install-tests
}
-PARALLEL_MAKE_pn-${PN} =
PACKAGES =+ ${PN}-perl ${PN}-tests
+FILES_${PN} += ${libdir}/*.so
+FILES_${PN}-dev = ${includedir}
FILES_${PN}-dbg += ${libdir}/libhugetlbfs/tests/obj32/.debug
${libdir}/libhugetlbfs/tests/obj64/.debug
FILES_${PN}-perl = ${libdir}/perl
FILES_${PN}-tests += ${libdir}/libhugetlbfs/tests
+INSANE_SKIP_${PN} = dev-so
+
INHIBIT_PACKAGE_STRIP = 1
INHIBIT_PACKAGE_DEBUG_SPLIT = 1
--
1.9.3
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][meta-perl] libxml-libxml-perl: add recipe
On 07/14/2014 04:28 PM, Hongxu Jia wrote: On 07/14/2014 02:12 PM, rongqing...@windriver.com wrote: +++ b/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb s/libxml-libxml-perl/libxml-perl/ How about rename the recipe with libxml-perl ? //Hongxu there is a libxml-perl under oe-core /oe-core/meta/recipes-devtools/perl/libxml-perl_0.08.bb -- Best Reagrds, Roy | RongQing Li -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][meta-perl] libxml-libxml-perl: add recipe
On 14-07-14 10:28 +0200, Hongxu Jia wrote: On 07/14/2014 02:12 PM, rongqing...@windriver.com wrote: +++ b/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb s/libxml-libxml-perl/libxml-perl/ How about rename the recipe with libxml-perl ? This would break the naming convention, libdistribution name-perl. The module is *actually* named XML::LibXML. Even though it looks strange, I think it would be preferable to stick to the convention. -- olofjn -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][meta-perl] libxml-libxml-perl: add recipe
On 07/14/2014 05:05 PM, Olof Johansson wrote: On 14-07-14 10:28 +0200, Hongxu Jia wrote: On 07/14/2014 02:12 PM, rongqing...@windriver.com wrote: +++ b/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb s/libxml-libxml-perl/libxml-perl/ How about rename the recipe with libxml-perl ? This would break the naming convention, libdistribution name-perl. The module is *actually* named XML::LibXML. Even though it looks strange, I think it would be preferable to stick to the convention. Thanks for all. And HongXu found a building failure on arm, I will fix it, and resend it. -- Best Reagrds, Roy | RongQing Li -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
Hi Robert, On Sunday 13 July 2014 10:19:08 Robert P. J. Day wrote: followup to last post -- all of the methods for overriding task definitions in the last post can be used without predeclaring that you're about to do that; you just go ahead and do it in either a class file or a recipe file. on the other hand, EXPORT_FUNCTIONS allows you to retain the base definition of a task (or non-task function, as i read it), then define a more general enhanced version. (side note: i don't see a single mention of EXPORT_FUNCTIONS in any of the numerous yocto docs -- i think this feature needs some explanation *somewhere*. :-) Did you try the new BitBake manual? http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#flexible-inheritance-for-class-functions Let me know if that doesn't answer your questions. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] the awkwardness of using core-image.bbclass
Hi Robert,
On Friday 11 July 2014 12:51:54 Robert P. J. Day wrote:
some observations/questions on core-image.bbclass, and whether it
can be used more understandably. this is being written from the
perspective of someone who has had the occasional student ask, why
was it done *that* way?
so here's the important part of core-image.bbclass:
CORE_IMAGE_BASE_INSTALL = '\
packagegroup-core-boot \
packagegroup-base-extended \
\
${CORE_IMAGE_EXTRA_INSTALL} \
'
CORE_IMAGE_EXTRA_INSTALL ?=
IMAGE_INSTALL ?= ${CORE_IMAGE_BASE_INSTALL}
inherit image
whose job is obviously to define the final contents in IMAGE_INSTALL
to be handed off to image.bbclass. so far, so good. but notice first
that while IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL are weakly
assigned, CORE_IMAGE_BASE_INSTALL is *not*, which -- if one is
perusing that file -- strongly suggests that if you're inheriting
from this class file, you really should use that value. but it doesn't
work that way.
first, here's (the relevant parts of) core-image-base.bb:
IMAGE_FEATURES += splash
inherit core-image
that's perfect -- define an additional feature, then pull in
core-image to take care of the rest. perfectly understandable.
core-image-minimal.bb is *not* so clean:
IMAGE_INSTALL = packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}
${CORE_IMAGE_EXTRA_INSTALL}
inherit core-image
i consider this recipe file potentially confusing since, although it
inherits core-image, it effectively stomps on the settings in there,
and just rams an overriding value into IMAGE_INSTALL. in short, rather
than inheriting cleanly from core-image and extending or enhancing
the recipe, core-image-mimimal simply kicks IMAGE_INSTALL out of the
way and sets its own final value.
As core-image.bbclass currently works, it core-image-minimal must do this;
otherwise you'll get packagegroup-base-extended in the image and the name
minimal won't be true anymore. If on the other hand you inherit image
instead of core-image then you won't be able to use the IMAGE_FEATURES
definitions that core-image.bbclass defines.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] what is the process for sending patches about eclipse-poky-kepler?
On 14/07/14 04:13, b40...@freescale.com wrote: Hello all, I need to send patches to eclipse-poky-kepler . What is the process for sending patches ? Thanks, Chunrong If it's poky specific then I would imagine either sending them to Poky list, or the Yocto list would be most appropriate. https://www.yoctoproject.org/tools-resources/community/mailing-lists -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer Cambridgeshire, UK http://www.embed.me.uk -- -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] is it addtask do_X ... or addtask X ... or does it matter?
On Sat, 12 Jul 2014, Christopher Larson wrote: On Sat, Jul 12, 2014 at 4:22 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: want to clarify the two different ways to use addtask. for example: classes/kernel.bbclass:addtask savedefconfig after do_configure classes/kernel.bbclass:addtask do_strip before do_sizecheck after do_kernel_link_vmlinux classes/kernel.bbclass:addtask sizecheck before do_install after do_strip so what is the preferred form? are they equivalent? addtask do_strip will add a task named 'do_do_strip', afaik. so is there a final opinion on the validity of doing addtask do_X ... rather than addtask X ... if what chris writes is accurate, there are some broken class and recipe files in oe-core: classes/kernel.bbclass:addtask do_strip before do_sizecheck after do_kernel_link_vmlinux classes/staging.bbclass:addtask do_populate_sysroot_setscene classes/insane.bbclass:addtask do_package_qa after do_packagedata do_package before do_build classes/insane.bbclass:addtask do_package_qa_setscene classes/package_rpm.bbclass:addtask do_package_write_rpm_setscene classes/license.bbclass:addtask do_populate_lic_setscene classes/archiver.bbclass:addtask do_ar_original after do_unpack classes/archiver.bbclass:addtask do_unpack_and_patch after do_patch classes/archiver.bbclass:addtask do_ar_patched after do_unpack_and_patch classes/archiver.bbclass:addtask do_ar_configured after do_unpack_and_patch classes/archiver.bbclass:addtask do_dumpdata classes/archiver.bbclass:addtask do_ar_recipe classes/archiver.bbclass:addtask do_deploy_archives before do_build classes/deploy.bbclass:addtask do_deploy_setscene classes/package_deb.bbclass:addtask do_package_write_deb_setscene classes/package.bbclass:addtask do_package_setscene classes/package.bbclass:addtask do_packagedata_setscene classes/package_ipk.bbclass:addtask do_package_write_ipk_setscene recipes-core/eglibc/eglibc-package.inc:addtask do_install_locale after do_install before do_populate_sysroot do_package recipes-core/base-passwd/base-passwd_3.5.29.bb:addtask do_package after do_populate_sysroot recipes-core/meta/package-index.bb:addtask do_package_index before do_build recipes-devtools/gcc/gcc-configure-common.inc:addtask do_preconfigure after do_patch before do_configure recipes-support/boost/boost.inc:addtask do_boostconfig after do_patch before do_configure surely all of the above can't be broken, can they? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Mon, 14 Jul 2014, Paul Eggleton wrote: On Friday 11 July 2014 20:39:04 Otavio Salvador wrote: On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: a number of the current packagegroup recipe files still have backward compatibility support for the old task-core names, seems like that's been there for well over a year, would it be safe to finally just toss that? seems like everyone's had enough time to make the move to the new names, and it would be clearer to not confuse the proper use of the word task these days. I agree; however this question should also be send to oe-core mailing list (added in Cc) I agree as well; these should go. I know there are some who want to keep these indefinitely for upgrade purposes, but I think there's a limit to how long they should stay around in OE-Core. They can always be preserved in bbappends for those that do want to keep them. i can submit a patch for that later today if no one objects. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
On Mon, 14 Jul 2014, Paul Eggleton wrote: Hi Robert, On Sunday 13 July 2014 10:19:08 Robert P. J. Day wrote: followup to last post -- all of the methods for overriding task definitions in the last post can be used without predeclaring that you're about to do that; you just go ahead and do it in either a class file or a recipe file. on the other hand, EXPORT_FUNCTIONS allows you to retain the base definition of a task (or non-task function, as i read it), then define a more general enhanced version. (side note: i don't see a single mention of EXPORT_FUNCTIONS in any of the numerous yocto docs -- i think this feature needs some explanation *somewhere*. :-) Did you try the new BitBake manual? http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#flexible-inheritance-for-class-functions Let me know if that doesn't answer your questions. actually, i worded the above *really* badly. i see it in the bitbake user manual, i was referring to the yocto-docs layer, which contains all of the yocto docs but not the bitbake manual, which might mislead some people into not knowing that the bitbake user manual is even there. i know bitbake is outside the scope of what belongs in the yocto-docs layer, but perhaps there should be at least a pointer to it in the yocto-docs README file? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
On Monday 14 July 2014 06:18:58 Robert P. J. Day wrote: On Mon, 14 Jul 2014, Paul Eggleton wrote: Hi Robert, On Sunday 13 July 2014 10:19:08 Robert P. J. Day wrote: followup to last post -- all of the methods for overriding task definitions in the last post can be used without predeclaring that you're about to do that; you just go ahead and do it in either a class file or a recipe file. on the other hand, EXPORT_FUNCTIONS allows you to retain the base definition of a task (or non-task function, as i read it), then define a more general enhanced version. (side note: i don't see a single mention of EXPORT_FUNCTIONS in any of the numerous yocto docs -- i think this feature needs some explanation *somewhere*. :-) Did you try the new BitBake manual? http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user- manual.html#flexible-inheritance-for-class-functions Let me know if that doesn't answer your questions. actually, i worded the above *really* badly. i see it in the bitbake user manual, i was referring to the yocto-docs layer, which contains all of the yocto docs but not the bitbake manual, which might mislead some people into not knowing that the bitbake user manual is even there. i know bitbake is outside the scope of what belongs in the yocto-docs layer, but perhaps there should be at least a pointer to it in the yocto-docs README file? Yes I think that would be a good idea. In fact the BitBake manual being up-to- date is a relatively new thing so we're probably missing pointers / links to it in a number of places. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Mon, 14 Jul 2014, Paul Eggleton wrote:
On Friday 11 July 2014 20:39:04 Otavio Salvador wrote:
On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day
rpj...@crashcourse.ca wrote:
a number of the current packagegroup recipe files still have
backward compatibility support for the old task-core names, seems
like that's been there for well over a year, would it be safe to
finally just toss that? seems like everyone's had enough time to make
the move to the new names, and it would be clearer to not confuse the
proper use of the word task these days.
I agree; however this question should also be send to oe-core mailing
list (added in Cc)
I agree as well; these should go. I know there are some who want to
keep these indefinitely for upgrade purposes, but I think there's a
limit to how long they should stay around in OE-Core. They can
always be preserved in bbappends for those that do want to keep
them.
getting rid of all that task-core stuff in packagegroups looks
pretty easy, except for this snippet in
packagegroup-core-full-cmdline.bb:
packages = d.getVar(PACKAGES, True).split()
for pkg in packages:
if pkg.endswith('-dev'):
mapped = namemap.get(pkg[:-4], None)
if mapped:
mapped += '-dev'
elif pkg.endswith('-dbg'):
mapped = namemap.get(pkg[:-4], None)
if mapped:
mapped += '-dbg'
else:
mapped = namemap.get(pkg, None)
if mapped:
oldtaskname = mapped.replace(packagegroup-core, task-core)
mapstr = %s %s % (mapped, oldtaskname)
d.appendVar(RPROVIDES_%s % pkg, mapstr)
d.appendVar(RREPLACES_%s % pkg, mapstr)
d.appendVar(RCONFLICTS_%s % pkg, mapstr)
}
would one simply delete that last if mapped: conditional in its
entirety? or what?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [yocto] python tkinter dependencies
On Thursday 10 July 2014 16:11:29 Jate S wrote: - Python-tkinter requires the tk recipe in meta-oe, so you must add this layer for your build. - I am on dora. I found that I needed commit tk: make multilib build compatible and fix library install made on 12/5/2013 (1ca29d1cda0d007c4e6a28fe1a4037b4029ad7ae). - I created a bbappend for python. In this I added DEPENDS_class-target on tk, and RDEPENDS_class-target on tk and tk-lib. Also, I did a SRC_URI replace to eliminate the avoid_warning_about_tkinter.patch file. I was able to build and use python-tkinter successfully. The question now is if this should go into meta-oe or oe-core. And how. The tcl recipe is in oe-core, but not tk. I'm not yet sure why this is. Does anybody know? I think the answer is that we have some things in OE-Core that depend on tcl (e.g. expect) but nothing in OE-Core requires tk. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Monday 14 July 2014 06:31:18 Robert P. J. Day wrote:
On Mon, 14 Jul 2014, Paul Eggleton wrote:
On Friday 11 July 2014 20:39:04 Otavio Salvador wrote:
On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day
rpj...@crashcourse.ca wrote:
a number of the current packagegroup recipe files still have
backward compatibility support for the old task-core names, seems
like that's been there for well over a year, would it be safe to
finally just toss that? seems like everyone's had enough time to make
the move to the new names, and it would be clearer to not confuse the
proper use of the word task these days.
I agree; however this question should also be send to oe-core mailing
list (added in Cc)
I agree as well; these should go. I know there are some who want to
keep these indefinitely for upgrade purposes, but I think there's a
limit to how long they should stay around in OE-Core. They can
always be preserved in bbappends for those that do want to keep
them.
getting rid of all that task-core stuff in packagegroups looks
pretty easy, except for this snippet in
packagegroup-core-full-cmdline.bb:
packages = d.getVar(PACKAGES, True).split()
for pkg in packages:
if pkg.endswith('-dev'):
mapped = namemap.get(pkg[:-4], None)
if mapped:
mapped += '-dev'
elif pkg.endswith('-dbg'):
mapped = namemap.get(pkg[:-4], None)
if mapped:
mapped += '-dbg'
else:
mapped = namemap.get(pkg, None)
if mapped:
oldtaskname = mapped.replace(packagegroup-core, task-core)
mapstr = %s %s % (mapped, oldtaskname)
d.appendVar(RPROVIDES_%s % pkg, mapstr)
d.appendVar(RREPLACES_%s % pkg, mapstr)
d.appendVar(RCONFLICTS_%s % pkg, mapstr)
}
would one simply delete that last if mapped: conditional in its
entirety? or what?
Well the packagegroup-core-full-cmdline rename was relatively recent (March),
so it would be a bit early to remove that as well. You'd need to cut out just
the oldtaskname (and corresponding %s) bit.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Mon, 14 Jul 2014, Paul Eggleton wrote: On Friday 11 July 2014 20:39:04 Otavio Salvador wrote: On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: a number of the current packagegroup recipe files still have backward compatibility support for the old task-core names, seems like that's been there for well over a year, would it be safe to finally just toss that? seems like everyone's had enough time to make the move to the new names, and it would be clearer to not confuse the proper use of the word task these days. I agree; however this question should also be send to oe-core mailing list (added in Cc) I agree as well; these should go. I know there are some who want to keep these indefinitely for upgrade purposes, but I think there's a limit to how long they should stay around in OE-Core. They can always be preserved in bbappends for those that do want to keep them. one more (general) question about this ... there's a fair bit of this task/packagegroup backward compatibility stuff under the meta-oe layer as well. i assume that patches to the meta-oe layer should still be posted to this list, but have a subject line of: [meta-oe][PATCH] ... correct? as in, two separate patches. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] Remove long-deprecated task-core backward compat for packagegroups.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
a few notes:
* seems valid as i'm rebuilding a core-image-minimal for qemux86 so
the recipes seem to parse properly
* almost all of this is simple variable assignment deletion but for
that first patch, which is just the python code which does the same
thing
* there is also removal of some assignments that relate to similar
stuff over in meta-oe. is it reasonable to just delete that content
here, and delete the related meta-oe stuff as another patch?
diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb
b/meta/recipes-core/packagegroups/packagegroup-base.bb
index 16f3a51..13a4fe4 100644
--- a/meta/recipes-core/packagegroups/packagegroup-base.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
@@ -124,13 +124,6 @@ python __anonymous () {
if nfc in distro_features and not nfc in machine_features and
(usbhost in machine_features):
d.setVar(ADD_NFC, packagegroup-base-nfc)
-
-# For backwards compatibility after rename
-packages = d.getVar(PACKAGES, True).split()
-for pkg in packages:
-d.appendVar(RPROVIDES_%s % pkg, pkg.replace(packagegroup-,
task-))
-d.appendVar(RREPLACES_%s % pkg, pkg.replace(packagegroup-,
task-))
-d.appendVar(RCONFLICTS_%s % pkg, pkg.replace(packagegroup-,
task-))
}
#
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
index c8bc362..bdc4a1d 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
@@ -17,11 +17,6 @@ PACKAGE_ARCH = ${MACHINE_ARCH}
MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?=
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?=
-# For backwards compatibility after rename
-RPROVIDES_${PN} = task-core-boot
-RREPLACES_${PN} = task-core-boot
-RCONFLICTS_${PN} = task-core-boot
-
# Distro can override the following VIRTUAL-RUNTIME providers:
VIRTUAL-RUNTIME_dev_manager ?= udev
VIRTUAL-RUNTIME_login_manager ?= busybox
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
index 24c98c4..247a30e 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
@@ -10,11 +10,6 @@ inherit packagegroup
PACKAGES = ${PN}-server
-# For backwards compatibility after rename
-RPROVIDES_${PN}-server = task-core-nfs-server
-RREPLACES_${PN}-server = task-core-nfs-server
-RCONFLICTS_${PN}-server = task-core-nfs-server
-
SUMMARY_${PN}-server = NFS server
RDEPENDS_${PN}-server = \
nfs-utils \
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
index 1723989..a544bbd 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
@@ -10,11 +10,6 @@ inherit packagegroup
#PACKAGEFUNCS =+ 'generate_sdk_pkgs'
-# For backwards compatibility after rename
-RPROVIDES_packagegroup-core-sdk = task-core-sdk
-RREPLACES_packagegroup-core-sdk = task-core-sdk
-RCONFLICTS_packagegroup-core-sdk = task-core-sdk
-
RDEPENDS_packagegroup-core-sdk = \
packagegroup-core-buildessential \
coreutils \
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
b/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
index 458d8fa..e99946f 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
@@ -4,9 +4,4 @@ PR = r1
inherit packagegroup
-# For backwards compatibility after rename
-RPROVIDES_${PN} = task-core-ssh-dropbear
-RREPLACES_${PN} = task-core-ssh-dropbear
-RCONFLICTS_${PN} = task-core-ssh-dropbear
-
RDEPENDS_${PN} = dropbear
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb
b/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb
index df70962..32d20e6 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb
@@ -4,9 +4,4 @@ PR = r1
inherit packagegroup
-# For backwards compatibility after rename
-RPROVIDES_${PN} = task-core-ssh-openssh
-RREPLACES_${PN} = task-core-ssh-openssh
-RCONFLICTS_${PN} = task-core-ssh-openssh
-
RDEPENDS_${PN} = openssh
diff --git
a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
index 3325ef6..5d1ce97 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
@@ -4,14 +4,6 @@ LICENSE = MIT
inherit packagegroup
-# For backwards compatibility after rename
-RPROVIDES_${PN} = task-core-standalone-sdk-target
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Monday 14 July 2014 07:39:23 Robert P. J. Day wrote: On Mon, 14 Jul 2014, Paul Eggleton wrote: On Friday 11 July 2014 20:39:04 Otavio Salvador wrote: On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: a number of the current packagegroup recipe files still have backward compatibility support for the old task-core names, seems like that's been there for well over a year, would it be safe to finally just toss that? seems like everyone's had enough time to make the move to the new names, and it would be clearer to not confuse the proper use of the word task these days. I agree; however this question should also be send to oe-core mailing list (added in Cc) I agree as well; these should go. I know there are some who want to keep these indefinitely for upgrade purposes, but I think there's a limit to how long they should stay around in OE-Core. They can always be preserved in bbappends for those that do want to keep them. one more (general) question about this ... there's a fair bit of this task/packagegroup backward compatibility stuff under the meta-oe layer as well. i assume that patches to the meta-oe layer should still be posted to this list, but have a subject line of: [meta-oe][PATCH] ... correct? as in, two separate patches. To be clear (since we're cross-posted to two lists in this thread) OE-Core patches go to the openembedded-core list, meta-oe patches to the openembedded- devel list. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Mon, 14 Jul 2014, Paul Eggleton wrote: On Monday 14 July 2014 07:39:23 Robert P. J. Day wrote: On Mon, 14 Jul 2014, Paul Eggleton wrote: On Friday 11 July 2014 20:39:04 Otavio Salvador wrote: On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: a number of the current packagegroup recipe files still have backward compatibility support for the old task-core names, seems like that's been there for well over a year, would it be safe to finally just toss that? seems like everyone's had enough time to make the move to the new names, and it would be clearer to not confuse the proper use of the word task these days. I agree; however this question should also be send to oe-core mailing list (added in Cc) I agree as well; these should go. I know there are some who want to keep these indefinitely for upgrade purposes, but I think there's a limit to how long they should stay around in OE-Core. They can always be preserved in bbappends for those that do want to keep them. one more (general) question about this ... there's a fair bit of this task/packagegroup backward compatibility stuff under the meta-oe layer as well. i assume that patches to the meta-oe layer should still be posted to this list, but have a subject line of: [meta-oe][PATCH] ... correct? as in, two separate patches. To be clear (since we're cross-posted to two lists in this thread) OE-Core patches go to the openembedded-core list, meta-oe patches to the openembedded- devel list. ah, gotcha, will fix. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
On Monday 14 July 2014 08:20:59 Robert P. J. Day wrote:
On Mon, 14 Jul 2014, Paul Eggleton wrote:
Hi Robert,
On Sunday 13 July 2014 10:19:08 Robert P. J. Day wrote:
followup to last post -- all of the methods for overriding task
definitions in the last post can be used without predeclaring that
you're about to do that; you just go ahead and do it in either a class
file or a recipe file. on the other hand, EXPORT_FUNCTIONS allows you
to retain the base definition of a task (or non-task function, as i
read it), then define a more general enhanced version.
(side note: i don't see a single mention of EXPORT_FUNCTIONS in
any of the numerous yocto docs -- i think this feature needs some
explanation *somewhere*. :-)
Did you try the new BitBake manual?
http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-
manual.html#flexible-inheritance-for-class-functions
Let me know if that doesn't answer your questions.
i think that section could be extended a bit to offer more
information, so i might take a shot at it. first, i think it should
emphasize that it's primarily(?) used for enhancing the default
implementation of base functions. just using foo and bar here is
maddeningly vague. throwing in an (admittedly OE-related) example like
this from cmake.bbclass:
cmake_do_compile() {
cd ${B}
base_do_compile
}
cmake_do_install() {
cd ${B}
autotools_do_install
}
would, i think, clarify the general power of this feature.
Unfortunately as far as the BitBake manual is concerned, it pretty much has to
be abstract. Remember that there are no base implementations of any task
functions in BitBake itself; the ones you refer to are in OE's base.bbclass.
and a question about a particular example. richard purdie replied to
my post a while back about package.bbclass and debian.bbclass, but i'm
still a bit confused. here's a snippet from package.bbclass:
python package_package_name_hook() {
A package_name_hook function can be used to rewrite the package names
by changing PKG. For an example, see debian.bbclass.
pass
}
EXPORT_FUNCTIONS package_name_hook
so as i read it, the above defines the function
package_package_name_hook which doesn't do a whole lot, but is now
available to other classes that inherit this one, particularly
debian.bbclass that's specifically mentioned.
but if one goes to debian.bbclass, one finds:
python debian_package_name_hook () {
import glob, copy, stat, errno, re
... snip ...
}
EXPORT_FUNCTIONS package_name_hook
but, as far as i can tell, that is the only class that requires a
package name hook, and it simply defines its own implementation -- it
does nothing with package.bbclass and makes no reference to the
exported function package_package_name_hook(). so am i just
misunderstanding something? what was the point of defining and
exporting that function in package.bbclass if no other class takes
advantage of it?
Right, the debian.bbclass implementation probably doesn't need to be
implemented in that way, AFAICT.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
On 14 July 2014 13:20, Robert P. J. Day rpj...@crashcourse.ca wrote: but, as far as i can tell, that is the only class that requires a package name hook, and it simply defines its own implementation -- it does nothing with package.bbclass and makes no reference to the exported function package_package_name_hook(). so am i just misunderstanding something? what was the point of defining and exporting that function in package.bbclass if no other class takes advantage of it? So there needs to be an empty implementation and EXPORT_FUNCTION for package_package_name_hook so that you don't get cannot find function package_name_hook when you don't have the debian.bbclass enabled. In cleaning that up I proposed removing the EXPORT_FUNCTION entirely for the hook, but Richard recalled there being something out there that did use the ability to chain up into debian.bbclass's implementation, so I kept it. Ross -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] Remove deprecated task backward compatibility from packagegroups
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
all of this looked relatively straightforward.
diff --git a/meta-efl/recipes-efl/packagegroups/packagegroup-efl-sdk.bb
b/meta-efl/recipes-efl/packagegroups/packagegroup-efl-sdk.bb
index 4e5ce78..5ead412 100644
--- a/meta-efl/recipes-efl/packagegroups/packagegroup-efl-sdk.bb
+++ b/meta-efl/recipes-efl/packagegroups/packagegroup-efl-sdk.bb
@@ -11,9 +11,6 @@ require packagegroup-efl-sdk.inc
PACKAGES = ${PN}
-RPROVIDES_${PN} += task-efl-sdk
-RREPLACES_${PN} += task-efl-sdk
-RCONFLICTS_${PN} += task-efl-sdk
RDEPENDS_${PN} = \
packagegroup-core-sdk \
${SDK-EFL} \
diff --git
a/meta-efl/recipes-efl/packagegroups/packagegroup-efl-standalone-sdk-target.bb
b/meta-efl/recipes-efl/packagegroups/packagegroup-efl-standalone-sdk-target.bb
index 1bcac45..6a3f33d 100644
---
a/meta-efl/recipes-efl/packagegroups/packagegroup-efl-standalone-sdk-target.bb
+++
b/meta-efl/recipes-efl/packagegroups/packagegroup-efl-standalone-sdk-target.bb
@@ -11,9 +11,6 @@ require packagegroup-efl-sdk.inc
PACKAGES = ${PN} ${PN}-dbg
-RPROVIDES_${PN} += task-efl-standalone-sdk-target
-RREPLACES_${PN} += task-efl-standalone-sdk-target
-RCONFLICTS_${PN} += task-efl-standalone-sdk-target
RDEPENDS_${PN} = \
packagegroup-core-standalone-sdk-target \
${SDK-EFL} \
diff --git a/meta-efl/recipes-efl/packagegroups/packagegroup-x11-illume.bb
b/meta-efl/recipes-efl/packagegroups/packagegroup-x11-illume.bb
index 47f758a..63ef0f6 100644
--- a/meta-efl/recipes-efl/packagegroups/packagegroup-x11-illume.bb
+++ b/meta-efl/recipes-efl/packagegroups/packagegroup-x11-illume.bb
@@ -11,9 +11,6 @@ inherit packagegroup allarch
ETHEME ?= e-wm-theme-default
ECONFIG ?= e-wm-config-mobile
-RPROVIDES_${PN} += task-x11-illume
-RREPLACES_${PN} += task-x11-illume
-RCONFLICTS_${PN} += task-x11-illume
RDEPENDS_${PN} = \
packagegroup-core-x11-xserver \
packagegroup-core-x11-utils \
diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
b/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
index 08db943..ad1cd83 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
@@ -23,9 +23,6 @@ MACHINE_EXTRA_RRECOMMENDS ?=
#
TASK_BASIC_SSHDAEMON ?= dropbear openssh-sftp openssh-sftp-server
-RPROVIDES_${PN} += task-basic
-RREPLACES_${PN} += task-basic
-RCONFLICTS_${PN} += task-basic
#
# The section below is designed to match with packagegroup-boot, but doesn't
depend on it to allow for more freedom
# when writing image recipes.
diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb
b/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb
index 3b634f3..61a519d 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb
@@ -19,10 +19,6 @@ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?=
# Make sure we build the kernel
DEPENDS = virtual/kernel
-RPROVIDES_${PN} += task-boot
-RREPLACES_${PN} += task-boot
-RCONFLICTS_${PN} += task-boot
-
#
# minimal set of packages - needed to boot
#
diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb
b/meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb
index fbba23c..2a4b067 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb
@@ -10,13 +10,6 @@ inherit packagegroup allarch
PACKAGES += ${PN}-debug
-RPROVIDES_${PN} += task-cli-tools
-RPROVIDES_${PN}-debug += task-cli-tools-debug
-RREPLACES_${PN} += task-cli-tools
-RREPLACES_${PN}-debug += task-cli-tools-debug
-RCONFLICTS_${PN} += task-cli-tools
-RCONFLICTS_${PN}-debug += task-cli-tools-debug
-
RDEPENDS_${PN} = \
dbus-daemon-proxy \
dosfstools \
diff --git a/meta-oe/recipes-devtools/packagegroups/packagegroup-sdk-target.bb
b/meta-oe/recipes-devtools/packagegroups/packagegroup-sdk-target.bb
index 9b8cc9a..aafe63a 100644
--- a/meta-oe/recipes-devtools/packagegroups/packagegroup-sdk-target.bb
+++ b/meta-oe/recipes-devtools/packagegroups/packagegroup-sdk-target.bb
@@ -6,9 +6,9 @@ PR = r1
inherit packagegroup allarch
-RPROVIDES_${PN} += packagegroup-native-sdk task-sdk-target task-native-sdk
-RREPLACES_${PN} += packagegroup-native-sdk task-sdk-target task-native-sdk
-RCONFLICTS_${PN} += packagegroup-native-sdk task-sdk-target task-native-sdk
+RPROVIDES_${PN} += packagegroup-native-sdk
+RREPLACES_${PN} += packagegroup-native-sdk
+RCONFLICTS_${PN} += packagegroup-native-sdk
RDEPENDS_${PN} = gcc-symlinks g++-symlinks cpp cpp-symlinks \
binutils-symlinks \
perl-modules \
diff --git
a/meta-oe/recipes-graphics/packagegroups/packagegroup-fonts-truetype.bb
b/meta-oe/recipes-graphics/packagegroups/packagegroup-fonts-truetype.bb
index 931564f..632e7d4 100644
--- a/meta-oe/recipes-graphics/packagegroups/packagegroup-fonts-truetype.bb
+++
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
On Mon, 14 Jul 2014, Burton, Ross wrote:
On 14 July 2014 13:20, Robert P. J. Day rpj...@crashcourse.ca wrote:
but, as far as i can tell, that is the only class that requires a
package name hook, and it simply defines its own implementation -- it
does nothing with package.bbclass and makes no reference to the
exported function package_package_name_hook(). so am i just
misunderstanding something? what was the point of defining and
exporting that function in package.bbclass if no other class takes
advantage of it?
So there needs to be an empty implementation and EXPORT_FUNCTION for
package_package_name_hook so that you don't get cannot find
function package_name_hook when you don't have the debian.bbclass
enabled.
In cleaning that up I proposed removing the EXPORT_FUNCTION entirely
for the hook, but Richard recalled there being something out there
that did use the ability to chain up into debian.bbclass's
implementation, so I kept it.
uh oh ... now i'm a bit confused again so let me back up a bit
because i really want to understand this. my apologies for the tedium.
as i read it, the only purpose of EXPORT_FUNCTIONS is to support the
idea of being able to qualify a function with its class name so that
you can (effectively) have access to more than one function with the
same name at the same time. first, let's see where this is *not*
necessary.
as an example, base.bbclass defines the routine:
oe_runmake() {
oe_runmake_call $@ || die oe_runmake failed
}
now, since every class automatically inherits base.bbclass, all of
those classes can call oe_runmake(), right? that routine is in their
namespace, there is no need to export it, and they will all get that
function as it's defined in base.bbclass.
in addition, even if a class inherits base.bbclass, it has the right
to totally override that routine by redefining a new oe_runmake(),
yes? (or possibly _appending or _prepending to it.) in any event, at
any time, there is only one definition of a function called
oe_runmake() in scope. so far, so good?
what EXPORT_FUNCTIONS appears to do is simply allow you access to
more than one function with the same name, so let's look at
base.bbclass and, say, the do_fetch() routine:
python base_do_fetch() {
... snip code ...
}
...
EXPORT_FUNCTIONS do_fetch
what does the above do? it now allows you to define, say,
derived.bbclass, and define a new do_fetch() in terms of the base
do_fetch(), as in:
do_fetch() {
...
base_do_fetch()
...
}
however, if i created a new class that had no interest in redefining
do_fetch() and i was happy with the base definition, i could simply
continue to use the name do_fetch(), correct? the fact that that
function was exported in base.bbclass is not relevant to me if i am
not trying to redefine the name. (i suspect i could also refer to it
by the name base_do_fetch() if i wanted, but that's unnecessary.)
that's why i was confused by ross' earlier paragraph about
package_name_hook being defined in package.bbclass -- unless some
other class is going to try to access two functions called
package_naem_hook at the same time, i currently see no need to
export it in package.bbclass. however, if there was something else
going on somewhere that needed this as richard purdie suggested, then
i'd be interested in knowing what that is just to understand the whole
picture.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 2/2] libhugetlbfs: fix packaging
On Mon, Jul 14, 2014 at 10:41:34AM +0200, Koen Kooi wrote:
Libhugetlbs doesn't generate proper .so.X libs, only two .so files. Package
those in ${PN} and silence the resulting QA warning. This fixes:
ERROR: QA Issue: libhugetlbfs-tests rdepends on libhugetlbfs-dev
Signed-off-by: Koen Kooi koen.k...@linaro.org
---
meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
index af7ed3e..d3b64bf 100644
--- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
+++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
@@ -25,6 +25,7 @@ COMPATIBLE_HOST =
(x86_64|powerpc|powerpc64|aarch64).*-linux*
LIBARGS = LIB32=${baselib} LIB64=${baselib}
EXTRA_OEMAKE = 'ARCH=${TARGET_ARCH}' 'OPT=${CFLAGS}' 'CC=${CC}' ${LIBARGS}
V=1
+PARALLEL_MAKE_pn-${PN} =
Is _pn override really needed?
CFLAGS += -fexpensive-optimizations -frename-registers -fomit-frame-pointer
-g0
TARGET_CC_ARCH += ${LDFLAGS}
@@ -46,12 +47,15 @@ do_install() {
install-tests
}
-PARALLEL_MAKE_pn-${PN} =
PACKAGES =+ ${PN}-perl ${PN}-tests
+FILES_${PN} += ${libdir}/*.so
+FILES_${PN}-dev = ${includedir}
FILES_${PN}-dbg += ${libdir}/libhugetlbfs/tests/obj32/.debug
${libdir}/libhugetlbfs/tests/obj64/.debug
FILES_${PN}-perl = ${libdir}/perl
FILES_${PN}-tests += ${libdir}/libhugetlbfs/tests
+INSANE_SKIP_${PN} = dev-so
+
INHIBIT_PACKAGE_STRIP = 1
INHIBIT_PACKAGE_DEBUG_SPLIT = 1
--
1.9.3
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 2/2] libhugetlbfs: fix packaging
On 14 July 2014 16:54, Martin Jansa martin.ja...@gmail.com wrote:
On Mon, Jul 14, 2014 at 10:41:34AM +0200, Koen Kooi wrote:
Libhugetlbs doesn't generate proper .so.X libs, only two .so files.
Package those in ${PN} and silence the resulting QA warning. This fixes:
ERROR: QA Issue: libhugetlbfs-tests rdepends on libhugetlbfs-dev
Signed-off-by: Koen Kooi koen.k...@linaro.org
---
meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
index af7ed3e..d3b64bf 100644
--- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
+++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
@@ -25,6 +25,7 @@ COMPATIBLE_HOST =
(x86_64|powerpc|powerpc64|aarch64).*-linux*
LIBARGS = LIB32=${baselib} LIB64=${baselib}
EXTRA_OEMAKE = 'ARCH=${TARGET_ARCH}' 'OPT=${CFLAGS}' 'CC=${CC}'
${LIBARGS} V=1
+PARALLEL_MAKE_pn-${PN} =
Is _pn override really needed?
It isn't, I only moved the line without noticing the override. Do you want
me to respin?
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
On Monday 14 July 2014 09:33:25 Robert P. J. Day wrote:
On Mon, 14 Jul 2014, Burton, Ross wrote:
On 14 July 2014 13:20, Robert P. J. Day rpj...@crashcourse.ca wrote:
but, as far as i can tell, that is the only class that requires a
package name hook, and it simply defines its own implementation -- it
does nothing with package.bbclass and makes no reference to the
exported function package_package_name_hook(). so am i just
misunderstanding something? what was the point of defining and
exporting that function in package.bbclass if no other class takes
advantage of it?
So there needs to be an empty implementation and EXPORT_FUNCTION for
package_package_name_hook so that you don't get cannot find
function package_name_hook when you don't have the debian.bbclass
enabled.
In cleaning that up I proposed removing the EXPORT_FUNCTION entirely
for the hook, but Richard recalled there being something out there
that did use the ability to chain up into debian.bbclass's
implementation, so I kept it.
uh oh ... now i'm a bit confused again so let me back up a bit
because i really want to understand this. my apologies for the tedium.
as i read it, the only purpose of EXPORT_FUNCTIONS is to support the
idea of being able to qualify a function with its class name so that
you can (effectively) have access to more than one function with the
same name at the same time. first, let's see where this is *not*
necessary.
as an example, base.bbclass defines the routine:
oe_runmake() {
oe_runmake_call $@ || die oe_runmake failed
}
now, since every class automatically inherits base.bbclass, all of
those classes can call oe_runmake(), right? that routine is in their
namespace, there is no need to export it, and they will all get that
function as it's defined in base.bbclass.
in addition, even if a class inherits base.bbclass, it has the right
to totally override that routine by redefining a new oe_runmake(),
yes? (or possibly _appending or _prepending to it.) in any event, at
any time, there is only one definition of a function called
oe_runmake() in scope. so far, so good?
Yes.
what EXPORT_FUNCTIONS appears to do is simply allow you access to
more than one function with the same name, so let's look at
base.bbclass and, say, the do_fetch() routine:
python base_do_fetch() {
... snip code ...
}
...
EXPORT_FUNCTIONS do_fetch
what does the above do? it now allows you to define, say,
derived.bbclass, and define a new do_fetch() in terms of the base
do_fetch(), as in:
do_fetch() {
...
base_do_fetch()
...
}
however, if i created a new class that had no interest in redefining
do_fetch() and i was happy with the base definition, i could simply
continue to use the name do_fetch(), correct? the fact that that
function was exported in base.bbclass is not relevant to me if i am
not trying to redefine the name. (i suspect i could also refer to it
by the name base_do_fetch() if i wanted, but that's unnecessary.)
Yes.
that's why i was confused by ross' earlier paragraph about
package_name_hook being defined in package.bbclass -- unless some
other class is going to try to access two functions called
package_naem_hook at the same time, i currently see no need to
export it in package.bbclass. however, if there was something else
going on somewhere that needed this as richard purdie suggested, then
i'd be interested in knowing what that is just to understand the whole
picture.
I'm not sure what that example was I'm afraid, but maybe Richard can fill in
the blanks.
Cheers,
Paul;
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 2/2] libhugetlbfs: fix packaging
On Mon, Jul 14, 2014 at 05:04:48PM +0200, Koen Kooi wrote:
On 14 July 2014 16:54, Martin Jansa martin.ja...@gmail.com wrote:
On Mon, Jul 14, 2014 at 10:41:34AM +0200, Koen Kooi wrote:
Libhugetlbs doesn't generate proper .so.X libs, only two .so files.
Package those in ${PN} and silence the resulting QA warning. This fixes:
ERROR: QA Issue: libhugetlbfs-tests rdepends on libhugetlbfs-dev
Signed-off-by: Koen Kooi koen.k...@linaro.org
---
meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
index af7ed3e..d3b64bf 100644
--- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
+++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
@@ -25,6 +25,7 @@ COMPATIBLE_HOST =
(x86_64|powerpc|powerpc64|aarch64).*-linux*
LIBARGS = LIB32=${baselib} LIB64=${baselib}
EXTRA_OEMAKE = 'ARCH=${TARGET_ARCH}' 'OPT=${CFLAGS}' 'CC=${CC}'
${LIBARGS} V=1
+PARALLEL_MAKE_pn-${PN} =
Is _pn override really needed?
It isn't, I only moved the line without noticing the override. Do you want
me to respin?
Please do, thanks
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] Regarding ./configure and Makefile
Hi,
Suppose I have a package and to compile and install that package, it is
required to run following:
./configure
make
make install
Then how can I include these in my package receipe.
Please help.
Regards,
Himanshu
nbsp;
From: Robert Yang lt;liezhi.y...@windriver.comgt;
Sent: Fri, 11 Jul 2014 06:42:31
To: Himanshu Pandey lt;pandey_himansh...@rediffmail.comgt;
Cc: openembedded-devel@lists.openembedded.org
lt;openembedded-devel@lists.openembedded.orggt;
Subject: Re: Regarding pptpd package
Seems that we don't have the pptpd recipes, you can search from here:
http://layers.openembedded.org/layerindex/branch/master/recipes/?q=pptpd
For the configure error:
sh: util/bindvar.sh: No such file or directory
You need check where is the bindvar.sh, and why can't find it.
// Robert
On 07/10/2014 07:29 PM, Himanshu Pandey wrote:
gt; Hi,
gt;
gt; nbsp;From where can I find pptpd in git.
gt;
gt; Please help.
gt;
gt; Regards,
gt; Himanshu
gt;
gt;
gt;
gt;
gt; From: Robert Yang lt;liezhi.y...@windriver.comgt;
gt; Sent: Thu, 10 Jul 2014 16:24:38
gt; To: Himanshu Pandey lt;pandey_himansh...@rediffmail.comgt;
gt; Cc: openembedded-devel@lists.openembedded.org
gt; lt;openembedded-devel@lists.openembedded.orggt;
gt; Subject: Re: Regarding dhcp package
gt;
gt; The error is:
gt;
gt; configure: error: source directory already configured; run make distclean
gt; there first
gt;
gt; Try a clean build ?
gt;
gt; For example:
gt;
gt; bitbake dhcp -ccleansstate amp;amp; bitbake dhcp
gt;
gt; If you get the same error again, you may need inherit autotools-brokensep
gt; rather than autotools as a quick workaround.
gt;
gt; // Robert
gt;
gt; On 07/10/2014 05:50 PM, Himanshu Pandey wrote:
gt; nbsp;gt; Hi,
gt; nbsp;gt;
gt; nbsp;gt; As advised by you I have done that but again I am getting an
error.
gt; nbsp;gt;
gt; nbsp;gt; Please find the log as attachment.
gt; nbsp;gt;
gt; nbsp;gt; Regards,
gt; nbsp;gt; Himanshu
gt; nbsp;gt;
gt; nbsp;gt; From: Robert Yang lt;liezhi.y...@windriver.comgt;
gt; nbsp;gt; Sent: Thu, 10 Jul 2014 14:08:59
gt; nbsp;gt; To: Himanshu Pandey lt;pandey_himansh...@rediffmail.comgt;
gt; nbsp;gt; Cc: openembedded-devel@lists.openembedded.org
gt; nbsp;gt; lt;openembedded-devel@lists.openembedded.orggt;
gt; nbsp;gt; Subject: Re: Regarding dhcp package
gt; nbsp;gt;
gt; nbsp;gt;
gt; nbsp;gt; On 07/10/2014 04:17 PM, Himanshu Pandey wrote:
gt; nbsp;gt; nbsp;gt; Hi Robert,
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt; I am getting an error while compiling my dhcp
package. Please find the log as
gt; nbsp;gt; nbsp;gt; attachment.
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt; My dhcp bb file is as follows:
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt; SECTION = base
gt; nbsp;gt; nbsp;gt; SUMMARY = Internet Software Consortium DHCP package
gt; nbsp;gt; nbsp;gt; DESCRIPTION = DHCP (Dynamic Host Configuration
Protocol) is a protocol \
gt; nbsp;gt; nbsp;gt; which allows individual devices on an IP network to
get their own \
gt; nbsp;gt; nbsp;gt; network configuration information from a server.
nbsp;DHCP helps make it \
gt; nbsp;gt; nbsp;gt; easier to administer devices.
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt; HOMEPAGE = http://www.isc.org/;
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt; LICENSE = CLOSED
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt; DEPENDS = openssl bind
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt; SRC_URI =
gt; nbsp;gt;
svn://192.43.23.436/home/repo/dhcp-4.2.4-P2;module=branch;user=;pswd=
gt;
lt;http://192.43.23.436/home/repo/dhcp-4.2.4-P2;module=branch;user=;pswd=gt;
gt; nbsp;gt;
lt;http://192.43.23.436/home/repo/dhcp-4.2.4-P2;module=branch;user=;pswd=gt;
gt; nbsp;gt; nbsp;gt; SRCREV = ${AUTOREV}
gt; nbsp;gt; nbsp;gt; S= ${WORKDIR}/trunk
gt; nbsp;gt; nbsp;gt; #inherit autotools
gt; nbsp;gt; nbsp;gt; do_compile() {
gt; nbsp;gt; nbsp;gt; nbsp; nbsp; nbsp; nbsp; nbsp;#cp -f
${WORKDIR}/trunk/include/site.h ${S}/includes
gt; nbsp;gt; nbsp;gt; nbsp; nbsp; nbsp; nbsp; nbsp;cd ../trunk
gt; nbsp;gt; nbsp;gt; nbsp; nbsp; nbsp; nbsp; nbsp;./configure
--prefix=${prefix} --host=${HOST_SYS}
gt; nbsp;gt; nbsp;gt; nbsp; nbsp; nbsp; nbsp; nbsp;make
gt; nbsp;gt; nbsp;gt; }
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt;
gt; nbsp;gt; I think that these are wrong, you should not disable the
inherit autotools,
gt; nbsp;gt; and should not use ./configure or make directly, try to
enable
gt; nbsp;gt; the inherit autotools, and remove the do_compile section to
see what
gt; nbsp;gt; would happen, maybe you need:
gt; nbsp;gt;
gt; nbsp;gt; inherit autotools
gt; nbsp;gt; S = ${WORKDIR}/trunk
gt; nbsp;gt;
gt; nbsp;gt; // Robert
gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt;
gt; nbsp;gt; nbsp;gt; do_install_append () {
gt; nbsp;gt; nbsp;gt; nbsp; nbsp; nbsp; nbsp; nbsp;install -d
${D}${sysconfdir}/init.d
gt; nbsp;gt; nbsp;gt; nbsp; nbsp; nbsp; nbsp; nbsp;install -d
${D}${sysconfdir}/default
gt; nbsp;gt; nbsp;gt; nbsp; nbsp; nbsp;
Re: [oe] Regarding ./configure and Makefile
On 14 July 2014 17:25, Himanshu Pandey pandey_himansh...@rediffmail.com wrote: Then how can I include these in my package receipe. Is that configure script actually generated by autoconf? If so, then you can inherit autotools. Otherwise you'll need to provide a do_configure() do_compile() and do_install() functions that call the right things. Ross -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][MASTER][PATCH] lxdm: add libpam DEPENDS
In theory pam optional, as it's a configure option (and it's been a USE flag forever). I don't use systemd, bu I would guess the systemd login manager might work on its own (ie, without pam). Not sure if lxdm supports remote auth or whatever, but for now I'll assume that pam is optional and test what I can. I'll let you test the systemd version... ;) Steve On Thu, Jul 10, 2014 at 8:09 AM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi Steve, On 25 June 2014 00:16, Stephen Arnold stephen.arnol...@gmail.com wrote: Yeah, it would certainly make more sense with a packageconfig option for that; currently it doesn't work either with or without the pam feature due to the missing plugins. So if you want hard deps, then the plugins need to be included as rdeps. Otherwise, adding an appropriate packageconfig option to the flexible depends sounds good. I still need an init script anyway, so... Just curious to know if you're still working on this? It doesn't look to me as though pam is optional with lxdm (?) Best regards, Trevor -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] State of bitbake world, Failed tasks 2014-07-14
http://www.openembedded.org/wiki/Bitbake_World_Status
== Failed tasks 2014-07-14 ==
=== common (31) ===
* meta-browser/recipes-mozilla/firefox/firefox_10.0.11esr.bb, do_compile
*
meta-openembedded/meta-filesystems/recipes-filesystems/owfs/owfs_2.9p1.bb,
do_compile
*
meta-openembedded/meta-filesystems/recipes-filesystems/smbnetfs/smbnetfs_git.bb,
do_configure
*
meta-openembedded/meta-multimedia/recipes-mkv/mkvtoolnix/mkvtoolnix_5.9.0.bb,
do_configure
*
meta-openembedded/meta-multimedia/recipes-multimedia/openal/openal-soft_1.15.1.bb,
do_compile
* meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_2.1.4.bb,
do_configure
* meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvstreams_4.6.1.bb,
do_install
* meta-openembedded/meta-oe/recipes-core/llvm/llvm3.3_3.3.bb, do_package_qa
* meta-openembedded/meta-oe/recipes-devtools/python/python-cython_git.bb,
do_package_qa
* meta-openembedded/meta-oe/recipes-devtools/python/python-pyyaml_3.10.bb,
do_compile
* meta-openembedded/meta-oe/recipes-extended/hexedit/hexedit_1.2.13.bb,
do_compile
* meta-openembedded/meta-oe/recipes-extended/lcdproc/lcdproc_0.5.5.bb,
do_compile
* meta-openembedded/meta-oe/recipes-navigation/gdal/gdal_1.10.1.bb,
do_install
* meta-openembedded/meta-oe/recipes-navigation/orrery/orrery_2.7.bb,
do_compile
* meta-openembedded/meta-oe/recipes-support/daemonize/daemonize_git.bb,
do_configure
* meta-openembedded/meta-oe/recipes-support/farsight/libnice_0.0.13.bb,
do_configure
* meta-openembedded/meta-oe/recipes-support/fltk/fltk_1.1.10.bb, do_install
* meta-openembedded/meta-oe/recipes-support/pidgin/libotr_4.0.0.bb,
do_compile
* meta-openembedded/meta-webserver/recipes-webadmin/webmin/webmin_1.620.bb,
do_package
* meta-openembedded/meta-xfce/recipes-xfce/xfconf/xfconf_4.10.0.bb,
do_configure
* meta-smartphone/meta-aurora/recipes-aurora/aurora/aurora-daemon_git.bb,
do_configure
*
meta-smartphone/meta-fso/recipes-freesmartphone/freesmartphone/zhone_git.bb,
do_compile
*
meta-smartphone/meta-fso/recipes-freesmartphone/python/python-pyrtc_git.bb,
do_compile
* meta-smartphone/meta-palm/recipes-bsp/tsmd/tsmd_git.bb, do_configure
* meta-smartphone/meta-shr/recipes-shr/3rdparty/numptyphysics_svn.bb,
do_configure
* meta-smartphone/meta-shr/recipes-shr/3rdparty/sensmon_git.bb, do_configure
* meta-smartphone/meta-shr/recipes-shr/3rdparty/vagalume_0.8.5.bb,
do_configure
* meta-smartphone/meta-shr/recipes-shr/3rdparty/valacompass_git.bb,
do_configure
* meta-smartphone/meta-shr/recipes-shr/games/mokomaze_0.5.5.bb, do_configure
* meta-smartphone/meta-shr/recipes-shr/shr/phonefsod_git.bb, do_configure
* meta-smartphone/meta-shr/recipes-shr/shr/python-phoneutils_git.bb,
do_compile
=== common-x86 (4) ===
* meta-browser/recipes-browser/chromium/chromium_35.0.1916.114.bb,
do_compile
*
meta-openembedded/meta-initramfs/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.10.bb,
do_package_qa
*
meta-openembedded/meta-oe/recipes-devtools/concurrencykit/concurrencykit_git.bb,
do_compile
*
meta-smartphone/meta-fso/recipes-freesmartphone/freesmartphone/mioctl_git.bb,
do_configure
=== qemuarm (14) ===
* meta-openembedded/meta-efl/recipes-navigation/mcnavi/mcnavi_0.3.4.bb,
do_configure
*
meta-openembedded/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb,
do_configure
*
meta-openembedded/meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.16.bb,
do_compile
*
meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb,
do_package_qa
* meta-openembedded/meta-oe/recipes-extended/hplip/hplip_3.12.6.bb,
do_compile
* meta-openembedded/meta-oe/recipes-extended/subsurface/subsurface_git.bb,
do_compile
* meta-openembedded/meta-oe/recipes-graphics/fbgrab/fbgrab_1.2.bb,
do_install
* meta-openembedded/meta-oe/recipes-support/flite/flite-alsa_1.3.bb,
do_install
* meta-openembedded/meta-oe/recipes-support/usbpath/usbpath_svn.bb,
do_configure
* meta-openembedded/meta-webserver/recipes-httpd/monkey/monkey_1.5.1.bb,
do_package
*
meta-smartphone/meta-fso/recipes-freesmartphone/freesmartphone/fso-gpsd_git.bb,
do_configure
*
meta-smartphone/meta-osmocombb/recipes-osmocombb/osmoconbb/osmocon_git.bb,
do_configure
* openembedded-core/meta/recipes-kernel/lttng/lttng-modules_2.3.3.bb,
do_compile
*
openembedded-core/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb,
do_configure
=== qemux86 (1) ===
* openembedded-core/meta/recipes-bsp/usbinit/usbinit.bb, do_install
=== qemux86_64 (2) ===
*
meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb,
do_compile
* meta-qt5/recipes-qt/qt5/qtwebengine_git.bb, do_compile
=== Number of failed tasks ===
{| class=wikitable
|-
||qemuarm ||45
[oe] [meta-handheld][PATCH] Revert zaurus collie: remove hardcoded mem=64M
Unfortunately the default for sa1100/collie is 16M so for collie it is necessary to specify mem=64M on cmdline. The very rare 5000D users will have to change that to mem=32M. This reverts commit f4f05028f5ad72a81d6620340fe1c92ac6486890. Signed-off-by: Andrea Adami andrea.ad...@gmail.com --- conf/machine/include/zaurus.inc | 2 +- recipes-kernel/linux/linux-yocto-3.10/collie/collie.cfg | 2 +- recipes-kernel/linux/linux-yocto-3.14/collie/defconfig| 2 +- recipes-kernel/linux/linux-yocto-tiny-kexecboot-3.10/collie/defconfig | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/conf/machine/include/zaurus.inc b/conf/machine/include/zaurus.inc index 1f1d28f..f74b987 100644 --- a/conf/machine/include/zaurus.inc +++ b/conf/machine/include/zaurus.inc @@ -39,7 +39,7 @@ SERIAL_CONSOLE_collie = 115200 ttySA0 CMDLINE_akita = console=ttyS0,115200n8 console=tty1 fbcon=rotate:1 CMDLINE_c7x0 = console=ttyS0,115200n8 console=tty1 -CMDLINE_collie = console=ttySA0,115200n8 console=tty1 fbcon=rotate:1 +CMDLINE_collie = console=ttySA0,115200n8 console=tty1 mem=64M fbcon=rotate:1 CMDLINE_poodle = console=ttyS0,115200n8 console=tty1 fbcon=rotate:1 CMDLINE_spitz = console=ttyS0,115200n8 console=tty1 fbcon=rotate:1 CMDLINE_tosa = console=ttyS0,115200n8 console=tty1 diff --git a/recipes-kernel/linux/linux-yocto-3.10/collie/collie.cfg b/recipes-kernel/linux/linux-yocto-3.10/collie/collie.cfg index 323893e..5238c69 100644 --- a/recipes-kernel/linux/linux-yocto-3.10/collie/collie.cfg +++ b/recipes-kernel/linux/linux-yocto-3.10/collie/collie.cfg @@ -47,7 +47,7 @@ CONFIG_SPARSEMEM_EXTREME=y # # Boot options # -CONFIG_CMDLINE=console=ttySA0,115200n8 console=tty1 fbcon=rotate:1 loglevel=3 +CONFIG_CMDLINE=console=ttySA0,115200n8 console=tty1 mem=64M fbcon=rotate:1 loglevel=3 # # RAM/ROM/Flash chip drivers diff --git a/recipes-kernel/linux/linux-yocto-3.14/collie/defconfig b/recipes-kernel/linux/linux-yocto-3.14/collie/defconfig index 32877cd..36ceadb 100644 --- a/recipes-kernel/linux/linux-yocto-3.14/collie/defconfig +++ b/recipes-kernel/linux/linux-yocto-3.14/collie/defconfig @@ -50,7 +50,7 @@ CONFIG_AEABI=y CONFIG_OABI_COMPAT=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 -CONFIG_CMDLINE=console=ttySA0,115200n8 console=tty1 fbcon=rotate:1 loglevel=3 +CONFIG_CMDLINE=console=ttySA0,115200n8 console=tty1 mem=64M fbcon=rotate:1 loglevel=3 CONFIG_KEXEC=y CONFIG_BINFMT_MISC=m CONFIG_PM_RUNTIME=y diff --git a/recipes-kernel/linux/linux-yocto-tiny-kexecboot-3.10/collie/defconfig b/recipes-kernel/linux/linux-yocto-tiny-kexecboot-3.10/collie/defconfig index d57e807..2903270 100644 --- a/recipes-kernel/linux/linux-yocto-tiny-kexecboot-3.10/collie/defconfig +++ b/recipes-kernel/linux/linux-yocto-tiny-kexecboot-3.10/collie/defconfig @@ -34,7 +34,7 @@ CONFIG_AEABI=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 -CONFIG_CMDLINE=console=tty1 console=ttySA0,115200n8 fbcon=rotate:1 loglevel=3 +CONFIG_CMDLINE=console=tty1 console=ttySA0,115200n8 fbcon=rotate:1 mem=64M loglevel=3 CONFIG_CMDLINE_FORCE=y CONFIG_KEXEC=y # CONFIG_BINFMT_SCRIPT is not set -- 1.9.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-handheld][PATCH] linux-yocto_3.14: zaurus: config serial 8250 as module
Zaurus is using pxa/sa1100 serial so we only need the pcmcia serial cs for i.e. bluetooth cf cards. Avoid device address conflict on pxa (fix pending upstream). Signed-off-by: Andrea Adami andrea.ad...@gmail.com --- recipes-kernel/linux/linux-yocto-3.14/akita/defconfig | 4 ++-- recipes-kernel/linux/linux-yocto-3.14/c7x0/defconfig | 4 ++-- recipes-kernel/linux/linux-yocto-3.14/collie/defconfig | 4 ++-- recipes-kernel/linux/linux-yocto-3.14/poodle/defconfig | 4 ++-- recipes-kernel/linux/linux-yocto-3.14/spitz/defconfig | 4 ++-- recipes-kernel/linux/linux-yocto-3.14/tosa/defconfig | 4 ++-- 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/recipes-kernel/linux/linux-yocto-3.14/akita/defconfig b/recipes-kernel/linux/linux-yocto-3.14/akita/defconfig index 8e58216..7d7046a 100644 --- a/recipes-kernel/linux/linux-yocto-3.14/akita/defconfig +++ b/recipes-kernel/linux/linux-yocto-3.14/akita/defconfig @@ -242,8 +242,8 @@ CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_INPUT_MISC=y CONFIG_INPUT_UINPUT=m -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250=m +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_PXA=y CONFIG_SERIAL_PXA_CONSOLE=y diff --git a/recipes-kernel/linux/linux-yocto-3.14/c7x0/defconfig b/recipes-kernel/linux/linux-yocto-3.14/c7x0/defconfig index 3a112db..2714fd7 100644 --- a/recipes-kernel/linux/linux-yocto-3.14/c7x0/defconfig +++ b/recipes-kernel/linux/linux-yocto-3.14/c7x0/defconfig @@ -223,8 +223,8 @@ CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_INPUT_MISC=y CONFIG_INPUT_UINPUT=m -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250=m +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_PXA=y CONFIG_SERIAL_PXA_CONSOLE=y diff --git a/recipes-kernel/linux/linux-yocto-3.14/collie/defconfig b/recipes-kernel/linux/linux-yocto-3.14/collie/defconfig index 8c84b6c..55cbd91 100644 --- a/recipes-kernel/linux/linux-yocto-3.14/collie/defconfig +++ b/recipes-kernel/linux/linux-yocto-3.14/collie/defconfig @@ -226,8 +226,8 @@ CONFIG_KEYBOARD_LOCOMO=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_INPUT_MISC=y CONFIG_INPUT_UINPUT=m -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250=m +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_SA1100=y CONFIG_SERIAL_SA1100_CONSOLE=y diff --git a/recipes-kernel/linux/linux-yocto-3.14/poodle/defconfig b/recipes-kernel/linux/linux-yocto-3.14/poodle/defconfig index 3e76043..1805246 100644 --- a/recipes-kernel/linux/linux-yocto-3.14/poodle/defconfig +++ b/recipes-kernel/linux/linux-yocto-3.14/poodle/defconfig @@ -221,8 +221,8 @@ CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_INPUT_MISC=y CONFIG_INPUT_UINPUT=m -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250=m +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_PXA=y CONFIG_SERIAL_PXA_CONSOLE=y diff --git a/recipes-kernel/linux/linux-yocto-3.14/spitz/defconfig b/recipes-kernel/linux/linux-yocto-3.14/spitz/defconfig index 56db157..bece3f9 100644 --- a/recipes-kernel/linux/linux-yocto-3.14/spitz/defconfig +++ b/recipes-kernel/linux/linux-yocto-3.14/spitz/defconfig @@ -241,8 +241,8 @@ CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_INPUT_MISC=y CONFIG_INPUT_UINPUT=m -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250=m +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_PXA=y CONFIG_SERIAL_PXA_CONSOLE=y diff --git a/recipes-kernel/linux/linux-yocto-3.14/tosa/defconfig b/recipes-kernel/linux/linux-yocto-3.14/tosa/defconfig index 799be1f..dc8f2ba 100644 --- a/recipes-kernel/linux/linux-yocto-3.14/tosa/defconfig +++ b/recipes-kernel/linux/linux-yocto-3.14/tosa/defconfig @@ -242,8 +242,8 @@ CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_WM97XX=m CONFIG_INPUT_MISC=y CONFIG_INPUT_UINPUT=m -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250=m +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_PXA=y CONFIG_SERIAL_PXA_CONSOLE=y -- 1.9.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass
then i noticed that the splash feature is defined, not in
core-image.bbclass, but in the more basic image.bbclass, as is
package-management:
FEATURE_PACKAGES_package-management = ${ROOTFS_PKGMANAGE}
SPLASH ?= psplash
FEATURE_PACKAGES_splash = ${SPLASH}
And then there is debug-tweaks for which the hooks are defined in
image.bbclass including the function zap_empty_root_password but the
post-processing is added to the variable by core-image.bbclass:
core-image.bbclass: ROOTFS_POSTPROCESS_COMMAND +=
'${@bb.utils.contains(IMAGE_FEATURES, debug-tweaks, ,
zap_empty_root_password ; ,d)}'
Since image.bbclass also adds the debug-tweaks to the valid image feature
list
image.bbclass:IMAGE_FEATURES[validitems] += debug-tweaks read-only-rootfs
my inclination would be to move the addition to ROOTFS_POSTPROCESS_COMMAND
from core-image.bbclass to image.bbclass.
The image feature readonly-rootfs is also added to the valid list by
image.bbclass.
Consequently this makes the image features splash, debug-tweaks,
package-management, splash and readonly-rootfs available to image recipes
that inherit image.bbclass while h/w codecs and others are added by
core-image.bbclass and are only available when an image recipe inherits
core-image.
Then there are the image features dbg-pkgs, dev-pkgs, doc-pkgs,
staticdev-pkgs and ptest-pkgs which are added to the image feature list by
populate_sdk_base.bbclass which image.bbclass inherits and hence they are
available to all images.
so is there some rationale for deciding which FEATURE_PACKAGES
settings are defined in core-image, while others are defined in
image?
That I do not really know. However, to some extend the choices as to what
class adds what image features make sense, alth
- The minimal set of features splash, debug-tweaks, package-management,
splash and readonly-rootfs to be added by the basic image.bbclass.
- Extended image features added by core-image.bbclass.
- SDK related image features by the populate_sdk_base.bbclass.
My $0.02
Cheers,
:rjs
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass
On Mon, 14 Jul 2014, Rudolf Streif wrote:
then i noticed that the splash feature is defined, not in
core-image.bbclass, but in the more basic image.bbclass, as is
package-management:
FEATURE_PACKAGES_package-management = ${ROOTFS_PKGMANAGE}
SPLASH ?= psplash
FEATURE_PACKAGES_splash = ${SPLASH}
And then there is debug-tweaks for which the hooks are defined in
image.bbclass including the function zap_empty_root_password but the
post-processing is added to the variable by core-image.bbclass:
core-image.bbclass: ROOTFS_POSTPROCESS_COMMAND +=
'${@bb.utils.contains(IMAGE_FEATURES, debug-tweaks, ,
zap_empty_root_password ; ,d)}'
Since image.bbclass also adds the debug-tweaks to the valid image
feature list
image.bbclass:IMAGE_FEATURES[validitems] += debug-tweaks read-only-rootfs
my inclination would be to move the addition to ROOTFS_POSTPROCESS_COMMAND
from core-image.bbclass to image.bbclass.
The image feature readonly-rootfs is also added to the valid list by
image.bbclass.
i didn't notice the rest of these as i stopped looking after the
splash example and thought i'd ask about it.
Consequently this makes the image features splash, debug-tweaks,
package-management, splash and readonly-rootfs available to image
recipes that inherit image.bbclass while h/w codecs and others are
added by core-image.bbclass and are only available when an image
recipe inherits core-image.
is there something special about hwcodecs that suggests it should
stay in core-image rather than moving to image as well? i'm just
trying to understand the rationale.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] avoiding hard-coded filenames in package file lists
occasionally, i still trip across stuff like this (this is from
oe-core):
meta/recipes-graphics/ttf-fonts/ttf-bitstream-vera_1.10.bb:FILES_${PN} = /etc
${datadir}/fonts
i'm assuming that one should avoid hard-coding names like /etc in
this case, and instead use (in this case) ${sysconfdir}, yes?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] php.inc removing directories that do not exist
php.inc - do_install_append_pn-php:
rm -rf ${D}/${TMPDIR}
[...]
TMP=`dirname ${D}/${TMPDIR}`
while test ${TMP} != ${D}; do
rmdir ${TMP}
TMP=`dirname ${TMP}`;
done
Added in this commit:
https://github.com/openembedded/meta-oe/commit/357915b6d11dfa612fbadaa4966a0b3e0f332467
This is failing when I try to install PHP using Ubuntu 14.04.
Here are the variables being used:
${D} (bitbake destination dir) =
[...]/build/tmp/work/cortexa9hf-vfp-neon-reach-linux-gnueabi/php/5.4.14-r6.0/image
${TMPDIR} (bitbake temp dir) = [...]/build/tmp
The combination of ${D}/${TMPDIR} doesn't make any sense to me. Maybe
the intention was something like ${D}/tmp?
I've removed these references to the dubious directory ${D}/${TMPDIR}
and everything builds fine without any warnings or errors. Anyone know
why this code exists?
Kind Regards,
Stephano
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass
is there something special about hwcodecs that suggests it should stay in core-image rather than moving to image as well? i'm just trying to understand the rationale. Not necessarily. But I would consider them extended features and they belong into core-image in my opinion. Not all embedded systems need them. Many don't have video or audio support. I would even suggest to move splash to core-image. If a device does not have video there is not reason for a splash screen. I consider debug-tweaks, package-management, and readonly-rootfs the basic image features to be in image. :rjs -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] is it addtask do_X ... or addtask X ... or does it matter?
On Mon, Jul 14, 2014 at 3:11 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: if what chris writes is accurate, there are some broken class and recipe files in oe-core: classes/kernel.bbclass:addtask do_strip before do_sizecheck after do_kernel_link_vmlinux classes/staging.bbclass:addtask do_populate_sysroot_setscene classes/insane.bbclass:addtask do_package_qa after do_packagedata do_package before do_build classes/insane.bbclass:addtask do_package_qa_setscene classes/package_rpm.bbclass:addtask do_package_write_rpm_setscene classes/license.bbclass:addtask do_populate_lic_setscene classes/archiver.bbclass:addtask do_ar_original after do_unpack classes/archiver.bbclass:addtask do_unpack_and_patch after do_patch classes/archiver.bbclass:addtask do_ar_patched after do_unpack_and_patch classes/archiver.bbclass:addtask do_ar_configured after do_unpack_and_patch classes/archiver.bbclass:addtask do_dumpdata classes/archiver.bbclass:addtask do_ar_recipe classes/archiver.bbclass:addtask do_deploy_archives before do_build classes/deploy.bbclass:addtask do_deploy_setscene classes/package_deb.bbclass:addtask do_package_write_deb_setscene classes/package.bbclass:addtask do_package_setscene classes/package.bbclass:addtask do_packagedata_setscene classes/package_ipk.bbclass:addtask do_package_write_ipk_setscene recipes-core/eglibc/eglibc-package.inc:addtask do_install_locale after do_install before do_populate_sysroot do_package recipes-core/base-passwd/base-passwd_3.5.29.bb:addtask do_package after do_populate_sysroot recipes-core/meta/package-index.bb:addtask do_package_index before do_build recipes-devtools/gcc/gcc-configure-common.inc:addtask do_preconfigure after do_patch before do_configure recipes-support/boost/boost.inc:addtask do_boostconfig after do_patch before do_configure surely all of the above can't be broken, can they? I stand corrected, looks like code in bb.build.addtask automatically adds do_ if it isn't present. We probably should pick one and fix the metadata to be consistent, however :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH][meta-perl][v2] libxml-libxml-perl: add recipe
From: Roy Li rongqing...@windriver.com
This module is an interface to libxml2, providing XML and HTML parsers \
with DOM, SAX and XMLReader interfaces, a large subset of DOM Layer 3 \
interface and a XML::XPath-like interface to XPath API of libxml2. \
The module is split into several packages which are not described in this \
section; unless stated otherwise, you only need to use XML::LibXML; in \
your programs.
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../libxml-libxml-perl/disable-libxml2-check.patch | 79 +
.../fix-CATALOG-conditional-compile.patch | 31 +++
.../using-DOCB-conditional.patch | 91
.../libxml/libxml-libxml-perl_2.0116.bb| 47 ++
4 files changed, 248 insertions(+)
create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl/disable-libxml2-check.patch
create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl/using-DOCB-conditional.patch
create mode 100644 meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb
diff --git
a/meta-perl/recipes-perl/libxml/libxml-libxml-perl/disable-libxml2-check.patch
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/disable-libxml2-check.patch
new file mode 100644
index 000..a8e7cc1
--- /dev/null
+++
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/disable-libxml2-check.patch
@@ -0,0 +1,79 @@
+Do not use the _libxml_check_lib() on cross-compile
+
+Upstream-Status: Inappropriate [configuration]
+
+xml2 have been added into package's DEPENDS, so not need to use the
+_libxml_check_lib() to check it again, and _libxml_check_lib() always
+return false on cross-compile environment
+
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ Makefile.PL | 52 ++--
+ 1 file changed, 26 insertions(+), 26 deletions(-)
+
+diff --git a/Makefile.PL b/Makefile.PL
+index c0485f1..09c676b 100644
+--- a/Makefile.PL
b/Makefile.PL
+@@ -411,32 +411,32 @@ sub _libxml_check_lib {
+ }
+ }
+
+-print Checking for ability to link against xml2...;
+-if ( _libxml_check_lib('xml2') ) {
+-print yes\n;
+-}
+-else {
+-print no\n;
+-print Checking for ability to link against libxml2...;
+-if ( _libxml_check_lib('libxml2')) {
+-print yes\n;
+-}
+-else {
+-print STDERR DEATH;
+-libxml2, zlib, and/or the Math library (-lm) have not been found.
+-Try setting LIBS and INC values on the command line
+-Or get libxml2 from
+- http://xmlsoft.org/
+-If you install via RPMs, make sure you also install the -devel
+-RPMs, as this is where the headers (.h files) are.
+-
+-Also, you may try to run perl Makefile.PL with the DEBUG=1 parameter
+-to see the exact reason why the detection of libxml2 installation
+-failed or why Makefile.PL was not able to compile a test program.
+-DEATH
+-exit 0; # 0 recommended by http://cpantest.grango.org (Notes for CPAN
Authors)
+-}
+-}
++#print Checking for ability to link against xml2...;
++#if ( _libxml_check_lib('xml2') ) {
++#print yes\n;
++#}
++#else {
++#print no\n;
++#print Checking for ability to link against libxml2...;
++#if ( _libxml_check_lib('libxml2')) {
++#print yes\n;
++#}
++#else {
++#print STDERR DEATH;
++#libxml2, zlib, and/or the Math library (-lm) have not been found.
++#Try setting LIBS and INC values on the command line
++#Or get libxml2 from
++# http://xmlsoft.org/
++#If you install via RPMs, make sure you also install the -devel
++#RPMs, as this is where the headers (.h files) are.
++#
++#Also, you may try to run perl Makefile.PL with the DEBUG=1 parameter
++#to see the exact reason why the detection of libxml2 installation
++#failed or why Makefile.PL was not able to compile a test program.
++#DEATH
++#exit 0; # 0 recommended by http://cpantest.grango.org (Notes for
CPAN Authors)
++#}
++#}
+
+ # -- #
+ # _NOW_ write the Makefile
+--
+1.7.10.4
+
diff --git
a/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
new file mode 100644
index 000..1dd9fb3
--- /dev/null
+++
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
@@ -0,0 +1,31 @@
+[PATCH] Fix a compile error
+
+Upstream-Status: Pending
+
+Fix a compile error by conditional using 'catal' since catal
+is only defined when LIBXML_CATALOG_ENABLED is enabled.
+
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ LibXML.xs |2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/LibXML.xs b/LibXML.xs
+index 66da04b..45da681 100644
+--- a/LibXML.xs
b/LibXML.xs
+@@ -2777,9 +2777,11 @@ _default_catalog( self, catalog )
+
Re: [oe] defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass
On Mon, 14 Jul 2014, Rudolf Streif wrote: is there something special about hwcodecs that suggests it should stay in core-image rather than moving to image as well? i'm just trying to understand the rationale. Not necessarily. But I would consider them extended features and they belong into core-image in my opinion. Not all embedded systems need them. Many don't have video or audio support. I would even suggest to move splash to core-image. If a device does not have video there is not reason for a splash screen. I consider debug-tweaks, package-management, and readonly-rootfs the basic image features to be in image. and i have no problem with that rationale. :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] is it addtask do_X ... or addtask X ... or does it matter?
On Mon, 14 Jul 2014, Christopher Larson wrote: On Mon, Jul 14, 2014 at 3:11 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: if what chris writes is accurate, there are some broken class and recipe files in oe-core: classes/kernel.bbclass:addtask do_strip before do_sizecheck after do_kernel_link_vmlinux classes/staging.bbclass:addtask do_populate_sysroot_setscene classes/insane.bbclass:addtask do_package_qa after do_packagedata do_package before do_build classes/insane.bbclass:addtask do_package_qa_setscene classes/package_rpm.bbclass:addtask do_package_write_rpm_setscene classes/license.bbclass:addtask do_populate_lic_setscene classes/archiver.bbclass:addtask do_ar_original after do_unpack classes/archiver.bbclass:addtask do_unpack_and_patch after do_patch classes/archiver.bbclass:addtask do_ar_patched after do_unpack_and_patch classes/archiver.bbclass:addtask do_ar_configured after do_unpack_and_patch classes/archiver.bbclass:addtask do_dumpdata classes/archiver.bbclass:addtask do_ar_recipe classes/archiver.bbclass:addtask do_deploy_archives before do_build classes/deploy.bbclass:addtask do_deploy_setscene classes/package_deb.bbclass:addtask do_package_write_deb_setscene classes/package.bbclass:addtask do_package_setscene classes/package.bbclass:addtask do_packagedata_setscene classes/package_ipk.bbclass:addtask do_package_write_ipk_setscene recipes-core/eglibc/eglibc-package.inc:addtask do_install_locale after do_install before do_populate_sysroot do_package recipes-core/base-passwd/base-passwd_3.5.29.bb:addtask do_package after do_populate_sysroot recipes-core/meta/package-index.bb:addtask do_package_index before do_build recipes-devtools/gcc/gcc-configure-common.inc:addtask do_preconfigure after do_patch before do_configure recipes-support/boost/boost.inc:addtask do_boostconfig after do_patch before do_configure surely all of the above can't be broken, can they? I stand corrected, looks like code in bb.build.addtask automatically adds do_ if it isn't present. We probably should pick one and fix the metadata to be consistent, however :) ah, yes, there it is: def addtask(task, before, after, d): if task[:3] != do_: task = do_ + task that just invites abuse, doesn't it? :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] vsftpd: fix install warning
From: Wenzong Fan wenzong@windriver.com
WARNING: QA Issue: vsftpd: Files/directories were installed but not shipped
/run
/run/vsftpd
/run/vsftpd/empty
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb
b/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb
index 0698a63..5df8211 100644
--- a/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb
+++ b/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb
@@ -70,7 +70,11 @@ do_install() {
sed -i s:/lib/security:${base_libdir}/security:
${D}${sysconfdir}/pam.d/vsftpd
sed -i s:ftpusers:vsftpd.ftpusers: ${D}${sysconfdir}/pam.d/vsftpd
fi
-install -d ${D}${localstatedir}/run/vsftpd/empty
+if ${@base_contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)};
then
+install -d ${D}${sysconfdir}/tmpfiles.d
+echo d /var/run/vsftpd/empty 0755 root root - \
+ ${D}${sysconfdir}/tmpfiles.d/${BPN}.conf
+fi
}
INITSCRIPT_PACKAGES = ${PN}
@@ -82,3 +86,13 @@ USERADD_PARAM_${PN} = --system --home-dir /var/lib/ftp
--no-create-home -g ftp
--shell /bin/false ftp
GROUPADD_PARAM_${PN} = -r ftp
+pkg_postinst_${PN}() {
+ if [ -n $D ]; then
+ exit 0
+ fi
+ if type systemd-tmpfiles /dev/null; then
+ systemd-tmpfiles --create
+ elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
+ ${sysconfdir}/init.d/populate-volatile.sh update
+ fi
+}
--
1.7.10.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][meta-perl][v2] libxml-libxml-perl: add recipe
Acked-by: Hongxu Jia hongxu@windriver.com
//Hongxu
On 07/15/2014 08:42 AM, rongqing...@windriver.com wrote:
From: Roy Li rongqing...@windriver.com
This module is an interface to libxml2, providing XML and HTML parsers \
with DOM, SAX and XMLReader interfaces, a large subset of DOM Layer 3 \
interface and a XML::XPath-like interface to XPath API of libxml2. \
The module is split into several packages which are not described in this \
section; unless stated otherwise, you only need to use XML::LibXML; in \
your programs.
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../libxml-libxml-perl/disable-libxml2-check.patch | 79 +
.../fix-CATALOG-conditional-compile.patch | 31 +++
.../using-DOCB-conditional.patch | 91
.../libxml/libxml-libxml-perl_2.0116.bb| 47 ++
4 files changed, 248 insertions(+)
create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl/disable-libxml2-check.patch
create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl/using-DOCB-conditional.patch
create mode 100644 meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb
diff --git
a/meta-perl/recipes-perl/libxml/libxml-libxml-perl/disable-libxml2-check.patch
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/disable-libxml2-check.patch
new file mode 100644
index 000..a8e7cc1
--- /dev/null
+++
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/disable-libxml2-check.patch
@@ -0,0 +1,79 @@
+Do not use the _libxml_check_lib() on cross-compile
+
+Upstream-Status: Inappropriate [configuration]
+
+xml2 have been added into package's DEPENDS, so not need to use the
+_libxml_check_lib() to check it again, and _libxml_check_lib() always
+return false on cross-compile environment
+
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ Makefile.PL | 52 ++--
+ 1 file changed, 26 insertions(+), 26 deletions(-)
+
+diff --git a/Makefile.PL b/Makefile.PL
+index c0485f1..09c676b 100644
+--- a/Makefile.PL
b/Makefile.PL
+@@ -411,32 +411,32 @@ sub _libxml_check_lib {
+ }
+ }
+
+-print Checking for ability to link against xml2...;
+-if ( _libxml_check_lib('xml2') ) {
+-print yes\n;
+-}
+-else {
+-print no\n;
+-print Checking for ability to link against libxml2...;
+-if ( _libxml_check_lib('libxml2')) {
+-print yes\n;
+-}
+-else {
+-print STDERR DEATH;
+-libxml2, zlib, and/or the Math library (-lm) have not been found.
+-Try setting LIBS and INC values on the command line
+-Or get libxml2 from
+- http://xmlsoft.org/
+-If you install via RPMs, make sure you also install the -devel
+-RPMs, as this is where the headers (.h files) are.
+-
+-Also, you may try to run perl Makefile.PL with the DEBUG=1 parameter
+-to see the exact reason why the detection of libxml2 installation
+-failed or why Makefile.PL was not able to compile a test program.
+-DEATH
+-exit 0; # 0 recommended by http://cpantest.grango.org (Notes for CPAN
Authors)
+-}
+-}
++#print Checking for ability to link against xml2...;
++#if ( _libxml_check_lib('xml2') ) {
++#print yes\n;
++#}
++#else {
++#print no\n;
++#print Checking for ability to link against libxml2...;
++#if ( _libxml_check_lib('libxml2')) {
++#print yes\n;
++#}
++#else {
++#print STDERR DEATH;
++#libxml2, zlib, and/or the Math library (-lm) have not been found.
++#Try setting LIBS and INC values on the command line
++#Or get libxml2 from
++# http://xmlsoft.org/
++#If you install via RPMs, make sure you also install the -devel
++#RPMs, as this is where the headers (.h files) are.
++#
++#Also, you may try to run perl Makefile.PL with the DEBUG=1 parameter
++#to see the exact reason why the detection of libxml2 installation
++#failed or why Makefile.PL was not able to compile a test program.
++#DEATH
++#exit 0; # 0 recommended by http://cpantest.grango.org (Notes for
CPAN Authors)
++#}
++#}
+
+ # -- #
+ # _NOW_ write the Makefile
+--
+1.7.10.4
+
diff --git
a/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
new file mode 100644
index 000..1dd9fb3
--- /dev/null
+++
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl/fix-CATALOG-conditional-compile.patch
@@ -0,0 +1,31 @@
+[PATCH] Fix a compile error
+
+Upstream-Status: Pending
+
+Fix a compile error by conditional using 'catal' since catal
+is only defined when LIBXML_CATALOG_ENABLED is enabled.
+
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ LibXML.xs |2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/LibXML.xs b/LibXML.xs
+index
Re: [oe] [PATCH][meta-perl] libxml-sax-writer-perl: add recipe
Acked-by: Hongxu Jia hongxu@windriver.com
//Hongxu
On 07/14/2014 02:12 PM, rongqing...@windriver.com wrote:
From: Roy Li rongqing...@windriver.com
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../libxml/libxml-sax-writer-perl_0.54.bb | 27
1 file changed, 27 insertions(+)
create mode 100644
meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
diff --git a/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
b/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
new file mode 100644
index 000..c7a24fc
--- /dev/null
+++ b/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
@@ -0,0 +1,27 @@
+SUMMARY = XML::SAX::Writer - SAX2 Writer
+DESCRIPTION = \
+XML::SAX::Writer helps to serialize SAX2 representations of XML documents to \
+strings, files, and other flat representations. It handles charset encodings, \
+XML escaping conventions, and so forth. It is still considered alpha, \
+although it has been put to limited use in settings such as XML::LibXML and \
+the AxKit XML Application Server. \
+
+SECTION = libs
+LICENSE = Artistic-1.0 | GPLv1+
+HOMEPAGE = http://search.cpan.org/dist/XML-SAX-Writer/;
+DEPENDS += libxml-filter-buffertext-perl-native
+RDEPENDS_${PN} += libxml-filter-buffertext-perl
+
+SRC_URI =
http://search.cpan.org/CPAN/authors/id/P/PE/PERIGRIN/XML-SAX-Writer-${PV}.tar.gz;
+SRC_URI[md5sum] = 383139d76418a82b9800dc4f8b568891
+SRC_URI[sha256sum] =
a1b4d959aed8f8337523c4cef4b431e56e619c795dc6f99a868548952101cf3d
+
+LIC_FILES_CHKSUM =
file://README;beginline=45;endline=46;md5=d41d8cd98f00b204e9800998ecf8427e
+
+S = ${WORKDIR}/XML-SAX-Writer-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
+
+PACKAGE_ARCH = all
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Fwd: Re: open embedded build issues with beagle board
Hi Cliff, thanks for your suggestion, i tried links which you mentioned in your mail. Now i am able to build minimal image for MACHINE = qmux6. Can you please tell us how can we make it for beagleboard omap 3530. Where can we find support layer for beagleboard. Thanks a lot in advance ! On Jul 11, 2014 11:30 AM, Bryan just4tec...@gmail.com wrote: Hi, As per your suggestion we took oe-core and other packages from followinf link: - http://git.openembedded.org/meta-openembedded We are using bitbake version 1.23.1. We have to build image for beagleboard so we find following to build image: - http://www.crashcourse.ca/wiki/index.php/Building_for_BBB_using_OpenEmbedded While following steps from the above link we have done following settings in local.conf and bblayers.conf file. MACHINE ??= beaglebone BBLAYERS ?= \ /home/rpjday/oe/dist/layers/oe-core/meta \ /home/rpjday/oe/dist/layers/meta-openembedded/meta-oe \ /home/rpjday/oe/dist/layers/meta-beagleboard/common-bsp \ Now while running bitbake core-image-minimal command we are getting following issues : chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/doc/programmer_reference/intro_what.html': Operation not permitted chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/doc/programmer_reference/program_ram.html': Operation not permitted chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/doc/programmer_reference/arch_apis.html': Operation not permitted chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/doc/programmer_reference/transapp_reclimit.html': Operation not permitted chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/doc/programmer_reference/am_close.html': Operation not permitted chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/doc/programmer_reference/lock_stdmode.html': Operation not permitted chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/doc/programmer_reference/transapp_env_open.html': Operation not permitted WARNING: /home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/temp/run.do_install.26236:1 exit 1 from chown -R root:root /home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image ERROR: Function failed: do_install (log file is located at /home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/temp/log.do_install.26236) one more doubt about the code base which we should follow as we found one other link which have oe-core code at https://github.com/openembedded;. We have tried both and found seperate issues while using both. Please suggest us how we can overcome these issues to get test image build for beagleboard. Thanks in advance -- Forwarded message -- From: Philip Balister phi...@balister.org Date: Jul 8, 2014 9:42 PM Subject: Re: [oe] open embedded build issues with beagle board To: openembedded-devel@lists.openembedded.org Cc: On 07/08/2014 02:54 AM, Bryan wrote: Hi All I am trying to build Openembeeded classic for Beagle board-XM but i am getting lot of broken link issues. I have set DISTRO as angstrom-2010.x in local.conf. Is this approach ok? or should i move to openembedded core ?? Pls suggest. Use the current Angstrom instructions, oe-classic is pretty much completely unsupported now. Philip Broken link e.g. Resolving www.angstrom-distribution.org (www.angstrom-distribution.org )... 140.211.169.177 Connecting to www.angstrom-distribution.org (www.angstrom-distribution.org)|140.211.169.177|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2014-07-08 10:13:43 ERROR 404: Not Found. Thanks in advance -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCHv2 1/2] libhugetlbfs: fix versioning
PE bump is needed because git+stuff 2.18
Signed-off-by: Koen Kooi koen.k...@linaro.org
---
meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
index 5645add..af7ed3e 100644
--- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
+++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
@@ -5,6 +5,9 @@ LIC_FILES_CHKSUM =
file://LGPL-2.1;md5=2d5025d4aa3495befef8f17206a5b0a1
DEPENDS = sysfsutils perl
RDEPENDS_${PN} += python python-io python-lang python-subprocess
python-resource
+PV = 2.18
+PE = 1
+
SRCREV = ea3f6b273f535aab38cefae30030774457bbbfe6
SRC_URI = git://git.code.sf.net/p/libhugetlbfs/code \
file://skip-checking-LIB32-and-LIB64-if-they-point-to-the-s.patch \
--
1.9.3
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCHv2 2/2] libhugetlbfs: fix packaging
Libhugetlbs doesn't generate proper .so.X libs, only two .so files. Package
those in ${PN} and silence the resulting QA warning. This fixes:
ERROR: QA Issue: libhugetlbfs-tests rdepends on libhugetlbfs-dev
Signed-off-by: Koen Kooi koen.k...@linaro.org
---
meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
index af7ed3e..f2da16a 100644
--- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
+++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
@@ -25,6 +25,7 @@ COMPATIBLE_HOST =
(x86_64|powerpc|powerpc64|aarch64).*-linux*
LIBARGS = LIB32=${baselib} LIB64=${baselib}
EXTRA_OEMAKE = 'ARCH=${TARGET_ARCH}' 'OPT=${CFLAGS}' 'CC=${CC}' ${LIBARGS}
V=1
+PARALLEL_MAKE =
CFLAGS += -fexpensive-optimizations -frename-registers -fomit-frame-pointer
-g0
TARGET_CC_ARCH += ${LDFLAGS}
@@ -46,12 +47,15 @@ do_install() {
install-tests
}
-PARALLEL_MAKE_pn-${PN} =
PACKAGES =+ ${PN}-perl ${PN}-tests
+FILES_${PN} += ${libdir}/*.so
+FILES_${PN}-dev = ${includedir}
FILES_${PN}-dbg += ${libdir}/libhugetlbfs/tests/obj32/.debug
${libdir}/libhugetlbfs/tests/obj64/.debug
FILES_${PN}-perl = ${libdir}/perl
FILES_${PN}-tests += ${libdir}/libhugetlbfs/tests
+INSANE_SKIP_${PN} = dev-so
+
INHIBIT_PACKAGE_STRIP = 1
INHIBIT_PACKAGE_DEBUG_SPLIT = 1
--
1.9.3
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] [v3] lz4: update to latest version
update to version r119
Use github instead of svn
LICENSE md5sum changed since it was updated in r117
FIxes CVE-2014-4611
Signed-off-by: Armin Kuster akus...@mvista.com
---
meta/recipes-support/lz4/{lz4_svn.bb = lz4_git.bb} | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
rename meta/recipes-support/lz4/{lz4_svn.bb = lz4_git.bb} (68%)
diff --git a/meta/recipes-support/lz4/lz4_svn.bb
b/meta/recipes-support/lz4/lz4_git.bb
similarity index 68%
rename from meta/recipes-support/lz4/lz4_svn.bb
rename to meta/recipes-support/lz4/lz4_git.bb
index 38e36d8..3978d76 100644
--- a/meta/recipes-support/lz4/lz4_svn.bb
+++ b/meta/recipes-support/lz4/lz4_git.bb
@@ -2,15 +2,12 @@ SUMMARY = Extremely Fast Compression algorithm
DESCRIPTION = LZ4 is a very fast lossless compression algorithm, providing
compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also
features an extremely fast decoder, with speed in multiple GB/s per core,
typically reaching RAM speed limits on multi-core systems.
LICENSE = BSD
-LIC_FILES_CHKSUM = file://LICENSE;md5=2008d2325e11691e17fcaa3a6046f850
+LIC_FILES_CHKSUM = file://LICENSE;md5=0b0d063f37a4477b54af2459477dcafd
-# Upstream names releases after SVN revs
-SRCREV = 112
-PV = r${SRCREV}
+SRCREV = 28fd251bc7b42e5cde15f9a2d78fc53b3b575558
+SRC_URI= git://github.com/Cyan4973/lz4.git;branch=master
-SRC_URI = svn://lz4.googlecode.com/svn/;module=trunk;protocol=http
-
-S = ${WORKDIR}/trunk
+S = ${WORKDIR}/git
EXTRA_OEMAKE = PREFIX=${prefix} CC='${CC}' DESTDIR=${D} LIBDIR=${libdir}
INCLUDEDIR=${includedir}
--
1.9.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
