On 21 January 2013 15:57, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> There is a trend at the moment to remove things from OE-Core. That is
> well and good but the question is where to draw the line. I do want to
> ensure we keep at least some cross section of software in the core so
> that the core can be stressed in a variety of environments.
>
> I'm not saying gupnp shouldn't move out however I do want to figure out
> what is going to stay in the core that we can test with. Obviously
> things remaining the core really do need end user apps that we can
> stress them with.
>
> I was a little sad to see gthumb being removed for example as we now
> have no image viewer in the core. It was also a larger gtk app so
> stressed more of that side of the apis. I took the patches as it
> probably does belong in meta-gnome. How do we test the various image
> decoding libraries are in fact working though?

On the whole, agreed.

Regarding image decoding, were QA actually testing the decoding
libraries in gthumb?  If we want to verify that libpng/libjpeg/etc
work then there are many options that don't involve a desktop image
editor and looking at the screen as that doesn't catch subtle decoding
problems.  This can be part of the automated tests - decode a sample
PNG, md5 the raw data, compare with reference md5sum.

Regarding GUPnP, as fond of it as I am, we were only compile-testing
it in world builds.  Who knows if the libraries were actually worked
because it was never actually linked to.  Now that it and related
projects have a new home we need to work with community members who
also use GUPnP to ensure that there is one canonical location, even if
they prefer to work with copies of the recipes instead of including
meta-oe (which is understandable).

Ross

_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to