I'm running into trouble using patch. I have 2 folders with many subfolders and files.
diff -ur backup/www/ www/ > sync.patch
Next, I'm trying to apply the patch.
patch < sync.patch
It asks me File to patch: as you can see.
|diff -ur ./backup/www/members/categorize.php ./www/members/categorize.php
|--- ./backup/www/members/categorize.php 2012-12-13 15:19:41.000000000 -0500
|+++ ./www/members/categorize.php 2012-10-15 23:32:12.000000000 -0400
--------------------------
File to patch:
The file ./www/members/categorize.php exists.
You probably need to investigate the -p flag for patch, which controls the way that directory prefixes are treated. See the man page.
Related
looking to disable some SELinux modules (set to off) and create others in modules.conf. I don't see an obvious way of updating modules.conf as I tried adding my changes as a modules.conf patch but it failed given that the modules.conf file gets built and is not just downloaded by BR so it is not available for patching like other things under the refpolicy directory:
Build window output:
refpolicy 2.20190609 PatchingApplying 0001-refpolicy-update-modules-conf.patch using patch:
can't find file to patch at input line 3
I did see in the log that there is a support/sedoctool.py that autogenerates the policy/modules.conf file so that the file is NOT patchable like most other things in the ref policy.
The relevant section of the buildroot/output/build/refpolicy-2.20190609/Makefile:
# policy building support tools
support := support
genxml := $(PYTHON) $(support)/segenxml.py
gendoc := $(PYTHON) $(support)/sedoctool.py
<...snip...>
########################################
#
# Create config files
#
conf: $(mod_conf) $(booleans) generate$(booleans) $(mod_conf): conf.intermediate.INTERMEDIATE: conf.intermediate
conf.intermediate: $(polxml)
#echo "Updating $(booleans) and $(mod_conf)"
$(verbose) $(gendoc) -b $(booleans) -m $(mod_conf) -x $(polxml)
Part of the hsmlinux build.log showing the sedoctool.py (gendoc) being run:
Updating policy/booleans.conf and policy/modules.conf
.../build-buildroot-sawshark/buildroot/output/host/usr/bin/python3 support/sedoctool.py -b policy/booleans.conf -m policy/modules.conf -x doc/policy.xml
I'm sure there is a standard way of doing this, just doesn't seem to be documented anywhere I can find.
Thanks.
Turns out that the sedoctool.py script is reading the doc/policy.xml. Looking at sedoctool.py:
#modules enabled and disabled values
MOD_BASE = "base"
MOD_ENABLED = "module"
MOD_DISABLED = "off"
<...snip...>
def gen_module_conf(doc, file_name, namevalue_list):
"""
Generates the module configuration file using the XML provided and the
previous module configuration.
"""
# If file exists, preserve settings and modify if needed.
# Otherwise, create it.
<...snip...>
mod_name = node.getAttribute("name")
mod_layer = node.parentNode.getAttribute("name")
<...snip...>
if mod_name and mod_layer:
file_name.write("# Layer: %s\n# Module: %s\n" % (mod_layer,mod_name))
if required:
file_name.write("# Required in base\n")
file_name.write("#\n")
if [mod_name, MOD_DISABLED] in namevalue_list:
file_name.write("%s = %s\n\n" % (mod_name, MOD_DISABLED))
# If the module is set as enabled.
elif [mod_name, MOD_ENABLED] in namevalue_list:
file_name.write("%s = %s\n\n" % (mod_name, MOD_ENABLED))
# If the module is set as base.
elif [mod_name, MOD_BASE] in namevalue_list:
file_name.write("%s = %s\n\n" % (mod_name, MOD_BASE))
So sedoctool.py has the nice feature of: "# If file exists, preserve settings and modify if needed." and modules.conf can just be added whole here via a complete file patch and the modules that are not desired set as "off" : refpolicy-2.20190609/policy/modules.conf and the script will update as needed based on desired policy.
One more detail is that in the next stage of the refpolicy Makefile (Building) the modules.conf with the updates is deleted in the beginning which kind of clashes with the ability of sedoctool to preserve the patched version of modules.conf...so patched the removal in the Building stage of the Makefile.
[7m>>> refpolicy 2.20190609 Building^[
<...snip...>
rm -f policy/modules.conf
The Makefile in refpolicy-2.20190609 has this line that I patched out because we are patching in our own modules.conf:
bare: clean
<...snip...>
$(verbose) rm -f $(mod_conf)
That patch looks like:
--- BUILDROOT/Makefile 2020-08-17 13:25:06.963804709 -0400
+++ FIX/Makefile 2020-08-17 19:25:29.540607763 -0400
## -636,7 +636,6 ##
$(verbose) rm -f $(modxml)
$(verbose) rm -f $(tunxml)
$(verbose) rm -f $(boolxml)
- $(verbose) rm -f $(mod_conf)
$(verbose) rm -f $(booleans)
$(verbose) rm -fR $(htmldir)
$(verbose) rm -f $(tags)
BTW,
Creating a patch with a complete new file in pp1:q!:
diff -crB --new-file pp0 pp1 > pp0.patch
I am newbie to yocto. I have create a simple layer and it consist of a simple patch file for wpa_supplicant. I want to modify wpa_supplicant.conf-sane file from my own layer. Original wpa_supplicant resides on different layer
wpa-supplicant-bbappend
├── wpa-supplicant
│ └── wiress_info.patch
└── wpa-supplicant_2.6.bbappend
I have generated a diff file
diff -u ../../../poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/wpa_supplicant.conf-sane wpa-supplicant/wpa_supplicant.conf-sane > wpa-supplicant/wiress_info.patch
Here is my patch file :
--- ../../../poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/wpa_supplicant.conf-sane 2019-04-15 02:47:49.379423777 +0900
+++ wpa-supplicant/wpa_supplicant.conf-sane 2019-04-15 03:03:31.765059417 +0900
## -3,5 +3,11 ##
update_config=1
network={
- key_mgmt=NONE
+ key_mgmt=NONE
+ ssid="tanmoyc"
+ psk="asdzxcqwe123"
+ proto=RSN
+ key_mgmt=WPA-PSK
+ pairwise=CCMP
+ auth_alg=OPEN
}
Here is my wpa-supplicant_2.6.bbappend file
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = " file://wiress_info.patch "
Still I am having some error during patch by yocto
Applying patch wiress_info.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- ../../../poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/wpa_supplicant.conf-sane 2019-04-15 02:47:49.379423777 +0900
|+++ wpa-supplicant/wpa_supplicant.conf-sane 2019-04-15 03:03:31.765059417 +0900
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
Patch wiress_info.patch does not apply (enforce with -f)
ERROR: wpa-supplicant-2.6-r0 do_patch: Function failed: patch_do_patch
I am not able to figure out whats wrong I am doing? Please help
Your patch has wrong source file to patch specified. Thus the message "No file to patch.".
The patches are applied with option -p1 (see Patching Code in doc) in directory in variable S (i.e. unpacked source files, see Patching in doc).
Although you can apply that patch by adding striplevel option in SRC_URI, the right way is to fix the patch itself. Please see Nayfe's comment about devshell, it is convenient way to do it (or fix path in your diff command).
Suppose I have a directory dir1, and have files f1.c and f2.c in it.
I copy all to directory dir2, modify both f1 and f2, and add a new file f3.c.
Then I do the diff to create patch:
diff -ruN dir1/ dir2/ > diff.patch
Now I want to apply the patch back to dir1. However the changes in f1 and f2 are successfully patched. but I don't get a new file f3.c in dir1:
[/local/home/tmp]$ patch -p0 < diff.patch
patching file dir1/f1.c
Hunk #1 succeeded at 1 with fuzz 2.
patching file dir1/f2.c
The next patch would create the file dir2/f3.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
How to apply the patch, so that I can add f3.c in dir1 too?
OK, i've figured out, that you must cd into dir1, and use the -p1 parameter:
cd dir1
patch -p1 < ../diff.patch
I've made a patch by using diff:
diff -u /home/user/onderzoeksstage/omf/Rakefile /home/user/onderzoeksstage/Rakefile > rakefile2.patch
I've placed this rakefile2.patch in another directory: /home/user/onderzoeksstage/omf/confine/patches.
Now, I was under the assumption that I could go to that directory where all my patches are collected, call patch < rakefile2.patch and patch would known where to find the file to patch (the original file /home/user/onderzoeksstage/omf/Rakefile) by reading out the rakefile2.patch header.
But when doing that, patch says that it does not find the file to patch:
[user#localhost patches]$ patch < rakefile2.patch
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|--- /home/user/onderzoeksstage/omf/Rakefile 2013-02-12 14:11:49.809792527 +0100
|+++ /home/user/onderzoeksstage/Rakefile 2013-02-12 12:17:50.314831492 +0100
--------------------------
File to patch: ...
...
So my assumption was obviously wrong, but so how does patch work?
When going to /home/user/onderzoeksstage/omf/ and calling patch < rakefile2.patch does work. Does patch only look at the header for the filename at the end of the path and not take in account the directory? And so what I try to accomplish will never work?
Why is this; is this because that way a patch could be applied to any file called Rakefile (e.g. in my case) and so make it a more "generic" patch?
Thanks
Does patch only look at the header for the filename at the end of the
path and not take in account the directory?
That's what it does by default. See the description of -p option in man patch. Looks like -p0 is what you want here.
My confusion arises from the following statement taken from here:
When pulling patches that conflict each other (e.g., change the same part of the file) Darcs detects the conflict and marks it in the repository content. It then lets the user resolve the problem.
This seemed inconsistent with what I was seeing, so I created the following work-flow using darcs 2.5.2:
Create repo foo;
Create a non-empty file in foo and record it;
Clone foo to bar;
Remove the file in foo and record it;
Add another line to the file in bar and record it;
Pull from foo into bar, obtain conflict notification;
After taking these steps I ran darcs whatsnew in bar, and was shown two 'patch primitives':
A hunk removing all of the "non-empty file in foo", but with no mention of the line added and recorded in bar;
A rmfile removing the file.
My question is: Why is there no mention of the line added and recorded in bar?
If I run darcs revert in bar, then everything makes sense: I see the "non-empty file" affected by neither conflicting patch, as per this statement taken from here:
The command darcs revert will remove the conflict marking and back up to state before conflicting patches.
But then if I run darcs mark-conflicts I am back to the same state as after the pull, with the two 'patch primitives' mentioned above, and no mention of the the line added and recorded in bar.
For reference / reproduction here is my complete work-flow from the command line:
$ mkdir foo
$ cd foo/
foo$ darcs initialize
foo$ touch shopping
foo$ vi shopping <-- add a couple of lines
foo$ darcs add shopping
foo$ darcs record
addfile ./shopping
Shall I record this change? (1/2) [ynW...], or ? for more options: y
hunk ./shopping 1
+cake
+pie
Shall I record this change? (2/2) [ynW...], or ? for more options: y
What is the patch name? Added shopping
Do you want to add a long comment? [yn]n
Finished recording patch 'Added shopping'
foo$ cd ..
$ darcs get foo/ bar
$ cd bar/
bar$ vi shopping <-- add another line
bar$ darcs record
hunk ./shopping 2
+beer
Shall I record this change? (1/1) [ynW...], or ? for more options: y
What is the patch name? Added beer
Do you want to add a long comment? [yn]n
Finished recording patch 'Added beer'
bar$ cd ../foo
foo$ rm shopping
foo$ darcs record
hunk ./shopping 1
-cake
-pie
Shall I record this change? (1/2) [ynW...], or ? for more options: y
rmfile ./shopping
Shall I record this change? (2/2) [ynW...], or ? for more options: y
What is the patch name? Removed shopping
Do you want to add a long comment? [yn]n
Finished recording patch 'Removed shopping'
foo$ cd ../bar
bar$ darcs pull
Pulling from "../foo"...
Mon Nov 14 19:26:44 GMT 2011 dukedave#gmail.com
* Removed shopping
Shall I pull this patch? (1/1) [ynW...], or ? for more options: y
Backing up ./shopping(-darcs-backup0)
We have conflicts in the following files:
./shopping
Finished pulling and applying.
bar$ darcs whatsnew
hunk ./shopping 1
-cake
-pie
rmfile ./shopping
If you run darcs changes -v inside bar, you'll see the history of your
changes, including the conflictor introduced as a result of you pulling
conflicting patches.
I've summarised your example to something everso slightly shorter:
DARCS=/usr/bin/darcs
$DARCS init --repo foo
cd foo
echo 'a' > myfile
$DARCS add myfile && $DARCS record -am 'Add myfile'
$DARCS get . ../bar
rm myfile
$DARCS record -am 'Remove myfile'
cd ../bar
echo 'b' >> myfile
$DARCS record -am 'Change myfile'
$DARCS pull -a ../foo
$DARCS changes -v
Now, after that, I see this output from darcs changes -v
Tue Nov 15 19:44:38 GMT 2011 Owen Stephens <darcs#owenstephens.co.uk>
* Remove myfile
conflictor [
hunk ./myfile 2
+b
]
|:
hunk ./myfile 1
-a
conflictor {{
|:
hunk ./myfile 2
+b
|:
hunk ./myfile 1
-a
}} []
|hunk ./myfile 1
|-a
|:
rmfile ./myfile
Tue Nov 15 19:44:38 GMT 2011 Owen Stephens <darcs#owenstephens.co.uk>
* Change myfile
hunk ./myfile 2
+b
Tue Nov 15 19:44:38 GMT 2011 Owen Stephens <darcs#owenstephens.co.uk>
* Add myfile
addfile ./myfile
hunk ./myfile 1
+a
So, let's explain the crazy output of "Remove myfile". "Remove myfile" exists
as the following in foo:
Tue Nov 15 19:44:38 GMT 2011 Owen Stephens <darcs#owenstephens.co.uk>
* Remove myfile
hunk ./myfile 1
-a
rmfile ./myfile
So, a hunk at line 1 and removal of the file.
Pulling "remove myfile" into bar, we modify the patch contents by introducing special "conflictor" primitives that represent the primitives within "Remove myfile" that conflict with other primitves in bar. N.b. there is no information loss here - we can always get back to the original primitives by unpulling the conflicting changes - in this case, unpulling "change myfile".
Conflictors are confusing, but AFAICT essentially separate changes that
conflict with a current patch, x into 2 sets:
"ix" which is the set of patches that includes:
i) patches that conflict with x and some other patch in the repo
ii) patches that conflict with a patch that conflicts with x
"xx" which is the sequence of patches that only conflict with the patch x.
I think the reason that this is done, is that Conflictors have the effect of
"undoing" primitives that cause conflicts, but only those that haven't been
undone by another Conflictor.
The output we see is something like:
"conflictor" ix "[" xx "]" x
I'm abusing notation, but hopefully you can somewhat decipher that (see
src/Darcs/Patch/V2/(Real.hs|Non.hs) in the darcs.net repo for the full story)
In this case, "Remove myfile" has 2 primitive patches, and (in this case) 2
corresponding conflictors when pulled into bar.
The first primitive (remove line 1 from myfile) only conflicts with the
primitive within "Change myfile" (add 'b' to line 2 of myfile) and so that's
the first conflictor:
conflictor [ <--- The start of xx (no ix here)
hunk ./myfile 2
+b
] <--- The end of xx
|:
hunk ./myfile 1 <--- x
-a
N.B ( "|:" is a marker that delimits a "Non" primitve's context from the
primitive itself - I won't try and explain it further, just read below |: to
see the primitive in question)
The second primitive (remove myfile) is only slightly more complicated: (rmfile
myfile) conflicts with (add 'b' to line 2 of myfile) which as we know conflicts
with (remove line 1 from myfile), so they both go into "ix", with no patches in
"xx". I'll remove the unnecessary "|:" delimiters and space things out:
conflictor {{
hunk ./myfile 2
+b
hunk ./myfile 1
-a
}}
[] <--- no xx
|hunk ./myfile 1 <--- start of x
|-a
|:
rmfile ./myfile <--- end of x
The final (rmfile myfile) has some context to indentify the exact primitive
that we're referring to (I'm not really sure why/how this is required, but
there we are), which is marked by leading '|'s and delimited by "|:".
Finally, to attempt explain the output of darcs whatsnew in foo; when
multiple patches conflict, I think the actual effect of the conflictor is to
"undo" any conflicting patches, giving the effect of neither;
gives the start of some explanations: http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory_and_conflicts.
I think what you're seeing is the result of the forced commutation of "Change myfile" and "Remove myfile" call them A and B respectively. Then to merge the two, Darcs creates A^-1 and commutes A^-1 and B to give B' and (A^-1)' where B' has the effect of A^-1 (since we're forcing the commutation to work), meaning that the effect of B' (i.e. the merged "remove myfile") is actually to just undo the adding of the line made by "Change myfile".
I haven't had time to look at how darcs mark-conflicts works, so I can't yet explain the working changes you're seeing with darcs changes in bar.