Date   

Re: Yocto weekly bug trend charts -- WW35

David Stewart
 

Very cool to see the trend continue in a good direction - thanks everyone for your hard work - it really counts!!

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Xu, Jiajun
Sent: Sunday, August 28, 2011 6:24 PM
To: yocto@yoctoproject.org
Subject: [yocto] Yocto weekly bug trend charts -- WW35

Hi all,
The overall open bug trend continue to decrease last week. The new-
submit vs. fixed bug is 35 vs. 40. Open bug number decreased to 136. WDD
number decreased to 675, which is close to the number of 1.0 release. Bug
status of WW35 could be found on
https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend.

Best Regards,
Jiajun
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Best way to override EXTRA_OECONF

Gary Thomas
 

On 2011-08-29 15:28, Chris Tapp wrote:
I'm using libGL provided by mesa-xlib, which includes mesa-common.

I also want to use libglu, but mesa-common says:

EXTRA_OECONF = "--disable-glu \

Is there a way I can override this without having to alter mesa-common.inc.

Would a mesa-xlib.bbappend file with

EXTRA_OECONF += "--enable-glu \

do it?
Try something like this in your .bbappend file:
EXTRA_OECONF := "${@oe_filter_out('--disable-glu', '${EXTRA_OECONF}', d)}"
EXTRA_OECONF += "--enable-glu "

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Best way to override EXTRA_OECONF

Chris Tapp
 

I'm using libGL provided by mesa-xlib, which includes mesa-common.

I also want to use libglu, but mesa-common says:

EXTRA_OECONF = "--disable-glu \

Is there a way I can override this without having to alter mesa- common.inc.

Would a mesa-xlib.bbappend file with

EXTRA_OECONF += "--enable-glu \

do it?

Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: Tested host distros for 1.1

Paul Eggleton
 

On Monday 29 August 2011 17:34:28 Rifenbark, Scott M wrote:
Do you know where I can get the full list?
No, that's why I started the discussion :)

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: Tested host distros for 1.1

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Paul,

Do you know where I can get the full list?

ScottR

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul Eggleton
Sent: Monday, August 29, 2011 9:33 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Tested host distros for 1.1

On Monday 29 August 2011 17:02:07 Rifenbark, Scott M wrote:
So the official list of distros we test against includes?:

Ubuntu 11.04
Fedora release 14 (Laughlin)
I think it should include these, but that's not the full list.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Tested host distros for 1.1

Paul Eggleton
 

On Monday 29 August 2011 17:02:07 Rifenbark, Scott M wrote:
So the official list of distros we test against includes?:

Ubuntu 11.04
Fedora release 14 (Laughlin)
I think it should include these, but that's not the full list.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: Tested host distros for 1.1

McClintock Matthew-B29882 <B29882@...>
 

On Mon, Aug 29, 2011 at 11:27 AM, Rifenbark, Scott M
<scott.m.rifenbark@intel.com> wrote:
Matthew,

Right now what I mention in the Poky manual you reference is somewhat vague.  Early on the team had some discussion as to whether to try and compile some sort of complete list of the distros that are supported.  It turned out the actual distros tested were few.  So I guess my comment here to the group was trying to verify (again) whether we had a real list of distros with version numbers we could say have been tested with Yocto.  Maybe it is worth discussing again how exhaustive and detailed we want the supported distros list to be.
I understand, I was just hoping a few more in that list would keep
being supported such as SUSE, etc. I know we build on Fedora 13 and
CentOS 5.5 (with a few fixes not upstream yet)

-M


Re: Tested host distros for 1.1

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Matthew,

Right now what I mention in the Poky manual you reference is somewhat vague. Early on the team had some discussion as to whether to try and compile some sort of complete list of the distros that are supported. It turned out the actual distros tested were few. So I guess my comment here to the group was trying to verify (again) whether we had a real list of distros with version numbers we could say have been tested with Yocto. Maybe it is worth discussing again how exhaustive and detailed we want the supported distros list to be.

Thanks,
ScottR

-----Original Message-----
From: McClintock Matthew-B29882 [mailto:B29882@freescale.com]
Sent: Monday, August 29, 2011 9:22 AM
To: Rifenbark, Scott M
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Tested host distros for 1.1

