Date   

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@...]
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@...> 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


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


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

David Stewart
 

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


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@... [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


Re: Last minute changes - Review Request

Saul G. Wold <sgw@...>
 

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


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


Re: Last minute changes - Review Request

David Stewart
 

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


Re: Media Network Demo: Black Sand and Netbook

Darren Hart <dvhart@...>
 

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


Last minute changes - Review Request

Richard Purdie <rpurdie@...>
 

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


Re: Media Network Demo: Black Sand and Netbook

Joshua Lock <joshua.lock@...>
 

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 could run gupnp-av-cp from my laptop (Ubuntu 10.10) and play music
from mediatomb on the rygel renderer. (YAY)
Cool!


What I'd like to see is for gupnp-av-cp to start automatically after the
sato desktop loads on each renderer. This would make each renderer a
standalone player.

So, it's functional (awesome!) and I see these ARs as pending for the
demo images:

[ ] add gupnp-av-cp to the rygel image
Already done
[ ] start rygel on boot (after networking)
I'll take this AR
[ ] start gupnp-av-cp after the sato desktop loads on the rygel image
I'll take this AR too
[ ] setup networking on each of the non-nas images to dhcp on eth0

With the above, each image should boot to a functional state with no
manual interference required.

How much of the above is already planned and how much do we need to get
an owner for?
I'll handle the Rygel and gupnp-av-cp ones, they where already on my
list :-)

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

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: Please verify the fixed bug in bugzilla.

Darren Hart <dvhart@...>
 

On 10/21/2010 12:44 AM, You, Yongkang wrote:
Hi all,

I just had a quick search in bugzilla and found a lot of bugs are resolved but not verified. We'd better to verify the fix before 0.9 launch.

The M4 resolved (but not verified) bugs (88):
http://bugzilla.pokylinux.org/buglist.cgi?bug_status=RESOLVED&query_format=advanced&target_milestone=0.9%20M4&query_based_on=&columnlist=bug_severity%2Creporter%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cproduct%2Ccomponent

All resolved (but not verified) bugs (198):
http://bugzilla.pokylinux.org/buglist.cgi?query_format=advanced&bug_status=RESOLVED
Bug 468 needs confirmation by someone in PRC with the HP Mini netbook. I've verified the other 4 I opened.

--
Darren Hart
Embedded Linux Kernel


Re: zypper and poky architectures

Qing He <qing.he@...>
 

On Thu, 2010-10-21 at 23:18 +0800, Mark Hatle wrote:
On 10/21/10 3:33 AM, Qing He wrote:
1. what uses for independent packages is called "noarch", "all" is not
recognized, something depends on update-rc.d won't be installed
because of missing dependency
We can certainly look into translating "all" to "noarch" post 0.9. That might
make it easier for people coming from the RPM world, to understand what is in
the package.

1. rename *.all.rpm to *.noarch.rpm
We can certainly do this easily.
If noarch is universally used in RPM word, I think we should use it.


2. the arch automatic detection system uses "uname -m", thus producing
armv5tejl, which can only be resolved as armv5tel, conflicting with
"armv5te" in rpm
This is a bug in Zypper. The machine names should come from somewhere other
then uname -m. (The value of uname -m is very much ia32 specific for the most
part.. other architectures have way too many possible namings for it to be
useful.) There is a line in "/etc/rpm/platform" that contains the name of Poky
architecture. This file should be referenced (instead of -m) for all cases.

3. enhance zypper arch module, make the addition more flexible,
allowing arch alias (e.g. armv5te = armv5tel = armel = arm)
Zypper should read the rpm platform file.
Sounds reasonable. After all, zypper is only intended to be a frontend
utility to the lower end package tool. Then we won't need to worry about
alias and different naming, and this detaches zypper from hardware.


3. many archs are missing in zypper, like mips, armeb, etc.
4. there is no concept of machine-dependent packages (task-base) in
zypper, although we can work around.
Generally speaking, this is true of most RPM installations. However, within RPM
itself.. there really isn't any concept of "arch" anymore.. They're really only
used for grouping and ordering. So Zypper may need to be updated to query the
arch of a package and use it for it's various operations.

2. removing the concept of machine-dependent packages, change all
*.qemuarm.rpm to *.armv5te.rpm
I'm a bit worried about doing this, as we'll end up with (potentially)
incompatible packages with exactly the same name and versions... Perhaps we
need to think about embedding the machine type into the name of the packages
instead?
Thanks for the info. If we are going for dynamic platform specs, it
doesn't really matter whether we have things like qemuarm or not, does it?



That would be some work to do, maybe 1.0 is a good time to get zypper
and package upgrade truely working.
Yes, we also need to get multi-arch as well.. (i.e. 32-bit and 64-bit at the
same time) working. I'm guessing there will be some Zypper interactions there
as well.
I don't really have ideas how this is done. I think on debian this is
actually avoided and i386 packages are repackaged as lib32xxx for x86_64
platform.

Thanks,
Qing


Re: zypper and poky architectures

Qing He <qing.he@...>
 

On Thu, 2010-10-21 at 19:21 +0800, Richard Purdie wrote:
On Thu, 2010-10-21 at 16:33 +0800, Qing He wrote:
I recently reported several zypper bugs specifically for arm, after
some deeper investigation, the problem seems to be of higher level than
I originally thought.

The root cause is that zypper and poky use different way to represent
architectures, as we are putting them together, these two ways are
not compatible, causing many minor glitches that need to modify at
least one of them.

Poky has three kinds of representations in a single target image, which
are independent, cpu-dependent and machine-dependent (all, armv5te,
qemuarm, respectively), e.g.

update-rc.d-0.7-r3.all.rpm
curl-7.21.0-r0.armv5te.rpm
task-base-1.0-r69.qemuarm.rpm

(note that armv5te is the same with gcc's -march option, meaning little
endian)
This is a good analysis and summary. It actually gets more complicated
as for some machines we have a long list of compatible package types
that can be installed, e.g. for qemuarm, if you list PACKAGE_ARCHES
you'll see armv4t armv5 armv5t armv5te which are all accepted by the
opkg backend.
Zypper also does something similar:

defCompatibleWith(_armv5tejl, _noarch,_armv3l,_armv4l,_armv4tl,_armv5l,_armv5tel);


Currently, at least zypper is broken on all of mips, arm, ppc, with
slightly different problems.

The ideal situation is to use consistent arch specification, the
following can be a solution:
1. rename *.all.rpm to *.noarch.rpm
This would only solve part of the problem though?
Yes, only a small part. And the way I prefer is to add an alias in zypper
instead of changing poky.


2. removing the concept of machine-dependent packages, change all
*.qemuarm.rpm to *.armv5te.rpm
This could mean making a copy of each rpm per machine so I'm not keen on
this.
Agreed.


3. enhance zypper arch module, make the addition more flexible,
allowing arch alias (e.g. armv5te = armv5tel = armel = arm)

That would be some work to do, maybe 1.0 is a good time to get zypper
and package upgrade truely working.

Any ideas and comments?
I think we're going to have to teach zypper to read a list of compatible
"architectures" from a configuration file. There is a config file opkg
writes to the filesystem continaing this list and we'll have to do
similar for RPM.
The problem is that current zypper uses hardcoded "archs" and
compatibility list, i.e. at build time with C++ code. Changing it to
read the list at run time is probably substantial.

Another possibility is to generate the list at build time and do it by
scripts and conditional compiling, this does have the problem of
creating logically different versions for different archs.


It does raise the question of how given two possible rpm's it would
chose between the two (for opkg, the list is in order).

Is the problem just in zypper and is rpm free from any issues in this
area?
I don't know much about rpm internals, there is a bug regarding the rpm,
http://bugzilla.pokylinux.org/show_bug.cgi?id=498

But it looks fair limited in impact.

Thanks,
Qing


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

Tom Zanussi <tom.zanussi@...>
 

On Thu, 2010-10-21 at 16:00 -0700, Darren Hart wrote:
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:
This is a good start. I don't know if this is the place to add it, but
I just wanted to capture the details of what I've done so far to get my
setup working. For now mainly in case anyone else could use some hints
on how to get everything going...

