search

meta-rust / cargo-bitbake

cargo extension that can generate BitBake recipes utilizing the classes from meta-rust
Apache License 2.0
83 stars 57 forks source link

Is this repo still maintained? #77

Open fnerdman opened 3 months ago

fnerdman commented 3 months ago

I see multiple important PRs, solving many of the issues raised. Is this repo still maintained?

mprt commented 1 month ago

@kraj @cardoe do you have any information regarding the status of this repo? Do you need any support?

cardoe commented 1 month ago

I haven't been involved in a Yocto project for years now. I turned over maintenance to others and had thought that Yocto proper picked up some of these tools.

Are you wanting to take over maintenance?

rwmacleod commented 1 month ago

I was a bit surprised that meta-rust continued to be maintained for a few years after Rust was merged into OE core. I think the main goal was to be able to use meta-rust primarily with dunfell branch projects in order to pick up newer versions of Rust. Is that accurate?

There are now mixin layers to use newer versions of Rust on kirkstone now: https://git.yoctoproject.org/meta-lts-mixins/log/?h=kirkstone/rust

Also, we are often blocked from updating Rust in oe-core/ master due to our self-imposed requirement to have the build be reproducible.

All of this is just background info for those thinking of continuing to maintain meta-rust. From my (selfish) point of view, it would be better to declare this layer obsolete and have more people work together in oe-core but I'm interested to hear what other people think.

g0hl1n commented 1 month ago

Apart from the state of meta-rust (as @rwmacleod mentioned an I agree with): What's the planned future of this repo (cargo-bitbake)?

Is there any other (preferred) way of getting rust projects into OE layers that I've missed?

If not: Please keep this tool maintained and evolving as there are some PRs open that IMHO should be merged/followed up on!

In case you need help please reach out to me. My workflow depends on this tool regularly and I'm willing to put some work into it.

mprt commented 1 month ago

I haven't been involved in a Yocto project for years now. I turned over maintenance to others and had thought that Yocto proper picked up some of these tools.

Are you wanting to take over maintenance?

I thought this issue was only referring to cargo-bitbake and not the yocto layer. Sorry for bothering/mentioning you - I just wanted to raise some dust, i.e. get the attention of someone who could answer @fnerdman's question.

I'm certainly neither experienced nor qualified enough to take over the maintenance, but I'm willing to support where I can.

paolobarbolini commented 1 month ago

We'd also like to help where we can. We currently use our own fork, but we'd like to see something supported out there, and help in that effort where possible.

To me meta-rust looks like a hack at this point. I feel like what should happen is that Yocto backports Rust upgrades to previous versions and keeps up with them. I'd like to try and contribute, but I haven't figured out how to do that yet, and the barrier to entry keeps me from trying to upstream my patches.

rwmacleod commented 1 month ago

Here's a proposal, does it make sense?

Newer versions of Rust on old branches should be done using a mixin layer:

We have one for kirkstone now: https://git.yoctoproject.org/meta-lts-mixins/log/?h=kirkstone/rust

A mixin layer for scarthgap is needed. Dunfell, like other non-LTS branches, is no longer maintained.

Updates will happen in oe-core/master first and they must pass all the tests including the troublesome reproducible build tests. The updates can then be brought back to the mixin layers.

The meta-rust layer can either be declared obsolete by moving any remaining recipes ( cargo-bitbake ) into oe-core or meta-oe .

This is a bit complicated, let me explain why we have the mixin layers. For those who don't know, I proposed that we simply upgrade to the latest version of Rust in supported branches of oe-core directly but despite the Rust upstream saying that this is the correct approach to fix CVEs and other bugs and that newer releases of Rust will never break old code, the Yocto TSC remained skeptical and in the interest of users decided to leave the version fixed in a release branch. The suggestion was to create and maintain the mixin layers for some time and if that proved that newer Rust never broke older code, then we could revisit this policy.

Did I miss anything? Do people agree that the proposals made should be implemented?