Hmm. If you are really installing kernel-module-<your name> to the image, at a glance, what you have really should be enough. Can you confirm that you are seeing your .ko on the image, and that it jus

Can you provide your recipe ? It would make suggestions easier. For example, my first question is: Is the module being installed to your image via IMAGE_INSTALL, or some other similar variable ? Bruce

The defconfig + fragment wouldn't have been ignored, but it is also possible that other settings / fragments were applied that are making it look like they were not applied. Can you look at your kerne

It's Monday, and I've only had half a coffee .. so bear with me. When I see i686, I'd expect that without -m32 it is generating 64bit by default .. so there's definitely a -m32 sneaking into the defin

For the most part the kernel builds do not take any flags from the outside, i.e. they are all generated based on the kernel build structure, not what is calling the build. (unless you bury flags into

Signed-off-by: Bruce Ashfield <bruce.ashfield@...> --- This goes along with the series just sent to oe-core to remove 4.14 and introduce 4.19 as the LTS (and LSB) kernel. Bruce meta-poky/con

I've tweaked the message and added this to my queue. It will come out early this week. Bruce

This should say "not always one space". There really should always just be a single space, but typos do sneak in. I'll queue the patch shortly. Bruce

Without being able to see the code that defines those CONFIG_ symbols, I can't say for sure. But if the fragment was located and added to the config queue, then the only real way that they wouldn't be

The reference machines with linux-yocto don't use defconfigs at all. They are fully assembled from the configuration fragments in the kernel-cache repo. You'll see the location of the kernel-cache, an

If you check the 4.4 tree, and the kernel-cache, I've pushed the latest set of -stable updates. Up to you if you want to bump the SRCREVs to pick them up, but I've validated them with my builds/boots.

Did you want .162 ? I have a whole set of -stable updates staged here, but haven't pushed anything since releases are imminent. But in the case of 4.4, I could lift my freeze, given that the kernel re

Thanks Kevin! I had missed that detail in my reply. Bruce

Doesn't look like it. I'd suggest sending a patch to the yocto mailing list, that way folks can comment directly and it can be pulled into point releases, etc. Bruce

The recipe name and the packages that you install are not (always) the same thing. i.e. in the recipe: PACKAGES =+ "libavahi-gobject avahi-daemon libavahi-common libavahi-core libavahi-client avahi-dn

That is what we normally do. See the old perf patches. They test for the issue, and then sed the change if required. Bruce

Also agreed. That was my primary suggestion as well, since even with that slow pace, we'd have it in all the kernel trees by the next Yocto release window. Bruce

Yup. That works too (as would a variable from the env), but we'll still need a sed based patch in the short term. Bruce

I'm ok with this type of solution as well, since this is similar to what we've had to do with perf in the past (sed and modify versus patching). I can always patch and fix things in linux-yocto, but t

This looks good to me. Also note that I have an outstanding bugzilla to see if I can invalidate stamps, etc, when these elements change .. so at that point, I'd be able to fixup this documentation sec