I'm on something like poky master: 5d88faa0f35f0205c1475893d8589d1e6533dcc0 = patch in hello-in-tree.scc = In case I do something like this (which worked until recently): cat hello-in-tree.scc define KFEATURE_DESCRIPTION "In tree hello world" define KFEATURE_COMPATIBILITY all patch yocto-testmod.patch kconf non-hardware hello-in-tree.cfg 2 strange things are happening: 1) The patch is suddenly applied each time I try to build the kernel - with and without modifying stuff (e.g. build an "out of tree" kernel module) This works only the first time and fails the second time (which does not make sense, but it happens because the patch is being applied also the second time) 2) No Upstream-Status check of the patch is done == patch in SRC_URI == In case I remove the patch from the scc file: cat hello-in-tree.scc define KFEATURE_DESCRIPTION "In tree hello world" define KFEATURE_COMPATIBILITY all #patch yocto-testmod.patch kconf non-hardware hello-in-tree.cfg and add it to my kernel recipe: ... FEATURES_PATH="${THISDIR}/linux-yocto-custom/features/" SRC_URI += "file://${FEATURES_PATH}/yocto-testmod.patch" ... 1) It behaves as it should (no attempt to apply it every time), so it does not fail the second time. 2) I need to include in the patch the Upstream-Status ... Subject: [PATCH] Yocto kernel module Upstream-Status: Inappropriate [res specific] ... ====== How should the behaviour be? Is "patch yocto-testmod.patch" in an scc file deprecated?
From what I see here[1] I suspect a patch from an scc file should still work. [1] https://git.yoctoproject.org/yocto-kernel-cache/tree/features/aufs/aufs.scc
... and that it bypasses the Upstream-Status check as can be seen here[1] [1] https://git.yoctoproject.org/yocto-kernel-cache/tree/features/aufs/aufs-fix-v6.7-kernel-build-compilation.patch
I'm out of the office until the 9th, but will comment quickly. I suspect this is due to the WORKDIR changes that went into master recently. kernel-yocto manages patches itself, and does track the queue of patches so it can detect if it is fully applied. BUT, if the do patch task is being run, it will re-run the process. If a fence post isn't found, it will try and repatch. So there's one of two things that changed. 1) the fence post isn't being found 2) the do_kernel_metadata is always been run when it shouldn't be. Since kernel-yocto manages the patches itself, it doesn't have the same QA checks as the quilt or basic git based patching. The patches in the kernel-cache won't ever get Upstream-status fields, so adding the check for patches applied from .scc files isn't something that I'll be adding. I'll run some tests next week and have a look at what's changed around the task hash or the fence post.
I should add, that the second mode that is checking the upstream-status means that the patching by kernel-yocto.bbclass is somehow being avoided/skipped and that should be the case. That is something that has always been previously overriden, it could also be that interaction that is causing the double patching.
Thanks Bruce. I will try to perform some more tests. It's possible that I included the same .scc file multiple times by mistake (because I ran my automated tests a couple of times).
The patch is applied twice because my testing scripts added the same .scc file twice. I guess the handling of patches without Upstream-Status is intended. We can close it.
Aha. No worries, I'm glad that it is working now. In theory, a duplicate .scc inclusion could be detected and some sort or warning thrown. I'll see if there's an easy way to do that. I'll also see about allowing QA checks to passthrough to linux-yocto applied patches that are passed on the SRC_URI. It is just the kernel-cache ones that have their history tracked in the git repository, so don't need the status in patches. I'll leave this open to remind myself to look into both things.
Bulk move as requesting during YP BB meeting.
Moving off old milestone per bug cleanup (to 6.2 M4).