On Mon, Jun 18, 2018 at 1:57 PM, Khem Raj <[email protected]> wrote: > 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. >
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 >> > <[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 -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
