Hi, during our development process, many of our recipes use AUTOREV to get
latest bits
Under warrior ( bitbake 1.42?) , we are seeing failures with the follow
structure
( from recipes not even used by the image, which recipe changes from bitbake to
bitbake)
Traceback (most recent call last):
File
"/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/fetch2/__init__.py",
line 1179, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at
0x7f43640bdc88>, d=<bb.data_smart.DataSmart object at 0x7f4364111588>,
name='default'):
if srcrev == "AUTOINC":
> srcrev = ud.method.latest_revision(ud, d, name)
File
"/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/fetch2/__init__.py",
line 1574, in Git.latest_revision(ud=<bb.fetch2.FetchData object at
0x7f43640bdc88>, d=<bb.data_smart.DataSmart object at 0x7f4364111588>,
name='default'):
except KeyError:
> revs[key] = rev = self._latest_revision(ud, d, name)
return rev
File
"/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/persist_data.py",
line 60, in SQLTable.wrap_func(*args=('XXXt',
'1a969ebe1841690d0c5c36c174aa119175c90cd6'), **kwargs={}):
try:
> return f(self, *args, **kwargs)
except sqlite3.OperationalError as exc:
File
"/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/persist_data.py",
line 89, in SQLTable.wrap_func(*args=(XXX',
'1a969ebe1841690d0c5c36c174aa119175c90cd6'), **kwargs={}):
with contextlib.closing(self.connection.cursor()) as
cursor:
> return f(self, cursor, *args, **kwargs)
return wrap_func
File
"/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/persist_data.py",
line 197, in SQLTable.__setitem__(cursor=<sqlite3.Cursor object at
0x7f4364180ab0>, key= XXX't', value='1a969ebe1841690d0c5c36c174aa119175c90cd6'):
else:
> cursor.execute("INSERT into %s(key, value) values (?, ?);" %
self.table, [key, value])
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was
${@bb.fetch2.get_srcrev(d)} which triggered exception IntegrityError: UNIQUE
constraint failed: BB_URI_HEADREVS.key
Most times , no problems
If I set BB_SRCREV_POLICY = "cache" , never a problem..
When bitbake on a ubuntu, the error is created and bitbake recovers
On a Centos, the error is created AND bitbake HANGS ( A Ctrl C will break into
the bitbake , but leaves a set of processes in memory, need to manually kill
the bitbake process and all its' children processes,
- this behavior makes centos for warrior bitbaking pretty useless .
Wondering if others are seeing this?
If so, any known 'fixes' (besides not using AUTOREV ?)
If so, will this get fixed in 'warrior' or later?
Thanks
Richard C Allen
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
