| Summary: | Fail correctly in perform_checksum | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Greg Turner <gmturner007> |
| Component: | Core - External Interaction | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | gmturner007 |
| Priority: | Low | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 409383 | ||
| Attachments: |
Fail correctly when not finding the requested hash function in perform_checksum
Don't fail in the first place, and don't fail to not fail :) |
||
Created attachment 308835 [details, diff]
Fail correctly when not finding the requested hash function in perform_checksum
Obviously, begs the question of why function getsize is there in the first place... :) But there I start to feel like maybe my tree is at fault somehow so I'll leave that to those of you plugged into git. Created attachment 308839 [details, diff]
Don't fail in the first place, and don't fail to not fail :)
Fixes a bug in my previous patch and fixes the underlying problem for extra credit :)
^^ note: code works, but still failed to make convoluted witty comment correctly :) sorry, couldn't resist... Ill shut up now. Thanks, this is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ef19d0fba35b1fff37257b70b3bd7c77b0b4e845 This is fixed in 2.1.10.57 and 2.2.0_alpha101. |
Python 2.7 barfs on this code: raise FooException( hashname + " bar baz" ) See attached patch Reproducible: Always Steps to Reproduce: emerge -C dev-python/pycrypto python2.7 -c "from portage.checksum import perform_all; perform_all('/dev/null')" Actual Results: TypeError: unsupported operand type(s) for +: 'function' and 'str' Expected Results: portage.exception.DigestException: <function getsize at 0xffeaaed4> hash function not available (needs dev-python/pycrypto) Tested on slightly out-of-date prefix tree so... conceivably this is an out-of-date bug; even so -- the enclosed str()-based implementation is slightly more robust as evidenced by the above.