Re: [OE-core] [PATCH 0/1] [denzil] linux-yocto: make validate_branches handle non BSP branches
On 12-08-22 1:27 AM, Tom Zanussi wrote: On Mon, 2012-08-13 at 13:10 -0400, Bruce Ashfield wrote: Scott, Here's a fix for validate_branches that comes from a pending master change that I've been running for 3 weeks, and one that TomZ has tested in his yocto BSP work on denzil. It fixes some BSP use cases that involve setting a specific SRCREV on a base branch, so that a BSP branch that doesn't yet exist can be created off of that known base. Previously only an existing BSP branch could have it's SRCREV restricted. Hi Scott, I don't see this in denzil - do you have it queued for the next pull request, or did it get missed? I was wondering the same thing, in particular, since I just made a minor tweak to this in master (which I'll send out tomorrow). The attached patch should also be merged to denzil. Bruce Tom cc: Tom Zanussi Cheers, Bruce The following changes since commit 73cdebf60df225ee10f2eb215935be3b61e1b831: documentation/dev-manual/dev-manual-kernel-appendix.xml: Add note about conflict (2012-06-29 15:54:26 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel-denzil http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-denzil Bruce Ashfield (1): linux-yocto: allow do_validate_branches to handle all branches meta/classes/kernel-yocto.bbclass | 119 + 1 files changed, 80 insertions(+), 39 deletions(-) 0001-kernel-yocto-set-master-branch-to-a-defined-SRCREV.patch Description: application/mbox ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [discussion] perf: specify SLANG_INC dir for perf
On 12-08-21 11:01 PM, Liang Li wrote:
On 2012-08-21 21:07, Bruce Ashfield wrote:
On 12-08-21 01:08 AM, Liang Li wrote:
On 2012-08-20 22:48, Bruce Ashfield wrote:
On 12-08-17 09:05 AM, Liang Li wrote:
On 2012-08-17 21:01, Liang Liwrote:
On 2012-08-17 18:53, Richard Purdie
wrote:
On Fri, 2012-08-17 at 18:00 +0800, Liang Li wrote:
I am totally confused, you mentioned 'general kernel do_install', I
assume it's oe-core kernel.bbclass concept. Then you mentioned 'get
the fix upstream in the mainline kernel', how could that happen?
We are discussing about the solution to 'fix the compile warning to
error' stuff that triggered by the '-I/usr/include/slang', right?
Yes.
We do not necessarily have to change recipe to fix it since the issue
is not introduced by the recipe, the hard coded '-I/usr/include/slang'
in the Makefile cause the issue, we can fix the root cause by kernel
patch(other than just comment the line out). I see your previous patch
to kernel, by comment out the '-I/usr/include/slang' line in the
Makefile, is the same behavior, but we won't have the change(comment
out -I.. in Makefile) upstream to mainline, right?
I am suggesting that firstly, someone send a patch to the mainline
kernel which changes -I/usr/include/slang to -I=/usr/include/slang in
that Makefile.
Secondly, I'm suggesting that we add a line to kernel_do_install() in
kernel.bbclass which does a sed on the Makefile as installed into
$kerneldir which changes -I/usr/include/slang to -I=/usr/include/slang.
We can then drop the patch I added to the linux-yocto kernels.
This is all that should be needed, it should fix all the issues people
have reported in a way that is acceptable to everyone.
Ah, I see what you mean now. But we have push acceptable kernel patch
One final (I hope) follow up on this.
Liang: were you going to put together (and test) the 'sed fix' for
kernel.bbclass ?
No problem, the patch for kernel.bbclass:
commit 60a0b06
Author: Liang Li
Date: Tue Aug 21 11:06:01 2012 +0800
kernel.bbclass: fix INC directory for SLANG
The change is intend to fix the hardcoded '-I/usr/include/slang' in
the Makefile to be able to aware of SYSROOT if its specified.
A planned kernel patch almost did the same change, but the change here
won't conflict with it so this change could work for all kernels.
Signed-off-by: Liang Li
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 1afb9ab..282194d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -190,6 +190,9 @@ kernel_do_install() {
for entry in $bin_files; do
rm -f $kerneldir/$entry
done
+
+ # Fix SLNAG_INC for slang.h
s/SLNAG_INC/SLANG_INC/
+ sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g'
$kerneldir/tools/perf/Makefile
It looks like your baseline for this patch is the denzil branch. We'd
want a version for master, which we could backport as required.
Yes, the change for the master branch is almost the same, except line
number context:
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f34e632..fdef1be 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -204,6 +204,9 @@ kernel_do_install() {
for entry in $bin_files; do
rm -f $kerneldir/$entry
done
+
+ # Fix SLANG_INC for slang.h
+ sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g'
$kerneldir/tools/perf/Makefile
}
sysroot_stage_all_append() {
---
}
PACKAGE_PREPROCESS_FUNCS += "kernel_package_preprocess"
---
The patch for kernel tree:
commit 6b72896
Author: Liang Li
Date: Wed Aug 1 14:31:24 2012 +0800
perf: add SLANG_INC for slang.h
Previously we hard code '-I/usr/include/slang' to CFLAGS to works with
some hosts that has /usr/include/slang/slang.h other than
/usr/include/slang.h like Fedora. This will cause compiling warnings
in some cases.
I'd rephrase this slightly as:
CFLAGS was previously hard coded to contain "-I/usr/include/slang" to
work with hosts that have "/usr/include/slang/slang.h" as well as hosts
that have "/usr/include/slang.h". This path can cause compile warnings
in some cases:
.. and indicate that these warnings can actually cause build errors if
WERROR is enabled.
We could downgrade the priority of the default hard coded path, and
provide user a chance to specify correct location of slang.h then user
could specify SLANG_INC to avoid compile warnings like the
'/usr/include/slang' is not exists etc.
Another minor rephrase:
To fix this issue, we can use -idirafter to downgrade the priority of the
default hard coded path. We can also make the slang include directory
a variable, to allow the user to specify SLANG_INC and set their own
include location.
No problem, rephrased commit message:
Subject: [PATCH] perf: add SLANG_INC for slang.h
CFLA
Re: [OE-core] [PATCH 0/1] [denzil] linux-yocto: make validate_branches handle non BSP branches
On Mon, 2012-08-13 at 13:10 -0400, Bruce Ashfield wrote: > Scott, > > Here's a fix for validate_branches that comes from a pending master > change that I've been running for 3 weeks, and one that TomZ has tested > in his yocto BSP work on denzil. > > It fixes some BSP use cases that involve setting a specific SRCREV > on a base branch, so that a BSP branch that doesn't yet exist can > be created off of that known base. Previously only an existing BSP > branch could have it's SRCREV restricted. > Hi Scott, I don't see this in denzil - do you have it queued for the next pull request, or did it get missed? Tom > cc: Tom Zanussi > > Cheers, > > Bruce > > The following changes since commit 73cdebf60df225ee10f2eb215935be3b61e1b831: > > documentation/dev-manual/dev-manual-kernel-appendix.xml: Add note about > conflict (2012-06-29 15:54:26 +0100) > > are available in the git repository at: > git://git.pokylinux.org/poky-contrib zedd/kernel-denzil > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-denzil > > Bruce Ashfield (1): > linux-yocto: allow do_validate_branches to handle all branches > > meta/classes/kernel-yocto.bbclass | 119 > + > 1 files changed, 80 insertions(+), 39 deletions(-) > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [discussion] perf: specify SLANG_INC dir for perf
On 2012-08-21 21:07, Bruce Ashfield wrote:
> On 12-08-21 01:08 AM, Liang Li wrote:
> > On 2012-08-20 22:48, Bruce Ashfield wrote:
> >> On 12-08-17 09:05 AM, Liang Li wrote:
> >>> On 2012-08-17 21:01, Liang Li wrote:
> On 2012-08-17 18:53, Richard Purdie
> wrote:
> > On Fri, 2012-08-17 at 18:00 +0800, Liang Li wrote:
> >> I am totally confused, you mentioned 'general kernel do_install', I
> >> assume it's oe-core kernel.bbclass concept. Then you mentioned 'get
> >> the fix upstream in the mainline kernel', how could that happen?
> >>
> >> We are discussing about the solution to 'fix the compile warning to
> >> error' stuff that triggered by the '-I/usr/include/slang', right?
> >
> > Yes.
> >
> >>We do not necessarily have to change recipe to fix it since the
> >> issue
> >> is not introduced by the recipe, the hard coded '-I/usr/include/slang'
> >> in the Makefile cause the issue, we can fix the root cause by kernel
> >> patch(other than just comment the line out). I see your previous patch
> >> to kernel, by comment out the '-I/usr/include/slang' line in the
> >> Makefile, is the same behavior, but we won't have the change(comment
> >> out -I.. in Makefile) upstream to mainline, right?
> >
> > I am suggesting that firstly, someone send a patch to the mainline
> > kernel which changes -I/usr/include/slang to -I=/usr/include/slang in
> > that Makefile.
> >
> > Secondly, I'm suggesting that we add a line to kernel_do_install() in
> > kernel.bbclass which does a sed on the Makefile as installed into
> > $kerneldir which changes -I/usr/include/slang to -I=/usr/include/slang.
> >
> > We can then drop the patch I added to the linux-yocto kernels.
> >
> > This is all that should be needed, it should fix all the issues people
> > have reported in a way that is acceptable to everyone.
> >
>
> Ah, I see what you mean now. But we have push acceptable kernel patch
> >>>
> >>
> >> One final (I hope) follow up on this.
> >>
> >> Liang: were you going to put together (and test) the 'sed fix' for
> >> kernel.bbclass ?
> >>
> >
> > No problem, the patch for kernel.bbclass:
> >
> > commit 60a0b06
> > Author: Liang Li
> > Date: Tue Aug 21 11:06:01 2012 +0800
> >
> > kernel.bbclass: fix INC directory for SLANG
> >
> > The change is intend to fix the hardcoded '-I/usr/include/slang' in
> > the Makefile to be able to aware of SYSROOT if its specified.
> >
> > A planned kernel patch almost did the same change, but the change here
> > won't conflict with it so this change could work for all kernels.
> >
> > Signed-off-by: Liang Li
> >
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index 1afb9ab..282194d 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -190,6 +190,9 @@ kernel_do_install() {
> > for entry in $bin_files; do
> > rm -f $kerneldir/$entry
> > done
> > +
> > + # Fix SLNAG_INC for slang.h
>
> s/SLNAG_INC/SLANG_INC/
>
> > + sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g'
> > $kerneldir/tools/perf/Makefile
>
> It looks like your baseline for this patch is the denzil branch. We'd
> want a version for master, which we could backport as required.
>
Yes, the change for the master branch is almost the same, except line
number context:
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f34e632..fdef1be 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -204,6 +204,9 @@ kernel_do_install() {
for entry in $bin_files; do
rm -f $kerneldir/$entry
done
+
+ # Fix SLANG_INC for slang.h
+ sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g'
$kerneldir/tools/perf/Makefile
}
sysroot_stage_all_append() {
---
> > }
> >
> > PACKAGE_PREPROCESS_FUNCS += "kernel_package_preprocess"
> >
> > ---
> >
> > The patch for kernel tree:
> >
> > commit 6b72896
> > Author: Liang Li
> > Date: Wed Aug 1 14:31:24 2012 +0800
> >
> > perf: add SLANG_INC for slang.h
> >
> > Previously we hard code '-I/usr/include/slang' to CFLAGS to works with
> > some hosts that has /usr/include/slang/slang.h other than
> > /usr/include/slang.h like Fedora. This will cause compiling warnings
> > in some cases.
>
> I'd rephrase this slightly as:
>
> CFLAGS was previously hard coded to contain "-I/usr/include/slang" to
> work with hosts that have "/usr/include/slang/slang.h" as well as hosts
> that have "/usr/include/slang.h". This path can cause compile warnings
> in some cases:
>
>
>
> .. and indicate that these warnings can actually cause build errors if
> WERROR is enabled.
>
> >
> > We could downgrade the priority of the default hard coded path, and
> > provide user a chance to specify correct location of slang.h then user
>
Re: [OE-core] qemu gl changes are broken.
On Tuesday 21 August 2012 16:46:31 Scott Garman wrote: > On 08/21/2012 10:45 AM, Scott Garman wrote: > > On 08/21/2012 09:21 AM, Scott Garman wrote: > >> Hello, > >> > >> I tried building some images overnight with the latest master, and could > >> not get them to run this morning with qemu - I got an odd error that a > >> VNC server was started instead? > >> > >> Just on a hunch, I reverted the following commits: > >> > >> qemu: Fix broken accidental path move > >> qemu-git: Drop GL passthrough support > >> qemu-0.15: Drop GL passthrough support > >> > >> rebuilt qemu-native, and now qemu works correctly. > >> > >> I have no idea why qemu is trying to fallback on a VNC server, as I did > >> not have one running on my machine. I know we use VNC for our > >> autobuilder sanity tests, but those haven't been integrated into the > >> runqemu scripts as far as I can tell. > > > > This may need further research, I seem to have it working on another > > machine. I'll report back once I've learned more. > > Ok, I can no longer reproduce this issue anymore, even on the original > machine. Figures. :-/ Is this perhaps what happens when DISPLAY is not set? Just a guess... Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] Replacing chrpath with patchelf
On Sat, Aug 18, 2012 at 6:27 PM, Phil Blundell wrote:
> On Sat, 2012-08-18 at 10:15 -0700, Khem Raj wrote:
>> so I figured. which now means you need to have patchelf on build host
>> preinstalled instead of chrpath.
>
> That'd be a bit of a pain, since (afaict) patchelf is not so widely
> available in host distributions as chrpath.
>
>> you never know. It just lifts this limitation. We ship
>> chrpath-nativesdk as well and people can use it in different ways
>
> I agree that removing the weird and arbitrary-seeming (from the user
> perspective) restriction on rpath length would be a good thing. But
> it's less clear that swapping a weird restriction that few people will
> ever run into for a requirement to pre-install a relatively obscure host
> binary on all systems is a good tradeoff.
patchelf does have packages for all familiar linux distros but its not in
their default feeds. May be it will be nicer to create one meta
package which installs
all prerequisites not only chrpath/patchelf and maintain that ourselves
this could be nicer since then user only installs
apt-get install make-my-host-compile-oe package on ubuntu and similar
for others.
>
> How about writing a python function, or a trivial standalone program
> (which can be compiled -native without requiring anything other than
> ${BUILD_CC}) to preprocess the binaries before chrpath sees them, or
> indeed just to replace chrpath altogether? Or, as an alternative, how
> about fixing chrpath to suck less and then just waiting for the improved
> version to trickle down into deployed host distributions?
>
> p.
>
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemu gl changes are broken.
On 08/21/2012 10:45 AM, Scott Garman wrote: On 08/21/2012 09:21 AM, Scott Garman wrote: Hello, I tried building some images overnight with the latest master, and could not get them to run this morning with qemu - I got an odd error that a VNC server was started instead? Just on a hunch, I reverted the following commits: qemu: Fix broken accidental path move qemu-git: Drop GL passthrough support qemu-0.15: Drop GL passthrough support rebuilt qemu-native, and now qemu works correctly. I have no idea why qemu is trying to fallback on a VNC server, as I did not have one running on my machine. I know we use VNC for our autobuilder sanity tests, but those haven't been integrated into the runqemu scripts as far as I can tell. This may need further research, I seem to have it working on another machine. I'll report back once I've learned more. Ok, I can no longer reproduce this issue anymore, even on the original machine. Figures. :-/ Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 4/5] u-boot-mkimage: Update to v2012.07
Signed-off-by: Tom Rini
---
.../u-boot/u-boot-mkimage_2012.04.01.bb| 35
meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb | 33 ++
2 files changed, 33 insertions(+), 35 deletions(-)
delete mode 100644 meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
create mode 100644 meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
deleted file mode 100644
index c41a2f1..000
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
+++ /dev/null
@@ -1,35 +0,0 @@
-DESCRIPTION = "U-boot bootloader mkimage tool"
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb"
-SECTION = "bootloader"
-
-PR = "r1"
-
-# This is needs to be validated among supported BSP's before we can
-# make it default
-DEFAULT_PREFERENCE = "-1"
-
-# This revision corresponds to the tag "v2012.04.01"
-# We use the revision in order to avoid having to fetch it from the
-# repo during parse
-SRCREV = "415d386877df49eb051b85ef74fa59a16dc17c7d"
-
-PV = "v2012.04.01+git${SRCPV}"
-
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
-
-S = "${WORKDIR}/git"
-
-EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
-
-do_compile () {
- oe_runmake tools
-}
-
-do_install () {
- install -d ${D}${bindir}
- install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage
- ln -sf uboot-mkimage ${D}${bindir}/mkimage
-}
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
new file mode 100644
index 000..0ba4c03
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
@@ -0,0 +1,33 @@
+DESCRIPTION = "U-boot bootloader mkimage tool"
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb"
+SECTION = "bootloader"
+
+# This is needs to be validated among supported BSP's before we can
+# make it default
+DEFAULT_PREFERENCE = "-1"
+
+# This revision corresponds to the tag "v2012.07"
+# We use the revision in order to avoid having to fetch it from the
+# repo during parse
+SRCREV = "190649fb4309d1bc0fe7732fd0f951cb6440f935"
+
+PV = "v2012.07+git${SRCPV}"
+
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
+
+S = "${WORKDIR}/git"
+
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
+
+do_compile () {
+ oe_runmake tools
+}
+
+do_install () {
+ install -d ${D}${bindir}
+ install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage
+ ln -sf uboot-mkimage ${D}${bindir}/mkimage
+}
+
+BBCLASSEXTEND = "native nativesdk"
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 3/5] u-boot-fw-utils: Update to v2012.07
Signed-off-by: Tom Rini
---
.../u-boot/u-boot-fw-utils_2012.04.01.bb | 35
meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb | 33 ++
2 files changed, 33 insertions(+), 35 deletions(-)
delete mode 100644 meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
create mode 100644 meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
deleted file mode 100644
index d217320..000
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
+++ /dev/null
@@ -1,35 +0,0 @@
-DESCRIPTION = "U-boot bootloader fw_printenv/setenv utils"
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb"
-SECTION = "bootloader"
-
-DEPENDS = "mtd-utils"
-
-PR = "r1"
-
-# This is needs to be validated among supported BSP's before we can
-# make it default
-DEFAULT_PREFERENCE = "-1"
-
-# This revision corresponds to the tag "v2012.04.01"
-# We use the revision in order to avoid having to fetch it from the
-# repo during parse
-SRCREV = "415d386877df49eb051b85ef74fa59a16dc17c7d"
-
-PV = "v2012.04.01+git${SRCPV}"
-
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
-
-S = "${WORKDIR}/git"
-
-EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
-
-do_compile () {
- oe_runmake env
-}
-
-do_install () {
- install -d ${D}${base_sbindir}
- install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_printenv
- install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_setenv
-}
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
new file mode 100644
index 000..565beb7
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
@@ -0,0 +1,33 @@
+DESCRIPTION = "U-boot bootloader fw_printenv/setenv utils"
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb"
+SECTION = "bootloader"
+
+DEPENDS = "mtd-utils"
+
+# This is needs to be validated among supported BSP's before we can
+# make it default
+DEFAULT_PREFERENCE = "-1"
+
+# This revision corresponds to the tag "v2012.07"
+# We use the revision in order to avoid having to fetch it from the
+# repo during parse
+SRCREV = "190649fb4309d1bc0fe7732fd0f951cb6440f935"
+
+PV = "v2012.07+git${SRCPV}"
+
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
+
+S = "${WORKDIR}/git"
+
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
+
+do_compile () {
+ oe_runmake env
+}
+
+do_install () {
+ install -d ${D}${base_sbindir}
+ install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_printenv
+ install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_setenv
+}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 5/5] u-boot: Update to v2012.07
Signed-off-by: Tom Rini
---
meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb | 29 --
meta/recipes-bsp/u-boot/u-boot_2012.07.bb| 29 ++
2 files changed, 29 insertions(+), 29 deletions(-)
delete mode 100644 meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb
create mode 100644 meta/recipes-bsp/u-boot/u-boot_2012.07.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb
b/meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb
deleted file mode 100644
index c4ec50d..000
--- a/meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb
+++ /dev/null
@@ -1,29 +0,0 @@
-require u-boot.inc
-
-# This is needs to be validated among supported BSP's before we can
-# make it default
-DEFAULT_PREFERENCE = "-1"
-
-# To build u-boot for your machine, provide the following lines in
-# your machine config, replacing the assignments as appropriate for
-# your machine.
-# UBOOT_MACHINE = "omap3_beagle_config"
-# UBOOT_ENTRYPOINT = "0x80008000"
-# UBOOT_LOADADDRESS = "0x80008000"
-
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb"
-
-# This revision corresponds to the tag "v2012.04.01"
-# We use the revision in order to avoid having to fetch it from the
-# repo during parse
-SRCREV = "415d386877df49eb051b85ef74fa59a16dc17c7d"
-
-PV = "v2012.04.01+git${SRCPV}"
-PR = "r1"
-
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
-
-S = "${WORKDIR}/git"
-
-PACKAGE_ARCH = "${MACHINE_ARCH}"
diff --git a/meta/recipes-bsp/u-boot/u-boot_2012.07.bb
b/meta/recipes-bsp/u-boot/u-boot_2012.07.bb
new file mode 100644
index 000..91f32e6
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/u-boot_2012.07.bb
@@ -0,0 +1,29 @@
+require u-boot.inc
+
+# This is needs to be validated among supported BSP's before we can
+# make it default
+DEFAULT_PREFERENCE = "-1"
+
+# To build u-boot for your machine, provide the following lines in
+# your machine config, replacing the assignments as appropriate for
+# your machine.
+# UBOOT_MACHINE = "omap3_beagle_config"
+# UBOOT_ENTRYPOINT = "0x80008000"
+# UBOOT_LOADADDRESS = "0x80008000"
+
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb"
+
+# This revision corresponds to the tag "v2012.07"
+# We use the revision in order to avoid having to fetch it from the
+# repo during parse
+SRCREV = "190649fb4309d1bc0fe7732fd0f951cb6440f935"
+
+PV = "v2012.07+git${SRCPV}"
+PR = "r1"
+
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
+
+S = "${WORKDIR}/git"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/5] u-boot-fw-utils: Correct EXTRA_OEMAKE
- HOSTCFLAGS / HOSTLDFLAGS have been valid for a long time for tools/env
- HOSTSTRIP will be needed in the future, does no harm to be correct
now.
Signed-off-by: Tom Rini
---
meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb |4 ++--
.../u-boot/u-boot-fw-utils_2012.04.01.bb |4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb
index 7c4df1a..ae20042 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb
@@ -6,7 +6,7 @@ SECTION = "bootloader"
DEPENDS = "mtd-utils"
-PR = "r1"
+PR = "r2"
SRC_URI = "ftp://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2";
@@ -15,7 +15,7 @@ SRC_URI[sha256sum] =
"362ddb935885da98cf461eba08f31e3e59d0c4ada6cb2fa15596f43af3
S = "${WORKDIR}/u-boot-${PV}"
-EXTRA_OEMAKE = 'HOSTCC="${CC}"'
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
do_compile () {
oe_runmake env
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
index fe3422a..d217320 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
@@ -5,6 +5,8 @@ SECTION = "bootloader"
DEPENDS = "mtd-utils"
+PR = "r1"
+
# This is needs to be validated among supported BSP's before we can
# make it default
DEFAULT_PREFERENCE = "-1"
@@ -20,7 +22,7 @@ SRC_URI =
"git://git.denx.de/u-boot.git;branch=master;protocol=git"
S = "${WORKDIR}/git"
-EXTRA_OEMAKE = 'HOSTCC="${CC}"'
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
do_compile () {
oe_runmake env
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/5] u-boot-mkimage: Correct EXTRA_OEMAKE
- HOSTLD has never been used in U-Boot, drop.
- HOSTSTRIP has been valid for a long time for tools
- Same for HOSTCFLAGS / HOSTLDFLAGS
Signed-off-by: Tom Rini
---
meta/recipes-bsp/u-boot/u-boot-mkimage_2011.03.bb |4 ++--
meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb |4 ++--
.../u-boot/u-boot-mkimage_2012.04.01.bb|4 +++-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.03.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.03.bb
index 34bae8e..fdbe7c9 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.03.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.03.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=1707d6db1d42237583f50183a5651ecb \
file://README;beginline=1;endline=22;md5=3a00ef51d3fc96e9d6c1bc4708ccd3b5"
SECTION = "bootloader"
-PR = "r1"
+PR = "r2"
SRC_URI = "ftp://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2 \
file://0001-Drop-config.h-include-in-tools-imximage.h.patch \
@@ -17,7 +17,7 @@ S = "${WORKDIR}/u-boot-${PV}"
BBCLASSEXTEND = "native nativesdk"
-EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTLD="${LD}" HOSTSTRIP=true'
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
do_compile () {
oe_runmake tools
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb
index 3ca0c2c..c4921d6 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=1707d6db1d42237583f50183a5651ecb \
file://README;beginline=1;endline=22;md5=5ba4218ac89af7846802d0348df3fb90"
SECTION = "bootloader"
-PR = "r0"
+PR = "r1"
SRC_URI = "ftp://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2";
@@ -15,7 +15,7 @@ S = "${WORKDIR}/u-boot-${PV}"
BBCLASSEXTEND = "native nativesdk"
-EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTLD="${LD}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
do_compile () {
oe_runmake tools
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
index aa107fe..c41a2f1 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
@@ -3,6 +3,8 @@ LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb"
SECTION = "bootloader"
+PR = "r1"
+
# This is needs to be validated among supported BSP's before we can
# make it default
DEFAULT_PREFERENCE = "-1"
@@ -18,7 +20,7 @@ SRC_URI =
"git://git.denx.de/u-boot.git;branch=master;protocol=git"
S = "${WORKDIR}/git"
-EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTLD="${LD}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
do_compile () {
oe_runmake tools
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] u-boot-fw-utils: Correct EXTRA_OEMAKE
On Tue, Aug 21, 2012 at 01:56:46PM -0700, Khem Raj wrote:
> On Tue, Aug 21, 2012 at 12:28 PM, Saul Wold wrote:
> > HOSTCFLAGS="${CFLAGS}
>
> needs a closing quote
Good spotting, both of you. But I can't test a v2 as the problem of
nothing being buildable on just oe-core still remains. Of course, I'll
happily don another brown paper bag atop my current one, just point me
at what I've got wrong :)
--
Tom
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] u-boot-fw-utils: Correct EXTRA_OEMAKE
On Tue, Aug 21, 2012 at 12:28 PM, Saul Wold wrote:
> HOSTCFLAGS="${CFLAGS}
needs a closing quote
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] pseudo diagnostics: please do not ignore these completely!
If you have really weird build problems: Check the pseudo.log file for a given package. A lot of packages are generating a fair number of diagnostics and warnings some of which indicate that stuff is non-trivially busted for some packages. A quick scan of a small build turned up 16 packages with no diagnostics, and 21 which had diagnostics of some sort. Of those 21, 18 had at least one case in which the database showed an inode as being a directory, and a request showed that it wasn't anymore, or vice versa. Pseudo is fairly paranoid about trying to catch stuff like this, but it tends to do its best to fail quietly and just log the errors -- these logs don't do much if we don't follow up on them, though. The basic rule is: If pseudo is aware of or using a file or directory, that file or directory should not be moved/renamed, or replaced, except under pseudo. In many cases, things will recover. If a file is created under pseudo, then renamed outside pseudo, then statted under pseudo again, the database entry for the inode will be found and pseudo will probably do the right thing. If there's a mismatch where an inode's basic type (file/directory/link) mismatches between the database and an incoming request, pseudo will nuke the bogus database entry. But this won't catch everything. So if you have a strange problem that you can't reproduce, check the pseudo.log file. It may not mean much to you, but if it says anything about "dir err" or "ino mismatch", something has gone pretty badly wrong. If you can reproduce "this file is full of weird messages" with a given package, that's probably a bug in the package, and I will try to look into some of these when I have a minute or three and see whether I can find any patterns. And yes, I'm aware that running things under pseudo is slow. I have plans to work on that too. Maybe I should do a kickstarter. :) -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] u-boot-fw-utils: Correct EXTRA_OEMAKE
On 08/20/2012 10:57 AM, Tom Rini wrote:
On Fri, Aug 17, 2012 at 07:46:19PM -0700, Saul Wold wrote:
On 08/17/2012 09:48 AM, Tom Rini wrote:
- HOSTCFLAGS / HOSTLDFLAGS have been valid for a long time for tools/env
- HOSTSTRIP will be needed in the future, does no harm to be correct
now.
Signed-off-by: Tom Rini
---
meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb |4 ++--
.../u-boot/u-boot-fw-utils_2012.04.01.bb |4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb
index 7c4df1a..99eef15 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb
@@ -6,7 +6,7 @@ SECTION = "bootloader"
DEPENDS = "mtd-utils"
-PR = "r1"
+PR = "r2"
SRC_URI = "ftp://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2";
@@ -15,7 +15,7 @@ SRC_URI[sha256sum] =
"362ddb935885da98cf461eba08f31e3e59d0c4ada6cb2fa15596f43af3
S = "${WORKDIR}/u-boot-${PV}"
-EXTRA_OEMAKE = 'HOSTCC="${CC}"'
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS} HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
Ah, finally here it is --^
Missing a "!
Sau!
do_compile () {
oe_runmake env
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
index fe3422a..364f8a5 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
@@ -5,6 +5,8 @@ SECTION = "bootloader"
DEPENDS = "mtd-utils"
+PR = "r1"
+
# This is needs to be validated among supported BSP's before we can
# make it default
DEFAULT_PREFERENCE = "-1"
@@ -20,7 +22,7 @@ SRC_URI =
"git://git.denx.de/u-boot.git;branch=master;protocol=git"
S = "${WORKDIR}/git"
-EXTRA_OEMAKE = 'HOSTCC="${CC}"'
+EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTCFLAGS="${CFLAGS} HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
do_compile () {
oe_runmake env
This had a failure also:
ERROR: Function failed: do_install (see
/srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/i586-poky-linux/u-boot-fw-utils-2011.06-r2/temp/log.do_install.69452
for further information)
ERROR: Logfile of failure stored in:
/srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/i586-poky-linux/u-boot-fw-utils-2011.06-r2/temp/log.do_install.69452
Log data follows:
| DEBUG: Executing shell function do_install
| install: cannot stat
`/srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/i586-poky-linux/u-boot-fw-utils-2011.06-r2/u-boot-2011.06/tools/env/fw_printenv':
No such file or directory
| ERROR: Function failed: do_install (see
/srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/i586-poky-linux/u-boot-fw-utils-2011.06-r2/temp/log.do_install.69452
for further information)
NOTE: package u-boot-fw-utils-2011.06-r2: task do_install: Failed
ERROR: Task 2755
(/srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-world/build/meta/recipes-bsp/u-boot/u-boot-fw-utils_2011.06.bb,
do_install) failed with exit code '1'
I have to admit that since these were trivial changes I didn't try and
build them. But oe-core doesn't build anymore. Doing:
git pull
git reset --hard origin/master
rm -rf build/conf build/tmp*
. oe-init-build-env
bitbake core-image-sato
Fails and can't give me a log. Can you pastebin the compile logs?
Finally the compile log, sorry had other fires I was fighting, seems the
make is doing nothing!
DEBUG: Executing shell function do_compile
NOTE: make -j 6 HOSTCC=arm-poky-linux-gnueabi-gcc -march=armv7-a
-fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon
-mtune=cortex-a8 --sysroot=/intel/poky/builds/world/tmp/sysroots/beagleboard
HOSTCFLAGS= -O2 -pipe -g -feliminate-unused-debug-types HOSTLDFLAGS=-Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed HOSTSTRIP=true tools
make -j 6 HOSTCC=arm-poky-linux-gnueabi-gcc -march=armv7-a
-fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon
-mtune=cortex-a8 --sysroot=/intel/poky/builds/world/tmp/sysroots/beagleboard
HOSTCFLAGS= -O2 -pipe -g -feliminate-unused-debug-types HOSTLDFLAGS=-Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed HOSTSTRIP=true tools
DEBUG: Shell function do_compile finished
Thanks!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 2:13 PM, Chris Larson wrote: > On Tue, Aug 21, 2012 at 11:47 AM, McClintock Matthew-B29882 > wrote: >>> #ifndef O_CLOEXEC >>> # define O_CLOEXEC 0 >>> #endif >>> >>> and be done with it >> >> Well this is seemingly the same way of doing it, just looks like you >> always want it applied? I don't think it should always be applied. >> >> If this was it takes to get the build fix in, then I will do it... >> please confirm what will be accepted. > > No, on newer systems O_CLOEXEC will be defined, so that #ifndef block > will never be entered, and there'll be no change. Right, I was not thinking... -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 11:47 AM, McClintock Matthew-B29882 wrote: >> #ifndef O_CLOEXEC >> # define O_CLOEXEC 0 >> #endif >> >> and be done with it > > Well this is seemingly the same way of doing it, just looks like you > always want it applied? I don't think it should always be applied. > > If this was it takes to get the build fix in, then I will do it... > please confirm what will be accepted. No, on newer systems O_CLOEXEC will be defined, so that #ifndef block will never be entered, and there'll be no change. -- Christopher Larson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 2:02 PM, Chris Larson wrote:
> On Tue, Aug 21, 2012 at 11:48 AM, Khem Raj wrote:
>> On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold wrote:
>>> On 08/21/2012 11:30 AM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
wrote:
>
> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj wrote:
>>
>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>> wrote:
>>>
>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
wrote:
>
> +
> +do_configure_prepend (){
> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h;
> then
> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
> + fi
> +}
IMO It would be safer to create a patch for kmod itself where you
define O_CLOEXEC if it
was not defined before. The above seems a bit risky
>>>
>>>
>>> Why is it risky? I only wanted to do this for affected systems. There
>>> is not an easy way to do this with a patch, unless of course I apply
>>> the patch manually.
>>
>>
>> manually gripping at the host installation and then if O_CLOEXEC might
>> be in comments
>
>
> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
>
>> and furthermore it if it comes from fcntl.h which is not where you are
>> looking for
>
>
> I am grepping this file though?
I would go into the specific file where its asking for O_CLOEXEC
and add
#ifndef O_CLOEXEC
# define O_CLOEXEC 0
#endif
and be done with it
>
> This does seem like a nicer approach.
OK - 2v1 ;) I'll respin as a patch.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 11:48 AM, Khem Raj wrote:
> On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold wrote:
>> On 08/21/2012 11:30 AM, Khem Raj wrote:
>>>
>>> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
>>> wrote:
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj wrote:
>
> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
> wrote:
>>
>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
>>>
>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>>> wrote:
+
+do_configure_prepend (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h;
then
+ export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
+ fi
+}
>>>
>>>
>>>
>>> IMO It would be safer to create a patch for kmod itself where you
>>> define O_CLOEXEC if it
>>> was not defined before. The above seems a bit risky
>>
>>
>> Why is it risky? I only wanted to do this for affected systems. There
>> is not an easy way to do this with a patch, unless of course I apply
>> the patch manually.
>
>
> manually gripping at the host installation and then if O_CLOEXEC might
> be in comments
How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
> and furthermore it if it comes from fcntl.h which is not where you are
> looking for
I am grepping this file though?
>>>
>>>
>>> I would go into the specific file where its asking for O_CLOEXEC
>>>
>>> and add
>>>
>>> #ifndef O_CLOEXEC
>>> # define O_CLOEXEC 0
>>> #endif
>>>
>>> and be done with it
This does seem like a nicer approach.
--
Christopher Larson
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 1:30 PM, Khem Raj wrote:
> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
> wrote:
>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj wrote:
>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>>> wrote:
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
> wrote:
>> +
>> +do_configure_prepend (){
>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
>> + fi
>> +}
>
>
> IMO It would be safer to create a patch for kmod itself where you
> define O_CLOEXEC if it
> was not defined before. The above seems a bit risky
Why is it risky? I only wanted to do this for affected systems. There
is not an easy way to do this with a patch, unless of course I apply
the patch manually.
>>>
>>> manually gripping at the host installation and then if O_CLOEXEC might
>>> be in comments
>>
>> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
>>
>>> and furthermore it if it comes from fcntl.h which is not where you are
>>> looking for
>>
>> I am grepping this file though?
>
> I would go into the specific file where its asking for O_CLOEXEC
>
> and add
>
> #ifndef O_CLOEXEC
> # define O_CLOEXEC 0
> #endif
>
> and be done with it
Well this is seemingly the same way of doing it, just looks like you
always want it applied? I don't think it should always be applied.
If this was it takes to get the build fix in, then I will do it...
please confirm what will be accepted.
-M
>
>>
>>> there are few variables like that where its impacting more than
>>> affected systems.
>>
>> I don't follow...
>>
>> -M
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1 denzil] recipes-core/eglibc-2.13: Patch for locale-base-tt-ru packaging
From: Jeff Polk
The eglibc-2.13 build can fail because locale-base-tt-ru is in
PACKAGES twice. This is because the SUPPORTED list and the i18n
directories are out of sync with each other; the SUPPORTED list
expects a directory named "tt_RU.UTF8", but the directory is
actually named "tt_RU", and likewise for the @iqtelif variants.
Signed-off-by: Peter Seebach
Signed-off-by: Jeff Polk
Signed-off-by: Mark Hatle
---
.../eglibc/eglibc-2.13/supported-tt-ru.patch | 13 +
meta/recipes-core/eglibc/eglibc_2.13.bb|3 ++-
2 files changed, 15 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-core/eglibc/eglibc-2.13/supported-tt-ru.patch
diff --git a/meta/recipes-core/eglibc/eglibc-2.13/supported-tt-ru.patch
b/meta/recipes-core/eglibc/eglibc-2.13/supported-tt-ru.patch
new file mode 100644
index 000..c65e38f
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-2.13/supported-tt-ru.patch
@@ -0,0 +1,13 @@
+--- a/localedata/SUPPORTED
b/localedata/SUPPORTED
+@@ -385,8 +385,8 @@
+ tr_TR.UTF-8/UTF-8 \
+ tr_TR/ISO-8859-9 \
+ ts_ZA/UTF-8 \
+-tt_RU.UTF-8/UTF-8 \
+-tt_RU.UTF-8@iqtelif/UTF-8 \
++tt_RU/UTF-8 \
++tt_RU@iqtelif/UTF-8 \
+ ug_CN/UTF-8 \
+ uk_UA.UTF-8/UTF-8 \
+ uk_UA/KOI8-U \
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index 690f99d..d0bac6b 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = "15508"
DEPENDS += "gperf-native"
-PR = "r28"
+PR = "r29"
PR_append = "+svnr${SRCPV}"
EGLIBC_BRANCH="eglibc-2_13"
@@ -14,6 +14,7 @@ SRC_URI =
"svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};proto=http
file://stack-protector-test.patch \
file://armv4-eabi-compile-fix.patch \
file://etc/ld.so.conf \
+ file://supported-tt-ru.patch \
file://generate-supported.mk \
file://ppc-sqrt.patch \
file://multilib_readlib.patch \
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1 denzil] Fix for generation of russian locale
The following changes since commit 95756cfbb7a9348b23cb46a49a5509e57e973faf: valgrind: fix default.supp missing issue (2012-08-21 11:19:26 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib mhatle/denzil-eglibc http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mhatle/denzil-eglibc Jeff Polk (1): recipes-core/eglibc-2.13: Patch for locale-base-tt-ru packaging .../eglibc/eglibc-2.13/supported-tt-ru.patch | 13 + meta/recipes-core/eglibc/eglibc_2.13.bb|3 ++- 2 files changed, 15 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.13/supported-tt-ru.patch -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold wrote:
> On 08/21/2012 11:30 AM, Khem Raj wrote:
>>
>> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
>> wrote:
>>>
>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
wrote:
>
> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
>>
>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>> wrote:
>>>
>>> +
>>> +do_configure_prepend (){
>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h;
>>> then
>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
>>> + fi
>>> +}
>>
>>
>>
>> IMO It would be safer to create a patch for kmod itself where you
>> define O_CLOEXEC if it
>> was not defined before. The above seems a bit risky
>
>
> Why is it risky? I only wanted to do this for affected systems. There
> is not an easy way to do this with a patch, unless of course I apply
> the patch manually.
manually gripping at the host installation and then if O_CLOEXEC might
be in comments
>>>
>>>
>>> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
>>>
and furthermore it if it comes from fcntl.h which is not where you are
looking for
>>>
>>>
>>> I am grepping this file though?
>>
>>
>> I would go into the specific file where its asking for O_CLOEXEC
>>
>> and add
>>
>> #ifndef O_CLOEXEC
>> # define O_CLOEXEC 0
>> #endif
>>
>> and be done with it
>>
> Wasn't this proposed back a month ago:
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026343.html
>
> And there was discussion about that approach then? I think it was rejected
> due to lack of testing.
I think if it worked fine on a system like cents 5.8 then that would
cover the case
as well try it on newer systems where O_CLOEXEC is available that should do it.
>
> Sau!
>
>>>
there are few variables like that where its impacting more than
affected systems.
>>>
>>>
>>> I don't follow...
>>>
>>> -M
>>
>>
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 1:41 PM, Saul Wold wrote:
> On 08/21/2012 11:30 AM, Khem Raj wrote:
>>
>> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
>> wrote:
>>>
>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
wrote:
>
> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
>>
>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>> wrote:
>>>
>>> +
>>> +do_configure_prepend (){
>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h;
>>> then
>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
>>> + fi
>>> +}
>>
>>
>>
>> IMO It would be safer to create a patch for kmod itself where you
>> define O_CLOEXEC if it
>> was not defined before. The above seems a bit risky
>
>
> Why is it risky? I only wanted to do this for affected systems. There
> is not an easy way to do this with a patch, unless of course I apply
> the patch manually.
manually gripping at the host installation and then if O_CLOEXEC might
be in comments
>>>
>>>
>>> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
>>>
and furthermore it if it comes from fcntl.h which is not where you are
looking for
>>>
>>>
>>> I am grepping this file though?
>>
>>
>> I would go into the specific file where its asking for O_CLOEXEC
>>
>> and add
>>
>> #ifndef O_CLOEXEC
>> # define O_CLOEXEC 0
>> #endif
>>
>> and be done with it
>>
> Wasn't this proposed back a month ago:
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026343.html
>
> And there was discussion about that approach then? I think it was rejected
> due to lack of testing.
Then we had a bit more analysis and discussion on the issue and others
chimed in they had implemented similar work arounds... it's all in
that thread.
-M
>
>
>>>
there are few variables like that where its impacting more than
affected systems.
>>>
>>>
>>> I don't follow...
>>>
>>> -M
>>
>>
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] distutils.bblass: change order of args to install step
This let's the user override install-lib argument again if it needs
to be something else, otherwise things like python-setuptools
won't be able to modify the install-lib dir
This fixes a new issue exposed by my previous distutils patch
that fixed the python modules default install location. Also,
it removes running the install step twice which was inadvertant
Signed-off-by: Matthew McClintock
---
meta/classes/distutils.bbclass |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 7588b81..52a1aa8 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -38,8 +38,7 @@ distutils_do_install() {
STAGING_LIBDIR=${STAGING_LIBDIR} \
PYTHONPATH=${D}/${PYTHON_SITEPACKAGES_DIR} \
BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
-${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
${DISTUTILS_INSTALL_ARGS} || \
-${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
${DISTUTILS_INSTALL_ARGS} --install-lib=${D}${libdir}/${PYTHON_DIR} || \
+${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
--install-lib=${D}${libdir}/${PYTHON_DIR} ${DISTUTILS_INSTALL_ARGS} || \
bbfatal "python setup.py install execution failed."
for i in `find ${D} -name "*.py"` ; do \
--
1.7.9.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On 08/21/2012 11:30 AM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
wrote:
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
wrote:
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock wrote:
+
+do_configure_prepend (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
+ export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
+ fi
+}
IMO It would be safer to create a patch for kmod itself where you
define O_CLOEXEC if it
was not defined before. The above seems a bit risky
Why is it risky? I only wanted to do this for affected systems. There
is not an easy way to do this with a patch, unless of course I apply
the patch manually.
manually gripping at the host installation and then if O_CLOEXEC might
be in comments
How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
and furthermore it if it comes from fcntl.h which is not where you are
looking for
I am grepping this file though?
I would go into the specific file where its asking for O_CLOEXEC
and add
#ifndef O_CLOEXEC
# define O_CLOEXEC 0
#endif
and be done with it
Wasn't this proposed back a month ago:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026343.html
And there was discussion about that approach then? I think it was
rejected due to lack of testing.
Sau!
there are few variables like that where its impacting more than
affected systems.
I don't follow...
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj wrote:
> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
> wrote:
>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>>> wrote:
+
+do_configure_prepend (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
+ export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
+ fi
+}
>>>
>>>
>>> IMO It would be safer to create a patch for kmod itself where you
>>> define O_CLOEXEC if it
>>> was not defined before. The above seems a bit risky
>>
>> Why is it risky? I only wanted to do this for affected systems. There
>> is not an easy way to do this with a patch, unless of course I apply
>> the patch manually.
>
> manually gripping at the host installation and then if O_CLOEXEC might
> be in comments
How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
> and furthermore it if it comes from fcntl.h which is not where you are
> looking for
I am grepping this file though?
> there are few variables like that where its impacting more than
> affected systems.
I don't follow...
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Toolchain rework, call for testing
On Tue, Aug 21, 2012 at 4:55 AM, Marcin Juszkiewicz wrote: > W dniu 17.08.2012 06:47, Khem Raj pisze: >> Hi All >> >> Recently glibc build has been simplified upstream. It has dropped the >> dependency on libgcc_s and libgcc_eh for building glibc itself. >> This means that we can simplify our toolchain bootstrap a bit by >> dropping 1 of the 3 cross gcc build stages. We do not need >> gcc-cross-intermediate anymore. > > Please adapt also toolchain-layer in meta-oe for those stuck with gcc 4.6. Patch for toolchain-layer is sent for meta-linaro The patch is here https://github.com/kraj/meta-linaro/commits/master please merge into the meta-linaro layer. > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc: bump PR
* missing in 30617bde61a3b0a0944b49a0c9fb7159dacbb19f, eglibc-initial fails to compile in incremental build with OEBasic Signed-off-by: Martin Jansa --- meta/recipes-devtools/gcc/gcc-4.7.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc index 3f13385..36ce1be 100644 --- a/meta/recipes-devtools/gcc/gcc-4.7.inc +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc @@ -1,6 +1,6 @@ require gcc-common.inc -PR = "r9" +PR = "r10" # Third digit in PV should be incremented after a minor release # happens from this branch on gcc e.g. currently its 4.7.1 -- 1.7.8.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] runqemu-export-rootfs and friends: don't put pseudo db in target fs
In a few places, we have scripts which use /var/pseudo for the pseudo state directory controlling a given filesystem. This seems possibly risky because it means that stuff running under qemu or whatnot could wipe out the data being used to handle that rootfs. Signed-off-by: Peter Seebach --- .../installer/adt-installer/scripts/extract_rootfs |7 +++ scripts/runqemu-export-rootfs |2 +- scripts/runqemu-extract-sdk| 13 +++-- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs b/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs index 62dc170..0bbbeef 100755 --- a/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs +++ b/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs @@ -28,7 +28,6 @@ extract_rootfs() native_sysroot=$3 target_sysroot=$2 PSEUDO_COMMAND="$native_sysroot/usr/bin/pseudo" - PSEUDO_OPTS="-P $natvie_sysroot/usr" TAR_OPTS="-xjf" PSEUDO_OPTS="-P $native_sysroot/usr" @@ -46,9 +45,9 @@ extract_rootfs() mkdir -p "$target_sysroot" fi - mkdir -p "$target_sysroot/var/pseudo" - touch "$target_sysroot/var/pseudo/pseudo.pid" - PSEUDO_LOCALSTATEDIR="$target_sysroot/var/pseudo" + mkdir -p "$target_sysroot/../pseudo_state" + touch "$target_sysroot/../pseudo_state/pseudo.pid" + PSEUDO_LOCALSTATEDIR="$target_sysroot/../pseudo_state" export PSEUDO_LOCALSTATEDIR echo_info "Extracting rootfs: $1, using pseudo..." diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs index f8213ba..9b7941b 100755 --- a/scripts/runqemu-export-rootfs +++ b/scripts/runqemu-export-rootfs @@ -68,7 +68,7 @@ NFSPID=~/.runqemu-sdk/nfs$NFS_INSTANCE.pid MOUNTPID=~/.runqemu-sdk/mount$NFS_INSTANCE.pid PSEUDO_OPTS="-P $OECORE_NATIVE_SYSROOT/usr" -PSEUDO_LOCALSTATEDIR="$NFS_EXPORT_DIR/var/pseudo" +PSEUDO_LOCALSTATEDIR="$NFS_EXPORT_DIR/../pseudo_state" export PSEUDO_LOCALSTATEDIR if [ ! -d "$PSEUDO_LOCALSTATEDIR" ]; then diff --git a/scripts/runqemu-extract-sdk b/scripts/runqemu-extract-sdk index 4b52475..8bab333 100755 --- a/scripts/runqemu-extract-sdk +++ b/scripts/runqemu-extract-sdk @@ -73,15 +73,16 @@ if [ ! -d "$SDK_ROOTFS_DIR" ]; then mkdir -p "$SDK_ROOTFS_DIR" fi -if [ -e "$SDK_ROOTFS_DIR/var/pseudo" ]; then - echo "Error: $SDK_ROOTFS_DIR/var/pseudo already exists!" - echo "Please delete the entire rootfs tree manually if this is really what you want" +if [ -e "$SDK_ROOTFS_DIR/../pseudo_state" ]; then + echo "Error: $SDK_ROOTFS_DIR/../pseudo_state already exists!" + echo "Please delete the rootfs tree and pseudo directory manually" +echo "if this is really what you want." exit 1 fi -mkdir -p "$SDK_ROOTFS_DIR/var/pseudo" -touch "$SDK_ROOTFS_DIR/var/pseudo/pseudo.pid" -PSEUDO_LOCALSTATEDIR="$SDK_ROOTFS_DIR/var/pseudo" +mkdir -p "$SDK_ROOTFS_DIR/../pseudo_state" +touch "$SDK_ROOTFS_DIR/../pseudo_state/pseudo.pid" +PSEUDO_LOCALSTATEDIR="$SDK_ROOTFS_DIR/../pseudo_state" export PSEUDO_LOCALSTATEDIR echo "Extracting rootfs tarball using pseudo..." -- 1.7.0.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Move PSEUDO_LOCALSTATEDIR outside rootfs
There's a race condition in one of our (non-poky) builds which involves a rootfs getting deleted while a pseudo process has a db in it open. This caused me to realize that there existed a pseudo database in a target filesystem, which made me panic. And we have a few really strange reports I've never been able to reproduce where target filesystems under qemu went pear-shaped in ways that look like pseudo suddenly got really, really, confused. Like say what would happen if a target could wipe out its own filesystem permissions, because they were in its rootfs. :P I haven't tested this super thoroughly, but I can still complete builds and SDK builds with it, and it makes sense. The following changes since commit 4ef8960c8d2876914bb78cbdce5fae3c5297e942: Khem Raj (1): gcc-cross-intermediate, gcc-crosssdk-intermediate: Remove are available in the git repository at: git://git.yoctoproject.org/poky-contrib seebs/varpseudo http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/varpseudo Peter Seebach (1): runqemu-export-rootfs and friends: don't put pseudo db in target fs .../installer/adt-installer/scripts/extract_rootfs |7 +++ scripts/runqemu-export-rootfs |2 +- scripts/runqemu-extract-sdk| 13 +++-- 3 files changed, 11 insertions(+), 11 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
wrote:
> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj wrote:
>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>> wrote:
>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
wrote:
> +
> +do_configure_prepend (){
> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
> + fi
> +}
IMO It would be safer to create a patch for kmod itself where you
define O_CLOEXEC if it
was not defined before. The above seems a bit risky
>>>
>>> Why is it risky? I only wanted to do this for affected systems. There
>>> is not an easy way to do this with a patch, unless of course I apply
>>> the patch manually.
>>
>> manually gripping at the host installation and then if O_CLOEXEC might
>> be in comments
>
> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
>
>> and furthermore it if it comes from fcntl.h which is not where you are
>> looking for
>
> I am grepping this file though?
I would go into the specific file where its asking for O_CLOEXEC
and add
#ifndef O_CLOEXEC
# define O_CLOEXEC 0
#endif
and be done with it
>
>> there are few variables like that where its impacting more than
>> affected systems.
>
> I don't follow...
>
> -M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
> wrote:
>> +
>> +do_configure_prepend (){
>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
>> + fi
>> +}
>
>
> IMO It would be safer to create a patch for kmod itself where you
> define O_CLOEXEC if it
> was not defined before. The above seems a bit risky
Why is it risky? I only wanted to do this for affected systems. There
is not an easy way to do this with a patch, unless of course I apply
the patch manually.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Toolchain rework, call for testing
On Tue, Aug 21, 2012 at 10:15:47AM -0700, Khem Raj wrote: > On Tue, Aug 21, 2012 at 5:18 AM, Martin Jansa wrote: > > > > Maybe it's because > > http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f > > is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic > > not OEBasicHash here). > > yes seems so. I have stopped using OEBasic long ago, you should stop > using it too. I'm using OEBasicHash on one jenkins setup, but that one is still building changes from 2 days ago.. (building 24/7.. ) > But feel free to send a PR bump patchlet. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] task-base: pull in the bluez asound module when appropriate
From: Christopher Larson
If the machine and distro both want alsa, then have task-base-bluetooth pull
in the libasound-module-bluez package.
Signed-off-by: Christopher Larson
---
meta/recipes-core/tasks/task-base.bb |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/tasks/task-base.bb
b/meta/recipes-core/tasks/task-base.bb
index 2325dbf..d5dd140 100644
--- a/meta/recipes-core/tasks/task-base.bb
+++ b/meta/recipes-core/tasks/task-base.bb
@@ -2,7 +2,7 @@ DESCRIPTION = "Merge machine and distro options to create a
basic machine task/p
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-PR = "r74"
+PR = "r75"
inherit task
@@ -205,8 +205,9 @@ RRECOMMENDS_task-base-pcmcia = "\
# Provide bluez-utils-compat utils for the time being, the binaries in that
package will vanish soon from upstream releases, so beware!
-RDEPENDS_task-base-bluetooth = "\
+RDEPENDS_task-base-bluetooth = "\
bluez4 \
+${@base_contains('COMBINED_FEATURES', 'alsa', 'libasound-module-bluez',
'',d)} \
"
RRECOMMENDS_task-base-bluetooth = "\
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
wrote:
> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj wrote:
>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>> wrote:
>>> +
>>> +do_configure_prepend (){
>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
>>> + fi
>>> +}
>>
>>
>> IMO It would be safer to create a patch for kmod itself where you
>> define O_CLOEXEC if it
>> was not defined before. The above seems a bit risky
>
> Why is it risky? I only wanted to do this for affected systems. There
> is not an easy way to do this with a patch, unless of course I apply
> the patch manually.
manually gripping at the host installation and then if O_CLOEXEC might
be in comments
and furthermore it if it comes from fcntl.h which is not where you are
looking for
there are few variables like that where its impacting more than
affected systems.
>
> -M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock wrote:
> +
> +do_configure_prepend (){
> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
> + fi
> +}
IMO It would be safer to create a patch for kmod itself where you
define O_CLOEXEC if it
was not defined before. The above seems a bit risky
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemu gl changes are broken.
On 08/21/2012 09:21 AM, Scott Garman wrote: Hello, I tried building some images overnight with the latest master, and could not get them to run this morning with qemu - I got an odd error that a VNC server was started instead? Just on a hunch, I reverted the following commits: qemu: Fix broken accidental path move qemu-git: Drop GL passthrough support qemu-0.15: Drop GL passthrough support rebuilt qemu-native, and now qemu works correctly. I have no idea why qemu is trying to fallback on a VNC server, as I did not have one running on my machine. I know we use VNC for our autobuilder sanity tests, but those haven't been integrated into the runqemu scripts as far as I can tell. This may need further research, I seem to have it working on another machine. I'll report back once I've learned more. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] RFC: OE-Core task rework
On 08/21/2012 01:49 AM, Paul Eggleton wrote: On Monday 20 August 2012 15:45:07 Mark Hatle wrote: ... Yup, there is a logical grouping for the lsb specific tasks, as for others. The naming needs to be made clear as to why it's there, and what it represents. Same with the summary and descriptions -- they should list the functionality provided by this group of components. The main concern with LSB is that we have something called task-basic, which seems to be intended for LSB but does not state as much, and I know at least one person has tried to use it and then been a little puzzled as to why rpm has been pulled in when ipk packaging has been selected. Just naming some of these tasks more appropriately would help avoid such situations. In the specific case of task-basic there may be a case for creating a similar but not LSB-focused task that pulls in real shell utilities in preference to the light versions provided by busybox. I was seriously stumped by the presence of rpm in what I felt should have been a very basic image. If a task/group is targeted at lsb, it needs to have lsb plastered all over the name so the rest of us can avoid it :) Philip 4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which converts some IMAGE_FEATURES into the addition of tasks to be installed (see classes/core-image.bbclass). At the very least we should probably rename this if we rename tasks to package groups, and there's a question as to how IMAGE_FEATURES scales - should every task be represented in there or only a select list? Would we be better off not trying to bring any tasks in via IMAGE_FEATURES at all and mostly leave that to control post-processing (e.g. package-management, debug-tweaks, etc.)? I'd certainly prefer that images were limited to selecting software from task (group) recipes only, and not providing their own. An image should be able to change the selection based on an "image feature" or similar configuration, but the underlying tasks/groups, recipes, etc should all be 'generic' to a given distribution configuration. The first part seems reasonable to me; but I'm still short of an answer as to what to do with the existing IMAGE_FEATURES code as mentioned above. At the moment aside from the special features such as debug-tweaks, these are just a thin layer on top of task recipes which doesn't add very much at all other than extra maintenance. I think if you go through the images today, a lot of that stuff is either old, or could be simplified by creating appropriate tasks/groups. OK, that's a good point. I have another task on my list to clean up our image recipes and that would be a good segue into that. Cheers, Paul ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] conf/bitbake.conf: allow cache reuse between bitbake, bitbake-layers and hob
BB_ENV_EXTRAWHITE is set by the bitbake wrapper script but not by
bitbake-layers, and thus it was affecting the data hash and thus
invalidating the cache. Any variables passed through from the
environment by being added to this variable should themselves
influence the hash already if they are not already excluded from,
the data hash, so BB_ENV_EXTRAWHITE can be excluded.
Similarly, DISABLE_SANITY_CHECKS is set by the hob script in order to
have sanity checks run later, but not set by the bitbake wrapper script.
It doesn't actually affect the build itself and so its value can also
be excluded from the data hash.
These changes prevent unnecessary reparsing between executions of
bitbake, bitbake-layers, and the initial pseudo build within the hob
script.
Fixes [YOCTO #2680].
Signed-off-by: Paul Eggleton
---
meta/conf/bitbake.conf |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index bc2d47d..ad98756 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -762,7 +762,7 @@ BB_CONSOLELOG ?=
"${LOG_DIR}/cooker/${MACHINE}/${DATETIME}.log"
# Setup our default hash policy
BB_SIGNATURE_HANDLER ?= "OEBasicHash"
BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR
SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER
FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST PRSERV_PORT
PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE CCACHE_DIR
EXTERNAL_TOOLCHAIN CCACHE"
-BB_HASHCONFIG_WHITELIST ?= "${BB_HASHBASE_WHITELIST} DATE TIME SESSION_MANAGER
DBUS_SESSION_BUS_ADDRESS SSH_AGENT_PID XDG_SESSION_COOKIE SSH_AUTH_SOCK
XAUTHORITY PSEUDO_BUILD"
+BB_HASHCONFIG_WHITELIST ?= "${BB_HASHBASE_WHITELIST} DATE TIME SESSION_MANAGER
DBUS_SESSION_BUS_ADDRESS SSH_AGENT_PID XDG_SESSION_COOKIE SSH_AUTH_SOCK
XAUTHORITY PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS"
BB_SIGNATURE_EXCLUDE_FLAGS ?= "doc defaultval _append _prepend deps depends
lockfiles type vardepsexclude \
vardeps vardepvalue file-checksums python func
task export unexport noexec \
nostamp dirs cleandirs sstate-lockfile-shared
prefuncs postfuncs export_func \
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Toolchain rework, call for testing
On Tue, Aug 21, 2012 at 5:18 AM, Martin Jansa wrote: > > Maybe it's because > http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f > is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic not > OEBasicHash here). yes seems so. I have stopped using OEBasic long ago, you should stop using it too. But feel free to send a PR bump patchlet. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Toolchain rework, call for testing
On Tue, Aug 21, 2012 at 4:55 AM, Marcin Juszkiewicz wrote: > W dniu 17.08.2012 06:47, Khem Raj pisze: >> Hi All >> >> Recently glibc build has been simplified upstream. It has dropped the >> dependency on libgcc_s and libgcc_eh for building glibc itself. >> This means that we can simplify our toolchain bootstrap a bit by >> dropping 1 of the 3 cross gcc build stages. We do not need >> gcc-cross-intermediate anymore. > > Please adapt also toolchain-layer in meta-oe for those stuck with gcc 4.6. > Yes. I am testing a patch for it. For tries just delete the *intermediate* files and see if it helps, I believe you will need it for meta-linaro as well. > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] qemu gl changes are broken.
Hello, I tried building some images overnight with the latest master, and could not get them to run this morning with qemu - I got an odd error that a VNC server was started instead? Just on a hunch, I reverted the following commits: qemu: Fix broken accidental path move qemu-git: Drop GL passthrough support qemu-0.15: Drop GL passthrough support rebuilt qemu-native, and now qemu works correctly. I have no idea why qemu is trying to fallback on a VNC server, as I did not have one running on my machine. I know we use VNC for our autobuilder sanity tests, but those haven't been integrated into the runqemu scripts as far as I can tell. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 5:49 AM, Richard Purdie
wrote:
> On Mon, 2012-08-20 at 13:49 -0500, Matthew McClintock wrote:
>> kmod will fail to build with the following error because O_CLOEXEC is
>> not defined:
>>
>> | libkmod/libkmod-module.c: In function 'kmod_module_get_initstate':
>> | libkmod/libkmod-module.c:1640: error: 'O_CLOEXEC' undeclared (first use in
>> this function)
>> | libkmod/libkmod-module.c:1640: error: (Each undeclared identifier is
>> reported only once
>> | libkmod/libkmod-module.c:1640: error: for each function it appears in.)
>> | libkmod/libkmod-module.c: In function 'kmod_module_get_refcnt':
>> | libkmod/libkmod-module.c:1754: error: 'O_CLOEXEC' undeclared (first use in
>> this function)
>> | libkmod/libkmod-module.c: In function 'kmod_module_get_sections':
>> | libkmod/libkmod-module.c:1913: error: 'O_CLOEXEC' undeclared (first use in
>> this function)
>> | libkmod/libkmod-file.c: In function 'kmod_file_open':
>> | libkmod/libkmod-file.c:282: error: 'O_CLOEXEC' undeclared (first use in
>> this function)
>> | libkmod/libkmod-file.c:282: error: (Each undeclared identifier is reported
>> only once
>> | libkmod/libkmod-file.c:282: error: for each function it appears in.)
>>
>> Since we are only using kmod-native for depmod, and it's a non-threaded
>> user of this libary being built this should be safe to override O_CLOEXEC.
>>
>> Keep in mind this is ONLY effecting the native builds and not what is
>> being shipped in the root file system.
>>
>> Signed-off-by: Matthew McClintock
>> ---
>> meta/recipes-kernel/kmod/kmod-native_git.bb |8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-kernel/kmod/kmod-native_git.bb
>> b/meta/recipes-kernel/kmod/kmod-native_git.bb
>> index 96de8b8..3c5e3c3 100644
>> --- a/meta/recipes-kernel/kmod/kmod-native_git.bb
>> +++ b/meta/recipes-kernel/kmod/kmod-native_git.bb
>> @@ -4,7 +4,7 @@
>> require kmod.inc
>> inherit native
>>
>> -PR = "${INC_PR}.0"
>> +PR = "${INC_PR}.1"
>>
>> do_install_append (){
>> for tool in depmod insmod lsmod modinfo modprobe rmmod
>> @@ -12,3 +12,9 @@ do_install_append (){
>> ln -s kmod ${D}${bindir}/$tool
>> done
>> }
>> +
>> +do_compile_append (){
>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
>> + fi
>> +}
>
>
> A compile append would execute after the compile. Isn't this after the
> point you need the change?
Yes, and this makes me wonder what I tested...
Anyways, v2 fixed up and sent. I also needed to export the CFLAGS even
earlier so they got picked up correctly.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
kmod will fail to build with the following error because O_CLOEXEC is
not defined:
| libkmod/libkmod-module.c: In function 'kmod_module_get_initstate':
| libkmod/libkmod-module.c:1640: error: 'O_CLOEXEC' undeclared (first use in
this function)
| libkmod/libkmod-module.c:1640: error: (Each undeclared identifier is reported
only once
| libkmod/libkmod-module.c:1640: error: for each function it appears in.)
| libkmod/libkmod-module.c: In function 'kmod_module_get_refcnt':
| libkmod/libkmod-module.c:1754: error: 'O_CLOEXEC' undeclared (first use in
this function)
| libkmod/libkmod-module.c: In function 'kmod_module_get_sections':
| libkmod/libkmod-module.c:1913: error: 'O_CLOEXEC' undeclared (first use in
this function)
| libkmod/libkmod-file.c: In function 'kmod_file_open':
| libkmod/libkmod-file.c:282: error: 'O_CLOEXEC' undeclared (first use in this
function)
| libkmod/libkmod-file.c:282: error: (Each undeclared identifier is reported
only once
| libkmod/libkmod-file.c:282: error: for each function it appears in.)
Since we are only using kmod-native for depmod, and it's a non-threaded
user of this libary being built this should be safe to override O_CLOEXEC.
Keep in mind this is ONLY effecting the native builds and not what is
being shipped in the root file system.
Signed-off-by: Matthew McClintock
---
meta/recipes-kernel/kmod/kmod-native_git.bb |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/kmod/kmod-native_git.bb
b/meta/recipes-kernel/kmod/kmod-native_git.bb
index 96de8b8..4558c7b 100644
--- a/meta/recipes-kernel/kmod/kmod-native_git.bb
+++ b/meta/recipes-kernel/kmod/kmod-native_git.bb
@@ -4,7 +4,7 @@
require kmod.inc
inherit native
-PR = "${INC_PR}.0"
+PR = "${INC_PR}.1"
do_install_append (){
for tool in depmod insmod lsmod modinfo modprobe rmmod
@@ -12,3 +12,9 @@ do_install_append (){
ln -s kmod ${D}${bindir}/$tool
done
}
+
+do_configure_prepend (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
+ export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
+ fi
+}
--
1.7.9.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4] busybox: Upgrade to upstream 1.20.2
On 08/21/2012 01:23 AM, Radu Moisan wrote:
Updated defconfig file from generated .config
Disabled CONFIG_LSOF,CONFIG_CROSS_COMPILER_PREFIX, and CONFIG_EXTRA_CFLAGS
for backwards compatibility.
Added busybox-1.20.2-kernel_ver.patch from upstream.
Signed-off-by: Radu Moisan
---
.../poky-tiny/defconfig|0
...box_1.19.4.bbappend => busybox_1.20.2.bbappend} |0
.../B921600.patch |0
.../busybox-1.20.2/busybox-1.20.2-kernel_ver.patch | 25 +
.../busybox-appletlib-dependency.patch |0
.../busybox-mkfs-minix-tests_bigendian.patch |0
.../busybox-udhcpc-no_deconfig.patch | 37 +--
.../{busybox-1.19.4 => busybox-1.20.2}/defconfig | 39 +---
.../fix-for-spurious-testsuite-failure.patch |0
.../get_header_tar.patch |0
.../run-parts.in.usr-bin.patch |0
.../sys_resource.patch |0
.../watch.in.usr-bin.patch |0
.../wget_dl_dir_fix.patch |0
.../{busybox_1.19.4.bb => busybox_1.20.2.bb} |9 +++--
15 files changed, 72 insertions(+), 38 deletions(-)
rename meta-yocto/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/poky-tiny/defconfig (100%)
rename meta-yocto/recipes-core/busybox/{busybox_1.19.4.bbappend =>
busybox_1.20.2.bbappend} (100%)
This needs to be split into 2 patches, one for meta-yocto (sent to
poky@yoctoproject,org and the rest of them to the OE-Core list.
Otherwise this looks good, I think you have addressed the other issues.
Sau!
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/B921600.patch (100%)
create mode 100644
meta/recipes-core/busybox/busybox-1.20.2/busybox-1.20.2-kernel_ver.patch
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/busybox-appletlib-dependency.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/busybox-mkfs-minix-tests_bigendian.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/busybox-udhcpc-no_deconfig.patch (78%)
rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/defconfig
(98%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/fix-for-spurious-testsuite-failure.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/get_header_tar.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/run-parts.in.usr-bin.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/sys_resource.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/watch.in.usr-bin.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/wget_dl_dir_fix.patch (100%)
rename meta/recipes-core/busybox/{busybox_1.19.4.bb => busybox_1.20.2.bb}
(79%)
diff --git a/meta-yocto/recipes-core/busybox/busybox-1.19.4/poky-tiny/defconfig
b/meta-yocto/recipes-core/busybox/busybox-1.20.2/poky-tiny/defconfig
similarity index 100%
rename from meta-yocto/recipes-core/busybox/busybox-1.19.4/poky-tiny/defconfig
rename to meta-yocto/recipes-core/busybox/busybox-1.20.2/poky-tiny/defconfig
diff --git a/meta-yocto/recipes-core/busybox/busybox_1.19.4.bbappend
b/meta-yocto/recipes-core/busybox/busybox_1.20.2.bbappend
similarity index 100%
rename from meta-yocto/recipes-core/busybox/busybox_1.19.4.bbappend
rename to meta-yocto/recipes-core/busybox/busybox_1.20.2.bbappend
diff --git a/meta/recipes-core/busybox/busybox-1.19.4/B921600.patch
b/meta/recipes-core/busybox/busybox-1.20.2/B921600.patch
similarity index 100%
rename from meta/recipes-core/busybox/busybox-1.19.4/B921600.patch
rename to meta/recipes-core/busybox/busybox-1.20.2/B921600.patch
diff --git
a/meta/recipes-core/busybox/busybox-1.20.2/busybox-1.20.2-kernel_ver.patch
b/meta/recipes-core/busybox/busybox-1.20.2/busybox-1.20.2-kernel_ver.patch
new file mode 100644
index 000..456fb08
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox-1.20.2/busybox-1.20.2-kernel_ver.patch
@@ -0,0 +1,25 @@
+--- busybox-1.20.2/libbb/kernel_version.c
busybox-1.20.2-kernel_ver/libbb/kernel_version.c
+@@ -20,18 +20,15 @@
+ int FAST_FUNC get_linux_version_code(void)
+ {
+ struct utsname name;
+- char *s;
++ char *s, *t;
+ int i, r;
+
+- if (uname(&name) == -1) {
+- bb_perror_msg("can't get system information");
+- return 0;
+- }
+-
++ uname(&name); /* never fails */
+ s = name.release;
+ r = 0;
+ for (i = 0; i < 3; i++) {
+- r = r * 256 + atoi(strtok(s, "."));
++ t = strtok(s, ".");
++ r = r * 256 + (t ? atoi(t) : 0);
+ s = NULL;
+ }
+ return r;
diff --git
a/meta/recipes-core/busybox/busybox-1.19.4
Re: [OE-core] [PATCH 0/1] package_rpm.bbclass: fix and enhance the incremental rpm generation
On 08/20/2012 11:48 PM, Robert Yang wrote: * Test info: $ bitbake core-image-sato core-image-sato-sdk meta-toolchain meta-toolchain-sdk $ bitbake package-index Tested the incremental rpm generation based on core-image-minimal and core-image-sato * Note: it doesn't have any conflict with the "Install external binary packages" patches which are in Patch Review. // Robert The following changes since commit 7c40daab587306da25c8d8f566392ee1f57bbef4: qemu: Fix broken accidental path move (2012-08-20 17:25:28 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib robert/inc_rpm http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/inc_rpm Robert Yang (1): package_rpm.bbclass: fix and enhance the incremental rpm generation meta/classes/package_rpm.bbclass | 68 -- 1 files changed, 43 insertions(+), 25 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/9] Rework cross toolchain bootstrap
On 08/20/2012 08:07 PM, Khem Raj wrote: This patchset drops one gcc bootstrap phase. It has been possible because of some work upstream glibc to drop build time dependency on libgcc_s and libgcc_eh I have built all possible images in OE-Core for all qemu machines all of them built fine except *-rt and *-initramfs which failed due to unrelated issues. I have built from scratch as well as built from sstate. Seems to go ok. The following changes since commit 04568d1f18250d531aad5d286157d2d559083520: qemu: Fix broken accidental path move (2012-08-20 17:25:21 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib kraj/toolchain-rework http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/toolchain-rework Khem Raj (9): eglibc-2.16: Remove build dependency on libgcc_s and libgcc_eh eglibc-2.16: Update to top of 2.16 branch gcc-cross: Make gcc-cross-initial as the only intermediate gcc stage eglibc: Fix eglibc-initial and let eglibc depend on it uclibc.inc,uclibc-config.inc: Untabify python snippets uclibc: Use gcc-cross-initial as staging compiler gcc-crosssdk-initial_4.7.bb: Add --with-native-system-header-dir to EXTRA_OECONF gcc-cross-intermediate, gcc-crosssdk-intermediate: Remove Merged the above set of 8 into OE-Core Thanks Sau! gcc: Switch SRC_URI to use svn .../0001-Add-ARM-specific-static-stubs.c.patch | 27 ++ ...f-libgcc_s-and-libgcc_eh-when-building-gl.patch | 343 meta/recipes-core/eglibc/eglibc-initial.inc| 16 +- meta/recipes-core/eglibc/eglibc-testing.inc|2 +- meta/recipes-core/eglibc/eglibc.inc| 11 +- meta/recipes-core/eglibc/eglibc_2.16.bb|6 +- meta/recipes-core/uclibc/uclibc-config.inc | 128 meta/recipes-core/uclibc/uclibc-initial_0.9.33.bb | 10 +- meta/recipes-core/uclibc/uclibc-initial_git.bb | 10 +- meta/recipes-core/uclibc/uclibc.inc| 28 +- meta/recipes-core/uclibc/uclibc_0.9.33.bb |7 +- meta/recipes-core/uclibc/uclibc_git.bb |7 +- meta/recipes-devtools/gcc/gcc-4.7.inc | 11 +- .../gcc/gcc-4.7/arm-nolibfloat.patch | 40 --- meta/recipes-devtools/gcc/gcc-cross-initial.inc| 50 ++- .../gcc/gcc-cross-intermediate.inc | 68 .../gcc/gcc-cross-intermediate_4.7.bb |3 - .../gcc/gcc-crosssdk-initial_4.7.bb|2 + .../gcc/gcc-crosssdk-intermediate.inc |9 - .../gcc/gcc-crosssdk-intermediate_4.7.bb |3 - 20 files changed, 534 insertions(+), 247 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.16/0001-Add-ARM-specific-static-stubs.c.patch create mode 100644 meta/recipes-core/eglibc/eglibc-2.16/0001-Avoid-use-of-libgcc_s-and-libgcc_eh-when-building-gl.patch delete mode 100644 meta/recipes-devtools/gcc/gcc-4.7/arm-nolibfloat.patch delete mode 100644 meta/recipes-devtools/gcc/gcc-cross-intermediate.inc delete mode 100644 meta/recipes-devtools/gcc/gcc-cross-intermediate_4.7.bb delete mode 100644 meta/recipes-devtools/gcc/gcc-crosssdk-intermediate.inc delete mode 100644 meta/recipes-devtools/gcc/gcc-crosssdk-intermediate_4.7.bb ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane.bbclass: Fix RPATH warning in the face of funny path strings
On 08/20/2012 02:05 PM, Andy Ross wrote:
In toolchain edge cases it's possible for the RPATH of a library to be
set to something like "/usr/lib/../lib". This should be detected as
"/usr/lib" and generate a warning.
Signed-off-by: Andy Ross
---
meta/classes/insane.bbclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 556a176..9d085a4 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -166,6 +166,9 @@ def package_qa_check_useless_rpaths(file, name, d, elf,
messages):
"""
Check for RPATHs that are useless but not dangerous
"""
+def rpath_eq(a, b):
+return os.path.normpath(a) == os.path.normpath(b)
+
if not elf:
return
@@ -181,7 +184,7 @@ def package_qa_check_useless_rpaths(file, name, d, elf,
messages):
m = rpath_re.match(line)
if m:
rpath = m.group(1)
- if rpath == libdir or rpath == base_libdir:
+ if rpath_eq(rpath, libdir) or rpath_eq(rpath, base_libdir):
# The dynamic linker searches both these places anyway. There is
no point in
# looking there again.
messages.append("%s: %s contains probably-redundant RPATH %s" %
(name, package_qa_clean_path(file, d), rpath))
Merged this to OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] coreutils: fix to build with acl support
On 08/21/2012 12:42 AM, jackie.hu...@windriver.com wrote: From: Jackie Huang Fix the issue that coreutils was built without acl support: configure: WARNING: libacl development library was not found or not usable. configure: WARNING: GNU coreutils will be built without ACL support. which will cause ls and cp commands don't have the ACL related behaviors: ls -l: no plus sign(+) after the permission string for files that have ACL cp -p: can not preserves the ACLs. [YOCTO #2959] Signed-off-by: Jackie Huang --- The following changes since commit 04568d1f18250d531aad5d286157d2d559083520: qemu: Fix broken accidental path move (2012-08-20 17:25:21 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/bug2959_acl_0821 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/bug2959_acl_0821 Jackie Huang (1): coreutils: fix to build with acl support .../coreutils-6.9/coreutils-build-with-acl.patch | 28 .../coreutils-8.14/coreutils-build-with-acl.patch | 28 meta/recipes-core/coreutils/coreutils_6.9.bb |1 + meta/recipes-core/coreutils/coreutils_8.14.bb |1 + 4 files changed, 58 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-core/coreutils/coreutils-6.9/coreutils-build-with-acl.patch create mode 100644 meta/recipes-core/coreutils/coreutils-8.14/coreutils-build-with-acl.patch Merged into OE-Core Please remember to add PR Bumps for recipe changes. Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libxpm-native: add dependency on gettext-native
On 08/20/2012 06:35 PM, Jesse Zhang wrote: Hi Saul, On 08/21/2012 05:16 AM, Saul Wold wrote: On 08/02/2012 06:57 PM, Jesse Zhang wrote: libxpm needs xgettext to build po files. Add explicit dependency on gettext-native. Signed-off-by: Jesse Zhang --- meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb b/meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb index 9eaa212..6830216 100644 --- a/meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb +++ b/meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb @@ -10,7 +10,8 @@ protocol." LICENSE = "BSD" LIC_FILES_CHKSUM = "file://COPYING;md5=3e07763d16963c3af12db271a31abaa5" DEPENDS += "libxext libsm libxt" -PR = "r0" +DEPENDS_virtclass-native = "gettext-native" Is there a reason you don't do an inherit gettext here to ensure other bits are set? Actually I don't know what's the preferred way to do this. What is required by libxpm is the xgettext command; using DEPENDS will be enough to make it available, but I didn't know the other solution. Ok, well I am telling you there is another, more correct, way to do this using the inherit gettext, so please try using inherit gettext and see if that works correctly. The meta/classes/gettext.bbclass in conjunction with native.bbclass correctly set the DEPENDS to use gettext-native. Also, on another note, please modify your patch subject to just say libxpm, this initial confused a couple of us thinking that libxpm was a native specific recipe. Sau! Also for the native, you maybe able to use the gettext-minimal-native if there is reason you can't use the inherit. gettext-minimal-native is already pulled in through the implicit dependency chain. But clearly it doesn't provide xgettext? jesse +PR = "r1" PE = "1" XORG_PN = "libXpm" ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] apr-util: fix the rules.mk with path to sysroot instead of the workdir of apr
On 08/16/2012 08:11 PM, jackie.hu...@windriver.com wrote: From: Jackie Huang The copying for rules.mk was happened in do_configure_prepend, but it will be replaced by the one generated by configure, in which APR_MKEXPORT points to the workdir of apr and cause compile filure when the workdir of apr is removed. So change the copying in _prepend to _append. [YOCTO #2947] Signed-off-by: Jackie Huang --- The following changes since commit 24babf9316da50c8a4d2f328c4336cb8cd6cf667: classes/chrpath: trigger an error if chrpath fails (2012-08-15 17:51:04 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/bug2947_apr_0817 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/bug2947_apr_0817 Jackie Huang (1): apr-util: fix the rules.mk with path to sysroot instead of the workdir of apr meta/recipes-support/apr/apr-util_1.4.1.bb |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core] error expanding variable do_*
On Tuesday 21 August 2012 15:52:17 Giuseppe Condorelli wrote: > > > []$ bitbake core-image-minimal > > > Pseudo is not present but is required, building this first before the > > > > main > > > > > build > > > NOTE: Error expanding variable do_unpack| ETA: > > > 00:00:04 > > > NOTE: Error during finalise of > > > /oelinux/condorg/openembedded-core/meta/recipes-sato/web/web_git.bb > > > ERROR: Unable to parse > > > /oelinux/condorg/openembedded-core/meta/recipes-sato/web/web_git.bb > > > ERROR: Command execution failed: Exited with 1 > > > > > > I tried with bitbake version 1.15.2 and 1.15.3, the latest two versions. > > > What about the "Error expanding variable do_unpack?" I've read something > > > > in > > > > > previous message on mailing list > > > but with no understanding. > > > > This is almost certainly because of the whitespace changes in python > > functions. > > What type of whitespace changes you are talking about? Please see: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/025962.html > > If you use master of OE-Core, you must use BitBake 1.15.3+; if you > > use denzil, you need to use 1.15.2. I'm a bit confused as to how you could > > have still got this error with 1.15.2 though since that change was not in > > that version (unless you are using master of OE-Core with BitBake 1.15.2). > > I've pulled last two months updates for master OE-Core branch and I tried > with both bitbake 1.15.2 and 1.15.3 versions. I just tried BitBake 1.15.3 with OE-Core latest master and I do not see that error. Are you using latest master of OE-Core or some specific revision? Can you provide me with any other information that would help me to reproduce the issue? If you check out OE-Core in a separate new directory and use BitBake 1.15.3 do you still get the same issue? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core] error expanding variable do_*
2012/8/21 Paul Eggleton > On Tuesday 21 August 2012 15:15:42 Giuseppe Condorelli wrote: > > Hi, > > > Hi Paul, many thanks for your quick reply. > > today I restarted to work on my own OE meta layer and, after having > pulled > > last two months changes is OE-Core, I was able to > > build nothing. > > This is the error I met > > > > []$ bitbake core-image-minimal > > Pseudo is not present but is required, building this first before the > main > > build > > NOTE: Error expanding variable do_unpack| ETA: > > 00:00:04 > > NOTE: Error during finalise of > > /oelinux/condorg/openembedded-core/meta/recipes-sato/web/web_git.bb > > ERROR: Unable to parse > > /oelinux/condorg/openembedded-core/meta/recipes-sato/web/web_git.bb > > ERROR: Command execution failed: Exited with 1 > > > > I tried with bitbake version 1.15.2 and 1.15.3, the latest two versions. > > What about the "Error expanding variable do_unpack?" I've read something > in > > previous message on mailing list > > but with no understanding. > > This is almost certainly because of the whitespace changes in python > functions. What type of whitespace changes you are talking about? > If you use master of OE-Core, you must use BitBake 1.15.3+; if you > use denzil, you need to use 1.15.2. I'm a bit confused as to how you could > have still got this error with 1.15.2 though since that change was not in > that > version (unless you are using master of OE-Core with BitBake 1.15.2). > > I've pulled last two months updates for master OE-Core branch and I tried with both bitbake 1.15.2 and 1.15.3 versions. > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core] error expanding variable do_*
On Tuesday 21 August 2012 15:15:42 Giuseppe Condorelli wrote: > Hi, > > today I restarted to work on my own OE meta layer and, after having pulled > last two months changes is OE-Core, I was able to > build nothing. > This is the error I met > > []$ bitbake core-image-minimal > Pseudo is not present but is required, building this first before the main > build > NOTE: Error expanding variable do_unpack| ETA: > 00:00:04 > NOTE: Error during finalise of > /oelinux/condorg/openembedded-core/meta/recipes-sato/web/web_git.bb > ERROR: Unable to parse > /oelinux/condorg/openembedded-core/meta/recipes-sato/web/web_git.bb > ERROR: Command execution failed: Exited with 1 > > I tried with bitbake version 1.15.2 and 1.15.3, the latest two versions. > What about the "Error expanding variable do_unpack?" I've read something in > previous message on mailing list > but with no understanding. This is almost certainly because of the whitespace changes in python functions. If you use master of OE-Core, you must use BitBake 1.15.3+; if you use denzil, you need to use 1.15.2. I'm a bit confused as to how you could have still got this error with 1.15.2 though since that change was not in that version (unless you are using master of OE-Core with BitBake 1.15.2). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] scripts/combo-layer: specify branch when getting current revision
Handle the case during update where the configured branch is not
currently checked out in the component repository by just specifying
it in the places where it was not previously.
Signed-off-by: Paul Eggleton
---
scripts/combo-layer |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/scripts/combo-layer b/scripts/combo-layer
index 448fe71..330faca 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -191,7 +191,7 @@ def action_init(conf, args):
branch = repo.get('branch', "master")
file_filter = repo.get('file_filter', "")
runcmd("git archive %s | tar -x -C %s %s" % (branch, extract_dir,
file_filter), ldir)
-lastrev = runcmd("git rev-parse HEAD", ldir).strip()
+lastrev = runcmd("git rev-parse %s" % branch, ldir).strip()
conf.update(name, "last_revision", lastrev, initmode=True)
runcmd("git add .")
if conf.localconffile:
@@ -475,7 +475,8 @@ def apply_patchlist(conf, repos):
else:
logger.info("No patches to apply from %s" % name)
ldir = conf.repos[name]['local_repo_dir']
-lastrev = runcmd("git rev-parse HEAD", ldir).strip()
+branch = conf.repos[name].get('branch', "master")
+lastrev = runcmd("git rev-parse %s" % branch, ldir).strip()
if lastrev != repo['last_revision']:
conf.update(name, "last_revision", lastrev)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] scripts/combo-layer: checkout branch in update when pull is disabled
On Tuesday 21 August 2012 11:40:55 Paul Eggleton wrote:
> If the user selects not to pull the component repos, at least ensure
> that the correct branch is checked out before proceeding.
>
> Signed-off-by: Paul Eggleton
> ---
> scripts/combo-layer |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/scripts/combo-layer b/scripts/combo-layer
> index 448fe71..6134e81 100755
> --- a/scripts/combo-layer
> +++ b/scripts/combo-layer
> @@ -356,6 +356,10 @@ def action_update(conf, args):
> branch = repo.get('branch', "master")
> repo_patch_dir = os.path.join(os.getcwd(), patch_dir, name)
>
> +if conf.nopull:
> +# Need to do this here as we didn't call action_pull that would
> do it otherwise +runcmd("git checkout %s" % branch, ldir)
> +
> # Step 2: generate the patch list and store to patch dir
> logger.info("Generating patches from %s..." % name)
> if dest_dir != ".":
Actually as Richard points out we don't need to be doing the checkout here -
we can just specify the branch in the one or two places where it isn't already
specified. A different patch is on its way.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [discussion] perf: specify SLANG_INC dir for perf
On 12-08-21 01:08 AM, Liang Li wrote:
On 2012-08-20 22:48, Bruce Ashfield wrote:
On 12-08-17 09:05 AM, Liang Li wrote:
On 2012-08-17 21:01, Liang Li wrote:
On 2012-08-17 18:53, Richard Purdie wrote:
On Fri, 2012-08-17 at 18:00 +0800, Liang Li wrote:
I am totally confused, you mentioned 'general kernel do_install', I
assume it's oe-core kernel.bbclass concept. Then you mentioned 'get
the fix upstream in the mainline kernel', how could that happen?
We are discussing about the solution to 'fix the compile warning to
error' stuff that triggered by the '-I/usr/include/slang', right?
Yes.
We do not necessarily have to change recipe to fix it since the issue
is not introduced by the recipe, the hard coded '-I/usr/include/slang'
in the Makefile cause the issue, we can fix the root cause by kernel
patch(other than just comment the line out). I see your previous patch
to kernel, by comment out the '-I/usr/include/slang' line in the
Makefile, is the same behavior, but we won't have the change(comment
out -I.. in Makefile) upstream to mainline, right?
I am suggesting that firstly, someone send a patch to the mainline
kernel which changes -I/usr/include/slang to -I=/usr/include/slang in
that Makefile.
Secondly, I'm suggesting that we add a line to kernel_do_install() in
kernel.bbclass which does a sed on the Makefile as installed into
$kerneldir which changes -I/usr/include/slang to -I=/usr/include/slang.
We can then drop the patch I added to the linux-yocto kernels.
This is all that should be needed, it should fix all the issues people
have reported in a way that is acceptable to everyone.
Ah, I see what you mean now. But we have push acceptable kernel patch
One final (I hope) follow up on this.
Liang: were you going to put together (and test) the 'sed fix' for
kernel.bbclass ?
No problem, the patch for kernel.bbclass:
commit 60a0b06
Author: Liang Li
Date: Tue Aug 21 11:06:01 2012 +0800
kernel.bbclass: fix INC directory for SLANG
The change is intend to fix the hardcoded '-I/usr/include/slang' in
the Makefile to be able to aware of SYSROOT if its specified.
A planned kernel patch almost did the same change, but the change here
won't conflict with it so this change could work for all kernels.
Signed-off-by: Liang Li
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 1afb9ab..282194d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -190,6 +190,9 @@ kernel_do_install() {
for entry in $bin_files; do
rm -f $kerneldir/$entry
done
+
+ # Fix SLNAG_INC for slang.h
s/SLNAG_INC/SLANG_INC/
+ sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g'
$kerneldir/tools/perf/Makefile
It looks like your baseline for this patch is the denzil branch. We'd
want a version for master, which we could backport as required.
}
PACKAGE_PREPROCESS_FUNCS += "kernel_package_preprocess"
---
The patch for kernel tree:
commit 6b72896
Author: Liang Li
Date: Wed Aug 1 14:31:24 2012 +0800
perf: add SLANG_INC for slang.h
Previously we hard code '-I/usr/include/slang' to CFLAGS to works with
some hosts that has /usr/include/slang/slang.h other than
/usr/include/slang.h like Fedora. This will cause compiling warnings
in some cases.
I'd rephrase this slightly as:
CFLAGS was previously hard coded to contain "-I/usr/include/slang" to
work with hosts that have "/usr/include/slang/slang.h" as well as hosts
that have "/usr/include/slang.h". This path can cause compile warnings
in some cases:
.. and indicate that these warnings can actually cause build errors if
WERROR is enabled.
We could downgrade the priority of the default hard coded path, and
provide user a chance to specify correct location of slang.h then user
could specify SLANG_INC to avoid compile warnings like the
'/usr/include/slang' is not exists etc.
Another minor rephrase:
To fix this issue, we can use -idirafter to downgrade the priority of the
default hard coded path. We can also make the slang include directory
a variable, to allow the user to specify SLANG_INC and set their own
include location.
Signed-off-by: Liang Li
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index b7a7a87..e403c36 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -496,8 +496,10 @@ else
msg := $(warning newt not found, disables TUI support. Please
install newt-devel or libnewt-dev);
BASIC_CFLAGS += -DNO_NEWT_SUPPORT
else
- # Fedora has /usr/include/slang/slang.h, but ubuntu
/usr/include/slang.h
- BASIC_CFLAGS += -I/usr/include/slang
+ # Some releases like Fedora has /usr/include/slang/slang.h
other than /usr/include/slang.h
+ SLANG_INC ?= -idirafter =/usr/include/slang
One more question, have you confirmed that gcc is fine with this being
in sysroot
Re: [OE-core] Toolchain rework, call for testing
On 2012-08-21 06:00, Phil Blundell wrote: On Tue, 2012-08-21 at 13:55 +0200, Marcin Juszkiewicz wrote: W dniu 17.08.2012 06:47, Khem Raj pisze: Hi All Recently glibc build has been simplified upstream. It has dropped the dependency on libgcc_s and libgcc_eh for building glibc itself. This means that we can simplify our toolchain bootstrap a bit by dropping 1 of the 3 cross gcc build stages. We do not need gcc-cross-intermediate anymore. Please adapt also toolchain-layer in meta-oe for those stuck with gcc 4.6. Why is it that gcc-4.7 doesn't work for those people? I have troubles with older versions of the Linux kernel on ARM. Anything older than 3.2 either doesn't boot or is unstable. Kernel only, user code built with 4.7+ seems to be fine. Since I need to use those older kernels and I don't have the time/budget to figure out why they don't work with 4.7+, I'm sticking with 4.6+ for now. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Toolchain rework, call for testing
On Thu, Aug 16, 2012 at 09:47:37PM -0700, Khem Raj wrote:
> Hi All
>
> Recently glibc build has been simplified upstream. It has dropped the
> dependency on libgcc_s and libgcc_eh for building glibc itself.
> This means that we can simplify our toolchain bootstrap a bit by
> dropping 1 of the 3 cross gcc build stages. We do not need
> gcc-cross-intermediate
> anymore. This should bring some build time reduction and simplify the
> bootstrap. I have a series of patches which I have tested
> by building core-image-minimal and meta-toolchain for all supported
> qemu architectures and also uclibc/eglibc both
> but it needs a lot more testing therefore I am calling out wider
> audience for help in testing it out.
>
> The branch is
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/toolchain-rework
eglibc fails to build in incremental build
| arm-oe-linux-gnueabi-gcc -march=armv4t -marm -mthumb-interwork
-mtune=arm920t --sysroot=/OE/shr-core/tmp-eglibc/sysroots/om-gta02-tcbootstrap
-nostdlib -nostartfiles -r -o
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.os
\
| -Wl,-d -Wl,--whole-archive
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.a
-o
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.os
| arm-oe-linux-gnueabi-gcc -march=armv4t -marm -mthumb-interwork
-mtune=arm920t --sysroot=/OE/shr-core/tmp-eglibc/sysroots/om-gta02-tcbootstrap
-nostdlib -nostartfiles -r -o
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.map.o
'-Wl,-('
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/dl-allobjs.os
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.a
-lgcc '-Wl,-)'
-Wl,-Map,/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.mapT
|
/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/armv4t-oe-linux-gnueabi.gcc-cross-initial/gcc/arm-oe-linux-gnueabi/4.7.2/ld:
cannot find -lgcc
| collect2: error: ld returned 1 exit status
| make[2]: ***
[/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.map]
Error 1
| make[2]: *** Waiting for unfinished jobs
| make[2]: Leaving directory
`/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/eglibc-2_16/libc/elf'
| make[1]: *** [elf/subdir_lib] Error 2
| make[1]: Leaving directory
`/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/eglibc-2_16/libc'
Maybe it's because
http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f
is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic not
OEBasicHash here).
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Toolchain rework, call for testing
On Tue, Aug 21, 2012 at 01:00:03PM +0100, Phil Blundell wrote: > On Tue, 2012-08-21 at 13:55 +0200, Marcin Juszkiewicz wrote: > > W dniu 17.08.2012 06:47, Khem Raj pisze: > > > Hi All > > > > > > Recently glibc build has been simplified upstream. It has dropped the > > > dependency on libgcc_s and libgcc_eh for building glibc itself. > > > This means that we can simplify our toolchain bootstrap a bit by > > > dropping 1 of the 3 cross gcc build stages. We do not need > > > gcc-cross-intermediate anymore. > > > > Please adapt also toolchain-layer in meta-oe for those stuck with gcc 4.6. > > Why is it that gcc-4.7 doesn't work for those people? At least it should parse for people who have toolchain-layer enabled.. Parsing recipes...ERROR: ParseError at /OE/shr-core/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-intermediate_4.6.bb:2: Could not include required file recipes-devtools/gcc/gcc-cross-intermediate.inc Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Toolchain rework, call for testing
On Tue, 2012-08-21 at 13:55 +0200, Marcin Juszkiewicz wrote: > W dniu 17.08.2012 06:47, Khem Raj pisze: > > Hi All > > > > Recently glibc build has been simplified upstream. It has dropped the > > dependency on libgcc_s and libgcc_eh for building glibc itself. > > This means that we can simplify our toolchain bootstrap a bit by > > dropping 1 of the 3 cross gcc build stages. We do not need > > gcc-cross-intermediate anymore. > > Please adapt also toolchain-layer in meta-oe for those stuck with gcc 4.6. Why is it that gcc-4.7 doesn't work for those people? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Toolchain rework, call for testing
W dniu 17.08.2012 06:47, Khem Raj pisze: > Hi All > > Recently glibc build has been simplified upstream. It has dropped the > dependency on libgcc_s and libgcc_eh for building glibc itself. > This means that we can simplify our toolchain bootstrap a bit by > dropping 1 of the 3 cross gcc build stages. We do not need > gcc-cross-intermediate anymore. Please adapt also toolchain-layer in meta-oe for those stuck with gcc 4.6. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] grub-efi-native: Update to version 2.00
Added -Wno-unused-result because of a read() with no result, and causing
error due to -Werror
Updated grub recipe because of a patch name change
Removed unnecessary patches (merged upstream).
Signed-off-by: Radu Moisan
---
...2man.patch => grub-2.00-disable-help2man.patch} | 117 +++-
...grub-2.00-fix-enable_execute_stack-check.patch} |8 +-
...ix.patch => grub-2.00-fpmath-sse-387-fix.patch} |0
.../grub/files/grub-no-unused-result.patch | 18 +++
...-efi-native_1.99.bb => grub-efi-native_2.00.bb} | 18 ++-
meta/recipes-bsp/grub/grub_2.00.bb |2 +-
6 files changed, 47 insertions(+), 116 deletions(-)
rename meta/recipes-bsp/grub/files/{grub-1.99-disable-help2man.patch =>
grub-2.00-disable-help2man.patch} (54%)
rename
meta/recipes-bsp/grub/files/{grub-1.99-fix-enable_execute_stack-check.patch =>
grub-2.00-fix-enable_execute_stack-check.patch} (92%)
rename meta/recipes-bsp/grub/files/{grub-1.99-fpmath-sse-387-fix.patch =>
grub-2.00-fpmath-sse-387-fix.patch} (100%)
create mode 100644 meta/recipes-bsp/grub/files/grub-no-unused-result.patch
rename meta/recipes-bsp/grub/{grub-efi-native_1.99.bb =>
grub-efi-native_2.00.bb} (80%)
diff --git a/meta/recipes-bsp/grub/files/grub-1.99-disable-help2man.patch
b/meta/recipes-bsp/grub/files/grub-2.00-disable-help2man.patch
similarity index 54%
rename from meta/recipes-bsp/grub/files/grub-1.99-disable-help2man.patch
rename to meta/recipes-bsp/grub/files/grub-2.00-disable-help2man.patch
index 3ffefdc..a2e42c2 100644
--- a/meta/recipes-bsp/grub/files/grub-1.99-disable-help2man.patch
+++ b/meta/recipes-bsp/grub/files/grub-2.00-disable-help2man.patch
@@ -10,14 +10,14 @@ unnecessarily.
Signed-off-by: Darren Hart
-Index: grub-1.99/configure.ac
+Index: grub-2.00/configure.ac
===
grub-1.99.orig/configure.ac
-+++ grub-1.99/configure.ac
-@@ -275,11 +275,12 @@ if test x$grub_cv_apple_cc = xyes ; then
- HOST_CFLAGS="$HOST_CFLAGS -fnested-functions"
+--- grub-2.00.orig/configure.ac
grub-2.00/configure.ac
+@@ -310,11 +310,12 @@ if test x$USE_NLS = xno; then
+ HOST_CFLAGS="$HOST_CFLAGS -fno-builtin-gettext"
fi
-
+
-if test "x$cross_compiling" = xyes; then
- AC_MSG_WARN([cannot generate manual pages while cross compiling])
-else
@@ -32,11 +32,11 @@ Index: grub-1.99/configure.ac
# Check for functions and headers.
AC_CHECK_FUNCS(posix_memalign memalign asprintf vasprintf getextmntent)
-Index: grub-1.99/configure
+Index: grub-2.00/configure
===
grub-1.99.orig/configure
-+++ grub-1.99/configure
-@@ -1172,7 +1172,6 @@ GL_COND_LIBTOOL_FALSE
+--- grub-2.00.orig/configure
grub-2.00/configure
+@@ -1215,7 +1215,6 @@ GL_COND_LIBTOOL_FALSE
GL_COND_LIBTOOL_TRUE
BUILD_CC
LIBUTIL
@@ -44,15 +44,7 @@ Index: grub-1.99/configure
POSUB
LTLIBINTL
LIBINTL
-@@ -1204,6 +1203,7 @@ LEXLIB
- am__fastdepCC_FALSE
- am__fastdepCC_TRUE
- CCDEPMODE
-+am__nodep
- AMDEPBACKSLASH
- AMDEP_FALSE
- AMDEP_TRUE
-@@ -3011,7 +3011,6 @@ _ACEOF
+@@ -3069,7 +3068,6 @@ _ACEOF
# Let the site file select an alternate cache file if it wants to.
# Prefer an explicitly selected file to automatically selected ones.
ac_site_file1=NONE
@@ -60,7 +52,7 @@ Index: grub-1.99/configure
if test -n "$CONFIG_SITE"; then
# We do not want a PATH search for config.site.
case $CONFIG_SITE in #((
-@@ -3019,14 +3018,8 @@ if test -n "$CONFIG_SITE"; then
+@@ -3077,14 +3075,8 @@ if test -n "$CONFIG_SITE"; then
*/*) ac_site_file1=$CONFIG_SITE;;
*) ac_site_file1=./$CONFIG_SITE;;
esac
@@ -76,7 +68,7 @@ Index: grub-1.99/configure
do
test "x$ac_site_file" = xNONE && continue
if test /dev/null != "$ac_site_file" && test -r "$ac_site_file"; then
-@@ -3313,8 +3306,9 @@ case $target_os in *\ *) target_os=`echo
+@@ -3371,8 +3363,9 @@ case $target_os in *\ *) target_os=`echo
# The aliases save the names the user supplied, while $host etc.
# will get canonicalized.
test -n "$target_alias" &&
@@ -88,83 +80,8 @@ Index: grub-1.99/configure
program_prefix=${target_alias}-
am__api_version='1.11'
-@@ -3786,11 +3780,11 @@ MAKEINFO=${MAKEINFO-"${am_missing_run}ma
-
- # We need awk for the "check" target. The system "awk" is bad on
- # some platforms.
--# Always define AMTAR for backward compatibility.
--
--AMTAR=${AMTAR-"${am_missing_run}tar"}
-+# Always define AMTAR for backward compatibility. Yes, it's still used
-+# in the wild :-( We should find a proper way to deprecate it ...
-+AMTAR='$${TAR-tar}'
-
--am__tar='${AMTAR} chof - "$$tardir"'; am__untar='${AMTAR} xf -'
-+am__tar='$${TAR-tar} chof - "$$tardir"' am__untar='$${TAR-tar} xf -'
-
-
-
-@@ -4256,6 +4250,7 @@ fi
- if test "x$enable_dependency_tracking" != xno; then
- am_depcomp="$ac_aux_dir/depcomp"
- AMDEPBACKSLASH='\'
-+ am__nodep='_no'
- fi
- if test "x$enable_dependency_tracking" != xno; then
[OE-core] [PATCH v2] grub-efi-native: Update to version 2.00
Added -Wno-unused-result because of a read() with no result, and causing
error due to -Werror
Updated grub recipe because of a patch name change
Removed unnecessary patches (merged upstream).
Signed-off-by: Radu Moisan
---
...2man.patch => grub-2.00-disable-help2man.patch} | 117 +++-
...grub-2.00-fix-enable_execute_stack-check.patch} |8 +-
...ix.patch => grub-2.00-fpmath-sse-387-fix.patch} |0
.../grub/files/grub-no-unused-result.patch | 13 +++
...-efi-native_1.99.bb => grub-efi-native_2.00.bb} | 18 ++-
meta/recipes-bsp/grub/grub_2.00.bb |2 +-
6 files changed, 42 insertions(+), 116 deletions(-)
rename meta/recipes-bsp/grub/files/{grub-1.99-disable-help2man.patch =>
grub-2.00-disable-help2man.patch} (54%)
rename
meta/recipes-bsp/grub/files/{grub-1.99-fix-enable_execute_stack-check.patch =>
grub-2.00-fix-enable_execute_stack-check.patch} (92%)
rename meta/recipes-bsp/grub/files/{grub-1.99-fpmath-sse-387-fix.patch =>
grub-2.00-fpmath-sse-387-fix.patch} (100%)
create mode 100644 meta/recipes-bsp/grub/files/grub-no-unused-result.patch
rename meta/recipes-bsp/grub/{grub-efi-native_1.99.bb =>
grub-efi-native_2.00.bb} (80%)
diff --git a/meta/recipes-bsp/grub/files/grub-1.99-disable-help2man.patch
b/meta/recipes-bsp/grub/files/grub-2.00-disable-help2man.patch
similarity index 54%
rename from meta/recipes-bsp/grub/files/grub-1.99-disable-help2man.patch
rename to meta/recipes-bsp/grub/files/grub-2.00-disable-help2man.patch
index 3ffefdc..a2e42c2 100644
--- a/meta/recipes-bsp/grub/files/grub-1.99-disable-help2man.patch
+++ b/meta/recipes-bsp/grub/files/grub-2.00-disable-help2man.patch
@@ -10,14 +10,14 @@ unnecessarily.
Signed-off-by: Darren Hart
-Index: grub-1.99/configure.ac
+Index: grub-2.00/configure.ac
===
grub-1.99.orig/configure.ac
-+++ grub-1.99/configure.ac
-@@ -275,11 +275,12 @@ if test x$grub_cv_apple_cc = xyes ; then
- HOST_CFLAGS="$HOST_CFLAGS -fnested-functions"
+--- grub-2.00.orig/configure.ac
grub-2.00/configure.ac
+@@ -310,11 +310,12 @@ if test x$USE_NLS = xno; then
+ HOST_CFLAGS="$HOST_CFLAGS -fno-builtin-gettext"
fi
-
+
-if test "x$cross_compiling" = xyes; then
- AC_MSG_WARN([cannot generate manual pages while cross compiling])
-else
@@ -32,11 +32,11 @@ Index: grub-1.99/configure.ac
# Check for functions and headers.
AC_CHECK_FUNCS(posix_memalign memalign asprintf vasprintf getextmntent)
-Index: grub-1.99/configure
+Index: grub-2.00/configure
===
grub-1.99.orig/configure
-+++ grub-1.99/configure
-@@ -1172,7 +1172,6 @@ GL_COND_LIBTOOL_FALSE
+--- grub-2.00.orig/configure
grub-2.00/configure
+@@ -1215,7 +1215,6 @@ GL_COND_LIBTOOL_FALSE
GL_COND_LIBTOOL_TRUE
BUILD_CC
LIBUTIL
@@ -44,15 +44,7 @@ Index: grub-1.99/configure
POSUB
LTLIBINTL
LIBINTL
-@@ -1204,6 +1203,7 @@ LEXLIB
- am__fastdepCC_FALSE
- am__fastdepCC_TRUE
- CCDEPMODE
-+am__nodep
- AMDEPBACKSLASH
- AMDEP_FALSE
- AMDEP_TRUE
-@@ -3011,7 +3011,6 @@ _ACEOF
+@@ -3069,7 +3068,6 @@ _ACEOF
# Let the site file select an alternate cache file if it wants to.
# Prefer an explicitly selected file to automatically selected ones.
ac_site_file1=NONE
@@ -60,7 +52,7 @@ Index: grub-1.99/configure
if test -n "$CONFIG_SITE"; then
# We do not want a PATH search for config.site.
case $CONFIG_SITE in #((
-@@ -3019,14 +3018,8 @@ if test -n "$CONFIG_SITE"; then
+@@ -3077,14 +3075,8 @@ if test -n "$CONFIG_SITE"; then
*/*) ac_site_file1=$CONFIG_SITE;;
*) ac_site_file1=./$CONFIG_SITE;;
esac
@@ -76,7 +68,7 @@ Index: grub-1.99/configure
do
test "x$ac_site_file" = xNONE && continue
if test /dev/null != "$ac_site_file" && test -r "$ac_site_file"; then
-@@ -3313,8 +3306,9 @@ case $target_os in *\ *) target_os=`echo
+@@ -3371,8 +3363,9 @@ case $target_os in *\ *) target_os=`echo
# The aliases save the names the user supplied, while $host etc.
# will get canonicalized.
test -n "$target_alias" &&
@@ -88,83 +80,8 @@ Index: grub-1.99/configure
program_prefix=${target_alias}-
am__api_version='1.11'
-@@ -3786,11 +3780,11 @@ MAKEINFO=${MAKEINFO-"${am_missing_run}ma
-
- # We need awk for the "check" target. The system "awk" is bad on
- # some platforms.
--# Always define AMTAR for backward compatibility.
--
--AMTAR=${AMTAR-"${am_missing_run}tar"}
-+# Always define AMTAR for backward compatibility. Yes, it's still used
-+# in the wild :-( We should find a proper way to deprecate it ...
-+AMTAR='$${TAR-tar}'
-
--am__tar='${AMTAR} chof - "$$tardir"'; am__untar='${AMTAR} xf -'
-+am__tar='$${TAR-tar} chof - "$$tardir"' am__untar='$${TAR-tar} xf -'
-
-
-
-@@ -4256,6 +4250,7 @@ fi
- if test "x$enable_dependency_tracking" != xno; then
- am_depcomp="$ac_aux_dir/depcomp"
- AMDEPBACKSLASH='\'
-+ am__nodep='_no'
- fi
- if test "x$enable_dependency_tracking" != xno; then
[OE-core] [PATCH v2] grub: Update to upstream stable 2.00
Removed unnecessary patches (merged upstream).
Signed-off-by: Radu Moisan
---
...rub-1.99-gcc-4.7.0-strict-aliasing-errors.patch | 147
...b-1.99-gcc-4.7.0-uninitialized-var-errors.patch | 41 -
.../grub/files/grub-1.99-gcc-4.7.0.patch | 34
.../files/grub-1.99_fix_for_automake_1.11.2.patch | 179
.../grub/grub-1.99/grub-1.99-lazy_stat.patch | 64 ---
.../grub/{grub-1.99 => grub-2.00}/40_custom|0
.../{grub-1.99 => grub-2.00}/grub-install.in.patch |0
.../{grub-1.99 => grub-2.00}/remove-gets.patch |0
.../grub/{grub_1.99.bb => grub_2.00.bb}| 16 +-
9 files changed, 7 insertions(+), 474 deletions(-)
delete mode 100644
meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0-strict-aliasing-errors.patch
delete mode 100644
meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0-uninitialized-var-errors.patch
delete mode 100644 meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0.patch
delete mode 100644
meta/recipes-bsp/grub/files/grub-1.99_fix_for_automake_1.11.2.patch
delete mode 100644 meta/recipes-bsp/grub/grub-1.99/grub-1.99-lazy_stat.patch
rename meta/recipes-bsp/grub/{grub-1.99 => grub-2.00}/40_custom (100%)
rename meta/recipes-bsp/grub/{grub-1.99 => grub-2.00}/grub-install.in.patch
(100%)
rename meta/recipes-bsp/grub/{grub-1.99 => grub-2.00}/remove-gets.patch (100%)
rename meta/recipes-bsp/grub/{grub_1.99.bb => grub_2.00.bb} (69%)
diff --git
a/meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0-strict-aliasing-errors.patch
b/meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0-strict-aliasing-errors.patch
deleted file mode 100644
index 9d81050..000
---
a/meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0-strict-aliasing-errors.patch
+++ /dev/null
@@ -1,147 +0,0 @@
-Upstream-Status: Pending
-
-This patch fixes these strick-aliasing errors with gcc 4.7
-
-
-| gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -I../include -I../include
-DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=I386_EFI -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/include -DGRUB_FILE=\"fs/zfs/zfs.c\" -I.
-I. -I.. -I.. -I../include -I../include
-isystem/home/nitin/builds/build0/tmp/sysroots/x86_64-linux/usr/include -O2
-pipe -g -feliminate-unused-debug-types -Wall -W -Wshadow -Wpointer-arith
-Wmissing-prototypes -Wundef -Wstrict-prototypes -g -falign-jumps=1
-falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow
-fno-dwarf2-cfi-asm -m32 -fno-stack-protector -mno-stack-arg-probe -Werror
-Wno-trampolines -ffreestanding
-isystem/home/nitin/builds/build0/tmp/sysroots/x86_64-linux/usr/include -O2
-pipe -c -o fs/zfs/zfs_module-zfs.o `test -f 'fs/zfs/zfs.c' || echo
'./'`fs/zfs/zfs.c
-| fs/zfs/zfs.c: In function 'get_filesystem_dnode':
-| fs/zfs/zfs.c:1449:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:1449:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c: In function 'make_mdn':
-| fs/zfs/zfs.c:1478:3: error: dereferencing type-punned pointer will break
strict-alERROR: Function failed: do_compile (see
/home/nitin/builds/build0/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r7/temp/log.do_compile.9293
for further information)
-| iasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c: In function 'dnode_get_fullpath':
-| fs/zfs/zfs.c:1554:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:1554:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:1571:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:1571:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c: In function 'grub_zfs_open':
-| fs/zfs/zfs.c:2234:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:2234:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c: In function 'fill_fs_info':
-| fs/zfs/zfs.c:2362:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:2362:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:2395:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:2395:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c: In function 'iterate_zap':
-| fs/zfs/zfs.c:2420:5: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
-| fs/zfs/zfs.c:2420:5: error: dereferencing type-punned pointe
Re: [OE-core] [PATCH] [Multilib] Complete recipe enablement
On Tue, 2012-08-21 at 11:40 +0300, Marinescu, Bogdan A wrote: > Resending. > > On Thu, Aug 2, 2012 at 10:49 AM, Bogdan Marinescu > wrote: > RP: The list of recipes in multilib.conf needs to go away and > we need > to just be able to extend all recipes with the multilib class. > Tested by building and running lib32-core-image-sato-sdk. > > [YOCTO #1563] > > Signed-off-by: Bogdan Marinescu > --- > meta/classes/multilib.bbclass |3 + > meta/conf/multilib.conf | 745 Already merged: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c4a7517f8ae6e176a0b8e59b1176cf65bb45aa78 As a sidenote, please put a prefix to the subject line showing which area the patch touches (missing a multilib: in this case) as per the commit message guidelines. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kmod-native_git.bb: fix builds for hosts with older libc
On Mon, 2012-08-20 at 13:49 -0500, Matthew McClintock wrote:
> kmod will fail to build with the following error because O_CLOEXEC is
> not defined:
>
> | libkmod/libkmod-module.c: In function 'kmod_module_get_initstate':
> | libkmod/libkmod-module.c:1640: error: 'O_CLOEXEC' undeclared (first use in
> this function)
> | libkmod/libkmod-module.c:1640: error: (Each undeclared identifier is
> reported only once
> | libkmod/libkmod-module.c:1640: error: for each function it appears in.)
> | libkmod/libkmod-module.c: In function 'kmod_module_get_refcnt':
> | libkmod/libkmod-module.c:1754: error: 'O_CLOEXEC' undeclared (first use in
> this function)
> | libkmod/libkmod-module.c: In function 'kmod_module_get_sections':
> | libkmod/libkmod-module.c:1913: error: 'O_CLOEXEC' undeclared (first use in
> this function)
> | libkmod/libkmod-file.c: In function 'kmod_file_open':
> | libkmod/libkmod-file.c:282: error: 'O_CLOEXEC' undeclared (first use in
> this function)
> | libkmod/libkmod-file.c:282: error: (Each undeclared identifier is reported
> only once
> | libkmod/libkmod-file.c:282: error: for each function it appears in.)
>
> Since we are only using kmod-native for depmod, and it's a non-threaded
> user of this libary being built this should be safe to override O_CLOEXEC.
>
> Keep in mind this is ONLY effecting the native builds and not what is
> being shipped in the root file system.
>
> Signed-off-by: Matthew McClintock
> ---
> meta/recipes-kernel/kmod/kmod-native_git.bb |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/kmod/kmod-native_git.bb
> b/meta/recipes-kernel/kmod/kmod-native_git.bb
> index 96de8b8..3c5e3c3 100644
> --- a/meta/recipes-kernel/kmod/kmod-native_git.bb
> +++ b/meta/recipes-kernel/kmod/kmod-native_git.bb
> @@ -4,7 +4,7 @@
> require kmod.inc
> inherit native
>
> -PR = "${INC_PR}.0"
> +PR = "${INC_PR}.1"
>
> do_install_append (){
> for tool in depmod insmod lsmod modinfo modprobe rmmod
> @@ -12,3 +12,9 @@ do_install_append (){
> ln -s kmod ${D}${bindir}/$tool
> done
> }
> +
> +do_compile_append (){
> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
> + fi
> +}
A compile append would execute after the compile. Isn't this after the
point you need the change?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python-dbus: updated to 1.1.1
On Tue, 2012-08-21 at 11:40 +0300, Marinescu, Bogdan A wrote:
> Resending.
>
> On Wed, Aug 1, 2012 at 6:16 PM, Bogdan Marinescu
> wrote:
> Signed-off-by: Bogdan Marinescu
> ---
> .../{python-dbus_1.1.0.bb => python-dbus_1.1.1.bb} |4
> ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-devtools/python/{python-dbus_1.1.0.bb =>
> python-dbus_1.1.1.bb} (83%)
>
> diff --git a/meta/recipes-devtools/python/python-dbus_1.1.0.bb
> b/meta/recipes-devtools/python/python-dbus_1.1.1.bb
> similarity index 83%
> rename from meta/recipes-devtools/python/python-dbus_1.1.0.bb
> rename to meta/recipes-devtools/python/python-dbus_1.1.1.bb
> index a10fda3..51d5bc2 100644
> --- a/meta/recipes-devtools/python/python-dbus_1.1.0.bb
> +++ b/meta/recipes-devtools/python/python-dbus_1.1.1.bb
> @@ -8,8 +8,8 @@ PR = "r0"
>
> SRC_URI =
>
> "http://dbus.freedesktop.org/releases/dbus-python/dbus-python-${PV}.tar.gz";
>
> -SRC_URI[md5sum] = "41a4595fd92eeebd632623af0bd7"
> -SRC_URI[sha256sum] =
> "2dc30b53cdb2e20f8d0265af3be878e9da68745cf9ccc72f75de869094c4fc60"
> +SRC_URI[md5sum] = "742c7432ad0f7c3f98291d58fa2e35dc"
> +SRC_URI[sha256sum] =
> "8917ca4fb8f4d693aee18d200cbad166b2c938dfb88c03bb4ab3d90a7c915e88"
> S = "${WORKDIR}/dbus-python-${PV}"
This is in master:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=516ce2fc8d2a6a330e8662921929aaf947daecb1
?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] scripts/combo-layer: checkout branch in update when pull is disabled
If the user selects not to pull the component repos, at least ensure
that the correct branch is checked out before proceeding.
Signed-off-by: Paul Eggleton
---
scripts/combo-layer |4
1 file changed, 4 insertions(+)
diff --git a/scripts/combo-layer b/scripts/combo-layer
index 448fe71..6134e81 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -356,6 +356,10 @@ def action_update(conf, args):
branch = repo.get('branch', "master")
repo_patch_dir = os.path.join(os.getcwd(), patch_dir, name)
+if conf.nopull:
+# Need to do this here as we didn't call action_pull that would do
it otherwise
+runcmd("git checkout %s" % branch, ldir)
+
# Step 2: generate the patch list and store to patch dir
logger.info("Generating patches from %s..." % name)
if dest_dir != ".":
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [discussion] perf: specify SLANG_INC dir for perf
On Tue, 2012-08-21 at 10:51 +0200, Henning Heinold wrote:
> On Tue, Aug 21, 2012 at 01:08:25PM +0800, Liang Li wrote:
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -190,6 +190,9 @@ kernel_do_install() {
> > for entry in $bin_files; do
> > rm -f $kerneldir/$entry
> > done
> > +
> > + # Fix SLNAG_INC for slang.h
> > + sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g'
> > $kerneldir/tools/perf/Makefile
> Hm,
>
> is this "-I=" a new special feature of gcc?
>
> -I/usr/include/slang
> -I=/usr/include/slang
It means the path is relative to any sysroot. It wasn't around for the
first implementations of sysroot but came shortly thereafter. As long as
its gcc 3.4 onwards it should be fine iirc.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/32] denzil pull request1
On Mon, 2012-08-13 at 14:14 -0700, Scott Garman wrote: > Hello, > > This is my first pull request for denzil since the 1.2.1 release was made. > > It has been run through the autobuilder, which is having some issues with > running sanity tests and buildhistory, so if the build succeeded for > everything except for those steps, I note it as "Green with known AB > issues" below. > > Note that these tests were run with a poky-based branch. > [...] > > The following changes since commit 741146fa90f28f7ce8d82ee7f7e254872d519724: > > gconf.bbclass: don't register schemas in the install stage (2012-06-29 > 15:03:01 +0100) > > are available in the git repository at: > > git://git.openembedded.org/openembedded-core-contrib > sgarman/denzil-next-pull1 > > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgarman/denzil-next-pull1 Merged to denzil. Thanks for putting this together. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [discussion] perf: specify SLANG_INC dir for perf
On 2012-08-21 16:51, Henning Heinold wrote:
> On Tue, Aug 21, 2012 at 01:08:25PM +0800, Liang Li wrote:
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -190,6 +190,9 @@ kernel_do_install() {
> > for entry in $bin_files; do
> > rm -f $kerneldir/$entry
> > done
> > +
> > + # Fix SLNAG_INC for slang.h
> > + sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g'
> > $kerneldir/tools/perf/Makefile
> Hm,
>
> is this "-I=" a new special feature of gcc?
>
> -I/usr/include/slang
> -I=/usr/include/slang
>
Not something new/special feature of gcc, should be as old as
--sysroot, maybe more than 10 years elder I guess.
Cheers,
Liang Li
> Bye Henning
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] RFC: OE-Core task rework
On Tuesday 21 August 2012 09:49:37 Paul Eggleton wrote: > The main concern with LSB is that we have something called task-basic, > which seems to be intended for LSB but does not state as much, and I know > at least one person has tried to use it and then been a little puzzled as > to why rpm has been pulled in when ipk packaging has been selected. Just > naming some of these tasks more appropriately would help avoid such > situations. In the specific case of task-basic there may be a case for > creating a similar but not LSB-focused task that pulls in real shell > utilities in preference to the light versions provided by busybox. Ugh, sorry. I meant task-core-basic here - not to be confused with task-basic in meta-oe [1]. Cheers, Paul [1] http://www.openembedded.org/wiki/Meta-oe_tasks -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [discussion] perf: specify SLANG_INC dir for perf
On Tue, Aug 21, 2012 at 01:08:25PM +0800, Liang Li wrote:
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -190,6 +190,9 @@ kernel_do_install() {
> for entry in $bin_files; do
> rm -f $kerneldir/$entry
> done
> +
> + # Fix SLNAG_INC for slang.h
> + sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g'
> $kerneldir/tools/perf/Makefile
Hm,
is this "-I=" a new special feature of gcc?
-I/usr/include/slang
-I=/usr/include/slang
Bye Henning
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] RFC: OE-Core task rework
On Monday 20 August 2012 15:45:07 Mark Hatle wrote: > > 1) Do we rename "task" to something a little more understandable to the > > uninitiated, such as "package group"? The word "task" is already used in a > > much more natural sense within bitbake as a unit of work. Historically I > > believe we picked up this term from Debian but I'm not aware of > > significant use by other mainstream distributions. > > "group" or "packagegroup" or "package-group" is my suggestion for the > existing 'task' recipes. From what I've seen, it should be a rename > opportunity -- we can even provide/rprovide the old names Indeed, and I think we would for compatibility purposes. > > 2) Look at the existing tasks and: > > * evaluate their usefulness > > * remove any that are obsolete > > * adjust existing contents if needed > > * look for useful groups of packages that might be added > > > > We need to pay particular attention to task-core-boot and task-base as > > these> > > are pulled in by default in any image that inherits from > > core-image.bbclass - if these are not generally working for people that > > are creating their own images, we need to change them such that they are. > > During the pre-oe-core Yocto Project development, a design was generated to > roughly group the packages into functional areas. For the most part, this > design (as well as legacy elements) still exist. > > I think the boot, base and others need to be evaluated for usefulness... but > my feeling is most of them are close to being correct. I think so as well. We may be pulling in one or two packages unconditionally where they should be optional (e.g. modutils-initscripts?) but most of it is pretty sensible. > > * Try to make each task have a reasonable name - there are some current > > uses of "core" and "base" that don't actually convey any meaning; LSB > > specific tasks should be named as such, etc. > > Yup, there is a logical grouping for the lsb specific tasks, as for others. > The naming needs to be made clear as to why it's there, and what it > represents. Same with the summary and descriptions -- they should list the > functionality provided by this group of components. The main concern with LSB is that we have something called task-basic, which seems to be intended for LSB but does not state as much, and I know at least one person has tried to use it and then been a little puzzled as to why rpm has been pulled in when ipk packaging has been selected. Just naming some of these tasks more appropriately would help avoid such situations. In the specific case of task-basic there may be a case for creating a similar but not LSB-focused task that pulls in real shell utilities in preference to the light versions provided by busybox. > > 4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which > > converts some IMAGE_FEATURES into the addition of tasks to be installed > > (see classes/core-image.bbclass). At the very least we should probably > > rename this if we rename tasks to package groups, and there's a question > > as to how IMAGE_FEATURES scales - should every task be represented in > > there or only a select list? Would we be better off not trying to bring > > any tasks in via IMAGE_FEATURES at all and mostly leave that to control > > post-processing (e.g. package-management, debug-tweaks, etc.)? > > I'd certainly prefer that images were limited to selecting software from > task (group) recipes only, and not providing their own. An image should be > able to change the selection based on an "image feature" or similar > configuration, but the underlying tasks/groups, recipes, etc should all be > 'generic' to a given distribution configuration. The first part seems reasonable to me; but I'm still short of an answer as to what to do with the existing IMAGE_FEATURES code as mentioned above. At the moment aside from the special features such as debug-tweaks, these are just a thin layer on top of task recipes which doesn't add very much at all other than extra maintenance. > I think if you go through the images today, a lot of that stuff is either > old, or could be simplified by creating appropriate tasks/groups. OK, that's a good point. I have another task on my list to clean up our image recipes and that would be a good segue into that. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][RFC] coreutils: Upgrade to upstream version 8.17
Your new patch needs a header, explaining why, and adding Upstream-Status and Signed-off-by tags. I meant this only as an RFC, to get feedback for my patch, from a functional point of view, it is not intended to be the final patch. I have a Signed-off-by tag, are you referring to something else? Can you give me more details about Upstream-Status? I've google'd this problem for a bit but could not find an existing patch for it, nor a bug filled for this matter. Since I don't know yet if what I'm fixing it's really a bug (or a misconfiguration on my side) I send this RFC to get a hold of whether I'm on the good track here or not. If this patch turns out to be valid, I'll get in touch with the guys from coreutils' mailing lists, and try to push it upstream. Radu, For patches included in a given recipe we also have Signed-off-by as well as the Upstream-Status tag as defined by: http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Please review this again. Soul, I understood your point, and in the *actual* patch I will update the Sign-off-by and a short description, and an Upstream Status. However, I reviewed again Commit_Patch_Message_Guidelines and there is nothing in there mentioned about RFCs. This is an RFC, and it was intended to get a quick feedback from people more familiar/experienced with coreutils/autotools. I need feedback about the functional change of this patch. In my first reply I described as extensively as I could my problem and my question. As far as the RFCs go, how long should I wait on an RFC? It's been more then a few days and nobody commented. Would it be appropriate to assume that if nobody had any comments, the patch is valid? Radu ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python-dbus: updated to 1.1.1
Resending.
On Wed, Aug 1, 2012 at 6:16 PM, Bogdan Marinescu <
bogdan.a.marine...@intel.com> wrote:
> Signed-off-by: Bogdan Marinescu
> ---
> .../{python-dbus_1.1.0.bb => python-dbus_1.1.1.bb} |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-devtools/python/{python-dbus_1.1.0.bb =>
> python-dbus_1.1.1.bb} (83%)
>
> diff --git
> a/meta/recipes-devtools/python/python-dbus_1.1.0.bbb/meta/recipes-devtools/python/
> python-dbus_1.1.1.bb
> similarity index 83%
> rename from meta/recipes-devtools/python/python-dbus_1.1.0.bb
> rename to meta/recipes-devtools/python/python-dbus_1.1.1.bb
> index a10fda3..51d5bc2 100644
> --- a/meta/recipes-devtools/python/python-dbus_1.1.0.bb
> +++ b/meta/recipes-devtools/python/python-dbus_1.1.1.bb
> @@ -8,8 +8,8 @@ PR = "r0"
>
> SRC_URI = "
> http://dbus.freedesktop.org/releases/dbus-python/dbus-python-${PV}.tar.gz";
>
> -SRC_URI[md5sum] = "41a4595fd92eeebd632623af0bd7"
> -SRC_URI[sha256sum] =
> "2dc30b53cdb2e20f8d0265af3be878e9da68745cf9ccc72f75de869094c4fc60"
> +SRC_URI[md5sum] = "742c7432ad0f7c3f98291d58fa2e35dc"
> +SRC_URI[sha256sum] =
> "8917ca4fb8f4d693aee18d200cbad166b2c938dfb88c03bb4ab3d90a7c915e88"
> S = "${WORKDIR}/dbus-python-${PV}"
>
> inherit distutils-base autotools pkgconfig
> --
> 1.7.9.5
>
>
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] busybox: Upgrade to upstream 1.20.2
Updated defconfig file from generated .config
Disabled CONFIG_LSOF,CONFIG_CROSS_COMPILER_PREFIX, and CONFIG_EXTRA_CFLAGS
for backwards compatibility.
Added busybox-1.20.2-kernel_ver.patch from upstream.
Signed-off-by: Radu Moisan
---
.../poky-tiny/defconfig|0
...box_1.19.4.bbappend => busybox_1.20.2.bbappend} |0
.../B921600.patch |0
.../busybox-1.20.2/busybox-1.20.2-kernel_ver.patch | 25 +
.../busybox-appletlib-dependency.patch |0
.../busybox-mkfs-minix-tests_bigendian.patch |0
.../busybox-udhcpc-no_deconfig.patch | 37 +--
.../{busybox-1.19.4 => busybox-1.20.2}/defconfig | 39 +---
.../fix-for-spurious-testsuite-failure.patch |0
.../get_header_tar.patch |0
.../run-parts.in.usr-bin.patch |0
.../sys_resource.patch |0
.../watch.in.usr-bin.patch |0
.../wget_dl_dir_fix.patch |0
.../{busybox_1.19.4.bb => busybox_1.20.2.bb} |9 +++--
15 files changed, 72 insertions(+), 38 deletions(-)
rename meta-yocto/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/poky-tiny/defconfig (100%)
rename meta-yocto/recipes-core/busybox/{busybox_1.19.4.bbappend =>
busybox_1.20.2.bbappend} (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/B921600.patch (100%)
create mode 100644
meta/recipes-core/busybox/busybox-1.20.2/busybox-1.20.2-kernel_ver.patch
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/busybox-appletlib-dependency.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/busybox-mkfs-minix-tests_bigendian.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/busybox-udhcpc-no_deconfig.patch (78%)
rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/defconfig
(98%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/fix-for-spurious-testsuite-failure.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/get_header_tar.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/run-parts.in.usr-bin.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/sys_resource.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/watch.in.usr-bin.patch (100%)
rename meta/recipes-core/busybox/{busybox-1.19.4 =>
busybox-1.20.2}/wget_dl_dir_fix.patch (100%)
rename meta/recipes-core/busybox/{busybox_1.19.4.bb => busybox_1.20.2.bb} (79%)
diff --git a/meta-yocto/recipes-core/busybox/busybox-1.19.4/poky-tiny/defconfig
b/meta-yocto/recipes-core/busybox/busybox-1.20.2/poky-tiny/defconfig
similarity index 100%
rename from meta-yocto/recipes-core/busybox/busybox-1.19.4/poky-tiny/defconfig
rename to meta-yocto/recipes-core/busybox/busybox-1.20.2/poky-tiny/defconfig
diff --git a/meta-yocto/recipes-core/busybox/busybox_1.19.4.bbappend
b/meta-yocto/recipes-core/busybox/busybox_1.20.2.bbappend
similarity index 100%
rename from meta-yocto/recipes-core/busybox/busybox_1.19.4.bbappend
rename to meta-yocto/recipes-core/busybox/busybox_1.20.2.bbappend
diff --git a/meta/recipes-core/busybox/busybox-1.19.4/B921600.patch
b/meta/recipes-core/busybox/busybox-1.20.2/B921600.patch
similarity index 100%
rename from meta/recipes-core/busybox/busybox-1.19.4/B921600.patch
rename to meta/recipes-core/busybox/busybox-1.20.2/B921600.patch
diff --git
a/meta/recipes-core/busybox/busybox-1.20.2/busybox-1.20.2-kernel_ver.patch
b/meta/recipes-core/busybox/busybox-1.20.2/busybox-1.20.2-kernel_ver.patch
new file mode 100644
index 000..456fb08
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox-1.20.2/busybox-1.20.2-kernel_ver.patch
@@ -0,0 +1,25 @@
+--- busybox-1.20.2/libbb/kernel_version.c
busybox-1.20.2-kernel_ver/libbb/kernel_version.c
+@@ -20,18 +20,15 @@
+ int FAST_FUNC get_linux_version_code(void)
+ {
+ struct utsname name;
+- char *s;
++ char *s, *t;
+ int i, r;
+
+- if (uname(&name) == -1) {
+- bb_perror_msg("can't get system information");
+- return 0;
+- }
+-
++ uname(&name); /* never fails */
+ s = name.release;
+ r = 0;
+ for (i = 0; i < 3; i++) {
+- r = r * 256 + atoi(strtok(s, "."));
++ t = strtok(s, ".");
++ r = r * 256 + (t ? atoi(t) : 0);
+ s = NULL;
+ }
+ return r;
diff --git
a/meta/recipes-core/busybox/busybox-1.19.4/busybox-appletlib-dependency.patch
b/meta/recipes-core/busybox/busybox-1.20.2/busybox-appletlib-dependency.patch
similarity index 100%
rename from
meta/recipes-core/busybox/busybox-1.19.4/busybox-appletlib-dependency.patch
rename to
meta/recipes-core/busybox/busybox-1.20.2/busybox-appletl
[OE-core] [PATCH 1/1] coreutils: fix to build with acl support
From: Jackie Huang
Fix the issue that coreutils was built without acl support:
configure: WARNING: libacl development library was not found or not usable.
configure: WARNING: GNU coreutils will be built without ACL support.
which will cause ls and cp commands don't have the ACL related behaviors:
ls -l: no plus sign(+) after the permission string for files that have ACL
cp -p: can not preserves the ACLs.
[YOCTO #2959]
Signed-off-by: Jackie Huang
---
.../coreutils-6.9/coreutils-build-with-acl.patch | 28
.../coreutils-8.14/coreutils-build-with-acl.patch | 28
meta/recipes-core/coreutils/coreutils_6.9.bb |1 +
meta/recipes-core/coreutils/coreutils_8.14.bb |1 +
4 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-core/coreutils/coreutils-6.9/coreutils-build-with-acl.patch
create mode 100644
meta/recipes-core/coreutils/coreutils-8.14/coreutils-build-with-acl.patch
diff --git
a/meta/recipes-core/coreutils/coreutils-6.9/coreutils-build-with-acl.patch
b/meta/recipes-core/coreutils/coreutils-6.9/coreutils-build-with-acl.patch
new file mode 100644
index 000..8273d78
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils-6.9/coreutils-build-with-acl.patch
@@ -0,0 +1,28 @@
+Upstream-Status: Inappropriate [embedded specific]
+
+Fix the following issue so that coreutils can build with ACL:
+
+configure: WARNING: libacl development library was not found or not usable.
+configure: WARNING: GNU coreutils will be built without ACL support.
+
+Signed-off-by: Jackie Huang
+---
+ m4/acl.m4 |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/m4/acl.m4 b/m4/acl.m4
+index d6a448a..a9d4836 100644
+--- a/m4/acl.m4
b/m4/acl.m4
+@@ -159,7 +159,7 @@ AC_DEFUN([gl_ACL_GET_FILE],
+ ]])],
+[gl_cv_func_working_acl_get_file=yes],
+[gl_cv_func_working_acl_get_file=no],
+- [gl_cv_func_working_acl_get_file=cross-compiling])])
++ [gl_cv_func_working_acl_get_file=yes])])
+
+ AS_IF([test $gl_cv_func_working_acl_get_file = yes], [$1], [$2])
+ ])
+--
+1.7.7
+
diff --git
a/meta/recipes-core/coreutils/coreutils-8.14/coreutils-build-with-acl.patch
b/meta/recipes-core/coreutils/coreutils-8.14/coreutils-build-with-acl.patch
new file mode 100644
index 000..8273d78
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils-8.14/coreutils-build-with-acl.patch
@@ -0,0 +1,28 @@
+Upstream-Status: Inappropriate [embedded specific]
+
+Fix the following issue so that coreutils can build with ACL:
+
+configure: WARNING: libacl development library was not found or not usable.
+configure: WARNING: GNU coreutils will be built without ACL support.
+
+Signed-off-by: Jackie Huang
+---
+ m4/acl.m4 |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/m4/acl.m4 b/m4/acl.m4
+index d6a448a..a9d4836 100644
+--- a/m4/acl.m4
b/m4/acl.m4
+@@ -159,7 +159,7 @@ AC_DEFUN([gl_ACL_GET_FILE],
+ ]])],
+[gl_cv_func_working_acl_get_file=yes],
+[gl_cv_func_working_acl_get_file=no],
+- [gl_cv_func_working_acl_get_file=cross-compiling])])
++ [gl_cv_func_working_acl_get_file=yes])])
+
+ AS_IF([test $gl_cv_func_working_acl_get_file = yes], [$1], [$2])
+ ])
+--
+1.7.7
+
diff --git a/meta/recipes-core/coreutils/coreutils_6.9.bb
b/meta/recipes-core/coreutils/coreutils_6.9.bb
index 5bfab16..20d8120 100644
--- a/meta/recipes-core/coreutils/coreutils_6.9.bb
+++ b/meta/recipes-core/coreutils/coreutils_6.9.bb
@@ -24,6 +24,7 @@ SRC_URI_BASE = "${GNU_MIRROR}/coreutils/${BP}.tar.bz2 \
file://coreutils-fix-install.patch \
file://man-touch.patch \
file://coreutils_fix_for_automake-1.12.patch \
+ file://coreutils-build-with-acl.patch \
"
SRC_URI = "${SRC_URI_BASE} file://fix_for_manpage_building.patch"
diff --git a/meta/recipes-core/coreutils/coreutils_8.14.bb
b/meta/recipes-core/coreutils/coreutils_8.14.bb
index 9a714a9..178bd67 100644
--- a/meta/recipes-core/coreutils/coreutils_8.14.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.14.bb
@@ -16,6 +16,7 @@ inherit autotools gettext
SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.xz \
file://remove-usr-local-lib-from-m4.patch \
file://remove-gets.patch \
+ file://coreutils-build-with-acl.patch \
"
SRC_URI[md5sum] = "bcb135ce553493a45aba01b39eb3920a"
SRC_URI[sha256sum] =
"0d120817c19292edb19e92ae6b8eac9020e03d51e0af9cb116cf82b65d18b02d"
--
1.7.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] coreutils: fix to build with acl support
From: Jackie Huang Fix the issue that coreutils was built without acl support: configure: WARNING: libacl development library was not found or not usable. configure: WARNING: GNU coreutils will be built without ACL support. which will cause ls and cp commands don't have the ACL related behaviors: ls -l: no plus sign(+) after the permission string for files that have ACL cp -p: can not preserves the ACLs. [YOCTO #2959] Signed-off-by: Jackie Huang --- The following changes since commit 04568d1f18250d531aad5d286157d2d559083520: qemu: Fix broken accidental path move (2012-08-20 17:25:21 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/bug2959_acl_0821 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/bug2959_acl_0821 Jackie Huang (1): coreutils: fix to build with acl support .../coreutils-6.9/coreutils-build-with-acl.patch | 28 .../coreutils-8.14/coreutils-build-with-acl.patch | 28 meta/recipes-core/coreutils/coreutils_6.9.bb |1 + meta/recipes-core/coreutils/coreutils_8.14.bb |1 + 4 files changed, 58 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-core/coreutils/coreutils-6.9/coreutils-build-with-acl.patch create mode 100644 meta/recipes-core/coreutils/coreutils-8.14/coreutils-build-with-acl.patch -- 1.7.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
