I'm porting a layer to kirkstone which as an outdated patch which cannot be applied anymore (to u-boot). Can devtool be used to fix that patch? The problem is that per default devtool modify applies the patches and therefore fails to load the workspace.
The patch refresh is indeed the best method if devtool modify can apply the patches with an offset. When devtool modify fails to apply the patches, one way to update the patches is:
Remove the patches which no longer apply from SRC_URI
Run devtool modify as usual
Port the patches manually and re-commit them
Terminate as usual with devtool finish
Of course, if a patch does not apply because it was integrated upstream, the right solution is to just remove it from SRC_URI.
Related
I made some changes on u-boot source /tmp/work/beaglebone_my-poky-linux-gnueabi/u-boot/1_2018.07-r0/git
When I rebuild with bitbake core-image-minimal. Bitbake is not overwriting images in the path /images/.
Then I used clean, cleansstate, but both of them deleted all my changes in the u-boot/1_2018.07-r0/git directory.
What is the most efficient way to customize the u-boot and kernel?
Thank you.
Changing a recipe's fetched sources directory is not enough to permanently modify source code in Yocto as it is just a temporary working directory that, as you experienced, can be cleaned and all.
Changes to Yocto recipes sources can be made by:
modifying the source code in the working directory
creating a patch for your changes
change/create some recipe to apply your patch
the patch will be applied in build time
This section describes the process of modifying source code and creating a patch:
https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#modifying-source-code
This section describes the process of creating an extra layer and a recipe for the patches you created in order to apply them during build time:
https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#modifying-source-code
Is it good practice to edit source code in poky/build/tmp/work directory ? because if we accidentally cleansstate ,the changes will be erased.
Alternatively we can edit source code in "files" directory along with recipe file but since mostly code here is in zipped form due to large number of files , so we will need to unzip and zip again just to change one line of code.
So what is best way to edit source code in yocto ?
If your question is about permanent changes, then Dan's answer is the one to follow. I.e. add a <recipe name>.bbappend to the recipe in your own layer, in which you add
SRC_URI += "file://mypatch1.patch \
file://mypatch2.patch \
"
enumerating all the patches you need.
If there's a large number of patches, it might make sense to fork the upstream repository, and maintain your own branch in your fork. In that case, you'll likely want to reference your own repository, instead of either the upstream repository or tarball.
OTOH, if your question was more about work-in-progress; then sure, doing it in oky/build/tmp/workoky/build/tmp/work/xxxx will work. (And quite likely, it's what most people have been doing for a long time).
However, there's a much better way in recent releases (from 1.8, fido). The new tool is called devtool. You can use it as follows:
devtool modify -x <recipe-name> <path-to-unpack-source>
unpacks the source and creates a new bbappend to build from the unpacked source. It also creates a git repo in the source directory.
Now you can modify the source. You can test-build your modified source by running devtool build <recipe-name>. Once you're satisfied, use git add ... and git commit to commit your changes to the local repo. Once you've commited the changes to the local repo, you can run:
devtool update-recipe <recipe-name>
to update the recipe in question. When you're satisfied, you can run devtool reset <recipe-name> to remove the temporary bbappend.
See also: Yocto manual on modifying source code
If you are continuously "patching" a given package manually, I would recommend you to look at implementing a .bbappend file in a separate layer which applies your patch using the do_patch function (http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#patching-dev-environment).
I am creating a patch for one of my project in eclipse. I am having eclipse Kepler Release and having installed Subversion client kit(1.7.9.2). After creating patch, I have realized that in patch file, its putting following content related to properties changes.
Property changes on: ao/search_indexes.py
___________________________________________________________________
Added: svn:executable
## -0,0 +1 ##
+*
This is creating a problem when one of my other team member is trying to apply this patch in his environment. He is also having same eclipse and subversion installed on his machine.
Is there a way to tell eclipse to compare only the actual content and ignore any SVN properties related data while applying patch or is there any way to create patch ignoring this SVN properties related changes?
You can manually edit the patch file to remove those lines. The format is pretty easy to follow, it's hard to mess it up, and there is nothing in that patch that will be messed up by removing parts of it. Just be sure to remove entire "hunks" and you'll be fine.
When I make multiple unrelated changes affecting the same set of files, I often create patches with all these unrelated changes mixed together, so I can revert my working copy, split the single patch into multiple, and apply them one by one to commit only one set of related changes at a time.
So far I haven't been able to find a clear answer, though it's possible that the answer is "change your workflow".
I've just started playing around with Mercurial's patch queue and I can see some serious power in it. It seems pretty awesome. In my tests, I've discovered that if you have a patch queue in repo1, and you pull from repo2, you can do some bad things. For example:
Create repos 1, and clone it.
Enable the queue on repo1
Make some commits and some patches on repo1
Pull changes to repo2
On repo1 un-apply(pop?) all your patches
Pull changes to repo2
Now you'll see two different branches - which makes sense from a certain viewpoint. However, since my patches aren't a part of repo1's history (at least until they're applied), it seems like there should be a way to tell mercurial that my patches are off-limits, and only provide what's in the "official history".
Is there a way to do this?
Mercurial phases may be the answer to this.
Starting with Mercurial v2.1, you can configure mq changesets to automatically be marked secret. secret changesets are ignored by incoming/pull and outgoing/push commands.
To enable this behavior, you need to add the following to your config:
[mq]
secret = True
Once enabled, it behaves as follows:
$ hg qpush --all
applying my-patch
now at: my-patch
$ hg phase -r .
16873: secret
$hg outgoing
comparing with https://www.mercurial-scm.org/repo/hg
searching for changes
no changes found (ignored 1 secret changesets)
When creating a patch with the "patch" tool or with the built in "patch"-functionality in svn and then applying it to a source tree, is there any way to easily step back from the applied patch to the previous version?
Apply the patch again in reverse (for example patch -R switch).
svn revert? You can revert to the previous revision (before the patch was applied).