[oe] [meta-xfce][PATCH] xfce4-panel: fix QA issue 'installed-vs-shipped'

[Khem Raj]

Hi Mark

It seems your distro is not inheriting it globally. Here I have
INHERIT_DISTRO ?=  "debian devshell sstate license remove-libtool"
On Mon, Jun 18, 2018 at 10:49 AM Mark Asselstine
<mark.asselstine at windriver.com> wrote:
>
> On Mon, Jun 18, 2018 at 1:15 PM, Mark Asselstine
> <mark.asselstine at windriver.com> wrote:
> > On Mon, Jun 18, 2018 at 1:07 PM, Mark Asselstine
> > <mark.asselstine at windriver.com> wrote:
> >> On Monday, June 18, 2018 12:51:47 PM EDT Andreas Müller wrote:
> >>> On Mon, Jun 18, 2018 at 4:45 PM, Mark Asselstine
> >>>
> >>> <mark.asselstine at windriver.com> wrote:
> >>> > Since commit 5f31db601408 [xfce4-panel: upgrade 4.12.2 -> 4.13.3] we
> >>> >
> >>> > are getting a QA Warnings/Erros for 'installed-vs-shipped':
> >>> >     ERROR: xfce4-panel-4.13.3-r0 do_package: QA Issue: xfce4-panel:
> >>> >
> >>> >     Files/directories were installed but not shipped in any package:
> >>> >       /usr/lib64/xfce4/panel/plugins/liblauncher.la
> >>> >       /usr/lib64/xfce4/panel/plugins/libdirectorymenu.la
> >>> >       ...
> >>> >
> >>> > From various OE documents the .la files should not be packaged in
> >>> > either the main recipe package or the -dev package unless required. So
> >>> > inherit 'remove-libtool' to have all the .la files cleaned up as they
> >>> > don't appear to be necessary.
> >>> >
> >>> > Signed-off-by: Mark Asselstine <mark.asselstine at windriver.com>
> >>> > ---
> >>> >
> >>> > This error is currently only seen on master-next since the xfce4-panel
> >>> > upgrade commit is yet to make it into master. As such this fix is only
> >>> > applicable to master-next.
> >>>
> >>> I think it was not the upgrade -> 4.13.3 commit but later commit / same
> >>> series
> >>>
> >>
> >> Sure, I can update the commit log and send a V2 but first let's sort out the
> >> remainder.
> >>
> >>> various classes recipes: Remove FILES entries for dbg/dev packages
> >>> ...
> >>> --- a/meta-xfce/classes/xfce.bbclass
> >>> +++ b/meta-xfce/classes/xfce.bbclass
> >>> @@ -12,11 +12,3 @@ DEPENDS += "intltool-native"
> >>>
> >>>  FILES_${PN} += "${datadir}/icons/* ${datadir}/applications/*
> >>> ${libdir}/xfce4/modules/*.so*"
> >>>  FILES_${PN}-doc += "${datadir}/xfce4/doc"
> >>> -
> >>> -FILES_${PN}-dev += "${libdir}/xfce4/*/*.la"
> >>> -FILES_${PN}-dev += "${libdir}/xfce4/*/*/*.la"
> >>> ...
> >>>
> >>> My builds have remove-libtool enabled so I did not see this QA
> >>> warning/error.
> >>>
> >>> Isn't remove-libtool enabled by default since pyro/2.3 - so that this
> >>> patch is obsolete (and all the other same kind coming later)?
> >>
> >> The documentation still indicates:
> >> ---
> >> <note>
> >>             The <filename>remove-libtool</filename> class is not enabled by
> >>             default.
> >> </note>
> >> ---
> >>
> >> So as far as I know this still needs to be handled recipe to recipe by
> >> inheriting the remove-libtool class in the affected recipes. I have done
> >> builds without manipulating the generated local.conf which seem to confirm
> >> this but I could be wrong. Add RP who might have some guidance.
> >>
> >> MarkA
> >
> > Just hit another one
> > ---
> > ERROR: gtk-xfce-engine-3.2.0-r0 do_package: QA Issue: gtk-xfce-engine:
> > Files/directories were installed but not shipped in any package:
> >  /usr/lib64/gtk-3.0/3.0.0/theming-engines/libxfce.la
> >  /usr/lib64/gtk-2.0/2.10.0/engines/libxfce.la
> > Please set FILES such that these items are packaged. Alternatively if
> > they are unneeded, avoid installing them or delete them within
> > do_install.
> > ---
> > Andreas, seeing as you didn't hit the 'installed-vs-shipped' QA issue
> > with thunar recipe I suspect the reason you didn't see this is not
> > related to remove-libtool but rather that you have disabled the
> > 'installed-vs-shipped' QA check itself.
>
> And xfce4-session now too. I found a reference from a few years back
> related to remove-libtool use on a per recipe basis
> (http://lists.openembedded.org/pipermail/openembedded-devel/2016-March/106323.html),
> so definitely some concerns being expressed using this on a per recipe
> basis. On the other hand this just seems like we are setting traps for
> ourselves. If we compare to another common class, rm_work, I can
> pretty much toggle rm_work on or off and recipes are expected to just
> work in either case. This is definitely not the case with
> remove-libtool which gives the impression of being optional but if not
> enabled and I do basic QA checks I will get failures, as is evident in
> my current build.
>
> MarkA
>
> >
> > MarkA
> >
> >
> >>
> >>>
> >>> Andreas
> >>
> >>
> >>
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-devel mailing list
> >> Openembedded-devel at lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel