On 9/22/11, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > On Wed, 2011-09-21 at 22:40 +0400, Dmitry Eremin-Solenikov wrote: >> I belive that "files were installed but not shipped in any package" >> message should become a fatal error. While it's true that sometimes some >> files are generated by do_install task, which aren't necessary for our >> target systems. However in generic I think this is a very important and >> usually overlooked QA sign. E.g. recently I've found/fixed some bugs in >> eglibc packaging only due to making this a fatal error. Sometimes new >> versions of a software add new files, but then they are sometimes >> ignored, as this messages can be easily missed. You can come with more >> examples if you'd like to. >> >> Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com> >> --- >> meta/classes/package.bbclass | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass >> index a9c510d..f4a535e 100644 >> --- a/meta/classes/package.bbclass >> +++ b/meta/classes/package.bbclass >> @@ -948,6 +948,7 @@ python populate_packages () { >> bb.warn("For recipe %s, the following files were installed but >> not >> shipped in any package:" % pn) >> for f in unshipped: >> bb.warn(" " + f) >> + bb.fatal("Unshipped files found") >> >> bb.build.exec_func("package_name_hook", d) > > One of thee post-release things I want to sort out is the QA warnings > and I add this warning under that category. We introduced the ideas of > warnings to error and warn on into the QA class already and I'd like to > be able to control this warning in that way using the same variables.
Nice idea! On the rights of a feature request: It would be nice to allow user to: 1) specify the severity of the QA problems (warn, error, fatal) on a global + per-qa-check level 2) specify an override for some of the checks, so that the packager can specify that e.g. QA check for .so links in a non-dev packages should be ignored for cgroups-pam package for /lib/security/pam*.so lib. (I get the idea from Debian lintian overrides. Hope I was able to write what I mean). > > Also, rather than being bb.fatal, this should be bb.error. An Error > message will allow the build to complete but will set the bitbake exit > code to show when errors have occurred. This means errors still light > the autobuilder up red when they occur so we're usually pretty good > about noticing and removing error messages. Hmmm. If it's a bb.error, is it logged somewhere except in the task log file? Because even if I see a red state in my oestats installation (BTW: what is the current way to track build statuses?), I don't think I'll be able to dig through multi-page oestats task output for some big image looking for erroneous-but-not-failed items. -- With best wishes Dmitry _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core