On Wed, 2010-11-03 at 09:27 +0100, Frans Meulenbroeks wrote:

2010/11/3 Frans Meulenbroeks <fransmeulenbroeks@...>:

Dear all,

Not sure whether I should sent this here or to the poky ML. Trying
here first, fee free to forward/redirect.

After my initial success of building poky 4.0 with the delivered
config, I decided to try to add my own layer (with some private
recipes), meanwhile also switching to MACHINE = "beagleboard". These
recipes build under OE.
In order to get things parsing I had to rework a few legacy staging
things (no big deal).

Also I got an error:
NOTE: Handling BitBake files: - (0053/0886) [ 5 %]NOTE: Error
expanding variable do_package
ERROR: string index out of range while parsing
/home/frans/yocto/poky-laverne-4.0/tv.axon.openembedded.2010/recipes/linux/linux-factory-sygtd1_2.6.34.bb

For now I removed the do_package function. No idea if that is sound.

After doing so the parsing goes well but I get an interesting
traceback, even if no recipe is given. See the log below.
I suspect this is because a var is referenced somewhere but the var is
not initialised. Guess this should not happen.
Then again my pythonese is not good enough to diagnose this.
Any suggestion is appreciated (meanwhile I'll try to use bisecting to
find the cause).

Best regards, Frans

Nevermind, already found the cause of the traceback. I accidently ran
bitbake in the wrong dir.
My default setup is such that BBPATH etc is set in such a way that I
can effectively run bitbake from any dir once the env is set.
Guess it would be nice if bitbake would have given a decent error msg though.

Frans (btw: still confused on the do_package thing)

Can you point at a copy of this recipe or the do_package function? At
this point its hard to guess what the problem might be. I suspect you
might be right about there being a reference to but not a definition of
a variable.

Cheers,

Richard

2010/11/3 Richard Purdie <rpurdie@...>:

On Wed, 2010-11-03 at 09:27 +0100, Frans Meulenbroeks wrote:

ess it would be nice if bitbake would have given a decent error msg though.

Frans (btw: still confused on the do_package thing)

Can you point at a copy of this recipe or the do_package function? At
this point its hard to guess what the problem might be. I suspect you
might be right about there being a reference to but not a definition of
a variable.

Richard, the recipe was a private kernel recipe which actually didn't
do too much.

It reads:

recipes/linux/linux-factory_2.6.34.bb:

FILESPATHPKG_append = ":linux-${PV}"

require linux_${PV}.bb

PACKAGES = ""
PROVIDES = ""
KERNEL_IMAGE_BASE_NAME = "${KERNEL_IMAGETYPE}-${PN}-${PV}-${PR}-${MACHINE}"
KERNEL_IMAGE_SYMLINK_NAME = "${KERNEL_IMAGETYPE}-${PN}-${MACHINE}"

S = "${WORKDIR}/linux-${PV}"

do_populate_sysroot() {
}

do_install() {
}

python do_package() {
}

As you see the do_package function is empty.
Basically this recipe was created as a mechanism (not necessarily the
best :-) ) to create a 2nd kernel for the same hardware which could be
used for factory upgrade. Idea is that this kernel has a much smaller
defconfig.

Actually I don't really know any more how/why I came to the code
above. I guess I just copied some stuff from oe kexecboot recipes. It
did what I needed it to do, so I just moved on to the next issue.
(and I must admit that I have no idea why the python thingie is there
before do_package, but I saw the same in a few other oe recipes).

Frans.

On 11/3/10 2:58 AM, Qing He wrote:

On Mon, 2010-11-01 at 23:37 +0800, Mark Hatle wrote:

(Sorry for the late response, today's my first day back from CELF)

On 10/21/10 8:47 PM, Qing He wrote:

On Thu, 2010-10-21 at 23:18 +0800, Mark Hatle wrote:

On 10/21/10 3:33 AM, Qing He wrote:

1. what uses for independent packages is called "noarch", "all" is not
recognized, something depends on update-rc.d won't be installed
because of missing dependency

We can certainly look into translating "all" to "noarch" post 0.9. That might
make it easier for people coming from the RPM world, to understand what is in
the package.

1. rename *.all.rpm to *.noarch.rpm

We can certainly do this easily.

If noarch is universally used in RPM word, I think we should use it.

My preference is staying with the Poky 'arch' naming... but renaming to noarch
is fine, and unless Richard or someone else sees an issue it could be used as a
temporary workaround. (There are a few places like rootfs generation that we'll
have to translate "all" to "noarch".. if we decide to do this.)

This is good. I may test if this works and let's see if Richard has any
comments on it.

Thanks for the info. If we are going for dynamic platform specs, it
doesn't really matter whether we have things like qemuarm or not, does it?

Ya, if we are able to do things dynamically, then the naming is no longer
important. That's really my hope as to how we implement the RPM components.

It seems to be an elegant solution, but need some efforts to find out
how this can fit in current zypper.

That would be some work to do, maybe 1.0 is a good time to get zypper
and package upgrade truely working.

Yes, we also need to get multi-arch as well.. (i.e. 32-bit and 64-bit at the
same time) working. I'm guessing there will be some Zypper interactions there
as well.

I don't really have ideas how this is done. I think on debian this is
actually avoided and i386 packages are repackaged as lib32xxx for x86_64
platform.

Since Poky does not yet have the ability to deal with Multiarch builds, this is
something we will have to work on designing as we get closer to Yocto 1.0.

Within RPM, the rpm package manager understands all of the "types" of each file
in the system. When you ask to install (note, not upgrade) two packages of the
same name the system checks the files.

When a conflict is identified, if the contents of the files are the same,
nothing is done -- no error is generated.

If the contents of the file are different, and the file is tagged as a
configuration file, then either first or last in wins (I don't remember which)
-- no error is generated.

If the contents of the file are different, and the file type is NOT ELF (and the
above has no already detected), then an error is generated and installation stops.

if the contents of the file are different, and the file type is ELF... then
there is a weighting algorithm that is used. Depending on the configuration the
following could happen:

multiarch is not allowed -- an error is generated

multiarch is allowed -- one of the components though is not an allowed multiarch
-- an error is generated (this could be the mips case of o32, n32 and n64 on the
same system. You could prevent someone from installing say o32 binaries.)

multiarch is allowed -- a 'winner' is chosen based on the system configuration.
The winner is installed, and the loser is not installed -- no error is generated.

Hmm, this is not quite what I've been thinking about. The problem is
the shared library, and the library path renaming.

The above winner works fine for executables, nobody needs different arch
versions of a same binary, but it's possible that several different
archs are used for different binaries, that's where the library problem
comes in.

Thats the full purpose of the winner is to deal with conflicts. Libraries should never conflict, if they do it's a bug in the library.

Let's say we have an i586 `ls', and an x86_64 `cp' that coexist in the same
box, they would possibly link to two different ld-linux.so and libc.so (this
scenario is common requirement on x86, esp. x86_64). If 32bit rpms can
be installed to 64bit platforms directly without any modification, that
would be great.

The file dependencies that I added in the 0.9 work will resolve this. Each library (file) is tagged with various dependency information. The information includes ELF types and will automatically choose the correct version (or versions) of a given library in order to resolve dependencies. (We'll have to double check it's working correctly of course, but the work is already there, just not verified. This is true for all packaging mechanisms...)

I guess the deb way to solve this is to create a special kind of
package, namely `lib32c_2.10.1-r1.x86_64.deb', which installs something
like /lib32/ld-linux-i586.so.2. If the executable can links to it, the
dedicated ld.so cache can get most of its library path right. However,
sadly, this special lib32 and maybe the 32bit executable package, may
not be installable on pure i586 archs.

That is something I would like to avoid as we move toward multiarch support in Poky. I want to be able to re-use packages from any architecture and not generate "special" 32-bit versions. There really should be no reason to do so in any packaging method. (The 32-bit/64-bit executable collision workaround really shouldn't be necessary if the rest of the system is done right..)

So should this kind of multiarch be concerned, where multiarch packages
coexist instead of being exlusive?

Multiarch need to co-exist.. The three primary cases I'm worried about are:

ia32: x86_32 & x86_64
ppc: ppc32 & ppc64
mips: mips_o32 & mips_n32 & mips_n64

I've seen situations in each where the "default" ABI type is different depending on customer needs, but generally speaking the defaults become:

ia32: x86_64
ppc: ppc32
mips: mips_o32 or mips_n32

(note the mips case is only for a mips64 compatible processor)

Thanks,
Qing

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =
"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans

On 11/3/10 10:34 AM, Frans Meulenbroeks wrote:

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =
"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

At this point we have no added any e500 support to Poky.

It would certainly be interesting to me to add/enable e500 support, as well as other spe optimizations that eglibc might provide.

--Mark

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

I can definitely guarantee that this would work in
the yocto kernel (with a small local step for you), in
fact, I've got a full BSP for this, and any of the extra
features in the kernel (SPE, IEEE float, lttng, etc) will
all work for any e500* board.

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Cheers,

Bruce

"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto

2010/11/3 Bruce Ashfield <bruce.ashfield@...>:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

I can definitely guarantee that this would work in
the yocto kernel (with a small local step for you), in
fact, I've got a full BSP for this, and any of the extra
features in the kernel (SPE, IEEE float, lttng, etc) will
all work for any e500* board.

Sounds good. Is there anything you could share as a starting point?

Frans

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Cheers,

Bruce

"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto

On 10-11-03 03:32 PM, Frans Meulenbroeks wrote:

2010/11/3 Bruce Ashfield<bruce.ashfield@...>:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

I can definitely guarantee that this would work in
the yocto kernel (with a small local step for you), in
fact, I've got a full BSP for this, and any of the extra
features in the kernel (SPE, IEEE float, lttng, etc) will
all work for any e500* board.

Sounds good. Is there anything you could share as a starting point?

There is. And I'll clean it up a bit. The BSP bootstrap
currently has a couple of different steps that are local
to your build (but eventually merge to the kernel tree if
a board is supported) which allow you to work directly in
the kernel git repo for your board work.

In the near future I'll have some updates for BSP
bootstrapping, both code and documents. But I'm more
than happy to walk through this right now if there
is interest.

Cheers,

Bruce

Frans

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Cheers,

Bruce

"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto

test

Hello Bruce,

On Wed, Nov 3, 2010 at 4:49 PM, Bruce Ashfield
<bruce.ashfield@...> wrote:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Was combo did you see problems with?

I added e500v2 support to OpenEmbedded more than one year ago and have
not seen issues yet in userspace GCC.
Recently been playing with SPE which also ran fine:
http://www.sidebranch.nl/spe-apu

Regards,
--
Leon

On 10-11-04 09:53 AM, Leon Woestenberg wrote:

Hello Bruce,

On Wed, Nov 3, 2010 at 4:49 PM, Bruce Ashfield
<bruce.ashfield@...> wrote:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Was combo did you see problems with?

It was particular to the mpc8315e config.

I added e500v2 support to OpenEmbedded more than one year ago and have
not seen issues yet in userspace GCC.
Recently been playing with SPE which also ran fine:
http://www.sidebranch.nl/spe-apu

Runtime on the target is fine, since this is all well known
and working (we've had SPE/e500/e500v2 BSPs working for
quite some time), the issue was specific to -Os and gcc 4.5
bootstrap building.

These have all largely been resolved now, and a minor kernel
patch has the powerpc kernel boot code building and working,
and cleanups can happen in our post yocto 0.9 efforts.

Cheers,

Bruce

Regards,

On 11/4/10 8:53 AM, Leon Woestenberg wrote:

Hello Bruce,

On Wed, Nov 3, 2010 at 4:49 PM, Bruce Ashfield
<bruce.ashfield@...> wrote:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Was combo did you see problems with?

I added e500v2 support to OpenEmbedded more than one year ago and have
not seen issues yet in userspace GCC.
Recently been playing with SPE which also ran fine:
http://www.sidebranch.nl/spe-apu

Regards,

I'm not sure we have all of the pieces in place yet in the toolchain.

My quick looking of my own e500v1 & e500v2 support includes both libc patches and compiler patches.

Just an FYI.. the compiler flags for e500v1:

-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe

and for e500v2:

-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe

Neither of those would be compatible with the existing "ppc" packaging arch. We will need to generate at least one new packaging arch type, likely 2 (one for each). Maybe called ppc_spe or something similar?

The key thing is that each of these cpu's has not only additional SPE instructions, but also additional registers, specific to those instructions, to pass values from function to function. It's not just using the PPC soft-float ABI..

--Mark

I'm sitting in a talk by Arnd Bergmann (IBM) at LPC. He's is speaking
about "porting Linux to a new architecture, done right" and among the
build systems he lists as good starting point he mentioned yocto :-)

/D

--
Dirk Hohndel
Intel Open Source Technology Center

Hello Mark,

On Thu, Nov 4, 2010 at 6:20 PM, Mark Hatle <mark.hatle@...> wrote:

On 11/4/10 8:53 AM, Leon Woestenberg wrote:
Just an FYI.. the compiler flags for e500v1:

-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe

and for e500v2:

-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe

Neither of those would be compatible with the existing "ppc" packaging arch.
 We will need to generate at least one new packaging arch type, likely 2
(one for each).  Maybe called ppc_spe or something similar?

In OpenEmbedded we use the core variant as the packaging name:

TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
-mfloat-gprs=double"
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"

Does that make sense?

Regards,
--
Leon 'likewise' Woestenberg

On 11/4/10 1:02 PM, Leon Woestenberg wrote:

Hello Mark,

On Thu, Nov 4, 2010 at 6:20 PM, Mark Hatle<mark.hatle@...> wrote:

On 11/4/10 8:53 AM, Leon Woestenberg wrote:
Just an FYI.. the compiler flags for e500v1:

-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe

and for e500v2:

-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe

Neither of those would be compatible with the existing "ppc" packaging arch.
We will need to generate at least one new packaging arch type, likely 2
(one for each). Maybe called ppc_spe or something similar?

In OpenEmbedded we use the core variant as the packaging name:

TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
-mfloat-gprs=double"
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"

Does that make sense?

Regards,

I think this is an area we need to coordinate.. I'm not against calling is ppce500v2 for right now. However, I think this is a place we need to coordinate efforts. I'm going to attempt to pull together a list of Linux ABIs & potential optimizations in the Yocto wiki.

The reason I bring this up is that over the years at Wind River, and my previous experience at MontaVista... and watching Emdebian and other projects.. _everyone_ names their package architectures differently.. because people only have a small view on the problem. We finally have enough history to have a chance at indicating what the actual ABIs are, and how the compatibility matrix may fill out. (also giving us a change to finally give these architectures reasonable naming schemes!)

--Mark

Hello Mark,

On Thu, Nov 4, 2010 at 7:18 PM, Mark Hatle <mark.hatle@...> wrote:

On 11/4/10 1:02 PM, Leon Woestenberg wrote:

and for e500v2:
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe
Neither of those would be compatible with the existing "ppc" packaging
arch.
 We will need to generate at least one new packaging arch type, likely 2
(one for each).  Maybe called ppc_spe or something similar?

In OpenEmbedded we use the core variant as the packaging name:

TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
-mfloat-gprs=double"
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"

Does that make sense?

I think this is an area we need to coordinate.. I'm not against calling is
ppce500v2 for right now.  However, I think this is a place we need to
coordinate efforts.  I'm going to attempt to pull together a list of Linux
ABIs & potential optimizations in the Yocto wiki.

The reason I bring this up is that over the years at Wind River, and my
previous experience at MontaVista... and watching Emdebian and other
projects.. _everyone_ names their package architectures differently..
because people only have a small view on the problem.  We finally have
enough history to have a chance at indicating what the actual ABIs are, and
how the compatibility matrix may fill out.  (also giving us a change to
finally give these architectures reasonable naming schemes!)

I don't see how we could be "final" on this, it seems a returning
topic every few years.

To bring in the OpenEmbedded arch namespace and our optimizations,
from the "master" branch at OpenEmbedded:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/conf/machine/include?h=master

Regards,
--
Leon

On 11/4/10 1:43 PM, Leon Woestenberg wrote:

Hello Mark,

On Thu, Nov 4, 2010 at 7:18 PM, Mark Hatle<mark.hatle@...> wrote:

On 11/4/10 1:02 PM, Leon Woestenberg wrote:

and for e500v2:
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe
Neither of those would be compatible with the existing "ppc" packaging
arch.
We will need to generate at least one new packaging arch type, likely 2
(one for each). Maybe called ppc_spe or something similar?

In OpenEmbedded we use the core variant as the packaging name:

TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
-mfloat-gprs=double"
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"

Does that make sense?

I think this is an area we need to coordinate.. I'm not against calling is
ppce500v2 for right now. However, I think this is a place we need to
coordinate efforts. I'm going to attempt to pull together a list of Linux
ABIs& potential optimizations in the Yocto wiki.

The reason I bring this up is that over the years at Wind River, and my
previous experience at MontaVista... and watching Emdebian and other
projects.. _everyone_ names their package architectures differently..
because people only have a small view on the problem. We finally have
enough history to have a chance at indicating what the actual ABIs are, and
how the compatibility matrix may fill out. (also giving us a change to
finally give these architectures reasonable naming schemes!)

I don't see how we could be "final" on this, it seems a returning
topic every few years.

To bring in the OpenEmbedded arch namespace and our optimizations,
from the "master" branch at OpenEmbedded:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/conf/machine/include?h=master

This is a place where I think the Yocto Project can help. We're likely never going to have a final answer.. but what we'll be able to do is give these impromptu ABIs reasonable names so when people talk, everyone can be talking about the same thing..

Then within the Yocto Project's build environment we can promote these namings as part of the implementation...

Open Embedded, and everyone else has legacy associated with their names, which we can try to either coordinate -- or at least help document...

--Mark

Regards,

On 11/01/2010 06:35 AM, Stewart, David C wrote:

I can buy another server and contribute it to the build effort. I had
intended to buy one this quarter to begin hosting yoctoproject.org
and a source mirror, but we could offload part of the builds to it as
well.

Great, thanks Dave! :)

I have spec'ed out and initiated an order for our newest server. In case anyone likes to geek out on hardware specs, here they are:

Dell PowerEdge R710
2x Xeon X5680 @ 3.33Ghz
24 GB RAM
6x 1.5 TB hard drives for use in a RAID5 array

While it's not a 4-processor system, the additional resources should be sufficient for us to tackle our resource problems my distributing the workload more evenly.

The system will likely arrive and be set up around the end of the month.

Scott

This is a rebased and resent version of that I sent to poky@... (Thanks to Mark and Saul's suggestion).
Since this is a non poky core change, I post this version in this mailing list.
Please review it and comment.

Thanks,
-- Dexuan

$ scripts/create-pull-request -r 2ecf311fbca970f6ea2d80accc3f925b097b664e -b dcui/master
Note: <commit_id> parameter assumed as 'HEAD'

meta/recipes-core/busybox/busybox-1.16.2/defconfig | 14 +++++++-------
meta/recipes-core/eglibc/eglibc-2.12/etc/ld.so.conf | 2 --
meta/recipes-core/eglibc/eglibc-package.inc | 2 +-
meta/recipes-core/eglibc/eglibc_2.12.bb | 2 +-
4 files changed, 9 insertions(+), 11 deletions(-)

Dexuan Cui (2):
busybox: enable more options for tar to support more file formats.
eglibc: install an empty /etc/ld.so.conf into target

Pull URL: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master

commit 032856f340075390052eeeee15d1e1495fe2d94b
Author: Dexuan Cui <dexuan.cui@...>
Date: Fri Nov 5 08:35:54 2010 +0800

eglibc: install an empty /etc/ld.so.conf into target

We add ${sysconfdir} into FILES_${PN} to avoid the below spurious warning

ldconfig: Can't open configuration file /etc/ld.so.conf: No such file or
directory

The file ld.so.conf can be empty because now we don't install
/usr/local/lib and /usr/X11R6/.

Fixes [BUGID #511]

Signed-off-by: Dexuan Cui <dexuan.cui@...>

commit b952fae48c45e39a14ec9c24b0ee544a741c3f69
Author: Dexuan Cui <dexuan.cui@...>
Date: Tue Oct 26 15:10:26 2010 +0800

busybox: enable more options for tar to support more file formats.

Fixes [BUGID #495]

Signed-off-by: Dexuan Cui <dexuan.cui@...>

Please find enclosed the annotated list of recipes that are not currently built as part of any task or image. There are a some basic options that could occur with these recipes, do nothing, move the recipe to a layer, or add the recipe to an existing image. The notes indicate a number of different options for the recipes that we chose.

The major changes to recipes are to moving them to meta-extras, meta-demoapps or meta-m2. Meta-extras is a location that will ultimately be deprecated, meta-demoapps is a staging area for further review and items that are more vertical oriented recipes.

Additional notes such as LSB or gmae SDK would move into those tasks or images as appropriate. There are additional notes which will be used for future discussion.

Please review the attached list and provide feedback.

Thanks

Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System