My Environment
| Software |
Version(s) |
| Operating System |
Fedora Rawhide |
jekyll |
4.2.1 |
github-pages |
No |
Expected Behaviour
I am the maintainer for the Jekyll package in Fedora.
Earlier Jekyll gems contained files with LR line endings.
The build script for creating the Fedora package
worked correctly with this setup.
My expectation when starting packaging 4.2.1
was that the line endings would still be LF.
Current Behavior
In 4.2.1 gem, files use CRLF linebreaks.
This broke the build script in various places:
- Patches applied with the
rpm %patch facility fail
with error "different line endings"
- Running
exe/jekyll --help (to generate some docs) fails
since the shebang is interpreted incorrectly
due to CR being there:
/usr/bin/env: ‘ruby\r’: No such file or directory
The script can be made to succeed
by converting line endings as needed.
Still, I am afraid this change can also have
other unexpected consequences.
The line endings are a brittle topic,
switching them in any direction
can cause all sorts of trouble.
I am not aware of any specific reason
to use LF instead of CRLF in gems.
Still, since there was I change,
I would first like to confirm that this was intentional
before adjusting the Fedora build script to handle this.
Code Sample
Snippet 1: Failing to apply a patch:
$ fedpkg mockbuild
...lots of output...
+ echo 'Patch #0 (0000-jekyll-commands-remove-bundle-install-step-for-new.patch):'
Patch #0 (0000-jekyll-commands-remove-bundle-install-step-for-new.patch):
+ /usr/bin/patch --no-backup-if-mismatch -f -p1 --fuzz=0
patching file lib/jekyll/commands/new.rb
Hunk #1 FAILED at 13 (different line endings).
Hunk #2 FAILED at 132 (different line endings).
2 out of 2 hunks FAILED -- saving rejects to file lib/jekyll/commands/new.rb.rej
patching file test/test_new_command.rb
error: Bad exit status from /var/tmp/rpm-tmp.vA9u1a (%prep)
...more lines about terminating the build...
Snippet 2: Failing to execute exe/jekyll:
$ fedpkg mockbuild
...lots of output...
+ help2man -N -s1 -o /builddir/build/BUILDROOT/rubygem-jekyll-4.2.1-1.fc36.x86_64/usr/share/man/man1/jekyll.1 /builddir/build/BUILDROOT/rubygem-jekyll-4.2.1-1.fc36.x86_64/usr/share/gems/gems/jekyll-4.2.1/exe/jekyll
help2man: can't get `--help' info from /builddir/build/BUILDROOT/rubygem-jekyll-4.2.1-1.fc36.x86_64/usr/share/gems/gems/jekyll-4.2.1/exe/jekyll
Try `--no-discard-stderr' if option outputs to stderr
error: Bad exit status from /var/tmp/rpm-tmp.G6uvuX (%install)
Bad exit status from /var/tmp/rpm-tmp.G6uvuX (%install)
...more lines about terminating the build...
That does not reveal what went wrong,
but runing exe/jekyll from the unpacked gem directly
reveals that the additional CR corrupts the shebang line:
$ exe/jekyll --help
/usr/bin/env: ‘ruby\r’: No such file or directory
My Environment
jekyllgithub-pagesExpected Behaviour
I am the maintainer for the Jekyll package in Fedora.
Earlier Jekyll gems contained files with LR line endings.
The build script for creating the Fedora package
worked correctly with this setup.
My expectation when starting packaging 4.2.1
was that the line endings would still be LF.
Current Behavior
In 4.2.1 gem, files use CRLF linebreaks.
This broke the build script in various places:
rpm%patchfacility failwith error "different line endings"
exe/jekyll --help(to generate some docs) failssince the shebang is interpreted incorrectly
due to CR being there:
/usr/bin/env: ‘ruby\r’: No such file or directoryThe script can be made to succeed
by converting line endings as needed.
Still, I am afraid this change can also have
other unexpected consequences.
The line endings are a brittle topic,
switching them in any direction
can cause all sorts of trouble.
I am not aware of any specific reason
to use LF instead of CRLF in gems.
Still, since there was I change,
I would first like to confirm that this was intentional
before adjusting the Fedora build script to handle this.
Code Sample
Snippet 1: Failing to apply a patch:
Snippet 2: Failing to execute
exe/jekyll:That does not reveal what went wrong,
but runing
exe/jekyllfrom the unpacked gem directlyreveals that the additional CR corrupts the shebang line: