Date   

Thanks, and buckle up!

David Stewart
 

All –

 

First of all, I want to thank you guys so much for all of the hard work you put in to bring us to this point, the first public launch of the Yocto Project. There is something really powerful when a team of talented people gathers together to do something special and then pulls it off. I know when we first put our eyes on October 17, 2010 and decided to launch our baby then, there were a few of us who quaked in our boots a bit at the thought of pulling off something like this.

 

But we did it! And it’s awesome to behold. It’s not perfect, but we have a lot to be proud about.

 

In my mind’s eye, I can think forward to a time when your code will have an impact on many people’s lives – whether it’s saving lives with medical devices, operating airplanes or cars safely, generating and routing energy efficiently or routing packets in your favorite website’s data center. Think about how many lives you can touch! Pretty amazing stuff.

 

So thank you, from my heart. I feel privileged to have worked with you.

 

Secondly, I know that tomorrow when the site goes live and announcements go out, I hope people will like our baby, and will tell us so. But you know, there are some people who could be quite critical, and criticize everything from our use of Python to package selection to the fonts on our web sites.  If you have not been through one of these launches before, this is simply a normal part of life in an open source project. When you get your stuff out there for people to see and interact with, you open yourself up to criticism too.

 

So don’t take anything as a personal insult. I try to look at all of it as feedback from a valuable person, and in my heart I do thank them for it.

 

Dave


Sanity test report with milestone build 20101024

xianchao zhang <xianchao.zhang@...>
 

Hi jiajun,

This is the Sanity Test Report for M4 build 20101024. Changhui and I  are responsible for qemumips/arm/ppc testing.

For zypper test cases with qemuarm, since create repo fails in my host, the related cases were not tested.

Test Summary

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

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Completed Rate [%]

Pass rate of total [%]

Qemumips Sato

19

0

16

3

0

100

84.21

Qemumips SDK

26

2

21

3

0

92.31

80.77

Qemuppc Sato

17

5

11

1

5

70.59

64.71

Qemuppc SDK

24

7

16

1

5

70.83

66.67

Qemuarm Sato

19

3

16

0

3

84.21

84.21

Qemuarm SDK

26

5

21

0

3

80.77

80.77

Total

131

22

101

8

16

83.21

77.10


Images

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

http://autobuilder.pokylinux.org/milestone/20101024/

Best Regards, xianchao


Re: Did not find big problems for today's Rc4 (x86/arm) toolchain sdk related images

Lu, Lianhao <lianhao.lu@...>
 

I did the SDK part test of RC4a images on qemuppc, qemumips, and BlackSand. No new bugs found compared to the test of RC3.

 

Best Regards,

-Lianhao

 

From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Tian, Kevin
Sent: Tuesday, October 26, 2010 8:39 AM
To: yocto@...
Subject: [yocto] Did not find big problems for today's Rc4 (x86/arm) toolchain sdk related images

 

FYI. SDK/toolchain part behaves well from RC4.

 

Thanks

Kevin

 

From: Wu, Tong
Sent: Monday, October 25, 2010 8:39 PM
To: Ke, Liping; Tian, Kevin; Yu, Ke; Lu, Lianhao
Subject: On behalf of Liping {Did not find big problems for today's Rc4 (x86/arm) toolchain sdk related images]

 

Hi, all

I did not bring my laptop, and can’t connect webmail, so use this mail box to report the result.

 

X86 sdk image, sdk toolchain, ide-support has been built successfully from clean-up folder at last.

 

X86/arm qemu run successfully.

 

Crosstool chain could compile the c/c++ project successfully in the host.

 

Qemu arm/x86 could compile c/c++ project successfully.

 

Thanks& Regards,

criping


Did not find big problems for today's Rc4 (x86/arm) toolchain sdk related images

Tian, Kevin <kevin.tian@...>
 

FYI. SDK/toolchain part behaves well from RC4.

 

Thanks

Kevin

 

From: Wu, Tong
Sent: Monday, October 25, 2010 8:39 PM
To: Ke, Liping; Tian, Kevin; Yu, Ke; Lu, Lianhao
Subject: On behalf of Liping {Did not find big problems for today's Rc4 (x86/arm) toolchain sdk related images]

 

Hi, all

I did not bring my laptop, and can’t connect webmail, so use this mail box to report the result.

 

X86 sdk image, sdk toolchain, ide-support has been built successfully from clean-up folder at last.

 

X86/arm qemu run successfully.

 

Crosstool chain could compile the c/c++ project successfully in the host.

 

Qemu arm/x86 could compile c/c++ project successfully.

 

Thanks& Regards,

criping


Test Report for Yocto M4 20101024 Build

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

Hi all,

       This is the Partial Test Report for M4 build 20101024(RC4a). Thanks for Dexuan’s help on testing. We finished most testing for IA targets. There is no regression issue found. 2 new normal issues are found. For non-IA targets, Changhui is still downloading images and will give full testing tomorrow. Then I gave a quick try for sato/sdk qemuarm/ppc/mips with RC4a builds. There is no new issue found on my side till now, no issue with booting/networking/basic system usage. So from QA’s view, RC4a has the same quality with RC3(with no regression and critical bugs).

 

Test Summary

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

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Completed Rate [%]

Pass rate of total [%]

Netbook SDK

76

19

54

3 (bug 491, bug 502)

0

75

71.05

eMenlow SDK

69

32

34

3 (bug 503, bug 491, bug 160, bug 310)

2 (bug 503)

53.62

49.28

Qemux86-64 Sato

19

0

19

0

0

100

100

Qemux86-64 SDK

26

2

24

0

0

92.31

92.31

Qemux86 Sato

19

0

19

0

0

100

100

Qemux86 SDK

26

2

24

0

0

92.31

92.31

* To check detail test result, you can login testlink with username/password(guest/guest) first. Then click hyperlinks in above table.

** For Netbook/E-menlow, testing is focused on sdk image.

*** The failed/blocked case number is listed with failed cases’ bug number.

 

Images

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

http://yoctobuild01.jf.intel.com/milestone/20101024/

http://autobuilder.pokylinux.org/milestone/20101024/

 

Issue Summary

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

New Bugs:

1.       Xorg and matchbox-window will SegFault when there are too many windows

http://bugzilla.pokylinux.org/show_bug.cgi?id=509

2.       "rpm -e libnss-mdns" gets error

http://bugzilla.pokylinux.org/show_bug.cgi?id=510

 

Best Regards,

Jiajun


Poky weekly bug trend charts -- WW43

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

Hi all,
This is the Poky weekly bug trend charts for last week (WW43). The open bug number increased to 128. 22 bugs are marked as fixed in last week.
The 1st chart indicates the total open bug number. The 2nd chart indicates the new bug submission and bug fixing count every week.

Best Regards,
Jiajun


Re: RC3 vs RC4a

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

From: Stewart, David C
Sent: Saturday, October 23, 2010 6:48 AM

We have an RC3 which we feel confident in based on our no-nogo launch
decision.

However, there are a handful of issues which are not critical but would
be desirable to address them - for example, having to do with errors
being "fatal" which are not, etc.

So I have asked Saul to create an RC4a with these patched in. Would
like Sanity and BAT tests run on RC4a to see if we should ship it, or
with stick with RC3.

RP - will complete the patch tonight.
Saul - will complete the RC4a build by 5PM Sunday (Pacific) Kevin and
Jiajun and whole team - test this build as much as you have time for.
OK, we'll try latest RC4a and report any new issues if seen.
QA will try as more as possible and send out result today.

Thanks
Kevin


Late Monday, we will decide whether to go with the RC3 build or RC4a build.

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


Re: RC3 vs RC4a

Tian, Kevin <kevin.tian@...>
 

From: Stewart, David C
Sent: Saturday, October 23, 2010 6:48 AM

We have an RC3 which we feel confident in based on our no-nogo launch decision.

However, there are a handful of issues which are not critical but would be desirable to
address them - for example, having to do with errors being "fatal" which are not, etc.

So I have asked Saul to create an RC4a with these patched in. Would like Sanity and BAT
tests run on RC4a to see if we should ship it, or with stick with RC3.

RP - will complete the patch tonight.
Saul - will complete the RC4a build by 5PM Sunday (Pacific)
Kevin and Jiajun and whole team - test this build as much as you have time for.
OK, we'll try latest RC4a and report any new issues if seen.

Thanks
Kevin


Late Monday, we will decide whether to go with the RC3 build or RC4a build.

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


Re: RC3 vs RC4a

Saul G. Wold <sgw@...>
 

On 10/22/2010 03:48 PM, Stewart, David C wrote:
We have an RC3 which we feel confident in based on our no-nogo launch decision.

However, there are a handful of issues which are not critical but would be desirable to address them - for example, having to do with errors being "fatal" which are not, etc.

So I have asked Saul to create an RC4a with these patched in. Would like Sanity and BAT tests run on RC4a to see if we should ship it, or with stick with RC3.

RP - will complete the patch tonight.
Saul - will complete the RC4a build by 5PM Sunday (Pacific)
The build has been running overnight and should be complete, the images are in the standard location on the internal and external autobuilder dated 20101024.

http://autobuilder.pokylinux.org/milestone/20101024/


Kevin and Jiajun and whole team - test this build as much as you have time for.
Please pass this request to the Windriver team also as I am not sure if they are on the list


Late Monday, we will decide whether to go with the RC3 build or RC4a build.
Once we (Jessica and I) get through Heathrow and I get a phone card (I hope), I will call Richard. If it's approved, Scott G. can move the bits to the yoctoproject.org machine.

Sau!



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


Re: Fetcher error reporting

Darren Hart <dvhart@...>
 

On 10/22/2010 04:44 PM, Darren Hart wrote:
On 10/22/2010 04:38 PM, Richard Purdie wrote:
On Fri, 2010-10-22 at 11:22 -0700, Darren Hart wrote:
Here is an example of the do_fetch/do_unpack failure that I believe is
representative of what Dirk saw and what I have been seeing
periodically.

I saw the following while building libproxy in poky-image-sdk-live on a
Fedora 13 box behind the firewall. I saw identical failures with opkg on
a different machine - also behind the firewall. Both SRC_URIs point to
googlecode.

log.do_fetch:
-------------
NOTE: fetch http://libproxy.googlecode.com/files/libproxy-0.4.3.tar.gz
NOTE: libproxy-0.4.3:
http://libproxy.googlecode.com/files/libproxy-0.4.3.tar.gz has no entry
in conf/checksums.ini, not checking URI

log.do_unpack:
--------------
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Exiting with failure status due to previous errors
NOTE: Unpacking
/vol/1/dvhart/poky.git/build/downloads/libproxy-0.4.3.tar.gz to
/vol/1/dvhart/poky.git/build/tmp/work/i586-poky-linux/libproxy-0.4.3-r2/
ERROR: Task failed:

With opkg, I tried the following which resulted in the same error.

$ bitbake -c clean;
$ rm downloads/*opkg*
$ bitbake opkg

In both cases, using wget to manually download the file and place it in
the downloads directory allowed the build to continue.
We've talked about this a lot over jabber. We don't have a reproducer.
What we do see is its always the wget fetcher that hits this (for mirror
urls in the case of git repos) and its failing creating a zero length
file.

If we make the assumption that wget is creating the empty file and
exiting with an error code and look at what bitbake would do, it would
give the behaviour described in these bugs.

Why? If the original fetch fails, it falls back to the mirror code. That
looks, sees a file on the disk and says "nothing to do".

Solution is therefore to make sure if the wget fetcher fails we wipe any
file that may be present.

Is is possible the wget fetcher is creating a zero length file and no
setting an error code but I really hope its not that broken.

So I've pushed this patch as a bandaid for the problem:

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=c5fab99a6f979a4a0ce246c6395b35a3082aec0d

I've applied and am running another build.
One poky-image-sdk-live build completed from a clean slate from inside the firewall. I have another outside the firewall that will take a bit longer, but is well on its way without any errors. Looking good.

--
Darren Hart
Embedded Linux Kernel


Re: Fetcher error reporting

Darren Hart <dvhart@...>
 

On 10/22/2010 04:38 PM, Richard Purdie wrote:
On Fri, 2010-10-22 at 11:22 -0700, Darren Hart wrote:
Here is an example of the do_fetch/do_unpack failure that I believe is
representative of what Dirk saw and what I have been seeing periodically.

I saw the following while building libproxy in poky-image-sdk-live on a
Fedora 13 box behind the firewall. I saw identical failures with opkg on
a different machine - also behind the firewall. Both SRC_URIs point to
googlecode.

log.do_fetch:
-------------
NOTE: fetch http://libproxy.googlecode.com/files/libproxy-0.4.3.tar.gz
NOTE: libproxy-0.4.3:
http://libproxy.googlecode.com/files/libproxy-0.4.3.tar.gz has no entry
in conf/checksums.ini, not checking URI

log.do_unpack:
--------------
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Exiting with failure status due to previous errors
NOTE: Unpacking
/vol/1/dvhart/poky.git/build/downloads/libproxy-0.4.3.tar.gz to
/vol/1/dvhart/poky.git/build/tmp/work/i586-poky-linux/libproxy-0.4.3-r2/
ERROR: Task failed:

With opkg, I tried the following which resulted in the same error.

$ bitbake -c clean;
$ rm downloads/*opkg*
$ bitbake opkg

In both cases, using wget to manually download the file and place it in
the downloads directory allowed the build to continue.
We've talked about this a lot over jabber. We don't have a reproducer.
What we do see is its always the wget fetcher that hits this (for mirror
urls in the case of git repos) and its failing creating a zero length
file.

If we make the assumption that wget is creating the empty file and
exiting with an error code and look at what bitbake would do, it would
give the behaviour described in these bugs.

Why? If the original fetch fails, it falls back to the mirror code. That
looks, sees a file on the disk and says "nothing to do".

Solution is therefore to make sure if the wget fetcher fails we wipe any
file that may be present.

Is is possible the wget fetcher is creating a zero length file and no
setting an error code but I really hope its not that broken.

So I've pushed this patch as a bandaid for the problem:

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=c5fab99a6f979a4a0ce246c6395b35a3082aec0d
I've applied and am running another build. This looks sane to me. If I still run into this, I think the next step is to do a brute force zero-length test, and throw the FetchError and take this modified path from this patch in that case too.

wget will generated a 0 length file when using -O (which we confirmed we do not) and there are old bugs against it for creating 0 length files when a valid host fails to connect (without the -O option) but I wasn't able to reproduce that with a current wget.

Here's to hoping this fixes it.

--
Darren Hart
Embedded Linux Kernel


Re: Fetcher error reporting

Richard Purdie <rpurdie@...>
 

On Fri, 2010-10-22 at 11:22 -0700, Darren Hart wrote:
Here is an example of the do_fetch/do_unpack failure that I believe is
representative of what Dirk saw and what I have been seeing periodically.

I saw the following while building libproxy in poky-image-sdk-live on a
Fedora 13 box behind the firewall. I saw identical failures with opkg on
a different machine - also behind the firewall. Both SRC_URIs point to
googlecode.

log.do_fetch:
-------------
NOTE: fetch http://libproxy.googlecode.com/files/libproxy-0.4.3.tar.gz
NOTE: libproxy-0.4.3:
http://libproxy.googlecode.com/files/libproxy-0.4.3.tar.gz has no entry
in conf/checksums.ini, not checking URI

log.do_unpack:
--------------
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Exiting with failure status due to previous errors
NOTE: Unpacking
/vol/1/dvhart/poky.git/build/downloads/libproxy-0.4.3.tar.gz to
/vol/1/dvhart/poky.git/build/tmp/work/i586-poky-linux/libproxy-0.4.3-r2/
ERROR: Task failed:

With opkg, I tried the following which resulted in the same error.

$ bitbake -c clean;
$ rm downloads/*opkg*
$ bitbake opkg

In both cases, using wget to manually download the file and place it in
the downloads directory allowed the build to continue.
We've talked about this a lot over jabber. We don't have a reproducer.
What we do see is its always the wget fetcher that hits this (for mirror
urls in the case of git repos) and its failing creating a zero length
file.

If we make the assumption that wget is creating the empty file and
exiting with an error code and look at what bitbake would do, it would
give the behaviour described in these bugs.

Why? If the original fetch fails, it falls back to the mirror code. That
looks, sees a file on the disk and says "nothing to do".

Solution is therefore to make sure if the wget fetcher fails we wipe any
file that may be present.

Is is possible the wget fetcher is creating a zero length file and no
setting an error code but I really hope its not that broken.

So I've pushed this patch as a bandaid for the problem:

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=c5fab99a6f979a4a0ce246c6395b35a3082aec0d

Cheers,

Richard


RC3 vs RC4a

David Stewart
 

We have an RC3 which we feel confident in based on our no-nogo launch decision.

However, there are a handful of issues which are not critical but would be desirable to address them - for example, having to do with errors being "fatal" which are not, etc.

So I have asked Saul to create an RC4a with these patched in. Would like Sanity and BAT tests run on RC4a to see if we should ship it, or with stick with RC3.

RP - will complete the patch tonight.
Saul - will complete the RC4a build by 5PM Sunday (Pacific)
Kevin and Jiajun and whole team - test this build as much as you have time for.

Late Monday, we will decide whether to go with the RC3 build or RC4a build.

Dave


Re: Last minute changes - Review Request

David Stewart
 

From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Dirk Hohndel
Sent: Friday, October 22, 2010 10:48 AM

On Fri, 22 Oct 2010 12:24:40 -0500, Mark Hatle
<mark.hatle@...> wrote:
Add a +1 to reviewed, worried, but accepting column. They each seem
reasonable,
low-enough risk..
same here

We won't have a bug free release. No one ever does. And any change
increases the risk.

So the question is "are they worth the added risk?". I believe the
proposed changes address issues that people WILL run into as they start
playing with things, so I think the risk is worth the reward.

/D
Saul and Richard and I put a plan together for this, will create a new thread for it.


On 10/22/10 12:23 PM, Saul G. Wold wrote:
On 10/22/2010 09:32 AM, Stewart, David C wrote:
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Richard Purdie
Sent: Friday, October 22, 2010 7:24 AM

Coming up to release there are a few things that the extended
testing
has shown up which we have fixes for and which we should consider
including in the release. I also finally got around to doing the
final
sstate stress testing and found several problematic issues. Given
that
sstate and checksums are a significant feature of this release,
I'd
really like them to work as well as we can make them. Prior to
this I
had stress tested the backend up not the use of the packages.
These
changes don't change any sstate packages themselves, just the use
of
them.

Since we already have the release images prepared and tested and
these
are not going to change, the criteria for potential changes:

a) We can unit test the changes and be confident they don't
break/regress things.
For the Future: Besides doing a basic build, we need to have some
real
unit tests for bitbake and the poky infrastructure, I guess I need
to
turn this into a Testing feature request for 1.0 (look for it soon).

b) They fix important bugs that the user can easily run into
or that make the project look bad.
After reviewing the changes I agree, don't get me wrong, I am still
very
nervous about these changes.

c) The changes are small, well documented and are obviously
correct
looking at the code/patch.
Some times we over look the obvious changes, been caught by that
myself
too many time.

d) The don't change the generated images.
<SNIP>

I'm not happy about being in this position and I know Dave will be
very
nervous about these late changes. To mitigate this I'd like to
propose
that a selection of people (Josh, Mark, Saul?) review these
changes and
report back on whether they feel these are appropriate and also
give the
build some testing with these applied.
I'm so predictable... :-) Yes, I'm nervous. I looked at all of the
patches and with the exception of one or two, they mostly seem like good
ones. I will accept these if Josh/Mark/Saul give us a +1 on their
review& testing.
If there was 1 or 2 changes, I would be much happier, but there are
almost a dozen changes, yes mostly individually they are OK, I am
still
reviewing them all, and have not started any testing with them yet.

I agree with Dave that there are a couple that I am more nervous
about
the pseudo/fakeroot as we have had so much trouble in the past, yes
I
know this will make things better, but what else will crop up?


Cheers,

Richard









_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto
--
Dirk Hohndel
Intel Open Source Technology Center
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto


Re: RFC: "Demo Use Cases" documentation for the web page

Mark Hatle <mark.hatle@...>
 

On 10/22/10 5:17 PM, Mark Hatle wrote:
On 10/22/10 5:04 PM, Darren Hart wrote:
On 10/22/2010 02:04 PM, Alex deVries wrote:

On 2010-10-22, at 4:22 PM, Darren Hart wrote:

boards list used in this demo.
Hrm... do we want to explicitly call them out? The point is that it was
multi-architecture, but for some to recreate it, the point is that it
doesn't really matter what hardware they have - poky can build for any
of them.

What do others think, should we mention the specific boards in use at
the demo?

Yeah, I think we should. It proves that it really does run on other hardware, and the demo hw is the example. Showing product names helps shake the image that this is IA-only.
OK, so can someone provide me with an appropriate list of the non-IA
platforms? I know them as "The MIPS board" "The PPC board" etc.
arm - beagleboard (I don't know the revision)
ppc - fsl-mpc8315e-rdb
Figured I should expand this..

Freescale MPC8315E-RDB (I think w/ have the 'A' revision, but thats not likely important)

mips - Ubiquity Networks Router Station Pro a.k.a. MIPS Linux Starter Kit
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto


Re: RFC: "Demo Use Cases" documentation for the web page

Mark Hatle <mark.hatle@...>
 

On 10/22/10 5:04 PM, Darren Hart wrote:
On 10/22/2010 02:04 PM, Alex deVries wrote:

On 2010-10-22, at 4:22 PM, Darren Hart wrote:

boards list used in this demo.
Hrm... do we want to explicitly call them out? The point is that it was
multi-architecture, but for some to recreate it, the point is that it
doesn't really matter what hardware they have - poky can build for any
of them.

What do others think, should we mention the specific boards in use at
the demo?

Yeah, I think we should. It proves that it really does run on other hardware, and the demo hw is the example. Showing product names helps shake the image that this is IA-only.
OK, so can someone provide me with an appropriate list of the non-IA
platforms? I know them as "The MIPS board" "The PPC board" etc.
arm - beagleboard (I don't know the revision)
ppc - fsl-mpc8315e-rdb
mips - Ubiquity Networks Router Station Pro a.k.a. MIPS Linux Starter Kit


Re: RFC: "Demo Use Cases" documentation for the web page

Darren Hart <dvhart@...>
 

On 10/22/2010 02:04 PM, Alex deVries wrote:

On 2010-10-22, at 4:22 PM, Darren Hart wrote:

boards list used in this demo.
Hrm... do we want to explicitly call them out? The point is that it was
multi-architecture, but for some to recreate it, the point is that it
doesn't really matter what hardware they have - poky can build for any
of them.

What do others think, should we mention the specific boards in use at
the demo?

Yeah, I think we should. It proves that it really does run on other hardware, and the demo hw is the example. Showing product names helps shake the image that this is IA-only.
OK, so can someone provide me with an appropriate list of the non-IA platforms? I know them as "The MIPS board" "The PPC board" etc.

--
Darren Hart
Embedded Linux Kernel


RFC V2: "Demo Use Cases" documentation for the web page

Darren Hart <dvhart@...>
 

Apologies for the resend, sent from the wrong address and the list bounced it.

Version 2 with some updates from Kevin, Dave, Tom, and Mark:

Media Network Demo
==================
The Yocto Project launch event at ECLF 2010 featured a
multi-architecture Media Network Demo. All the source for this demo is
available in the meta-demo git repository as a layer for the poky build
system.

The following images made up the demo:
o poky-image-nas
o poky-image-mediatomb
o poky-image-rygel

Note that the goal of these recipes was to demonstrate example
functionality and the flexibility and power of Yocto. The goal was not
to produce a production-ready image.


poky-image-nas
--------------
The poky-image-nas image boots your device as a network attached storage
device. It provides a DHCP service and an NFS server, which exports
/media/storage out of the box. Adding your MP3 or OGG format music files
under this directory will make them available to other devices on your
LAN. As presently configured, it assumes an address of 192.168.1.1 and
offers DHCP addresses in the 192.168.1.128 - 192.168.1.254 lease block.

poky-image-mediatomb
--------------------
The poky-image-mediatomb image adds a UPnP content provider via the
mediatomb package. Note that you will have to update your networking
scripts to suit your system and network. For the demo, we simply added
"auto eth0" to /etc/network/interfaces and got a DHCP address from the
NAS. After modifying the networking, be sure to restart the mediatomb
service (or just reboot). You can configure it to mount the
/media/storage share from a poky-image-nas system (as we did), or store
your media locally. Use the mediatomb web interface to add music to the
database and make it available to UPnP renderers. See
/var/log/mediatomb.log for the address and port:

2010-09-08 10:50:03 INFO: MediaTomb Web UI can be reached by following this link:
2010-09-08 10:50:03 INFO: http://192.168.1.3:49152/

poky-image-rygel
----------------
The poky-image-rygel image provides gupnp tools and the rygel media
renderer along with the sato desktop. The renderer is started on boot
via an init script and can be controlled locally or via any control
point on the network. Several devices can run this image and stream
media from the mediatomb device. To use a local control point, locate
the "UPnP AV control" under the "Utilities" category of the sato
desktop. Expand "Mediatomb" in the treeview and you should see a
familiar music navigation hierarchy. Select a song and hit the "Play"
button. If you have multiple renderers on the network, you can select
which one to control with the renderer drop-down.


--
Darren Hart
Embedded Linux Kernel


Re: RFC: "Demo Use Cases" documentation for the web page

Alex deVries <alex.devries@...>
 

On 2010-10-22, at 4:22 PM, Darren Hart wrote:

boards list used in this demo.
Hrm... do we want to explicitly call them out? The point is that it was
multi-architecture, but for some to recreate it, the point is that it
doesn't really matter what hardware they have - poky can build for any
of them.

What do others think, should we mention the specific boards in use at
the demo?

Yeah, I think we should. It proves that it really does run on other hardware, and the demo hw is the example. Showing product names helps shake the image that this is IA-only.

- A


--
Alex deVries
Chief Linux Technologist
Wind River Systems


Re: RFC: "Demo Use Cases" documentation for the web page

Darren Hart <dvhart@...>
 

On 10/21/2010 05:26 PM, Tian, Kevin wrote:
From: Darren Hart
Sent: Friday, October 22, 2010 7:01 AM


Media Network Demo
==================
We're looking to have a section on the web site for the demo that
explains what each use-case is and possibly how it can be replicated.
I'm taking the approach of describing each image. Consider the
following:

The Yocto Project launch event at ECLF 2010 featured a
multi-architecture Media Network Demo. All the source for this demo is
available in the meta-demo git repository as a layer for the poky build
system.

The following images made up the demo:
o poky-image-nas
o poky-image-mediatomb
o poky-image-rygel

poky-image-nas
--------------
The poky-image-nas image boots your device as a network attached storage
device. It provides a DHCP service and an NFS server. We used this image
to store all our media.

poky-image-mediatomb
--------------------
The poky-image-mediatomb image adds a UPnP content provider via the
mediatomb package. This image mounts the media share from the NAS and
makes it available to UPnP renderers.

poky-image-rygel
----------------
The poky-image-rygel image provides gupnp tools and the rygel media
renderer along with the sato desktop. The renderer can be controlled
locally or via any control point on the network. Several devices can run
this image and stream media from the mediatomb device.


Open Questions
--------------
o Is this more or less what we are looking for?
boards list used in this demo.
Hrm... do we want to explicitly call them out? The point is that it was multi-architecture, but for some to recreate it, the point is that it doesn't really matter what hardware they have - poky can build for any of them.

What do others think, should we mention the specific boards in use at the demo?


Also a simple figure is always more intuitive to catch the intention here. :-)

o Should we modify the mediatomb image to:
o automatically mount a specific share from the NAS?
o add something to the config to automatically scan the
media share?
o The poky-image-rygel description needs to be updated as we finalize
the package.
One thought is, could we convert this demo page into something more useful
as the collection for various use cases on Yocto which can be contributed by
any user, and then here UPnP is the 1st example?
I'm not opposed to the idea, but for now, let's just make it a page where people can go and get more detail about what we did for the demo and get them started on replicating it if they should so choose.


Thanks
Kevin

--
Darren Hart
Embedded Linux Kernel