Date   

Upgrading Yocto without rebuilding instances #yocto

b.senzio@...
 

Hello everyone,

Say I built Yocto for the latest build for instance Hardknott. Let’s say I need to build for Zeus instead (and hopefully keep everything I built [that doesn’t need to be updated]).

 

Has anyone done this?

 

Outside of building a whole new Yocto distribution from scratch… What else can I do?

 

I have to rebuild Yocto with an older version because apparently there is some issue with Uboot that is not able to be built correctly.


Re: Problems building eSDK: Exception: variable BBFILES references itself!

Bryan Evenson
 

Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 3:59 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable BBFILES
references itself!

On Wed, 2022-02-09 at 20:19 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 2:47 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable
BBFILES references itself!

On Wed, 2022-02-09 at 19:36 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 1:51 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable
BBFILES references itself!

On Wed, 2022-02-09 at 18:10 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 12:25 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception:
variable BBFILES references itself!

On Wed, 2022-02-09 at 16:51 +0000, Bryan Evenson wrote:
All,

I've used the SDK in the past and want to start using the
eSDK for my
project.
I'm on the dunfell branch. I'm trying to build the eSDK
for my image by
calling:

bitbake <my_image_name> -c populate_sdk_ext

The sdk generation fails with the error in the subject. I
haven't been able to find any documentation on what this
means or how to fix it. I've tried deleting my tmp
directory and running cleansstate on my image and I still
get the same error. I've also tried generating the eSDK
for core-image-minimal and I have the same error. I can
generate the SDK successfully, just not the eSDK. I have
copied more of the
build output below if it helps.
Note that I have replaced some text that I'm paranoid
about publishing on the internet; the modified text is
enclosed with <>.

Does anyone have any insight as to why the eSDK build is failing?
Could you share what bitbake -e shows BBFILES as being set to?
The variable history from that command for the variable may
also be
helpful.

There has to be something different to how you're setting it
compared to what we test on the autobuilder.

Cheers,

Richard
Here's what I was able to pull from bitbake -e. I've included
details for both BBFILES and BBFILES_DYNAMIC. Let me know if
anything else would be helpful.
Thanks, I'm not seeing anything too odd there. I guess next we
need to see the bblayers.conf that the code is building into the
eSDK and compare it to your original conf/bblayer.conf.

The generated file should be in the eSDK image directory
somewhere, I'm not able to look up the exact path right now. Let
me know if you can't
find it.
Lets see if the two bblayers.conf files look different and
introduce some issue.
I think I found what you were looking for under the image tmp
working
directory at sdk-ext/image/temp-renamed-sdk/conf/bblayers.conf.
Here's a comparison of my original bblayers.conf in my tmp directory
and the generated bblayers.conf for the eSDK. I confirmed that the
layers directory is present and contains all the layers as listed in the
generated bblayers.conf.

##########################################################
############
###
#
# Contents of my original bblayers.conf #
##########################################################
############
### # LAYER_CONF_VERSION is increased each time
build/conf/bblayers.conf # changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
<my_home_dir>/poky/<my_custom_layer1> \
<my_home_dir>/poky/<my_custom_layer2> \
<my_home_dir>/poky/meta-bacnet \
<my_home_dir>/poky/meta-atmel \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
<my_home_dir>/poky/meta-yocto-bsp \
<my_home_dir>/poky/meta-openembedded/meta-oe \
<my_home_dir>/poky/meta-openembedded/meta-networking \
<my_home_dir>/poky/meta-openembedded/meta-python \
<my_home_dir>/poky/poky-build/workspace \
"
BBLAYERS_NON_REMOVABLE ?= " \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
"

##########################################################
############
###
#
# Contents of my
<img_tmp_work_dir>/sdk-ext/image/tmp-renamed-
sdk/conf/bblayers.conf
#
##########################################################
############
### # WARNING: this configuration has been automatically generated
and in # most cases should not be edited. If you need more
flexibility than # this configuration provides, it is strongly
suggested that you set # up a proper instance of the full build
system and use that instead.

BBPATH = "${TOPDIR}"
SDKBASEMETAPATH = "${TOPDIR}"
BBLAYERS := " \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer1> \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer2> \
${SDKBASEMETAPATH}/layers/poky/meta-bacnet \
${SDKBASEMETAPATH}/layers/poky/meta-atmel \
${SDKBASEMETAPATH}/layers/poky/meta \
${SDKBASEMETAPATH}/layers/poky/meta-poky \
${SDKBASEMETAPATH}/layers/poky/meta-yocto-bsp \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-oe
\
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-
networking \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-
python \
${SDKBASEMETAPATH}/workspace \
"

Let me know if anything else would be helpful for diagnosing this issue.
I'm now wondering what happens if you remove

<my_home_dir>/poky/poky-build/workspace \

since I suspect your local workspace probably doesn't make sense in
the eSDK?
Could you try temporarily removing that and see if that helps?

The BBFILES entry in one of these layer.conf files is probably
causing some issue but I can't easily know which one. You could
remove some of the other layers to try and see if you identify where the
issue is from too?
This is odd. I removed the workspace from my local bblayers.conf. I
executed:
bitbake -c cleansstate image
bitbake image
bitbake image -c populate_sdk_ext

I got the same error message as before. Also, the bblayers.conf in
the tmp- sdk-ext directory still contains the workspace directory in the
BBLAYERS list.
I then switched and built core-image-minimal the same way, and I'm
getting the same error. I checked BBLAYERS in bitbake -e for
core-image-minimal, and the workspace directory is not listed. I
don’t know how populate_sdk_ext is pulling the workspace directory into
BBLAYERS. Any ideas?

I suspect the eSDK adds a workspace for the devtool and similar workflows
so that piece may be normal and perhaps it was conflicting with your existing
workspace? I have to admit I don't remember if it does that or not offhand
but it could.

If that were the case, it is sounding like the conflict may be with some other
layer instead.

Cheers,

Richard
I found it. In one of my layers, instead of:

BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"

I had:

BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

I know I looked at that line a few times in the last day and never noticed the problem. This has been like this on my layer for a long time. Not sure how this has built without issue for the last eight years. Thanks for the assistance.

Thanks,
Bryan


3.4.2 rc1 QA

Richard Purdie
 

3.4.2 rc1 was built on the autobuilder. It didn't send the QA email as that is
broken. I haven't sent it manually as we need to decide what to do with this
build. There was one failure and 8 warnings.

