Bodhi hash collision?
lmacken at redhat.com
Sat Feb 20 04:09:08 UTC 2010
On Sat, Feb 20, 2010 at 01:42:29AM +0100, Christian Krause wrote:
> Hi Luke,
> On 02/18/2010 10:08 PM, Luke Macken wrote:
> > On Thu, Feb 18, 2010 at 03:57:58PM -0500, Josh Kayse wrote:
> >> On 02/18/2010 02:35 PM, Jonathan Underwood wrote:
> >>> Hi,
> >>> I just logged into the bodhi web interface and clicked on "my
> >>> updates". In the list I see a recent package I pushed to testing -
> >>> shorewall-4.4.6-2.fc12. When I click on it, it takes me to a screen
> >>> for luckybackup-0.3.5-2.fc12. Something seems to have gone awry with
> >>> the hash generation or linking or something. I'd file a bug report but
> >>> I am not sure where the problem lies exactly. Any pointers?
> >>> Cheers,
> >>> Jonathan
> >> Both packages have the same Update ID. You can access your update
> >> by going to
> >> https://admin.fedoraproject.org/updates/shorewall-4.4.6-2.fc12
> > It looks like today's push started overlapping IDs... I'm looking into
> > it, and will reassign ID's once it is fixed.
> A couple of my updates suffer from the same problem. Is it still under
> investigation and should I just wait or should I report the specific
A large number of updates currently suffer from duplicate IDs, and I
need to figure out a clever way to fix it.
If you want some details as to how this happened...
Bodhi's PackageUpdate.assign_id method is insane, mainly to hack around
SQLObject shortcomings. This method apparently relied on the
PackageUpdate.date_pushed field *not* getting updated when an update
goes from testing->stable in order to determine the last ID assigned.
I recently made a change that updates this timestamp when a testing
update hits stable, and thus broke the id assignment algorithm (sadly,
not the test suite (which is up to 101 unit tests, btw)).
I'm working on a script to fix all of these duplicates at once, as well
as an improved ID assignment algorithm.
More information about the devel