11896 2017-08-04 09:51:29 +0000 checkpkg needs to have exemption in metadata 2017-08-17 10:31:56 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.4 x86 Multiple RESOLVED FIXED Medium+ normal 2.4 M3 1 ross.burton alex.kanavin meta.mr.watcher meta.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 75646 0 ross.burton 2017-08-04 09:51:29 +0000 The checkpkg selftest has to maintain a separate list of recipes that can't pass checkpkg's upgrade testing. This isn't scalable to other layers as there is only a single exception list. The checkpkg logic should have a variable that recipes can set to exclude themselves from the upgrade check. This will speed up checkpkg, and allow tooling to tell between "couldn't tell if there is an upgrade" and "we cannot tell if there is an upgrade" (where the former could be fixed or be transient network failure). 75684 1 alex.kanavin 2017-08-07 10:23:51 +0000 I think there is a need for two per-recipe variables actually: UPSTREAM_CHECK_UNKNOWN - set if the upstream check fails reliably, e.g. absent git tags, or weird versions used on our or on upstream side. The upstream check test will treat this the same way it treats the exception list now - mismatches both ways will be reported as failures. UPSTREAM_CHECK_UNRELIABLE - set if the upstream check cannot be reliably performed due to transient network failures, or server behaving weirdly. This one should be used sparingly, as it completely excludes a recipe from upstream checking. The upstream check test will never fail. Agree? 75765 2 ross.burton 2017-08-09 10:55:45 +0000 That seems reasonable, yes.