Date   

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


Re: Media Network Demo: Black Sand and Netbook

Tom Zanussi <tom.zanussi@...>
 

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

I could run gupnp-av-cp from my laptop (Ubuntu 10.10) and play music
from mediatomb on the rygel renderer. (YAY)

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
I think this is already done - I have it on my image and it works for
me.

[ ] start rygel on boot (after networking)
[ ] start gupnp-av-cp after the sato desktop loads on the rygel image
[ ] setup networking on each of the non-nas images to dhcp on eth0
eth0 on the rygel image seems to come up ok, it's just the mediatomb
image that doesn't afaics. I'll probably look into this tonight.

I also added a small change in tom/demo that allows the mediatomb image
to do nfs. After doing that, I was able to mount an nfs share from my
laptop on the Black Sand, and have mediatomb add all the media there.

Tom

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?


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

Darren Hart <dvhart@...>
 

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?
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


Media Network Demo: Black Sand and Netbook

Darren Hart <dvhart@...>
 

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

I could run gupnp-av-cp from my laptop (Ubuntu 10.10) and play music
from mediatomb on the rygel renderer. (YAY)

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
[ ] start rygel on boot (after networking)
[ ] start gupnp-av-cp after the sato desktop loads on the rygel image
[ ] 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?

--
Darren Hart
Embedded Linux Kernel


Yocto project 0.0 Release Readiness Review

David Stewart
 

Attending: Paul, Davest, Dirk, Richard, Saul, Alex, Mark, Jessica, Bruce, Darren

 

Goal: Review the release criteria and make a clear decision to see that we're ready to release.

 

Summary: Launch criteria met with these exceptions:

                * BSPs for Tunnel Creek coming by end of November

                * Documentation and web site will become live over the weekend for check out

                * One high open bug (issue with zypper on targets) to be addressed early in post-launch time frame, OK for now

                * Medium open bug count is higher than desired; major focused effort on resolving bugs in next dev cycle

                * Full test report for all architectures pending - will review by end of week

 

Decision: Go for launch

 

Details:

 

Features Completeness -  100%

                Exceptions relative to the features on the product requirement:

                                Tunnel Creek BSP - will be available by end of November

                                Documentation - the basic pieces are there, more are coming in post 0.9 launch

                                Several engineers unfamiliar with the project are taking the existing bits and making sure they can do a build without hand-holding. This should be complete by latest on Sunday.

 

Bug Status:

                Note: these bug count goals are suggestions for now, we need to

 

* No High Bugs. Actual bugs below:

                190 - an enhancement, will be addressed for the 0.9 release

                443 - zypper segfaulting on some architectures parsing package list on some images.  Zypper really needs to be rearchitected early in the 1.0 cycle. Just use RPM directly. Document.

                477 - Certain Python modules don't work on the target, late breaking, will downgrade to medium

 

* Medium Bugs < 15

                51 total are open now, 7 will be addressed before launch

                Does not meet the criteria, but as these are documented we believe they are acceptable to ship with.

                We need to do a serious effort to reduce the bug count for 1.0.

                We also need to analyze our bug handling process in the next planning meeting.

 

* Low Bugs < 30

                37 are open now.

 

* No Undecided Bugs

                May include some which come in very late and have not been dispositioned yet.

 

Unit Tests Completed - 100%

Test Cases Completed - 100%

                What was planned was completed. Would like to expand this going forward.

 

Sanity Test – 100%

BAT Testing – 100%

Full Test – 90% Passing

                93% completion for all architectures for QEMU and iA hardware

                Need report on ARM, PPC and MIPs hardware - Saul

 

Legal & License – Have Legal & Open Source PDT Approval

                Have completed all required legal review

 

Docs – Pass stakeholder review & Publish to Website

                Currently in process and under review, should be available for review


Re: UPnP demo - call for testing

Darren Hart <dvhart@...>
 

On 10/21/2010 03:50 AM, Joshua Lock wrote:
On Thu, 2010-10-21 at 13:32 +0800, Xu, Dongxiao wrote:
Xu, Dongxiao wrote:
I'd also like to have a try, and building the demo image now.

Thanks,
Dongxiao

Joshua Lock wrote:
Hi all,

I've successfully tested the UPnP demo in my office but would
appreciate someone else taking a bash.

Unfortunately you currently need my branch from poky-contrib
(josh/demo) and the corresponding branch from meta-demo (josh/demo).

The renderer and controller are installed together in the
poky-image-rygel image (I've been using the -live variant).

I needed to use amixer to enable the soundcard and increase the
volume on the netbook I was using.

"amixer set Master on
amixer set Master 75"

Run rygel from a terminal and launch gupnp-av-cp and you should be
able to set play music from a content store on the device. I haven't
tested video...
I just setup the environment and gupnp-av-cp could play music from
another host within the network. However it seems that video doesn't
work yet. Does gupnp-av-cp supports video play?
Thanks for testing this Dongxiao!

I'm not sure whether video is required for the demo, but it should be
supported by gupnp-av-cp and Rygel so long as required gstreamer plugins
are installed. What type of video where you trying to play?
Video is a nice to have, but not required for the UK demo.

--
Darren Hart
Embedded Linux Kernel


Re: UPnP demo - call for testing

Mark Hatle <mark.hatle@...>
 

On 10/21/10 9:52 AM, Tom Zanussi wrote:
On Wed, 2010-10-20 at 10:18 -0700, Joshua Lock wrote:
Hi all,

I've successfully tested the UPnP demo in my office but would appreciate
someone else taking a bash.
With the mediatomb image running on a Black Sand and the rygel image
running on an eMenlow, and using the av-cp on my laptop, I'm able to get
ok audio out of the eMenlow speakers - pretty nifty! ;-)