Basically this is just what I did, and it may be completely wrong -
please do correct anything stupid and suggest improvements if you see
any - at this point I just want to get the basic stuff up and running so
I can pack it all up tomorrow night and not be too worried about not
having anything.

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.
Rather than using the nas image, since all I have is a laptop and the
two atom boards, I decided to just do the simplest thing for now and
have my laptop host and serve up the images over nfs (I was thinking of
doing the nas image inside of say an arm qemu instance running on the
laptop, and may still if I get time, but as a simple approximation, this
will work. All this is also just a fallback in case the real demo
system breaks down, so I'm not being too particular).

So on the laptop, install the nfs server and export the media files:

# apt-get install nfs-kernel-server

Put a bunch of music files somewhere - in my case I put some files in:

/home/trz/Music

Add a line to /etc/exports to export that directory:

/home/trz/Music *(ro,sync,no_root_squash)

restart the nfs server:

/etc/init.d/nfs-kernel-server restart

Let's say the IP address the laptip got was 192.168.1.3.

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.
ssh into the mediatomb board, in my case, this is a Black Sand, and
mount the exported media share:

# mount 192.168.1.3:/home/trz/Music /media/music

So now the mediatomb box has access to the files it's going to
advertise. Let's tell mediatomb to do that.

Look in /var/log/mediatomb.log

You should see a line like this:

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/

Point a web browser at that URL and you should see the minimalistic
Mediatomb web interface. Click on the 'Filesystem link' and you should
see somewhere in there your /media/music mount. Click on that and you
should see all your music on the right-hand-side. Click on the '+' and
that should add all your songs to mediatomb (watch out, there doesn't
seem to be any indication as to whether it succeeded or not - I had
duplicates show up in Mediatomb if I did that more than once - just like
iTunes, yeah!).

If you go the 'Database link', you should see a treeview with your songs
somewhere in there. This is the same hierarchy you'll see and navigate
to play your songs in the rygel image 'AV control point'.

*Note, if mediatomb.log showed errors instead of the URL you need, it's
probably because eth0 didn't come up (working on a fix). An ifup
eth0; /etc/init.d/mediatomb restart should fix that.

If that step was successful, you should now be able to see and play your
songs from another box...


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.
On the rygel image, open up a terminal and type:

# rygel

(the latest image takes awhile to display anything - it's not graphical,
will display a couple lines of text - one of which is an error message,
but the 'playbin' plugin should say it's available, and things should
still work.)

Navigate back to the Desktop and find the 'UpnP Universal Control Point'
and click on it. That should open up a graphical UI showing available
data sources (but is not where you play media from)...

Navigate back to the Desktop and find the 'UPnP AV Control Point'.
Click on that, and you should see something more familiar, something
that looks like it can actually do something useful, which is play a
song. Click on treeview in the app, and eventually you should see some
songs. Click on a song, and hit the 'Play' button, and it should play
the song - it couldn't be easier!

NOTE: make sure you have speaker connected to the board you're rendering
the music on. If that doesn't work, try opening a terminal window and
using amixer to play around with the volume e.g.:

amixer set Master on
amixer set Master 75

For extra credit, install gupnp-tools and try the AV Control Point from
your laptop, or any system - you should see the same media and should be
able to control it from anywhere. Choose a different song and send it
to any other renderer running on any other box, etc. The possibilities
are endless!


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.



Re: Please verify the fixed bug in bugzilla.

You, Yongkang <yongkang.you@...>
 

On Thursday, October 21, 2010 8:48 PM, Richard Purdie wrote:
On Thu, 2010-10-21 at 15:44 +0800, You, Yongkang wrote:
Hi all,

I just had a quick search in bugzilla and found a lot of
bugs are resolved but not verified. We'd better to verify the
fix before 0.9 launch.

The M4 resolved (but not verified) bugs (88):
http://bugzilla.pokylinux.org/buglist.cgi?bug_status=RESOLVED&q
uery_format=advanced&target_milestone=0.9%20M4&query_based_on=&
columnlist=bug_severity%2Creporter%2Cpriority%2Cop_sys%2Cassign
ed_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cproduct%2Ccomponent

All resolved (but not verified) bugs (198):
http://bugzilla.pokylinux.org/buglist.cgi?query_format=advanced
&bug_status=RESOLVED

Just to remind people, who is responsible for verifying a bug? The
original reporter?
RP,

Yes. The original reporter is responsible for bug verification. Please do it as more as possible.

Do we need to close (verify) all fixed bugs before 0.9 release? QA can help to close the old bugs (bug ID <100).

Thanks,
Yongkang


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

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

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.

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?

Thanks
Kevin