Date   

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@yoctoproject.org
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@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] 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@windriver.com> 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@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] 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@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
--
Dirk Hohndel
Intel Open Source Technology Center
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
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@yoctoproject.org
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


Fetcher error reporting

Darren Hart <dvhart@...>
 

Richard,

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.

--
Darren Hart
Embedded Linux Kernel


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

Mark Hatle <mark.hatle@...>
 

On 10/22/10 12:35 PM, Stewart, David C wrote:
From: Darren Hart [mailto:dvhart@linux.intel.com]
Sent: Thursday, October 21, 2010 4:01 PM


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:
At this point, the site map is set, and we're working with the web guys to set this up for review today and over the weekend. I'm loath to mess with the structure at this point, and adding something like this would require more than a page, it requires references, etc.

I'm inclined to add a page to the new wiki once it is set up. (Scott is working on that now). Then we could add a link to the signage and on the Resources page.

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."

What might be better here would be a little additional info with each of these. Some examples below.

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.
"The filesystem called /<blah> is exported via nfsexport<or whatever>. To make use of this for our demo setup, put your *.mp3 or *.ogg files into the /<blah> directory. You need to make sure your system is on a network, and the TCP/IP stack is configured correctly to be visible by the other client systems."
/media/storage is the export location...

(I am sure you can fix this up to make it better).

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.
"You need to edit<this file> to nfsmount the filesystem from the NFS server in the previous example or use a local disk or another file server."

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.
"To activate the media renderer, type<something> at the command line as root." You get my drift.

Let's go through one more round on email with these enhancements and by then the wiki should be set up.


Open Questions
--------------
o Is this more or less what we are looking for?
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.



--
Darren Hart
Embedded Linux Kernel


Re: Last minute changes - Review Request

Dirk Hohndel <hohndel@...>
 

On Fri, 22 Oct 2010 12:24:40 -0500, Mark Hatle <mark.hatle@windriver.com> 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


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@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] 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@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
--
Dirk Hohndel
Intel Open Source Technology Center


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

Dirk Hohndel <hohndel@...>
 

On Fri, 22 Oct 2010 10:35:49 -0700, "Stewart, David C" <david.c.stewart@intel.com> wrote:
From: Darren Hart [mailto:dvhart@linux.intel.com]
Sent: Thursday, October 21, 2010 4:01 PM


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:
At this point, the site map is set, and we're working with the web guys to set this up for review today and over the weekend. I'm loath to mess with the structure at this point, and adding something like this would require more than a page, it requires references, etc.

I'm inclined to add a page to the new wiki once it is set up. (Scott is working on that now). Then we could add a link to the signage and on the Resources page.
I think this is much more appropriate for the wiki, anyway.


--
Dirk Hohndel
Intel Open Source Technology Center


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

David Stewart
 

From: Darren Hart [mailto:dvhart@linux.intel.com]
Sent: Thursday, October 21, 2010 4:01 PM


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:
At this point, the site map is set, and we're working with the web guys to set this up for review today and over the weekend. I'm loath to mess with the structure at this point, and adding something like this would require more than a page, it requires references, etc.

I'm inclined to add a page to the new wiki once it is set up. (Scott is working on that now). Then we could add a link to the signage and on the Resources page.

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."

What might be better here would be a little additional info with each of these. Some examples below.

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.
"The filesystem called /<blah> is exported via nfsexport <or whatever>. To make use of this for our demo setup, put your *.mp3 or *.ogg files into the /<blah> directory. You need to make sure your system is on a network, and the TCP/IP stack is configured correctly to be visible by the other client systems."

(I am sure you can fix this up to make it better).

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.
"You need to edit <this file> to nfsmount the filesystem from the NFS server in the previous example or use a local disk or another file server."

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.
"To activate the media renderer, type <something> at the command line as root." You get my drift.

Let's go through one more round on email with these enhancements and by then the wiki should be set up.


Open Questions
--------------
o Is this more or less what we are looking for?
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.



--
Darren Hart
Embedded Linux Kernel


Re: Last minute changes - Review Request

Mark Hatle <mark.hatle@...>
 

Add a +1 to reviewed, worried, but accepting column. They each seem reasonable, low-enough risk..

--Mark

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@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] 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@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto


Re: Last minute changes - Review Request

Saul G. Wold <sgw@...>
 

On 10/22/2010 09:32 AM, Stewart, David C wrote:
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] 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@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.pokylinux.org/listinfo/yocto


Re: Last minute changes - Review Request

Joshua Lock <josh@...>
 

On Fri, 2010-10-22 at 15:23 +0100, Richard Purdie wrote:

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've looked over the changes and spent this afternoon testing them, I
believe they are appropriate for the 0.9 release.

Cheers,
Joshua
--
Joshua Lock
Intel Open Source Technology Centre