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.
b) They fix important bugs that the user can easily run into
or that make the project look bad.
c) The changes are small, well documented and are obviously correct
looking at the code/patch.
d) The don't change the generated images.

I'm proposing the following, for each I've provided a rationale:

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

Printing "fatal:" to new users is worrying

[Reported by Dirk]

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

Users can easily hit the sanity warning about missing 32 bit libs. We
don't need this functionality at this time so we might as well turn it
off by default

[Reported by Dirk]

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

Doesn't change the build output but fixes a build issue people can
easily run into in from scratch builds due to a missing dependency.

[Reported by Dexuan]

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

Removes the "WARNING: Function do_build doesn't exist" message which
could worry users and looks bad

[Reported by Richard]

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

Several complaints have been received about the inability to easily
delete sstate and DL_DIR contents to recover from failures. This adds a
cleanall task which does this. Downside is that this is undocumented.

[Reported by Darren and others, run into by Dirk]

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

Fixes an sstate bug where the do_package sstate packages don't install
correctly. A user could hit this if cleaning and rebuilding a package
under certain circumstances.

[Reported by Richard]

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

Fixes an issue with sstate where rebuilding a package using partially
prebuilt state would break rpm generation and silently remove all the
rpm packages.

[Reported by Richard]

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

Fixes a typo spotted in the debian packaging backend. We don't use this
by default but it should be fixed.

[Reported by Richard]

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

User testing keeps showing up issues with the pseudo directory creation
failing to happen. This patch solves the problem in a brute force
fashion, once and forall.

[Reported by Mark and others]

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

Fixes an sstate issue seen on the Poky mailing list where file:// sstate
mirrors wouldn't work.

[Reported by Gary Thomas (poky list)]

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

Just changes a log level to make the output from sstate slightly more
readable.

[Reported by Richard]


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.

Cheers,

Richard

On 10/22/2010 12:29 AM, Joshua Lock wrote:

On Thu, 2010-10-21 at 15:44 -0700, Darren Hart wrote:

I build mediatomb and rygel live atom-pc images from today's poky/master
+ meta-demo/master. I booted mediatomb on the BlackSand and rygel on the
netbook. I had to manually start the rygel renderer on the netbook. I
didn't see gupnp-av-cp on the rygel image as I expected and the
gupnp-universal-cp command failed to start on the netbook (via a sato
terminal) complaining about missing icons. If I tried to stabrt this
over an ssh - connection, the gupnp-universal-cp started fine (strange).

Hmm, I've commits to fix both of those issues in meta-demo master since
at least yesterday morning.b

I think my build just has some stale data that the various cleans haven't cleared. I'm going to try some clean builds today.


--
Darren Hart
Embedded Linux Kernel

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.
b) They fix important bugs that the user can easily run into
or that make the project look bad.
c) The changes are small, well documented and are obviously correct
looking at the code/patch.
d) The don't change the generated images.

I'm proposing the following, for each I've provided a rationale:

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=d5504a4275d94868e
28b00c272411e82f4999d95

Printing "fatal:" to new users is worrying

[Reported by Dirk]

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=2a69c58046a86d0f7
83acebd8a77e9419b43139a

Users can easily hit the sanity warning about missing 32 bit libs. We
don't need this functionality at this time so we might as well turn it
off by default

[Reported by Dirk]

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=0068e55d8f64ae13a
1049c37164e8b14dc33f53f

Doesn't change the build output but fixes a build issue people can
easily run into in from scratch builds due to a missing dependency.

[Reported by Dexuan]

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=6e277cb014a53aef6
6ae931b5142495f8a02404f

Removes the "WARNING: Function do_build doesn't exist" message which
could worry users and looks bad

[Reported by Richard]

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

Several complaints have been received about the inability to easily
delete sstate and DL_DIR contents to recover from failures. This adds a
cleanall task which does this. Downside is that this is undocumented.

[Reported by Darren and others, run into by Dirk]

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

Fixes an sstate bug where the do_package sstate packages don't install
correctly. A user could hit this if cleaning and rebuilding a package
under certain circumstances.

[Reported by Richard]

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=13f116b1ad6a955b0
7d4cbaba85879913c30e1ee

Fixes an issue with sstate where rebuilding a package using partially
prebuilt state would break rpm generation and silently remove all the
rpm packages.

[Reported by Richard]

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=00a96a20995cefacc
52e10559029de32941ecf6e

Fixes a typo spotted in the debian packaging backend. We don't use this
by default but it should be fixed.

[Reported by Richard]

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=36f1ae42fe13dae17
4b7fb5eb85dc49d7d7b516b

User testing keeps showing up issues with the pseudo directory creation
failing to happen. This patch solves the problem in a brute force
fashion, once and forall.

[Reported by Mark and others]

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=3f599b3f6a4728627
7cdaa8503f8a8da024eadd4

Fixes an sstate issue seen on the Poky mailing list where file:// sstate
mirrors wouldn't work.

[Reported by Gary Thomas (poky list)]

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=535a77a9b681423e2
f10744aca54858c25a03cb0

Just changes a log level to make the output from sstate slightly more
readable.

[Reported by Richard]


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.

Cheers,

Richard









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

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

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

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

--Mark

From: Darren Hart [mailto:dvhart@...]
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

On Fri, 22 Oct 2010 10:35:49 -0700, "Stewart, David C" <david.c.stewart@...> wrote:

From: Darren Hart [mailto:dvhart@...]
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

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

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

On 10/22/10 12:35 PM, Stewart, David C wrote:

From: Darren Hart [mailto:dvhart@...]
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

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

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

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

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

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

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

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

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

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

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