[OE-core] [PATCH 1/1] qemu-script: Fix qemu seg fault if install Nvidia proprietary driver.
From: Zhai Edwin edwin.z...@intel.com This fix works on Ubuntu, and other distro can add its own path of Mesa's libGL Signed-off-by: Zhai Edwin edwin.z...@intel.com --- scripts/poky-qemu-internal | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/scripts/poky-qemu-internal b/scripts/poky-qemu-internal index c88d711..acaeb1b 100755 --- a/scripts/poky-qemu-internal +++ b/scripts/poky-qemu-internal @@ -448,20 +448,29 @@ else fi # qemu got segfault if linked with nVidia's libgl +GL_LD_PRELOAD=$LD_PRELOAD + if ldd $QEMUBIN | grep -i nvidia /dev/null then cat EOM WARNING: nVidia proprietary OpenGL libraries detected. nVidia's OpenGL libraries are known to have compatibility issues with qemu, resulting in a segfault. Please uninstall these drivers or ensure the mesa libGL -libraries precede nvidia's via LD_PRELOAD. +libraries precede nvidia's via LD_PRELOAD(Already do it on Ubuntu). EOM + +# Automatically use Ubuntu system's mesa libGL, other distro can add its own path +if grep -i ubuntu /etc/lsb-release /dev/null +then +echo Skip nVidia's libGL on Ubuntu! +GL_LD_PRELOAD=/usr/lib/libGL.so $LD_PRELOAD +fi fi echo Running $QEMU... # -no-reboot is a mandatory option - see bug #100 echo $QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append ''$KERNCMDLINE $SCRIPT_KERNEL_OPT'' -$QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append $KERNCMDLINE $SCRIPT_KERNEL_OPT +LD_PRELOAD=$GL_LD_PRELOAD $QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append $KERNCMDLINE $SCRIPT_KERNEL_OPT cleanup -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native
Richard Purdie wrote:
On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
Recently I have been looking into it and I've made some commits
..
1) As you said, after we install perl-native into its own directory,
any recipe not depending on perl-native doesn't see
${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
However, if we keep the current code, what's the bad consequence if
the recipe not depending on perl-native does see perl of perl-native?
looks no?
We have an assumption that perl is already on the system we're
building on. Perl is a relatively stable language with defined
compatibility and interoperability. Most recipes are therefore fine
using perl from the build system directly and don't need perl-native.
I think we defined a special name for the build system perl
(perl-native-runtime?). Better names are welcome but we should ensure
we use the right dependency in the right places.
The time to use perl-native instead of perl-native-runtime is where
any perl module is being built, perl itself is being built or
anything that has an explicit dependency on the perl version present.
Thanks for all the clarification!
3) In gnu-config_20080123.bb's do_install, I don't understand this
lines: here the != should be =? if [ ${BUILD_ARCH} !=
${TARGET_ARCH} ]; then sed -i -e
's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi
This means it only applies for non-native packages. (native has
BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
with things like the nativesdk packages where bindir != /usr/bin.
Thanks for the explanation!
My understanding about non-native package is target recipe (in this case
bindir=/usr/bin)
and -nativesdk recipe.
gnu-config_20080123.bb doesn't have -nativesdk version(BBCLASSEXTEND doesn't
contain nativesdk), so looks the sed replacement is useless at present?
e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit
host, BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked;
when building gnu-config, the sed will be invoked, but bindir is
just /usr/bin, so the replacement operation actually does nothing.
You can define a system where exec_prefix is and bindir is hence
/bin when it wouldn't do nothing.
And for gnu-config-native, I think we need do a
sed -i -e
's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g'
${D}${bindir}/gnu-configize Correct?
No, the whole point is to stop it seeing perl-native. Only perl itself
and modules should be using perl-native.
So gnu-config-native should use perl-native-runtime(i.e., the system perl) and
shouldn't depend on perl-native.
Howeve, there is a sed replacement in gnu-config-native's do_install:
-e 's,@autom4te_perllibdir@,${datadir}/autoconf,g
and meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in is intened
to be run with #! /usr/bin/env perl -- this incurs some race conditions:
1) if perl-natvie does populate_sysroot later than
${STAGING_BINDIR_NATIVE}/gnu-configize is invoked, /usr/bin/perl is used
but perl-native's modules are used due to the unshift @INC, $datadir in
gnu-configize.in.
This is just http://bugzilla.pokylinux.org/show_bug.cgi?id=941
2) if perl-natvie does populate_sysroot earlier than the gnu-configize
is invokded, we don't meet bug 941.
The above is the current situation. If we install perl-native into its own
sysroot, in the gnu-configize, the system perl is always found and used,
and we always meet with bug 941.
How can we fix bug 941 then?
BTW: the 2 lines at the beginning of gnu-configize.in is suspicious:
eval 'case $# in 0) exec /usr/bin/perl -S $0;; *) exec /usr/bin/perl -S $0
$@;; esac'
if 0;
I'm new to the synax of perl, but I believe the string after the eval is
not executed due to if 0.
Can we remove the 2 lines?
4) My last commit of the top 5 commits is a chaos... I'm trying to
replace every DEPENDS on perl-native with inherit perlnative.
I'm now stuck in fixing the build issues for libxml-parser-perl and
libxml-parser-perl-native.
I don't know how to fix get_perl_version and perl_get_libdirs in
cpan-base.bbclass -- for libxml-parser-perl-native, I have to manage
to add a /perl-native into STAGING_LIBDIR and libdir, but for
libxml-parser-perl, I can't change STAGING_LIBDIR and libdir. Can you
please help me out?
I'd suggest splitting this into two steps:
a) Check through all perl-native references and correct the ones that
should be perl-native-runtime.
b) Replace all remaining perl-native references with the class
dependency.
Ok, I'm checking all the references.
In step a), gnu-config would have a dependency on perl-native-runtime
so wouldn't use the perlnative class.
Please see my above reply.
Just for reference, using perl-native-runtime means that someone can
remove it from ASSUME_PROVIDED and provide a version of it themselves
if they so wish (using perl-native or otherwise).
I suspect you'll still have
Re: [OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native
On Fri, 2011-05-06 at 16:52 +0800, Cui, Dexuan wrote:
Richard Purdie wrote:
3) In gnu-config_20080123.bb's do_install, I don't understand this
lines: here the != should be =? if [ ${BUILD_ARCH} !=
${TARGET_ARCH} ]; then sed -i -e
's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi
This means it only applies for non-native packages. (native has
BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
with things like the nativesdk packages where bindir != /usr/bin.
Thanks for the explanation!
My understanding about non-native package is target recipe (in this case
bindir=/usr/bin)
and -nativesdk recipe.
gnu-config_20080123.bb doesn't have -nativesdk version(BBCLASSEXTEND doesn't
contain nativesdk), so looks the sed replacement is useless at present?
Not useless but not heavily used directly in Poky at this time.
DISTRO=minimal in OE for example sets exec_prefix= so bindir
becomes /bin.
e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit
host, BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked;
when building gnu-config, the sed will be invoked, but bindir is
just /usr/bin, so the replacement operation actually does nothing.
You can define a system where exec_prefix is and bindir is hence
/bin when it wouldn't do nothing.
As I mentioned here :)
And for gnu-config-native, I think we need do a
sed -i -e
's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g'
${D}${bindir}/gnu-configize Correct?
No, the whole point is to stop it seeing perl-native. Only perl itself
and modules should be using perl-native.
So gnu-config-native should use perl-native-runtime(i.e., the system perl) and
shouldn't depend on perl-native.
Correct.
Howeve, there is a sed replacement in gnu-config-native's do_install:
-e 's,@autom4te_perllibdir@,${datadir}/autoconf,g
Don't confuse the data files that autoconf installs and references with
a program that is mixing the perl-native binary and libraries with the
host system ones. I think the above change is harmless as its just
linking in some perl files.
and meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in is intened
to be run with #! /usr/bin/env perl -- this incurs some race conditions:
This is more problematic though as it does this but also references
perl's full path more directly further in the file. This is the real
problem as its mixing and matching two different perl versions.
1) if perl-natvie does populate_sysroot later than
${STAGING_BINDIR_NATIVE}/gnu-configize is invoked, /usr/bin/perl is used
but perl-native's modules are used due to the unshift @INC, $datadir in
gnu-configize.in.
This is just http://bugzilla.pokylinux.org/show_bug.cgi?id=941
2) if perl-natvie does populate_sysroot earlier than the gnu-configize
is invokded, we don't meet bug 941.
The above is the current situation. If we install perl-native into its own
sysroot, in the gnu-configize, the system perl is always found and used,
and we always meet with bug 941.
It doesn't matter which perl we use but we do need to use the same perl
consistently.
How can we fix bug 941 then?
BTW: the 2 lines at the beginning of gnu-configize.in is suspicious:
eval 'case $# in 0) exec /usr/bin/perl -S $0;; *) exec /usr/bin/perl -S
$0 $@;; esac'
if 0;
I'm new to the synax of perl, but I believe the string after the eval is
not executed due to if 0.
Can we remove the 2 lines?
I ended up getting some other opinions on this code as it makes no sense
to me either. The best guess I've heard is its allowing the script to
work in shell and perl. I then looked at other autoconf scripts and they
use this same construct so its obviously copied from there. I agree the
style is pointless and we could remove it but it is at least consistent
with the rest of autoconf.
I went digging and was surprised to see many hardcoded paths to perl in
the autoconf scripts. It turns out path_prog_fixes.patch isn't being
applied to autoconf-native, only the target version. When we do apply
it, it turns out the patch is buggy in the native case and I had to
change @bindir@/env to /usr/bin/env to make it work since we don't have
a env in the STAGING_BINDIR_NATIVE.
My point is that we need to be consistent about which perl version we
use in these scripts. Either we use one from the environment using env
or we hardcode to /usr/bin/perl. Since the perl-native binary won't be
in the path for any of these, autodetecting and letting it hardcode is
probably fine. It has the advantage that if there are any binary modules
ever involved, they'll match the version of perl they were built for
regardless of whether perl-native is a dependency or not. If someone
adds a perl-native dependency to autoconf-native, it will also still
select the correct perl.
Whilst doing this we need to keep bug #968 in mind and ensure that if
perl-native is used, all of perl-native is in the sysroot.
Re: [OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native
Op 6 mei 2011, om 13:31 heeft Richard Purdie het volgende geschreven:
On Fri, 2011-05-06 at 16:52 +0800, Cui, Dexuan wrote:
Richard Purdie wrote:
3) In gnu-config_20080123.bb's do_install, I don't understand this
lines: here the != should be =? if [ ${BUILD_ARCH} !=
${TARGET_ARCH} ]; then sed -i -e
's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi
This means it only applies for non-native packages. (native has
BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
with things like the nativesdk packages where bindir != /usr/bin.
Thanks for the explanation!
My understanding about non-native package is target recipe (in this case
bindir=/usr/bin)
and -nativesdk recipe.
gnu-config_20080123.bb doesn't have -nativesdk version(BBCLASSEXTEND doesn't
contain nativesdk), so looks the sed replacement is useless at present?
Not useless but not heavily used directly in Poky at this time.
DISTRO=minimal in OE for example sets exec_prefix= so bindir
becomes /bin.
Nitpick: that's DISTRO=micro
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for remote layering.
Hi Jeremy, Sorry for the delayed response, I took the opportunity to take some vacation for a change and its taken me a few days to catch up on email. Thanks for posting this. Whilst some of what I mention below may sound negative, its not meant this way and what you have gives a nice basis to start some discussion from on this topic. I do want to take a step back and ensure we integrate this functionality at the right level within the stack. I've made comments below. On Thu, 2011-04-28 at 11:09 -0700, Jeremy Puhlman wrote: The bulk of this patch is based on Chris Larson's collection.inc, but refactored for use inside bitbake, and for layers. Adds two new configuration options: LAYER_UNPACKDIR - directory to unpack downloaded layers for use in configuration. LAYER_REMOTE_STASH - location to store downloaded layers for use in configuration. Layers can be specified in the current manner: BBLAYERS = \ /path/to/layer/one \ /path/to/layer/two \ Or you can specify uris: BBLAYERS = \ http://url.to.my.tarball/tarball.tar.gz \ git://gitserver.com/git/repo;proto=http \ /path/to/layer/three \ file:///path/to/layer/four \ This is good but what I don't really like about this is that whilst you can specify where to get the layer from, it isn't clear where the layer ends up locally. Compare the above to something like: BBLAYERS = \ /path/to/layer/one;srcuri=http://url.to.my.tarball/tarball.tar.gz \ /path/to/layer/two;srcuri=git://gitserver.com/git/repo;proto=http \ /path/to/layer/three \ /path/to/layer/four \ This is more ugly but it does clearly set an expectation for both where its coming from and where it ends up on disk. It also means we can then set specific revisions to checkout or other information e.g. whether the revisions should auto-increment. The syntax would probably come naturally to anyone who has used SRC_URI (and hence it also flows nicely into the fetcher code). Currently there is a single layer option, that can be added to a uri, layerBase=subpath. This option would be used to specify if a layer starts somewhere other then the base of the tarball/scm repository. For example if you wanted to add oe-core you would do: Ideally this could become an option that any of our fetchers would support... lib/bb/cooker.py |3 +- lib/bb/fetch/layer.py | 65 lib/bb/fetch2/layer.py | 76 ++ lib/bb/remotelayer.py | 197 I'm not going to dive into the patches at this point but layer isn't really a fetcher as such as it doesn't correspond to a specific source type, its just a wrapper around other fetch methods. I'm therefore a little worried this confuses the abstraction we currently have there. Going back to the high level approach discussion, I'm also wondering if there should be some bblayers tool which gets run prior to bitbake (maybe automatically in some cases) which handles the parsing of the BBLAYERS options and does whatever is needed to handle the setup there, then hands off to bitbake itself. I'm very keen to get the abstraction level of this code right so I'd be interested in your (and others) thoughts on this... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC] systemd units packaging
Hi,
The past few days I have gotten systemd to work in OE.dev and I have some
questions on how to do in the oe-core universe. First some background:
Systemd is a /sbin/init replacement using ideas from apples launchd like socket
activation. Startup scripts are replaced by .ini like files:
sshd.socket:
--
[Unit]
Description=OpenSSH Server Socket.
Conflicts=sshd.service
[Socket]
ListenStream=22
Accept=yes
[Install]
WantedBy=sockets.target
--
sshd@.service
--
[Unit]
Description=OpenSSH per connection server daemon.
After=syslog.target
[Service]
ExecStartPre=/usr/sbin/sshd -t
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket
--
The above 2 units combined will start openssh as soon as port 22 is being
accessed. This is comparable with inetd. For sysV style init you can use
something like this:
sshd.service:
--
[Unit]
Description=OpenSSH server daemon.
After=syslog.target network.target
[Service]
Type=forking
PIDFile=/var/run/sshd.pid
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd $OPTIONS
[Install]
WantedBy=multi-user.target
--
All those files are placed in /lib/systemd/system. You can make those exec the
old sysv scripts if you wish.
Now onto my issues:
packaging:
In OE .dev I added FILES_${PN} += ${base_libdir}/systemd to udev,
dbus, rsyslog and avahi. This means we end up with both sysV script and systemd
units. What I would like to have is ${PN}-sysvinit and ${PN}-systemd and the
image recipe can choose which init systems gets used. Is something like that
possible? Are there better ways? Note that systemd support sysV initscripts as
well, but it needs some care with naming. As I understand it, if a unit is
found with the same name as a sysV script, only the unit will get used.
A rootfs postprocess command that deletes /etc/init.d won't work, since it will
come back when upgrading the packages.
building:
At the moment systemd enabled software installs the units regardless or
config options. What should be do with software that has an option for that?
And what if we need to patch the units files in? The initsystem is a choice at
the image level, so artificially limiting it to a distro choice is not a good
idea.
sharing:
The Arch people have a github with their custom units:
https://github.com/falconindy/systemd-arch-units/ Do we use those? Do we use
fedora ones https://bugzilla.redhat.com/show_bug.cgi?id=697698 ? People on
#systemd are talking about a shared repo on fd.o, but nothing tangible yet.
And related to this: how do I get the installed but not packaged output back?
The bitbake logging changes are hiding it now, which is counterproductive.
So, what are your thoughts on all this?
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] package.bbclass: convert unpackaged file message from 'info' to 'warn' so that it shows up on the console
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/classes/package.bbclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index e6b3df7..082f233 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -676,9 +676,9 @@ python populate_packages () {
unshipped.append(path)
if unshipped != []:
- bb.note(the following files were installed but not shipped in
any package:)
+ bb.warn(the following files were installed but not shipped in
any package:)
for f in unshipped:
- bb.note( + f)
+ bb.warn( + f)
bb.build.exec_func(package_name_hook, d)
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package.bbclass: convert unpackaged file message from 'info' to 'warn' so that it shows up on the console
Acked-by: Mark Hatle mark.ha...@windriver.com
On 5/6/11 9:48 AM, Koen Kooi wrote:
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/classes/package.bbclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index e6b3df7..082f233 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -676,9 +676,9 @@ python populate_packages () {
unshipped.append(path)
if unshipped != []:
- bb.note(the following files were installed but not shipped in
any package:)
+ bb.warn(the following files were installed but not shipped in
any package:)
for f in unshipped:
- bb.note( + f)
+ bb.warn( + f)
bb.build.exec_func(package_name_hook, d)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] systemd units packaging
On Fri, May 6, 2011 at 11:51, Koen Kooi k...@dominion.thruhere.net wrote:
So, is having both sets inside ${PN} a dealbreaker?
I think it is not BUT this choice could be a distro choice. So I see as:
USE_INIT=(sysv|systemd|both)
Being both the default.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] systemd units packaging
Op 6 mei 2011, om 17:36 heeft Otavio Salvador het volgende geschreven:
On Fri, May 6, 2011 at 11:51, Koen Kooi k...@dominion.thruhere.net wrote:
So, is having both sets inside ${PN} a dealbreaker?
I think it is not BUT this choice could be a distro choice.
Everything can be a distro choice, you can make gtk/qt or even qt-x11/qt-e a
distro choice. The point is to see what is an image choice and what isn't.
Defaulting to distro choice is a recipe for disaster (pun intended)
I do *NOT* want to write a new distro.conf for every silly option out there.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] [PATCH 1/1] linux-yocto: move non-core machines to meta-yocto
On 05/06/2011 11:44 AM, Bruce Ashfield wrote:
The machine configuration of the non-core (non-qemu) machines
has moved to meta-yocto. Moving the branch mappings, compatibility
and SRCREVs of these machines to meta-yocto should also be
done.
Anyone using meta-yocto to build these machines will see no impact
from this change.
Signed-off-by: Bruce Ashfieldbruce.ashfi...@windriver.com
---
meta-yocto/conf/layer.conf |3 ++-
.../linux/linux-yocto-stable_git.bbappend | 12
.../recipes-kernel/linux/linux-yocto_git.bbappend | 12
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 10 +-
meta/recipes-kernel/linux/linux-yocto_git.bb | 11 +--
Bruce,
This need to be 2 pull requests, since the first 4 files are actually in
meta-yotco, part of poky.git and the linux-yocto_git.bb is in OE-core
Please split this into 2 requests, one for oe-core, just the
linux-yocto_git.bb file
and a second one to poky with the reset.
I also noted that you list the emenlow in one of the .bbappend files,
but only as SRCREV_machine_emenlow, should that be there with Paul's
moving emenlow to meta-intel?
Sau!
5 files changed, 28 insertions(+), 20 deletions(-)
create mode 100644
meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
create mode 100644 meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend
diff --git a/meta-yocto/conf/layer.conf b/meta-yocto/conf/layer.conf
index f11d8ed..68786b2 100644
--- a/meta-yocto/conf/layer.conf
+++ b/meta-yocto/conf/layer.conf
@@ -2,7 +2,8 @@
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a packages directory, add to BBFILES
-BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb
+BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += yocto
BBFILE_PATTERN_yocto := ^${LAYERDIR}/
diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
b/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
new file mode 100644
index 000..ea0287d
--- /dev/null
+++ b/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
@@ -0,0 +1,12 @@
+KMACHINE_atom-pc = atom-pc
+KMACHINE_routerstationpro = routerstationpro
+KMACHINE_mpc8315e-rdb = fsl-mpc8315e-rdb
+KMACHINE_beagleboard = beagleboard
+
+SRCREV_machine_atom-pc = 72ca49ab08b8eb475cec82a10049503602325791
+SRCREV_machine_routerstationpro = 49745cd45c92a89e70c6e2334caa80818c134562
+SRCREV_machine_mpc8315e-rdb = a1c0ed6bf4060c10874b2a8547d81b3169dcf16a
+SRCREV_machine_beagleboard = ef7f944e773950d4016b7643f9ecf052bbe250cd
+
+COMPATIBLE_MACHINE += (atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)
+
diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend
b/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend
new file mode 100644
index 000..e4aa7fd
--- /dev/null
+++ b/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend
@@ -0,0 +1,12 @@
+KMACHINE_atom-pc = yocto/standard/common-pc/atom-pc
+KMACHINE_routerstationpro = yocto/standard/routerstationpro
+KMACHINE_mpc8315e-rdb = yocto/standard/fsl-mpc8315e-rdb
+KMACHINE_beagleboard = yocto/standard/beagleboard
+
+SRCREV_machine_emenlow = c3bbcb676f929c4fc0511a6e66494b8770d015a1
+SRCREV_machine_atom-pc = b906f358fd404a1e74a961f25079274e0d933ee1
+SRCREV_machine_routerstationpro = 95ca94d2e71ca2db6822a37a7f575fa79c3d05d0
+SRCREV_machine_mpc8315e-rdb = 53c800c244e73d81d2832f6da306eeae3b09e5dc
+SRCREV_machine_beagleboard = b906f358fd404a1e74a961f25079274e0d933ee1
+
+COMPATIBLE_MACHINE = (mpc8315e-rdb|routerstationpro|beagleboard)
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
index 93b06fd..66991ae 100644
--- a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -7,10 +7,6 @@ KMACHINE_qemux86-64 = common_pc_64
KMACHINE_qemuppc = qemu_ppc32
KMACHINE_qemumips = mti_malta32_be
KMACHINE_qemuarm = arm_versatile_926ejs
-KMACHINE_atom-pc = atom-pc
-KMACHINE_routerstationpro = routerstationpro
-KMACHINE_mpc8315e-rdb = fsl-mpc8315e-rdb
-KMACHINE_beagleboard = beagleboard
LINUX_VERSION ?= 2.6.34
LINUX_VERSION_EXTENSION ?= -yocto-${LINUX_KERNEL_TYPE_EXTENSION}
@@ -23,10 +19,6 @@ SRCREV_machine_qemumips =
c32d40f960e3c89d07f079bec4c96dcbfc749f0b
SRCREV_machine_qemuppc = 96d6bc31d3caaf62a966255479cc5cee0e76b1e9
SRCREV_machine_qemux86 = 72ca49ab08b8eb475cec82a10049503602325791
SRCREV_machine_qemux86-64 = 72ca49ab08b8eb475cec82a10049503602325791
-SRCREV_machine_atom-pc = 72ca49ab08b8eb475cec82a10049503602325791
-SRCREV_machine_routerstationpro = 49745cd45c92a89e70c6e2334caa80818c134562
-SRCREV_machine_mpc8315e-rdb = a1c0ed6bf4060c10874b2a8547d81b3169dcf16a
-SRCREV_machine_beagleboard = ef7f944e773950d4016b7643f9ecf052bbe250cd
SRCREV_machine = 72ca49ab08b8eb475cec82a10049503602325791
SRCREV_meta =
Re: [OE-core] [PATCH 0/1] qemu-script: Fix qemu segfault with Nvidia's proprietary driver
On 05/06/2011 01:36 AM, Zhai Edwin wrote: From: Zhai Edwinedwin.z...@intel.com Previsous solution is only giving warnings as different distro has different path of mesa libGL. This patch try to use different path for different distro after looking at /etc/lsb-release per Raj's suggestion. Ubuntu is there, and other distro handling can be easily added. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: gzhai/fix3 Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/fix3 Thanks, Zhai Edwinedwin.z...@intel.com --- Zhai Edwin (1): qemu-script: Fix qemu seg fault if install Nvidia proprietary driver. scripts/poky-qemu-internal | 13 +++-- I think that you are using the old script name, I think that you should be changing runqemu-internal, not poky-qemu-internal Please correct this. Sau! 1 files changed, 11 insertions(+), 2 deletions(-) ___ 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
