The master branches in the poky and meta-openembedded layers currently are being prepared for the kirkstone LTS release. Many BSP layers already track these branches on their own master branches. For my current project, only the Mender layers lack support for this new release, so… when can we expect new branches? If the release plans and schedule will not be made available publicly, can your commercial customers obtain this information? These details are critical for determining timelines and resource allocations.
Starting with dunfell, I read that Mender will only support LTS releases. For devices already in production, updating from one LTS release to the next will require weeks (if not months) of integration and testing, as that process requires catching up with two years of upstream development. Obviously, I would like to start that process as soon as possible, if only because I expect to contribute improvements/fixes for my target in the meta-mender-community repository (which could add additional weeks/months). I imagine other developers find themselves in a similar situation and are frustrated with the lack of a clear roadmap.
If it will be months before Mender layers become available for kirkstone, then I need to find another path forward that avoids blocking on this feature, even if that means removing mender support during initial development of my board layers. In the future, I hope Mender will prioritize development for new LTS releases to avoid delaying adoption by your customers.
As of now, the master-next branch of meta-mender has preliminary support for kirkstone. This should not be considered production-ready, but should certainly give you a quick start already.
For a timeline, stable support for kirkstone will be available shortly after the official Yocto release.
The meta-mender-community repository is a different beast, though. As you probably noticed, most of the supported boards are tied to a specific BSP version and not exactly following the release branches. For adding your target there, I’ll put it like that: “we’ll make it work”. Whenever you are ready to submit something and the release you want to target doesn’t have corresponding branch yet, ping me and I’ll set it up.
Thank you for the prompt and thorough reply. I will try out the master-next branch early next week.
My initial investigation let me know that I will run into problems with the community-supported layer for my target. Presently, that repo does not have a master or master-next branch, so it will require some broad patches to bring it up to date (e.g. override syntax, variable renaming, and other scripted transformations). Can I talk y’all into running those scripts and pushing them to an interim kirkstone-next branch for subsequent community development efforts? I imagine any such foundational work would be a welcomed by everyone with projects using that repository.
yes right the variable renames. Hm. Actually I don’t feel good about refactoring board supports that are bound to be broken then, just for the sake of syntax compatibility. I fear that this raises very wrong expectations.
Another idea. Does your target rely on anything already in there? If not, then I could give you an empty kirkstone-contrib or such branch as a PR target. If yes, then we would better only adapt the pieces that actually have a chance of being functional.
We do use one of the existing layers in the community repository; an empty branch would break history continuity, so may I suggest a different strategy:
Fork the current dunfell branch to kirkstone
Run all required automatic conversions on the new branch,
Add a bbfatal statement in each layer.conf that explains the need to update it,
Include in that statement a clear deadline for such work to be done,
When the deadline arrives, drop all of the BSPs that never got updated.
@TheYoctoJester Using your branch, I can build mender-client without any extra hacks. Good progress. I plan to start runtime testing sometime next week, and I will post those results here.
@TheYoctoJester I now have successfully performed a major update from my dunfell image to these new kirkstone images (and incremental upgrades from there). Hopefully, the outstanding changes can be merged soon.
Also, I noticed today that the upstream poky repository now contains a kirkstone branch. Does this mean a corresponding mender branch will appear soon, or does that require the assorted meta-mender sublayers’ transitive dependencies (meta-openembedded and meta-raspberrypi) to produce their own kirkstone branches?
The meta-mender and meta-mender-community repositories will get kirkstone branches once we have reached production quality. I personally expect both of the mentioned layers to also follow this practise close to the release by the Yocto Project.
I won’t lie, this integration has been quite difficult, but today I had the first test run where a respectable amount of tests passed. There is still quite a bit of work remaining, which is to fix the remaining failing tests, as well as solving all of these tasks, but now I think we can start hoping for “within a few weeks”.
I had been using the TheYoctoJester/master-next branch to build for kirkstone, but that now fails due to the kirkstone branch being removed from the kacf/mender repository. Meanwhile, the official Mender layer repository still fails to build on the master-next branch, due to the OpenSSL 3.0 compatibility issue that I reported here. Is there a working branch that can be used for ongoing testing? Any further update on the timeline for a kirkstone release?
HI, on actual master-next systemd-boot fails in patch phase. Seems path which is added in meta-mender must be refreshed. Anybody see the same issue or it’s just me doing some stupid thing? Thanks.
