non-upstreamed patches

[Colin Walters <walters@verbum.org>]

So I've switched back to looking at Yocto again for a project, and the
Edison release works fine.  Thanks!

I work on GNOME (almost all of it), and I see quite a number of patches
in the Yocto tree that I think have been inappropriately categorized as
Upstream-Status: Inappropriate.

For example,
recipies-core/glib-2.0/glib-2.0/remove.test.for.qsort_r.patch

We definitely want upstream GLib to work for cross builds.  It was my
understanding that the better way to handle autoconf checks that require
running code was to pass a precomputed cache file:
http://www.gnu.org/s/hello/manual/autoconf/Site-Defaults.html

I think this makes sense to do for fundamental libraries like GLib;
hacking up the configure.ac isn't a good long term plan.

Another thing that seems to be proliferating is gtk-doc workarounds.  If
it isn't working for you guys to --disable-gtk-doc, just tell me why and
I'll fix it.

(The -Werror bit there is a total fuckup on our part, I will eventually
convince Owen to remove it...)

librsvg/librsvg-2.31.1/doc_Makefile.patch is also TOTALLY appropriate
upstream.  Why would you think it isn't?

gtk+/gtk+-2.24.6/run-iconcache.patch is another cross build issue that
I'm pretty sure we can solve better upstream.  gtk+ for example already
has an automake conditional:
AM_CONDITIONAL(CROSS_COMPILING, test $cross_compiling = yes)

We can just not run this code if that's true.

(And I am totally fine with just copying that conditional into every
single GNOME module).

hardcoded_libtool.patch is another one I think we can get upstream in a
better way; shouldn't it just be using $LIBTOOL ?

Finally, on the Upstream-Status: pending patches, can you guys please
add links to bugzilla?

Thanks!