On Mon, Jun 18, 2018 at 10:54 AM Mark Hatle <[email protected]> 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 > > <[email protected]> wrote: > >> > >> On Mon, Jun 18, 2018 at 1:15 PM, Mark Asselstine > >> <[email protected]> wrote: > >>> On Mon, Jun 18, 2018 at 1:07 PM, Mark Asselstine > >>> <[email protected]> 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 > >>>>> > >>>>> <[email protected]> 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 <[email protected]> > >>>>>> --- > >>>>>> > >>>>>> 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 > >>>> [email protected] > >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel > >> -- > >> _______________________________________________ > >> Openembedded-devel mailing list > >> [email protected] > >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