The failure was with meta-agl. As far as I know agl doesn't support honister and
the next branch has moved on for kirkstone. There is therefore an open question
about what we configure the autobuilder to do there.

The warnings all look to be from SDK testing with sstate server networking
issues. They shouldn't break the release and I don't believe there is any code
side issue beyond the server one.

Thoughts?

[Yes, we need to get these things fixed, I know. They are being worked on. I'm
resorting to merging master stuff blind at this point too as the issues affect
that as well.]

Cheers,

Richard


Re: Adding DKMS support to yocto build project #dunfell #kernel

Josef Holzmayr
 

Hi Rayaan,

On 10. Feb 2022, at 10:29, rayaan@... wrote:
I am new to yocto and in need of assistance please.

Could someone please assist me with getting DKMS included in my build.

my platform is: stm32mp1
Currently DKMS is not supported in Yocto/OE and there are no imminent plans to change that. See the discussion on the topic at https://lists.openembedded.org/g/openembedded-core/message/159558

Maybe you can work out something for yourself using NI’s layer as mentioned in https://lists.openembedded.org/g/openembedded-core/message/159694

Greetz,
Josef


Adding DKMS support to yocto build project #dunfell #kernel

rayaan@...
 

Good day,

I am new to yocto and in need of assistance please.

Could someone please assist me with getting DKMS included in my build.

my platform is: stm32mp1


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.14.rc1)

Teoh, Jay Shen
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.14.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion next Tuesday, Feb 15.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Tuesday, 1 February, 2022 5:47 AM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.1.14.rc1)

