file "copyrigh" is created and produces lintian error

[nerdoc]

I created a package, and used the "Generate Simple Template" button. Changed the name/email and saved my project. After creating the .deb, lintian told me that:

[...]
E: eurolyser: md5sums-lists-nonexistent-file usr/share/doc/eurolyser/copyrigh
W: eurolyser: file-missing-in-md5sums usr/share/doc/eurolyser/copyright

There is the "t" missing at the end of "copyrigh" - I think there is the problem why lintian is not finding the file.
Could it be that debreate snips away the last letter? There is nothing to configure about the copyright notice file - I suppose the bug is in the code somewhere.

How can I help?
Here is my eurolyser.dbp.txt file (extension changed to .txt for uploading at Github - please remove the .txt)

[AntumDeluge]

You are probably right. It is most likely in the code. I will try to have a look at it tonight.

[AntumDeluge]

The problem is that Lintian is not reading the last character of md5sums file. It appears that it expects the last character of the file to be an empty newline. Debreate's function WriteFile by default strips all trailing newlines when it writes to a file. The solution is simple: Just disable stripping newline characters for writing the md5sums file.

Thank you for the report. I will get this fixed & try to get a new release out soon.

[AntumDeluge]

Created a new development release. PPA packages should be available soon.

[nerdoc]

A CR (or CR/LF in Windows) is a line terminator, not a line delimiter. So the last line should be terminated by a CR.
OTOH, lintian has a bad habit here "stripping" the last character...?

[AntumDeluge]

It appears that Lintian simply excludes the final character of a file when read. It assumes that the final character of the file will be a newline character (simply LF for Unix line endings, which is what Debreate uses when it writes out to a file). So, when Debreate was stripping newline characters from the end of the file, Lintian would read it but still ignore the final character (which in your case was "t"). So it would read in the md5sums file that usr/share/doc/eurolyser/copyrigh should exist because it ignored that final character.

I assume that if the file was using Windows line endings (CR/LF) it would still read the file fine, as long as the file ended in a new line. It would just ignore the LF character & probably read the CR character.

The fix that I made simply ensure that when the md5sums file is written, it is terminated with the LF character. And Lintian will read everything before that. It's a flaw in Lintian in my opinion. But, not a big deal.

[AntumDeluge]

Should be fixed with commit 3e3a955