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 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

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

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 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

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 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 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)

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

frans@frans-desktop:~/yocto/poky-laverne-4.0$ bitbake -v -v -v -D -D -D
DEBUG: Removed the following variables from the environment:
GDM_KEYBOARD_LAYOUT, GNOME_DESKTOP_SESSION_ID, LESSOPEN, CVS_RSH,
GNOME_KEYRING_CONTROL, SPEECHD_PORT, SHLVL, MANDATORY_PATH, WINDOWID,
CVSROOT, GDMSESSION, LESSCLOSE, ORBIT_SOCKETDIR, GTK_MODULES,
HISTIGNORE, XDG_CONFIG_DIRS, DEFAULTS_PATH, OLDPWD, GDM_LANG,
HISTCONTROL, BUILDDIR, OE_TOPDIR, LS_COLORS
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/bitbake.conf
DEBUG: CONF conf/bitbake.conf:637: including conf/site.conf
DEBUG: CONF file 'conf/site.conf' not found
DEBUG: CONF conf/bitbake.conf:638: including conf/auto.conf
DEBUG: CONF file 'conf/auto.conf' not found
DEBUG: CONF conf/bitbake.conf:639: including conf/local.conf
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/tv.axon.openembedded.gtd100/conf/local.conf
DEBUG: CONF conf/bitbake.conf:640: including conf/build/x86_64-linux.conf
DEBUG: CONF file 'conf/build/x86_64-linux.conf' not found
DEBUG: CONF conf/bitbake.conf:641: including conf/target/INVALID-INVALID.conf
DEBUG: CONF file 'conf/target/INVALID-INVALID.conf' not found
DEBUG: CONF conf/bitbake.conf:642: including conf/machine/beagleboard.conf
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/machine/beagleboard.conf
DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/machine/beagleboard.conf:17:
including conf/machine/include/tune-cortexa8.inc
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/machine/include/tune-cortexa8.inc:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/machine/include/tune-cortexa8.inc
DEBUG: CONF conf/bitbake.conf:643: including conf/machine-sdk/${SDKMACHINE}.conf
DEBUG: CONF file 'conf/machine-sdk/${SDKMACHINE}.conf' not found
DEBUG: CONF conf/bitbake.conf:644: including conf/distro/poky.conf
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf
DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:57:
including conf/distro/include/poky-default.inc
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-default.inc:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-default.inc
DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-default.inc:52:
including conf/distro/include/as-needed.inc
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/as-needed.inc:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/as-needed.inc
DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:60:
including conf/distro/include/poky-eglibc.inc
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-eglibc.inc:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-eglibc.inc
DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:95:
including conf/distro/include/poky-fixed-revisions.inc
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-fixed-revisions.inc:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-fixed-revisions.inc
DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:96:
including conf/distro/include/preferred-xorg-versions.inc
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/preferred-xorg-versions.inc:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/preferred-xorg-versions.inc
DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:139:
including conf/distro/include/world-broken.inc
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/world-broken.inc:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/world-broken.inc
DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:140:
including conf/distro/include/distro_tracking_fields.inc
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/distro_tracking_fields.inc:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/distro_tracking_fields.inc
DEBUG: CONF conf/bitbake.conf:645: including conf/documentation.conf
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/documentation.conf
DEBUG: CONF conf/bitbake.conf:646: including conf/sanity.conf
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/sanity.conf
DEBUG: CONF conf/bitbake.conf:647: including conf/abi_version.conf
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/abi_version.conf
DEBUG: BB classes/base.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/base.bbclass
DEBUG: BB :0: inheriting classes/patch.bbclass
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/patch.bbclass:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/patch.bbclass
DEBUG: BB :0: inheriting classes/staging.bbclass
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/staging.bbclass:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/staging.bbclass
DEBUG: BB :0: inheriting classes/mirrors.bbclass
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/mirrors.bbclass:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/mirrors.bbclass
DEBUG: BB :0: inheriting classes/utils.bbclass
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/utils.bbclass:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/utils.bbclass
DEBUG: BB :0: inheriting classes/utility-tasks.bbclass
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/utility-tasks.bbclass:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/utility-tasks.bbclass
DEBUG: BB :0: inheriting classes/metadata_scm.bbclass
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/metadata_scm.bbclass:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/metadata_scm.bbclass
DEBUG: BB classes/devshell.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/devshell.bbclass
DEBUG: BB classes/package_ipk.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/package_ipk.bbclass
DEBUG: BB :0: inheriting classes/package.bbclassmachine
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/package.bbclass:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/package.bbclass
DEBUG: BB :0: inheriting classes/packagedata.bbclass
DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/packagedata.bbclass:
handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/packagedata.bbclass
DEBUG: BB classes/debian.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/debian.bbclass
DEBUG: BB classes/poky.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/poky.bbclass
DEBUG: BB classes/devshell.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/devshell.bbclass
DEBUG: BB classes/insane.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/insane.bbclass
DEBUG: BB classes/sstate.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/sstate.bbclass
DEBUG: BB classes/sanity.bbclass: handle(data, include)
DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/sanity.bbclass
DEBUG: Using '${OE_TOPDIR}/tmp/cache/bb_persist_data.sqlite3' as the
persistent data cache
DEBUG: Clearing SRCREV cache due to cache policy of: clear
DEBUG: mkdirhier(${OE_TOPDIR}/tmp/cache)
DEBUG: Using cache in '${OE_TOPDIR}/tmp/cache/bb_codeparser.dat' for
codeparser cache
FATAL: Traceback (most recent call last):
File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake//bin/bitbake",
line 216, in <module>
ret = main()
File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake//bin/bitbake",
line 177, in main
cooker = bb.cooker.BBCooker(configuration, server)
File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/cooker.py",
line 85, in __init__
self.parseConfigurationFiles(self.configuration.file)
File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/cooker.py",
line 555, in parseConfigurationFiles
bb.event.fire(bb.event.ConfigParsed(), self.configuration.data)
File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/event.py",
line 98, in fire
fire_class_handlers(event, d)
File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/event.py",
line 68, in fire_class_handlers
ret = bb.utils.better_eval("tmpHandler(e)", locals)
File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/utils.py",
line 373, in better_eval
return eval(source, _context, locals)
File "<string>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'find'

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.

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.

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.


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

Thanks,
Qing

Hi,

I've seen a few comments that people are struggling with the python
version Poky requires not being present in certain distros. I can now
point to one potential solution in the form of a standalone install of
python (in /opt/poky) which Poky itself can generate. I've shared
prebuilt 32 and 64 bit versions of these at:

http://autobuilder.yoctoproject.org/downloads/miscsupport/python-nativesdk-standalone-i586.tar.bz2
http://autobuilder.yoctoproject.org/downloads/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2

They are not statically linked but are self contained with all the
libraries they need so should work on pretty much any Linux system.

To use them, extract as root in / and then just run:

export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
or
export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH

before running bitbake and the version of python in these tarballs will
be used by bitbake instead.

For reference, you can generate these tarballs by running:

SDKMACHINE=i586 bitbake external-python-tarball
or
SDKMACHINE=x86_64 bitbake external-python-tarball

using Poky's master branch.

Cheers,

Richard

I have updated the spreadsheet and removed items that should not have been included (-natives and other tools). I have also added annotation to the first column to show some potential adjustments and existing inter-dependencies within the list.

Again, please review the remaining items and provide any input.

Thanks

Sau!

On 10-11-01 07:42 PM, Darren Hart wrote:

On 11/01/2010 02:40 PM, Bruce Ashfield wrote:

On 10-11-01 4:13 PM, Saul Wold wrote:

On 11/01/2010 12:17 PM, Darren Hart wrote:

On 10/30/2010 01:50 AM, Saul Wold wrote:

We need to review the existing Bugzilla and update the Products and
Categories to reflect the projects correctly. Please review this email
and make comments, suggestions for moving forward with a better
Bugzilla
categorization.

Currently we have "Core OS" with the following Components:
General
Graphics Driver
Kernel
Tool Chain

Along with "Poky" which contains:
General
SDK Tools

There are also product categories for "Runtime Distribution", "Sato"
and
"SDK Plugins". Along with other infrastructure items.

I would propose that we clearly define the some new products and move
bugs as appropriate:

Poky Build System - for Poky class and configuration issues
User Space - for user space, patching and runtime failures
Tool Chain - break it down to compiler, tools, libraries

The divide between User Space and Tool Chain is a bit vague. For
instance, I would generally expect to see glibc under User Space, but
your description seems to place it under Tool Chain.

Good point. (See my reply to Mark's email)

and general Kernel - Break it down to Arch / Config components

Please keep the kernel separate from the Tool Chain, something along the
lines of:

Kernel
- Core
- Drivers
- Tooling (Trace, Debug, Perf)

I think my lines might have run together! It was meant to be separate,
and this looks like a good break down.

This is too much separation, having over categorization
of the kernel defects at this point is overkill.

Agree in principle.

I'd suggest three categories:

- kernel build (which often transitions to
straight up build-system after triage).
- kernel configuration
- kernel runtime

Let me confirm:

- kernel runtime (this includes all errors, panics, BUGs, etc. from the
three categories I listed above - no objection).

It does. What we can also do, is split it between
'kernel' and 'BSP'. I've been triaging bugs like this
for 6 years now, and typically it is very hard for
the submitters to categorize properly. But typically
they do know if it is particular to a board (BSP) or
everywhere (kernel). The BSP would also cover the drivers
category that you had listed above .. since often, drivers
are exercised by one (or few) boards and those are the
ones that have problems.

It's still 3 categories, but separate by type of bug instead of area of
bug. It's still fine with me. My biggest concern was keeping the kernel
separate, and it is in either form. I'll happily defer to Bruce with
respect to an efficient set of kernel bug categories for an embedded
"not-a-distribution".

Agreed. We are aligned here. We'll adjust these as we
go forward to whatever makes sense.

Bruce

Let's keep it simple.

Agreed.

On Tue, 2010-11-02 at 09:48 -0500, Tom Zanussi wrote:

On Tue, 2010-11-02 at 06:20 -0700, tiagoprn wrote:

Hello again!

I think nokia n8xx could be a nice example of what yocto/poky are
capable of.

Especially now that Nokia has abandoned this devices, it would be cool
to have a new OS being supported on it.

Yes, I agree.

I'm new to poky, so, if you could make it easier to build the toochain
to build it to a n800, me and many other n8xx owners would be quite
happy.

Right, it doesn't seem to be working out of the box - I'll take a look
and see if we can't rescue it from meta-extras...

BTW, I'd actually like to have one of these for myself - can you suggest
a source for them other than eBay?

Let me chip in with some information here. Poky used to support the n800
machine semi-officially and it ran sato quite well including the wiki
and touchscreen. The problem has been that the xserver and kernel
recipes were not updated, Poky moved on and these older versions no
longer worked/interacted well. For this reason, the machine was moved to
meta-extras as it no longer worked.

I know its possible to make it work again and there shouldn't be massive
amounts of effort needed. If someone does step up and fixes it up and
agrees to maintain it, the machine can come back. It is going to need
someone to give it some TLC though.

Cheers,

Richard

On Tue, 2010-11-02 at 06:20 -0700, tiagoprn wrote:

Hello again!

I think nokia n8xx could be a nice example of what yocto/poky are
capable of.

Especially now that Nokia has abandoned this devices, it would be cool
to have a new OS being supported on it.

Yes, I agree.

I'm new to poky, so, if you could make it easier to build the toochain
to build it to a n800, me and many other n8xx owners would be quite
happy.

Right, it doesn't seem to be working out of the box - I'll take a look
and see if we can't rescue it from meta-extras...

BTW, I'd actually like to have one of these for myself - can you suggest
a source for them other than eBay?

Thanks,

Tom

Regards,


2010/11/1 Bruce Ashfield <bruce.ashfield@...>

On 10-10-30 12:20 PM, Tom Zanussi wrote:
On Fri, 2010-10-29 at 04:50 -0700, tiagoprn wrote:
Hello everyone!

I have a question. I have just read about the
yocto/poky projects and
here I am with a hope. :)

I have a nokia n800 (an internet tablet
abandoned by Nokia just about
2 years ago).

With poky/yocto project tools, is it possible
to install a linux
toolchain with X and the touchscreen/wireless
components working, for
an example, in a SD Card and boot my device
into it?

I'm anxious for that.


Hi,

It looks like yocto already has support for the n800 -
there's this
entry in local.conf:

# Other supported machines
.
.






#MACHINE ?= "nokia800"


and see this section in README.hardware:

'Nokia 770/N800/N810 Internet Tablets (nokia770 and
nokia800)'

which says:

"The nokia800 images and kernel will run on both the
N800 and N810"

Sounds like what you're looking for...


The rest of the config has been moved to meta-extras, and
we'd need to do a bit of kernel work, but it has worked in the
past, and could work again in the future.

In other words 'I agree'.

Cheers,

Bruce


Tom




_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto




--
***
TIAGOPRN
Desenvolvedor Web, Linux e Windows
(Django, Python, Delphi, Lazarus, MySQL, SQLite)
E-mail: tiagoprn@...
Blog: http://tgplima.net84.net
LinkedIn (profile público):
http://br.linkedin.com/in/tiagoparanhoslima
twitter: https://twitter.com/tiagoprn
identi.ca: http://identi.ca/tiagoprn

Hello again!

I think nokia n8xx could be a nice example of what yocto/poky are capable of.

Especially now that Nokia has abandoned this devices, it would be cool to have a new OS being supported on it.

I'm new to poky, so, if you could make it easier to build the toochain to build it to a n800, me and many other n8xx owners would be quite happy.

Regards,

--
***
TIAGOPRN
Desenvolvedor Web, Linux e Windows
(Django, Python, Delphi, Lazarus, MySQL, SQLite)
E-mail: tiagoprn@...
Blog: http://tgplima.net84.net
LinkedIn (profile público): http://br.linkedin.com/in/tiagoparanhoslima
twitter: https://twitter.com/tiagoprn

On Tue, 2010-11-02 at 11:39 +0000, Hector Oron wrote:

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

So to be clear, you set MACHINE="balloon3"? You're therefore building
with some layer or additional metadata? I'd suggest trying a supported
machine like "atom-pc" first before trying to add your own.

Yes and yes. I'll attempt "atom-pc" later on, but that is not much of
interest for me. Thanks.

I'd just appreciate people being a little clearer about what they're
attempting to do.

Obviously I don't know how you've setup this balloon3 target but knowing
this isn't an out the box configuration might help me target my replies
to you.

There would appear to be a problem with the kernel provision for your
board. As a hint, either have a kernel recipe and point to it with
PREFERRED_PROVIDER_virtual/kernel setting in the machine configuration
or ensure the machine in question is listed in COMPATIBLE_MACHINE of the
kernel recipe you want to use.

Cheers,

Richard

Hello,

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

So to be clear, you set MACHINE="balloon3"? You're therefore building
with some layer or additional metadata? I'd suggest trying a supported
machine like "atom-pc" first before trying to add your own.

Yes and yes. I'll attempt "atom-pc" later on, but that is not much of
interest for me. Thanks.

Best regards,
--
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html

On Tue, 2010-11-02 at 10:08 +0000, Hector Oron wrote:

Hello,

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

Which MACHINE is that set for? Its unusual for the system to be using
linux-dummy.

It is a balloon3 [1]. I think you have not official support for it. I
also got an Intel Embedded Devkit 1-N450 (Black Sand) which I could
attempt to build for it.

[1] http://balloonboard.org/

So to be clear, you set MACHINE="balloon3"? You're therefore building
with some layer or additional metadata? I'd suggest trying a supported
machine like "atom-pc" first before trying to add your own.

Cheers,

Richard

On Tue, 2010-11-02 at 10:03 +0000, Hector Oron wrote:

At a guess this is a 64 bit kernel and a 32 bit userspace? What does
"uname -a" show?

Yes, it is 64 bit kernel host running a 32 bit userland.
Linux enorme 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux

I suspect if you add

BUILD_ARCH = "i686"

to your local.conf, the build might work better? If you can confirm that
we can probably detect this problem and avoid this failure.

Build attempted with
BUILD_ARCH="i686" BB_NUMBER_THREADS="2" PARALLEL_MAKE="-j 2"
MACHINE=$(BOARD) bitbake $(YOCTO_IMAGE)
got same result as above.

Only certainly variables can be passed through the environment. Can you
put the line in local.conf please and retry as otherwise it won't have
any effect.

Same as the above failure (64 bit kernel and 32 bit userspace)?

Sure.

others|*)
cat <<EOF
- I need to setup "vm.mmap_min_addr = 0" under /etc/sysctl.conf

Right, but it detected that?

If it was not set, scripts warn about it, once you set it up, it goes through.

Ok, good.

Cheers,

Richard