A build flagged for QA (yocto-3.1.14.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.14.rc1


Build hash information:

bitbake: be6ecc160ac4a8d9715257b9b955363cecc081ea
meta-agl: 7a644d636237459c54128a71d083cb6f9e1b8e60
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: 9979cfa676105cb68cfadfdaeabf044d7c919319
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 87984115eb6ed1a4c17204629dcb100f6b76fe82
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: ab9fca485e13f6f2f9761e1d2810f87c2e4f060a
oecore: f3be01483b01c88f8c4ba24ca73ccf1bcc33665c
poky: bba323389749ec3e306509f8fb12649f031be152



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







Re: Maintaining ABI Compatibility for LTS branch

Richard Purdie
 

On Wed, 2022-02-09 at 14:13 -0500, Sinan Kaya wrote:
On 2/9/2022 1:41 PM, Richard Purdie wrote:
There are lots of levels it could be implemented at but it is something someone
would need to pick up and drive forward with a long term view to helping with
issues etc.
What would be the minimum acceptable solution with the least investment?
in other words, do we have a list of requirements?
You're after our LTS to maintain ABI. In order to do that we need help, not just
with patches generating some output, but in day to day running of the project,
i.e. help comparing output before and after changes. Whenever a patch is
submitted which breaks this, it will need attention and help some someone to
explain to that submitter what the issue, why it is important and hints on how
to fix it.
That's true, this will require engagement from the community. Tool could
take few iterations to perfect. Until then, I expect tool owner to be
responsible for fixing these bugs. Once stability is reached, it becomes
community maintained.

If the tool owner doesn't maintain and community has no interest, tool
dies and gets reverted. It is as simple as any open source engagement.

When stability is established, each code contributor to LTS would be
subject to addressing issues found before they get merged.
I agree, this either needs input from the community in order to drive it or a
sponsor. It will be interesting to see if people are interested in doing this
and I guess we can gauge that from the replies to this thread to see if people
do want to do it. I can tell you first hand how badly the existing maintainers
are burning out with the current load so we need new people.

The idea of "least investment" sends shivers down my spine since it sounds like
you want to do the absolute bare minimum to have this happen, rather than a more
community oriented approach.
It depends on your taste. I believe in smaller improvements
as opposed to throwing a big project to you that no-one will use it.
We both agree on incremental improvements and I am fine with that. I don't want
any patch acceptance taken as a sign we're goging to add a significant process
burden though. I'd prefer we have a broad agreement of what the end objective is
architecture wise too.

Everyone has different needs. We need to find the common ones.
That's why, I'm asking if there is an existing tool that works for
large part of the community accepting that there will be some folks
that won't have their needs addressed.

I'm interested in revisiting the tooling discussion and have these gaps
addressed for the biggest audience so that we can have something to
build upon.


Anyway, my point is there is more to this than just a patch. We have various
kinds of build output already and reports on test regressions - nobody helps
with them. I need some kind of a sign that ABI would be different and there are
people able to help with review on an ongoing basis, else it will just be
something else I and a small number of others become overloaded with.
Noted. Hopefully, things will be not that volatile for the LTS branch
and tool would actually help the maintainer.

In an ideal world, change needs to be stopped before that happens and
have the patch author address it similar to how you monitor build
pipelines.

Our team has posted a solution. BMW folks posted a solution.
None of them got merged.
Can you remind me of your team's please?
https://lists.yoctoproject.org/g/yocto/topic/85279259?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,160,85279259

This was an intern project from last summer that we are interested
in expanding coverage.
"None of them got merged" isn't particularly fair here. There was a brief thread
on the yocto list, no patches were proposed or reviewed and the implementation
is a standalone layer so doesn't need to merge anyway, people could use it
already if they wanted.

If the question is whether something would be accepted into core, the answer is
possibly, it would depends. The quality of the code in that layer needs
improving for core and I'm not sure about the approach. Hooking it against
buildhistory is "easy" but as I mentioned in separate discussions earlier today,
buildhistory is getting pulled in different directions (such as a SBOM) and I'm
worried about some of the extensions to it. Certainly, the ABI saving shouldn't
really be buried in a do_install postfunc and perhaps is more of a build history
item that some others that are being proposed.

This probably does need a discussion on the architecture list and we need some
discussion and decisions about where/what buildhistory could/should do. Adding
this to buildhistory is all well and good but we don't have a meaningful
integration/monitoring of existing buildhistory issues in our
autobuilder/workflow today even before adding new things.


I have to admit I can't remember what the conclusion was on your team's version
but if you remind me of the patches I can try and remember. This is a bigger
problem than just patches though sadly.
Sure, let's find out what everyone is doing.
Ok.

Cheers,

Richard


Re: Problems building eSDK: Exception: variable BBFILES references itself!

Richard Purdie
 

On Wed, 2022-02-09 at 20:19 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 2:47 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable BBFILES
references itself!

On Wed, 2022-02-09 at 19:36 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 1:51 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable
BBFILES references itself!

On Wed, 2022-02-09 at 18:10 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 12:25 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable
BBFILES references itself!

On Wed, 2022-02-09 at 16:51 +0000, Bryan Evenson wrote:
All,

I've used the SDK in the past and want to start using the eSDK
for my
project.
I'm on the dunfell branch. I'm trying to build the eSDK for
my image by
calling:

bitbake <my_image_name> -c populate_sdk_ext

The sdk generation fails with the error in the subject. I
haven't been able to find any documentation on what this means
or how to fix it. I've tried deleting my tmp directory and
running cleansstate on my image and I still get the same
error. I've also tried generating the eSDK for
core-image-minimal and I have the same error. I can generate
the SDK successfully, just not the eSDK. I have copied more of the
build output below if it helps.
Note that I have replaced some text that I'm paranoid about
publishing on the internet; the modified text is
enclosed with <>.

Does anyone have any insight as to why the eSDK build is failing?
Could you share what bitbake -e shows BBFILES as being set to?
The variable history from that command for the variable may also be
helpful.

There has to be something different to how you're setting it
compared to what we test on the autobuilder.

Cheers,

Richard
Here's what I was able to pull from bitbake -e. I've included
details for both BBFILES and BBFILES_DYNAMIC. Let me know if
anything else would be helpful.
Thanks, I'm not seeing anything too odd there. I guess next we need
to see the bblayers.conf that the code is building into the eSDK and
compare it to your original conf/bblayer.conf.

The generated file should be in the eSDK image directory somewhere,
I'm not able to look up the exact path right now. Let me know if you can't
find it.
Lets see if the two bblayers.conf files look different and introduce
some issue.
I think I found what you were looking for under the image tmp working
directory at sdk-ext/image/temp-renamed-sdk/conf/bblayers.conf. Here's a
comparison of my original bblayers.conf in my tmp directory and the
generated bblayers.conf for the eSDK. I confirmed that the layers directory
is present and contains all the layers as listed in the generated bblayers.conf.

##########################################################
############
###
#
# Contents of my original bblayers.conf #
##########################################################
############
### # LAYER_CONF_VERSION is increased each time
build/conf/bblayers.conf # changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
<my_home_dir>/poky/<my_custom_layer1> \
<my_home_dir>/poky/<my_custom_layer2> \
<my_home_dir>/poky/meta-bacnet \
<my_home_dir>/poky/meta-atmel \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
<my_home_dir>/poky/meta-yocto-bsp \
<my_home_dir>/poky/meta-openembedded/meta-oe \
<my_home_dir>/poky/meta-openembedded/meta-networking \
<my_home_dir>/poky/meta-openembedded/meta-python \
<my_home_dir>/poky/poky-build/workspace \
"
BBLAYERS_NON_REMOVABLE ?= " \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
"

##########################################################
############
###
#
# Contents of my
<img_tmp_work_dir>/sdk-ext/image/tmp-renamed-
sdk/conf/bblayers.conf
#
##########################################################
############
### # WARNING: this configuration has been automatically generated and
in # most cases should not be edited. If you need more flexibility
than # this configuration provides, it is strongly suggested that you
set # up a proper instance of the full build system and use that
instead.

BBPATH = "${TOPDIR}"
SDKBASEMETAPATH = "${TOPDIR}"
BBLAYERS := " \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer1> \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer2> \
${SDKBASEMETAPATH}/layers/poky/meta-bacnet \
${SDKBASEMETAPATH}/layers/poky/meta-atmel \
${SDKBASEMETAPATH}/layers/poky/meta \
${SDKBASEMETAPATH}/layers/poky/meta-poky \
${SDKBASEMETAPATH}/layers/poky/meta-yocto-bsp \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-oe \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-
networking \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-
python \
${SDKBASEMETAPATH}/workspace \
"

Let me know if anything else would be helpful for diagnosing this issue.
I'm now wondering what happens if you remove

<my_home_dir>/poky/poky-build/workspace \

since I suspect your local workspace probably doesn't make sense in the
eSDK?
Could you try temporarily removing that and see if that helps?

The BBFILES entry in one of these layer.conf files is probably causing some
issue but I can't easily know which one. You could remove some of the other
layers to try and see if you identify where the issue is from too?
This is odd. I removed the workspace from my local bblayers.conf. I executed:
bitbake -c cleansstate image
bitbake image
bitbake image -c populate_sdk_ext

I got the same error message as before. Also, the bblayers.conf in the tmp-
sdk-ext directory still contains the workspace directory in the BBLAYERS list.
I then switched and built core-image-minimal the same way, and I'm getting the
same error. I checked BBLAYERS in bitbake -e for core-image-minimal, and the
workspace directory is not listed. I don’t know how populate_sdk_ext is
pulling the workspace directory into BBLAYERS. Any ideas?
I suspect the eSDK adds a workspace for the devtool and similar workflows so
that piece may be normal and perhaps it was conflicting with your existing
workspace? I have to admit I don't remember if it does that or not offhand but
it could.

If that were the case, it is sounding like the conflict may be with some other
layer instead.

Cheers,

Richard


Re: Problems building eSDK: Exception: variable BBFILES references itself!

Bryan Evenson
 

Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 2:47 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable BBFILES
references itself!

On Wed, 2022-02-09 at 19:36 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 1:51 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable
BBFILES references itself!

On Wed, 2022-02-09 at 18:10 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 12:25 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable
BBFILES references itself!

On Wed, 2022-02-09 at 16:51 +0000, Bryan Evenson wrote:
All,

I've used the SDK in the past and want to start using the eSDK
for my
project.
I'm on the dunfell branch. I'm trying to build the eSDK for
my image by
calling:

bitbake <my_image_name> -c populate_sdk_ext

The sdk generation fails with the error in the subject. I
haven't been able to find any documentation on what this means
or how to fix it. I've tried deleting my tmp directory and
running cleansstate on my image and I still get the same
error. I've also tried generating the eSDK for
core-image-minimal and I have the same error. I can generate
the SDK successfully, just not the eSDK. I have copied more of the
build output below if it helps.
Note that I have replaced some text that I'm paranoid about
publishing on the internet; the modified text is
enclosed with <>.

Does anyone have any insight as to why the eSDK build is failing?
Could you share what bitbake -e shows BBFILES as being set to?
The variable history from that command for the variable may also be
helpful.

There has to be something different to how you're setting it
compared to what we test on the autobuilder.

Cheers,

Richard
Here's what I was able to pull from bitbake -e. I've included
details for both BBFILES and BBFILES_DYNAMIC. Let me know if
anything else would be helpful.
Thanks, I'm not seeing anything too odd there. I guess next we need
to see the bblayers.conf that the code is building into the eSDK and
compare it to your original conf/bblayer.conf.

The generated file should be in the eSDK image directory somewhere,
I'm not able to look up the exact path right now. Let me know if you can't
find it.
Lets see if the two bblayers.conf files look different and introduce
some issue.
I think I found what you were looking for under the image tmp working
directory at sdk-ext/image/temp-renamed-sdk/conf/bblayers.conf. Here's a
comparison of my original bblayers.conf in my tmp directory and the
generated bblayers.conf for the eSDK. I confirmed that the layers directory
is present and contains all the layers as listed in the generated bblayers.conf.

##########################################################
############
###
#
# Contents of my original bblayers.conf #
##########################################################
############
### # LAYER_CONF_VERSION is increased each time
build/conf/bblayers.conf # changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
<my_home_dir>/poky/<my_custom_layer1> \
<my_home_dir>/poky/<my_custom_layer2> \
<my_home_dir>/poky/meta-bacnet \
<my_home_dir>/poky/meta-atmel \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
<my_home_dir>/poky/meta-yocto-bsp \
<my_home_dir>/poky/meta-openembedded/meta-oe \
<my_home_dir>/poky/meta-openembedded/meta-networking \
<my_home_dir>/poky/meta-openembedded/meta-python \
<my_home_dir>/poky/poky-build/workspace \
"
BBLAYERS_NON_REMOVABLE ?= " \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
"

##########################################################
############
###
#
# Contents of my
<img_tmp_work_dir>/sdk-ext/image/tmp-renamed-
sdk/conf/bblayers.conf
#
##########################################################
############
### # WARNING: this configuration has been automatically generated and
in # most cases should not be edited. If you need more flexibility
than # this configuration provides, it is strongly suggested that you
set # up a proper instance of the full build system and use that
instead.

BBPATH = "${TOPDIR}"
SDKBASEMETAPATH = "${TOPDIR}"
BBLAYERS := " \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer1> \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer2> \
${SDKBASEMETAPATH}/layers/poky/meta-bacnet \
${SDKBASEMETAPATH}/layers/poky/meta-atmel \
${SDKBASEMETAPATH}/layers/poky/meta \
${SDKBASEMETAPATH}/layers/poky/meta-poky \
${SDKBASEMETAPATH}/layers/poky/meta-yocto-bsp \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-oe \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-
networking \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-
python \
${SDKBASEMETAPATH}/workspace \
"

Let me know if anything else would be helpful for diagnosing this issue.
I'm now wondering what happens if you remove

<my_home_dir>/poky/poky-build/workspace \

since I suspect your local workspace probably doesn't make sense in the
eSDK?
Could you try temporarily removing that and see if that helps?

The BBFILES entry in one of these layer.conf files is probably causing some
issue but I can't easily know which one. You could remove some of the other
layers to try and see if you identify where the issue is from too?
This is odd. I removed the workspace from my local bblayers.conf. I executed:
bitbake -c cleansstate image
bitbake image
bitbake image -c populate_sdk_ext

I got the same error message as before. Also, the bblayers.conf in the tmp-sdk-ext directory still contains the workspace directory in the BBLAYERS list. I then switched and built core-image-minimal the same way, and I'm getting the same error. I checked BBLAYERS in bitbake -e for core-image-minimal, and the workspace directory is not listed. I don’t know how populate_sdk_ext is pulling the workspace directory into BBLAYERS. Any ideas?

Thanks,
Bryan


Re: Problems building eSDK: Exception: variable BBFILES references itself!

Richard Purdie
 

On Wed, 2022-02-09 at 19:36 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 1:51 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable BBFILES
references itself!

On Wed, 2022-02-09 at 18:10 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 12:25 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable
BBFILES references itself!

On Wed, 2022-02-09 at 16:51 +0000, Bryan Evenson wrote:
All,

I've used the SDK in the past and want to start using the eSDK for
my
project.
I'm on the dunfell branch. I'm trying to build the eSDK for my
image by
calling:

bitbake <my_image_name> -c populate_sdk_ext

The sdk generation fails with the error in the subject. I haven't
been able to find any documentation on what this means or how to
fix it. I've tried deleting my tmp directory and running
cleansstate on my image and I still get the same error. I've also
tried generating the eSDK for core-image-minimal and I have the
same error. I can generate the SDK successfully, just not the
eSDK. I have copied more of the build output below if it helps.
Note that I have replaced some text that I'm paranoid about
publishing on the internet; the modified text is
enclosed with <>.

Does anyone have any insight as to why the eSDK build is failing?
Could you share what bitbake -e shows BBFILES as being set to? The
variable history from that command for the variable may also be helpful.

There has to be something different to how you're setting it
compared to what we test on the autobuilder.

Cheers,

Richard
Here's what I was able to pull from bitbake -e. I've included details
for both BBFILES and BBFILES_DYNAMIC. Let me know if anything else
would be helpful.
Thanks, I'm not seeing anything too odd there. I guess next we need to see
the bblayers.conf that the code is building into the eSDK and compare it to
your original conf/bblayer.conf.

The generated file should be in the eSDK image directory somewhere, I'm
not able to look up the exact path right now. Let me know if you can't find it.
Lets see if the two bblayers.conf files look different and introduce some
issue.
I think I found what you were looking for under the image tmp working directory at sdk-ext/image/temp-renamed-sdk/conf/bblayers.conf. Here's a comparison of my original bblayers.conf in my tmp directory and the generated bblayers.conf for the eSDK. I confirmed that the layers directory is present and contains all the layers as listed in the generated bblayers.conf.

#########################################################################
#
# Contents of my original bblayers.conf
#
#########################################################################
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
<my_home_dir>/poky/<my_custom_layer1> \
<my_home_dir>/poky/<my_custom_layer2> \
<my_home_dir>/poky/meta-bacnet \
<my_home_dir>/poky/meta-atmel \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
<my_home_dir>/poky/meta-yocto-bsp \
<my_home_dir>/poky/meta-openembedded/meta-oe \
<my_home_dir>/poky/meta-openembedded/meta-networking \
<my_home_dir>/poky/meta-openembedded/meta-python \
<my_home_dir>/poky/poky-build/workspace \
"
BBLAYERS_NON_REMOVABLE ?= " \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
"

#########################################################################
#
# Contents of my <img_tmp_work_dir>/sdk-ext/image/tmp-renamed-sdk/conf/bblayers.conf
#
#########################################################################
# WARNING: this configuration has been automatically generated and in
# most cases should not be edited. If you need more flexibility than
# this configuration provides, it is strongly suggested that you set
# up a proper instance of the full build system and use that instead.

BBPATH = "${TOPDIR}"
SDKBASEMETAPATH = "${TOPDIR}"
BBLAYERS := " \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer1> \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer2> \
${SDKBASEMETAPATH}/layers/poky/meta-bacnet \
${SDKBASEMETAPATH}/layers/poky/meta-atmel \
${SDKBASEMETAPATH}/layers/poky/meta \
${SDKBASEMETAPATH}/layers/poky/meta-poky \
${SDKBASEMETAPATH}/layers/poky/meta-yocto-bsp \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-oe \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-networking \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-python \
${SDKBASEMETAPATH}/workspace \
"

Let me know if anything else would be helpful for diagnosing this issue.
I'm now wondering what happens if you remove  

<my_home_dir>/poky/poky-build/workspace \

since I suspect your local workspace probably doesn't make sense in the eSDK?
Could you try temporarily removing that and see if that helps?

The BBFILES entry in one of these layer.conf files is probably causing some
issue but I can't easily know which one. You could remove some of the other
layers to try and see if you identify where the issue is from too?

Cheers,

Richard


Re: Error: Transaction check error: while doing do_rootfs task

Sourabh Hegde
 

Hello Khem,

Doing "bitbake -e core-image-swupdate | grep ^INIT_MANAGER=" shows INIT_MANAGER="none". And "bitbake -e core-image-swupdate | grep ^DISTRO_FEATURES=" shows DISTRO_FEATURES="acl alsa argp bluetooth ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat largefile opengl ptest multiarch wayland vulkan systemd wifi systemd pulseaudio sysvinit gobject-introspection-data ldconfig".

I don't understand why these is both systemd and sysvinit. In the core-image-swupdate I have mentioned:

DISTRO_FEATURES_append = " systemd"

Can you please let me know how can I check if the recipe has dependency on sysvinit or not?

Thanks in advance


Re: Problems building eSDK: Exception: variable BBFILES references itself!

Bryan Evenson
 

Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 1:51 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable BBFILES
references itself!

On Wed, 2022-02-09 at 18:10 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 12:25 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable
BBFILES references itself!

On Wed, 2022-02-09 at 16:51 +0000, Bryan Evenson wrote:
All,

I've used the SDK in the past and want to start using the eSDK for
my
project.
I'm on the dunfell branch. I'm trying to build the eSDK for my
image by
calling:

bitbake <my_image_name> -c populate_sdk_ext

The sdk generation fails with the error in the subject. I haven't
been able to find any documentation on what this means or how to
fix it. I've tried deleting my tmp directory and running
cleansstate on my image and I still get the same error. I've also
tried generating the eSDK for core-image-minimal and I have the
same error. I can generate the SDK successfully, just not the
eSDK. I have copied more of the build output below if it helps.
Note that I have replaced some text that I'm paranoid about
publishing on the internet; the modified text is
enclosed with <>.

Does anyone have any insight as to why the eSDK build is failing?
Could you share what bitbake -e shows BBFILES as being set to? The
variable history from that command for the variable may also be helpful.

There has to be something different to how you're setting it
compared to what we test on the autobuilder.

Cheers,

Richard
Here's what I was able to pull from bitbake -e. I've included details
for both BBFILES and BBFILES_DYNAMIC. Let me know if anything else
would be helpful.
Thanks, I'm not seeing anything too odd there. I guess next we need to see
the bblayers.conf that the code is building into the eSDK and compare it to
your original conf/bblayer.conf.

The generated file should be in the eSDK image directory somewhere, I'm
not able to look up the exact path right now. Let me know if you can't find it.
Lets see if the two bblayers.conf files look different and introduce some
issue.
I think I found what you were looking for under the image tmp working directory at sdk-ext/image/temp-renamed-sdk/conf/bblayers.conf. Here's a comparison of my original bblayers.conf in my tmp directory and the generated bblayers.conf for the eSDK. I confirmed that the layers directory is present and contains all the layers as listed in the generated bblayers.conf.

#########################################################################
#
# Contents of my original bblayers.conf
#
#########################################################################
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
<my_home_dir>/poky/<my_custom_layer1> \
<my_home_dir>/poky/<my_custom_layer2> \
<my_home_dir>/poky/meta-bacnet \
<my_home_dir>/poky/meta-atmel \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
<my_home_dir>/poky/meta-yocto-bsp \
<my_home_dir>/poky/meta-openembedded/meta-oe \
<my_home_dir>/poky/meta-openembedded/meta-networking \
<my_home_dir>/poky/meta-openembedded/meta-python \
<my_home_dir>/poky/poky-build/workspace \
"
BBLAYERS_NON_REMOVABLE ?= " \
<my_home_dir>/poky/meta \
<my_home_dir>/poky/meta-poky \
"

#########################################################################
#
# Contents of my <img_tmp_work_dir>/sdk-ext/image/tmp-renamed-sdk/conf/bblayers.conf
#
#########################################################################
# WARNING: this configuration has been automatically generated and in
# most cases should not be edited. If you need more flexibility than
# this configuration provides, it is strongly suggested that you set
# up a proper instance of the full build system and use that instead.

BBPATH = "${TOPDIR}"
SDKBASEMETAPATH = "${TOPDIR}"
BBLAYERS := " \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer1> \
${SDKBASEMETAPATH}/layers/poky/<my_custom_layer2> \
${SDKBASEMETAPATH}/layers/poky/meta-bacnet \
${SDKBASEMETAPATH}/layers/poky/meta-atmel \
${SDKBASEMETAPATH}/layers/poky/meta \
${SDKBASEMETAPATH}/layers/poky/meta-poky \
${SDKBASEMETAPATH}/layers/poky/meta-yocto-bsp \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-oe \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-networking \
${SDKBASEMETAPATH}/layers/poky/meta-openembedded/meta-python \
${SDKBASEMETAPATH}/workspace \
"

Let me know if anything else would be helpful for diagnosing this issue.

Thanks,
Bryan

Cheers,

Richard


Re: Maintaining ABI Compatibility for LTS branch

Richard Purdie
 

On Wed, 2022-02-09 at 18:41 +0000, Richard Purdie wrote:

The BMW one is about hash equivalence so wouldn't help your ABI output problem
with the LTS. From what I remember, it predates hash equivalence and the project
needed a generic equivalance mechanism complete with server done at the runqueue
level in bitbake. This has now happened so we could revisit the idea of what is
in that layer but translating it to a hash equivalence plugin.

I'd also add that even with hash equivalence done well like we ended up with, we
have only two people interested/able to work on bugs with it, the author and
myself. For a key component of the system, this worries me a lot. Adding more
complexity without maintainer support isn't going to help anyone.
Sorry, I'm getting confused here with earlier work Michael Ho did at BMW. The
links here:

https://lists.yoctoproject.org/g/yocto/message/52650
https://github.com/bmwcarit/meta-abicompat

are the revised version from last year which *does* hook into hash equivalence.
I'm getting two things confused, sorry.

The nice thing about the layer above is that it is a standalone layer, we don't
have to merge it in order to use it. This shows the power of the new hash
equivalence code as it is a plugin to it. We may consider merging it at some
point but there is less of a pressing need and we need time to experiment with
it.

At this point it is a proof of concept and doesn't solve the ABI problem you're
describing in the original email. Sorry about any confusion.

The abidw recipe could be useful to your ABI issue.

Cheers,

Richard


Re: Maintaining ABI Compatibility for LTS branch

Sinan Kaya <okaya@...>
 

On 2/9/2022 1:41 PM, Richard Purdie wrote:
There are lots of levels it could be implemented at but it is something someone
would need to pick up and drive forward with a long term view to helping with
issues etc.
What would be the minimum acceptable solution with the least investment?
in other words, do we have a list of requirements?
You're after our LTS to maintain ABI. In order to do that we need help, not just
with patches generating some output, but in day to day running of the project,
i.e. help comparing output before and after changes. Whenever a patch is
submitted which breaks this, it will need attention and help some someone to
explain to that submitter what the issue, why it is important and hints on how
to fix it.
That's true, this will require engagement from the community. Tool could
take few iterations to perfect. Until then, I expect tool owner to be
responsible for fixing these bugs. Once stability is reached, it becomes
community maintained.

If the tool owner doesn't maintain and community has no interest, tool
dies and gets reverted. It is as simple as any open source engagement.

When stability is established, each code contributor to LTS would be
subject to addressing issues found before they get merged.

The idea of "least investment" sends shivers down my spine since it sounds like
you want to do the absolute bare minimum to have this happen, rather than a more
community oriented approach.
It depends on your taste. I believe in smaller improvements
as opposed to throwing a big project to you that no-one will use it.

Everyone has different needs. We need to find the common ones.
That's why, I'm asking if there is an existing tool that works for
large part of the community accepting that there will be some folks
that won't have their needs addressed.

I'm interested in revisiting the tooling discussion and have these gaps
addressed for the biggest audience so that we can have something to
build upon.

Anyway, my point is there is more to this than just a patch. We have various
kinds of build output already and reports on test regressions - nobody helps
with them. I need some kind of a sign that ABI would be different and there are
people able to help with review on an ongoing basis, else it will just be
something else I and a small number of others become overloaded with.
Noted. Hopefully, things will be not that volatile for the LTS branch
and tool would actually help the maintainer.

In an ideal world, change needs to be stopped before that happens and
have the patch author address it similar to how you monitor build
pipelines.

Our team has posted a solution. BMW folks posted a solution.
None of them got merged.
Can you remind me of your team's please?
https://lists.yoctoproject.org/g/yocto/topic/85279259?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,160,85279259

This was an intern project from last summer that we are interested
in expanding coverage.

The BMW one is about hash equivalence so wouldn't help your ABI output problem
with the LTS. From what I remember, it predates hash equivalence and the project
needed a generic equivalance mechanism complete with server done at the runqueue
level in bitbake. This has now happened so we could revisit the idea of what is
in that layer but translating it to a hash equivalence plugin.
I'd also add that even with hash equivalence done well like we ended up with, we
have only two people interested/able to work on bugs with it, the author and
myself. For a key component of the system, this worries me a lot. Adding more
complexity without maintainer support isn't going to help anyone.
OK, I didn't know the story behind the change.

Could we take the version from BMW folks, merge and have the next person
add new features where it doesn't satisfy requirements?
See above on the BMW version. I'm a little worried you're suggesting merging
something which doesn't actually do what you need/want:(.
Got it.

or vice versa? or as Ross said some other work?
or none of the solutions are acceptable?
I have to admit I can't remember what the conclusion was on your team's version
but if you remind me of the patches I can try and remember. This is a bigger
problem than just patches though sadly.
Sure, let's find out what everyone is doing.


Re: Problems building eSDK: Exception: variable BBFILES references itself!

Richard Purdie
 

On Wed, 2022-02-09 at 18:10 +0000, Bryan Evenson wrote:
Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 12:25 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable BBFILES
references itself!

On Wed, 2022-02-09 at 16:51 +0000, Bryan Evenson wrote:
All,

I've used the SDK in the past and want to start using the eSDK for my
project.
I'm on the dunfell branch. I'm trying to build the eSDK for my image
by
calling:

bitbake <my_image_name> -c populate_sdk_ext

The sdk generation fails with the error in the subject. I haven't
been able to find any documentation on what this means or how to fix
it. I've tried deleting my tmp directory and running cleansstate on
my image and I still get the same error. I've also tried generating
the eSDK for core-image-minimal and I have the same error. I can
generate the SDK successfully, just not the eSDK. I have copied more
of the build output below if it helps. Note that I have replaced some
text that I'm paranoid about publishing on the internet; the modified text is
enclosed with <>.

Does anyone have any insight as to why the eSDK build is failing?
Could you share what bitbake -e shows BBFILES as being set to? The variable
history from that command for the variable may also be helpful.

There has to be something different to how you're setting it compared to
what we test on the autobuilder.

Cheers,

Richard
Here's what I was able to pull from bitbake -e. I've included details for
both BBFILES and BBFILES_DYNAMIC. Let me know if anything else would be
helpful.
Thanks, I'm not seeing anything too odd there. I guess next we need to see the
bblayers.conf that the code is building into the eSDK and compare it to your
original conf/bblayer.conf.

The generated file should be in the eSDK image directory somewhere, I'm not able
to look up the exact path right now. Let me know if you can't find it. Lets see
if the two bblayers.conf files look different and introduce some issue.

Cheers,

Richard


Re: Maintaining ABI Compatibility for LTS branch

Richard Purdie
 

On Wed, 2022-02-09 at 13:15 -0500, Sinan Kaya wrote:
On 2/9/2022 11:42 AM, Richard Purdie wrote:
There are two reasons people are interested:

a) for release stability as you mention
b) for performance as it could be tied into the hash equivalence mechanism for
artefact reuse - if A hasn't changed ABI, B dependning on it needn't rebuild.

There was a proof of concept of b) here:
https://lists.yoctoproject.org/g/yocto/message/52650

There are lots of levels it could be implemented at but it is something someone
would need to pick up and drive forward with a long term view to helping with
issues etc.
What would be the minimum acceptable solution with the least investment?
in other words, do we have a list of requirements?
You're after our LTS to maintain ABI. In order to do that we need help, not just
with patches generating some output, but in day to day running of the project,
i.e. help comparing output before and after changes. Whenever a patch is
submitted which breaks this, it will need attention and help some someone to
explain to that submitter what the issue, why it is important and hints on how
to fix it.

The idea of "least investment" sends shivers down my spine since it sounds like
you want to do the absolute bare minimum to have this happen, rather than a more
community oriented approach.

Anyway, my point is there is more to this than just a patch. We have various
kinds of build output already and reports on test regressions - nobody helps
with them. I need some kind of a sign that ABI would be different and there are
people able to help with review on an ongoing basis, else it will just be
something else I and a small number of others become overloaded with.

Our team has posted a solution. BMW folks posted a solution.
None of them got merged.
Can you remind me of your team's please?

The BMW one is about hash equivalence so wouldn't help your ABI output problem
with the LTS. From what I remember, it predates hash equivalence and the project
needed a generic equivalance mechanism complete with server done at the runqueue
level in bitbake. This has now happened so we could revisit the idea of what is
in that layer but translating it to a hash equivalence plugin.

I'd also add that even with hash equivalence done well like we ended up with, we
have only two people interested/able to work on bugs with it, the author and
myself. For a key component of the system, this worries me a lot. Adding more
complexity without maintainer support isn't going to help anyone.

Could we take the version from BMW folks, merge and have the next person
add new features where it doesn't satisfy requirements?
See above on the BMW version. I'm a little worried you're suggesting merging
something which doesn't actually do what you need/want :(.

or vice versa? or as Ross said some other work?
or none of the solutions are acceptable?
I have to admit I can't remember what the conclusion was on your team's version
but if you remind me of the patches I can try and remember. This is a bigger
problem than just patches though sadly.

Cheers,

Richard


Re: Maintaining ABI Compatibility for LTS branch

Sinan Kaya <okaya@...>
 

On 2/9/2022 11:42 AM, Richard Purdie wrote:
There are two reasons people are interested:
a) for release stability as you mention
b) for performance as it could be tied into the hash equivalence mechanism for
artefact reuse - if A hasn't changed ABI, B dependning on it needn't rebuild.
There was a proof of concept of b) here:
https://lists.yoctoproject.org/g/yocto/message/52650
There are lots of levels it could be implemented at but it is something someone
would need to pick up and drive forward with a long term view to helping with
issues etc.
What would be the minimum acceptable solution with the least investment?
in other words, do we have a list of requirements?

Our team has posted a solution. BMW folks posted a solution.
None of them got merged.

Could we take the version from BMW folks, merge and have the next person
add new features where it doesn't satisfy requirements?

or vice versa? or as Ross said some other work?

or none of the solutions are acceptable?


Re: Problems building eSDK: Exception: variable BBFILES references itself!

Bryan Evenson
 

Richard,

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, February 9, 2022 12:25 PM
To: Bryan Evenson <bevenson@...>;
yocto@...
Subject: Re: [yocto] Problems building eSDK: Exception: variable BBFILES
references itself!

On Wed, 2022-02-09 at 16:51 +0000, Bryan Evenson wrote:
All,

I've used the SDK in the past and want to start using the eSDK for my
project.
I'm on the dunfell branch. I'm trying to build the eSDK for my image
by
calling:

bitbake <my_image_name> -c populate_sdk_ext

The sdk generation fails with the error in the subject. I haven't
been able to find any documentation on what this means or how to fix
it. I've tried deleting my tmp directory and running cleansstate on
my image and I still get the same error. I've also tried generating
the eSDK for core-image-minimal and I have the same error. I can
generate the SDK successfully, just not the eSDK. I have copied more
of the build output below if it helps. Note that I have replaced some
text that I'm paranoid about publishing on the internet; the modified text is
enclosed with <>.

Does anyone have any insight as to why the eSDK build is failing?
Could you share what bitbake -e shows BBFILES as being set to? The variable
history from that command for the variable may also be helpful.

There has to be something different to how you're setting it compared to
what we test on the autobuilder.

Cheers,

Richard
Here's what I was able to pull from bitbake -e. I've included details for both BBFILES and BBFILES_DYNAMIC. Let me know if anything else would be helpful.

Thanks,
Bryan

# $BBFILES [24 operations]
# set? <my_home_dir>/poky/poky-build/conf/bblayers.conf:6
# ""
# immediate <my_home_dir>/poky/<my_custom_layer1>/conf/layer.conf:6
# "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
# append <my_home_dir>/poky/<my_custom_layer2>/conf/layer.conf:5
# "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend"
# append <my_home_dir>/poky/meta-bacnet/conf/layer.conf:6
# "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend"
# append <my_home_dir>/poky/meta-atmel/conf/layer.conf:5
# "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend"
# append <my_home_dir>/poky/meta/conf/layer.conf:4
# "${LAYERDIR}/recipes-*/*/*.bb"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb"
# append <my_home_dir>/poky/meta-poky/conf/layer.conf:6
# "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bbappend"
# append <my_home_dir>/poky/meta-yocto-bsp/conf/layer.conf:6
# "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bbappend"
# append <my_home_dir>/poky/meta-openembedded/meta-oe/conf/layer.conf:15
# "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bbappend"
# append <my_home_dir>/poky/meta-openembedded/meta-networking/conf/layer.conf:6
# "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bbappend"
# append <my_home_dir>/poky/meta-openembedded/meta-python/conf/layer.conf:5
# "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-python/recipes*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-python/recipes*/*/*.bbappend"
# append <my_home_dir>/poky/poky-build/workspace/conf/layer.conf:4
# "${LAYERDIR}/recipes/*/*.bb ${LAYERDIR}/appends/*.bbappend"
# set data_smart.py:945 [expandVarref]
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-python/recipes*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-python/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/workspace/recipes/*/*.bb <my_home_dir>/poky/poky-build/workspace/appends/*.bbappend"
# append cookerdata.py:401 [parseConfigurationFiles]
# " <my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/meta-python/recipes-*/*/*.bb"
# set <my_home_dir>/poky/meta/conf/documentation.conf:90
# [doc] "List of recipe files used by BitBake to build software."
# pre-expansion value:
# " <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-python/recipes*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-python/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/workspace/recipes/*/*.bb <my_home_dir>/poky/poky-build/workspace/appends/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/meta-python/recipes-*/*/*.bb"
BBFILES=" <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/meta-yocto-bsp/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-oe/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-networking/recipes-*/*/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-python/recipes*/*/*.bb <my_home_dir>/poky/meta-openembedded/meta-python/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/workspace/recipes/*/*.bb <my_home_dir>/poky/poky-build/workspace/appends/*.bbappend <my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/meta-python/recipes-*/*/*.bb"
#
# $BBFILES_DYNAMIC [4 operations]
# append <my_home_dir>/poky/meta-atmel/conf/layer.conf:21
# " meta-aws:${LAYERDIR}/dynamic-layers/aws-layer/*/*/*.bb meta-aws:${LAYERDIR}/dynamic-layers/aws-layer/*/*/*.bbappend "
# set data_smart.py:945 [expandVarref]
# " meta-aws:<my_home_dir>/poky/meta-atmel/dynamic-layers/aws-layer/*/*/*.bb meta-aws:<my_home_dir>/poky/meta-atmel/dynamic-layers/aws-layer/*/*/*.bbappend "
# append <my_home_dir>/poky/meta-openembedded/meta-oe/conf/layer.conf:31
# " meta-python:${LAYERDIR}/dynamic-layers/meta-python/recipes-*/*/*.bb perl-layer:${LAYERDIR}/dynamic-layers/perl-layer/recipes-*/*/*.bb "
# set data_smart.py:945 [expandVarref]
# " meta-aws:<my_home_dir>/poky/meta-atmel/dynamic-layers/aws-layer/*/*/*.bb meta-aws:<my_home_dir>/poky/meta-atmel/dynamic-layers/aws-layer/*/*/*.bbappend meta-python:<my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/meta-python/recipes-*/*/*.bb perl-layer:<my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/perl-layer/recipes-*/*/*.bb "
# pre-expansion value:
# " meta-aws:<my_home_dir>/poky/meta-atmel/dynamic-layers/aws-layer/*/*/*.bb meta-aws:<my_home_dir>/poky/meta-atmel/dynamic-layers/aws-layer/*/*/*.bbappend meta-python:<my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/meta-python/recipes-*/*/*.bb perl-layer:<my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/perl-layer/recipes-*/*/*.bb "
BBFILES_DYNAMIC=" meta-aws:<my_home_dir>/poky/meta-atmel/dynamic-layers/aws-layer/*/*/*.bb meta-aws:<my_home_dir>/poky/meta-atmel/dynamic-layers/aws-layer/*/*/*.bbappend meta-python:<my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/meta-python/recipes-*/*/*.bb perl-layer:<my_home_dir>/poky/meta-openembedded/meta-oe/dynamic-layers/perl-layer/recipes-*/*/*.bb "


Re: Maintaining ABI Compatibility for LTS branch

Khem Raj
 

On Wed, Feb 9, 2022 at 8:37 AM Steve Sakoman <steve@...> wrote:

On Tue, Feb 8, 2022 at 1:07 PM Richard Purdie
<richard.purdie@...> wrote:

Forwarding to the correct list address and cc the LTS maintainer.

Cheers,

Richard



---------- Forwarded message ----------
From: Sinan Kaya <okaya@...>
To: Richard Purdie <richard.purdie@...>, Paul Eggleton <bluelightning@...>, Yocto list discussion <yocto@...>
Cc:
Bcc:
Date: Sun, 6 Feb 2022 20:14:37 -0500
Subject: Maintaining ABI Compatibility for LTS branch
Hi Everyone,

One of the limitations of Yocto LTS branch is that there is no
guaranteed backwards compatibility. Therefore, any time we move a branch
forward to move to latest dunfell release, we are taking a risk of
breaking our customers.
I'd be interested in hearing about any cases where we've broken things!

In general I don't take version upgrades (other than bug fix/cve fix
only dot releases)

Yocto reserves the right to move a package version forward if a
security fix cannot be applied properly as an example.
These cases should be extremely rare, and the community/technical
steering committee is given an opportunity to review this before it
happens.

I'm certainly open to suggestions on how we can do better.

I'd love to see some tooling to do ABI checking!
I think its not that LTS itself but also upgrade from LTS to LTS or other
newer versions, it wouuld be good to have this tool and prerhaps a list
of API/ABI changes to help migration/upgrade to newer LTS releases.


Steve

This promise is being held true on the kernel by running kernel API
tests etc. and running test benches across different CI environments.

I was curious about how everyone is approaching this problem.
There was some attempt to bring ABI checking functionality in the past
but this has never been merged.

Is everyone rolling their own solution? or never moving forward?

Sinan


Re: Error: Transaction check error: while doing do_rootfs task

Khem Raj
 

I think core-image-swupdate.bb is adding sysvinit explicitly, please
remove it from that.

On Wed, Feb 9, 2022 at 6:54 AM Sourabh Hegde <hrsourabh011@...> wrote:

Hello All,

While bitbaking an image recipe with systemd configured in "local.conf", I am facing an error while doing do_rootfs task.

In the local.conf :

DISTRO_FEATURES_append = " systemd"
#DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

Bitbake error:
.
.
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
file /sbin/telinit conflicts between attempted installs of sysvinit-2.96-r0.cortexa7t2hf_neon_vfpv4 and systemd-1:244.5-r0.cortexa7t2hf_neon_vfpv4

I was not facing this error before without systemd.

Can anyone please let me know how to resolve this error and what does this error mean?

Your help will be much appreciated.

Thanks in advance

P.S: If I uncomment DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" in local.conf I get below error:

ERROR: Nothing RPROVIDES 'sysvinit' (but [...]/core-image-swupdate.bb RDEPENDS on or otherwise requires it)
sysvinit was skipped: missing required distro feature 'sysvinit' (not in DISTRO_FEATURES)

1241 - 1260 of 57339