On Mon, Aug 29, 2011 at 11:02 AM, Rifenbark, Scott M
<scott.m.rifenbark@intel.com> wrote:
So the official list of distros we test against includes?:

       Ubuntu 11.04
       Fedora release 14 (Laughlin)
The manual mentions a few more:

http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#intro-requirements

-M


Re: Tested host distros for 1.1

McClintock Matthew-B29882 <B29882@...>
 

On Mon, Aug 29, 2011 at 11:02 AM, Rifenbark, Scott M
<scott.m.rifenbark@intel.com> wrote:
So the official list of distros we test against includes?:

       Ubuntu 11.04
       Fedora release 14 (Laughlin)
The manual mentions a few more:

http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#intro-requirements

-M


Re: Tested host distros for 1.1

Rifenbark, Scott M <scott.m.rifenbark@...>
 

So the official list of distros we test against includes?:

Ubuntu 11.04
Fedora release 14 (Laughlin)

ScottR

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul Eggleton
Sent: Tuesday, August 23, 2011 8:43 AM
To: yocto@yoctoproject.org
Subject: [yocto] Tested host distros for 1.1

Hi all,

We now have the mechanism for fixing bug #1096 [1] i.e. showing a warning if
the user is running a build on a distro that has not been tested; however to
make this work what we now need is a list of distributions we want to consider
tested. What distros specifically are we going to list for 1.1?

Cheers,
Paul

[1] http://bugzilla.pokylinux.org/show_bug.cgi?id=1096


--

Paul Eggleton
Intel Open Source Technology Centre
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: ARM summit at Plumbers 2011

Jeff Law <law@...>
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/28/11 22:02, Jon Masters wrote:
On Tue, 2011-08-23 at 17:11 +0100, Steve McIntyre wrote:

UPDATE: we've not had many people confirm interest in this event
yet, which is a shame. If you would like to join us for this
session, please reply and let me know. If we don't get enough
interest by the end of Sunday (28th August), then we'll have to
cancel the meeting.
I'm obviously confirming, but I'll repeat that for the record. My
interests here include helping to lead up Fedora's ARMv7 efforts,
but also wider ARM platform standardization (boot, device
enumeration, multi-arch, ABI, kernel consolidation, and many other
things).

If there's at least representation from a few of the distros (as it
seems is the case at this point) then I think it's worthwhile having
the formal slots. Nothing is lost in so doing. In any case, many
discussions will take place if we have the opportunity to do so.
I've certain got an interest in hashing out ARM relative issues from a
tools standpoint. So count me in.

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOW7VaAAoJEBRtltQi2kC74u8IAIJi+BTmyxbyg8fnYm+lMjq5
K0CKMTpOcDCjZjEOcRx5YrTgOZsEwJKpngvqI82zzbz9vK6Gdw+0HydygaBSZSF7
wBJGv6mmKrP2/ZUts3c68cQDSoNisfeEEZk2MVCrHqm1RZAWW2vynb8zSBr589kV
f7WNEDNTZJwvam7DEZa4/ZAhPUfKxTwREl0H0ZK+miiW47vJtrQiZ6C9KJtFcgLN
Kqo5Jlmtdn2Jmv5s0LXSABtfwRtULqRnTICzZIE8440T4RVDbDI7Sc4jOIy6d31C
YQcKWOjXD9eYzYkOqeJfbLX5bLlOyjfbqfi8lA+jZbTVldjthOGAsmNR5E2h25Q=
=mnMM
-----END PGP SIGNATURE-----


Weekly test report for Yocto1.1 20110824 build

Fan, WenhuaX <wenhuax.fan@...>
 

Hi All,

       This is the weekly test report for Yocto1.1 20110824 build. There were two new bugs found, compiled the sudoku failed. The sato-sdk image for beagleboard built failed. I2C and standby issue still exist on eMenlow. Xorg eats lots of CPU time after standby on Crownbay. I/OAT DMA engine init failed in current build on Jasperforest. The rpm/zypper install/removal consume disk space issue still exists. Install/Remove Software issue exist also. No icons shown on X desktop with sato image still exist. For bug fixing, the images could be installed on Sugarbay and Jasperforest. Libsdl.so issue fixed on Sugarbay.

      For hob, there is 1 new bug reported. There are 4 bugs existing in our testing. Duplicated package name will be shown in brought in by column. Packages not reload correctly when changing Machine type. User could not build other package/image after one build finished. Package number is not consistent with user customized bb file.

