Date   

Re: Results of latest documentation audit, May 2011

Scott Garman <scott.a.garman@...>
 

On 05/06/2011 02:36 PM, Darren Hart wrote:
On 05/06/2011 01:29 PM, Scott Garman wrote:
Hello,

As a data point for where we stand in ensuring our packages are
producing documentation, I have some scripts which build all recipes
(using the output of bitbake -s, not world), and then check that a -doc
package is generated which is populated with files.

A summary of the results using yesterday's master are as follows:

591 recipes in total
308 recipes are building documentation
283 recipes are not building documentation

31 recipes did not build (and are counted as not building documentation
above).

The lists of recipes are attached to this email. We'd like to improve
the percentage of recipes that produce documentation (separated into
-doc packages, of course) for our next major release in October.

Our userspace recipe maintainers should look into setting aside some
time to know which of their recipes are in the "not building
documentation" list and work to improve them. A lot of this is likely to
be low-hanging fruit.
I see "linux-*" in the list. What sort of documentation are we looking
for? The linux-image* packages in Ubuntu, for example, include a
changelog and a copyright.
I'm not particularly concerned about the kernel packages. I think we can ignore it. I'll update my script to not report these recipes.

The main goal is to ensure that man pages and the like are being generated for userspace applications.

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center


Re: [PATCH 1/1] linux-yocto: move non-core machines to meta-yocto

Saul Wold <sgw@...>
 

On 05/06/2011 11:44 AM, Bruce Ashfield wrote:
The machine configuration of the non-core (non-qemu) machines
has moved to meta-yocto. Moving the branch mappings, compatibility
and SRCREVs of these machines to meta-yocto should also be
done.

Anyone using meta-yocto to build these machines will see no impact
from this change.

Signed-off-by: Bruce Ashfield<bruce.ashfield@windriver.com>
---
meta-yocto/conf/layer.conf | 3 ++-
.../linux/linux-yocto-stable_git.bbappend | 12 ++++++++++++
.../recipes-kernel/linux/linux-yocto_git.bbappend | 12 ++++++++++++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 10 +---------
meta/recipes-kernel/linux/linux-yocto_git.bb | 11 +----------
Bruce,

This need to be 2 pull requests, since the first 4 files are actually in meta-yotco, part of poky.git and the linux-yocto_git.bb is in OE-core

Please split this into 2 requests, one for oe-core, just the linux-yocto_git.bb file

and a second one to poky with the reset.

I also noted that you list the emenlow in one of the .bbappend files, but only as SRCREV_machine_emenlow, should that be there with Paul's moving emenlow to meta-intel?

Sau!

5 files changed, 28 insertions(+), 20 deletions(-)
create mode 100644 meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
create mode 100644 meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend

diff --git a/meta-yocto/conf/layer.conf b/meta-yocto/conf/layer.conf
index f11d8ed..68786b2 100644
--- a/meta-yocto/conf/layer.conf
+++ b/meta-yocto/conf/layer.conf
@@ -2,7 +2,8 @@
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a packages directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb"
+BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+ ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "yocto"
BBFILE_PATTERN_yocto := "^${LAYERDIR}/"
diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend b/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
new file mode 100644
index 0000000..ea0287d
--- /dev/null
+++ b/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
@@ -0,0 +1,12 @@
+KMACHINE_atom-pc = "atom-pc"
+KMACHINE_routerstationpro = "routerstationpro"
+KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
+KMACHINE_beagleboard = "beagleboard"
+
+SRCREV_machine_atom-pc = "72ca49ab08b8eb475cec82a10049503602325791"
+SRCREV_machine_routerstationpro = "49745cd45c92a89e70c6e2334caa80818c134562"
+SRCREV_machine_mpc8315e-rdb = "a1c0ed6bf4060c10874b2a8547d81b3169dcf16a"
+SRCREV_machine_beagleboard = "ef7f944e773950d4016b7643f9ecf052bbe250cd"
+
+COMPATIBLE_MACHINE += "(atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
+
diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend b/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend
new file mode 100644
index 0000000..e4aa7fd
--- /dev/null
+++ b/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend
@@ -0,0 +1,12 @@
+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"
+
+SRCREV_machine_emenlow = "c3bbcb676f929c4fc0511a6e66494b8770d015a1"
+SRCREV_machine_atom-pc = "b906f358fd404a1e74a961f25079274e0d933ee1"
+SRCREV_machine_routerstationpro = "95ca94d2e71ca2db6822a37a7f575fa79c3d05d0"
+SRCREV_machine_mpc8315e-rdb = "53c800c244e73d81d2832f6da306eeae3b09e5dc"
+SRCREV_machine_beagleboard = "b906f358fd404a1e74a961f25079274e0d933ee1"
+
+COMPATIBLE_MACHINE = "(mpc8315e-rdb|routerstationpro|beagleboard)"
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
index 93b06fd..66991ae 100644
--- a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -7,10 +7,6 @@ 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"

