Since the last commit was submitted over one year ago it might be worth to fork this repo in order to maintain that by the community to have support of the latest yocto releases without any obstacles.

Forking is not the problem, its about having people who are committed to maintain the project.
We could wait for those to appear, or for MS to show some more dedication, or we could just go ahead and see where it gets us.
I've setup a new team and forked this repo over there, have a look: https://github.com/Azure-yocto/meta-iotedge.
It's not much at this moment but hopefully it will grow over time.
Feedback is much appreciated.

Indeed, let's have a mirror of this repo that supports the zeus release and wait for the movement of Microsoft guys because that will be wrong/difficult/superfluous to maintain both repositories in long term.

I apologize for the inactivity on this repo. We have a PR for 1.0.9.4 on Zeus (#45) and 1.0.9.4 was just merged to the Thud branch (#40). What Yocto release are you most interested in?

One thing to note is that we should be using the branch corresponding to the Yocto release, not the master branch. There hasn't been any activity on the master branch for quite awhile, but there has been some activity on the other branches. I just updated the Readme to discuss this.

Long term, we are looking at cutting a long term service release of IoT Edge itself and would like to get this version stable on Yocto as well. Ideally, the focus is on Dunfell, the LTS relase of Yocto.

@myagley Cool, my team just updating Yocto from Thud to Dunfell and meta-iotedge was a showstopper. I hope #43 is merged soon!

Looking forward to #43 as well!

For our devices we're using the Sumo branch (on Yocto Rocko). I recon its in the best interest of everyone to update to Dunfell, however many small teams rely on the BSP provided by the SOM manufacturer and they're not always providing the latest. In real life people will be using different branches of Yocto and different versions of IoTEdge. The setup of this repo as it is now is good, but what we need is having PR's and issues handled, not only for the most favored branches. I'm not saying everything should be done by MS engineers, we need a way for community to contribute quality code. Maybe more than maintainer would be welcome?

For example, NXP is currently not supporting Dunfell: https://community.nxp.com/t5/i-MX-Processors/Is-Yocto-dunfell-branch-supported-by-imx-manifest/m-p/1080021

Seems like #46 is merged! @ShepherdDev10 @kbumsik

really need better support, I need 1.0.10 support on zeus/sumo.
There seems to be plenty of PR's that just are not getting merged in a timely manor.

really need better support, I need 1.0.10 support on zeus/sumo.
There seems to be plenty of PR's that just are not getting merged in a timely manor.

You can override the recipes in your own layer, just copying the recipes and change SRCREV etc. That's what I do.

really need better support, I need 1.0.10 support on zeus/sumo.
There seems to be plenty of PR's that just are not getting merged in a timely manor.

You can override the recipes in your own layer, just copying the recipes and change SRCREV etc. That's what I do.

You're completely right, off course it's of anyone's interest that code gets merged in one central place.

You're completely right, off course it's of anyone's interest that code gets merged in one central place.

I agree! Also there's another thing to worry about. The different versions of iotedge-daemon etc are only compatible with certain versions of Rust. To be able to compile 1.2-rc2 I had to update to 1.46 which is the highest version available for Yocto. This could be a problem when iotedge has Rust pinned to 1.47. What if they start using language features only available to 1.47+ and so on?

@myagley There is PR for support for newer rust (needed for #59 as well) and for gatesgarth and hardknott (currently master) Yocto releases in:
#49
waiting for review since Oct 20, 2020.

@geoffrey-vl the https://github.com/Azure-yocto/meta-iotedge doesn't exist, does it mean that you've also given up on your fork after #43 was merged?

@shr-project there wasn't happening any collaboration, hence I've removed that fork.

It would be nice with a clarification whether this repo is dead or not.

Same problem here. I need at least 1.0.10.

Not dead so closing this issue. We recognize we have work to do.

@micahl still looks dead to me, #49 wasn't reviewed in almost a year and in the meantime we had to abandon this layer.

There is this #63 topic that gives a better view on what may be on track, but without releasing a timeline in public. I think you may be interested in subscribing to that topic.

I really don't understand how this issue can be closed.

Even a sideways glance at the stats will tell you that this repo is at best unloved, at worse unmaintained.

https://github.com/Azure/meta-iotedge/graphs/code-frequency

Can we have some more transparency around this repository?

I am bound to yocto by the manufacturer we use for our hardware and the azure iot software suite was a perfect fit to manage our modules.

The lack of compatibility is very concerning, just gotta find a good alternative I guess..

With 1.1.16 release 12 days ago, there's no activity here ... I'm not sure why.
1.1.x is rapidly coming to an end in December 2022, there is already a new LTS - no activity over here.
There's a pull request that brings 1.2.x opened since January 22 - no real activity since February.
Gatesgarth, Hardknott, Honister, Kirkstone (in May 2022) ... I could go on.

It's really looking like this is very much unloved.
With changes between 1.1 and 1.4 it would be really great if there was some sort of overlap to give people time to migrate, but the outlook now is quite unfortunate.

@sindelar-fr we are working on updating the recipes in the dunfell branch to target 1.4 instead of 1.1. For anyone that needs the existing 1.1 recipes there is the dunfell-1.1 branch.