Layer does not support Scarthgap

[epc-aapo]

Version(s) of meta-rust

1.78

Version(s) of poky and/or oe-core

Scarthgap

Expected result

Build succeeds

Actual result

build$ bitbake core-image-minimal
ERROR: Layer rust-layer is not compatible with the core layer which only supports these series: scarthgap (layer is compatible with hardknott honister mickledore kirkstone gatesgarth)

Steps to reproduce

Add meta-rust layer to bblayer.conf and attempt to build against the latest LTS Scarthgap.

[neusoft-zhangboqi]

+1

[epc-aapo]

Updating Yocto release to Scarthgap and removing meta-rust from bblayers.conf seems to resolve this issue. I guess this meta layer is not being actively maintained anymore since it has been merged in the openembedded-core.

[kanavin]

For the purpose of backporting newer rust onto older Yocto releases (including scarthgap), the official place for such work is https://git.yoctoproject.org/meta-lts-mixins/

I'd suggest everyone to focus their efforts there, and mark this layer as deprecated and no longer maintained for anything reasonably recent.

[be-neth]

And the purpose of using rust compiler with a different version that the one provided by meta ? Do you have a nice solution instead of using meta-rust ?

I am not sure with your suggestion, I would like a way to change or update rust version from the one from meta. I will try to check on Scarthgap, and propose a nice way to still fetch meta-rust in Yocto for this purpose without duplicating stuff from what we already have in meta.

[kanavin]

And the purpose of using rust compiler with a different version that the one provided by meta ? Do you have a nice solution instead of using meta-rust ?

Yes, we do: https://git.yoctoproject.org/meta-lts-mixins/

[be-neth]

And the purpose of using rust compiler with a different version that the one provided by meta ? Do you have a nice solution instead of using meta-rust ?

Yes, we do: git.yoctoproject.org/meta-lts-mixins

Sorry, but from what I understand, this is not the same purpose. What about using rust 1.80.1 today with Yocto Scarthgap, you cannot from what I know.

Using meta-rust, I can (in fact not today, but very soon, I need to send a PR), and it is very simple to change rust compiler version. (And that very important especially with a language without a stable ABI).

What do you think of the idea to keep meta-rust for this purpose ?

[kanavin]

Yes, we do: git.yoctoproject.org/meta-lts-mixins

Sorry, but from what I understand, this is not the same purpose. What about using rust 1.80.1 today with Yocto Scarthgap, you cannot from what I know.

It is the same purpose, and you can. But you first need to update to that version in oe-core master, then backport it to a LTS branch in meta-lts-mixins. This is specifically so that all bug fixing and backporting for newer versions onto older yoctos happens in a controlled manner, and happens just once.

Using meta-rust, I can (in fact not today, but very soon, I need to send a PR), and it is very simple to change rust compiler version. (And that very important especially with a language without a stable ABI).

Apologies, but this is only simple because there's no github CI that validates your PRs (or even an informal definition of what needs to work), and you seem to run very minimal manual tests with such updates. And no one seems to be addressing any of the many open issues. In oe-core, there is CI, and it does find issues that have to be resolved before anything merges.

What do you think of the idea to keep meta-rust for this purpose ?

My problem with meta-rust is that it's a duplication of effort, and the result seems to be of lesser quality than what is in core judging by all the open issues. We do need competent people to update rust in core, there are not many of them around, and I would very much like to convince you to contribute there.

[be-neth]

Alright then, I will start trying to contribute directly in oe-core for rust compiler update and maybe help in meta-lts-mixins.

And thanks for clarifying.

[kanavin]

Thanks!

I take back the lack of CI here on github; it does exist. From what I can see it only checks that rust-hello-world builds, but there are no runtime checks or execution of rust test suite or a check for binary reproducibility, or verification across multiple hardware targets and build host distributions or SDK tests. In oe-core, there is all of the above and more.