From: Stefano S. <ste...@po...> - 2008-11-08 19:27:08
|
Hi all, first post here, so first of all a big thanks to the MinGW developers and community for your hard work. I'm trying MinGW with Windows XP on a virtual machine, and I'm experiencing really weird problems with patch. patch isn't working, that is it fails every time I try to use it, for example: stefano@WINDOWS-XP-2 ~/src/ffmpeg $ patch -p0 < configure.patch (Stripping trailing CRs from patch.) patching file configure Hunk #1 FAILED at 1405. 1 out of 1 hunk FAILED -- saving rejects to file configure.rej stefano@WINDOWS-XP-2 ~/src/ffmpeg $ patch -version patch 2.5.4 Copyright 1984-1988 Larry Wall Copyright 1989-1999 Free Software Foundation, Inc. This program comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of this program under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. written by Larry Wall and Paul Eggert I tried it with another installation of MinGW on another machine (this time patch 2.5) and it works just fine. I wonder if the "(Stripping trailing CRs from patch.)" stuff is indicative of the problem. BTW, can you say in which MinGW package can I found patch?, so that I can try with some other version. I'll be grateful for any suggestion, unfortunately this problem is a show-stopper for me. Regards. |
From: Roumen P. <bug...@ro...> - 2008-11-08 20:36:08
|
Stefano Sabatini wrote: [SNIP] > patch isn't working, that is it fails every time I try to use it, for > example: > > stefano@WINDOWS-XP-2 ~/src/ffmpeg > $ patch -p0 < configure.patch > (Stripping trailing CRs from patch.) > patching file configure > Hunk #1 FAILED at 1405. > 1 out of 1 hunk FAILED -- saving rejects to file configure.rej [SNIP] Probably patch is not for current source code. The message is normal if a part of a patch can't be applied to code. "patch isn't working" :) - it works when save "rejects to file" ... Next you may skip all patches to configure. This file is created(generated) by autoconf and after patch you has to run appropriate autoconf version to recreate file. Roumen |
From: Stefano S. <ste...@po...> - 2008-11-08 23:14:54
|
On date Saturday 2008-11-08 22:35:57 +0200, Roumen Petrov wrote: > Stefano Sabatini wrote: > [SNIP] > > patch isn't working, that is it fails every time I try to use it, for > > example: > > > > stefano@WINDOWS-XP-2 ~/src/ffmpeg > > $ patch -p0 < configure.patch > > (Stripping trailing CRs from patch.) > > patching file configure > > Hunk #1 FAILED at 1405. > > 1 out of 1 hunk FAILED -- saving rejects to file configure.rej > [SNIP] > Probably patch is not for current source code. > The message is normal if a part of a patch can't be applied to code. > > "patch isn't working" :) - it works when save "rejects to file" ... Well, I meant "is not working as I expect". > Next you may skip all patches to configure. This file is > created(generated) by autoconf and after patch you has to run > appropriate autoconf version to recreate file. Mmh no that's not the case, that configure isn't autogenerated. But now I see what's the problem is, see at the post I'm going to write... Regards. |
From: Soren A. <so...@bl...> - 2008-11-08 22:09:01
|
[[ Reply composed at 08 Nov 2008 T17:01 (US EST) ]] I'm responding to the message sent on 08 Nov 2008, at around 19:25 UTC, by "Stefano Sabatini" <stefano.sabatini-lala ~at~ OBSCURED dot NUL>, who wrote > I'm trying MinGW with Windows XP on a virtual machine, and I'm > experiencing really weird problems with patch. > patch isn't working, that is it fails every time I try to use it, > for example: > $ patch -p0 < configure.patch > (Stripping trailing CRs from patch.) > patching file configure > Hunk #1 FAILED at 1405. > 1 out of 1 hunk FAILED -- saving rejects to file configure.rej > I tried it with another installation of MinGW on another machine > (this time patch 2.5) and it works just fine. > I wonder if the "(Stripping trailing CRs from patch.)" stuff is > indicative of the problem. I like to break down problems into the smallest possible pieces and then try to prioritize them. (1) "(Stripping trailing CRs from patch.)" Ahem. Good, gives me an opportunity to explain a Developer Fundamental yet again. If you have patch files (a.k.a. diffs) with DOS line endings, then your other problems all receed into insignificance. You need to *never, ever* use a WinDOS brain-damaged text editor on patches. You need to never, ever store, submit or attempt to apply patches that have DOS line endings.§ You will be reviled and cursed and spat upon if you ever send a patch that has DOS line endings to a project maintainer. (2) "MinGW [...] on a virtual machine": should make no difference where the Windows is running, except that sometimes large systems like a VM might have "mount" options for "drives" (what the rest of the universe knows as "disk partitions") that specify whether the "drive" is to be mounted so that anything detected as a "text" file has line ending conversions done on it automatically by the input/output system. The support venue for your virtualization technology would be the right place to go for information about that. (3) "stefano@WINDOWS-XP-2 ~/src/ffmpeg": no, not a mistake, I really mean "look at your prompt". "~/src/ffmpeg" looks like a bash prompt. It is, isn't it. So, you are using MSYS? Mingw is not MSYS. MSYS is quite precisely the kind of software referred to in "(2)" above, that might have mount options that specify "conversion of text file line endings". So when you do the redirection in the shell ("< configure.patch"), the line endings might be molested by the I/O system. So if your are not guilty of creating or not checking for a foul broken patch (one with DOS line endings), this might be the culprit. HTH, Sören 'somian' Andersen § Of course sometimes a text file must have DOS ending in actual use. Files that are input to proprietary Microsoft developer programs that do not accept *nix line endings are one example. In that case IMHO the patches should be stored and transmitted with comments to the effect that a conversion before use must be done, but should still only have *nix line endings. Hint: there are simple, Open Source cli utilities that exist to convert text files from on line ending type to another. "dos2unix"/"unix2dos" is one. -- Blame it on Caradhras the Cruel. |
From: Stefano S. <ste...@po...> - 2008-11-08 23:39:57
|
On date Saturday 2008-11-08 17:08:50 -0500, Soren Andersen wrote: > [[ Reply composed at 08 Nov 2008 T17:01 (US EST) ]] > I'm responding to the message sent on 08 Nov 2008, at around 19:25 > UTC, by "Stefano Sabatini" <stefano.sabatini-lala ~at~ OBSCURED dot > NUL>, who wrote > > > I'm trying MinGW with Windows XP on a virtual machine, and I'm > > experiencing really weird problems with patch. > > patch isn't working, that is it fails every time I try to use it, > > for example: > > > $ patch -p0 < configure.patch > > (Stripping trailing CRs from patch.) > > patching file configure > > Hunk #1 FAILED at 1405. > > 1 out of 1 hunk FAILED -- saving rejects to file configure.rej > > > I tried it with another installation of MinGW on another machine > > (this time patch 2.5) and it works just fine. > > > I wonder if the "(Stripping trailing CRs from patch.)" stuff is > > indicative of the problem. > > I like to break down problems into the smallest possible pieces and > then try to prioritize them. > > (1) "(Stripping trailing CRs from patch.)" Ahem. Good, gives me > an opportunity to explain a Developer Fundamental yet again. If > you have patch files (a.k.a. diffs) with DOS line endings, then > your other problems all receed into insignificance. You need to > *never, ever* use a WinDOS brain-damaged text editor on patches. > You need to never, ever store, submit or attempt to apply patches > that have DOS line endings.§ You will be reviled and cursed and > spat upon if you ever send a patch that has DOS line endings to a > project maintainer. Uh, that was the point, and after main weep and hair-tearing now I finally have the key of the puzzle, thank you for pointing me in the right direction! svn, which I used to download the sources, were using native eol termination, so all the files in that dir, including configure, were CR-LF terminated. Patch issued with svn diff FILES > PATCH aren't valid according to your assumption, since they're too CR-LF terminated, which I think is bad, anyway running dos2unix fix'em. Applying a DOS line-terminated patch on a whatever file seems not to work, the same for applying a valid (Unix line-terminated) patch file on a DOS line-terminated file. dos2unix-ing both the patch and the file to patch worked, but it's rather clumsy, so I wonder what's the standard procedure to apply patches in MinGW, or in general to apply patch on DOS line-terminated files. > (2) "MinGW [...] on a virtual machine": should make no difference > where the Windows is running, except that sometimes large systems > like a VM might have "mount" options for "drives" (what the rest > of the universe knows as "disk partitions") that specify whether > the "drive" is to be mounted so that anything detected as a "text" > file has line ending conversions done on it automatically by the > input/output system. The support venue for your virtualization > technology would be the right place to go for information about > that. > > (3) "stefano@WINDOWS-XP-2 ~/src/ffmpeg": no, not a mistake, I > really mean "look at your prompt". "~/src/ffmpeg" looks like a > bash prompt. It is, isn't it. So, you are using MSYS? Mingw is > not MSYS. MSYS is quite precisely the kind of software referred > to in "(2)" above, that might have mount options that specify > "conversion of text file line endings". So when you do the > redirection in the shell ("< configure.patch"), the line endings > might be molested by the I/O system. So if your are not guilty of > creating or not checking for a foul broken patch (one with DOS > line endings), this might be the culprit. > > HTH, > Sören 'somian' Andersen > > § Of course sometimes a text file must have DOS ending in actual > use. Files that are input to proprietary Microsoft developer > programs that do not accept *nix line endings are one example. In > that case IMHO the patches should be stored and transmitted with > comments to the effect that a conversion before use must be done, > but should still only have *nix line endings. Hint: there are > simple, Open Source cli utilities that exist to convert text files > from on line ending type to another. "dos2unix"/"unix2dos" is one. Please make your point more clear here, what do you mean with "stored and transmitted with comments"? What I would like to avoid is the conversion of the file to patch. BTW, I still continue to be amazed by the bewildering amount of human-years wasted because of the really really poor choice of using this "clever" end-of-line termination mechanism in DOS, choosed apparently for no other reason than to make compatibility with Unix system more difficult. Consider that one of the man which took this choice is one of the richest man on Earth, and you get the measure of the level of insanity on this planet... Regards. |
From: Greg C. <gch...@sb...> - 2008-11-09 00:13:46
|
On 2008-11-08 23:38Z, Stefano Sabatini wrote: > > svn, which I used to download the sources, were using native eol > termination, so all the files in that dir, including configure, were > CR-LF terminated. http://www.google.com/search?q=svn%3Aeol-style > dos2unix-ing both the patch and the file to patch worked, but it's > rather clumsy, so I wonder what's the standard procedure to apply > patches in MinGW, or in general to apply patch on DOS line-terminated > files. I use only "\n"-delimited files, and avoid any tool that changes the delimiter to "\r\n". |
From: Caleb C. <xen...@gm...> - 2008-11-09 13:44:08
|
When I was working on building MSYS from source I had a problem with patch, due to line endings. I had to revert to an older version of patch. You might try that. |
From: Stefano S. <ste...@po...> - 2008-11-09 15:04:17
|
On date Sunday 2008-11-09 08:44:02 -0500, Caleb Cushing wrote: > When I was working on building MSYS from source I had a problem with > patch, due to line endings. I had to revert to an older version of > patch. You might try that. Mmh.., thanks indeed with an older version of patch (2.5.1) I wasn't having problem, maybe the more recent one is more picky about the line endings. Regards. |
From: Earnie B. <ea...@us...> - 2008-11-10 12:45:51
|
Quoting Stefano Sabatini <ste...@po...>: > On date Sunday 2008-11-09 08:44:02 -0500, Caleb Cushing wrote: >> When I was working on building MSYS from source I had a problem with >> patch, due to line endings. I had to revert to an older version of >> patch. You might try that. > > Mmh.., thanks indeed with an older version of patch (2.5.1) I wasn't > having problem, maybe the more recent one is more picky about the line > endings. > The patch, is it an MSYS dependent one that is having an issue? Mixing line endings is just plain wrong. I suggest you put in editor hints into the source file. Something like ``// vim:ff=unix'' will always leave the source file in unix format. Also watch out for programs that do auto conversion of line endings. Those foul programs are a sore spot in the open source community. Make sure your files are transferred to your system in the same format as the source. Earnie |
From: Caleb C. <xen...@gm...> - 2008-11-16 19:54:56
|
> The patch, is it an MSYS dependent one that is having an issue? In my case there was a problem with <CR> line endings in one of the LZMA patches... it was mentioned in my thread on the msys list about building msys from source. -- Caleb Cushing |
From: Earnie B. <ea...@us...> - 2008-11-17 20:48:18
|
Quoting Caleb Cushing <xen...@gm...>: >> The patch, is it an MSYS dependent one that is having an issue? > > In my case there was a problem with <CR> line endings in one of the > LZMA patches... it was mentioned in my thread on the msys list about > building msys from source. > The patch executable that you get with MSYS would include the \r\n in the patched file for the lines patched even if the file itself only has \n line endings. Earnie |