2

I am trying to apply a patch that is provided by the seek-for-android project to code I downloaded from Cyanogenmod. The code compiled successfully with make, so I know all the files are there. I just can not get any visibility into what patch is doing or if it is even working. I tried the -verbose option. I don't know how long it takes for patch to traverse the directory and look for the files to update. I don't see much of an activity in my cpu. Here are the instructions I am following: enter link description here Here is a screen capture of what I see:

   root@ubuntu:~/android/system# ls
    abi       cm-11-2      docs             Makefile   sdk
    android   cm-11-3      external         ndk        smartcard-api-3_1_0
    art       cts          frameworks       out        smartcard-api-3_1_0.tgz
    bionic    dalvik       hardware         packages   system
    bootable  developers   kernel           pdk        tools
    build     development  libcore          prebuilt   vendor
    cm-11     device       libnativehelper  prebuilts
    root@ubuntu:~/android/system# cd smartcard-api-3_1_0
    root@ubuntu:~/android/system/smartcard-api-3_1_0# cd ..
    root@ubuntu:~/android/system# patch -p1 smartcard-api-3_1_0/smartcard-api.patch   ^C
     root@ubuntu:~/android/system# patch -p1 -R smartcard-api-3_1_0/smartcard- api.patch 
    ^C
    root@ubuntu:~/android/system# patch -p1 -verbose smartcard-   api-3_1_0/smartcard-  
    api.patch 
    patch 2.6.1
    Copyright (C) 1988 Larry Wall
    Copyright (C) 2003, 2009 Free Software Foundation, Inc.

I think in some cases, I should look for the target file? The output below seems to say that one patch was successful, while the other file was not found? I guess I have to find the target file and specify it? For some reason even a full path is not recognized.

root@ubuntu:~/android/system# patch -p1 < smartcard-api-3_1_0/uicc.patch 
patching file frameworks/base/telephony/java/com/android/internal/telephony  /ITelephony.aidl
Hunk #1 FAILED at 304.
1 out of 1 hunk FAILED -- saving rejects to file frameworks/base/telephony /java/com/android/internal/telephony/ITelephony.aidl.rej
patching file frameworks/base/telephony/java/com/android/internal/telephony  /RILConstants.java
Hunk #1 FAILED at 55.
Hunk #2 FAILED at 262.
2 out of 2 hunks FAILED -- saving rejects to file frameworks/base/telephony/java/com/android/internal/telephony/RILConstants.java.rej
patching file frameworks/opt/telephony/src/java/com/android/internal/telephony /CommandException.java
Hunk #1 FAILED at 42.
Hunk #2 FAILED at 83.
2 out of 2 hunks FAILED -- saving rejects to file frameworks/opt/telephony  /src/java/com/android/internal/telephony/CommandException.java.rej
patching file frameworks/opt/telephony/src/java/com/android/internal/telephony /CommandsInterface.java
Hunk #1 succeeded at 1250 (offset 109 lines).
patching file frameworks/opt/telephony/src/java/com/android/internal/telephony /IccCard.java
Hunk #1 FAILED at 214.
1 out of 1 hunk FAILED -- saving rejects to file frameworks/opt/telephony  /src/java/com/android/internal/telephony/IccCard.java.rej
patching file frameworks/opt/telephony/src/java/com/android/internal/telephony  /RIL.java
Hunk #1 succeeded at 2592 (offset 253 lines).
Hunk #2 succeeded at 4109 (offset 467 lines).
Hunk #3 succeeded at 4619 (offset 543 lines).
patching file frameworks/opt/telephony/src/java/com/android/internal/telephony/sip/SipCommandInterface.java
Hunk #1 FAILED at 536.
1 out of 1 hunk FAILED -- saving rejects to file frameworks/opt/telephony/src/java/com/android/internal/telephony/sip/SipCommandInterface.java.rej
patching file frameworks/opt/telephony/src/java/com/android/internal/telephony  /test/SimulatedCommands.java
Hunk #1 FAILED at 1655.
1 out of 1 hunk FAILED -- saving rejects to file frameworks/opt/telephony /src/java/com/android/internal/telephony/test/SimulatedCommands.java.rej
patching file frameworks/opt/telephony/src/java/com/android/internal/telephony/uicc/IccCardProxy.java
Hunk #1 succeeded at 844 (offset 102 lines).
patching file frameworks/opt/telephony/src/java/com/android/internal/telephony/uicc/UiccCardApplication.java
Hunk #1 FAILED at 44.
Hunk #2 succeeded at 437 (offset 100 lines).
Hunk #3 succeeded at 941 (offset 194 lines).
1 out of 3 hunks FAILED -- saving rejects to file frameworks/opt/telephony  /src/java/com/android/internal/telephony/uicc/UiccCardApplication.java.rej
patching file frameworks/opt/telephony/tests/telephonytests/src/com/android    /internal/telephony/gsm/UsimDataDownloadCommands.java
Hunk #1 succeeded at 651 with fuzz 2 (offset 21 lines).
can't find file to patch at input line 404
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
 diff --git a/packages/apps/Phone/src/com/android/phone  /PhoneInterfaceManager.java b/packages/apps/Phone/src/com/android/phone    /PhoneInterfaceManager.java
