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