All,

This morning I stopped the autobuilder and fixed a few scripts that caused our first milestone build to not generate a source release tarball. I also removed a few unneeded sdk targets from milestone-internal and fixed the CURRENT linking issue. I'll have these all packaged up and ready to pull into the poky-autobuilder repo next week but I wanted to go through the changes before I left for the weekend (so I don't forget what I did :) )

The first change was with poky-autobuild-generate-sources-tarball. The tarball generation failed due to git trying to archive a hardcoded branch (master). This script now takes an optional third arg of $BRANCH. If the third arg isn't set, it defaults to 'master'. This should fix the source tarball generation.

The second change was to poky-autobuild-generate-release. This script now takes an optional third arg of 'current', which causes it to just create a CURRENT symlink to the latest release directory. I want to remove this functionality from this script as issuing a 'current' doesn't actually generate a release and the functionality should be extracted and put in it's own script. It was just a convenient place to put it for now.

I also removed all the non-IA arch sdk builds from milestone-internal. Building these happens on milestone-external and is not needed.

M2 build 2 is now running and judging from the last build, milestone-external should be done around 12 noon PST tomorrow and milestone-internal finished around 8am PST.

If you have any questions or concerns, I'll be checking email intermittently this weekend.

-b

2010/12/16 Saul Wold <sgw@...>:

Hello All,

Recently Richard sent around an email proposing that a new repository be
created for hosting layers that are not part of the core Yocto Metadata.

This new repository "poky-extras" can host different contributed layers and
will be open to any one.

From Richard's proposed ground rules:

* it has the OE style open contributions model
* consists of a set of layers, each clearly identified at the top level
* each layer has a clearly named maintainer or maintainers
* people respect the layer maintainers
* layers are split into logical "topics" where at all possible

The first layer contained in this new repository is the meta-linaro layer,
the top level repository will be removed short since it will now be
maintained in poky-extras.

If you require write access to this repository, please send your request to
git-requests@...

Saul, all,

I've peeked at poky-extras. The meta-linaor layer does not have an
identifiable maintainer (grep -ir maint . in that dir did not result
in any hits).
Do we have a policy on when/how to create a layer.
My intention is to bring over some of my OE recipes (as I would love
to be able to build my james image under poky too).

Best regards, Frans

The M2 branch has had a minor change to back out the 2.6.37 Kernel for the QEMU ARM and PPC arches due to some issue with that version. The problem are related to the mouse on ARM and a very slow boot on Qemu PPC.

We will move forward with the M2 build starting tonight or tomorrow morning, which will provide a QA window starting on Monday in China.

Thanks to all members of the community and team for their support in making this release happen.


--
Sau!

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

The current milestone release builders have a slight bug in a script called the final build steps that generate the release tarball. I found it this afternoon after milestone-internal failed on tarball generation. I'll have to fix this on monday, but in the meantime, I've run the fixed script by hand on the internal and will fix the one on external and run it by hand tomorrow after milestone-external finishes up.

-b

On Fri, Dec 17, 2010 at 3:50 PM, Bruce Ashfield
<bruce.ashfield@...> wrote:

The existing 2.6.34 kernel tree uses _ where poky typically
uses -. This is a historical artifact, since working with
gnu Make and shells means avoiding - is wise. The opposite
is true in Yocto.

To avoid using the _ reserved character wherever possible
we can simply remove it from the branch names in the
new 2.6.37 kernel, but to keep the content stable in the
0.9 2.6.34 kernel, we map _ to - for the purposes of
packaging.

To further faciliate this switch, the branch names no
longer need to be shortened in the KMACHINE mappings, but
can be fully specified and the tools/processing adapt as
required. This gives us the flexibility to map multiple
boards to a single branch for building.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
 meta/classes/kernel-yocto.bbclass                  |   12 +++++-------
 .../conf/distro/include/poky-default-revisions.inc |    2 +-
 .../recipes-kernel/linux/linux-yocto-stable_git.bb |    8 ++++++--
 meta/recipes-kernel/linux/linux-yocto_git.bb       |   18 +++++++++---------
 4 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 8e82012..f541878 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -10,7 +10,7 @@ S = "${WORKDIR}/linux"
 # and is used in the SRC_URI. The machine is then set back to ${MACHINE},
 # since futher processing will use that to create local branches
 python __anonymous () {
-    import bb, re
+    import bb, re, string

    version = bb.data.getVar("LINUX_VERSION", d, 1)
    # 2.6.34 signifies the old-style tree, so we need some temporary
@@ -29,12 +29,14 @@ python __anonymous () {
        # The branch for a build is:
        #    yocto/<kernel type>/${KMACHINE} or
        #    yocto/<kernel type>/${KMACHINE}/base
-        bb.data.setVar("KBRANCH", bb.data.expand("yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}",d), d)
+        bb.data.setVar("KBRANCH", bb.data.expand("${KMACHINE}",d), d)
        bb.data.setVar("KMETA", "meta", d)

        mach = bb.data.getVar("KMACHINE", d, 1)
        # drop the "/base" if it was on the KMACHINE
        kmachine = mach.replace('/base','')
+        # drop everything but the last segment
+        kmachine = os.path.basename( kmachine )
        # and then write KMACHINE back
        bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), kmachine, d)

@@ -51,11 +53,7 @@ do_patch() {
           defconfig=${WORKDIR}/defconfig
       fi

-       if [ -n "${BOOTSTRAP}" ]; then
-           kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
-       else
-           kbranch=${KBRANCH}
-       fi
+       kbranch=${KBRANCH}

       # simply ensures that a branch of the right name has been created
       createme ${ARCH} ${kbranch} ${defconfig}
diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index a8fdf81..6b77bee 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -57,7 +57,7 @@ SRCREV_pn-gypsy ??= "147"
 SRCREV_pn-inputproto ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
 SRCREV_pn-inputproto-native ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
 SRCREV_pn-inputproto-nativesdk ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
-SRCREV_pn-kern-tools-native ??= "c85dcdd2dc50d71476a11c2960bf14c2b144b3c7"
+SRCREV_pn-kern-tools-native ??= "796d7fef92b2eed449c17c14441587ff0c465368"
 SRCREV_pn-libdrm ??= "3f3c5be6f908272199ccf53f108b1124bfe0a00e"
 SRCREV_pn-libfakekey ??= "2031"
 SRCREV_pn-libgdbus ??= "aeab6e3c0185b271ca343b439470491b99cc587f"
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
index dd4d176..a059f3d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -12,7 +12,8 @@ KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
 KMACHINE_beagleboard = "beagleboard"

 LINUX_VERSION ?= "2.6.34"
-LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE_EXTENSION}"
+
 PR = "r0"

I should have bumped PR here. I'll push that change to my contrib
branch, but won't
resend to the list.

Cheers,

Bruce

 PV = "${LINUX_VERSION}+git${SRCPV}"
 SRCREV_FORMAT = "meta_machine"
@@ -21,11 +22,14 @@ COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|route

 # this performs a fixup on the SRCREV for new/undefined BSPs
 python __anonymous () {
-    import bb, re
+    import bb, re, string

    rev = bb.data.getVar("SRCREV_machine", d, 1)
    if rev == "standard":
        bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+
+    kerntype = string.replace(bb.data.expand("${LINUX_KERNEL_TYPE}", d), "_", "-")
+    bb.data.setVar("LINUX_KERNEL_TYPE_EXTENSION", kerntype, d)
 }

 SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index f40fe38..6677f99 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -1,15 +1,15 @@
 inherit kernel
 require linux-yocto.inc

-KMACHINE_qemux86  = "common_pc/base"
-KMACHINE_qemux86-64  = "common_pc_64"
-KMACHINE_qemuppc  = "qemu_ppc32"
-KMACHINE_qemumips = "mti_malta32_be"
-KMACHINE_qemuarm  = "arm_versatile_926ejs"
-KMACHINE_atom-pc  = "atom-pc"
-KMACHINE_routerstationpro = "routerstationpro"
-KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
-KMACHINE_beagleboard = "beagleboard"
+KMACHINE_qemux86  = "yocto/standard/common_pc/base"
+KMACHINE_qemux86-64  = "yocto/standard/common-pc-64"
+KMACHINE_qemuppc  = "yocto/standard/qemu-ppc32"
+KMACHINE_qemumips = "yocto/standard/mti-malta32-be"
+KMACHINE_qemuarm  = "yocto/standard/arm-versatile-926ejs"
+KMACHINE_atom-pc  = "yocto/standard/common-pc/atom-pc"
+KMACHINE_routerstationpro = "yocto/standard/routerstationpro"
+KMACHINE_mpc8315e-rdb = "yocto/standard/fsl-mpc8315e-rdb"
+KMACHINE_beagleboard = "yocto/standard/beagleboard"

 LINUX_VERSION ?= "2.6.37"
 LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
