Tag Info

Hot answers tagged

29

The purpose is to save lots of traffic. The Linux tarball is around 75MB, whereas the patches usually just have a few KB. So if you compile your own kernel, and update to each new minor version the day it is released, instead of redownloading a new 75MB tarball for each minor update, you just download (for example) the main tarball for a given version ...


14

Patches are usually contained in .diff files, because the patches are created using the diff command. A patch is a series of insertions and deletions into source code. For this reason, in order to use the patch, you must build the application (e.g., "foobar") from source after applying the patch. So, in steps: 1. Get the source package for foobar. ...


8

Don't you want the other way around? diff -Nub . /current-files | patch -b


8

The most common way to create a patch is to run the diff command or some version control's built-in diff-like command. Sometimes, you're just comparing two files, and you run diff like this: diff -u version_by_alice.txt version_by_bob.txt >alice_to_bob.patch Then you get a patch that contains changes for one file and doesn't contain a file name at all. ...


7

patch creates new file, that's why it holds effective user credentials. A workaround: use patch -o to have temporary file created, then simply cat tmp file to original file.


7

To patch a file means to modify it, with the connotation that the modification is generally small. The usage comes from the general English usage where a patch is a small modification (to a piece of cloth, for example). When it comes to files, a patch is not always a repair. A patch is a series of instructions that describe how to modify a file or a set of ...


7

Make assumes that an exit code of 0 means success, anything else means failure. This is the standard convention used by almost all command-line tools. Unfortunately, diff is not one of those. Checking the GNU diff info page, and also the Single Unix Specification "diff" entry, 0 means no differences found, 1 means differences found, and ≥2 means error. You ...


6

From the man: -pnum or --strip=num Strip the smallest prefix containing num leading slashes from each file name found in the patch file. A sequence of one or more adjacent slashes is counted as a single slash. This controls how file names found in the patch file are treated, in case you keep your files in a ...


6

I think you are looking for Ksplice. I haven't really followed the technology so I'm not sure how freely available the how-to information is but they certainly have freely available support for some Fedora and Ubuntu versions.


6

You might want to take a look into patchutils [1]. For the vim part, I wrote a small vim plugin that helps with navigating in patches: diff_navigator [2]. [1] http://cyberelk.net/tim/software/patchutils/ [2] http://www.vim.org/scripts/script.php?script_id=2361


6

Just in case it helps someone, if you are using bash script then the example given by Omnifarious would not work. In bash the exit status of a successful command is 0 So the following would work: patch -p0 -N --dry-run --silent < patchfile 2>/dev/null #If the patch has not been applied then the $? which is the exit status #for last command would ...


6

You'll need patchutils installed for this. This script will split one large patch into smaller separate paches, each of them containing only one hunk for one file. You can then apply these patches with patch --forward. #!/bin/sh -eu PATCH=$1 OUTDIR=$2 test -f "$PATCH" && test -d "$OUTDIR" TDIR=$(mktemp -d) trap 'rm -rf $TDIR' 0 INDEX=0 ...


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 ...


5

Try rlwrap -c patch -i patch.diff rlwrap tries do add readline functionality to commands that lack it. There exists a couple of alternatives to rlwrap. If you're a zsh user, you may also have a look at Using zsh's line editor to wrap around subprocesses and at /usr/share/zsh/functions/Misc/nslookup for an example of how to add the zsh line editor to a ...


5

The process is clearly defined in the kernel source code. system1:/usr/src/linux/Documentation # ll SubmittingPatches -rw-r--r-- 1 root root 28473 Dec 2 2009 SubmittingPatches They go over every step you have to take. It looks like email is the only way. I would recommend getting another free account or simply mail it from your laptop using nail | mail ...


5

Somewhat off-topic, I guess but I still think it's useful. If you use git to do your development you can easily split your whole changes into smaller "hunks" that embody one feature each. You end up with one commit per feature and can use git's git-format-patch to create (and even sign and properly attribute) patches, I outlined how to do that here


5

To tell patch not to produce backups just omit the -b and any --backup-... options. To instruct it not to create .rej files add -r - option to the command.


5

http://marc.info/ has a link for each message to get the raw body, and https://lkml.org/ has (in the sidebar) links to download any contained diffs. There are also archives with NNTP access that may provide raw messages, though I haven't tried this.


5

diff has an option to ignore whitespace changes (-w), same for patch (-l). In general, it's a bad idea to ignore whitespace though, so you should reserve its use for special cases, when someone's editor did something horrible...


5

These are called "patchset". Patchset are groups of patches that serves the same functionality, are related, or implement a function in steps. These in particular, are the difference between a major revision of the kernel (X.Y) and subsequent minor/maintenance revisions (X.Y.Z) with several proposes: Save space on the servers. Save bandwidth. Being easily ...


4

Wiggle (git://neil.brown.name/wiggle) can do this, and has a Debian package


4

As Gilles says, you'll need to use a tool that knows about the format of your config files. For your particular example, you can use a short Python script that uses the built-in ConfigParser module. First, let's say your original configuration file on the server is original.cfg: [config] ip=127.0.0.1 port=22 Now put your changes in a new file called ...


4

This is a general problem with diffs copied/pasted into text file without space indentation. You need to add space in front of each line except for symbols "+", "-" and "@@". To avoid this problem, it is always suggested to generated the diff files before in hand (by diff or version control diff tool) and then download the diff file as whole, instead of ...


4

You don't need patch for this; it's for extracting changes and sending them on without the unchanged part of the file. The tool for merging two versions of a file is merge, but as @vonbrand wrote, you need the "base" file from which your two versions diverged. To do a merge without it, use diff like this: diff -DVERSION1 file1.xml file2.xml > merged.xml ...


3

The patch is failing because the other patches that you have previously applied have shifted the code around sufficiently to defeat patch's attempts to apply the change, even with an offset (as can be seen in those hunks that did succeed). If you open dwm.c.rej you will see the failed hunks, then it is just a matter of hand patching them in to dwm.c. For ...


3

Parse them into two separate datasets with whatever program you prefer. I would use common lisp and store each config file as a nested list of lists. And then use language tools to do the merging/patching/union/set-difference/etc. At a high level, for a one side diff, the code might look like: (union (vals A :keys 'all) (vals B :keys ...


3

When you apply a patch to a file, you are overwriting part of it with updated data (a patch can also tack additional data on to the end). You can patch any type of file, whether it's text, binary, or whatever, because all files are streams of bytes when it comes down to it. The parts of it that are supposed to be overwritten are specified in the patch ...


3

The allocators you mention are userspace allocators, entirely different to kernel allocators. Perhaps some of the underlying concepts could be used in the kernel, but it would have to be implemented from scratch. The kernel already has 3 allocators, SLAB, SLUB, SLOB, (and there was/is SLQB). SLUB in particular is designed to work well on multi-CPU systems. ...


3

First of all, you shouldn't need to patch your kernel just because it's not the latest. You would normally rely on your distribution maintainers to do patching. You might need to patch if you had some kind of uncommon hardware, but most of the time, you just need a different or newer kernel module that is supplied separately from the kernel. My current ...


3

I wouldn't really recommend using sed for such a thing. The trouble is, that even if a patch applies it can often be with a "fuzz" - which means, that some of the context lines are not matched perfectly. While this often means that the underlying surrounding code changed slightly, it can also mean, that the patch applied in a wrong place (I've seen this ...



Only top voted, non community-wiki answers of a minimum length are eligible