Paul Eggleton 0947ec0a65 rrs_upgrade_history: handle broken version numbers ... In OE-Core revision e0531174119bff21e9014b95ed1bbd0e1c01af26 we accidentally committed a new e2fsprogs recipe with ..bb at the end of its name instead of .bb. This was fixed immediately afterwards, but when the RRS hits this commit, it doesn't fail immediately, but the bogus version "1.43." gets into the database and all subsequent commits touching the e2fsprogs recipe cause bb.utils.vercmp_part() to blow up because one of the version parts in the "previous" version in the database is apparently empty. To work around this and any similar issues, just reject any change that results in such a broken version string (on the assumption that it'll be corrected in a subsequent commit and thus we will get to re-parse the recipe then and therefore not miss the upgrade.) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>		2018-05-04 23:57:53 +12:00
..
common.py	rrs/tools/common.py: ensure we pass a string to loadDataFull()	2018-05-04 23:57:53 +12:00
daily_run.sh	rrs/tools/rrs_unique_recipes: drop	2018-05-04 23:57:52 +12:00
rrs_distros.py	rrs/tools: run all tools scripts with python3	2018-05-04 23:57:53 +12:00
rrs_maintainer_history.py	rrs/tools: use layer index lock	2018-05-04 23:57:53 +12:00
rrs_upgrade_history.py	rrs/tools: use layer index lock	2018-05-04 23:57:53 +12:00
rrs_upstream_email.py	rrs/tools: run all tools scripts with python3	2018-05-04 23:57:53 +12:00
rrs_upstream_history.py	rrs/tools: use layer index lock	2018-05-04 23:57:53 +12:00
upgrade_history_internal.py	rrs_upgrade_history: handle broken version numbers	2018-05-04 23:57:53 +12:00