LINUX_VERSION ?= "2.6.34"
LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE_EXTENSION}"
@@ -23,10 +19,6 @@ SRCREV_machine_qemumips = "c32d40f960e3c89d07f079bec4c96dcbfc749f0b"
SRCREV_machine_qemuppc = "96d6bc31d3caaf62a966255479cc5cee0e76b1e9"
SRCREV_machine_qemux86 = "72ca49ab08b8eb475cec82a10049503602325791"
SRCREV_machine_qemux86-64 = "72ca49ab08b8eb475cec82a10049503602325791"
-SRCREV_machine_atom-pc = "72ca49ab08b8eb475cec82a10049503602325791"
-SRCREV_machine_routerstationpro = "49745cd45c92a89e70c6e2334caa80818c134562"
-SRCREV_machine_mpc8315e-rdb = "a1c0ed6bf4060c10874b2a8547d81b3169dcf16a"
-SRCREV_machine_beagleboard = "ef7f944e773950d4016b7643f9ecf052bbe250cd"
SRCREV_machine = "72ca49ab08b8eb475cec82a10049503602325791"
SRCREV_meta = "ec26387cb168e9e0976999b528b5a9dd62e3157a"

@@ -34,7 +26,7 @@ PR = "r1"
PV = "${LINUX_VERSION}+git${SRCPV}"
SRCREV_FORMAT = "meta_machine"

-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"

