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

2010/11/1 Stewart, David C <david.c.stewart@...>:

Check out
http://www.yoctoproject.org/blogs/davest/2010/10/7/four-architectures-grooving-together,
my latest post to the Yocto Project blog. Some photos there of the UPnP
demo.



I also plan to post one up showing a little of the sausage-making… just a
little…



Let me know what you think.

Dave, the demo looked indeed quite impressive, and actually I was
trying to fetch the sources, but ....
git clone does not work for me. I've tried a few times and from
different systems/locations.
the poky master clones fine.

frans@frans-desktop:~/yocto$ git clone git://git.pokylinux.org/meta-demo
Initialized empty Git repository in /home/frans/yocto/meta-demo/.git/
fatal: The remote end hung up unexpectedly

Best regards, Frans

On 11/01/2010 12:07 AM, Frans Meulenbroeks wrote:

Dave, the demo looked indeed quite impressive, and actually I was
trying to fetch the sources, but ....
git clone does not work for me. I've tried a few times and from
different systems/locations.
the poky master clones fine.

frans@frans-desktop:~/yocto$ git clone git://git.pokylinux.org/meta-demo
Initialized empty Git repository in /home/frans/yocto/meta-demo/.git/
fatal: The remote end hung up unexpectedly

Best regards, Frans

Hi Frans,

It looks like anonymous access to the git repository isn't enabled. I can clone it using ssh:// but not get the same error as you when using git://

We'll have someone resolve this later today. Thanks for reporting it.

Scott

Hello,

Leading up to our 0.9 release, our autobuilder has been building an increasing number of targets for our nightly-release buildset. We've now reached the point that the nightly build takes more than 24 hours to run (> 26 hours, in fact) - which is clearly a problem on a build that we'd like to generate on a daily basis.

The following is a list of everything which is built within nightly-release:

The following targets are built for qemux86, qemux86-64, qemuarm, qemumips, and qemuppc:

* poky-image-minimal
* poky-image-sato
* poky-image-lsb
* poky-image-sdk
* meta-toolchain-sdk (SDKMACHINE=i586 and also x86_64)

For emenlow and atom-pc, we build:

* poky-image-minimal-live
* poky-image-sato-live
* poky-image-sdk-live
* meta-toolchain-sdk (SDKMACHINE=i586 and also x86_64)

Finally, we also build the Eclipse plugin, and copy the shared state prebuilds and RPM output at the end of the build.

I was going to post build times for some of these targets for reference, but it would be misleading as we build the targets in succession (e.g, we start with poky-image-sdk which takes the bulk of the time, and then the other targets can largely rely on the shared state builds).

Ideally I think our nightly build should take much less than 24 hours to build. The question is what we can move out of the nightly build and do on perhaps a weekly basis instead?