NoteFor different images, they are built against different commit/branch on autobuilder. You can refer to “Commit Information” section for detailed information. The test report is archived @https://wiki.yoctoproject.org/wiki/Yocto_1.1_Weekly_Test_Report

 

 

Test Summary:

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

 

Test Result Summary

Component

Target

Status

Comments

BSP

SugarBay

GOOD

Everything runs well

CrownBay-emgd

GOOD

Xorg eats lots of CPU time after standby

JasperForest

GOOD

I/OAT DMA engine init failed;

Blacksand

GOOD

Everything runs well

eMenlow

GOOD

I2C_transfer error; Standby failed;

Beagleboard

BLOCK

Sato-sdk image build failed.

Routerstationpro

GOOD

Everything runs well

Mpc8315e-rdb

GOOD

Everything runs well

QEMU

qemux86

GOOD

Rpm/zypper install/removal consume disk space;"Install/Remove" icon can't work.

qemux86-64

GOOD

Rpm/zypper install/removal consume disk space;"Install/Remove" icon can't work.

qemuarm

BUGGY

Everything runs well

qemuppc

GOOD

Unfs does not work with qemuppc

qemumips

GOOD

Everything runs well

ADT

 

BUGGY

Unfs does not work with qemuppc.

HOB

 

BUGGY

duplicated brought in package list. Packages not reload correctly when changing Machine type. User could not build other package/image after one build finished. Package number is not consistent with user customized bb file.

 

Critical bugs, more than 50% test cases are blocked

 

Only Normal, Minor or Enhancement bugs, or less than 10% test cases failed

 

Normal, Major and Critical bugs, and more than 10% test cases failed

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Sugarbay Sato-SDK

62

0

62

0

0

Jasperforest Sato-SDK

34

0

33

1 (bug 1188)

0

n450 Sato-SDK

58

0

58

0

0

eMenlow Sato-SDK

58

0

56

2 (bug 310, 503)

0

Crownbay-Sato-SDK

59

0

59

0

0

Beagleboard

40

0

0

0

40 (bug 1381)

Routerstationpro

33

0

33

0

0

Mpc8315e-rdb

36

0

36

0

0

Qemux86-64 Sato

30

0

28

2 (bug 1174, 1234)

0

Qemux86-64 Sato-SDK

35

0

32

3 (bug 1174, 1234, 1236)

0

Qemux86 Sato

30

0

28

2 (bug 1174, 1234)

0

Qemux86 Sato-SDK

35

0

33

2 (bug 1174, 1234)

0

Qemumips Sato

30

0

29

1 (bug 1234)

0

Qemumips Sato-SDK

35

0

34

1 (bug 1234)

0

Qemuppc Sato

22

0

21

  1 (bug 414)

0

Qemuppc Sato-SDK

27

0

26

1 (bug 414)

0

Qemuarm Sato

30

0

29

  1 (bug 1234)

0

Qemuarm Sato-SDK

35

0

34

  1 (bug 1234)

0

ADT

6

0

5

1 (bug 414)

0

HOB

20

0

17

3 (bug 1281 1285 1420)

0

Total

715

0

653

22

40

 

 

Commit Information

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

 

For Emenlow:

 

Tree/Branch: Poky/Master

Poky Commit id: 2c8120d4895c1e2539df2226bae5b5f3b914cb07

Meta Branch: Master

Meta commit id: fb15cc4e1c4be75c81acaf6a1dd33675a9142975

 

For Crownbay/Blacksand/:

 

Tree/Branch: Poky/Master

Poky Commit id: 9ca6806de9d9df9d901774c1b23a14f28f10a844

Meta Branch: Master

Meta commit id: fb15cc4e1c4be75c81acaf6a1dd33675a9142975

 

For Sugarbay/Jasperforest:

 

Tree/Branch: Poky/Master

Poky Commit id: 6c2b7beac3cd23ed44bd3e195c6360a0932876bf

