Hi Mark and Richard,
I am trying to setup a RPM multilib system that, it is a qemux86-64 base image
with MULTILIB_IMAGE_INSTALL = lib32-connman-gnome. With several fixes, the
build can pass.
However in run time testing I met a problem that, for those libraries whose
base/multilib versions
How should meta data be structured so that a layer can support a set
of systems using a set of processors?
For example, many of the 'eBox' systems use variants of the Vortex86
SoC. So, a set of machine files are needed for these (e.g. ebox-3300,
ebox-3500mx, etc.).
These have different
On 9/2/11 2:33 AM, Xu, Dongxiao wrote:
Hi Mark and Richard,
I am trying to setup a RPM multilib system that, it is a qemux86-64 base
image with MULTILIB_IMAGE_INSTALL = lib32-connman-gnome. With several
fixes, the build can pass.
However in run time testing I met a problem that, for those
On 11-09-02 03:26 AM, Chris Tapp wrote:
How should meta data be structured so that a layer can support a set of
systems using a set of processors?
For example, many of the 'eBox' systems use variants of the Vortex86
SoC. So, a set of machine files are needed for these (e.g. ebox-3300,
On Fri, Sep 2, 2011 at 10:48 AM, Mark Hatle mark.ha...@windriver.com wrote:
The normal OE approach is to resolve all items by run-time dependencies. That
is why a lot more is built then installed.
So if you want a system capable of running bash, you would create a task (and
related image)
On 11-09-01 04:41 PM, Saxena, Rahul wrote:
Removed duplicate statement
I noticed that these patches are Signed-off, can you confirm
your Sign-off so I can add it to the patches?
Bruce
---
meta/cfg/kernel-cache/bsp/fishriver/fishriver.scc | 1 -
1 files changed, 0 insertions(+), 1
On Fri, Sep 2, 2011 at 12:09 PM, Mark Hatle mark.ha...@windriver.com wrote:
For everything I see, that should work.
In classes/image.bbclass, RDEPENDS is augmented by the contents of
IMAGE_INSTALL, LINGUAS_INSTALL, MULTILIB_IMAGE_INSTALL, and
NORMAL_FEATURE_INSTALL.
The bitbake side is
On 9/2/11 1:36 PM, McClintock Matthew-B29882 wrote:
On Fri, Sep 2, 2011 at 12:09 PM, Mark Hatle mark.ha...@windriver.com wrote:
For everything I see, that should work.
In classes/image.bbclass, RDEPENDS is augmented by the contents of
IMAGE_INSTALL, LINGUAS_INSTALL, MULTILIB_IMAGE_INSTALL,
FYI: ipkg appears to work fine if you have
MULTILIB_IMAGE_INSTALL and MULTILIB_PACKAGE_ARCH set.
Will file a bug shortly.
-M
On Fri, Sep 2, 2011 at 1:56 PM, Mark Hatle mark.ha...@windriver.com wrote:
On 9/2/11 1:36 PM, McClintock Matthew-B29882 wrote:
On Fri, Sep 2, 2011 at 12:09 PM, Mark
On Fri, 2011-09-02 at 00:26 -0700, Chris Tapp wrote:
How should meta data be structured so that a layer can support a set
of systems using a set of processors?
For example, many of the 'eBox' systems use variants of the Vortex86
SoC. So, a set of machine files are needed for these (e.g.
Hi Mark,
-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com]
Sent: Friday, September 02, 2011 11:03 PM
To: Xu, Dongxiao
Cc: Richard Purdie (richard.pur...@linuxfoundation.org);
yocto@yoctoproject.org
Subject: Re: RPM multilib package installation issue
On
To match the accompanying 1.6 systemtap upgrade.
Please pull into linux-yocto-3.0/meta.
The following changes are available in the git repository at:
git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git
tzanussi/reenable-systemtap
Re-enable the 'systemtap feature' that turns on the kernel options required
for systemtap, a system-wide tracing tool.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
meta/cfg/kernel-cache/ktypes/standard/standard.scc |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On 09/01/2011 10:19 AM, Saul Wold wrote:
Seeing this change reminded me that we really should move grub_1.98 to
oe-core, is there any objection to this? Any reason this should not be
part of oe-core to support general x86_64 machines?
I am considering pushing to drop grub entirely from
14 matches
Mail list logo