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

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

[Paul Gortmaker]

After the uprev in: commit ad5d2ff6c782a3319aedc25cc641574e39328460
("xterm: 308 -> 320") I started getting this failure:

ERROR: QA Issue: xterm: Files/directories were installed but not shipped in any package:
  /usr/lib
  /usr/lib/X11
  /usr/lib/X11/app-defaults
  /usr/lib/X11/app-defaults/XTerm-color
  /usr/lib/X11/app-defaults/UXTerm
  /usr/lib/X11/app-defaults/UXTerm-color
  /usr/lib/X11/app-defaults/XTerm
  /usr/lib/X11/app-defaults/KOI8RXTerm-color
  /usr/lib/X11/app-defaults/KOI8RXTerm
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
xterm: 9 installed and not shipped files. [installed-vs-shipped]
ERROR: Fatal QA errors found, failing task.
ERROR: Function failed: do_package
ERROR: Logfile of failure stored in: /home/paul/poky/build/tmp/work/core2-64-overc-linux/xterm/320-r0/temp/log.do_package.4639
ERROR: Task 11 (/home/paul/poky/meta-openembedded/meta-oe/recipes-graphics/xorg-app/xterm_320.bb, do_package) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1056 tasks of which 858 didn't need to be rerun and 1 failed.

The fail can be avoided by the revert of one line that was in
the above commit, as which is done here.  Should there be a
desire to better absract out FILES_${PN} that can be done in
a separate follow on commit that is tested to confirm it does
not reintroduce this same build regression.

Cc: Li xin <lixin.fnst@cn.fujitsu.com>
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 meta-oe/recipes-graphics/xorg-app/xterm_320.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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() {
     oe_runconf
 }
 
-FILES_${PN} += "${libdir}/X11"
+FILES_${PN} += "/usr/lib/X11"
-- 
2.1.4

Re: [PATCH] xterm: revert FILES_PN change from recent package uprev

[Phil Blundell]

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.

p.

Re: [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.

Re: [PATCH] xterm: revert FILES_PN change from recent package uprev

[Phil Blundell]

On Sun, 2016-01-31 at 16:51 -0500, Paul Gortmaker wrote:
> 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.

I agree that this is confusing, and the way that poky merges all the
layers together into a single tree doesn't help.  But in fact I think
you were already 90% of the way there.  Once you've figured out that
this is part of meta-openembedded, you just need to consult the README
file in the appropriate subdir, for example:

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/README

(which, I assume, also shows up in your poky checkout although I haven't
checked this)

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

Not that I know of, but that sounds like a good idea.  Perhaps it could
be added to the layer index page:

http://layers.openembedded.org/layerindex/branch/master/layers/

p.

Re: [PATCH] xterm: revert FILES_PN change from recent package uprev

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

On 31 January 2016 at 21:51, Paul Gortmaker <paul.gortmaker@windriver.com>
wrote:

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

There is no meta-oe or meta-openembedded in poky.

Ross

[-- Attachment #2: Type: text/html, Size: 805 bytes --]

Re: [PATCH] xterm: revert FILES_PN change from recent package uprev

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

On 31 January 2016 at 19:56, Paul Gortmaker <paul.gortmaker@windriver.com>
wrote:

> -FILES_${PN} += "${libdir}/X11"
> +FILES_${PN} += "/usr/lib/X11"
>

Is xterm hard-coding /usr/lib/X11?  Should that be $prefix/lib/X11?  What
is the xserver itself looking in?  Is that actually using $libdir/X11 so
the xterm makefile is broken and should be patched?

Ross

[-- Attachment #2: Type: text/html, Size: 785 bytes --]

Re: [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 23:05) Burton, Ross wrote:

> 
> On 31 January 2016 at 21:51, Paul Gortmaker <paul.gortmaker@windriver.com>
> wrote:
> 
>     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.
> 
> 
> There is no meta-oe or meta-openembedded in poky.

A fair comment.  We'd needed the OE components to augment poky
functionality a long time ago, and scripted it to the point that I'd
just forgot it was automatic and where they came from.

Anyway, regardless where the components come from, there is value in
adding clarity to that, I think.

Thanks,
Paul.
--

> 
> Ross