# this performs a fixup on historical kernel types with embedded _'s
python __anonymous () {
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index 3b4e77e..d4f2ece 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -7,10 +7,6 @@ KMACHINE_qemux86-64 = "yocto/standard/common-pc-64/base"
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"

KBRANCH = ${KMACHINE}
KMETA = meta
@@ -23,11 +19,6 @@ SRCREV_machine_qemumips = "f5d26f2eda2be8b942172cda8f27de33ebf38ec3"
SRCREV_machine_qemuppc = "7eb6c68d977d9039a2b5a734172b064a9d19cdc1"
SRCREV_machine_qemux86 = "ad62d1aab734513cd96c8f4517f816420a218e77"
SRCREV_machine_qemux86-64 = "b906f358fd404a1e74a961f25079274e0d933ee1"
-SRCREV_machine_emenlow = "c3bbcb676f929c4fc0511a6e66494b8770d015a1"
-SRCREV_machine_atom-pc = "b906f358fd404a1e74a961f25079274e0d933ee1"
-SRCREV_machine_routerstationpro = "95ca94d2e71ca2db6822a37a7f575fa79c3d05d0"
-SRCREV_machine_mpc8315e-rdb = "53c800c244e73d81d2832f6da306eeae3b09e5dc"
-SRCREV_machine_beagleboard = "b906f358fd404a1e74a961f25079274e0d933ee1"
SRCREV_machine = "b906f358fd404a1e74a961f25079274e0d933ee1"
SRCREV_meta = "ecab1e2bc12a8b0c4d064a00acc3260f6e8528c5"

@@ -37,7 +28,7 @@ SRCREV_FORMAT = "meta_machine"

SRC_URI = "git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|mpc8315e-rdb|routerstationpro|beagleboard)"
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"

# Functionality flags
KERNEL_REVISION_CHECKING ?= "t"


Re: Results of latest documentation audit, May 2011

Darren Hart <darren.hart@...>
 

On 05/06/2011 01:29 PM, Scott Garman wrote:
Hello,

As a data point for where we stand in ensuring our packages are
producing documentation, I have some scripts which build all recipes
(using the output of bitbake -s, not world), and then check that a -doc
package is generated which is populated with files.

A summary of the results using yesterday's master are as follows:

591 recipes in total
308 recipes are building documentation
283 recipes are not building documentation

31 recipes did not build (and are counted as not building documentation
above).

The lists of recipes are attached to this email. We'd like to improve
the percentage of recipes that produce documentation (separated into
-doc packages, of course) for our next major release in October.

Our userspace recipe maintainers should look into setting aside some
time to know which of their recipes are in the "not building
documentation" list and work to improve them. A lot of this is likely to
be low-hanging fruit.
I see "linux-*" in the list. What sort of documentation are we looking
for? The linux-image* packages in Ubuntu, for example, include a
changelog and a copyright.

Thanks,

--
Darren

Thanks,

Scott




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

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Results of latest documentation audit, May 2011

Scott Garman <scott.a.garman@...>
 

Hello,

As a data point for where we stand in ensuring our packages are producing documentation, I have some scripts which build all recipes (using the output of bitbake -s, not world), and then check that a -doc package is generated which is populated with files.

A summary of the results using yesterday's master are as follows:

591 recipes in total
308 recipes are building documentation
283 recipes are not building documentation

31 recipes did not build (and are counted as not building documentation above).

The lists of recipes are attached to this email. We'd like to improve the percentage of recipes that produce documentation (separated into -doc packages, of course) for our next major release in October.

Our userspace recipe maintainers should look into setting aside some time to know which of their recipes are in the "not building documentation" list and work to improve them. A lot of this is likely to be low-hanging fruit.

Thanks,

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center


Re: [PATCH 0/1] Add emenlow pieces removed from oe-core

Tom Zanussi <tom.zanussi@...>
 

On Fri, 2011-05-06 at 05:45 -0700, Paul Eggleton wrote:
From: Paul Eggleton <paul.eggleton@linux.intel.com>

This adds back the emenlow-specific pieces recently removed from oe-core.

Thanks,
Paul Eggleton <paul.eggleton@linux.intel.com>
Acked-by: Tom Zanussi <tom.zanussi@intel.com>

Pulled into meta-intel/master.

Thanks, Paul!

---


Paul Eggleton (1):
Add emenlow pieces removed from oe-core

.../recipes-core/tasks/task-core-tools.bbappend | 2 ++
.../tasks/task-poky-sdk-gmae.bbappend | 1 +
.../task-poky-standalone-gmae-sdk-target.bbappend | 1 +
.../clutter/clutter-1.4_1.4.2.bbappend | 4 ++++
.../clutter/clutter-1.6_1.6.14.bbappend | 4 ++++
.../recipes-graphics/clutter/clutter_git.bbappend | 4 ++++
.../recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend | 2 ++
.../recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend | 2 ++
8 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 meta-emenlow/recipes-core/tasks/task-core-tools.bbappend
create mode 100644 meta-emenlow/recipes-gnome/tasks/task-poky-sdk-gmae.bbappend
create mode 100644 meta-emenlow/recipes-gnome/tasks/task-poky-standalone-gmae-sdk-target.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter-1.4_1.4.2.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter-1.6_1.6.14.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter_git.bbappend
create mode 100644 meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend
create mode 100644 meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend


[PATCH 1/1] linux-yocto: move non-core machines to meta-yocto

Bruce Ashfield <bruce.ashfield@...>
 

The machine configuration of the non-core (non-qemu) machines
has moved to meta-yocto. Moving the branch mappings, compatibility
and SRCREVs of these machines to meta-yocto should also be
done.

Anyone using meta-yocto to build these machines will see no impact
from this change.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
meta-yocto/conf/layer.conf | 3 ++-
.../linux/linux-yocto-stable_git.bbappend | 12 ++++++++++++
.../recipes-kernel/linux/linux-yocto_git.bbappend | 12 ++++++++++++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 10 +---------
meta/recipes-kernel/linux/linux-yocto_git.bb | 11 +----------
5 files changed, 28 insertions(+), 20 deletions(-)
create mode 100644 meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
create mode 100644 meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend

diff --git a/meta-yocto/conf/layer.conf b/meta-yocto/conf/layer.conf
index f11d8ed..68786b2 100644
--- a/meta-yocto/conf/layer.conf
+++ b/meta-yocto/conf/layer.conf
@@ -2,7 +2,8 @@
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a packages directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb"
+BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+ ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "yocto"
BBFILE_PATTERN_yocto := "^${LAYERDIR}/"
diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend b/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
new file mode 100644
index 0000000..ea0287d
--- /dev/null
+++ b/meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
@@ -0,0 +1,12 @@
+KMACHINE_atom-pc = "atom-pc"
+KMACHINE_routerstationpro = "routerstationpro"
+KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
+KMACHINE_beagleboard = "beagleboard"
+
+SRCREV_machine_atom-pc = "72ca49ab08b8eb475cec82a10049503602325791"
+SRCREV_machine_routerstationpro = "49745cd45c92a89e70c6e2334caa80818c134562"
+SRCREV_machine_mpc8315e-rdb = "a1c0ed6bf4060c10874b2a8547d81b3169dcf16a"
+SRCREV_machine_beagleboard = "ef7f944e773950d4016b7643f9ecf052bbe250cd"
+
+COMPATIBLE_MACHINE += "(atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
+
diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend b/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend
new file mode 100644
index 0000000..e4aa7fd
--- /dev/null
+++ b/meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend
@@ -0,0 +1,12 @@
+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"
+
+SRCREV_machine_emenlow = "c3bbcb676f929c4fc0511a6e66494b8770d015a1"
+SRCREV_machine_atom-pc = "b906f358fd404a1e74a961f25079274e0d933ee1"
+SRCREV_machine_routerstationpro = "95ca94d2e71ca2db6822a37a7f575fa79c3d05d0"
+SRCREV_machine_mpc8315e-rdb = "53c800c244e73d81d2832f6da306eeae3b09e5dc"
+SRCREV_machine_beagleboard = "b906f358fd404a1e74a961f25079274e0d933ee1"
+
+COMPATIBLE_MACHINE = "(mpc8315e-rdb|routerstationpro|beagleboard)"
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
index 93b06fd..66991ae 100644
--- a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -7,10 +7,6 @@ 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"

LINUX_VERSION ?= "2.6.34"
LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE_EXTENSION}"
@@ -23,10 +19,6 @@ SRCREV_machine_qemumips = "c32d40f960e3c89d07f079bec4c96dcbfc749f0b"
SRCREV_machine_qemuppc = "96d6bc31d3caaf62a966255479cc5cee0e76b1e9"
SRCREV_machine_qemux86 = "72ca49ab08b8eb475cec82a10049503602325791"
SRCREV_machine_qemux86-64 = "72ca49ab08b8eb475cec82a10049503602325791"
-SRCREV_machine_atom-pc = "72ca49ab08b8eb475cec82a10049503602325791"
-SRCREV_machine_routerstationpro = "49745cd45c92a89e70c6e2334caa80818c134562"
-SRCREV_machine_mpc8315e-rdb = "a1c0ed6bf4060c10874b2a8547d81b3169dcf16a"
-SRCREV_machine_beagleboard = "ef7f944e773950d4016b7643f9ecf052bbe250cd"
SRCREV_machine = "72ca49ab08b8eb475cec82a10049503602325791"
SRCREV_meta = "ec26387cb168e9e0976999b528b5a9dd62e3157a"

@@ -34,7 +26,7 @@ PR = "r1"
PV = "${LINUX_VERSION}+git${SRCPV}"
SRCREV_FORMAT = "meta_machine"

-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"