Our buildserver hardware is a dual quad-core Xeon server with 12 GB of RAM. Throwing hardware at the problem is another solution, but not an inexpensive one (we'd be looking at a 4-socket machine filled with quad-cores and 32 GB of RAM).

I'm open to ideas on how to address this issue. QA will be driving a lot of the requirements and I'm especially interested to hear your thoughts.

Scott

On Mon, 2010-11-01 at 02:38 -0700, Scott Garman wrote:

Leading up to our 0.9 release, our autobuilder has been building an
increasing number of targets for our nightly-release buildset. We've now
reached the point that the nightly build takes more than 24 hours to run
(> 26 hours, in fact) - which is clearly a problem on a build that we'd
like to generate on a daily basis.

The following is a list of everything which is built within nightly-release:

The following targets are built for qemux86, qemux86-64, qemuarm,
qemumips, and qemuppc:

* poky-image-minimal
* poky-image-sato
* poky-image-lsb
* poky-image-sdk
* meta-toolchain-sdk (SDKMACHINE=i586 and also x86_64)

For emenlow and atom-pc, we build:

* poky-image-minimal-live
* poky-image-sato-live
* poky-image-sdk-live
* meta-toolchain-sdk (SDKMACHINE=i586 and also x86_64)

Finally, we also build the Eclipse plugin, and copy the shared state
prebuilds and RPM output at the end of the build.

I was going to post build times for some of these targets for reference,
but it would be misleading as we build the targets in succession (e.g,
we start with poky-image-sdk which takes the bulk of the time, and then
the other targets can largely rely on the shared state builds).

Ideally I think our nightly build should take much less than 24 hours to
build. The question is what we can move out of the nightly build and do
on perhaps a weekly basis instead?

Our buildserver hardware is a dual quad-core Xeon server with 12 GB of
RAM. Throwing hardware at the problem is another solution, but not an
inexpensive one (we'd be looking at a 4-socket machine filled with
quad-cores and 32 GB of RAM).

There doesn't just have to be one build machine, we are going to end up
needing multiple machines and we can split the load between them quite
easily. I think there is going to be a second machine needed alongside
the existing one regardless of what other optimisations we make.

The changes in development at the moment will have a mixed effect on the
autobuilder's load. On the plus side we know there are performance
regressions with 0.9 which we're about to investigate. I can think of
one change I have in mind which on its own should get the builds back
under the 24 hour time.

On the down side there are going to be changes that need increased
horsepower from the build machines such as the runtime testing we're
close to enabling or enabling builds of world.

Cheers,

Richard

From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Richard Purdie
Sent: Monday, November 01, 2010 4:03 AM

On Mon, 2010-11-01 at 02:38 -0700, Scott Garman wrote:

Our buildserver hardware is a dual quad-core Xeon server with 12 GB of
RAM. Throwing hardware at the problem is another solution, but not an
inexpensive one (we'd be looking at a 4-socket machine filled with
quad-cores and 32 GB of RAM).

There doesn't just have to be one build machine, we are going to end up
needing multiple machines and we can split the load between them quite
easily. I think there is going to be a second machine needed alongside
the existing one regardless of what other optimisations we make.

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.

As you know, I want us to get to the root of the problem, which is efficiency of the build process. Since RP has already committed to addressing this, I'm fine with a short-term fix if it will help. :-)

Scott - please put in an order, will tell you the max amount today when we're f2f.

Dave

On Mon, 2010-11-01 at 08:07 +0100, Frans Meulenbroeks wrote:

Dave, the demo looked indeed quite impressive, and actually I was
trying to fetch the sources, but ....
git clone does not work for me. I've tried a few times and from
different systems/locations.
the poky master clones fine.

frans@frans-desktop:~/yocto$ git clone git://git.pokylinux.org/meta-demo
Initialized empty Git repository in /home/frans/yocto/meta-demo/.git/
fatal: The remote end hung up unexpectedly

These was a problem with anonymous clones of this repository but this
should be fixed now, sorry about that.

Cheers,

Richard

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

2. the arch automatic detection system uses "uname -m", thus producing
armv5tejl, which can only be resolved as armv5tel, conflicting with
"armv5te" in rpm

This is a bug in Zypper. The machine names should come from somewhere other
then uname -m. (The value of uname -m is very much ia32 specific for the most
part.. other architectures have way too many possible namings for it to be
useful.) There is a line in "/etc/rpm/platform" that contains the name of Poky
architecture. This file should be referenced (instead of -m) for all cases.

3. enhance zypper arch module, make the addition more flexible,
allowing arch alias (e.g. armv5te = armv5tel = armel = arm)

Zypper should read the rpm platform file.

Sounds reasonable. After all, zypper is only intended to be a frontend
utility to the lower end package tool. Then we won't need to worry about
alias and different naming, and this detaches zypper from hardware.

3. many archs are missing in zypper, like mips, armeb, etc.
4. there is no concept of machine-dependent packages (task-base) in
zypper, although we can work around.

Generally speaking, this is true of most RPM installations. However, within RPM
itself.. there really isn't any concept of "arch" anymore.. They're really only
used for grouping and ordering. So Zypper may need to be updated to query the
arch of a package and use it for it's various operations.

2. removing the concept of machine-dependent packages, change all
*.qemuarm.rpm to *.armv5te.rpm

I'm a bit worried about doing this, as we'll end up with (potentially)
incompatible packages with exactly the same name and versions... Perhaps we
need to think about embedding the machine type into the name of the packages
instead?

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.

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.

---

If DEB and IPK don't support this (which I wouldn't be surprised if they don't), then we'll need to: extend them, modify the package naming to include some type of architecture keying to avoid conflicts, or simply state multiarch support isn't available if the rootfs type is DEB or IPK. (I suspect the middle case is what we'll end up with.)

