2

I have two repositories, A and B, which have a common ancestor. A then has a branch with a specific patch (let's call it C) and I would like to apply this patch to B. I believe it is important to notice that this patch has been applied through several commits, on top of the mainline kernel, since it is an ongoing project on the mainline kernel.

My initial plan was to:

  1. Clone C and B into two local repositories.
  2. Merge B and C, resolving conflicts.
  3. Create a Yocto Layer based on this patch.

The goal is to have a layer that, when put on a recipe on B, applies the patch on B. I am not sure about my first two steps (or if there is any better way of doing this), and my last step seems yet very confusing to me, specifically on how would it be done in practical terms. For now, I have no interest in the branches' history.

To be more specific (I don't know if this helps): Branch C is a mainline Linux kernel with a specific patch. Branch B is a different kernel, although it is the same version as in C (5.4). I want to apply the patch from C in B.

What is the best (if any such thing exists) approach to achieve this?

Mölp
  • 142
  • 9
  • If you own A and B, why not just apply the C patch manually to it and be done with it? Otherwise, I really don't understand what you want to do. You need to give the actual end use-case because it seems to me you're focusing on debugging a choice you made rather than asking for a way to do something. Why do you not apply C manually to B and create a recipe or bbappend for the recipe handling B? Why does it need to be done in Yocto? Why do you need a separate A and B? Do you need to build both kernels A and B? If so, why? What role do they play in your build? – qschulz Dec 09 '20 at 20:32
  • The goal is to have a Yocto layer that once added to a project working in B, it applies the patch to B. I cannot apply the patch directly to B because it modifies several files from the kernel; more importantly, I cannot obtain only the patch online, but only the mainline kernel with the patch. It needs to be done in Yocto because that's what I am working with. "The choice" I made is just an idea, I am of course open to any other suggestions.I don't need a separate A and B, that's what I currently have. – Mölp Dec 10 '20 at 08:58
  • Continuing to answer your questions: A doesn't have any role in my build, it is just a mainline kernel. – Mölp Dec 10 '20 at 09:05
  • Many commits touch multiple files, that's fine. If you have one commit you want from mainline, `git clone` the mainline kernel, then `git format-patch -1`. This will create one patch that you can then apply to B. If it does not apply cleanly (probably won't), you need to resolve the conflicts manually (in a `git clone` of B if you want) and then create the patch for it (still `git format-patch`). Take the patch (a file), add it to the recipe for B. Voilà. Does this work for you? If not, which part? Why? – qschulz Dec 10 '20 at 19:09
  • I don't think it works because the patch was not done in only one commit, but it is an ongoing project, with several commits. I could select a specific point in history (i.e a specific commit) that I want, but I don't know whether this will also bring everything that was ever added in the form of other commits. – Mölp Dec 11 '20 at 09:42

1 Answers1

-1

You can check out the single files (e.g. the patch) and store it locally (file protocol fetcher, SRC_URI="file://xyz.patch"), then apply it to the mainline kernel that you get via git (for a patch to work only path and filename have to be correct)

How to sparsely checkout only one single file from a git repository?

In this thread is another solution : Give each SRC_URI a name and use it it SRCREV overrides:

https://www.yoctoproject.org/pipermail/yocto/2015-July/025588.html

https://docs.yoctoproject.org/ref-manual/ref-variables.html#term-SRC_URI

ralf htp
  • 9,149
  • 4
  • 22
  • 34
  • What if the patch modifies some of the already existing, basic code of the Kernel? – Mölp Dec 09 '20 at 12:16
  • The steps are fetch(), patch(), configure(),... so basically you only have to know which file to patch and where it is located, see i.e. this recipe https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-graphics/libgles/sunxi-mali_git.bb . Beside this recipe has severe flaws but the SRC_URI stuff is accurate – ralf htp Dec 09 '20 at 12:30