On Mon, Jun 18, 2018 at 1:15 PM, Mark Asselstine <mark.asselst...@windriver.com> wrote: > On Mon, Jun 18, 2018 at 1:07 PM, Mark Asselstine > <mark.asselst...@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.asselst...@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.asselst...@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@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel