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>
This commit is contained in:
Paul Eggleton 2018-03-27 15:59:22 +13:00
parent 291f6bfde7
commit 0947ec0a65

View File

@ -62,6 +62,10 @@ def _create_upgrade(recipe_data, layerbranch, ct, title, info, logger, initial=F
pn = recipe_data.getVar('PN', True)
pv = recipe_data.getVar('PV', True)
if '..' in pv or pv.endswith('.'):
logger.warn('Invalid version for recipe %s in commit %s, ignoring' % (recipe_data.getVar('FILE', True), ct))
return
recipes = Recipe.objects.filter(pn=pn, layerbranch=layerbranch).order_by('id')
if not recipes:
logger.warn("%s: Not found in Layer branch %s." %