Meta Branch: Master

Meta commit id: fb15cc4e1c4be75c81acaf6a1dd33675a9142975

 

For Qemux86/Toolchain /Qemuarm/Qemumips/Qemuppc/beagleboard/mpc8315e-rdb/routerstationpro:

 

Tree/Branch: Poky/Master

Poky Commit id: f8cddd74574756174a82c856cecdeb6f83b9dea5

 

 

Issue Summary

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

 

Component

Bug Number

Target Milestone

System & Core OS

System Usage

Bug 503 - [emenlow] system cannot enter S3 standby mode

1.1

Bug 1082 - [x86_64] No icons shown on X desktop with sato image

1.0 M2

Bug 1174: [zypper/rpm] package install/removal costs lots of disk space

1.1 M3

Bug 1234: No response when I click the 'Install/Remove Software' icon

1.1 M4

Other

Bug 310 - [eMenlow] i2c_transfer error on e-Menlow

1.1

Bug 1188 - [japerforest] I/OAT DMA engine init failed

1.1

Bug 1258 -[crownbay] Xorg eats lots of CPU time after standby

1.1 M4

Bug 1381: lttng-ust do_compile failed on autobuilder for beagleboard with 20110817 build

1.1

New! Bug 1421 -  [eMenlow] Failed to compile the Sudoku

---

HOB

Bug 1281 - packages not reload correctly when changing Machine type

1.1

Bug 1285 - User could not build other package/image after one build finished

1.1

Bug 1359 - [HOB] package number is not consistent with user customized bb file

1.1

New! Bug 1420 - [HOB] duplicated brought in package list

---

ADT

Bug 414: [PPC] kernel panic when booting poky-image-sdk-qemuppc through UNFS

1.1

 

 

Verified Fixed Bug:

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

 

1.       Bug 817 - "/lib/modules/2.6.37.2-yocto-standard+/kernel/drivers" dir not found in mpc8315e-rdb sato-sdk images results in USB stick do not work (nightly build 20110305-4)

2.       Bug 883 - [Sugarbay] GFX 3D game test fail to run with sugarbay BSP image due to libsdl.so

3.       Bug 1387 - [Sugarbay/Jasperforest] Failed to install image due to couldn’t find device

 


Re: ARM summit at Plumbers 2011

Jon Masters <jcm@...>
 

On Tue, 2011-08-23 at 17:11 +0100, Steve McIntyre wrote:

UPDATE: we've not had many people confirm interest in this event yet,
which is a shame. If you would like to join us for this session,
please reply and let me know. If we don't get enough interest by the
end of Sunday (28th August), then we'll have to cancel the meeting.
I'm obviously confirming, but I'll repeat that for the record. My
interests here include helping to lead up Fedora's ARMv7 efforts, but
also wider ARM platform standardization (boot, device enumeration,
multi-arch, ABI, kernel consolidation, and many other things).

If there's at least representation from a few of the distros (as it
seems is the case at this point) then I think it's worthwhile having the
formal slots. Nothing is lost in so doing. In any case, many discussions
will take place if we have the opportunity to do so.

Jon.


Yocto weekly bug trend charts -- WW35

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

Hi all,
The overall open bug trend continue to decrease last week. The new-submit vs. fixed bug is 35 vs. 40. Open bug number decreased to 136. WDD number decreased to 675, which is close to the number of 1.0 release. Bug status of WW35 could be found on https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend.

Best Regards,
Jiajun


Re: [PATCH 1/1] emenlow xpsb-glx: add package libglu to fix lsb image build warning

Tom Zanussi <tom.zanussi@...>
 

On Sun, 2011-08-28 at 04:10 -0700, Yu Ke wrote:
lsb image requires libglu, so split the xpsb-glx to provide the libglu
package. mesa-dri also do in the same way. so this patch make xpsb-glx
in sync with mesa-dri.

