> - add ptest support to the recipe. It must have feature parity with the GNU recipe.
OK, I'll do that in meta-openembedded, since I don't want to mix this change with a move between two repos > - investigate and propose a plan for pseudo compatibility. It's not easy: pseudo relies on substituting libc API, and rust binaries issue kernel syscalls directly. It is doable, since uutils-coreutils already uses the libc crate for many things, and the rustix crate can be configured at build-time to use the libc crate instead of using kernel syscalls directly. On the other hand, PREFERRED_PROVIDER_coreutils is independent of PREFERRED_PROVIDER_coreutils-native, and very few recipes depend on coreutils-native, so I suggest decoupling a potential merge of uutils-coreutils with pseudo support. The target version delivers almost all the value, and pseudo compatibility can follow separately. Or am I missing something? > - propose a test plan for Yocto. Merely sticking it into poky-altcfg is actually a regression in testing, because then sysvinit images will be tested only with GNU, and systemd images will be tested only with uutils. OK, then I'm not sure what's best in terms of testing matrix. I'll need to investigate. > - last, but not least. Actually this is the most important one: fix your relationship with GNU coreutils. It's painful to watch you two bicker, and I do not want the Yocto project to be dragged into this. On the last point: I can see Collin feels strongly about this, and I take the licensing concern seriously. But I haven't been in conflict with him or with GNU coreutils. If there's a specific exchange you'd like me to look at, please point me to it. Étienne On Tue, Oct 13, 2026 at 9:42 AM Alexander Kanavin <[email protected]> wrote: > Alright. Here's a suggested plan for you: > > - add ptest support to the recipe. It must have feature parity with the > GNU recipe. > > - investigate and propose a plan for pseudo compatibility. It's not easy: > pseudo relies on substituting libc API, and rust binaries issue kernel > syscalls directly. > > - address concerns of 'license-washing'. A few of us are deeply > uncomfortable with this recent wave of component rewrites (especially AI > assisted which causes dubious copyrights) where the primary goal is not > technical improvement but simply getting rid of the GPL. The purpose of > open source is not serving commercial interests, it's making computing > better for everyone. > > - get the core community distributions (which is, Fedora and Debian) to > have a plan and timeline of adoping uutils as the default. This is the > ultimate test of maturity. > > - propose a test plan for Yocto. Merely sticking it into poky-altcfg is > actually a regression in testing, because then sysvinit images will be > tested only with GNU, and systemd images will be tested only with uutils. > > - last, but not least. Actually this is the most important one: fix your > relationship with GNU coreutils. It's painful to watch you two bicker, and > I do not want the Yocto project to be dragged into this. > > Alex > > > On Mon, 12 Oct 2026 at 23:13, Etienne Cordonnier <[email protected]> > wrote: > >> Hi Alex, >> - what is achieved by moving it to core is improving no-gplv3.inc for >> users who are not using gplv3 and still want full coreutils syntax support. >> It will also make it possible to add it to poky-altcfg.conf, and generally >> make it easier to consume without needing meta-openembedded. >> >> - what specifically makes this component mature enough is: >> - I've added the recipe to meta-openembedded in July 2022 and it has >> been continuously tested and improved since (e.g. I fixed the musl support >> upstream, the cross-compilation of stdbuf upstream, some buildpath issue) >> - its adoption in Ubuntu 26.04 as default coreutils implementation and >> the resulting large-scale usage and bug-fixing >> - its availability in Windows as "Coreutils for Windows" starting in >> June 2026 as a package maintained by Microsoft, and the resulting >> large-scale usage and bug-fixing >> - its massive adoption in various distros and package-managers (see >> https://uutils.org/users/ >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__uutils.org_users_&d=DwMFaQ&c=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw&r=AhkbNonVuMIGRfPx_Qj9TsRih1DULJTKUkSGa66m67E&m=TQmofvWjML0rStkG9aORknAn231FNShwwQFbVxuoEpFoFov2hNAHI82gZaXe_Ji-&s=CBQ3d8b8uYSdxwNhKRN4m1Bv7jOIX0EwE2ZOXtUfDj0&e=> >> ) >> - its >95% pass-rate of the GNU testing suite in release 0.0.12 (some >> tests are still skipped) >> - anecdotally, my own usage in production on embedded devices for >> several years without issues (on arm and qemu-arm64) >> >> - "should we make uutils-coreutils the default choice, or maybe the only >> choice?" >> -> maybe in several years when uutils-coreutils has matured even more >> and has 100% test coverage of the GNU test suite? At the moment I think the >> safest choice on critical devices is still GNU coreutils, so I wouldn't >> remove or make rust coreutils the default or only choice. Also rust >> binaries are bigger than C binaries so there is some tradeoff involved. GNU >> coreutils 9.12 main package is 10.3MB big in my test build, compared to >> 13.6MB for the uutils-coreutils 0.0.12 main package (uutils-coreutils uses >> a multi-binary executable to save space, GNU coreutils doesn't). >> >> - "Does it work as a provider of coreutils-native and is it compatible >> with pseudo?" >> - the recipe uutils-coreutils-native compiles, but it's not compatible >> with pseudo because of differences in syscalls, and it's not suitable as a >> replacement for coreutils-native at the moment. I'll try to make it work >> with pseudo in the future, but I think almost all users consume it as a >> target recipe and that's where it provides most value. >> >> - "Does it pass the full autobuilder matrix when selected as coreutils >> provider? Should we add that test to the autobuilder?" >> -> it should, but I've not tested the full matrix of the autobuilder. I >> would like to add the recipe to poky-altcfg.conf, and as far as I >> understand this would add it to the autobuilder as side-effect. >> I am also working on adding ptest support for the recipe and can send >> this if necessary for the acceptance to oe-core. >> >> Étienne >> >> On Mon, Oct 12, 2026 at 3:04 PM Alexander Kanavin <[email protected]> >> wrote: >> >>> On Sat, 10 Oct 2026 at 13:30, Etienne Cordonnier via >>> lists.openembedded.org >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org&d=DwMFaQ&c=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw&r=AhkbNonVuMIGRfPx_Qj9TsRih1DULJTKUkSGa66m67E&m=Pf9ypvX_MT4dU4cYC3brv9jpglRcRrrz1luHXObxYfW6J0oO8XAW6KnUoiQHzUES&s=QSmPEv1BkubeZVNksJqkHkppRkyy-Bac7QdkZuoYqaA&e=> >>> <[email protected]> wrote: >>> >>>> >>>> uutils-coreutils, the Rust reimplementation of GNU coreutils, is mature >>>> enough for production use, so move the recipe from meta-oe to oe-core. >>>> It provides and rprovides coreutils, and is excluded from world unless >>>> selected as the coreutils provider. >>>> >>> >>> This needs a bit more justification. What is achieved by moving it to >>> core? What specifically makes this component mature enough? What tests were >>> performed with it? Does it pass the full autobuilder matrix when selected >>> as coreutiuls provider? Should we add that test to the autobuilder? Should >>> we make uutils-coreutils the default choice, or maybe the only choice? Does >>> it work as a provider of coreutils-native, and is it compatible with pseudo? >>> >>> Adding things to core has a pretty high bar, and the above commit >>> message does not meet it. >>> >>> Alex >>> >>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#247713): https://lists.openembedded.org/g/openembedded-core/message/247713 Mute This Topic: https://lists.openembedded.org/mt/121685421/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