--
1.7.0.4

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky

--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

The existing 2.6.34 kernel tree uses _ where poky typically
uses -. This is a historical artifact, since working with
gnu Make and shells means avoiding - is wise. The opposite
is true in Yocto.

To avoid using the _ reserved character wherever possible
we can simply remove it from the branch names in the
new 2.6.37 kernel, but to keep the content stable in the
0.9 2.6.34 kernel, we map _ to - for the purposes of
packaging.

To further faciliate this switch, the branch names no
longer need to be shortened in the KMACHINE mappings, but
can be fully specified and the tools/processing adapt as
required. This gives us the flexibility to map multiple
boards to a single branch for building.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta/classes/kernel-yocto.bbclass | 12 +++++-------
.../conf/distro/include/poky-default-revisions.inc | 2 +-
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 8 ++++++--
meta/recipes-kernel/linux/linux-yocto_git.bb | 18 +++++++++---------
4 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 8e82012..f541878 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -10,7 +10,7 @@ S = "${WORKDIR}/linux"
# and is used in the SRC_URI. The machine is then set back to ${MACHINE},
# since futher processing will use that to create local branches
python __anonymous () {
- import bb, re
+ import bb, re, string

version = bb.data.getVar("LINUX_VERSION", d, 1)
# 2.6.34 signifies the old-style tree, so we need some temporary
@@ -29,12 +29,14 @@ python __anonymous () {
# The branch for a build is:
# yocto/<kernel type>/${KMACHINE} or
# yocto/<kernel type>/${KMACHINE}/base
- bb.data.setVar("KBRANCH", bb.data.expand("yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}",d), d)
+ bb.data.setVar("KBRANCH", bb.data.expand("${KMACHINE}",d), d)
bb.data.setVar("KMETA", "meta", d)

mach = bb.data.getVar("KMACHINE", d, 1)
# drop the "/base" if it was on the KMACHINE
kmachine = mach.replace('/base','')
+ # drop everything but the last segment
+ kmachine = os.path.basename( kmachine )
# and then write KMACHINE back
bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), kmachine, d)

@@ -51,11 +53,7 @@ do_patch() {
defconfig=${WORKDIR}/defconfig
fi

- if [ -n "${BOOTSTRAP}" ]; then
- kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
- else
- kbranch=${KBRANCH}
- fi
+ kbranch=${KBRANCH}

# simply ensures that a branch of the right name has been created
createme ${ARCH} ${kbranch} ${defconfig}
diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index a8fdf81..6b77bee 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -57,7 +57,7 @@ SRCREV_pn-gypsy ??= "147"
SRCREV_pn-inputproto ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-native ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-nativesdk ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
-SRCREV_pn-kern-tools-native ??= "c85dcdd2dc50d71476a11c2960bf14c2b144b3c7"
+SRCREV_pn-kern-tools-native ??= "796d7fef92b2eed449c17c14441587ff0c465368"
SRCREV_pn-libdrm ??= "3f3c5be6f908272199ccf53f108b1124bfe0a00e"
SRCREV_pn-libfakekey ??= "2031"
SRCREV_pn-libgdbus ??= "aeab6e3c0185b271ca343b439470491b99cc587f"
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
index dd4d176..a059f3d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -12,7 +12,8 @@ KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
KMACHINE_beagleboard = "beagleboard"

LINUX_VERSION ?= "2.6.34"
-LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE_EXTENSION}"
+
PR = "r0"
PV = "${LINUX_VERSION}+git${SRCPV}"
SRCREV_FORMAT = "meta_machine"
@@ -21,11 +22,14 @@ COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|route

# this performs a fixup on the SRCREV for new/undefined BSPs
python __anonymous () {
- import bb, re
+ import bb, re, string

rev = bb.data.getVar("SRCREV_machine", d, 1)
if rev == "standard":
bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+
+ kerntype = string.replace(bb.data.expand("${LINUX_KERNEL_TYPE}", d), "_", "-")
+ bb.data.setVar("LINUX_KERNEL_TYPE_EXTENSION", kerntype, d)
}

SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index f40fe38..6677f99 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -1,15 +1,15 @@
inherit kernel
require linux-yocto.inc

-KMACHINE_qemux86 = "common_pc/base"
-KMACHINE_qemux86-64 = "common_pc_64"
-KMACHINE_qemuppc = "qemu_ppc32"
-KMACHINE_qemumips = "mti_malta32_be"
-KMACHINE_qemuarm = "arm_versatile_926ejs"
-KMACHINE_atom-pc = "atom-pc"
-KMACHINE_routerstationpro = "routerstationpro"
-KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
-KMACHINE_beagleboard = "beagleboard"
+KMACHINE_qemux86 = "yocto/standard/common_pc/base"
+KMACHINE_qemux86-64 = "yocto/standard/common-pc-64"
+KMACHINE_qemuppc = "yocto/standard/qemu-ppc32"
+KMACHINE_qemumips = "yocto/standard/mti-malta32-be"
+KMACHINE_qemuarm = "yocto/standard/arm-versatile-926ejs"
+KMACHINE_atom-pc = "yocto/standard/common-pc/atom-pc"
+KMACHINE_routerstationpro = "yocto/standard/routerstationpro"
+KMACHINE_mpc8315e-rdb = "yocto/standard/fsl-mpc8315e-rdb"
+KMACHINE_beagleboard = "yocto/standard/beagleboard"

LINUX_VERSION ?= "2.6.37"
LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
--
1.7.0.4

Richard/Saul,

I'll repeat what is in the patch here:

The existing 2.6.34 kernel tree uses _ where poky typically
uses -. This is a historical artifact, since working with
gnu Make and shells means avoiding - is wise. The opposite
is true in Yocto.

To avoid using the _ reserved character wherever possible
we can simply remove it from the branch names in the
new 2.6.37 kernel, but to keep the content stable in the
0.9 2.6.34 kernel, we map _ to - for the purposes of
packaging.

To further faciliate this switch, the branch names no
longer need to be shortened in the KMACHINE mappings, but
can be fully specified and the tools/processing adapt as
required. This gives us the flexibility to map multiple
boards to a single branch for building.

-------

I've been building with this for a week, Darren has also
had sucess with this as well.

*** We need to coordinate the merge, I've pushed the new
branches to the linux-yocto-2.6.37 kernel, but we need
to purge the old branches as well.

So send me a heads up and I'll do that removal once
this merges.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield <bruce.ashfield@...>
---


Bruce Ashfield (1):
linux-yocto: remove or adjust to _ in branch names

meta/classes/kernel-yocto.bbclass | 12 +++++-------
.../conf/distro/include/poky-default-revisions.inc | 2 +-
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 8 ++++++--
meta/recipes-kernel/linux/linux-yocto_git.bb | 18 +++++++++---------
4 files changed, 21 insertions(+), 19 deletions(-)

I've compiled a list (based on the mirrors.kernel.org calendar and my research) of upcoming releases prior to and immediately after Yocto v1.0. These may be OS versions we should plan on being able to support. I was not able to find info on release dates for Debian sneezy, Mandravia or Slackware, so if anyone has that info, I'd appreciate it so we can fill in the blanks.

-b

--------------------------------

November 2nd
Fedora 14: Final

March 1st
Fedora 15 Alpha

Mar 10 2011
openSUSE 11.4

April 5th
Fedora 15 Beta

April 28th
Ubuntu 11.04

May 10th
Fedora 15 Final

Hi, all,

I just create a new wiki page to track LTP status for Yocto Project:

https://wiki.yoctoproject.org/wiki/LTP_result

Embedded Linux distribution is unlike a typical desktop Linux, because it's normally
customized for specific purpose and thus not all packages required by normal Linux
test suites (LTP/POSIX/LSB) are included in a specific profile.

Given that, the major purpose of this wiki page is for tracking and reference. For
one we want to track the ongoing trend in each Yocto release/milestone, and fix
regressions in time. In the meantime, we also want to understand what a failure
implicates. Is it simply come from the fact of customization, or from some problems
in installed packages? For the former we want to document them, and for the latter
we'd like to fix them.

I tried to make the page simple, as there could be many combinations to show
the data (milestones, machines, error types, etc.). Now it's still experimental and
under development. So far I use qemux86 result from the 12/11 nightly result
as the example based on SDK profile. Later when our QA team finish the M2 test,
we'll update this page to reflect latest milestone information.

Thanks
Kevin

From: Tim Bird
Sent: Friday, December 17, 2010 4:37 AM

For those interested in my build saga,
I performed a mostly successful build of poky-minimal-image
on my old Fedora 8 distro (oustide my Sony firewall).

