[poky] non-upstreamed patches

[Richard Purdie]

On Sat, 2011-11-12 at 19:57 -0500, Colin Walters wrote:
> So I've switched back to looking at Yocto again for a project, and the
> Edison release works fine.  Thanks!

Pleased to hear it! :)

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

The Upstream-Status fields are relatively new and I think some of the
categorizations are perhaps not quite right or need to be interpreted
correctly. 

http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations

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

Taking this one as an example, someone has run into problems and fixed
it in a way that is certainly not appropriate for upstream as the patch
stands.

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

Totally agreed. We do have site cache files an a much better way of
handling that issue would be to add the value to the site cache. In an
ideal world I've have caught that patch and asked it to be a site entry,
it looks like its slipped through. I'll certainly take a site file entry
and change to drop the patch.

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

This is a mess of our own making :/. You'd probably get a bit of a shock
if you look at our gtk-doc recipe. Since we reautoconf files, we need
the gtk-doc .m4 file. We just provide a static copy of it. To handle the
makefile, we just touch that.

I have a suspicion that EXTRA_DIST exists if you use the gtk-doc
makefile and hence appending to it is a good idea and hence that patch
truly is inappropriate for upstream.

In many cases we've learnt from our experiences and instead of touching
the makefile, we echo EXTRA_DIST = "" to it instead (or similar).

Ultimately I'd like to see a fixed gtk-doc recipe. It was so long ago I
last tried that I can't remember what issues we found.

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

That would be a nice change to get upstream. The current patch is
inappropriate but I'm sure we could create one that could be accepted.

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

Good question, I think I might tried that and had some kind of problem
but if that did would it would be great to see it upstream too.

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

If its been filed there should be links. "Pending" can also mean "needs
to be submitted upstream". As I said, this is a relatively new thing, we
used to have no information in the patches at all so it is getting
better. We're making progress although never as fast as we would in an
ideal world! :)

Any help would be appreciated, the reminders above are helpful as there
does appear to be some low hanging fruit there. Also the pointers on
which ones might make it into gnome upstream are useful!

Cheers,

Richard