master branches in the
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.
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.
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-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
- 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.
That sounds like a good plan. I will hopefully be able to do so next week.
The branch is prepared at https://github.com/mendersoftware/meta-mender-community/tree/kirkstone-next. It’s mostly locked down via
bb.fatal at the moment, and I will ping maintainers to look into it soon.
If anything else is blocking you, let me know.
@zach-welch-aquabyte, a short heads up:
GitHub - TheYoctoJester/meta-mender at master-next should give you a current, buildable state. If you run into problems, please let me know.
@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-raspberrypi) to produce their own
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.
It’s been a couple months; any update on when a production release supporting kirkstone might drop?
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”.
Thanks Kristian, and best of luck to you and the team!
Q. have you guys been pushing your work in progress to the ‘next’ branch?
That’s all of the work in that link, and it is about to be merged to
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
The OpenSSL issue has already been fixed, but there is no client release yet which has it included. Try setting this option in your
PREFERRED_VERSION_mender-client = "master-git%"
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.
systemd-boot is not being tested by us since it was a contributed feature. Looks like somebody needs to pick this up and refresh it.
This is fine but
master-next is not compilable due do_path error in systemd-boot. So maybe can be dropped in this branch? Thanks.