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

[Mark Asselstine]

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