[OE-core] [PATCH] xterm: revert FILES_PN change from recent package uprev

[Paul Gortmaker]

[Re: [OE-core] [PATCH] xterm: revert FILES_PN change from recent package uprev] On 31/01/2016 (Sun 20:45) Phil Blundell wrote:

> On Sun, 2016-01-31 at 14:56 -0500, Paul Gortmaker wrote:
> > diff --git a/meta-oe/recipes-graphics/xorg-app/xterm_320.bb b/meta-oe/recipes-graphics/xorg-app/xterm_320.bb
> > index f67d890abcae..10b75fca32db 100644
> > --- a/meta-oe/recipes-graphics/xorg-app/xterm_320.bb
> > +++ b/meta-oe/recipes-graphics/xorg-app/xterm_320.bb
> > @@ -27,4 +27,4 @@ do_configure() {
> 
> This file doesn't exist in oe-core.  I think you must have sent this
> patch (and the inetutils one, to which the same applies) to the wrong
> mailing list.

Of course you are right.  In my defense, in poky, the full path is
meta-openembedded/meta-oe/<....> and with two references in the path to
OE, I think I can't be the only one consistently getting confused like
this.

Both the Yocto mailing list summary:

https://www.yoctoproject.org/tools-resources/community/mailing-lists

and the OE list summary:

http://lists.openembedded.org/mailman/listinfo

are lacking path info that would help me out to get the right list.

If i go into poky/meta-openembedded, and crack open .git/config I'll see
the source git://git.openembedded.org/meta-openembedded listed.  So I
think at least at that point, I need to look at OE lists and not yocto
lists.  But looking the 2nd link above I'm still none the wiser where in
OE the xterm patch needs to be sent to, and OE-core looks right until I
clone core and find the file simply isn't there.

What is the mailing list decoder secret that I'm missing here?  If I'm
looking at the web pages and even the .git/config and I still get it
wrong, then I think I must be missing something obvious.

My best guess at the moment is oe-devel, but that is only because I
cheated and looked at the archive and found meta-networking patches
sent there.

Is there a 1:1 mapping between mailing lists <---> git://<server>/<path>
out there, since I think that would help.  And/or maybe a get_maintainer
script like the kernel has.

Thanks,
Paul.