| Message ID | 20250205212427.2044310-1-JPEWhacker@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | bitbake.conf: Include fragments before local.conf | expand |
We have discussed this before. With this change, users will no longer be able to set fragments from local.conf, as addfragments would be processed before that file. You need to use ?= in fragments instead for things that are meant to be overridden. Alex On Wed 5. Feb 2025 at 22.24, Joshua Watt <jpewhacker@gmail.com> wrote: > Per some usability assessment and offline discussion, one of the useful > use cases of config fragments is that they allow the "default" > configuration for some device to be committed to source control and > easily selected and used by the end users. However, when doing this, > there is still the desire that the user can "override" the provided > fragments for their local builds in local.conf > > As a practical example, the configuration for a product can be capture > as a config fragment, and an empty local.conf will reproduce the > standard build for the product. If the user wants to make "tweaks" to > the standard build, they can do so in local.conf > > As such, move the config fragments to be loaded before local.conf > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > --- > meta/conf/bitbake.conf | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > index 8b607088c6e..d0154044f5a 100644 > --- a/meta/conf/bitbake.conf > +++ b/meta/conf/bitbake.conf > @@ -826,12 +826,13 @@ FILESOVERRIDES = > "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDE > require conf/abi_version.conf > include conf/site.conf > include conf/auto.conf > -include conf/local.conf > > OE_FRAGMENTS_PREFIX ?= "conf/fragments" > OE_FRAGMENTS_METADATA_VARS ?= "BB_CONF_FRAGMENT_SUMMARY > BB_CONF_FRAGMENT_DESCRIPTION" > addfragments ${OE_FRAGMENTS_PREFIX} OE_FRAGMENTS > OE_FRAGMENTS_METADATA_VARS > > +include conf/local.conf > + > require ${@"conf/multiconfig/${BB_CURRENT_MC}.conf" if "${BB_CURRENT_MC}" > != "" else ""} > include conf/machine/${MACHINE}.conf > include conf/machine-sdk/${SDKMACHINE}.conf > -- > 2.47.1 > >
On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > We have discussed this before. With this change, users will no longer be able to set fragments from local.conf, as addfragments would be processed before that file. You need to use ?= in fragments instead for things that are meant to be overridden. Is there need to set fragments from local.conf? IMHO, not being able to override a fragment in local.conf is "surprising" behavior, and I don't think it's going to necessarily be possible to alway use ?= in a fragment; all of the ad-hoc "fragment" management systems I've used before have allowed local.conf to be the final source of truth, so it will also make migration to use config fragments harder if they don't follow suite. Anyway, maybe some other users of "fragment" like systems can chime in if they have an opinion. > > Alex > > On Wed 5. Feb 2025 at 22.24, Joshua Watt <jpewhacker@gmail.com> wrote: >> >> Per some usability assessment and offline discussion, one of the useful >> use cases of config fragments is that they allow the "default" >> configuration for some device to be committed to source control and >> easily selected and used by the end users. However, when doing this, >> there is still the desire that the user can "override" the provided >> fragments for their local builds in local.conf >> >> As a practical example, the configuration for a product can be capture >> as a config fragment, and an empty local.conf will reproduce the >> standard build for the product. If the user wants to make "tweaks" to >> the standard build, they can do so in local.conf >> >> As such, move the config fragments to be loaded before local.conf >> >> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >> --- >> meta/conf/bitbake.conf | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf >> index 8b607088c6e..d0154044f5a 100644 >> --- a/meta/conf/bitbake.conf >> +++ b/meta/conf/bitbake.conf >> @@ -826,12 +826,13 @@ FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDE >> require conf/abi_version.conf >> include conf/site.conf >> include conf/auto.conf >> -include conf/local.conf >> >> OE_FRAGMENTS_PREFIX ?= "conf/fragments" >> OE_FRAGMENTS_METADATA_VARS ?= "BB_CONF_FRAGMENT_SUMMARY BB_CONF_FRAGMENT_DESCRIPTION" >> addfragments ${OE_FRAGMENTS_PREFIX} OE_FRAGMENTS OE_FRAGMENTS_METADATA_VARS >> >> +include conf/local.conf >> + >> require ${@"conf/multiconfig/${BB_CURRENT_MC}.conf" if "${BB_CURRENT_MC}" != "" else ""} >> include conf/machine/${MACHINE}.conf >> include conf/machine-sdk/${SDKMACHINE}.conf >> -- >> 2.47.1 >>
One could conceivably want to ship a local.conf.sample template with fragments already enabled in it, or hand edit local.conf to enable something via fragment. We can’t force users to use fragment tooling. It would be equally surprising to find out that setting fragments this way doesn’t actually have any effect. I understand your argument, it’s just that we’ve taken the least worst option. Consider fragments as extensions of distro and machine configurations - both come after local.conf and can’t be tweaked from it. Alex On Wed 5. Feb 2025 at 22.55, Joshua Watt <jpewhacker@gmail.com> wrote: > On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin <alex.kanavin@gmail.com> > wrote: > > > > We have discussed this before. With this change, users will no longer be > able to set fragments from local.conf, as addfragments would be processed > before that file. You need to use ?= in fragments instead for things that > are meant to be overridden. > > Is there need to set fragments from local.conf? IMHO, not being able > to override a fragment in local.conf is "surprising" behavior, and I > don't think it's going to necessarily be possible to alway use ?= in a > fragment; all of the ad-hoc "fragment" management systems I've used > before have allowed local.conf to be the final source of truth, so it > will also make migration to use config fragments harder if they don't > follow suite. > > Anyway, maybe some other users of "fragment" like systems can chime in > if they have an opinion. > > > > > Alex > > > > On Wed 5. Feb 2025 at 22.24, Joshua Watt <jpewhacker@gmail.com> wrote: > >> > >> Per some usability assessment and offline discussion, one of the useful > >> use cases of config fragments is that they allow the "default" > >> configuration for some device to be committed to source control and > >> easily selected and used by the end users. However, when doing this, > >> there is still the desire that the user can "override" the provided > >> fragments for their local builds in local.conf > >> > >> As a practical example, the configuration for a product can be capture > >> as a config fragment, and an empty local.conf will reproduce the > >> standard build for the product. If the user wants to make "tweaks" to > >> the standard build, they can do so in local.conf > >> > >> As such, move the config fragments to be loaded before local.conf > >> > >> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > >> --- > >> meta/conf/bitbake.conf | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > >> index 8b607088c6e..d0154044f5a 100644 > >> --- a/meta/conf/bitbake.conf > >> +++ b/meta/conf/bitbake.conf > >> @@ -826,12 +826,13 @@ FILESOVERRIDES = > "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDE > >> require conf/abi_version.conf > >> include conf/site.conf > >> include conf/auto.conf > >> -include conf/local.conf > >> > >> OE_FRAGMENTS_PREFIX ?= "conf/fragments" > >> OE_FRAGMENTS_METADATA_VARS ?= "BB_CONF_FRAGMENT_SUMMARY > BB_CONF_FRAGMENT_DESCRIPTION" > >> addfragments ${OE_FRAGMENTS_PREFIX} OE_FRAGMENTS > OE_FRAGMENTS_METADATA_VARS > >> > >> +include conf/local.conf > >> + > >> require ${@"conf/multiconfig/${BB_CURRENT_MC}.conf" if > "${BB_CURRENT_MC}" != "" else ""} > >> include conf/machine/${MACHINE}.conf > >> include conf/machine-sdk/${SDKMACHINE}.conf > >> -- > >> 2.47.1 > >> >
Btw the other option for overriding fragments would be to use direct require statement with a path to them in local.conf, followed by tweaks. It’s not too horrible. And using a fragment variable can then be seen as ‘immutable’ fragment enabling which could be beneficial precisely because users can’t mess with it. Alex On Wed 5. Feb 2025 at 23.26, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > One could conceivably want to ship a local.conf.sample template with > fragments already enabled in it, or hand edit local.conf to enable > something via fragment. We can’t force users to use fragment tooling. > > It would be equally surprising to find out that setting fragments this way > doesn’t actually have any effect. > > I understand your argument, it’s just that we’ve taken the least worst > option. Consider fragments as extensions of distro and machine > configurations - both come after local.conf and can’t be tweaked from it. > > Alex > > On Wed 5. Feb 2025 at 22.55, Joshua Watt <jpewhacker@gmail.com> wrote: > >> On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin <alex.kanavin@gmail.com> >> wrote: >> > >> > We have discussed this before. With this change, users will no longer >> be able to set fragments from local.conf, as addfragments would be >> processed before that file. You need to use ?= in fragments instead for >> things that are meant to be overridden. >> >> Is there need to set fragments from local.conf? IMHO, not being able >> to override a fragment in local.conf is "surprising" behavior, and I >> don't think it's going to necessarily be possible to alway use ?= in a >> fragment; all of the ad-hoc "fragment" management systems I've used >> before have allowed local.conf to be the final source of truth, so it >> will also make migration to use config fragments harder if they don't >> follow suite. >> >> Anyway, maybe some other users of "fragment" like systems can chime in >> if they have an opinion. >> >> > >> > Alex >> > >> > On Wed 5. Feb 2025 at 22.24, Joshua Watt <jpewhacker@gmail.com> wrote: >> >> >> >> Per some usability assessment and offline discussion, one of the useful >> >> use cases of config fragments is that they allow the "default" >> >> configuration for some device to be committed to source control and >> >> easily selected and used by the end users. However, when doing this, >> >> there is still the desire that the user can "override" the provided >> >> fragments for their local builds in local.conf >> >> >> >> As a practical example, the configuration for a product can be capture >> >> as a config fragment, and an empty local.conf will reproduce the >> >> standard build for the product. If the user wants to make "tweaks" to >> >> the standard build, they can do so in local.conf >> >> >> >> As such, move the config fragments to be loaded before local.conf >> >> >> >> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >> >> --- >> >> meta/conf/bitbake.conf | 3 ++- >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf >> >> index 8b607088c6e..d0154044f5a 100644 >> >> --- a/meta/conf/bitbake.conf >> >> +++ b/meta/conf/bitbake.conf >> >> @@ -826,12 +826,13 @@ FILESOVERRIDES = >> "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDE >> >> require conf/abi_version.conf >> >> include conf/site.conf >> >> include conf/auto.conf >> >> -include conf/local.conf >> >> >> >> OE_FRAGMENTS_PREFIX ?= "conf/fragments" >> >> OE_FRAGMENTS_METADATA_VARS ?= "BB_CONF_FRAGMENT_SUMMARY >> BB_CONF_FRAGMENT_DESCRIPTION" >> >> addfragments ${OE_FRAGMENTS_PREFIX} OE_FRAGMENTS >> OE_FRAGMENTS_METADATA_VARS >> >> >> >> +include conf/local.conf >> >> + >> >> require ${@"conf/multiconfig/${BB_CURRENT_MC}.conf" if >> "${BB_CURRENT_MC}" != "" else ""} >> >> include conf/machine/${MACHINE}.conf >> >> include conf/machine-sdk/${SDKMACHINE}.conf >> >> -- >> >> 2.47.1 >> >> >> > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#210881): > https://lists.openembedded.org/g/openembedded-core/message/210881 > Mute This Topic: https://lists.openembedded.org/mt/111021218/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Wed, Feb 5, 2025 at 3:26 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > One could conceivably want to ship a local.conf.sample template with fragments already enabled in it, or hand edit local.conf to enable something via fragment. We can’t force users to use fragment tooling. > > It would be equally surprising to find out that setting fragments this way doesn’t actually have any effect. > > I understand your argument, it’s just that we’ve taken the least worst option. Consider fragments as extensions of distro and machine configurations - both come after local.conf and can’t be tweaked from it. That's an expected design choice; we already have MACHINE and DISTRO which work pretty well, so I though config fragments were intended to standardize the part that is more difficult e.g. setting configuration files from source control roundabout the time of auto.conf, since that is where all the different mechanisms that have cropped up do. > > Alex > > On Wed 5. Feb 2025 at 22.55, Joshua Watt <jpewhacker@gmail.com> wrote: >> >> On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote: >> > >> > We have discussed this before. With this change, users will no longer be able to set fragments from local.conf, as addfragments would be processed before that file. You need to use ?= in fragments instead for things that are meant to be overridden. >> >> Is there need to set fragments from local.conf? IMHO, not being able >> to override a fragment in local.conf is "surprising" behavior, and I >> don't think it's going to necessarily be possible to alway use ?= in a >> fragment; all of the ad-hoc "fragment" management systems I've used >> before have allowed local.conf to be the final source of truth, so it >> will also make migration to use config fragments harder if they don't >> follow suite. >> >> Anyway, maybe some other users of "fragment" like systems can chime in >> if they have an opinion. >> >> > >> > Alex >> > >> > On Wed 5. Feb 2025 at 22.24, Joshua Watt <jpewhacker@gmail.com> wrote: >> >> >> >> Per some usability assessment and offline discussion, one of the useful >> >> use cases of config fragments is that they allow the "default" >> >> configuration for some device to be committed to source control and >> >> easily selected and used by the end users. However, when doing this, >> >> there is still the desire that the user can "override" the provided >> >> fragments for their local builds in local.conf >> >> >> >> As a practical example, the configuration for a product can be capture >> >> as a config fragment, and an empty local.conf will reproduce the >> >> standard build for the product. If the user wants to make "tweaks" to >> >> the standard build, they can do so in local.conf >> >> >> >> As such, move the config fragments to be loaded before local.conf >> >> >> >> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >> >> --- >> >> meta/conf/bitbake.conf | 3 ++- >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf >> >> index 8b607088c6e..d0154044f5a 100644 >> >> --- a/meta/conf/bitbake.conf >> >> +++ b/meta/conf/bitbake.conf >> >> @@ -826,12 +826,13 @@ FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDE >> >> require conf/abi_version.conf >> >> include conf/site.conf >> >> include conf/auto.conf >> >> -include conf/local.conf >> >> >> >> OE_FRAGMENTS_PREFIX ?= "conf/fragments" >> >> OE_FRAGMENTS_METADATA_VARS ?= "BB_CONF_FRAGMENT_SUMMARY BB_CONF_FRAGMENT_DESCRIPTION" >> >> addfragments ${OE_FRAGMENTS_PREFIX} OE_FRAGMENTS OE_FRAGMENTS_METADATA_VARS >> >> >> >> +include conf/local.conf >> >> + >> >> require ${@"conf/multiconfig/${BB_CURRENT_MC}.conf" if "${BB_CURRENT_MC}" != "" else ""} >> >> include conf/machine/${MACHINE}.conf >> >> include conf/machine-sdk/${SDKMACHINE}.conf >> >> -- >> >> 2.47.1 >> >>
On Wed, Feb 5, 2025 at 3:37 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > Btw the other option for overriding fragments would be to use direct require statement with a path to them in local.conf, followed by tweaks. It’s not too horrible. And using a fragment variable can then be seen as ‘immutable’ fragment enabling which could be beneficial precisely because users can’t mess with it. Sure, and I've done that before. I assumed this was intended to replace that behavior with a nicer UI, but apparently that was not the goal? > > Alex > > On Wed 5. Feb 2025 at 23.26, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: >> >> One could conceivably want to ship a local.conf.sample template with fragments already enabled in it, or hand edit local.conf to enable something via fragment. We can’t force users to use fragment tooling. >> >> It would be equally surprising to find out that setting fragments this way doesn’t actually have any effect. >> >> I understand your argument, it’s just that we’ve taken the least worst option. Consider fragments as extensions of distro and machine configurations - both come after local.conf and can’t be tweaked from it. >> >> Alex >> >> On Wed 5. Feb 2025 at 22.55, Joshua Watt <jpewhacker@gmail.com> wrote: >>> >>> On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote: >>> > >>> > We have discussed this before. With this change, users will no longer be able to set fragments from local.conf, as addfragments would be processed before that file. You need to use ?= in fragments instead for things that are meant to be overridden. >>> >>> Is there need to set fragments from local.conf? IMHO, not being able >>> to override a fragment in local.conf is "surprising" behavior, and I >>> don't think it's going to necessarily be possible to alway use ?= in a >>> fragment; all of the ad-hoc "fragment" management systems I've used >>> before have allowed local.conf to be the final source of truth, so it >>> will also make migration to use config fragments harder if they don't >>> follow suite. >>> >>> Anyway, maybe some other users of "fragment" like systems can chime in >>> if they have an opinion. >>> >>> > >>> > Alex >>> > >>> > On Wed 5. Feb 2025 at 22.24, Joshua Watt <jpewhacker@gmail.com> wrote: >>> >> >>> >> Per some usability assessment and offline discussion, one of the useful >>> >> use cases of config fragments is that they allow the "default" >>> >> configuration for some device to be committed to source control and >>> >> easily selected and used by the end users. However, when doing this, >>> >> there is still the desire that the user can "override" the provided >>> >> fragments for their local builds in local.conf >>> >> >>> >> As a practical example, the configuration for a product can be capture >>> >> as a config fragment, and an empty local.conf will reproduce the >>> >> standard build for the product. If the user wants to make "tweaks" to >>> >> the standard build, they can do so in local.conf >>> >> >>> >> As such, move the config fragments to be loaded before local.conf >>> >> >>> >> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >>> >> --- >>> >> meta/conf/bitbake.conf | 3 ++- >>> >> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >> >>> >> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf >>> >> index 8b607088c6e..d0154044f5a 100644 >>> >> --- a/meta/conf/bitbake.conf >>> >> +++ b/meta/conf/bitbake.conf >>> >> @@ -826,12 +826,13 @@ FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDE >>> >> require conf/abi_version.conf >>> >> include conf/site.conf >>> >> include conf/auto.conf >>> >> -include conf/local.conf >>> >> >>> >> OE_FRAGMENTS_PREFIX ?= "conf/fragments" >>> >> OE_FRAGMENTS_METADATA_VARS ?= "BB_CONF_FRAGMENT_SUMMARY BB_CONF_FRAGMENT_DESCRIPTION" >>> >> addfragments ${OE_FRAGMENTS_PREFIX} OE_FRAGMENTS OE_FRAGMENTS_METADATA_VARS >>> >> >>> >> +include conf/local.conf >>> >> + >>> >> require ${@"conf/multiconfig/${BB_CURRENT_MC}.conf" if "${BB_CURRENT_MC}" != "" else ""} >>> >> include conf/machine/${MACHINE}.conf >>> >> include conf/machine-sdk/${SDKMACHINE}.conf >>> >> -- >>> >> 2.47.1 >>> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#210881): https://lists.openembedded.org/g/openembedded-core/message/210881 >> Mute This Topic: https://lists.openembedded.org/mt/111021218/1686489 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >>
On Wed, 2025-02-05 at 14:55 -0700, Joshua Watt via lists.openembedded.org wrote: > On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin > <alex.kanavin@gmail.com> wrote: > > > > We have discussed this before. With this change, users will no > > longer be able to set fragments from local.conf, as addfragments > > would be processed before that file. You need to use ?= in > > fragments instead for things that are meant to be overridden. > > Is there need to set fragments from local.conf? IMHO, not being able > to override a fragment in local.conf is "surprising" behavior, and I > don't think it's going to necessarily be possible to alway use ?= in > a fragment; all of the ad-hoc "fragment" management systems I've used > before have allowed local.conf to be the final source of truth, so it > will also make migration to use config fragments harder if they don't > follow suite. > > Anyway, maybe some other users of "fragment" like systems can chime > in if they have an opinion. FWIW, setting fragments in local.conf is exactly how I first tried to use them and I can see users doing that :/ Cheers, Richard
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 8b607088c6e..d0154044f5a 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -826,12 +826,13 @@ FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDE require conf/abi_version.conf include conf/site.conf include conf/auto.conf -include conf/local.conf OE_FRAGMENTS_PREFIX ?= "conf/fragments" OE_FRAGMENTS_METADATA_VARS ?= "BB_CONF_FRAGMENT_SUMMARY BB_CONF_FRAGMENT_DESCRIPTION" addfragments ${OE_FRAGMENTS_PREFIX} OE_FRAGMENTS OE_FRAGMENTS_METADATA_VARS +include conf/local.conf + require ${@"conf/multiconfig/${BB_CURRENT_MC}.conf" if "${BB_CURRENT_MC}" != "" else ""} include conf/machine/${MACHINE}.conf include conf/machine-sdk/${SDKMACHINE}.conf
Per some usability assessment and offline discussion, one of the useful use cases of config fragments is that they allow the "default" configuration for some device to be committed to source control and easily selected and used by the end users. However, when doing this, there is still the desire that the user can "override" the provided fragments for their local builds in local.conf As a practical example, the configuration for a product can be capture as a config fragment, and an empty local.conf will reproduce the standard build for the product. If the user wants to make "tweaks" to the standard build, they can do so in local.conf As such, move the config fragments to be loaded before local.conf Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> --- meta/conf/bitbake.conf | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)