Op 30 jun 2011, om 17:33 heeft Paul Eggleton het volgende geschreven: > On Thursday 30 June 2011 16:11:29 Koen Kooi wrote: >> These were turned off by: >> >> commit fae8d5e985e9b05ce90f1eca434ad4dbf2259725 >> Author: Richard Purdie <rpur...@linux.intel.com> >> Date: Thu Jul 8 23:51:06 2010 +0100 >> >> insane.bbclass: Relax fatal errors for now until we get have >> time to > work >> through the backlog >> >> The current metadata triggers so many of these that they need to be made >> fatal so people will actually fix them. > ... >> return not error_class in [0, 5, 7, 8, 9] > > So in principle I can agree that making these fatal again will make people > sort out the problems that they are flagging up. However, why is class 7 - > .desktop files being "invalid" - a fatal error, considering there are many > sub- > classes of "invalidity" being tested for with varying levels of significance? > > (This has probably been discussed on the OE list before but IMHO it merits > revisiting if so.)
It's a white list, so: # 0 - non dev contains .so # 5 - .la contains installed=yes or reference to the workdir # 7 - the desktop file is not valid # 8 - .la contains reference to the workdir # 9 - LDFLAGS ignored Are warnings and # 1 - package contains a dangerous RPATH # 2 - package depends on debug package # 3 - non dbg contains .so # 4 - wrong architecture # 6 - .pc contains reference to /usr/include or workdir # 10 - Build paths in binaries # 11 - package depends on devel package Are fatal errors. The splits seems arbitrary to me, but it that's how it was last year before RP disabled all fatal errors. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
