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

Mon Jun 18 18:09:23 UTC 2018

On Mon, Jun 18, 2018 at 1:57 PM, Khem Raj <raj.khem at gmail.com> wrote:
> On Mon, Jun 18, 2018 at 10:54 AM Mark Hatle <mark.hatle at windriver.com> wrote:
>>
>> On 6/18/18 12:50 PM, Khem Raj wrote:
>> > Hi Mark
>> >
>> > It seems your distro is not inheriting it globally. Here I have
>> > INHERIT_DISTRO ?=  "debian devshell sstate license remove-libtool"
>>
>> So is remove-libtool a recipe or a distro option?
>>
>> I'm asking because doing this half-way is causing a lot of confusion.
>>
>> If it's a distro option, then the recipes should work without it being set.  If
>> it's a recipe option, then the recipes that need it should use it.
>>
>> Right now it doesn't seem to be working with these recipes because they don't
>> package the .la files UNLESS it's enabled.  So the fix is either to package them
>> (by default) or inherit the remove-libtool.
>>
>
> since we make it as part of meta/conf/distro/defaultsetup.conf
> its a default policy,  its perfectly fine for a distro to disregard that
> however, then you fall into a non-default case. I am willing to accept
> per recipe patches but I would recommend to consider it as a distro
> feature for your distro.
>

Andreas,

Can you revert your "various classes recipes: Remove FILES entries for
dbg/dev packages" then? If this is a distro feature then these recipes
need to build without the QA issue and without the remove-libtool
distro feature being set.

MarkA

>> --Mark
>>
>> > 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
>>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel