End of line encoding

[malcolmlewis]

Hi When building on the openSUSE Build Service for Tumbleweed I get end of line encoding warnings as follows;

[   58s] perl-PDF-Builder.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/packages/perl-PDF-Builder/CONTRIBUTING
[   58s] perl-PDF-Builder.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/packages/perl-PDF-Builder/examples/resources/pod2htmd.temp
[   58s] perl-PDF-Builder.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/packages/perl-PDF-Builder/examples/resources/sample.txt
[   58s] This file has wrong end-of-line encoding, usually caused by creation or
[   58s] modification on a non-Unix system. It could prevent it from being displayed
[   58s] correctly in some circumstances.

Can these files be cleaned up for the next release?

[PhilterPaper]

Are those definitely the only files with a problem, or was only a subset of files examined? A quick look at a recent CPAN package looks like there are a number of other text files in DOS mode (CRLF line-ends, which I assume that is what the complaint is). I'm kind of surprised it didn't complain about any other files.

Those three files would be easy enough to fix for the next release (although I have to check the examples that rely on sample.txt to be sure it can handle Unix-style line-ends -- I think that part of the intent is that a given file be displayable across multiple platforms). If it's a more general problem, I'll have to take a closer look at the build process.

[malcolmlewis]

Hi Those where the only ones reported. I initially ran a sed over all the files to clean up, but failed the tests, so just fixed those ones and passed all tests.

[PhilterPaper]

What exactly is the objective here? I can see objecting to what are supposed to be human-readable files (such as CONTRIBUTING) not being easily displayed on your system (though if I "fix" them for Unixy systems, I have to make sure they don't become unusable on Windows systems, etc.). Is some tool going through and picking files that look like human-readable text, and raising the alarm if their lines don't have the expected local line-end? What are you trying to accomplish here?

If it's just those three files, at most, it shouldn't be a problem. I just don't want to either 1) overlook a bunch more that should be changed, OR 2) break a bunch of files by changing them unnecessarily. Plus, after installation and testing, only the lib/ directory is going to be around. Some of the other files show up only on CPAN and other such meta-listings -- is that what you're aiming for? Developers should keep the whole install directory set around so they can run the examples/, contrib/, and so on, and read the LICENSE, etc.

[malcolmlewis]

Hi Only to remove the warnings thrown by the rpmlint report that runs when built on the openSUSE Build Service, I'm just try getting this package into the openSUSE Distribution as it's a dependency for gscan2pdf I maintain.

If you can fix the human-readable one, that would be appreciated, we can ignore the others, and add a note it's a won't fix in the spec file to keep the package reviewers happy :)

[PhilterPaper]

I'll see what I can do. Certainly, various "types" of files should be consistent in their format, but some need to be of a certain format (e.g., DOS CRLF). This is the first complaint I've received about formats, so SuSe must be fairly strict about such things, compared to other packagers.

[PhilterPaper]

OK, I have gone through and modified the build so that the three files you listed, plus a handful of other human-readable text files, will now be "unix" format (not MSDOS). I did not touch binary and mixed-binary (e.g., PDF) files. You should see this in release 3.022 by the end of the month.