# this performs a fixup on historical kernel types with embedded _'s
python __anonymous () {
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index 3b4e77e..d4f2ece 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -7,10 +7,6 @@ KMACHINE_qemux86-64 = "yocto/standard/common-pc-64/base"
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"

KBRANCH = ${KMACHINE}
KMETA = meta
@@ -23,11 +19,6 @@ SRCREV_machine_qemumips = "f5d26f2eda2be8b942172cda8f27de33ebf38ec3"
SRCREV_machine_qemuppc = "7eb6c68d977d9039a2b5a734172b064a9d19cdc1"
SRCREV_machine_qemux86 = "ad62d1aab734513cd96c8f4517f816420a218e77"
SRCREV_machine_qemux86-64 = "b906f358fd404a1e74a961f25079274e0d933ee1"
-SRCREV_machine_emenlow = "c3bbcb676f929c4fc0511a6e66494b8770d015a1"
-SRCREV_machine_atom-pc = "b906f358fd404a1e74a961f25079274e0d933ee1"
-SRCREV_machine_routerstationpro = "95ca94d2e71ca2db6822a37a7f575fa79c3d05d0"
-SRCREV_machine_mpc8315e-rdb = "53c800c244e73d81d2832f6da306eeae3b09e5dc"
-SRCREV_machine_beagleboard = "b906f358fd404a1e74a961f25079274e0d933ee1"
SRCREV_machine = "b906f358fd404a1e74a961f25079274e0d933ee1"
SRCREV_meta = "ecab1e2bc12a8b0c4d064a00acc3260f6e8528c5"

@@ -37,7 +28,7 @@ SRCREV_FORMAT = "meta_machine"

SRC_URI = "git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|mpc8315e-rdb|routerstationpro|beagleboard)"
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"

# Functionality flags
KERNEL_REVISION_CHECKING ?= "t"
--
1.7.0.4


[PATCH 0/1] linux-yocto: move non-core machines to meta-yocto

Bruce Ashfield <bruce.ashfield@...>
 

The machine configuration of the non-core (non-qemu) machines
has moved to meta-yocto. Moving the branch mappings, compatibility
and SRCREVs of these machines to meta-yocto should also be
done.

Anyone using meta-yocto to build these machines will see no impact
from this change.

Acked-by: Darren Hart <dvhart@linux.intel.com>

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@windriver.com>
---


Bruce Ashfield (1):
linux-yocto: move non-core machines to meta-yocto

meta-yocto/conf/layer.conf | 3 ++-
.../linux/linux-yocto-stable_git.bbappend | 12 ++++++++++++
.../recipes-kernel/linux/linux-yocto_git.bbappend | 12 ++++++++++++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 10 +---------
meta/recipes-kernel/linux/linux-yocto_git.bb | 11 +----------
5 files changed, 28 insertions(+), 20 deletions(-)
create mode 100644 meta-yocto/recipes-kernel/linux/linux-yocto-stable_git.bbappend
create mode 100644 meta-yocto/recipes-kernel/linux/linux-yocto_git.bbappend


[PATCH 1/1] Add emenlow pieces removed from oe-core

Paul Eggleton
 

From: Paul Eggleton <paul.eggleton@linux.intel.com>

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
.../recipes-core/tasks/task-core-tools.bbappend | 2 ++
.../tasks/task-poky-sdk-gmae.bbappend | 1 +
.../task-poky-standalone-gmae-sdk-target.bbappend | 1 +
.../clutter/clutter-1.4_1.4.2.bbappend | 4 ++++
.../clutter/clutter-1.6_1.6.14.bbappend | 4 ++++
.../recipes-graphics/clutter/clutter_git.bbappend | 4 ++++
.../recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend | 2 ++
.../recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend | 2 ++
8 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 meta-emenlow/recipes-core/tasks/task-core-tools.bbappend
create mode 100644 meta-emenlow/recipes-gnome/tasks/task-poky-sdk-gmae.bbappend
create mode 100644 meta-emenlow/recipes-gnome/tasks/task-poky-standalone-gmae-sdk-target.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter-1.4_1.4.2.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter-1.6_1.6.14.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter_git.bbappend
create mode 100644 meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend
create mode 100644 meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend

diff --git a/meta-emenlow/recipes-core/tasks/task-core-tools.bbappend b/meta-emenlow/recipes-core/tasks/task-core-tools.bbappend
new file mode 100644
index 0000000..9743e2c
--- /dev/null
+++ b/meta-emenlow/recipes-core/tasks/task-core-tools.bbappend
@@ -0,0 +1,2 @@
+RDEPENDS_task-core-tools-profile_append_emenlow = " lttng-ust systemtap"
+
diff --git a/meta-emenlow/recipes-gnome/tasks/task-poky-sdk-gmae.bbappend b/meta-emenlow/recipes-gnome/tasks/task-poky-sdk-gmae.bbappend
new file mode 100644
index 0000000..ff258e0
--- /dev/null
+++ b/meta-emenlow/recipes-gnome/tasks/task-poky-sdk-gmae.bbappend
@@ -0,0 +1 @@
+SDK-EXTRAS_emenlow ?= " lttng-ust-dev"
diff --git a/meta-emenlow/recipes-gnome/tasks/task-poky-standalone-gmae-sdk-target.bbappend b/meta-emenlow/recipes-gnome/tasks/task-poky-standalone-gmae-sdk-target.bbappend
new file mode 100644
index 0000000..ff258e0
--- /dev/null
+++ b/meta-emenlow/recipes-gnome/tasks/task-poky-standalone-gmae-sdk-target.bbappend
@@ -0,0 +1 @@
+SDK-EXTRAS_emenlow ?= " lttng-ust-dev"
diff --git a/meta-emenlow/recipes-graphics/clutter/clutter-1.4_1.4.2.bbappend b/meta-emenlow/recipes-graphics/clutter/clutter-1.4_1.4.2.bbappend
new file mode 100644
index 0000000..71677ad
--- /dev/null
+++ b/meta-emenlow/recipes-graphics/clutter/clutter-1.4_1.4.2.bbappend
@@ -0,0 +1,4 @@
+DEPENDS_emenlow = "${STDDEPENDS} virtual/xserver-xf86 virtual/libgl"
+EXTRA_OECONF_emenlow = "${BASE_CONF} --with-flavour=glx"
+PACKAGE_ARCH_emenlow = "${MACHINE_ARCH}"
+
diff --git a/meta-emenlow/recipes-graphics/clutter/clutter-1.6_1.6.14.bbappend b/meta-emenlow/recipes-graphics/clutter/clutter-1.6_1.6.14.bbappend
new file mode 100644
index 0000000..71677ad
--- /dev/null
+++ b/meta-emenlow/recipes-graphics/clutter/clutter-1.6_1.6.14.bbappend
@@ -0,0 +1,4 @@
+DEPENDS_emenlow = "${STDDEPENDS} virtual/xserver-xf86 virtual/libgl"
+EXTRA_OECONF_emenlow = "${BASE_CONF} --with-flavour=glx"
+PACKAGE_ARCH_emenlow = "${MACHINE_ARCH}"
+
diff --git a/meta-emenlow/recipes-graphics/clutter/clutter_git.bbappend b/meta-emenlow/recipes-graphics/clutter/clutter_git.bbappend
new file mode 100644
index 0000000..71677ad
--- /dev/null
+++ b/meta-emenlow/recipes-graphics/clutter/clutter_git.bbappend
@@ -0,0 +1,4 @@
+DEPENDS_emenlow = "${STDDEPENDS} virtual/xserver-xf86 virtual/libgl"
+EXTRA_OECONF_emenlow = "${BASE_CONF} --with-flavour=glx"
+PACKAGE_ARCH_emenlow = "${MACHINE_ARCH}"
+
diff --git a/meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend b/meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend
new file mode 100644
index 0000000..92eabf2
--- /dev/null
+++ b/meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend
@@ -0,0 +1,2 @@
+QT_GLFLAGS_emenlow = "-opengl"
+
diff --git a/meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend b/meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend
new file mode 100644
index 0000000..92eabf2
--- /dev/null
+++ b/meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend
@@ -0,0 +1,2 @@
+QT_GLFLAGS_emenlow = "-opengl"
+
--
1.7.4.1


[PATCH 0/1] Add emenlow pieces removed from oe-core

Paul Eggleton
 

From: Paul Eggleton <paul.eggleton@linux.intel.com>

This adds back the emenlow-specific pieces recently removed from oe-core.

Thanks,
Paul Eggleton <paul.eggleton@linux.intel.com>
---


Paul Eggleton (1):
Add emenlow pieces removed from oe-core

.../recipes-core/tasks/task-core-tools.bbappend | 2 ++
.../tasks/task-poky-sdk-gmae.bbappend | 1 +
.../task-poky-standalone-gmae-sdk-target.bbappend | 1 +
.../clutter/clutter-1.4_1.4.2.bbappend | 4 ++++
.../clutter/clutter-1.6_1.6.14.bbappend | 4 ++++
.../recipes-graphics/clutter/clutter_git.bbappend | 4 ++++
.../recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend | 2 ++
.../recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend | 2 ++
8 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 meta-emenlow/recipes-core/tasks/task-core-tools.bbappend
create mode 100644 meta-emenlow/recipes-gnome/tasks/task-poky-sdk-gmae.bbappend
create mode 100644 meta-emenlow/recipes-gnome/tasks/task-poky-standalone-gmae-sdk-target.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter-1.4_1.4.2.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter-1.6_1.6.14.bbappend
create mode 100644 meta-emenlow/recipes-graphics/clutter/clutter_git.bbappend
create mode 100644 meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend
create mode 100644 meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend

--
1.7.4.1


Yocto weekly bug trend charts -- WW18

Xu, Jiajun <jiajun.xu@...>
 

Hi all,
This is latest Yocto bug trend chart for WW18. The open bug number increased a lot from 182 to 185.

Best Regards,
Jiajun


[PATCH 3/3] linux-yocto: update SRCREVs

Bruce Ashfield <bruce.ashfield@...>
 

Updating the linux-yocto/2.6.37 SRCREVs to pickup:

perf tool: Fix gcc 4.6.0 issues

1/1 [
Author: Kyle McMartin
Email: kyle@mcmartin.ca
Subject: perf tool: Fix gcc 4.6.0 issues
Date: Thu, 5 May 2011 00:06:01 -0400

commit fb7d0b3cefb80a105f7fd26bbc62e0cbf9192822 upstream.

GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf
due to the -Werror=unused-but-set-variable flag.

I've gone through and annotated some of the assignments that had side
effects (ie: return value from a function) with the __used annotation,
and in some cases, just removed unused code.

In a few cases, we were assigning something useful, but not using it in
later parts of the function.

kyle@dreadnought:~/src% gcc --version
gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3)

Cc: Ingo Molnar <mingo@redhat.com>
LKML-Reference: <20110124161304.GK27353@bombadil.infradead.org>
Signed-off-by: Kyle McMartin <kyle@redhat.com>
[ committer note: Fixed up the annotation fixes, as that code moved recently ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
[Backported to 2.6.38.2 by deleting unused but set variables]
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[Backported to linux-yocto kernel git version]
Signed-off-by: Khem Raj <raj.khem@gmail.com>
]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
meta/recipes-kernel/linux/linux-yocto_git.bb | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index 8a46e02..3b4e77e 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -18,20 +18,20 @@ KMETA = meta
LINUX_VERSION ?= "2.6.37"
LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"

-SRCREV_machine_qemuarm = "e5ca41def834db9d18b28393a45d53a8d18f3d05"
-SRCREV_machine_qemumips = "9bbc8e3432406429923fab0de038af5d3e647901"
-SRCREV_machine_qemuppc = "f0ff494e62bfaa921e844c1ec7fe6cf4a977980a"
-SRCREV_machine_qemux86 = "cb0537a40dadea20f12bc10e0986fd2a70290b42"
-SRCREV_machine_qemux86-64 = "69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3"
-SRCREV_machine_emenlow = "2215a346eb4f9e09053d00bdf61ed999ff80e029"
-SRCREV_machine_atom-pc = "69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3"
-SRCREV_machine_routerstationpro = "8db69980d76e1f863af409e70175963f23de83ab"
-SRCREV_machine_mpc8315e-rdb = "6861d8a4d58f8aa75997f7678cc454791544507a"
-SRCREV_machine_beagleboard = "69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3"
-SRCREV_machine = "69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3"
+SRCREV_machine_qemuarm = "b0375c21e29453458f9aa9986dc3f1ec69bf1aef"
+SRCREV_machine_qemumips = "f5d26f2eda2be8b942172cda8f27de33ebf38ec3"
+SRCREV_machine_qemuppc = "7eb6c68d977d9039a2b5a734172b064a9d19cdc1"
+SRCREV_machine_qemux86 = "ad62d1aab734513cd96c8f4517f816420a218e77"
+SRCREV_machine_qemux86-64 = "b906f358fd404a1e74a961f25079274e0d933ee1"
+SRCREV_machine_emenlow = "c3bbcb676f929c4fc0511a6e66494b8770d015a1"
+SRCREV_machine_atom-pc = "b906f358fd404a1e74a961f25079274e0d933ee1"
+SRCREV_machine_routerstationpro = "95ca94d2e71ca2db6822a37a7f575fa79c3d05d0"
+SRCREV_machine_mpc8315e-rdb = "53c800c244e73d81d2832f6da306eeae3b09e5dc"
+SRCREV_machine_beagleboard = "b906f358fd404a1e74a961f25079274e0d933ee1"
+SRCREV_machine = "b906f358fd404a1e74a961f25079274e0d933ee1"
SRCREV_meta = "ecab1e2bc12a8b0c4d064a00acc3260f6e8528c5"

-PR = "r16"
+PR = "r17"
PV = "${LINUX_VERSION}+git${SRCPV}"
SRCREV_FORMAT = "meta_machine"

--
1.7.0.4


[PATCH 2/3] linux-yocto: safely process unbranched repositories

Bruce Ashfield <bruce.ashfield@...>
 

The BSP bootstrap and -dev use cases can be applied against
unbranched or repos without meta data. To allow the proper
and safe processing of those repositories, slight modifications
to the tools are required to pass the branch on the command
line (rather than detecting it always) and to only checkout
branches that exist.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
meta/classes/kernel-yocto.bbclass | 7 +++++--
.../kern-tools/kern-tools-native_git.bb | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 78a1309..ffc0b4c 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -25,7 +25,7 @@ do_patch() {
addon_features="$addon_features --feature $feat"
done
fi
- updateme ${addon_features} ${ARCH} ${MACHINE} ${WORKDIR}
+ updateme --branch ${kbranch} ${addon_features} ${ARCH} ${MACHINE} ${WORKDIR}
if [ $? -ne 0 ]; then
echo "ERROR. Could not update ${kbranch}"
exit 1
@@ -87,9 +87,12 @@ do_kernel_configme() {
if [ -n "${YOCTO_KERNEL_EXTERNAL_BRANCH}" ]; then
# switch from a generic to a specific branch
kbranch=${YOCTO_KERNEL_EXTERNAL_BRANCH}
+ cd ${S}
+ git checkout ${kbranch}
+ else
+ cd ${S}
fi

- cd ${S}
configme --reconfig --output ${B} ${kbranch} ${MACHINE}
if [ $? -ne 0 ]; then
echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index cc71179..820765e 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8

DEPENDS = "git-native guilt-native"

-SRCREV = "92b965b02e3ac32badde3ee71a1e7d3a85cedeb8"
+SRCREV = "c5896a60acc61f8966cfee3bb241ff564610cea4"
PR = r10
PV = "0.1+git${SRCPV}"

--
1.7.0.4


[PATCH 1/3] linux-yocto: apply meta data to external repos

Bruce Ashfield <bruce.ashfield@...>
 

To support quick uprev and testing, it is desireable to build
repositories that do not have embedded meta data. In this scenario
the meta data can be automatically created or provided externally.
This commit supports the first situation by detecting the lack
of meta data and then automatically creating a base set of meta
files.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
meta/classes/kernel-yocto.bbclass | 27 +++++++++++++++----
.../kern-tools/kern-tools-native_git.bb | 2 +-
2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index fc9f3a7..78a1309 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -66,8 +66,15 @@ IFS='
fi
cd ${S}

- # checkout and clobber and unimportant files
- git checkout -f ${KBRANCH}
+ set +e
+ git show-ref --quiet --verify -- "refs/heads/${KBRANCH}"
+ if [ $? -eq 0 ]; then
+ # checkout and clobber and unimportant files
+ git checkout -f ${KBRANCH}
+ else
+ echo "Not checking out ${KBRANCH}, it will be created later"
+ git checkout -f master
+ fi
}
do_kernel_checkout[dirs] = "${S}"

@@ -105,21 +112,29 @@ python do_kernel_configcheck() {
bb.plain( "%s" % result )
}

+# overrides the base kernel_do_configure, since we don't want all the
+# defconfig processing in there
+kernel_do_configure() {
+ yes '' | oe_runmake oldconfig
+}
+
+
# Ensure that the branches (BSP and meta) are on the locatios specified by
# their SRCREV values. If they are NOT on the right commits, the branches
# are reset to the correct commit.
do_validate_branches() {
cd ${S}
- branch_head=`git show-ref -s --heads ${KBRANCH}`
- meta_head=`git show-ref -s --heads ${KMETA}`
- target_branch_head="${SRCREV_machine}"
- target_meta_head="${SRCREV_meta}"

# nothing to do if bootstrapping
if [ -n "${YOCTO_KERNEL_EXTERNAL_BRANCH}" ]; then
return
fi

+ branch_head=`git show-ref -s --heads ${KBRANCH}`
+ meta_head=`git show-ref -s --heads ${KMETA}`
+ target_branch_head="${SRCREV_machine}"
+ target_meta_head="${SRCREV_meta}"
+
current=`git branch |grep \*|sed 's/^\* //'`
if [ -n "$target_branch_head" ] && [ "$branch_head" != "$target_branch_head" ]; then
if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 00cc666..cc71179 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8

DEPENDS = "git-native guilt-native"

-SRCREV = "8f61abb6344e78677450994e8930cabc86102d78"
+SRCREV = "92b965b02e3ac32badde3ee71a1e7d3a85cedeb8"
PR = r10
PV = "0.1+git${SRCPV}"

--
1.7.0.4


[PATCH 0/3] linux-yocto: consolidated pull request

Bruce Ashfield <bruce.ashfield@...>
 

Richard/Saul,

I've been running with these changes since before ELC, so they've had
some good soak time. The first two changes lay the ground for for some
1.1 functionality and are used by recipes in the meta-kernel-dev layer.
The changes are transparent to existing recipes.

In particular they are related to auto creating meta data for kernel
repository builds. They are enough for basic korg/defconfig builds and
limited other repository building. More changes will complete this work
shortly.

The last patch just updates the SRCREVs to pickup Khem's backported
perf tool / gcc 4.6.0 patch.

There are about 8 more pending patches that deal with some recipe
renames, cleanup and more 1.1 functionality but I wanted to get
this first set of 3 out before rebasing the rest.

Sorry about the big cross post, but these changes span quite a few
different interest groups.

cc: Khem Raj <raj.khem@gmail.com>

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@windriver.com>
---


Bruce Ashfield (3):
linux-yocto: apply meta data to external repos
linux-yocto: safely process unbranched repositories
linux-yocto: update SRCREVs

meta/classes/kernel-yocto.bbclass | 34 +++++++++++++++-----
.../kern-tools/kern-tools-native_git.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_git.bb | 24 +++++++-------
3 files changed, 39 insertions(+), 21 deletions(-)


Re: RFC: Package exclusion

Paul Eggleton
 

Hi Beth,

On Wednesday 04 May 2011 00:08:59 Elizabeth Flanagan wrote:
Most of the issues surrounding the license field is currently on my plate
for M1.D

License tracking Build a parser to do license tracking more gracefully and
make sure all recipes are correct. (takes ~2 weeks) 1 Accept Beth Beth
M1,
Sprint D

There is currently no specification on the LICENSE field values and how
they should be parsed. I'm going to be starting that in the next week or
so. We should sync up with each other if this work is going to overlap.
Schedule some time for this week?
Yes there's definitely quite an overlap here and we should coordinate efforts.
Will catch you later on IRC to organise some time.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: RFC: Package exclusion

Elizabeth Flanagan <elizabeth.flanagan@...>
 

On 05/03/2011 09:00 AM, Paul Eggleton wrote:
Hi all,

As part of the 1.1 feature list I suggested a review of the
INCOMPATIBLE_LICENSE and COMMERCIAL* package exclusion mechanisms we have
within Poky. Below I've outlined my ideas and would appreciate any
comments/additions/corrections.

==== Aims ====

* Make error messages clear when user/dependencies have asked for something
to be built that can't be due to restrictions

* Ensure that exclusion system is reliable

==== Proposed implementation ====

1) Ensure all documentation of LICENSE field value syntax is clear, concise
and up-to-date (wiki and manual)

2) Go through and audit all recipes LICENSE field values to ensure that they
all conform to the specifications. This includes making sure that | (package
may be used under one of a selection of licences) and& (recipe has mixed
licences that apply to the code base, so conditions of all must be observed)
are used correctly.

3) bitbake/core changes:

