Conary has awesome features. One of them records the versions of the software used to build packages. This information is stored in the binary package's TroveInfo object. With it, we can evaluate our exposure to bugs in compilers, libraries, and tools.

For some reason, we've found that system databases are recording these build requirements in components too. This is not good. It means that the entry for the Trove object in the system database doesn't match the Trove object in the repository. This wasn't a huge problem until we started adding digital signatures to the Trove object this week.

If your system is affected, you will see a TroveIntegrityError when attempting an update. To see if your system has build requirement trove info stored for a component, run:

sqlite3 /var/lib/conarydb/conarydb "select instances.trovename from troveinfo, instances where infotype in (4, 5) and instances.trovename like '%:%' and troveinfo.instanceid=instances.instanceid;"

I'm collecting information about the data that's stored in these invalid entries. If the above command produced a list of troves, please run:

sqlite3 /var/lib/conarydb/conarydb "select trovename,hex(data) from troveinfo, instances where infotype in (4, 5) and instances.trovename like '%:%' and troveinfo.instanceid=instances.instanceid;" > /tmp/out

and send the output in /tmp/out to msw AT rpath.com.

To clean up your database, run:

sqlite3 /var/lib/conarydb/conarydb "delete from troveinfo where infotype in (4, 5) and instanceid in (select instanceid from instances where trovename like '%:%');"