[csw-users] md5 hash for CSWgtkengines-2.20.2, REV=2011.03.08 possibly incorrect in dublin catalog?

[Maciej (Matchek) Bliziński]

2013/4/9 sean walmsley <spwalmsley at yahoo.ca>:
> After setting up cryptographic verification as per the getting started page,
> my new install of packages from the "dublin" catalog stops with the
> following message:
>
> => Fetching CSWgtkengines-2.20.2,REV=2011.03.08 (716/749) ...
> MD5 for CSWgtkengines-2.20.2,REV=2011.03.08 doesn't match catalog!
>
> The previous 715 package hashes seem to match, so I think I've set the
> verification up correctly.
>
> To check the hash, I manually downloaded the file and calculated the md5
> hash from the gzipped package file as follows:
>
> digest -a md5 gtk_engines-2.20.2\,REV\=2011.03.08-SunOS5.9-sparc-CSW.pkg.gz
> d227942517c1e77679a09235779e1aff
>
> This *IS* different from the catalog value which is:
>
> 6f872fd0e79c7a0b5f03dd0a205ebc43
>
> To check my methodology I calculated the hash for the gtk_doc package and
> got the same value as in the catalog.
>
> Is the catalog hash for gtk_engines incorrect, or has the file in the
> repository perhaps been corrupted? Or, perhaps I'm just missing something
> :-(
>
> Any assistance you can provide would be greatly appreciated.

I looked at the catalog and indeed there is a discrepancy. Following a
few more leads, I looked into the package database:

http://buildfarm.opencsw.org/pkgdb/catalogs/dublin-sparc-SunOS5.10/

...which says that 6f872fd0e79c7a0b5f03dd0a205ebc43 should be in the
catalog. However, if we look as all packages with the "gtk_engines"
catalogname...

http://buildfarm.opencsw.org/pkgdb/catalognames/gtk_engines/

...we see, that there are two distinct packages, as in different data,
with the same version! They have identical file names, but different
contents. Unfortunately, this means that the previous file has been
overwritten, and we only have the file with contents hash
d227942517c1e77679a09235779e1aff.

Our current options are:

- find a copy of 6f872fd0e79c7a0b5f03dd0a205ebc43 and replace the file on disk
- ascertain if d227942517c1e77679a09235779e1aff is a good package to
be in the catalog, and modify the database to list it as a catalog
member

Finding 6f872fd0e79c7a0b5f03dd0a205ebc43 might not be easy.

We also need to figure out what scenario caused this. I'm guessing
that it was caused creating two different files with the same name and
uploading them to the catalog. I'll need to look what exactly happens
when you do that and whether we can put in some safeguards against it.

Maciej