What you see here is the first 6 digits of the RMD160 sum for dev-python/pycrypto/metadata.xml generated on different platforms: alpha amd64 ia64 x86 2.0 b0aeda 11aff8 11aff8 b0aeda 2.0-r1 b0aeda 11aff8 11aff8 b0aeda 2.0.1 b0aeda b0aeda 11aff8 b0aeda 2.0.1-r1 b0aeda b0aeda 11aff8 b0aeda So it appears that alpha is fine, amd64 was fixed in 2.0.1, and ia64 is still broken. Looking at RIPEMD.c, I think the programmers don't realize that "int" means 32-bits according to the C standard, and "long" means native size of a pointer: #ifdef __alpha__ typedef unsigned int word; /* unsigned 32-bit integer */ #elif defined(__amd64__) typedef uint32_t word; /* unsigned 32-bit integer */ #else typedef unsigned long word; /* unsigned 32-bit integer */ #endif IMHO this should simply be: typedef unsigned int word; /* unsigned 32-bit integer */ For the moment, rather than rock the boat, I've added a patch to make ia64 work correctly, see pycrypto-2.0.1-r2. However I think the existing code is going to have problems on any 64-bit architectures not specifically handled.
Btw, I assigned this to dev-portage because it affects Manifest generation. Feel free to reassign it as appropriate. Mainly I'm looking for somebody to agree or disagree with my assessment, then push it upstream
> Looking at RIPEMD.c, I think the programmers don't realize that "int" > means 32-bits according to the C standard, and "long" means native size of a > pointer: it is usually safe to assume int is 32bits, but that isnt good programming imho > IMHO this should simply be: > > typedef unsigned int word; /* unsigned 32-bit integer */ if you want 32bits, then you should use the uint32_t def
The proper fix ought to be to use uint32_t for all architectures. I can confirm the bug on my ia64 machine: # emerge -uD world Calculating world dependencies ...done! >>> emerge (1 of 3) sys-libs/timezone-data-2006a to / !!! Digest verification Failed: !!! /usr/portage/sys-libs/timezone-data/timezone-data-2006a.ebuild !!! Reason: Failed on RMD160 verification !!! Got: 76142fd7417cdb675bc0a6f5d34b4979ed451237 !!! Expected: 688734ae4535c63334dabac100df4faef08ee990 BTW: Is there any way to get portage to ignore RMD160 sums?
> BTW: Is there any way to get portage to ignore RMD160 sums? remove the RMD160 line from the digest file
> > BTW: Is there any way to get portage to ignore RMD160 sums? > > remove the RMD160 line from the digest file ... and the Manifest file, and update all the other sums since the files have changed... That's doable for an ebuild or two, but not much more.
(In reply to comment #3) > The proper fix ought to be to use uint32_t for all architectures. > > I can confirm the bug on my ia64 machine: > > # emerge -uD world > Calculating world dependencies ...done! > >>> emerge (1 of 3) sys-libs/timezone-data-2006a to / > > !!! Digest verification Failed: > !!! /usr/portage/sys-libs/timezone-data/timezone-data-2006a.ebuild > !!! Reason: Failed on RMD160 verification > !!! Got: 76142fd7417cdb675bc0a6f5d34b4979ed451237 > !!! Expected: 688734ae4535c63334dabac100df4faef08ee990 > > BTW: Is there any way to get portage to ignore RMD160 sums? > Not to be recommended lightly, but FEATURES="-strict" should do it also.
(In reply to comment #6) > (In reply to comment #3) > > BTW: Is there any way to get portage to ignore RMD160 sums? > > > > Not to be recommended lightly, but FEATURES="-strict" should do it also. and or.. emerge --digest foo
(In reply to comment #3) > BTW: Is there any way to get portage to ignore RMD160 sums? Editing /usr/lib/portage/pym/portage_checksum.py, and commenting out the line hashfunc_map["RMD160"] = rmd160hash seems to do the trick.
So, we have a universal fix and now the question is who's going to fix the package?
if Aron doesnt commit a "final" fix, i'll take care of it ...
It's in as 2.0.1-r3