--Mark

Thanks,
Qing

Hello,

Leading up to our 0.9 release, our autobuilder has been building an
increasing number of targets for our nightly-release buildset. We've
now reached the point that the nightly build takes more than 24 hours
to run (> 26 hours, in fact)
- which is clearly a problem on a build that we'd like to generate on
a daily basis.

The following is a list of everything which is built within nightly-release:

The following targets are built for qemux86, qemux86-64, qemuarm,
qemumips, and qemuppc:

* poky-image-minimal
* poky-image-sato
* poky-image-lsb
* poky-image-sdk
* meta-toolchain-sdk (SDKMACHINE=i586 and also x86_64)

For emenlow and atom-pc, we build:

* poky-image-minimal-live
* poky-image-sato-live
* poky-image-sdk-live
* meta-toolchain-sdk (SDKMACHINE=i586 and also x86_64)

Finally, we also build the Eclipse plugin, and copy the shared state
prebuilds and RPM output at the end of the build.

I was going to post build times for some of these targets for
reference, but it would be misleading as we build the targets in
succession (e.g, we start with poky-image-sdk which takes the bulk of
the time, and then the other targets can largely rely on the shared state builds).

Ideally I think our nightly build should take much less than 24 hours
to build. The question is what we can move out of the nightly build
and do on perhaps a weekly basis instead?

How about customizing the nightly build to build part of targets for every day? For example, x86/x86_64 for Monday, atom-pc/emenlow for Tuesday..... etc.
And we can schedule a new build task for weekly, which is only triggered on Wednesday(or maybe Tuesday night) for QA weekly testing and with all targets built out.

Our buildserver hardware is a dual quad-core Xeon server with 12 GB of RAM.
Throwing hardware at the problem is another solution, but not an
inexpensive one (we'd be looking at a 4-socket machine filled with
quad-cores and 32 GB of RAM).

I'm open to ideas on how to address this issue. QA will be driving a
lot of the requirements and I'm especially interested to hear your thoughts.

Scott


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

Best Regards,
Jiajun

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, and general Kernel - Break it down
to Arch / Config components SDK - For all SDK related issues, have
components for plugin, tools, ...
Sato - as it exists today
Runtime Distribution- Delete this, we are not a distro (no bugs now)

Additionally, there is other discussion about Poky Test components for
the standards tests such as LSB, LTP, Posix.

These test suites can help to find bugs from user level to kernel. It's hard to put them as components under just one product. User can decide the product and add note in bug title that the bug is for LSB or LTP.
If we want to make it easier to report bugs for such test suites, how about adding a Standard Test Suite product, which includes LSB, LTP, POSIX and Others as components.

We will need to add Product Categories for other Yocto Projects that
do not have bugzilla yet.

Finally we need to update the Bugzilla Interface to be Yocto Project,
changing naming as appropriate.

Please take a few minutes to review this and give some feedback.


Thanks

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

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

Best Regards,
Jiajun

#! /bin/sh

# Hello,

case $Debian_build_system in

