-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync cargo.eclass and drop coreos-cargo.eclass #2028
Conversation
I'll look at fero-client since that's breaking CI. I see there's still an issue with thin-provisioning-tools, as it has a custom |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks! About fero-client
- could you maybe ask on Flatcar channel if we are even using it in SDK? It looks like it would be a part of the release process. Maybe instead of fixing it, we could just drop it. Because otherwise we probably would need to fork it into the flatcar
org as it's archived by upstream.
sdk_container/src/third_party/portage-stable/eclass/rust-toolchain.eclass
Show resolved
Hide resolved
I've fixed up thin-provisioning-tools, as well as aadvark-dns and netavark, which were creating amd64 binaries in the arm64 podman sysext. The fixes aren't actually upstream yet, as the eclass change needs a few days for feedback, and I need to run the other changes by their respective maintainers. They may insist on a revbump, meaning the changes won't be in the stable versions, but hopefully not. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. We will need to remember not to clobber your modifications during weekly updates if they are not upstreamed by the time the weekly updates happen.
Not a problem, if a revbump happens, we will pull the unstable versions then through overlay profiles. |
Thanks for approving. No need to rush the merge though, I'll do it early next week, which should be enough time for the upstream merges. |
We sign releases manually now. Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Cross-compiling is handled in the upstream cargo.eclass now. Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Sync cargo.eclass and drop coreos-cargo.eclass
coreos-cargo.eclass has some hacks to cross-compile with Cargo. I have now added cross-compiling to the upstream Gentoo cargo.eclass using a lot less code, removing the need for awkward tweaks to enable coreos-cargo.eclass. This syncs the upstream changes and drops our eclass entirely.
The
TARGET_*
wrappers that coreos-cargo.eclass set up no longer seem necessary. These worked around an issue with Cargo that was reported many years ago, but I was not able to reproduce it now.How to use
Testing done
I did the above, and also with ue-rs. fero-client doesn't seem to build at the moment for an unrelated reason (Rust too new?), but it was already broken by the coreos-cargo.eclass hacks anyway.
changelog/
directory - Not user-facing./boot
and/usr
size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.