support for Yocto 5.1 LTS (scarthgap) compatibility

[abrahamlincolng]

support for Yocto 5.1 LTS (scarthgap) compatibility

We are currently utilizing the Dunfell LTS branch of the meta-iotedge layer and have plans to transition to Yocto 5.0 LTS (Scarthgap). However, at present, the meta-iotedge layer does not offer support or compatibility with the Yocto Scarthgap version.

Could you kindly consider updating the meta-iotedge layer to be compatible with Scarthgap?

[davidcodesido]

I'm also interested in this. In particular cause the depency with meta-rust is breaking my attempts to build an image with chromium in it.

[moto-timo]

Scarthgap is 5.0. The subject line should be edited. 5.1 is the next development release (Styhead).

[moto-timo]

It would also be nice to finally see the 1.4.33 branch merged, since whenever you run the client it warns that you are not on the latest version.

[ghost]

When is 1.4.33 branch expected to be merged? Also I would like to use 1.5.0 LTS on Yocto Kirkstone can you give me an approximate date for that?

[davidcodesido]

Any feedback here Azure?

[sindelar-fr]

When is 1.4.33 branch expected to be merged? Also I would like to use 1.5.0 LTS on Yocto Kirkstone can you give me an approximate date for that?

Yeah it would be great to have the 1.5.0 available way before November 2024, when 1.4 LTS will be EOLed. It kind of feels like the history is repeating again .... :(

[jolting]

I'm not sure if anyone is working on this, but I got this compiling with Scarthgap.

I ran into some issues as mentioned in #161. It appears that the the Azure/iotedge repo uses git for cargo dependencies, which can't easily be used by meta-rust because it freezes dependencies. Yocto recipes should not do network access during the do-compile stage, so downloading these git repositories is broken. It seems this was not enforced in previous versions of meta-rust and the new Yocto Rust integration uses the freeze option to avoid the network access during the build. You get a error from cargo whining about things being frozen.

The trick is to specify multiple SRC_URIs in your recipe.
See Here: yoctoproject/poky@0d099fa

In the SRC_URI you have to name the repos with the same name as the package name.
jolting@48b6d2d#diff-114791b545f3fe25e3a94a8707e925595ef4bbc4f587acfaf5c9e6287fb8f56eR11-R36

It will automatically setup Cargo to use the local git repos instead of fetching them during build. One caveat is the Cargo.lock files have to be patched to remove the source lines and copied into the target project as well. You also need a separate SRC_URI for each sub package. Also some special care needs to be given to ensure relative paths are maintained because some packages reference other packages using relative paths. Once all those packages are laid out and the git dependencies are patched it seems to build just fine. I'm hoping there is a better way to do this. That's just seemed to be the most expedient way of doing this.

All could be avoided if all these packages were published to some sort of crate server instead of using git for cargo dependencies. Food for thought. It's much more straightforward to consume crates from crate servers. It would avoid all the Cargo lock, git and relative path tomfoolery I had to go through to get this working. Maybe that exists somewhere. Let me know if it does.

I hope that is useful to anyone trying to do a similar thing.
I think I might replicate my efforts for 1.5.0 next. It was a nice learning experience.