|index 6600ae5..2ae6739 100644
|--- a/packages/apps/Phone/src/com/android/phone/PhoneInterfaceManager.java
|+++ b/packages/apps/Phone/src/com/android/phone/PhoneInterfaceManager.java
--------------------------
File to patch: 
1
  • Note that you need two hyphens in --verbose; with just one, patch will read it as -v, output its version information, and stop.
    – deltab
    May 5, 2014 at 2:16

3 Answers 3

6

For some reason, the patch file has to be fed into the patch program by redirection, i.e.

     patch file

does not work, but

    patch < file

works

7
  • 2
    This is the answer. If you write patch file then it will just sit and wait for you to type something in on stdin. May 4, 2014 at 20:36
  • Thanks. It worked. I now have to figure out why only 2 out of three changes took. One of them reported fuzz, which I believe means the target pattern was at a different line. This group is really great. Mercurial is a big help to me also as I can roll back. After I run the patch it stays at "file to patch:" prompt, and I use crtl C to come out. Is that normal? May 4, 2014 at 21:48
  • @user3326293 A reasonable thing to check is whether the files you are trying to patch actually exist. A second is to check what p/strip number should be used for the patch. Normally if the strip number is wrong, no part of the patch will apply, however. May 5, 2014 at 0:01
  • @Fahim I see what you mean about the P/strip numbers. Maybe it is too tough to update the patch right? In the case of the first error; ITelephony, the path to the file in my environment is one directory shorter. Can I just update the patch with the right path? May 6, 2014 at 1:21
  • I was mistaken, the file is there and the path is correct. The project that wrote the script, asked me what version of code I am trying to patch, so may be they'll fix it. Is there anything I can do to find out why it failed? May 6, 2014 at 1:33
6

A very easy solution is to put your files under version control before applying the patch. The version control tools du jour are Git and Mercurial. I personally use and recommend Mercurial.

Also, if you want to see what files a patch applies to, you can run

diffstat patchname

Sample output with Mercurial:

apt-get source hello
cd hello-2.9
hello-2.9$ hg init
hello-2.9$ hg add
hello-2.9$ hg ci     # brings up an editor - add a commit message
hello-2.9$ patch -p1 < debian/patches/99-config-guess-config-sub 
    patching file build-aux/config.guess
    patching file build-aux/config.sub
hello-2.9$ hg st
    M build-aux/config.guess
    M build-aux/config.sub
hello-2.9$ hg diff   # diff output
hello-2.9$ diffstat debian/patches/99-config-guess-config-sub
    config.guess |  149 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------
    config.sub   |   36 ++++++++++++++++++++----------------
    2 files changed, 106 insertions(+), 79 deletions(-)
8
  • Can I do that to an entire directory? What would I see? Can you share a sample output? I noticed there is a debug option. Would that give me more information? My issue is that I am not sure if it is looking for files to update or it is just sitting there due to an error. May 4, 2014 at 15:16
  • @user3326293 Of course you can apply to a entire directory. May 4, 2014 at 15:17
  • @user3326293 FYI, patch behaves in the standard Unix fashion. If it finishes successfully, it doesn't say much. If there is an error, it gets chatty. May 4, 2014 at 17:10
  • Ok. That is good to know. But does it not return the command prompt? Is that normal? I just ran "hg st", and the screen is full of items. I now realize that this patch covers a huge number of files. Again, I am just a bit uneasy because patch does not return the command prompt once it is done. Do I have to do something extra for that to happen? May 4, 2014 at 18:35
  • @user3326293 Not returning the command prompt means it has not finished, and is abnormal. May 4, 2014 at 18:37
3

You can use the -i option instead of using redirection outright:

$ patch -i /path/to/file.patch

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .