On Thu, Aug 25, 2022 at 12:11 PM Randy MacLeod <[email protected]> wrote: > > On 2022-08-25 07:53, Richard Purdie wrote: > > On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: > >> On Thu, 25 Aug 2022 at 12:59, Richard Purdie > >> <[email protected]> wrote: > >>> The usptreamable version of the patch would probably be something which > >>> splits the target names in no_atomics up into components and matched on > >>> subsections of it rather than the whole string. My rust isn't really up > >>> to doing that though. > >>> > >>> I didn't really want us to maintain a separate list of targets which > >>> have atomics issues given it and the list in no_atomics would get out > >>> of sync very easily too. > >> But then the same patch needs to be applied to (and maintained > >> separately in) librsvg - and everything else that includes a copy of > >> crossbeam. Perhaps it's worth to at least make the above suggestion > >> about making it upstreamable in the patch commit message? > > Yes, I can improve the patch header. I do understand the patch isn't > > ideal. > > > > The alternatives are: > > > > * we take my patch > > * we break powerpc, mips, armv5, riscv32 and others > > * we drop the rust upgrades (the latent problem still exists) > > * we rewrite the patch > > > > For me to rewrite the patch, I'll need to learn more rust. I'm sure I > > can do that but it will take time and that time is time I can't use for > > other things. > > > > I'm hoping that by explaining the issue and documenting it, *someone* > > would step up and work out the upstreamable patch. This hasn't worked > > well for the rust recipes so far as I've had to do a lot of work to get > > them more into shape. I'm hoping the problem was just the shear scale > > and now issues are in easier smaller pieces others can/will help. It > > will certainly be time before someone else can schedule that in, we > > don't have anyone who can do it now. > > Yes, with the range of things I have had going on, re-writing the > rust classes/recipes was too big a task to consider. However, I can > and will work to get this patch into a form that is upstreamable. > > I've created a bug to track that: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14904 > > and at least started to look at some of the code! >
Also opening an issue upstream at https://github.com/crossbeam-rs/crossbeam would be a good thing. crossbeam is vendored by many rust packages and we will end up spewing the all such recipes with the tweak in addition to regenerating the checksums in toml files with every upgrade. > ../Randy > > > > > > I will say that I'm really really tired. > > > > I have a ton of autobuilder failures and in order to resolve them I'm > > rewriting patches many times over, first to get them to work, then > > taking review feedback and people complaining they're not perfect or > > don't fix other issues. I have a pile of other problems like this. > > > > I appreciate the desire not to have patches, particularly when they're > > as painful as the rust ones are. I appreciate the patch can be improved > > and should go upstream. I was hoping to take some time off tomorrow but > > it looks like I have other things to do (in reality probably on the > > weekend, I need to rework the llvm patches too and both sets take hours > > in rebuild time even to test). > > > > Cheers, > > > > Richard > > > > > > > > -- > # Randy MacLeod > # Wind River Linux > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169897): https://lists.openembedded.org/g/openembedded-core/message/169897 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