* LICENSE field checking must fully parse the field and understand the
difference between | and&, and must not e.g. mark Qt as being GPLv3 only.

* Make the LICENSE validity checking more strict (given recipes have been
audited and rules are clear after above)

* Don't exclude any recipes at parse time - simply record all excluded
recipes and their runtime provides in a blacklist which also includes flags
indicating the reason for blacklisting

* Ensure all excluded licences in INCOMPATIBLE_LICENSE are valid (e.g. catch
GPL3 as apposed to GPLv3) - if not, error out

* Check when calculating dependencies if anything is scheduled to be built
that is on the blacklist - if any are, gather all of them up and then stop and
list them in an error message along with reason and depchain for each one

* Check when constructing the rootfs if anything in the runtime provides
blacklist is going to be included - if so, error out
Most of the issues surrounding the license field is currently on my plate for M1.D

License tracking Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks) 1 Accept Beth Beth M1, Sprint D

There is currently no specification on the LICENSE field values and how they should be parsed. I'm going to be starting that in the next week or so. We should sync up with each other if this work is going to overlap. Schedule some time for this week?

-b


Cheers,
Paul
--
---------------
Elizabeth Flanagan
Yocto Project
Release Engineer


Re: OpenEmbedded eV membership drive

Richard Purdie
 

