[oe] [meta-oe][PATCH] lighttpd: get rid of annoying warning
* Fixes:
| lighttpd_1.4.30.bb: it is recommended to set SYSTEMD_PACKAGES as
existing-package-systemd
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
.../lighttpd/lighttpd_1.4.30.bbappend |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta-oe/recipes-extended/lighttpd/lighttpd_1.4.30.bbappend
b/meta-oe/recipes-extended/lighttpd/lighttpd_1.4.30.bbappend
index 1341405..e7f4a16 100644
--- a/meta-oe/recipes-extended/lighttpd/lighttpd_1.4.30.bbappend
+++ b/meta-oe/recipes-extended/lighttpd/lighttpd_1.4.30.bbappend
@@ -1,10 +1,10 @@
FILESEXTRAPATHS := ${THISDIR}/${PN}
-PRINC := ${@int(PRINC) + 3}
+PRINC := ${@int(PRINC) + 4}
inherit systemd
SRC_URI += file://lighttpd.service
-SYSTEMD_PACKAGES = ${PN}
-SYSTEMD_SERVICE_${PN} = lighttpd.service
+SYSTEMD_PACKAGES = ${PN}-systemd
+SYSTEMD_SERVICE_${PN}-systemd = lighttpd.service
--
1.7.9.5
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] Prefix in rpms packages
Hi Mark, All, thanks for your reply. What I need is to manually install target rpms locating them in my own directory. With no relocation available I should install them starting from / and this is not good if I need to install on host. What I need (in other words) is the possibility to set Prefix during spec file creation to have a relocation. Am I wrong? Cheers, Giuseppe 2012/5/7 Mark Hatle mark.ha...@windriver.com On 5/7/12 5:30 AM, Giuseppe Condorelli wrote: Hi All, after having built my own image, I've looked at the resultant rpms under the deploy directory and I saw no relocation is possible (rpm -qplipackage). This because Prefix is not set during spec file creation (package_rpm.bbclass). As far as you know, is it possible to set Prefix somehow? What type of packages are you trying to relocate? For target packages I don't expect that it would ever work. The items built by the build system often have internal paths and expectations. For SDK packages (i.e. things that run on the host), it might be possible to make them relocatable, but it would be specific to those style packages. (Any relocatable package has to have the inbuilt knowledge to move and change configuration files as necessary. Also you have to have the right set of packages to install into the environment and such. I don't believe we use RPM to install any native/SDK packages today.) --Mark Please let me know. Thanks, Giuseppe __**_ Openembedded-devel mailing list Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/** openembedded-develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel __**_ Openembedded-devel mailing list Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] Prefix in rpms packages
On 5/8/12 3:02 AM, Giuseppe Condorelli wrote: Hi Mark, All, thanks for your reply. What I need is to manually install target rpms locating them in my own directory. With no relocation available I should install them starting from / and this is not good if I need to install on host. What I need (in other words) is the possibility to set Prefix during spec file creation to have a relocation. Am I wrong? You should not be installing target RPMs onto your host system directly. This will contaminate your host RPM database and produce a system with invalid entries, causing programs like yum, smart or zypper to fail when attempting to update. When you install target packages into your host environment for development you should be using a chroot and with the RPM database located within that chroot. This is how the build system does it, and really is the only safe way to do the install. (If you need the update-alternatives and other pre/post-install scriptlets to run.. then this requires even more advanced knowledge..) (I'm going to assume you don't need the scriptlets to run...) As your regular non-privileged user id, you can run pseudo to enable root-like fake chroot and other privileged operations.. and then inside of the pseudo environment use the version of RPM we built: rpm --root=your install path -Uhv --noscripts --dbpath=/var/lib/rpm list of package (the above is from memory, so verify this before running it) Look at meta/classes/rootfs_rpm.bbclass and meta/classes/package_rpm.bbclass for more details of exactly how the system constructs root filesystems. --Mark Cheers, Giuseppe 2012/5/7 Mark Hatlemark.ha...@windriver.com On 5/7/12 5:30 AM, Giuseppe Condorelli wrote: Hi All, after having built my own image, I've looked at the resultant rpms under the deploy directory and I saw no relocation is possible (rpm -qplipackage). This because Prefix is not set during spec file creation (package_rpm.bbclass). As far as you know, is it possible to set Prefix somehow? What type of packages are you trying to relocate? For target packages I don't expect that it would ever work. The items built by the build system often have internal paths and expectations. For SDK packages (i.e. things that run on the host), it might be possible to make them relocatable, but it would be specific to those style packages. (Any relocatable package has to have the inbuilt knowledge to move and change configuration files as necessary. Also you have to have the right set of packages to install into the environment and such. I don't believe we use RPM to install any native/SDK packages today.) --Mark Please let me know. Thanks, Giuseppe __**_ Openembedded-devel mailing list Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/** openembedded-develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel __**_ Openembedded-devel mailing list Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] Prefix in rpms packages
Many many thanks for clarification, Mark! 2012/5/8 Mark Hatle mark.ha...@windriver.com On 5/8/12 3:02 AM, Giuseppe Condorelli wrote: Hi Mark, All, thanks for your reply. What I need is to manually install target rpms locating them in my own directory. With no relocation available I should install them starting from / and this is not good if I need to install on host. What I need (in other words) is the possibility to set Prefix during spec file creation to have a relocation. Am I wrong? You should not be installing target RPMs onto your host system directly. This will contaminate your host RPM database and produce a system with invalid entries, causing programs like yum, smart or zypper to fail when attempting to update. When you install target packages into your host environment for development you should be using a chroot and with the RPM database located within that chroot. This is how the build system does it, and really is the only safe way to do the install. (If you need the update-alternatives and other pre/post-install scriptlets to run.. then this requires even more advanced knowledge..) (I'm going to assume you don't need the scriptlets to run...) As your regular non-privileged user id, you can run pseudo to enable root-like fake chroot and other privileged operations.. and then inside of the pseudo environment use the version of RPM we built: rpm --root=your install path -Uhv --noscripts --dbpath=/var/lib/rpm list of package (the above is from memory, so verify this before running it) Look at meta/classes/rootfs_rpm.**bbclass and meta/classes/package_rpm.**bbclass for more details of exactly how the system constructs root filesystems. --Mark Cheers, Giuseppe 2012/5/7 Mark Hatlemark.ha...@windriver.com** On 5/7/12 5:30 AM, Giuseppe Condorelli wrote: Hi All, after having built my own image, I've looked at the resultant rpms under the deploy directory and I saw no relocation is possible (rpm -qplipackage). This because Prefix is not set during spec file creation (package_rpm.bbclass). As far as you know, is it possible to set Prefix somehow? What type of packages are you trying to relocate? For target packages I don't expect that it would ever work. The items built by the build system often have internal paths and expectations. For SDK packages (i.e. things that run on the host), it might be possible to make them relocatable, but it would be specific to those style packages. (Any relocatable package has to have the inbuilt knowledge to move and change configuration files as necessary. Also you have to have the right set of packages to install into the environment and such. I don't believe we use RPM to install any native/SDK packages today.) --Mark Please let me know. Thanks, Giuseppe ___ Openembedded-devel mailing list Openembedded-devel@lists.**ope**nembedded.org http://openembedded.org Openembedded-**de...@lists.openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/**http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/** openembedded-develhttp://**lists.linuxtogo.org/cgi-bin/** mailman/listinfo/openembedded-**develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.**ope**nembedded.org http://openembedded.org Openembedded-**de...@lists.openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/ openembedded-develhttp://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-devel http://**lists.linuxtogo.org/cgi-bin/**mailman/listinfo/openembedded-** develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel __**_ Openembedded-devel mailing list Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/** openembedded-develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel __**_ Openembedded-devel mailing list Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [oe-core] How to produce toolchain sdk
Hi All, as you have understood from my previous requests, I'm a newbe of OE-Core and I'm wondering which is the better way to build a toolchain sdk. I'm understanding it's different respect the classic openembedded tree (where I was able to build it). Please can you help me? Thanks, Giuseppe ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] How to produce toolchain sdk
Hi Giuseppe, Le Tue, 8 May 2012 16:41:12 +0200, Giuseppe Condorelli giuseppe.condore...@gmail.com a écrit : as you have understood from my previous requests, I'm a newbe of OE-Core and I'm wondering which is the better way to build a toolchain sdk. I'm understanding it's different respect the classic openembedded tree (where I was able to build it). Please can you help me? you can try : bitbake meta-toolchain or for qt embedded : bitbake meta-toolchain-qte Eric ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Linuxtag 2012
On Tue, May 08, 2012 at 12:23:42AM +0200, Florian Boor wrote: Hallo list! We have been accepted for a project booth at LinuxTag [1] again this year! This means that we have a booth at the largest Linux fair in Europe and the opportunity to get in touch with users, companies and other projects there. LinuxTag takes place in Berlin, Germany from May 23 to 26. We need several people who want to help manning the booth. The years before was able to attend myself but this year I still do not know if I'll be able to do so. So if you are able to attend please take this chance to represent OE at LinuxTag! We have a big box with useful things for the booth (TFT, table cloth with OE logo, lamps, flyers...). This box will be available at the event location. Something useful to bring yourself are all sorts of devices OE supports. Greetings Florian Fine, I can help out one day at least. Bye Henning ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] openssh: rename bbappends to match new oe-core version
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
...enssh_5.9p1.bbappend = openssh_6.0p1.bbappend} |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
rename meta-oe/recipes-connectivity/openssh/{openssh_5.9p1.bbappend =
openssh_6.0p1.bbappend} (88%)
diff --git a/meta-oe/recipes-connectivity/openssh/openssh_5.9p1.bbappend
b/meta-oe/recipes-connectivity/openssh/openssh_6.0p1.bbappend
similarity index 88%
rename from meta-oe/recipes-connectivity/openssh/openssh_5.9p1.bbappend
rename to meta-oe/recipes-connectivity/openssh/openssh_6.0p1.bbappend
index de7668f..a459065 100644
--- a/meta-oe/recipes-connectivity/openssh/openssh_5.9p1.bbappend
+++ b/meta-oe/recipes-connectivity/openssh/openssh_6.0p1.bbappend
@@ -1,6 +1,6 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-PRINC := ${@int(PRINC) + 2}
+PRINC := ${@int(PRINC) + 1}
SYSTEMD_PACKAGES = openssh-sshd-systemd
SYSTEMD_SERVICE = sshd.socket
--
1.7.8.6
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Disable GNU Hash check ?
On 2012-03-06 11:08, Hauser, Wolfgang (external) wrote:
Thanks for that hint, but it is
INSANE_SKIP_${PN} = True
INSANE_SKIP_${PN}-dev = True
INSANE_SKIP_${PN}-dbg = True
That solves the problem.
Regards
Wolfgang
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Had this problem with a source package containing both a kernel driver
and applications.
The GNU Hash problem occured on the applications but not on the kernel
modules.
The way it works, is that you create a configuration file, and then call
make without parameters
so you build both the kernel and the apps in one step.
Added TARGET_CC_ARCH+=${LDFLAGS}, as recommended in some
mails, without effect.
Adding
INSANE_SKIP_${PN} = True
INSANE_SKIP_${PN}-dev = True
INSANE_SKIP_${PN}-dbg = True
makes the symptom go away.
The core of the recipe is:
--
inherit module
EXTRA_OEMAKE = ' \
KLIB=${STAGING_KERNEL_DIR} \
KLIB_BUILD=${STAGING_KERNEL_DIR} \
KERNEL_VERSION=${KERNEL_VERSION} \
TARGET_CC_ARCH+=${LDFLAGS} \
'
do_compile () {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS CC LD CPP
oe_runmake
}
---
While the kernel modules seems to build OK,
I have a feeling that it is not right to build the applications this way
and this is why I get the error messages.
I'd rather fix the root cause than do the workaround,
but splitting up the build into two steps is really not supported by the
package.
Would appreciate some comments.
--
Best Regards
Ulf Samuelsson
u...@emagii.com
+46 722 427437
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Simultaneous build of two intree packages
On 2012-05-07 14:33, Radek Dostal wrote: On Mon, 2012-05-07 at 06:02 -0600, Gary Thomas wrote: On 2012-05-07 05:54, Radek Dostal wrote: Dear All, I have three intree recipes A, B and C which are part of the same layer. = B depends on A = C depends on A. There is no dependency between B and C. Only important thing is that B and C are not build simultaneously. This is not a problem unless I use configure BB_NUMBER_THREADS 1. Than builds B and C starts to collide and produce mess because they are both intree builds. What are you doing that makes these clash? usually it crashes during ln -sf target dest which is executed simultaneously with same parameters for both builds. There are other issues as well in addition to this ln issue. Is there something like a mutex/lock mechanism in openembedded-core, which would forbid two recipes to be build simultaneously? Just make C depend on B I have already considered this, but unfortunately I also have configurations where only B is included or where only C is included :( Thanks, Radek ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel Fixing the packages, is probably the way to go. You could also create pseudo package D which is available in several versions. Package D-1.0c: Package D is depending on nothing Package D-1.0bc:Package D is depending on B Package C is always dependent on Package D and A. Package B is always dependent on Package A If you set PREFERRED_VERSION_D = 1.0c C is depending on D, which is depending on nothing, and C is depending on A. No problem, A and C is built. If you set PREFERRED_VERSION_D = 1.0c C is depending on D, which is depending on B. B and C is depending on A. A is built, then B is built, and then D finalizing with C. If you only want B, don't include C in the image. Not tested, but it looks like it would work. -- Best Regards Ulf Samuelsson u...@emagii.com +46 722 427437 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Simultaneous build of two intree packages
Not sure if it applies, but if all build dirs share the same configuration step, you could create a single recipe and split the results into more packages. On Mon, 2012-05-07 at 23:23 +0200, Radek Dostal wrote: On Mon, 2012-05-07 at 15:08 -0600, Gary Thomas wrote: I think that your recipes are not well behaved - two recipes probably should not be creating the same file in such a way. Can you post the recipes, or at least the code snippets that break? I agree usually it should not be a case, but since both of the recipes are in-tree recipes within the same tree, than obviously tree is the shared resource. Pasting the recipes would probably not be very helpful. Only thing they do is that they call the cmake bellow and actual error occurs within cmake scripts. Just in order to give overview: First whole structure is configured. Configuration is shared between all the recipes. Second actual make is called on different subdirectories. Cmake in its nature is not designed to be able to started multiple time over same tread (with exception of starting it via -jX). Thanks, Radek ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Disable GNU Hash check ?
On Tue, May 8, 2012 at 2:08 PM, Ulf Samuelsson openembed...@emagii.com wrote: I'd rather fix the root cause than do the workaround, but splitting up the build into two steps is really not supported by the package. Would appreciate some comments. in OE-Core the default hash style is now gnu hash for toolchain on all except mips since mips can not support gnu hash. you should not need to add commandline parameters to indicate it. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe/denzil][PATCH 3/6] media-ctl: update to latest git
Hi Koen,
On Wed, May 2, 2012 at 5:45 PM, Koen Kooi k...@dominion.thruhere.net wrote:
* split out libs
* media-ctl has been relicensed to LGPLv2.1+
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta-oe/recipes-multimedia/v4l2apps/media-ctl_git.bb | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/meta-oe/recipes-multimedia/v4l2apps/media-ctl_git.bb
b/meta-oe/recipes-multimedia/v4l2apps/media-ctl_git.bb
index 99ec8e2..76d811b 100644
--- a/meta-oe/recipes-multimedia/v4l2apps/media-ctl_git.bb
+++ b/meta-oe/recipes-multimedia/v4l2apps/media-ctl_git.bb
@@ -1,16 +1,20 @@
DESCRIPTION = Media controller control application
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe
+LICENSE = LGPLv2+
+LIC_FILES_CHKSUM = file://COPYING.LIB;md5=d749e86a105281d7a44c2328acebc4b0
SRC_URI = git://git.ideasonboard.org/media-ctl.git;protocol=git
-SRCREV = a183835abdefb8e40650fc9eb22e2d291aac9883
+SRCREV = 46bec667b675573cf1ce698c68112e3dbd31930e
PV = 0.0.1
+PR = r1
S = ${WORKDIR}/git
inherit autotools
-# It needs some kernel definitions for v4l2, so it isn't machine specific
+# It needs some kernel definitions only for v4l2, so it isn't machine
specific
EXTRA_OECONF = --with-kernel-headers=${STAGING_KERNEL_DIR}
+PACKAGES =+ libmediactl libv4l2subdev
+FILES_libmediactl = ${libdir}/libmediactl${SOLIBS}
+FILES_libv4l2subdev = ${libdir}/libv4l2subdev${SOLIBS}
--
1.7.10
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
I tried using this new recipe on OE-classic and bitbake v1.12 but the
do_configure failed.
A look into the configure.log shows
..
checking linux/media.h usability ... no
checking linux/media.h presence ... no
checking for linux/media.h ... no
ERROR: Kernel header file not found or not usable!
...
This is due to ${STAGING_KERNEL_DIR} pointing to an invalid location.
It's pointing to /sysroots/armv7a-angstrom-linux-gnueabi/kernel
instead it is located in /sysroots/${MACHINE}-angstrom-linux-gnueabi/kernel
Change you please relook into this?
Thank you.
--
Regards,
James Ang
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