Fix [YOCTO #1395]
Thanks, Yu Ke. Pulled into meta-intel/master.

Acked-by: Tom Zanussi <tom.zanussi@intel.com>

Signed-off-by: Yu Ke <ke.yu@intel.com>
---
.../recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb b/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb
index 0d675c6..8fb25d6 100644
--- a/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb
+++ b/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb
@@ -4,7 +4,7 @@ DESCRIPTION = "X11 drivers for Poulsbo (psb) 3D acceleration"
# not Intel proprietary, but it has no obvious license attached to it.
LICENSE = "Intel-binary-only"
LIC_FILES_CHKSUM = "file://${WORKDIR}/${PN}-${PV}/COPYING;md5=02c597a2f082b4581596065bb5a521a8"
-PR = "r7"
+PR = "r8"

inherit autotools

@@ -41,6 +41,11 @@ DEPENDS += "libxfixes libxdamage libdrm-poulsbo libxxf86vm dri2proto libxmu libx
FILES_${PN} = "${libdir}/* ${libdir}/xorg/modules/dri/* \
${libdir}/xorg/modules/drivers/*"

+PACKAGES =+ "libglu libglu-dev"
+
+FILES_libglu = "${libdir}/libGLU.so.*"
+FILES_libglu-dev = "${libdir}/libGLU.* ${includedir}/GL/glu*.h"
+
# Multiple virtual/gl providers being built breaks staging
EXCLUDE_FROM_WORLD = "1"


[PATCH 1/1] emenlow xpsb-glx: add package libglu to fix lsb image build warning

Yu Ke <ke.yu@...>
 

lsb image requires libglu, so split the xpsb-glx to provide the libglu
package. mesa-dri also do in the same way. so this patch make xpsb-glx
in sync with mesa-dri.

Fix [YOCTO #1395]

Signed-off-by: Yu Ke <ke.yu@intel.com>
---
.../recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb b/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb
index 0d675c6..8fb25d6 100644
--- a/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb
+++ b/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb
@@ -4,7 +4,7 @@ DESCRIPTION = "X11 drivers for Poulsbo (psb) 3D acceleration"
# not Intel proprietary, but it has no obvious license attached to it.
LICENSE = "Intel-binary-only"
LIC_FILES_CHKSUM = "file://${WORKDIR}/${PN}-${PV}/COPYING;md5=02c597a2f082b4581596065bb5a521a8"
-PR = "r7"
+PR = "r8"

inherit autotools

@@ -41,6 +41,11 @@ DEPENDS += "libxfixes libxdamage libdrm-poulsbo libxxf86vm dri2proto libxmu libx
FILES_${PN} = "${libdir}/* ${libdir}/xorg/modules/dri/* \
${libdir}/xorg/modules/drivers/*"

+PACKAGES =+ "libglu libglu-dev"
+
+FILES_libglu = "${libdir}/libGLU.so.*"
+FILES_libglu-dev = "${libdir}/libGLU.* ${includedir}/GL/glu*.h"
+
# Multiple virtual/gl providers being built breaks staging
EXCLUDE_FROM_WORLD = "1"

--
1.7.0.4


[PATCH 0/1] fix for emenlow lsb bug 1395

Yu Ke <ke.yu@...>
 

this patch fix the bug 1395 http://bugzilla.yoctoproject.org/show_bug.cgi?id=1395
the root cause is that: lsb image rdepends on libglu, and xpsb does not provide it.
so mesa-dri will be built for libglu. then there will be warning message because
both mesa-dri and xpsb will provide virtual/libgl, and cause conflict.

to fix it, xpsb should also provide split package libglu.

Signed-off-by: Yu Ke <ke.yu@intel.com>

The following changes since commit dc00302411d9384deb0c61b34240aa43f108a736:
Tom Zanussi (1):
meta-intel: update meta-emenlow kernel SRCREVs

are available in the git repository at:

git://git.pokylinux.org/poky-contrib kyu3/bug1395-libglu
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/bug1395-libglu

Yu Ke (1):
emenlow xpsb-glx: add package libglu to fix lsb image build warning

.../recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)


[PATCH] meta-crownbay: prefer mesa version 7.8 for bernard

Tom Zanussi <tom.zanussi@...>
 

bernard uses emgd 1.5, which requires mesa 7.8. It was inadvertently
picking up 7.10 instead - we need to explicitly specify 7.8.

Fixes [YOCTO #971]

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
---
meta-crownbay/conf/machine/crownbay.conf | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/meta-crownbay/conf/machine/crownbay.conf b/meta-crownbay/conf/machine/crownbay.conf
index 4591842..b1f95af 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -30,6 +30,7 @@ XSERVER ?= "xserver-xf86-emgd \

PREFERRED_VERSION_xserver-xf86-emgd ?= "1.7.99.2"
PREFERRED_VERSION_xserver-xf86-emgd-bin ?= "1.7.99.2"
+PREFERRED_VERSION_mesa-dri ?= "7.8.2"

SERIAL_CONSOLE = "115200 ttyS0"

--
1.7.0.4


Agenda: Yocto Technical Team Meeting - (Tuesday, August 30, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

Liu, Song <song.liu@...>
 

We have a simple agenda next week. Please let me know if there is anything else we should cover.

Song

Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.1 M4 status review and issues - 20 min (team)
- Status summary (Song)
- Build status (Beth)
* Opens

-------------------------------------------------------
Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 28, 2011 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
49611427
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a chairperson:
1.972.995.7777x67184230#
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x49611427#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free)
Airtel subscribers use 0008 009 861 212 (Toll Free)
From TI Campus use 89957777
Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 28, 2011
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 22, 2012, 10:40 AM CDT


Re: [lsb-discuss] [fedora-arm] ARM summit at Plumbers 2011

keld@...
 

I would relly like the dscussion to go on widely as it is now.
Otherwise I would probably not follow this interesting discussion.

best regards
keld

On Fri, Aug 26, 2011 at 10:02:09PM +0100, Luke Kenneth Casson Leighton wrote:
russell, good to hear from you.

can i recommend, that although this is a really wide set of
cross-posting on a discussion that underpins pretty much everything
(except gnu/hurd and minix) because it's linux kernel, that, just as
steve kindly advised, we keep this to e.g.
cross-distro@lists.linaro.org? i'll be doing that from now on [after
this] perhaps including arm-netbooks as well, but will be taking off
all the distros.

so - folks, let's be clear: please move this discussion to
cross-distro@lists.linaro.org, and, if it's worthwhile discussing in
person, please do contact steve, so he can keep the slot open at the
Plumbers 2011 summit.

On Fri, Aug 26, 2011 at 5:35 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote:
As such refactoring consolidated larger and larger chunks of kernel
code, new designs would gravitate towards those consolidated
implementations because they would be the dominant references.
Don't bet on it. ??That's not how it works (unfortunately.)

Just look at the many serial port inventions dreamt up by SoC designers -
everyone is different from each other. ??Now consider: why didn't they use
a well established standard 16550A or later design?
*sigh* because they wanted to save power. or pins. or... just be
bloody-minded.

This "need to be different" is so heavily embedded in the mindset of the
hardware people that I doubt "providing consolidated implementations"
will make the blind bit of difference.
i think... russell... after they are told, repeatedly, "no, you can't
have that pile of junk in the mainline linux kernel, Get With The
Programme", you'd think that, cumulatively if they end up having to
maintain a 6mb patch full of such shit, they _might_ get with the
programme?

and if they don't, well.... who honestly cares? if they don't, it's
not *your* problem, is it? _they_ pay their employees to continue to
main a pile of junk, instead of spongeing off of _your_ time (and
linus's, and everyone else's in the Free Software Community).


??I doubt that hardware people
coming up with these abominations even care one bit about what's in
the kernel.
then don't f******g make it _your_ problem, or anyone else's, upstream!! :)

this is the core of the proposal that i have been advocating: if it's
"selfish", i.e. as bill and many many others clearly agree with "if
the bang-per-buck ratio is on the low side" then keep it *out* the
mainline linux kernel...

... and that really is the end of the matter.

the sensible people that i've been talking to about this are truly
puzzled as to why the principles of "cooperation and collaboration"
behind free software are just being... completely ignored, in
something as vital as The Linux Kernel, and they feel that it's really
blindingly obvious that the "bang-per-buck" ratio of patches to
mainline linux kernel need to go up.

so the core of the proposal that is the proposed
"selfish-vs-cooperation patch policy" is quite simple: if the patch
has _some_ evidence of collaboration, cooperation, refactoring,
sharing - *anything* that increases the bang-per-buck ratio with
respect to the core fundamental principles of Free Software - it goes
to the next phase [which is technical evaluation etc. etc.].
otherwise, it's absolutely out, regardless of its technical
correctness, and that's the end of it.

the linux kernel mainline source tree should *not* be a
dumping-ground for a bunch of selfish self-centred pathological
profit-mongering corporations whose employees end up apologising in
sheer embarrassment as they submit time-pressured absolutely shit
non-cooperative and impossible-to-maintain code.

you're not the only one, russell, who is pissed off at having to tidy
up SoC vendors' patches. there's another ARM-Linux guy, forget his
name, specialises in samsung: two years ago he said that he was
getting fed up with receiving yet another pile of rushed junk... and
that's *just* him, specialising in samsung ARM SoCs!

we're just stunned that you, the recipient of _multiple_ SoC vendors
piles of shite, have tolerated this for so long!

anyway - i've endeavoured to put together some examples, in case
that's not clear: i admit it's quite hard to create clear examples,
and would greatly appreciate help doing so. i've had some very much
appreciated help from one of the openwrt developers (thanks!)
clarifying by creating another example that's similar to one which
wasn't clear.

http://lkcl.net/linux/linux-selfish.vs.cooperation.html

this should be _fun_, guys. it shouldn't be a chore. if you're not
enjoying it, and not being paid, tell the people who are clearly
taking the piss to f*** off!

but - i also would like to underscore this with another idea: "lead
by example" (which is why i've kept the large cross-distro list) we -
the free software community - are seeing tons of nice lovely android
tablets, tons of nice lovely expensive bits of big iron and/or x86
laptops, and only in very small areas (OpenRD Ultimate, GuruPlug,
Pandaboard, IMX53QSB, Origen) are our needs for actual hardware which
_we_ want (and i'm *not* being presumptious here - i'm inviting people
to *say* what they want) just aren't being met.

who wants a bloody 800x600 VIA VunnnderMedia ARM9 350mhz tablet, to
do linux kernel and gnu/linux distribution development on, _anyway_???
and who the hell wants only 512mb of RAM (iMX51). and who in their
right fucking mind dreamed up that 1024x600 LCD panel size?

so here's what i propose:

we, The Free Software Community, want Our Figureheads (linus, bruce,
alan, russell) to call us to arms (so to speak), to band together a la
KickStarter http://kickstarter.org (or other), so that we can create
the hardware platform(s) that *we* want, and, in the process, can take
the opportunity to sort out the Linux Kernel mainline tree in the
process (learning by doing, doing by leading, leading by example etc.
etc.)

apart from anything - and this goes to you, linus and russell - i
think that you would be much happier taking a break from doing git
patch conflict management, _actually_ getting down and dirty with some
real device driver writing, and i think you'd be much happier doing
that knowing that the device you were writing those kernel drivers for
was something that actual real free software developers really really
wanted.

now, as i said above: i don't _dare_ to presume that i know what
actual real free software developers want, in terms of hardware, but
there's a small sampling on the debian-arm mailing list... let me drop
you roughly in the middle of it, here:
http://lists.debian.org/debian-arm/2011/08/msg00045.html mostly that
was focussed around those little engineering boards (panda, IMX53QSB,
origen etc.) but my aim here is to get people to think:

what hardware, which is fully free-software-compliant, that you would
buy and recommend to others, that could also be attractive in
mass-volume, do _you_ want to see, that would be useful to _you_?

i'm getting fed up of seeing stuff come out of factories that's
completely useless. or gpl-violating. and/or requires
reverse-engineering.
http://lkcl.net/linux/ideal-vs-reality.of.product.development.html for
some background.

as a free software developer, what hardware do YOU want?

answers on this one to arm-netbooks@lists.phcomp.co.uk (subscription
required, please remember)

and, lastly - linus, russell, alan, bruce: there are people out there
who would really appreciate if you could take up this call. not just
me. we'd like to see you using your skills, and actually be happy and
enjoy doing nitty-gritty linux kernel development, to the benefit of
the free software community, instead of turning into patch
junkies^H^H^H^H^H^Hmonkeys^H^H^H^H^H^H^Hmanagers.

l.
_______________________________________________
lsb-discuss mailing list
lsb-discuss@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss