Just out of curiosity: is this all considered to be part of kirkstone
release?
Lately I got the impression that neither the deprecation mechanism nor
the list of potentially variable renamings are fully matured.
So from my perspective this shouldn't part of a potential LTS release,
even if it's considered a big thing by some.
Or asking differently: just imagine this will be implemented for
kirkstone release and after the release there will be additional
findings... what's the take of the project on backporting vs. not
backporting these changes?
On 17.02.22 18:35, Saul Wold wrote:
On 2/17/22 04:32, Richard Purdie wrote:
On Thu, 2022-02-17 at 10:17 +0000, Richard Purdie via
lists.openembedded.org
wrote:
On Tue, 2022-02-15 at 12:08 +0000, Richard Purdie via
lists.openembedded.org
wrote:
In all the above cases there are still the issues that:
1) showing errors doesn't make bitbake exit or stop the build
2) It won't handle variables from the shell environment. This will
likely need
special code in bitbake.
3) There are probably some variables which are removed and no longer
used/supported which we should also tell the user about (show a
message instead
of a rename?)
4) The current code doesn't handle overridden variables. This is
easier to add
to c) but something for b) should be possible.
I had been wondering about c) above and keeping overhead down but I
think we'll
just have to go back to b) and try and work through the issues
above. I worry
that stopping the builds on error in particular is going to be
problematic. I
felt I should at least share some of the complexities of this with
people so
that if it doesn't end up happening, the complexity of the issue is
at least
more visible.
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 still need tweaking. 1) was
fixed but I
think may have regressed again as the autobuilder didn't stop builds
the way I
expected it to. 3) still isn't done.
Joshua was able to fix the erroronce/warnonce log implementation,
thanks.
Thanks to patches from Saul and Scott we have:
* a conversion script in master-next which converts metadata to match
renames
* patches for bitbake and oe-core to transition to several of the new
names
I was able to get the changes in master-next to run on the
autobuilder with
unconverted layers being the failure cases.
The remaining things I'm aware of that need to be done are:
a) Resolve BB_DISKMON_DIRS in bitbake (last remaining bitbake rename)
b) Add some mechanism to show an error about now unused variables
c) Check builds really stop at parsing if errors are shown
d) Tweak the code for checking if overridden versions of variables
are set
e) bump bitbake version and change the OE-Core minimum version
requirement
f) consider changing the layer compatibility string to match for this
g) Handle ICECC_USER*/ICECC_SYSTEM* changes
h) Do something with the WHITELIST_(ANY LICENSE) variable
i) Scan over OE-Core for whitelist/blacklist variable name usage in
python code
and propose patches for the issues
j) translate the names in the docs (the script should handle that)
k) document the conversion script and write the migration guide entry
b), d), e), f), g) are now in master-next but will need debugging and
impact
other layers.
Thank RP for all that you have done, I will have a patch to master-next
for the script shortly.
I think a), c) and h) probably block merging, the remainder can follow
post
merge for core.
I will start looking at the WHITELIST_<license> changes and review the
old emails.
Sau!
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1470):
https://lists.openembedded.org/g/openembedded-architecture/message/1470
Mute This Topic: https://lists.openembedded.org/mt/89158954/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
