I've run into an issue with patch (version 2.6) and was wondering if anyone else has run into this problem:
System A: Virtual Machine (VBOX) with FC21. diff == 3.3, patch == 2.7.5
Generate a Linux kernel patch for ixgbe driver (updating driver to support new HW)
Orig directory: linux/drivers/net/ethernet/intel/ixgbe
update dir: /home/patches/ixgbe-4.0.3
Patch file generated via diff -Naur <orig> <update> > file.patch
File looks OK. There are changed files as well as "new" file being added to the Orig.
Using BuildRoot (2015.08.01) and their patching setup, the patch executes, and works just fine, the driver builds and the image boots.
System B: Corp Server with RHEL6. diff == 2.8.1, patch == 2.6
Copied the entire Buildroot setup to this machine. Modify directory paths and the build runs OK, up until the patch. Output shows that changed files get updated OK, but any "new" file ends up in the "update dir" path, which doesn't exist in this environment. Verified the /home/xx/yy/zz directory DOES exist, that patch created from the filename in the patch file. Why????
System A works just fine, it puts the "new" file in the correct kernel directory.
Anyone seen this strange behavior before? How can I:
tell diff to use the orig directory?
tell patch to use the orig directory? (Build root handles patching via scripts)
Any assistance would be greatly appreciated. . .
Stephen
TL;DR: to generate the patch, make sure the original and modified directories are side-by-side.
Patches will be applied with -p1, i.e. the first component of the paths will be stripped off. So on the original side, you'll have drivers/net/ethernet/intel/ixgbe/<filename>, but on the patched side, you'll have home/patches/igbe/<filename>. Now it looks like patch 2.6 will take the path at the patched side, which clearly doesn't exist. I'm actually surprised that it does work with later patch versions.
The canonical way to generate patches is to make a copy of the full original source directory, i.e. the entire linux directory, and put that side-by-side with the patched directory. Then you do diff -Naur linux-orig linux-patched from the directory just above. Or, better yet, start from a git-controlled linux directory, make the modification, commit the change, and do git format-patch -1 -o <path-to-buildroot-patches>.
Related
I have a Yocto build for i.mx6 and I want to modify its Kernel. I figured that if I copy Kernel source outside the Yocto project and make my modifications without dealing with patches, I can speed things up significantly. But the thing is, the Kernel source I have to use is already patched and I want to fetch and continue working from there. I will work on the already-patched source files and re-arranging them is a painful process.
For starting point, my patches work fine, and I can get a working image using bitbake fsl-image-multimedia-full command. The Kernel source I want to use is created after this process.
I have tried copying the source under ..../tmp/work-shared/imx6qsabresd/kernel-source. Although make zImage and make modules finished without any trouble, manual building was not successful with an error in a dtsi file (Unable to parse...). Of course, I have checked the file and there was no syntax error.
Also, I checked the kernel source files I copied and it seems that the patches are successfully implemented.
Am I doing something wrong with the patches? With my manual build routine, I can build unpatched kernel source with no errors. I am sure that there are experienced Yocto users here that have their own workarounds to make this process shorter. So, any help is appreciated. Thanks in advance.
You can also edit files in tmp/work-shared/<machine>/kernel-source then compile modified kernel with bitbake -C compile virtual/kernel
My favorite method of doing kernel development in a Yocto project is to create an SDK and build the kernel outside of the Yocto system. This allows more rapid builds because make will only build new changes, whereas a kernel build within Yocto always starts from scratch.
Here are some of my notes on compiling the Linux kernel outside of the Yocto system. The exact paths for this will depend on your exact configuration and software versions. In your case, IMAGE_NAME=fsl-image-multimedia-full
Run bitbake -c populate_sdk ${IMAGE_NAME}. You will get a
self-extracting and self-installing shell script.
Run the shell script (for me it was
tmp/deploy/sdk/${NAME}-glibc-i686-${IMAGE_NAME}-cortexa9hf-neon-toolchain-1.0.0.sh),
and agree to the default SDK location (for me it was
usr/local/oecore-i686).
Source the scripts generated by the install script. I use the
following helper script to load the SDK so I don't have to keep
track of the paths involved. You need to source this in each time
you want to use the SDK.
enable_sdk.sh:
#!/bin/bash
if [[ "$0" = "$BASH_SOURCE" ]]
then
echo "Error: you must source this script."
exit 1
fi
source /usr/local/oecore-i686/environment-setup-corei7-32-${NAME}-linux
source /usr/local/oecore-i686/environment-setup-cortexa9hf-neon-${NAME}-linux-gnueabi
Copy the defconfig file from your Yocto directory to your kernel
directory (checked out somewhere outside of the Yocto tree) as
.config.
Run make oldconfig in your kernel directory so that the Linux
kernel build system picks up the existing .config.
Note: you may have to answer questions about config options that
are not set in the .config file.
Note: running make menuconfig will fail when the SDK is enabled,
because the SDK does not have the ncurses libraries set up
correctly. For this command, run it in a new terminal that has not
enabled the SDK so that it uses the local ncurses-dev packages you
have installed.
Run make -jN to build the kernel.
To run the new kernel, copy the zImage and ${NAME}.dtb files to
your NFS/TFTP share or boot device. I use another script to speed
up the process.
update_kernel.sh:
#!/bin/bash
set -x
sudo cp /path-to-linux-source/arch/arm/boot/dts/${NAME}.dtb /srv/nfs/${DEVICE}/boot/
sudo cp /path-to-linux-source/arch/arm/boot/zImage /srv/nfs/${DEVICE}/boot/
set +x
You can also point Yocto to your local Linux repo in your .bb
file. This is useful for making sure your kernel changes still
build correctly within Yocto.
SRC_URI = "git:///path-to-linux-source/.git/;branch=${KBRANCH};protocol=file"
UPDATE: Over a year later, I realize that I completely missed the question about broken patches. Without more information, I can't be sure what went wrong copying the kernel source from Yocto to an external build. I'd suggest opening a Bitbake devshell for the kernel and doing a diff with the external directory after manually applying patches to see what went wrong, or just copy the source from inside the devshell to your external directory.
https://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#platdev-appdev-devshell
When debugging certain commands or even when just editing packages, devshell can be a useful tool. When you invoke devshell, source files are extracted into your working directory and patches are applied.
Since it can't parse it, there seems to be a problem with patch. How do you patch the device tree? Are you patching it in the .bb file?
If so, check your patch for possible syntax errors, it's very easy to overlook the syntax errors in device tree. You can remove the patch and do it manually from bitbake -c devshell <kernel-name>
If not, please try to do it there and check again. Please share results if any of these helps you.
I am using Tortoise SVN and Visual SVN Server.
Here is how I am using SVN:
Export Code from Windows7 System and then Copy all code Files to my Fedora System
Make required changes.
Then I Checkout on Windows7 System.
Then Copy All code files from Fedora System to windows7 system.
Then paste in Folder where I checked out.
At this point when I check for modified files. SVN shows me all files as modified, even though they are not modified by me.
Also when I diff unmodified files by me no change is shown, but svn shows that file with red icon.
Could someone please explain the solution this issue?
Note: On Fedora System I am using QT Creator to edit code files. This issue observed with .txt, .cpp, .c files only not with qt ui files.
You can find here how TortoiseSVN finds out if a file is modified.
You should look at the file metadata (date of creation/modification, ownership, etc.)
Edit: If you have issues with end-of-line markers, you can modify SVN behaviour with the svn:eol-style property. See this page for Tortoise configuration.
I am trying to add a patch to a Debian package (on an amd64 machine running Ubuntu 14.10 "Trusty").
While troubleshooting the issue, I've reduced the patch to one that adds a single file. (For the sake of context, this file modifies a fluxbox package so that it also creates a fluxbox-dbg file with debugging symbols.)
I created the patch by following these steps:
(Made sure I had all existing patches applied.)
quilt new add-dbg-package.patch
quilt add debian/rules.d/70-debug-symbols.mk
(Created that file with the contents I wanted.)
quilt refresh
The patch seems fine:
With all patches applied, the file exists and has the correct contents.
The patch contains a delta that adds the complete contents of the file, and nothing else.
No other patch references the file.
When I pop the new patch, the file is removed; when I push it again, it is recreated.
However, when I try to rebuild the package with debuild, I get this:
The next patch would create the file debian/rules.d/70-debug-symbols.mk, which already exists! Skipping patch.
1 out of 1 hunk ignored
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'add-dbg-package.patch' is correctly applied by quilt, use 'quilt refresh' to update it
If I take its advice, quilt tells me that the patch is up-to-date (as it seems to be). quilt diff tells me that there are no changes.
As one thought: is it incorrect to add quilt patches for changes to Debian control files?
Can anyone help me understand what I've done to offend debuild?
You should not add quilt patches over /debian/ files. The patches are for the code only. Just change the debian/rules.d/70-debug-symbols.mk file and build the package.
The Debian/Ubuntu policy says:
The program quilt offers a basic method for recording modifications to the *upstream source* for Debian packaging.
I have a linux eclipse project checked into our company svn. Works great.
The project is intended to be cross compiled on Windows.
Untill now, I have simply moved the source files between OSes. However, I thought I'd like to let svn do this for me. Should be simple enough, just checkout the eclipse linux src into the VS project dir, right? Wrong!
The correct source was checked out of svn and it worked fine. But when I tried to check it back in i kept getting "Commit not completed filename remains in conflict" errors. I hadn't even changed anything!
Did a little checking. Turns out the linux src directory is pretty much just the source and headers. On the MSVS side the project directory contains the source and headers but also contains a bunch of files that are used by VS with names like projname.vcproj etc. etc.
So, I did a checkout into a scratch dirextory, .\fred. Checked .\fred back in. No problems. Added a new file to .fred, xxx.xxx. Check in reported:
svn: E200009: Commit failed (details follow):
svn: E200009: 'C:\Projects\fred\xxx.xxx' is not under version control
Makes me wonder about those uncommitted Visual Studio files.
So, are those files my problem? Are they breaking the commit operation?
As an alternate solution I am thinking of adding the VS files to the src dir in svn. If linux/eclipse checks them out I can tell eclipse to ignore them (I think it'll just ignore them for me). Any thoughts or recommendations for this approach?
(BTW, i still had fresh source on the linux side so any thing that got clobbered could be safely restored.)
So here is one solution I have working for the moment. I am not sure how totally stable it is.
Caveat: The project i am using already existed as a MSVS project.
In the MSVS solution dir, rename the source dir (MSVS likes the source dir name to match the solution dir name, so this means the source dir may not be named src) to something uninvolved in the solution, like temp.
SVN checkout the src (eclipse like to call source dirs src).
cd into the source dir. Issue the command:
svn changelist msvs *.cpp *.h
Add *.c if needed. "msvs" is the changelist name. It can be whatever you want ti to be.
This will created a changelist for the checked out directory.
Now, copy the remaining files from the temp directory into your source dir.
When you need to do a checkin, cd into the source dir and issue this command:
svn ci --changelist msvs
Note. You have to be in the src dir for this to work.
I need to apply a patch to the vim source code, but I am having trouble finding the source code for version 7.3.285. The source code from the main vim site builds version 7.3.154. When I do a google search for "vim 7.3.285 source" I get mostly .rpm files and always something about Mandriva. I managed to find a .scr.rpm file and unpacked it, but then the main vim folder it had was exactly the same as the one on the vim site. My guess is that I have use the patch folder to apply the patch to version 285. So I tried the following:
Download .src.rpm file here
unpack .src.rpm file like so rpm2cpio vim-7.3.285-1.src.rpm | cpio -idmv --no-absolute-filenames
apply the patches to the vim73 folder somewhat like so for i in 'seq 0 285'; do patch -p0 < ../vim-7.3-patches/7.3.$i; done
then I also applied the aforementioned patch in a similar way patch -p1 -i ../vim-7.3.285-breakindent.patch
finally I compiled vim: configure, make and sudo make install
However, and this is where it gets weird, if I issue the command vim, it claims to be running version 7.3.285. If however, I issue the command gvim it claims to be running version 7.3.154. It was my understanding that you compile vim and gvim gets compiled too. Does anyone have any idea what is going wrong? Is there a 7.3.285 source file I can download instead to test out?
to get the 7.3.285 source clone the mercurial repo and then do hg up v7-3-285
full instructions here