This was after I installed an poky 586 sdk, and set
path to include /opt/poky/.../usr/bin (to pick up python 2.6.5)

and after adding a fedora package to add chrpath to my
system (not listed on the yocto distro help page).

The build took 6 hours, and the emulator didn't quite finish.
Here was the error:
ERROR: Logfile of failure stored in:
/a/home/tbird/work/yocto/poky-4.0-build/tmp/work/i686-linux/qemu-native-0.12.4-r22/t
emp/log.do_configure.12332
Log data follows:
| You need libGL.so and libGLU.so to exist in your library path and the
development headers for SDL installed to build qemu-native.
| Ubuntu package names are: libgl1-mesa-dev, libglu1-mesa-dev and
libsdl1.2-dev
| ERROR: Task failed: ('function do_configure failed',
'/a/home/tbird/work/yocto/poky-4.0-build/tmp/work/i686-linux/qemu-native-0.12.4-r22/
temp/log.do_configure.12332')
NOTE: package qemu-native-0.12.4-r22: task do_configure: Failed

I checked, and indeed my system is missing SDL-devel. Due to
some broken dependencies in my yum database, it turned out to be
difficult to install this package, and I'm going to give up
(again) on this machine.

I noticed after the build that my yocto directory was consuming
30G of disk space. The big parts were in
yocto/poky-4.0-build/tmp/work
$ du -sh *
2.2M all-poky-linux
18G i586-poky-linux
3.5G i686-linux
4.6G qemux86-poky-linux

This seems a bit high? Is this normal?
-- Tim

It's normal. There're several reasons for that. One is the debug symbols. The other
is that Yocto implements build tasks in staged way to avoid interference among tasks,
which results in multiple copies of installed files. For example, do_install() installs
compilation output to ${WORKDIR}/image, and then do_package() copies image/ to
a 'package' directory for stripping and some path tweaks, and then further copies
into a packages-split directory which prepare for final packaging of base, -dev, -doc,
locale, etc. packages. This way the input and output of each task is clear and less
error-prone, but in some sacrifice of increased disk usage. :-)

Thanks
Kevin

Hi, Jessica and all

If anyone who want to try installer scripts, we will have a poweroff tomorrow, so I am not sure whether lianhao's repository still works or not.
Just for your info!

Thanks& Regards,
criping

Cool.
Thanks a lot!
Would this also be the place where user contributed bsp's (like the
one for kirkwood I posted a while ago) could go in?

Frans

Hi, Jessica and Josh

This is a simple bb class file for generating installer tarball. And thanks for Lianhao/ke/Dexuan...'s
help which saves me lots of efforts...

It contains below steps:

1. fetch opkg source tarball to download location and copy other six files (opkg conf, scripts, user conf) to workdir (do_fetch)
2. unpacking opkg source tarball to workdir (do_unpack). {So accordingly, in installer script, I will remove the untar step}
3. when do_install, tar the the opkg source file directory as well as other six files and copy it to sdk output directory (tmp/deploy/sdk)

After bitbaking, adt-installer.tar.bz2 will be in ${build}/tmp/deploy/sdk and untar it. User can untar the tarball and running yocto_install installation script.

I only attach bb file in the attachment. For installer, after RP's review, I will merge it into the final patch together with this bb file.
If you're interest about the current installer implementation, please fetch it @
http://llu-piketon.sh.intel.com/installer.tar


Any comments are highly appreciated. Actually I am not very sure about many options in bb file.


Thanks & Regards,
criping

All,

Please take some time, especially if you've been through a Yocto/poky
release cycle, to review and provide feedback to the enclosed Yocto v1.0
Release Plan. This plan spells out the day by day activities of the
upcoming M4 release sprint for Yocto v1.0.

This plan (sans graphics for the moment) is also available via the wiki:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v._1.0_Release_Cycle

-b

From: Garman, Scott A
Sent: Friday, December 17, 2010 5:57 AM

On 12/15/2010 06:40 PM, Tian, Kevin wrote:

On the other hand, along with this I realize that there's one area we need further
discuss. How often should we upgrade packages in a given release cycle? MeeGo
only does once. For Yocto we want to keep our recipes in cutting-edge which is
why we schedule two upgrade windows in M2 and M3 this time.

I'd like to question this. Is the goal for Poky/Yocto to track the
bleeding-edge releases of software, or is the goal to be a well-tested
and stable foundation for embedded software applications?