lenny_amd64)
cat <<EOF
[...]
| /srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57-r5/git/target-arm/dummygl.c:5:22:
warning: X11/Xlib.h: No such file or directory
| /srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57-r5/git/target-arm/dummygl.c:6:23:
warning: X11/Xutil.h: No such file or directory
| /srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57-r5/git/target-arm/dummygl.c:8:
error: expected ')' before '*' token
| /srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57-r5/git/target-arm/dummygl.c:13:
warning: no previous prototype for 'opengl_process_enable'
| /srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57-r5/git/target-arm/dummygl.c:19:
warning: no previous prototype for 'mem_opengl'
| make[1]: *** [dummygl.o] Error 1
| make[1]: Leaving directory
`/srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57-r5/git/arm-linux-user'
| make: *** [subdir-arm-linux-user] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed:
/srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57-r5/temp/log.do_compile.28106
NOTE: package qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57-r5:
task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package qemu-native-0.10.2+git9eab386edbf8cf002a731f8204a156f243a47a57:
failed
ERROR: Build of
/srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/meta/packages/qemu/qemu-native_git.bb
do_compile failed
ERROR: Task 597
(/srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/meta/packages/qemu/qemu-native_git.bb,
do_compile) failed
NOTE: Tasks Summary: Attempted 229 tasks of which 0 didn't need to be
rerun and 1 failed.
ERROR: '/srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/meta/packages/qemu/qemu-native_git.bb'
failed
NOTE: build 201011011610: completed
make: *** [/srv/build/builds/menuconfig2-test/build/rootfs/yocto/purple-3.2/foo]
Error 1
EOF
;;
lenny_i386)
cat <<EOF
[...]
| NOTE: Running
/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/gmp-native-4.2.4-r0/gmp-4.2.4/configure
--build=x86_64-linux --host=x86_64-linux
--target=x86_64-linux
--prefix=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr
--exec_prefix=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr

--bindir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/bin
--sbindir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/sbin

--libexecdir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/libexec

--datadir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/share
--sysconfdir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/etc
--sharedstatedir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/com
--localstatedir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/var
--libdir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/lib

--includedir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/include

--oldincludedir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/include
--infodir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/share/info
--mandir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/share/man
...
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... x86_64-pc-linux-gnu
| checking for a BSD-compatible install... /usr/bin/install -c
[...]
| checking size of unsigned short... 2
| checking for unsigned... yes
| checking size of unsigned... 4
| checking for unsigned long... yes
| checking size of unsigned long... 4
| checking for mp_limb_t... yes
| checking size of mp_limb_t... 4
| configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
| in this configuration expects 64 bits.
| You appear to have set $CFLAGS, perhaps you also need to tell GMP the
| intended ABI, see "ABI and ISA" in the manual.
| FATAL: oe_runconf failed
NOTE: Task failed:
/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/gmp-native-4.2.4-r0/temp/log.do_configure.28892
NOTE: package gmp-native-4.2.4-r0: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package gmp-native-4.2.4: failed
ERROR: Build of
/srv/build/builds/build/rootfs/yocto/purple-3.2/meta/packages/gmp/gmp-native_4.2.4.bb
do_configure failed
ERROR: Task 556
(/srv/build/builds/build/rootfs/yocto/purple-3.2/meta/packages/gmp/gmp-native_4.2.4.bb,
do_configure) failed
NOTE: Tasks Summary: Attempted 135 tasks of which 135 didn't need to
be rerun and 1 failed.
ERROR: '/srv/build/builds/build/rootfs/yocto/purple-3.2/meta/packages/gmp/gmp-native_4.2.4.bb'
failed
NOTE: build 201011011717: completed
make: *** [/srv/build/builds/menuconfig2-i386/../build/rootfs/yocto/purple-3.2/foo]
Error 1
EOF
;;
unstable_amd64)
cat <<EOF
Still building......
EOF
;;
unstable_i386)
cat <<EOF
[...]
| checking size of unsigned long... 4
| checking size of mp_limb_t... 4
| configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
| in this configuration expects 64 bits.
| You appear to have set $CFLAGS, perhaps you also need to tell GMP the
| intended ABI, see "ABI and ISA" in the manual.
| FATAL: oe_runconf failed
| ERROR: Task failed: ('function do_configure failed',
'/srv/build/builds/build/rootfs/yocto/laverne-4.0/build/tmp/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.13641')
NOTE: package gmp-native-5.0.1-r0: task do_configure: Failed
ERROR: Task 971
(virtual:native:/srv/build/builds/build/rootfs/yocto/laverne-4.0/meta/recipes-support/gmp/gmp_5.0.1.bb,
do_configure) failed with 1
Waiting for 1 active tasks to finish:
1: gettext-native-0.17-r5 do_compile (pid 13646)
NOTE: package gettext-native-0.17-r5: task do_compile: Succeeded
ERROR: 'virtual:native:/srv/build/builds/build/rootfs/yocto/laverne-4.0/meta/recipes-support/gmp/gmp_5.0.1.bb'
failed
make: *** [/srv/build/builds/menuconfig2-i386/../build/rootfs/yocto/laverne-4.0/foo]
Error 1
EOF
;;
others|*)
cat <<EOF
- I need to setup "vm.mmap_min_addr = 0" under /etc/sysctl.conf
- sh linked to dash makes build system fail
(./build/rootfs/yocto/laverne-4.0/poky-init-build-env):
(sid_i386)zumbi@enorme:/srv/build/builds/build/rootfs/yocto/laverne-4.0$
checkbashisms poky-init-build-env
possible bashism in poky-init-build-env line 24 ($BASH_SOMETHING):
elif test x"$BASH_SOURCE" = x; then
possible bashism in poky-init-build-env line 27 ($BASH_SOMETHING):
. `dirname $BASH_SOURCE`/scripts/poky-env-internal
- On lenny python 2.5 required, so Purple 3.2 was built (Laverne
was not tried)
- On unstable Laverne 4.0 was attempted
EOF
;;
esac

echo "Have a nice day!"

-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (700, 'unstable'), (600, 'testing'), (500, 'stable'),
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
# ^^^^^----- I had to change it so I could build on unstable ;-)

--
 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 10/30/10 3: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, and general
Kernel - Break it down to Arch / Config components
SDK - For all SDK related issues, have components for plugin, tools, ...
Sato - as it exists today
Runtime Distribution- Delete this, we are not a distro (no bugs now)

My proposal -- similar bug slightly different:

Poky Build System
Bitbake
Documentation
General

Poky Distribution
Runtime Distribution -- Poky embedded linux distribution
Documentation
Security
Toolchain
SDK
Test Suite

Yocto Infrastructure
AutoBuilder
Bugzilla
Website

Anjuta Plug-in
???

Eclipse Plug-in
???

Cross-Prelink

Pseudo

SDK Generator

Swabber


... specifically we need a major category for each of the projects in Yocto, right now the bugzilla is very specific to Poky and I think that needs to be updated now that things are public.

Additionally, there is other discussion about Poky Test components for
the standards tests such as LSB, LTP, Posix.

My suggestion is that is part of the run-time distribution. If someone chooses to not use the Poky run-time, then the tests likely won't be useful on their own.

We will need to add Product Categories for other Yocto Projects that do
not have bugzilla yet.

Finally we need to update the Bugzilla Interface to be Yocto Project,
changing naming as appropriate.

Please take a few minutes to review this and give some feedback.


Thanks

Sau!

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

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

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.

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)

Thanks,

--
Darren

SDK - For all SDK related issues, have components for plugin, tools, ...
Sato - as it exists today
Runtime Distribution- Delete this, we are not a distro (no bugs now)

Additionally, there is other discussion about Poky Test components for
the standards tests such as LSB, LTP, Posix.

We will need to add Product Categories for other Yocto Projects that do
not have bugzilla yet.

Finally we need to update the Bugzilla Interface to be Yocto Project,
changing naming as appropriate.

Please take a few minutes to review this and give some feedback.


Thanks

Sau!

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

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

--
Darren Hart
Embedded Linux Kernel

On 11/1/10 2: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.

I think this is where the Bugzilla description needs to be verbose.

Toolchain for me includes: userspace kernel headers (but not the kernel), binutils, gcc, "the libc" (uclibc, glibc, eglibc), and gdb.

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

Yes, I agree. the kernel needs to be treated as a separate project as it is an external item to Poky -- but part of the overall Yocto Project.

--Mark

Thanks,

--
Darren

SDK - For all SDK related issues, have components for plugin, tools, ...
Sato - as it exists today
Runtime Distribution- Delete this, we are not a distro (no bugs now)

Additionally, there is other discussion about Poky Test components for
the standards tests such as LSB, LTP, Posix.

We will need to add Product Categories for other Yocto Projects that do
not have bugzilla yet.

Finally we need to update the Bugzilla Interface to be Yocto Project,
changing naming as appropriate.

Please take a few minutes to review this and give some feedback.


Thanks

Sau!

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

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

On Oct 30, 2010, at 1: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.

We'll also want to update this document after we make these changes:
https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking

We might want to streamline that doc a bit to better summarize what
someone needs to know to file a bug to get people started before
diving into all of the details.

Dawn

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.

Sau!

Thanks,

--
Darren

SDK - For all SDK related issues, have components for plugin, tools, ...
Sato - as it exists today
Runtime Distribution- Delete this, we are not a distro (no bugs now)

Additionally, there is other discussion about Poky Test components for
the standards tests such as LSB, LTP, Posix.

We will need to add Product Categories for other Yocto Projects that do
not have bugzilla yet.

Finally we need to update the Bugzilla Interface to be Yocto Project,
changing naming as appropriate.

Please take a few minutes to review this and give some feedback.


Thanks

Sau!

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

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

On 11/01/2010 12:00 PM, Mark Hatle wrote:

On 10/30/10 3: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, and general
Kernel - Break it down to Arch / Config components
SDK - For all SDK related issues, have components for plugin, tools, ...
Sato - as it exists today
Runtime Distribution- Delete this, we are not a distro (no bugs now)

My proposal -- similar bug slightly different:

Poky Build System
Bitbake
Documentation
General

Add Configurations - for the config/site data

Poky Distribution
Runtime Distribution -- Poky embedded linux distribution

Remember this is not a Distribution, I think Yocto (Poky?) Meta-Data / Recipes and then the following components

Documentation
Security
Toolchain
SDK
Test Suite

Add:
User Space Recipes (this could be further broken down, if needed)
Toolchain Recipes (instead of Toolchain)
General

Yocto Infrastructure
AutoBuilder
Bugzilla
Website

Anjuta Plug-in
???

Eclipse Plug-in
???

Cross-Prelink

Pseudo

SDK Generator

Swabber

Add the Kernel Product
- Core
- Drivers
- Tooling (Trace, Debug, Perf)

... specifically we need a major category for each of the projects in
Yocto, right now the bugzilla is very specific to Poky and I think that
needs to be updated now that things are public.

Additionally, there is other discussion about Poky Test components for
the standards tests such as LSB, LTP, Posix.

My suggestion is that is part of the run-time distribution. If someone
chooses to not use the Poky run-time, then the tests likely won't be
useful on their own.

We will need to add Product Categories for other Yocto Projects that do
not have bugzilla yet.

Finally we need to update the Bugzilla Interface to be Yocto Project,
changing naming as appropriate.

Please take a few minutes to review this and give some feedback.


Thanks

Sau!

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

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

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

Hi,

I don't have answers to all of the failures but let me try and respond
to the ones I have some ideas about:

On Mon, 2010-11-01 at 18:23 +0000, Hector Oron wrote:

lenny_i386)
cat <<EOF
[...]
| NOTE: Running
/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/gmp-native-4.2.4-r0/gmp-4.2.4/configure
--build=x86_64-linux --host=x86_64-linux
--target=x86_64-linux
--prefix=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr
--exec_prefix=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr

--bindir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/bin
--sbindir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/sbin

--libexecdir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/libexec

--datadir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/share
--sysconfdir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/etc
--sharedstatedir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/com
--localstatedir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/var
--libdir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/lib

--includedir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/include

--oldincludedir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/include
--infodir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/share/info
--mandir=/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/staging/x86_64-linux/usr/share/man
...
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... x86_64-pc-linux-gnu
| checking for a BSD-compatible install... /usr/bin/install -c
[...]
| checking size of unsigned short... 2
| checking for unsigned... yes
| checking size of unsigned... 4
| checking for unsigned long... yes
| checking size of unsigned long... 4
| checking for mp_limb_t... yes
| checking size of mp_limb_t... 4
| configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
| in this configuration expects 64 bits.
| You appear to have set $CFLAGS, perhaps you also need to tell GMP the
| intended ABI, see "ABI and ISA" in the manual.
| FATAL: oe_runconf failed
NOTE: Task failed:
/srv/build/builds/build/rootfs/yocto/purple-3.2/build/tmp/work/x86_64-linux/gmp-native-4.2.4-r0/temp/log.do_configure.28892
NOTE: package gmp-native-4.2.4-r0: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package gmp-native-4.2.4: failed
ERROR: Build of
/srv/build/builds/build/rootfs/yocto/purple-3.2/meta/packages/gmp/gmp-native_4.2.4.bb
do_configure failed
ERROR: Task 556
(/srv/build/builds/build/rootfs/yocto/purple-3.2/meta/packages/gmp/gmp-native_4.2.4.bb,
do_configure) failed
NOTE: Tasks Summary: Attempted 135 tasks of which 135 didn't need to
be rerun and 1 failed.
ERROR: '/srv/build/builds/build/rootfs/yocto/purple-3.2/meta/packages/gmp/gmp-native_4.2.4.bb'
failed
NOTE: build 201011011717: completed
make: *** [/srv/build/builds/menuconfig2-i386/../build/rootfs/yocto/purple-3.2/foo]
Error 1
EOF

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

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.

;;
unstable_i386)
cat <<EOF
[...]
| checking size of unsigned long... 4
| checking size of mp_limb_t... 4
| configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
| in this configuration expects 64 bits.
| You appear to have set $CFLAGS, perhaps you also need to tell GMP the
| intended ABI, see "ABI and ISA" in the manual.
| FATAL: oe_runconf failed
| ERROR: Task failed: ('function do_configure failed',
'/srv/build/builds/build/rootfs/yocto/laverne-4.0/build/tmp/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.13641')
NOTE: package gmp-native-5.0.1-r0: task do_configure: Failed
ERROR: Task 971
(virtual:native:/srv/build/builds/build/rootfs/yocto/laverne-4.0/meta/recipes-support/gmp/gmp_5.0.1.bb,
do_configure) failed with 1
Waiting for 1 active tasks to finish:
1: gettext-native-0.17-r5 do_compile (pid 13646)
NOTE: package gettext-native-0.17-r5: task do_compile: Succeeded
ERROR: 'virtual:native:/srv/build/builds/build/rootfs/yocto/laverne-4.0/meta/recipes-support/gmp/gmp_5.0.1.bb'
failed
make: *** [/srv/build/builds/menuconfig2-i386/../build/rootfs/yocto/laverne-4.0/foo]
Error 1
EOF

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

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

Right, but it detected that?

- sh linked to dash makes build system fail
(./build/rootfs/yocto/laverne-4.0/poky-init-build-env):
(sid_i386)zumbi@enorme:/srv/build/builds/build/rootfs/yocto/laverne-4.0$
checkbashisms poky-init-build-env
possible bashism in poky-init-build-env line 24 ($BASH_SOMETHING):
elif test x"$BASH_SOURCE" = x; then
possible bashism in poky-init-build-env line 27 ($BASH_SOMETHING):
. `dirname $BASH_SOURCE`/scripts/poky-env-internal

Ouch. We don't support building with /bin/sh as dash (way too many
broken scripts our there still) and the system would tell you as such if
it detected that. Looks like bashisms have made it into the setup script
though which we need to fix.

Cheers,

Richard

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. I'd
suggest three categories:

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

Let's keep it simple.

Bruce

Sau!

Thanks,

--
Darren

SDK - For all SDK related issues, have components for plugin, tools, ...
Sato - as it exists today
Runtime Distribution- Delete this, we are not a distro (no bugs now)

Additionally, there is other discussion about Poky Test components for
the standards tests such as LSB, LTP, Posix.

We will need to add Product Categories for other Yocto Projects that do
not have bugzilla yet.

Finally we need to update the Bugzilla Interface to be Yocto Project,
changing naming as appropriate.

Please take a few minutes to review this and give some feedback.


Thanks

Sau!

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

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