On Mon 2015-11-16 02:52:49 -0500, Emmanuel Bourg wrote: > Another point worth considering, uscan doesn't apply a filter equivalent > to 'unzip -a' to .tar.gz archives, so for consistency I'd argue that it > shouldn't do it for zip archives either and unpack the files as is.
fwiw, my initial concern was gutmann's cryptlib. But alas, i don't think cryptlib is suitable for debian, for a number of reasons: https://www.debian-administration.org/users/dkg/weblog/74 So please don't make this consideration for debian based on any particular cryptlib idiosyncracies. however... > I realize I didn't explain in my initial report why the transformation > of the files was an issue for javamail. The file affected [1] is > involved in a test case that is sensitive to the line endings [2]. Most > of the lines in folddata end with \n, but a few of them are terminated > by \r\n to cover some corner cases with different line endings. The > transformation performed by uscan alters folddata and causes the test to > fail. By definition, it sounds to me like javamail is providing bad data if they distribute this as a pkzip file. Given that the pkzip format has the semantics for how line endings should be treated, if it really needs these line endings to be byte-for-byte identical for the tests to succeed, it should mark the file in question as a binary file, not a text file. --dkg
