This patch found a bug in my scripts - it failed to grep the patch for sender and subject - but it looks like there might be something wrong with the patch itself, it doesn't apply here.
Buildbot said: Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/194 BUILD FAILED: failed git
and here's what I get when I do it by hand: $ wget http://source.winehq.org/patches/data/78249 $ git apply 78249
typocz.patch:31: trailing whitespace. msgstr "Ověřte prosím, že název souboru byl zadán správně" typocz.patch:40: trailing whitespace. "Chcete ho vytvořit?" typocz.patch:49: trailing whitespace. "Chcete ho přepsat novým?" typocz.patch:54: trailing whitespace. msgstr "Nedovolený(é) znak(y) v cestě k souboru" typocz.patch:63: trailing whitespace. "Chcete ho přepsat novým?" error: patch failed: po/cs.po:210 error: po/cs.po: patch does not apply
2011/9/1 Dan Kegel dank@kegel.com:
This patch found a bug in my scripts - it failed to grep the patch for sender and subject - but it looks like there might be something wrong with the patch itself, it doesn't apply here.
The patch uses dos line endings, that's why it doesn't apply.
Octavian
On Thu, Sep 1, 2011 at 7:52 AM, Octavian Voicu octavian.voicu@gmail.com wrote:
2011/9/1 Dan Kegel dank@kegel.com:
This patch found a bug in my scripts - it failed to grep the patch for sender and subject - but it looks like there might be something wrong with the patch itself, it doesn't apply here.
The patch uses dos line endings, that's why it doesn't apply.
That's it, thanks. (I had seen them, but thought patch tools were smart enough to ignore 'em; I guess patch does if the whole patch is in CRLF format, but in this case, the preamble wasn't.)
I just checked, and none of our .c, .h, or .po files have embedded CR's. I guess it would be ok to strip trailing CR's on incoming patches, I'll do that.
But there's something even fishier about http://source.winehq.org/patches/data/78249 -- it ends in a block of NUL characters. What's up with that? hexdump -C shows ... 00001560 20 0d 0a 20 23 3a 20 77 69 6e 68 6c 70 33 32 2e | .. #: winhlp32.| 00001570 72 63 3a 36 34 0d 0a 20 23 2c 20 66 75 7a 7a 79 |rc:64.. #, fuzzy| 00001580 0d 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001590 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001d80 00 00 0a 0a |....|
- Dan
On Thu, Sep 1, 2011 at 7:21 PM, Dan Kegel dank@kegel.com wrote:
I just checked, and none of our .c, .h, or .po files have embedded CR's. I guess it would be ok to strip trailing CR's on incoming patches, I'll do that.
That's weird, did they blacklist the 0x0d character from the encoding of Unicode characters? Pasted all the Unicode characters from a Wikipedia page in a file and couldn't find any 0x0d in the file.
In any case, is Alexandre also going to strip CRs? If not, there isn't much point in doing that, as patch wouldn't go in with the CRs.
Octavian
On Thu, 1 Sep 2011, Octavian Voicu wrote: [...]
The patch uses dos line endings, that's why it doesn't apply.
I don't know what happened because the email was generated the same way as all the other emails for PO file patches. There's something in the Czech language that causes both alpine and icedove to mangle the patches. And it appears to not just be the carriage returns, the encoding seems to be broken too.
I have manually resent the patch as a .bin attachement. The email tool considers that to be a binary file and it seems to prevent it and others in the chain from messing with it.
-
Dan Kegel -
Francois Gouget -
Octavian Voicu