On Sun, 12 Aug 2012 22:57:41 +0100, "Adam D. Barratt" writes: >Ping?
sorry for the late response: after digging through this a few more times i've got an explanation for the debdiff output. in 0.2.0-1 there were some local changes to vmm, precisely the ones that debdiff reports now (in reverse): ie. the change from Number::Bytes::Format to Number::Format and the VMware::VIRuntime loading in eval. for 0.2.0-2 i renamed vmm to vwm, and adjusted the inline pod sections to reflect that name change. nothing else was modified. the problem is that the debian diff doesn't represent file deletions, and that i rather should have left the vmm filename intact and just installed it with its new name via debian/rules (hindsight and all that). net effect: a newly unpacked 0.2.0-2 includes the correct vwm file, but also a superfluous and unused vmm file from the orig tarball, which of course reflects only the state before the -1 changes were made. what's the verdict? upload a new version -3 that avoids the filename changes and concomitant spurious difference reports, or accept the current status with vmm(from -1) identical modulo doc changes to vwm(from -2) and ignore the unnecessary vmm(from orig tarball)? regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ When you understand UNIX, you will understand the world. When you understand NT....you will understand NT -- R. Thieme
signature.asc
Description: Digital Signature