On Thu, Feb 06, 2014 at 01:30:46PM +0100, Emmanuel Bourg wrote: > I've got some trouble with uscan when repacking the source zip [1] of > JavaMail. The file > 'mail/src/test/resources/javax/mail/internet/folddata' is altered in the > process. Its md5sum is 7ac9a5 in the source zip, and bbb321 in the > repacked tarball. > > After investigating it looks like the repacking replaced the \r\n line > terminators with \n, causing the unit tests to fail.
Daniel requested this in #618513. I felt a little unsure of it at the time, but acquiesced. Given the above effects, and re-reading the reasoning provided by cryptlib's upstream[0], I'm thinking it may be best to revert this. 0: To unzip the code under Unix use the -a option to ensure that the text files are converted to the Unix format. I don't see why this requirement is imposed by cryptlib. If the source he's distributing uses dos line endings, why shouldn't that be the form they're modified in? If someone on a Windows system creates a patch, their files are going to have dos line endings, not Unix, so I don't think that suggestion has anything to do with feeding patches back to upstream. It's likely just a tip for ensuring the line endings are “correct” for the user's OS, which, as I stated initially, is less likely to cause problems for *nix tools if they aren't. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <james...@debian.org>
signature.asc
Description: Digital signature