I think the both. :-)

Upgrading a recipe within a couple of weeks of its release may end up
using more of our resources if/when we encounter new bugs that were
introduced in the new release. Or worse, if we don't encounter them
during distro builds and then our users take our release and discover
them for themselves.

This is always being a tradeoff in all distributions. There's no simple guideline
whether there's severe risk to upgrade to a latest release, and I think the
one general rule is to pick up a newer release with enough stability. How to
judge that? This finally goes to the owner of each recipe.

I'm not saying we need to be as conservative as long-term-support
enterprise Linux distros, but IMHO I think racing to always upgrade our
recipes to versions released a handful of weeks ago can be
counterproductive in many situations.

A policy I might put forward for consideration is this: recipe upgrades
are done once per release cycle, and upstream versions that have come
out within the last 30 days should not be upgraded unless we have a
really good reason for doing so.

I think there's no simple guideline meaningful in general context like this. All the
decisions should come to the actual recipe maintainer, based on his knowledge
in this specific area. Once we involve with upstream more closely, we should be
able to tell whether a new release is worthy to go or not in most cases.

Besides that, what in general we can do is about the process.

That's why we come up a two phase upgrade windows in 1.0. With the first window
as the major upgrade, and the 2nd window to catch up minor version changes which
should be with little risk. If there's important release coming out in 2nd window, we
(again mainly the recipe owner) again need to make decision instead of a simple
global rule "to go" or "not to go". As I raised in early thread, I suggest to those
minor version upgrade in later of 2nd window.

That's also why we're currently developing the package reporting system, which is
expected to check upstream release periodically and once a new release coming
out the maintainer gets notified to make decision.

So in a nutshell:
- the general goal is to being cutting-edge
- we work out a process which give recipe maintainers enough opportunities
to check new releases of packages they own, toward our 'cutting-edge' goal
- Saul generates a general candidate list from those info in start of each
upgrade window
- then it's always recipe maintainers to make decision whether a new release
should go or not, based on its stability, new features and risks given time to Yocto
release point. If there's a decision not to upgrade, the maintainer should document
it well

Having said that so far our process is not exactly as expected yet, and our expertise
on each area still need time. But I think that's the what we'll need to be. :-)

Thanks
Kevin

On 12/16/2010 06:17 AM, Yu, Ke wrote:

Thanks Saul for working out this list.

I am a bit surprised on the large number of to-be-upgraded list: 160, because according to our plan, we actually upgrade most of the recipes in M2, and only a small number of recipes are supposed to be left for M3. To find out the reason why, PRC team collect some data to analysis, and here is the result:

I am sorry I gave everyone a scare with my numbers, as Kevin points out, currently this information is stateless, I am going my best to gather the information that I have at hand

Among the 160, PRC team (Dexuan, Dongxiao, Edwin, Ke, Qing) owns 105 recipes. the 105 recipes can be grouped into 3 cases:
Case A: the recipe is not planned to upgrade in M2, mostly due to that it is up-to-update in M2 planning time, and later has new version available.
Case B: the recipe is planned to upgrade in M2, but not upgrade and leave it to M3
Case C: the recipe is planned to upgrade in M2, and it is upgraded in M2, but later has new version available.

Can you send me a list of the Case C recipes, I would like to review if we need to update all of them. As I said in the past some of these may be the Xserver and libraries which we do want to update since we went to an RC release first.

Sau!

According to our data collection, Case A has 31 recipes, Case B has 21 recipes, Case C has 53 recipes. In other word, in M2 time, we leave 21 recipes (Case B) for M3, but due to new version available after the planning, there are extra 84 recipes (case A + case C) added to be upgraded. Even only count Case C, we can see almost 50% ofM3 to-be-upgraded recipes are already upgraded in M2. This is probably one area we can improved in the future.

Thanks

Regards
Ke

-----Original Message-----
From: poky-bounces@... [mailto:poky-
bounces@...] On Behalf Of Saul Wold
Sent: Thursday, December 16, 2010 8:58 AM
To: Yocto Project Discussion; poky@...
Subject: [poky] Recipe Updating Status and call to action


Folks,

As we get ready for M3 opening up shortly, I wanted to get folks aware of where
we are with M2 and the recipe updating process. Based on my rough reckoning,
we had about 266 recipes that needed updating at the start of M2, we updated
about 110 (possibly more). There are now about 160 recipes in the update list
that need tackling.

