[OE-core] [PATCH 0/1] poky-default-revisions: move SRCREV to every recipe
From: Yu Ke ke...@intel.com move the SRCREV from poky-default-revisions.inc to its corresponding recipe, in this case, those non poky distro can also use its SRCREV. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: kyu3/srcrev-recipe Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/srcrev-recipe Thanks, Yu Ke ke...@intel.com --- Yu Ke (1): poky-default-revisions: move the SRCREV to recipe file meta-demoapps/recipes-gnome/abiword/abiword_cvs.bb |1 + .../recipes-graphics/clutter/table_git.bb |1 + meta-demoapps/recipes-graphics/clutter/tidy_git.bb |1 + .../matchbox-themes-extra_git.bb |1 + .../conf/distro/include/poky-default-revisions.inc | 203 meta/conf/layer.conf |2 - .../eee-acpi-scripts/eee-acpi-scripts_git.bb |1 + meta/recipes-bsp/uboot/u-boot_git.bb |1 + meta/recipes-bsp/x-load/x-load_git.bb |1 + meta/recipes-bsp/zaurusd/zaurusd_svn.bb|1 + meta/recipes-connectivity/connman/connman_git.bb |1 + meta/recipes-connectivity/gsm/libgsmd_svn.bb |1 + meta/recipes-connectivity/gypsy/gypsy_git.bb |1 + meta/recipes-connectivity/ofono/ofono_git.bb |1 + meta/recipes-core/dbus-wait/dbus-wait_svn.bb |2 + meta/recipes-core/eglibc/eglibc_2.12.bb|2 + meta/recipes-core/psplash/psplash_svn.bb |1 + .../installer/adt-installer_1.0.bb |1 + meta/recipes-devtools/opkg-utils/opkg-utils_svn.bb |1 + meta/recipes-devtools/opkg/opkg-nogpg_svn.bb |2 + meta/recipes-devtools/opkg/opkg_svn.bb |1 + meta/recipes-devtools/pkgconfig/pkgconfig_git.bb |1 + meta/recipes-devtools/prelink/prelink_git.bb |1 + meta/recipes-devtools/pseudo/pseudo_git.bb |1 + meta/recipes-devtools/qemu/qemu_git.bb |2 + .../recipes-devtools/swabber/swabber-native_git.bb |1 + meta/recipes-devtools/tcf-agent/tcf-agent_svn.bb |1 + meta/recipes-devtools/ubootchart/ubootchart_svn.bb |1 + meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb |1 + meta/recipes-extended/libzypp/libzypp_git.bb |1 + meta/recipes-extended/sat-solver/sat-solver_git.bb |1 + meta/recipes-extended/zypper/zypper_git.bb |1 + meta/recipes-gnome/gnome/gconf-dbus_svn.bb |1 + .../gnome/gobject-introspection_git.bb |2 + .../gtk-theme-torturer/gtk-theme-torturer_git.bb |3 +- meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb|2 + meta/recipes-graphics/clutter/clutter-box2d_git.bb |1 + .../clutter/clutter-gst-1.4_git.bb |1 + .../clutter/clutter-gtk-1.4_git.bb |1 + meta/recipes-graphics/clutter/clutter_git.bb |1 + meta/recipes-graphics/drm/libdrm_git.bb|1 + meta/recipes-graphics/fstests/fstests_svn.bb |2 + meta/recipes-graphics/libfakekey/libfakekey_git.bb |2 + .../libmatchbox/libmatchbox_git.bb |1 + .../matchbox-wm-2/matchbox-wm-2_svn.bb |1 + .../matchbox-wm/matchbox-wm_git.bb |1 + meta/recipes-graphics/mesa/mesa-dri_git.bb |1 + meta/recipes-graphics/mesa/qemugl_git.bb |2 + meta/recipes-graphics/mutter/mutter_git.bb |1 + meta/recipes-graphics/xcb/libxcb_git.bb|2 + meta/recipes-graphics/xcb/xcb-proto_git.bb |1 + .../xorg-driver/xf86-input-keyboard_git.bb |1 + .../xorg-driver/xf86-input-mouse_git.bb|1 + .../xorg-driver/xf86-input-synaptics_git.bb|1 + .../xorg-driver/xf86-video-intel_git.bb|1 + .../xorg-driver/xf86-video-omapfb_git.bb |1 + meta/recipes-graphics/xorg-lib/libx11-diet_git.bb |2 + meta/recipes-graphics/xorg-lib/libx11-trim_git.bb |1 + meta/recipes-graphics/xorg-lib/libx11_git.bb |1 + .../recipes-graphics/xorg-lib/libxcalibrate_git.bb |1 + meta/recipes-graphics/xorg-lib/libxext_git.bb |1 + meta/recipes-graphics/xorg-lib/libxi_git.bb|1 + .../xorg-proto/calibrateproto_git.bb |2 + meta/recipes-graphics/xorg-proto/dri2proto_git.bb |3 + meta/recipes-graphics/xorg-proto/inputproto_git.bb |1 + .../xorg-xserver/xserver-xf86-dri-lite_git.bb |1 + .../xvideo-tests/xvideo-tests_svn.bb |2 + meta/recipes-kernel/blktrace/blktrace_git.bb |2 + meta/recipes-kernel/dtc/dtc_git.inc|2 + .../kern-tools/kern-tools-native_git.bb|1 + .../linux-firmware/linux-firmware_git.bb |1 + .../linux-libc-headers-yocto_git.bb|1 + .../recipes-kernel/linux/linux-yocto-stable_git.bb | 12 ++ meta/recipes-kernel/linux/linux-yocto_git.bb | 14 ++
Re: [OE-core] [PATCH 0/1] poky-default-revisions: move SRCREV to every recipe
2011/5/4 Richard Purdie richard.pur...@linuxfoundation.org On Wed, 2011-05-04 at 22:05 +0800, Yu Ke wrote: From: Yu Ke ke...@intel.com move the SRCREV from poky-default-revisions.inc to its corresponding recipe, in this case, those non poky distro can also use its SRCREV. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: kyu3/srcrev-recipe Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/srcrev-recipe Thanks, Yu Ke ke...@intel.com --- Yu Ke (1): poky-default-revisions: move the SRCREV to recipe file Merged to master, thanks for resolving this issue! :) Cheers, Richard I would have preferred a more standardised placement of SRCREV. Most of the time the SRCREV is before the PV, but not always (and sometimes separated with an empty line and sometimes not). Also there is at least one error introduced: diff --git a/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbb/meta/recipes-devtools/yaffs2/ yaffs2-utils_cvs.bb index 6171fe5..c729c7c 100644 --- a/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbhttp://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb?h=kyu3/srcrev-recipeid=d2e078aa046ae6c4f169695f546cf229db5be1f7 +++ b/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbhttp://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb?h=kyu3/srcrev-recipeid=c75b49ff5cfd10f5187af2b66a0a8d5513460374 @@ -1,3 +1,4 @@ require yaffs2-utils.inc PR = r1 +SRCDAT = 20071107 That should be SRCDATE. There might be more of these, my eye just fell on this one. Frans PS: speaking of yaffs2 utils: it could be considered to move to a somewhat newer version (not that I care as I do not use yaffs2) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] [PATCH 1/3] Remove machine-specific metadata for machines no longer in oe-core
On 05/04/2011 09:21 AM, Paul Eggleton wrote:
On Wednesday 04 May 2011 16:07:17 Gary Thomas wrote:
Perhaps it makes sense to always package netbase in ${MACHINE_ARCH} since
it almost always will have machine specific data?
I'll let someone else comment on this, I don't have a hard opinion either way.
Also, what about these overrides? (There may be others, I just noticed
these)
./meta/recipes-core/base-passwd/base-passwd_3.5.22.bb:do_install_append_op
enmn() {
./meta/recipes-core/netbase/netbase_4.45.bb:INITSCRIPT_PARAMS_openmn =
start 85 1 2 3 4 5 . stop 85 0 6 1 .
./meta/recipes-core/busybox/busybox.inc:INITSCRIPT_PARAMS_${PN}-syslog_slu
gos = start 20 .
./meta/recipes-core/netbase/netbase_4.45.bb:INITSCRIPT_PARAMS_slugos =
start 42 S 0 6 .
./meta/recipes-core/base-files/base-files_3.0.14.bb:hostname_slugos =
nslu2
./meta/recipes-core/base-files/base-files_3.0.14.bb:do_install_append_slug
os() {
./meta/recipes-core/base-files/base-files_3.0.14.bb:CONFFILES_${PN}_slugos
= ${sysconfdir}/resolv.conf ${sysconfdir}/fstab ${sysconfdir}/hostname
./meta/recipes-devtools/dpkg/dpkg.inc:DPKG_INIT_POSITION_slugos = 41
These are all distro overrides and unless I'm mistaken these are all removed
by the second patch in the series.
Sorry, I missed that. Good work!
--
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] [PATCH 0/1] poky-default-revisions: move SRCREV to every recipe
On Wed, 2011-05-04 at 16:24 +0200, Frans Meulenbroeks wrote: Most of the time the SRCREV is before the PV, but not always (and sometimes separated with an empty line and sometimes not). Patches welcome... Also there is at least one error introduced: diff --git a/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbb/meta/recipes-devtools/yaffs2/ yaffs2-utils_cvs.bb index 6171fe5..c729c7c 100644 --- a/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbhttp://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb?h=kyu3/srcrev-recipeid=d2e078aa046ae6c4f169695f546cf229db5be1f7 +++ b/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbhttp://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb?h=kyu3/srcrev-recipeid=c75b49ff5cfd10f5187af2b66a0a8d5513460374 @@ -1,3 +1,4 @@ require yaffs2-utils.inc PR = r1 +SRCDAT = 20071107 That should be SRCDATE. There might be more of these, my eye just fell on this one. Good catch, we need to fix that. Frans PS: speaking of yaffs2 utils: it could be considered to move to a somewhat newer version (not that I care as I do not use yaffs2) It is something we should look at going, yes although I don't think yaffs2 has changed that much in a while. 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 0/1] poky-default-revisions: move SRCREV to every recipe
2011/5/4 Richard Purdie richard.pur...@linuxfoundation.org On Wed, 2011-05-04 at 16:24 +0200, Frans Meulenbroeks wrote: Most of the time the SRCREV is before the PV, but not always (and sometimes separated with an empty line and sometimes not). Patches welcome... I know. It was more a hint for future changes. Also this probably should be part of a more global style cleanup to make things more according to the style guide. [...] PS: speaking of yaffs2 utils: it could be considered to move to a somewhat newer version (not that I care as I do not use yaffs2) It is something we should look at going, yes although I don't think yaffs2 has changed that much in a while. The latest changes are about 13 months old, but there seem to be quite some changes since 2007 (although quite some seem cosmetical). (btw there is also an abiword cvs recipe with a srcdate of 2007; somehow odd given the number of regular releases abiword has). Frans. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] error: LOOP: udev/ libudev during do_rootfs?
Hello Mark, thanks for your response. On Wed, May 4, 2011 at 12:31 AM, Mark Hatle mark.ha...@windriver.com wrote: On 5/3/11 5:19 PM, Leon Woestenberg wrote: on oe-core I'm testing the addition of powerpc-linux-gnuspe targets. | error: LOOP: | error: removing udev-164-r1.ppce500v2 Requires: libudev0 = 164 from tsort relations. | error: removing libudev0-164-r1.ppce500v2 Requires: udev = 164-r1 from tsort relations. | Preparing... ## | ERROR: Function 'do_rootfs' failed (see In the past I've only seen this type of mystery failure when PSEUDO was not be run properly. (pseudo is being configured by the bitbake wrapper, located in the scripts directory. It has to be preloaded by the wrapper for performance reasons during the build.) If you are not using the bitbake wrapper script (automatically added to your environment when you use the environment setup script oe-init-build-env) you will need to either use the environment setup script, or add the wrapper to your path [or call it directly]. If the wrapper is being invoked, I have some further checks to verify behavior on your system. If the failures continue, what type of host system do you have (distro), and what version of libc? Do you have both 32-bit and 64-bit libraries and executables installed? Ubuntu 10.04 32-bit only, glibc 2.11.1 Linux sideways 2.6.32-25-generic-pae #44-Ubuntu SMP Fri Sep 17 21:57:48 UTC 2010 i686 GNU/Linux $ . oe-init-build-env $ which bitbake /home/leon/sandbox/sidebranch/yocto/oe-core/scripts/bitbake OE Build Configuration: BB_VERSION= 1.13.0 METADATA_BRANCH = master METADATA_REVISION = 472c04ed1a8715243de0c5430883bc23d60aca19 TARGET_ARCH = powerpc TARGET_OS = linux-gnuspe MACHINE = p2020rdb DISTRO= poky DISTRO_VERSION= 0.9+snapshot-20110504 TARGET_FPU= I could reproduce twice from scratch, and the problem repeats by running bitbake core-image-minimal again. On an earlier snapshot of oe-core with meta-openembedded, I didn't run into this. I will now rerun against MACHINE=mpc8315e-rdb. Regards, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc 2.13 upgrade
On (28/04/11 15:03), Saul Wold wrote: On 04/27/2011 01:13 PM, Khem Raj wrote: On Wed, Apr 27, 2011 at 9:44 AM, Koen Kooik...@dominion.thruhere.net wrote: Why not move those srcrevs into the recipe? IIRC these ones aren't affected by RPs concerns I am ok doing that but here http://lists.linuxtogo.org/pipermail/openembedded-core/2011-April/001536.html it seems we still need to investigate it before we start moving SRCREVs to recipes. We are days away from having this implemented (early next week is the plan right now). Once you see the big pull that moves SRCREVs, then you can go ahead with your upgrade. The SRCREV move happened today. I have updated the eglibc patch accordingly and pushed it to contrib branch here. I have earlier tested it on all arches this time I tested only on arm and it still works fine. So please try it out in your configurations and let me know if anything is needed. branch is here http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/eglibc-2.13 Thanks -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] How to patch yocto kernel
On (02/05/11 01:31), Bruce Ashfield wrote:
On Sun, May 1, 2011 at 11:56 PM, Khem Raj raj.k...@gmail.com wrote:
On Sun, May 1, 2011 at 7:40 PM, Bruce Ashfield bruce.ashfi...@gmail.com
wrote:
On Sun, May 1, 2011 at 9:14 PM, Khem Raj raj.k...@gmail.com wrote:
Hi
I am trying to test this patch
http://uclibc.org/~kraj/perf-tool-Fix-gcc-4.6.0-issues.patch
to fix the build using gcc 4.6.0 but the kernel patching for yocto is
not as usual as other recipes
since it uses entire set of tooling around it.
I tried to look around for documentation and few references I found
https://wiki.pokylinux.org/wiki/Wind_River_Kernel
discourages putting patches in metadata. and in another document it
says it uses git to do patching but does not explain how.
So if someone can explain in simple terms how to patch a linux-yocto
would be really helpful from a
developer POV or any documentation will be helpful.
How do people develop/test patches on linux-yocto I understand
eventually they are desired to be part
of linux-yocto git but that comes after they are tried and tested locally
I would have preferred to have the usual SRC_URI patching atleast for
local testing. As of now
it seems not to use normal OE recipe procedures.
Are you actually not seeing this work ? I put in place compatibility
with existing patching via the SRC_URI for just this reason. A patch
specified in the SRC_URI will be picked up by the tools and applied
to the end of the BSP branch during the patching phase.
if it worked. I would not be writing this email :)
:) you never know, I didn't see your error message so I didn't want
to presume.
But I spoke too soon earlier, I had a bbappend in my layers that
meant I was modifying the wrong SRC_URI to have your patch
applied.
When I modified the right SRC_URI like so:
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta\
+ file://perf-tool-Fix-gcc-4.6.0-issues.patch
(i.e. the obvious way)
I see the patch applied to the end of my BSP branch:
git branch
master
meta
yocto/base
yocto/eg20t
yocto/emgd
yocto/gma500
yocto/standard/arm-versatile-926ejs
yocto/standard/base
yocto/standard/beagleboard
yocto/standard/common-pc-64/base
yocto/standard/common-pc-64/jasperforest
yocto/standard/common-pc-64/sugarbay
yocto/standard/common-pc/atom-pc
* yocto/standard/common-pc/base
commit 2500f7dc4d6c0d8b2f5ddad6369ee4541456533a
Author: Kyle McMartin k...@mcmartin.ca
Date: Mon May 2 01:26:49 2011 -0400
commit fb7d0b3cefb80a105f7fd26bbc62e0cbf9192822 upstream.
GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf
due to the -Werror=unused-but-set-variable flag.
I've gone through and annotated some of the assignments that had side
effects (ie: return value from a function) with the __used annotation,
and in some cases, just removed unused code.
In a few cases, we were assigning something useful, but not using it in
later parts of the function.
kyle@dreadnought:~/src% gcc --version
gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3)
Cc: Ingo Molnar mi...@redhat.com
LKML-Reference: 20110124161304.gk27...@bombadil.infradead.org
Signed-off-by: Kyle McMartin k...@redhat.com
[ committer note: Fixed up the annotation fixes, as that code
moved recently ]
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
[Backported to 2.6.38.2 by deleting unused but set variables]
Signed-off-by: Thomas Meyer tho...@m3y3r.de
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
[Backported to linux-yocto kernel git version]
Signed-off-by: Khem Raj raj.k...@gmail.com
I did modify the patch format slightly, since git am needs to be able to
grok the patch for it to apply.
Did you get any sort of error message when your patch didn't apply ?
When I did a build from scratch then it worked fine. Have you already
taken this patch in ? if not what needs to be done ?
-Khem
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemu segfaulting when booting ext3 image
Raj, We have a bug for Nvidia driver @ http://bugzilla.pokylinux.org/show_bug.cgi?id=649 and a fix @ http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=gzhai/fix2id=f596757000465a4b8350e16f21553a23b8bbedfa I think it deserves a try. BTW, where is your gl library, including original one and Nvidia's? I doubt the layout may changes in ubuntu 11.04, so that our code failed to detect it. Thanks, edwin Khem Raj wrote: On Tue, May 3, 2011 at 11:43 AM, Scott Garman scott.a.gar...@intel.com wrote: On 05/03/2011 10:32 AM, Mark Hatle wrote: On 5/3/11 12:27 PM, Khem Raj wrote: On Mon, May 2, 2011 at 5:41 PM, Zhai, Edwinedwin.z...@intel.com wrote: Did you installed Nvidia proprietary driver? Any error mesg from the runqemu script? yes I did and I think that could be a culprit but then why would it work with nfs boot. there is no useful message from script it just collapses The script tries to detect the nvidia drivers. If it finds them is supposed to issue a warning. Sounds like your system might not have a version that it knows how to detect. The Nvidia libGL bug caused a segfault in qemu when booting images, so it should be pretty obvious if that's what's causing it. Given that Khem is booting the nfs version successfully, and not seeing any error message, I think this might be a new error. the host system is 64-bit kubuntu 11.04 with nvidia proprietary drivers. IIRC it worked fine without them but that was a month back. 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 ___ 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/1] poky-default-revisions: move SRCREV to every recipe
on 2011-5-4 22:24, Frans Meulenbroeks wrote: 2011/5/4 Richard Purdierichard.pur...@linuxfoundation.org On Wed, 2011-05-04 at 22:05 +0800, Yu Ke wrote: From: Yu Keke...@intel.com move the SRCREV from poky-default-revisions.inc to its corresponding recipe, in this case, those non poky distro can also use its SRCREV. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: kyu3/srcrev-recipe Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/srcrev-recipe Thanks, Yu Keke...@intel.com --- Yu Ke (1): poky-default-revisions: move the SRCREV to recipe file Merged to master, thanks for resolving this issue! :) Cheers, Richard I would have preferred a more standardised placement of SRCREV. Most of the time the SRCREV is before the PV, but not always (and sometimes separated with an empty line and sometimes not). Also there is at least one error introduced: diff --git a/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbb/meta/recipes-devtools/yaffs2/ yaffs2-utils_cvs.bb index 6171fe5..c729c7c 100644 --- a/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbhttp://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb?h=kyu3/srcrev-recipeid=d2e078aa046ae6c4f169695f546cf229db5be1f7 +++ b/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbhttp://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb?h=kyu3/srcrev-recipeid=c75b49ff5cfd10f5187af2b66a0a8d5513460374 @@ -1,3 +1,4 @@ require yaffs2-utils.inc PR = r1 +SRCDAT = 20071107 That should be SRCDATE. There might be more of these, my eye just fell on this one. Thanks for pointing it out. For unknown reason, my proxy does not work in cvs fetcher , so this recipe is untested. I should take more care on this. A patch is just sent out to fix it. Regards Ke Frans PS: speaking of yaffs2 utils: it could be considered to move to a somewhat newer version (not that I care as I do not use yaffs2) ___ 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 36/52] gettext.bbclass: Use _append instead of =+
On Tue, May 3, 2011 at 3:39 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2011-05-03 at 11:04 -0700, Khem Raj wrote:
This has the same problem It empties out DEPENDS_GETTEXT after they have
have already been added to DEPENDS via virtclass e.g. when you build
gcc-runtime-nativesdk it will report a dep loop since now it depends on
virtual/gettext-nativesdk (added by gettext class)
and virtual/gettext-nativesdk depends on compilerlibs
provided by gcc-runtime-nativesdk. This was same problem I was trying to
circumvent
Ok, how about this version:
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 4f20bc2..3b83e42 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -89,9 +89,11 @@ def base_dep_prepend(d):
deps += virtual/${TARGET_PREFIX}gcc
virtual/${TARGET_PREFIX}compilerlibs virtual/libc
return deps
-DEPENDS_prepend=${@base_dep_prepend(d)}
-DEPENDS_virtclass-native_prepend=${@base_dep_prepend(d)}
-DEPENDS_virtclass-nativesdk_prepend=${@base_dep_prepend(d)}
+BASEDEPENDS = ${@base_dep_prepend(d)}
+
+DEPENDS_prepend=${BASEDEPENDS}
+DEPENDS_virtclass-native_prepend=${BASEDEPENDS}
+DEPENDS_virtclass-nativesdk_prepend=${BASEDEPENDS}
FILESPATH = ${@base_set_filespath([ ${FILE_DIRNAME}/${PF},
${FILE_DIRNAME}/${P}, ${FILE_DIRNAME}/${PN}, ${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files, ${FILE_DIRNAME} ], d)}
# THISDIR only works properly with imediate expansion as it has to run
diff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
index a40e74f..6f79e5e 100644
--- a/meta/classes/gettext.bbclass
+++ b/meta/classes/gettext.bbclass
@@ -1,17 +1,17 @@
-def gettext_after_parse(d):
- # Remove the NLS bits if USE_NLS is no.
- if bb.data.getVar('USE_NLS', d, 1) == 'no':
- cfg = oe_filter_out('^--(dis|en)able-nls$',
bb.data.getVar('EXTRA_OECONF', d, 1) or , d)
- cfg += --disable-nls
- depends = bb.data.getVar('DEPENDS', d, 1) or
- bb.data.setVar('DEPENDS',
oe_filter_out('^(virtual/libiconv|virtual/libintl)$', depends, d), d)
- bb.data.setVar('EXTRA_OECONF', cfg, d)
+def gettext_dependencies(d):
+ if d.getVar('USE_NLS', True) == 'no':
+ return
+ if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True) and not
oe.utils.inherits(d, 'cross-canadian'):
+ return
+ return d.getVar('DEPENDS_GETTEXT', False)
-python () {
- gettext_after_parse(d)
-}
+def gettext_oeconf(d):
+ # Remove the NLS bits if USE_NLS is no.
+ if d.getVar('USE_NLS', True) == 'no':
+ return '--disable-nls'
+ return --enable-nls
-DEPENDS_GETTEXT = gettext gettext-native
+DEPENDS_GETTEXT = virtual/gettext gettext-native
-DEPENDS =+ ${DEPENDS_GETTEXT}
-EXTRA_OECONF += --enable-nls
+BASEDEPENDS =+ ${@gettext_dependencies(d)}
+EXTRA_OECONF += ${@gettext_oeconf(d)}
a build from scratch revealed few more issues with this patch too.
1. We have to only remove gettext from dependencies if its a target
package for all other it still it needed otherwise all native and
cross tools start failing to build
e.g. binutils-cross this can be easily solved by a patch
iff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
index 6f79e5e..cc39204 100644
--- a/meta/classes/gettext.bbclass
+++ b/meta/classes/gettext.bbclass
@@ -1,5 +1,5 @@
def gettext_dependencies(d):
-if d.getVar('USE_NLS', True) == 'no':
+if d.getVar('USE_NLS', True) == 'no' and not oe.utils.inherits(d,
'native', 'nativesdk', 'cross')
return
if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True) and not
oe.utils.inherits(d, 'cross-canadian')
return
second problem is that EXTRA_OECONF when recipes override it instead
of += or appending etc.
then --enable|--disable-nls that we added via gettext_oeconf() is lost
as a result some packages complain about config.rpath
when USE_NLS is set to no the reason is their configure is missing the
argument --disable-nls this works ok
for eglibc based targets since default is to enable-nls if nothing is
specified but uclibc fails. As a testcase try to preprocess
utils-linux
recipe and check the contents of EXTRA_OECONF
___
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] poky-default-revisions: move SRCREV to every recipe
on 2011-5-4 23:39, Bruce Ashfield wrote: On Wed, May 4, 2011 at 10:05 AM, Yu Keke...@intel.com wrote: From: Yu Keke...@intel.com move the SRCREV from poky-default-revisions.inc to its corresponding recipe, in this case, those non poky distro can also use its SRCREV. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: kyu3/srcrev-recipe Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/srcrev-recipe Thanks, Yu Keke...@intel.com --- Yu Ke (1): poky-default-revisions: move the SRCREV to recipe file meta-demoapps/recipes-gnome/abiword/abiword_cvs.bb |1 + .../recipes-graphics/clutter/table_git.bb |1 + meta-demoapps/recipes-graphics/clutter/tidy_git.bb |1 + snip meta/recipes-kernel/blktrace/blktrace_git.bb |2 + meta/recipes-kernel/dtc/dtc_git.inc|2 + .../kern-tools/kern-tools-native_git.bb|1 + .../linux-firmware/linux-firmware_git.bb |1 + .../linux-libc-headers-yocto_git.bb|1 + .../recipes-kernel/linux/linux-yocto-stable_git.bb | 12 ++ meta/recipes-kernel/linux/linux-yocto_git.bb | 14 ++\ Would it be possible to get direct cc on changes to the linux-yocto recipes ? I didn't expect this and it is causing me a bit of pain at the moment. A direct cc' would have helped, since I would have preferred to stage the change in with my other items. Bruce Get it, will CC you next time for linux-yocto changes. Regards Ke ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemu segfaulting when booting ext3 image
On Wed, May 4, 2011 at 5:40 PM, Zhai, Edwin edwin.z...@intel.com wrote: Raj, We have a bug for Nvidia driver @ http://bugzilla.pokylinux.org/show_bug.cgi?id=649 and a fix @ http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=gzhai/fix2id=f596757000465a4b8350e16f21553a23b8bbedfa I think it deserves a try. BTW, where is your gl library, including original one and Nvidia's? I doubt the layout may changes in ubuntu 11.04, so that our code failed to detect it. yes this helps indeed. Please propose this patch for oe-core's scripts/runqemu-internal Thanks -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 36/52] gettext.bbclass: Use _append instead of =+
On (04/05/11 18:07), Khem Raj wrote:
On Tue, May 3, 2011 at 3:39 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2011-05-03 at 11:04 -0700, Khem Raj wrote:
This has the same problem It empties out DEPENDS_GETTEXT after they have
have already been added to DEPENDS via virtclass e.g. when you build
gcc-runtime-nativesdk it will report a dep loop since now it depends on
virtual/gettext-nativesdk (added by gettext class)
and virtual/gettext-nativesdk depends on compilerlibs
provided by gcc-runtime-nativesdk. This was same problem I was trying to
circumvent
Ok, how about this version:
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 4f20bc2..3b83e42 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -89,9 +89,11 @@ def base_dep_prepend(d):
deps += virtual/${TARGET_PREFIX}gcc
virtual/${TARGET_PREFIX}compilerlibs virtual/libc
return deps
-DEPENDS_prepend=${@base_dep_prepend(d)}
-DEPENDS_virtclass-native_prepend=${@base_dep_prepend(d)}
-DEPENDS_virtclass-nativesdk_prepend=${@base_dep_prepend(d)}
+BASEDEPENDS = ${@base_dep_prepend(d)}
+
+DEPENDS_prepend=${BASEDEPENDS}
+DEPENDS_virtclass-native_prepend=${BASEDEPENDS}
+DEPENDS_virtclass-nativesdk_prepend=${BASEDEPENDS}
FILESPATH = ${@base_set_filespath([ ${FILE_DIRNAME}/${PF},
${FILE_DIRNAME}/${P}, ${FILE_DIRNAME}/${PN}, ${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files, ${FILE_DIRNAME} ], d)}
# THISDIR only works properly with imediate expansion as it has to run
diff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
index a40e74f..6f79e5e 100644
--- a/meta/classes/gettext.bbclass
+++ b/meta/classes/gettext.bbclass
@@ -1,17 +1,17 @@
-def gettext_after_parse(d):
- # Remove the NLS bits if USE_NLS is no.
- if bb.data.getVar('USE_NLS', d, 1) == 'no':
- cfg = oe_filter_out('^--(dis|en)able-nls$',
bb.data.getVar('EXTRA_OECONF', d, 1) or , d)
- cfg += --disable-nls
- depends = bb.data.getVar('DEPENDS', d, 1) or
- bb.data.setVar('DEPENDS',
oe_filter_out('^(virtual/libiconv|virtual/libintl)$', depends, d), d)
- bb.data.setVar('EXTRA_OECONF', cfg, d)
+def gettext_dependencies(d):
+ if d.getVar('USE_NLS', True) == 'no':
+ return
+ if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True) and not
oe.utils.inherits(d, 'cross-canadian'):
+ return
+ return d.getVar('DEPENDS_GETTEXT', False)
-python () {
- gettext_after_parse(d)
-}
+def gettext_oeconf(d):
+ # Remove the NLS bits if USE_NLS is no.
+ if d.getVar('USE_NLS', True) == 'no':
+ return '--disable-nls'
+ return --enable-nls
-DEPENDS_GETTEXT = gettext gettext-native
+DEPENDS_GETTEXT = virtual/gettext gettext-native
-DEPENDS =+ ${DEPENDS_GETTEXT}
-EXTRA_OECONF += --enable-nls
+BASEDEPENDS =+ ${@gettext_dependencies(d)}
+EXTRA_OECONF += ${@gettext_oeconf(d)}
a build from scratch revealed few more issues with this patch too.
1. We have to only remove gettext from dependencies if its a target
package for all other it still it needed otherwise all native and
cross tools start failing to build
e.g. binutils-cross this can be easily solved by a patch
iff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
index 6f79e5e..cc39204 100644
--- a/meta/classes/gettext.bbclass
+++ b/meta/classes/gettext.bbclass
@@ -1,5 +1,5 @@
def gettext_dependencies(d):
-if d.getVar('USE_NLS', True) == 'no':
+if d.getVar('USE_NLS', True) == 'no' and not oe.utils.inherits(d,
'native', 'nativesdk', 'cross')
return
if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True) and not
oe.utils.inherits(d, 'cross-canadian')
return
second problem is that EXTRA_OECONF when recipes override it instead
of += or appending etc.
then --enable|--disable-nls that we added via gettext_oeconf() is lost
as a result some packages complain about config.rpath
when USE_NLS is set to no the reason is their configure is missing the
argument --disable-nls this works ok
for eglibc based targets since default is to enable-nls if nothing is
specified but uclibc fails. As a testcase try to preprocess
utils-linux
recipe and check the contents of EXTRA_OECONF
attached is a patch on top of this patch which fixes both the issues I
mentioned. I also thought of defining USE_NLS to yes in
native/cross/nativesdk classes but then I resorted to add the check in
gettext.bbclass
Please review and apply if appropriate
Thanks
--
-Khem
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] linux-yocto: apply meta data to external repos
To support quick uprev and testing, it is desireable to build
repositories that do not have embedded meta data. In this scenario
the meta data can be automatically created or provided externally.
This commit supports the first situation by detecting the lack
of meta data and then automatically creating a base set of meta
files.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-yocto.bbclass | 27 +++
.../kern-tools/kern-tools-native_git.bb|2 +-
2 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index fc9f3a7..78a1309 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -66,8 +66,15 @@ IFS='
fi
cd ${S}
- # checkout and clobber and unimportant files
- git checkout -f ${KBRANCH}
+ set +e
+ git show-ref --quiet --verify -- refs/heads/${KBRANCH}
+ if [ $? -eq 0 ]; then
+ # checkout and clobber and unimportant files
+ git checkout -f ${KBRANCH}
+ else
+ echo Not checking out ${KBRANCH}, it will be created later
+ git checkout -f master
+ fi
}
do_kernel_checkout[dirs] = ${S}
@@ -105,21 +112,29 @@ python do_kernel_configcheck() {
bb.plain( %s % result )
}
+# overrides the base kernel_do_configure, since we don't want all the
+# defconfig processing in there
+kernel_do_configure() {
+yes '' | oe_runmake oldconfig
+}
+
+
# Ensure that the branches (BSP and meta) are on the locatios specified by
# their SRCREV values. If they are NOT on the right commits, the branches
# are reset to the correct commit.
do_validate_branches() {
cd ${S}
- branch_head=`git show-ref -s --heads ${KBRANCH}`
- meta_head=`git show-ref -s --heads ${KMETA}`
- target_branch_head=${SRCREV_machine}
- target_meta_head=${SRCREV_meta}
# nothing to do if bootstrapping
if [ -n ${YOCTO_KERNEL_EXTERNAL_BRANCH} ]; then
return
fi
+ branch_head=`git show-ref -s --heads ${KBRANCH}`
+ meta_head=`git show-ref -s --heads ${KMETA}`
+ target_branch_head=${SRCREV_machine}
+ target_meta_head=${SRCREV_meta}
+
current=`git branch |grep \*|sed 's/^\* //'`
if [ -n $target_branch_head ] [ $branch_head !=
$target_branch_head ]; then
if [ -n ${KERNEL_REVISION_CHECKING} ]; then
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 00cc666..cc71179 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
DEPENDS = git-native guilt-native
-SRCREV = 8f61abb6344e78677450994e8930cabc86102d78
+SRCREV = 92b965b02e3ac32badde3ee71a1e7d3a85cedeb8
PR = r10
PV = 0.1+git${SRCPV}
--
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 3/3] linux-yocto: update SRCREVs
Updating the linux-yocto/2.6.37 SRCREVs to pickup:
perf tool: Fix gcc 4.6.0 issues
1/1 [
Author: Kyle McMartin
Email: k...@mcmartin.ca
Subject: perf tool: Fix gcc 4.6.0 issues
Date: Thu, 5 May 2011 00:06:01 -0400
commit fb7d0b3cefb80a105f7fd26bbc62e0cbf9192822 upstream.
GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf
due to the -Werror=unused-but-set-variable flag.
I've gone through and annotated some of the assignments that had side
effects (ie: return value from a function) with the __used annotation,
and in some cases, just removed unused code.
In a few cases, we were assigning something useful, but not using it in
later parts of the function.
kyle@dreadnought:~/src% gcc --version
gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3)
Cc: Ingo Molnar mi...@redhat.com
LKML-Reference: 20110124161304.gk27...@bombadil.infradead.org
Signed-off-by: Kyle McMartin k...@redhat.com
[ committer note: Fixed up the annotation fixes, as that code moved
recently ]
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
[Backported to 2.6.38.2 by deleting unused but set variables]
Signed-off-by: Thomas Meyer tho...@m3y3r.de
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
[Backported to linux-yocto kernel git version]
Signed-off-by: Khem Raj raj.k...@gmail.com
]
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto_git.bb | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb
b/meta/recipes-kernel/linux/linux-yocto_git.bb
index 8a46e02..3b4e77e 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -18,20 +18,20 @@ KMETA = meta
LINUX_VERSION ?= 2.6.37
LINUX_VERSION_EXTENSION ?= -yocto-${LINUX_KERNEL_TYPE}
-SRCREV_machine_qemuarm = e5ca41def834db9d18b28393a45d53a8d18f3d05
-SRCREV_machine_qemumips = 9bbc8e3432406429923fab0de038af5d3e647901
-SRCREV_machine_qemuppc = f0ff494e62bfaa921e844c1ec7fe6cf4a977980a
-SRCREV_machine_qemux86 = cb0537a40dadea20f12bc10e0986fd2a70290b42
-SRCREV_machine_qemux86-64 = 69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3
-SRCREV_machine_emenlow = 2215a346eb4f9e09053d00bdf61ed999ff80e029
-SRCREV_machine_atom-pc = 69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3
-SRCREV_machine_routerstationpro = 8db69980d76e1f863af409e70175963f23de83ab
-SRCREV_machine_mpc8315e-rdb = 6861d8a4d58f8aa75997f7678cc454791544507a
-SRCREV_machine_beagleboard = 69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3
-SRCREV_machine = 69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3
+SRCREV_machine_qemuarm = b0375c21e29453458f9aa9986dc3f1ec69bf1aef
+SRCREV_machine_qemumips = f5d26f2eda2be8b942172cda8f27de33ebf38ec3
+SRCREV_machine_qemuppc = 7eb6c68d977d9039a2b5a734172b064a9d19cdc1
+SRCREV_machine_qemux86 = ad62d1aab734513cd96c8f4517f816420a218e77
+SRCREV_machine_qemux86-64 = b906f358fd404a1e74a961f25079274e0d933ee1
+SRCREV_machine_emenlow = c3bbcb676f929c4fc0511a6e66494b8770d015a1
+SRCREV_machine_atom-pc = b906f358fd404a1e74a961f25079274e0d933ee1
+SRCREV_machine_routerstationpro = 95ca94d2e71ca2db6822a37a7f575fa79c3d05d0
+SRCREV_machine_mpc8315e-rdb = 53c800c244e73d81d2832f6da306eeae3b09e5dc
+SRCREV_machine_beagleboard = b906f358fd404a1e74a961f25079274e0d933ee1
+SRCREV_machine = b906f358fd404a1e74a961f25079274e0d933ee1
SRCREV_meta = ecab1e2bc12a8b0c4d064a00acc3260f6e8528c5
-PR = r16
+PR = r17
PV = ${LINUX_VERSION}+git${SRCPV}
SRCREV_FORMAT = meta_machine
--
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 2/3] linux-yocto: safely process unbranched repositories
The BSP bootstrap and -dev use cases can be applied against
unbranched or repos without meta data. To allow the proper
and safe processing of those repositories, slight modifications
to the tools are required to pass the branch on the command
line (rather than detecting it always) and to only checkout
branches that exist.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-yocto.bbclass |7 +--
.../kern-tools/kern-tools-native_git.bb|2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 78a1309..ffc0b4c 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -25,7 +25,7 @@ do_patch() {
addon_features=$addon_features --feature $feat
done
fi
- updateme ${addon_features} ${ARCH} ${MACHINE} ${WORKDIR}
+ updateme --branch ${kbranch} ${addon_features} ${ARCH} ${MACHINE}
${WORKDIR}
if [ $? -ne 0 ]; then
echo ERROR. Could not update ${kbranch}
exit 1
@@ -87,9 +87,12 @@ do_kernel_configme() {
if [ -n ${YOCTO_KERNEL_EXTERNAL_BRANCH} ]; then
# switch from a generic to a specific branch
kbranch=${YOCTO_KERNEL_EXTERNAL_BRANCH}
+ cd ${S}
+ git checkout ${kbranch}
+ else
+ cd ${S}
fi
- cd ${S}
configme --reconfig --output ${B} ${kbranch} ${MACHINE}
if [ $? -ne 0 ]; then
echo ERROR. Could not configure
${KMACHINE}-${LINUX_KERNEL_TYPE}
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index cc71179..820765e 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
DEPENDS = git-native guilt-native
-SRCREV = 92b965b02e3ac32badde3ee71a1e7d3a85cedeb8
+SRCREV = c5896a60acc61f8966cfee3bb241ff564610cea4
PR = r10
PV = 0.1+git${SRCPV}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