Still need to get the nas piece going, but it all basically works with
the hardware I have (and will be bringing) - nice job!
poky-image-nas should work on any hardware -- just keep in mind that by default it serves everything over "eth1". Update the config files in meta-demo/images/poky-image-nas/* to point to eth0 (or elsewhere).

--Mark

Tom



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


Re: zypper and poky architectures

Mark Hatle <mark.hatle@...>
 

On 10/21/10 6:21 AM, 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.

This is natural until zypper is involved. Zypper supports only one arch
at one time (and this arch should not be changed in fly), and use the
idea of arch compatibility (e.g. _noarch is compatible with _i586), it
then hardcodes the available archs in a different way than poky does,
thus creating several problems:
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
2. the arch automatic detection system uses "uname -m", thus producing
armv5tejl, which can only be resolved as armv5tel, conflicting with
"armv5te" in rpm
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.

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?

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.

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.

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?
We will need to do some additional verification on RPM -- but it appears to me that RPM should not have a problem with this. As far as I'm aware, RPM5 simply ignores the ARCH field for the most part. (My concern as we move in this direction will be ordering of priority between architecture types.. perhaps thats not even in the scope of RPM to worry about... but replacing say an armv4 w/ an armv5 is...)

--Mark

Cheers,

Richard

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


Re: zypper and poky architectures

Mark Hatle <mark.hatle@...>
 

On 10/21/10 3:33 AM, 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 natural until zypper is involved. Zypper supports only one arch
at one time (and this arch should not be changed in fly), and use the
idea of arch compatibility (e.g. _noarch is compatible with _i586), it
then hardcodes the available archs in a different way than poky does,
thus creating several problems:
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.

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

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
We can certainly do this easily.

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?

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.

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.

--Mark

Any ideas and comments?

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


Re: UPnP demo - call for testing

David Stewart
 

Nice - thanks Tom and Josh
Sent from my Blackberry

----- Original Message -----
From: Tom Zanussi [mailto:tom.zanussi@...]
Sent: Thursday, October 21, 2010 07:52 AM
To: Joshua Lock <josh@...>
Cc: yocto@... <yocto@...>
Subject: Re: [yocto] UPnP demo - call for testing

On Wed, 2010-10-20 at 10:18 -0700, Joshua Lock wrote:
Hi all,

I've successfully tested the UPnP demo in my office but would appreciate
someone else taking a bash.
With the mediatomb image running on a Black Sand and the rygel image
running on an eMenlow, and using the av-cp on my laptop, I'm able to get
ok audio out of the eMenlow speakers - pretty nifty! ;-)

Still need to get the nas piece going, but it all basically works with
the hardware I have (and will be bringing) - nice job!

Tom



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


Re: UPnP demo - call for testing

Joshua Lock <josh@...>
 

On Thu, 2010-10-21 at 09:52 -0500, Tom Zanussi wrote:
On Wed, 2010-10-20 at 10:18 -0700, Joshua Lock wrote:
Hi all,

I've successfully tested the UPnP demo in my office but would appreciate
someone else taking a bash.
With the mediatomb image running on a Black Sand and the rygel image
running on an eMenlow, and using the av-cp on my laptop, I'm able to get
ok audio out of the eMenlow speakers - pretty nifty! ;-)

Still need to get the nas piece going, but it all basically works with
the hardware I have (and will be bringing) - nice job!
Huzzah! Replicated on three set ups, victory is mine!

Unfortunately I've had only limited success with videos so will continue
to look into that...

Thanks for testing Tom!

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


Re: UPnP demo - call for testing

Tom Zanussi <tom.zanussi@...>
 

On Wed, 2010-10-20 at 10:18 -0700, Joshua Lock wrote:
Hi all,

I've successfully tested the UPnP demo in my office but would appreciate
someone else taking a bash.
With the mediatomb image running on a Black Sand and the rygel image
running on an eMenlow, and using the av-cp on my laptop, I'm able to get
ok audio out of the eMenlow speakers - pretty nifty! ;-)

Still need to get the nas piece going, but it all basically works with
the hardware I have (and will be bringing) - nice job!

Tom


Re: Yocto Readiness Review Meeting

Alex deVries <Alex.deVries@...>
 

I'll be there too.

- A

On 2010-10-19, at 6:31 PM, Richard Purdie wrote:

On Tue, 2010-10-19 at 15:13 -0700, Wold, Saul wrote:
David, Kevin, Paul, Richard:

As discussed in the project sync we need to do a readiness review to
look at the current state of the release with regards to existing open
bugs, QA testing, and general sanity of the release.

The best time for this would be Thursday morning at 11:00, could the
folks on the "To:" line please respond with your availablity to meet at
this time. We need to do it in the morning to enable Richard to attend
at a "reasonable" hour.


Thursday Oct 21, 2010 11:00AM
Where: 916-356-2663, 8-356-2663 Bridge 92 / 3302969
This is ok with me.

Cheers,

Richard
--
Alex deVries
Chief Linux Technologist
Wind River Systems


Re: Release checklist

Richard Purdie <rpurdie@...>
 

On Wed, 2010-10-20 at 10:02 -0700, Dirk Hohndel wrote:
On Wed, 20 Oct 2010 14:07:21 +0100, Richard Purdie <rpurdie@...> wrote:
Coming up to launch there are going to be some technical things that
need to be done, I'm aiming to write these down and assign owners so we
remember them all and that they all happen:

* Remove password protection from yoctoproject.org (sub)domains [RP]
* Swap default site redirection and name for lists.* and wiki.* [RP]
* Make meta-demo public [RP]
* Remove password protection from autobuilder [ScottG]
* Upload final version of the eclipse plugin [Jessica]
* Upload final Yocto release images and tarballs [???]
While not exactly technical, these should be tracked as well:

* post announcement email to LWN [RP or DH]
* post announcement email to... (where else?)
Poky and OpenEmbedded mailing lists from me.

* prior to announcement distribute Q&A inside Intel [TE]

What date and time are we going to actually do these things?
- We should open everything up 4pm UK time on Wednesday
- Post announcements AFTER dinner (so 8pm UK time)

/D


Re: UPnP demo - call for testing

Xu, Dongxiao <dongxiao.xu@...>
 

Joshua Lock wrote:
On Thu, 2010-10-21 at 13:32 +0800, Xu, Dongxiao wrote:
Xu, Dongxiao wrote:
I'd also like to have a try, and building the demo image now.

Thanks,
Dongxiao

Joshua Lock wrote:
Hi all,

I've successfully tested the UPnP demo in my office but would
appreciate someone else taking a bash.

Unfortunately you currently need my branch from poky-contrib
(josh/demo) and the corresponding branch from meta-demo
(josh/demo).

The renderer and controller are installed together in the
poky-image-rygel image (I've been using the -live variant).

I needed to use amixer to enable the soundcard and increase the
volume on the netbook I was using.

"amixer set Master on
amixer set Master 75"

Run rygel from a terminal and launch gupnp-av-cp and you should be
able to set play music from a content store on the device. I
haven't tested video...
I just setup the environment and gupnp-av-cp could play music from
another host within the network. However it seems that video doesn't
work yet. Does gupnp-av-cp supports video play?
Thanks for testing this Dongxiao!

I'm not sure whether video is required for the demo, but it should be
supported by gupnp-av-cp and Rygel so long as required gstreamer
plugins are installed. What type of video where you trying to play?
I played OGG format video which should be supported. I saw the progress bar is moving, showing that the video is playing, however there is no video screen...


To clarify did you test the josh/demo or master branch of the
meta-demo repository?
I used josh/demo branch.

Thanks,
Dongxiao


Cheers,
Joshua


Re: Please verify the fixed bug in bugzilla.

Richard Purdie <rpurdie@...>
 

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&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
Just to remind people, who is responsible for verifying a bug? The
original reporter?

Cheers,

Richard


Re: zypper and poky architectures

Richard Purdie <rpurdie@...>
 

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.

This is natural until zypper is involved. Zypper supports only one arch
at one time (and this arch should not be changed in fly), and use the
idea of arch compatibility (e.g. _noarch is compatible with _i586), it
then hardcodes the available archs in a different way than poky does,
thus creating several problems:
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
2. the arch automatic detection system uses "uname -m", thus producing
armv5tejl, which can only be resolved as armv5tel, conflicting with
"armv5te" in rpm
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.

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?

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.

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.

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?

Cheers,

Richard


Re: UPnP demo - call for testing

Joshua Lock <josh@...>
 

On Wed, 2010-10-20 at 16:48 -0700, Darren Hart wrote:
On 10/20/2010 03:09 PM, Joshua Lock wrote:
On Wed, 2010-10-20 at 18:18 +0100, Joshua Lock wrote:
Hi all,

I've successfully tested the UPnP demo in my office but would appreciate
someone else taking a bash.

Unfortunately you currently need my branch from poky-contrib (josh/demo)
and the corresponding branch from meta-demo (josh/demo).
I've just pushed one change to poky/master and merged a tidied up
changeset into the master branch of meta-demo. So you should now be able
to test with latest poky and meta-demo master.

Cheers,
Joshua
I have added the COMMERCIAL_LICENSE bits to my local.conf and mediatomb
built after that.

building poky-image-rygel-live, gupnp-dlna do_configure is failing with:

configure: error: Package requirements (gstreamer-0.10 >=
0.10.29.2) were not met:

No package 'gstreamer-0.10' found

Have you seen that?
No, but I can see how it happened. Gstreamer isn't listed in
gupnp-dlna's DEPENDS and it's likely that gstreamer wasn't built before
gupnp-dlna configure was run - I have updated the gupnp-dlna recipe in
the meta-demo master branch.


Sorry about that!

Joshua
--
Joshua Lock
Intel Open Source Technology Centre