Also, the distro tracking data for Version information is getting stale, there are
about 135 RECIPE_LATEST_VERSION metadata tags that need to be updated.

I have attached a spreadsheet that shows the update status of both the
upstream (RMatch Column) and tracking data (TMatch Column).

I would like to see the team and community pitch in and complete these 160
recipe updates for the 1.0 Release. Please be sure the ownership /
RECIPE_MAINTAINER information is correct.

IMPORTANT: Please use distro/stage in poky-contrib to update the
distro_tracking_fields.inc file, I have many updates in that already, I will do my
best not to rebase that until we get it updated.

The attached spread sheet contains 3 Sheets, please review the 2nd and 3rd
sheets (Labeled Tracking Updates and Recipe Updates respectively).

Thanks.

--
Sau!

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

Hello All,

Recently Richard sent around an email proposing that a new repository be created for hosting layers that are not part of the core Yocto Metadata.

This new repository "poky-extras" can host different contributed layers and will be open to any one.

From Richard's proposed ground rules:

* it has the OE style open contributions model
* consists of a set of layers, each clearly identified at the top level
* each layer has a clearly named maintainer or maintainers
* people respect the layer maintainers
* layers are split into logical "topics" where at all possible

The first layer contained in this new repository is the meta-linaro layer, the top level repository will be removed short since it will now be maintained in poky-extras.

If you require write access to this repository, please send your request to git-requests@...

--
Sau!

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

On 12/15/2010 06:40 PM, Tian, Kevin wrote:

On the other hand, along with this I realize that there's one area we need further
discuss. How often should we upgrade packages in a given release cycle? MeeGo
only does once. For Yocto we want to keep our recipes in cutting-edge which is
why we schedule two upgrade windows in M2 and M3 this time.

I'd like to question this. Is the goal for Poky/Yocto to track the bleeding-edge releases of software, or is the goal to be a well-tested and stable foundation for embedded software applications?

Upgrading a recipe within a couple of weeks of its release may end up using more of our resources if/when we encounter new bugs that were introduced in the new release. Or worse, if we don't encounter them during distro builds and then our users take our release and discover them for themselves.

I'm not saying we need to be as conservative as long-term-support enterprise Linux distros, but IMHO I think racing to always upgrade our recipes to versions released a handful of weeks ago can be counterproductive in many situations.

A policy I might put forward for consideration is this: recipe upgrades are done once per release cycle, and upstream versions that have come out within the last 30 days should not be upgraded unless we have a really good reason for doing so.

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project

On Thu, Dec 16, 2010 at 12:36 PM, Tim Bird <tim.bird@...> wrote:

For those interested in my build saga,
I performed a mostly successful build of poky-minimal-image
on my old Fedora 8 distro (oustide my Sony firewall).

This was after I installed an poky 586 sdk, and set
path to include /opt/poky/.../usr/bin (to pick up python 2.6.5)

and after adding a fedora package to add chrpath to my
system (not listed on the yocto distro help page).

The build took 6 hours, and the emulator didn't quite finish.
Here was the error:
ERROR: Logfile of failure stored in:
/a/home/tbird/work/yocto/poky-4.0-build/tmp/work/i686-linux/qemu-native-0.12.4-r22/temp/log.do_configure.12332
Log data follows:
| You need libGL.so and libGLU.so to exist in your library path and the
development headers for SDL installed to build qemu-native.
|        Ubuntu package names are: libgl1-mesa-dev, libglu1-mesa-dev and
libsdl1.2-dev
| ERROR: Task failed: ('function do_configure failed',
'/a/home/tbird/work/yocto/poky-4.0-build/tmp/work/i686-linux/qemu-native-0.12.4-r22/temp/log.do_configure.12332')
NOTE: package qemu-native-0.12.4-r22: task do_configure: Failed

I checked, and indeed my system is missing SDL-devel.  Due to
some broken dependencies in my yum database, it turned out to be
difficult to install this package, and I'm going to give up
(again) on this machine.

I noticed after the build that my yocto directory was consuming
30G of disk space.  The big parts were in
yocto/poky-4.0-build/tmp/work
$ du -sh *
2.2M    all-poky-linux
18G     i586-poky-linux
3.5G    i686-linux
4.6G    qemux86-poky-linux

This seems a bit high?  Is this normal?

These are build objects if you don't need them
add INHERIT += "rm_work"
to your conf/local.conf which should delete the intermediate
objects after a recipe builds.

Thx
-Khem