On Sun, 12 Aug 2012 08:08:38 +0900, John Marino
<dragonflybsd%marino.st@localhost>
wrote:
On 8/11/2012 21:38, Thomas Klausner wrote:
On Sat, Aug 11, 2012 at 05:34:05PM +0000, John Marino wrote:
Module Name: pkgsrc
Committed By: marino
Date: Sat Aug 11 17:34:05 UTC 2012
Modified Files:
pkgsrc/editors/Sigil: distinfo
pkgsrc/editors/Sigil/patches: patch-src_ZipArchive_DirEnumerator.cpp
patch-src_ZipArchive_ZipFile__stl.cpp
patch-src_ZipArchive_ZipPlatform__lnx.cpp
Log Message:
editors/Sigil: Fix patch phase, Repack all patches
Sigil is delivered in a zip file, and the files have DOS line endings.
The patches had unix line endings, and at least on some platforms
including NetBSD 5, this resulted in rejected hunks.
All three patches repacked, now contain DOS line endings and work fine.
This is no general solution either; on NetBSD-6.99.10/amd64 I now get:
Also note that:
./extract/extract: : ${EXTRACT_OPTS_ZIP=-aqo}
where
-a When extracting a text file, convert DOS-style line endings
to Unix-style line endings.
so the files should already extract to Unix-style line endings.
Some unzips might need "-aa" instead to force this conversion.
Thomas
So the extract is not working reliably? IOW, the "-a" option is not
recognized by some implementations? Wouldn't removing -a switch make
these current patches work on all platforms?
It should not depend on `unzip' implementation.
`-a' option only effect to archive entries marked as `text' files,
but in this archive, all files are marked as `binary'.
So all files will be extracted AS-IS (may be DOS-sytle line endings).
I recall seeing another package that would strip out /r/n of all files
destined to get patched as a pre-patch (or post-extract) target. It
worked in all cases but it's a "gotcha" in that you have to know to add
to files to the list in the Makefile.
There's got to be standard solution here that works in all cases. THere
are lots of zip file archives.
As suggested by wiz@, first suggested workaround is `-aa' option,
treat whole entries as `text' file.
But it may break binary files.
For this archive, *.png files are included and will be installed,
so such workaround should not be used fot this case.
Probably, we can create a framework for EOL style conversion.