On Tue, 2011-05-03 at 23:15 +0200, Frans Meulenbroeks wrote:
2011/5/3 Richard Purdie <richard.purdie@linuxfoundation.org>
This was discussed at the last TSC meeting and we reviewed the
TSC
meeting minutes where it was recorded that:

"""
Election wise, we'll elect the seats in the order from the
board
announcement email until we have 5 elected members. We will
rely on the
board to call the first election in May.
"""

which the TSC has reminded the board about last week.

I don't think it is up to the TSC to decide on the re-election
timeframe. As it stands the TSC got a 2 month mandate. See the quote
above (from Philip's email from feb 10).
That is all I wanted to indicate.
The TSC was asked by the board to figure out the details of the election
which we did in the first meeting as requested and provided our feedback
back to the board. The board naturally has the ultimate say in this.

Cheers,

Richard


Re: OpenEmbedded eV membership drive

Frans Meulenbroeks <fransmeulenbroeks@...>
 



2011/5/3 Richard Purdie <richard.purdie@...>
On Tue, 2011-05-03 at 22:05 +0200, Frans Meulenbroeks wrote:
> 2011/5/3 Philip Balister <philip@...>
>
> [...]
>
>         People ask me why they should join the eV. Besides being a
>         good way to show your support for the OpenEmbedded project,
>         the Technical Steering Committee is elected by the eV members.
>
> Sorry but the current TSC is NOT elected by the eV members.

The current situation was making the best of a bad set of circumstances,
the plan is to hold elections and nothing has changed in that regard.

> Actually the board even fails to meet its own "rules" stipulated when
> they installed this interim TSC.
>
> From Philip's email from feb 10:
> This interim TSC will operate for 2 months when we shall start elections
> at two month intervals for the 5 positions on the TSC. The new elected
> TSC members will operate under the charter detailed on the wiki here
>
> http://wiki.openembedded.org/index.php/TSCCharter.
> We're now almost 3 months later and no election has been held!

This was discussed at the last TSC meeting and we reviewed the TSC
meeting minutes where it was recorded that:

"""
Election wise, we'll elect the seats in the order from the board
announcement email until we have 5 elected members. We will rely on the
board to call the first election in May.
"""

which the TSC has reminded the board about last week.

Cheers,

Richard

I don't think it is up to the TSC to decide on the re-election timeframe. As it stands the TSC got a 2 month mandate. See the quote above (from Philip's email from feb 10).
That is all I wanted to indicate.

Frans


Re: OpenEmbedded eV membership drive

Richard Purdie
 

On Tue, 2011-05-03 at 22:05 +0200, Frans Meulenbroeks wrote:
2011/5/3 Philip Balister <philip@balister.org>

[...]

People ask me why they should join the eV. Besides being a
good way to show your support for the OpenEmbedded project,
the Technical Steering Committee is elected by the eV members.

Sorry but the current TSC is NOT elected by the eV members.
The current situation was making the best of a bad set of circumstances,
the plan is to hold elections and nothing has changed in that regard.

Actually the board even fails to meet its own "rules" stipulated when
they installed this interim TSC.

From Philip's email from feb 10:
This interim TSC will operate for 2 months when we shall start elections
at two month intervals for the 5 positions on the TSC. The new elected
TSC members will operate under the charter detailed on the wiki here

http://wiki.openembedded.org/index.php/TSCCharter.
We're now almost 3 months later and no election has been held!
This was discussed at the last TSC meeting and we reviewed the TSC
meeting minutes where it was recorded that:

"""
Election wise, we'll elect the seats in the order from the board
announcement email until we have 5 elected members. We will rely on the
board to call the first election in May.
"""

which the TSC has reminded the board about last week.

Cheers,

Richard


Re: [OE-core] OpenEmbedded eV membership drive

Mark Hatle <mark.hatle@...>
 

Speaking as a member of the TSC, our understanding is an election would be
called for the first position at the beginning of May. (More or less this week.)

The TSC members up for election was decided by the TSC to be in the order of the
original board announcement, with the final two members going up for election at
the same time.

--Mark

On 5/3/11 3:05 PM, Frans Meulenbroeks wrote:
2011/5/3 Philip Balister <philip@balister.org>

[...]


People ask me why they should join the eV. Besides being a good way to show
your support for the OpenEmbedded project, the Technical Steering Committee
is elected by the eV members.

Sorry but the current TSC is NOT elected by the eV members.
Actually the board even fails to meet its own "rules" stipulated when they
installed this interim TSC.

From Philip's email from feb 10:

This interim TSC will operate for 2 months when we shall start elections
at two month intervals for the 5 positions on the TSC. The new elected
TSC members will operate under the charter detailed on the wiki here
http://wiki.openembedded.org/index.php/TSCCharter.

We're now almost 3 months later and no election has been held!

Frans
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core