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

Mon Jun 18 17:57:57 UTC 2018

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.

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