Renaming the 1.2.4 (not the 1.2.4-r1 !) ebuild works fine. NOTE: the fix for
wrong md5 generation on amd64 is in the official source, this is the reason
that 1.2.4-r0 and not 1.2.4-r1 should be used as a prototype.
George
Created an attachment (id=110049) [details]
new version out: dcfldd/dcfldd-1.3.4.1.ebuild
Actually another version is out by now (released Dec 2006), by the versioning
looks like some "minor bugfox" which, according to the website, is:
Fixed an issue with error-producing blocks not being zero padding under BSD
systems.
The ebuild is attached. The only change (from 1.2.4-r0) is that ~amd64 is
readded to KEYWORDS and versionator is inherited and replace_version_separator
is used to mangle version string (since upstream decided on a fancy version
number of 1.3.4-1).
Indeed a "diff -ru" between 1.3.4 and 1.3.4-1 sources shows only this:
--- dcfldd-1.3.4/work/dcfldd-1.3.4/copy.c 2006-01-05 23:47:12.000000000
+0100
+++ dcfldd-1.3.4.1/work/dcfldd-1.3.4-1/copy.c 2006-12-14 22:58:57.000000000
+0100
@@ -266,11 +266,15 @@
print_stats();
/* Seek past the bad block if possible. */
lseek(STDIN_FILENO, (off_t) input_blocksize, SEEK_CUR);
- if (conversions_mask & C_SYNC)
+ if (conversions_mask & C_SYNC) {
/* Replace the missing input with null bytes and
proceed normally. */
+ // EXPERIMENTAL: let's try re-zeroing this buffer
+ memset((char *) ibuf,
+ (conversions_mask & (C_BLOCK | C_UNBLOCK)) ? ' ' :
'\0',
+ input_blocksize);
nread = 0;
- else
+ } else
continue;
} else {
/* Write any partial block. */
So, I'd say it is safe to assume that 1.3.4-1 is the latest working version,
especially assuming that it is marked stable by upstream.
George
