We need to be mindful that we need to resolve this to unblock the other language changes and feature creep here is potentially problematic. I do think it is worth trying to improve things rather than

wrote: b), d), e), f), g) are now in master-next but will need debugging and impact other layers. I think a), c) and h) probably block merging, the remainder can follow post merge for core. Cheers, Ri

wrote: Let me follow up on where things are now at. I worked on the bitbake level rename support and we have a patch which resolves some of the issues above. 2) is fixed, 4) partially works and may st

Hi All, I'm a little saddened/annoyed/frustrated that we're less that a week before feature freeze and yet there is still no mechanism in bitbake to handle variable deprecation/renaming. There has als

Sharing a copy of this to openembedded-architecture. Cheers, Richard

I think either can be acceptable, it really depends on the situation. Cheers, Richard

I think so. It isn't the perfect solution but it is what will likely be the most successful/practical. I don't think it makes sense to dictate that and make a hard rule. Where there are many dependenc

Ideally we will need this information to be visible to our tools, yes. No. I deliberately tried to stress the most important things we needed to ensure. There are other important things too, e.g. the

The TSC had a meeting today and talked about this a little. I'm going to give my opinion and the others on the TSC can chime in if they want to add or differ. Firstly, the c) option of highlighting is

I was thinking something similar, I think we should document this in the proper documentation and then the wiki can refer to it. Wikis are good to a point and great at pulling info together but not a

The hope is something which can be broadly used but not every category has to perfectly match every corner case. From the inactive perspective, I'd define it as "no upstream the changes could be submi

Patch status tends to only really make the most sense on the development code branches and you couldn't say the kernel was inactive. Wouldn't the state be "Backport" in that case anyway? Cheers, Richa

I'm in favour of adding the new category and I agree some kind of dates in the [reason] space would be nice to have. For the purposes of a patch upstream, the last commit date is much more important t

That does still feel like we're admitting our syntax is broken though :( By that you mean I didn't expand on the other thread? Sadly I haven't had the time, no. I didn't prioritise it as you made it c

wrote: FWIW the above breaks meson which tries to run "ar D--version" after the above change. The intercept script is going to have to be a little more "clever" :/ Cheers, Richard

I think this would be something really useful to fix. For ranlib, we can probably just patch BUILD_RANLIB to add the flag. For ar, we need to remove the u option so it can only really be done with an

Er, yes. What was I thinking exactly? :) Anyway, you all knew what I meant! I think anything with two or more such operators should just error as that has never been supported and shouldn't/couldn't d

Hi All, I shared a patch on the bitbake mailing list to make some syntax generate warnings, specifically things of the form: XXX_append += "YYY" XXX_prepend += "YYY" XXX_remove += "YYY" and the ?=, =+

Some servers out there (e.g. our own git.yoctoproject.org) have slightly different git and https urls so this isn't as simple as you'd think. The security offered by https isn't as great as it first s

wrote: I've sent out a couple of patches for bitbake, one which does the remapping and a second which adds the warning. Testing would be appreciated before I merge them (I need to focus on master firs