local.conf & bblayers.conf changes...
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
--rich
Quoted 5 lines · Rich Pixley
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
For bblayers.conf, we bumped the version becase we moved the BBPATH initial setting into the bblayers.conf to ensure we dont accidently pickup things in . because of the way a :: was being parsed. See this commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e3a61b40b7b697d83b41e7e247cd1f94eb7673c
Not sure what you mean about local.conf, since I am not sure of your starting point.
Sau!
Quoted 8 lines
--rich
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 6 lines · Saul Wold
Quoted 5 lines · Rich Pixley
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
Quoted 8 lines
For bblayers.conf, we bumped the version becase we moved the BBPATH initial setting into the bblayers.conf to ensure we dont accidently pickup things in . because of the way a :: was being parsed. See this commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e3a61b40b7b697d83b41e7e247cd1f94eb7673cNot sure what you mean about local.conf, since I am not sure of your starting point.
Ok, so I *liked* having BBPATH be relative. The alternative, using absolute pathnames, means that you have to bolt absolute path names into all of your binaries, all of your debug symbols, and all of your build configurations. This means that your binary sizes are greater, that debug symbols are significantly greater and more difficult to configure properly in your debuger, and that working directories cannot be moved around or renamed without needing to manually force full rebuilds. It also means that some forms of file system checkpointing can't be used since you can't rely on the build to be in the same place on the file system every build.
I'll try to roll with the current plan, though.
In the current arrangement, I'm getting confusing messages about not setting MACHINE, even though MACHINE is set in my local.conf. I'm guessing that means that the pathing is busted and it's not finding my local.conf. How is the initial configuration file found? And which configuration file is initial? Is that "./conf/bblayers.conf"? And if so, does this mean that I need to put my other directory assignments like TOPDIR and TMPDIR in bblayers.conf as well? And if so, then what's the logical distinction between bblayers.conf and local.conf at this point if build policy needs to go into bblayers.conf?
--rich
Quoted 6 lines · Saul Wold
Quoted 5 lines · Rich Pixley
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
Quoted 8 lines
For bblayers.conf, we bumped the version becase we moved the BBPATH initial setting into the bblayers.conf to ensure we dont accidently pickup things in . because of the way a :: was being parsed. See this commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e3a61b40b7b697d83b41e7e247cd1f94eb7673cNot sure what you mean about local.conf, since I am not sure of your starting point.
Maybe he refers to OELAYOUT_ABI change from:
http://git.openembedded.org/openembedded-core/commit/?id=4199efed48005a62267fa3374c33b13627d85f44
Which in sanity.conf suggests:
"To continue, either rebuild or switch back to the OEBasic signature
handler with BB_SIGNATURE_HANDLER = 'OEBasic'."
see: http://git.openembedded.org/openembedded-core/commit/meta/classes/sanity.bbclass?id=bf440fd971dd549ae4e92c54046ea062ef51cd85
but doesn't say that if you decide to switch back to OEBasic signature handler that you have to also bump tmp-eglibc/abi_version to 8 to silence this sanity check and keep OEBasic without rebuilding.
Cheers,
Quoted 17 lines
Sau!
Quoted 8 lines
--rich
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 15 lines · Rich Pixley
Quoted 6 lines · Saul Wold
Quoted 5 lines · Rich Pixley
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
Quoted 8 lines
For bblayers.conf, we bumped the version becase we moved the BBPATH initial setting into the bblayers.conf to ensure we dont accidently pickup things in . because of the way a :: was being parsed. See this commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e3a61b40b7b697d83b41e7e247cd1f94eb7673cNot sure what you mean about local.conf, since I am not sure of your starting point.
Quoted 10 lines
Ok, so I *liked* having BBPATH be relative. The alternative, using absolute pathnames, means that you have to bolt absolute path names into all of your binaries, all of your debug symbols, and all of your build configurations. This means that your binary sizes are greater, that debug symbols are significantly greater and more difficult to configure properly in your debuger, and that working directories cannot be moved around or renamed without needing to manually force full rebuilds. It also means that some forms of file system checkpointing can't be used since you can't rely on the build to be in the same place on the file system every build.
BBPATH being relative doesn't affect what ends up in debug symbols, etc.
The BBPATH needs to be absolute, within the scope of a single loaded session to avoid randomly included items, primarily from the CWD. This prevents non-repeatable builds.
In a layer, the typical BBPATH is something like:
BBPATH := "${LAYERDIR}:${BBPATH}"
LAYERDIR is always the path to the layer being processed at any given time... so if a layer also provides addition scripts you can do:
# Add scripts to PATH
PATH := "${PATH}:${LAYERDIR}/scripts"
As for the debug items, the system handles all of the debug symbols for you. All target symbols are referenced from the -root- of the target filesystem. If this is not happening in your builds, then you've disabled the debug symbol processing -- or you found a bug in the system... On the target side, debugging on the target that is, everything should 'just work' with no manual settings.
On a remote debug, you just need to tell the system where the relative path is to the root of the filesystem you are debugging, gdb should then be able to add the references to the associated sources and .debug split items.
This is all unchanged behavior for oe-core from when it was made oe-core to present.
Quoted 6 lines
I'll try to roll with the current plan, though.
In the current arrangement, I'm getting confusing messages about not setting MACHINE, even though MACHINE is set in my local.conf. I'm guessing that means that the pathing is busted and it's not finding my local.conf. How is the initial configuration file found? And which
If it says MACHINE isn't configured, then you are lacking a proper BSP/machine configuration file.
There are a couple of checks, but in the end they resolve down to checking that TUNE_ARCH, TARGET_OS, and TUNE_PKGARCH exit and are reasonable, as well as conf/machine/${MACHINE}.conf can be loaded.
Any of the above items not found or not configured properly indicate MACHINE isn't defined, or the conf/machine/${MACHINE}.conf doesn't exist -- or is incorrectly configured.
Quoted 5 lines
configuration file is initial? Is that "
./conf/bblayers.conf"? And if so, does this mean that I need to put my other directory assignments like TOPDIR and TMPDIR in bblayers.conf as well? And if so, then what's the logical distinction between bblayers.conf and local.conf at this point if build policy needs to go into bblayers.conf?
bblayers shouldn't affect your machine files, other then a layer may contain a conf/machine/...conf file. The BBPATH setting of ${LAYERDIR} allows this directory to be automatically scanned when requesting a conf file.
--Mark
Quoted 7 lines
--rich
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 10 lines · Rich Pixley
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
--rich
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Hi Rich,
What I did was create a new build directory and do a diff between my current config and the newly generated config.
I couldn't find the reference local.conf file that bitbake tells you to compare against...
Regards,
Jack.
Quoted 29 lines · Mark Hatle
Quoted 15 lines · Rich Pixley
Quoted 6 lines · Saul Wold
Quoted 5 lines · Rich Pixley
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
Quoted 8 lines
For bblayers.conf, we bumped the version becase we moved the BBPATH initial setting into the bblayers.conf to ensure we dont accidently pickup things in . because of the way a :: was being parsed. See this commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e3a61b40b7b697d83b41e7e247cd1f94eb7673cNot sure what you mean about local.conf, since I am not sure of your starting point.
Quoted 10 lines
Ok, so I *liked* having BBPATH be relative. The alternative, using absolute pathnames, means that you have to bolt absolute path names into all of your binaries, all of your debug symbols, and all of your build configurations. This means that your binary sizes are greater, that debug symbols are significantly greater and more difficult to configure properly in your debuger, and that working directories cannot be moved around or renamed without needing to manually force full rebuilds. It also means that some forms of file system checkpointing can't be used since you can't rely on the build to be in the same place on the file system every build.
BBPATH being relative doesn't affect what ends up in debug symbols, etc.
Quoted 7 lines
The BBPATH needs to be absolute, within the scope of a single loaded session to avoid randomly included items, primarily from the CWD. This prevents non-repeatable builds.
In a layer, the typical BBPATH is something like:
BBPATH := "${LAYERDIR}:${BBPATH}"
No, please append to it, so order of layers in BBPATH is the same as order of layers in BBLAYERS variable in bblayers.conf
So typical BBPATH in layer.conf should be:
BBPATH .= ":${LAYERDIR}"
This is now consistent in all layers I'm using and quick search in layers I'm not using shows only meta-baryon having it vice versa.
Cheers,
Quoted 64 lines
LAYERDIR is always the path to the layer being processed at any given time... so if a layer also provides addition scripts you can do:
# Add scripts to PATH
PATH := "${PATH}:${LAYERDIR}/scripts"As for the debug items, the system handles all of the debug symbols for you. All target symbols are referenced from the -root- of the target filesystem. If this is not happening in your builds, then you've disabled the debug symbol processing -- or you found a bug in the system... On the target side, debugging on the target that is, everything should 'just work' with no manual settings.
On a remote debug, you just need to tell the system where the relative path is to the root of the filesystem you are debugging, gdb should then be able to add the references to the associated sources and .debug split items.
This is all unchanged behavior for oe-core from when it was made oe-core to present.
Quoted 6 lines
I'll try to roll with the current plan, though.
In the current arrangement, I'm getting confusing messages about not setting MACHINE, even though MACHINE is set in my local.conf. I'm guessing that means that the pathing is busted and it's not finding my local.conf. How is the initial configuration file found? And which
If it says MACHINE isn't configured, then you are lacking a proper BSP/machine configuration file.
There are a couple of checks, but in the end they resolve down to checking that
TUNE_ARCH,TARGET_OS, andTUNE_PKGARCHexit and are reasonable, as well asconf/machine/${MACHINE}.confcan be loaded.Any of the above items not found or not configured properly indicate MACHINE isn't defined, or the
conf/machine/${MACHINE}.confdoesn't exist -- or is incorrectly configured.Quoted 5 lines
configuration file is initial? Is that "
./conf/bblayers.conf"? And if so, does this mean that I need to put my other directory assignments like TOPDIR and TMPDIR in bblayers.conf as well? And if so, then what's the logical distinction between bblayers.conf and local.conf at this point if build policy needs to go into bblayers.conf?bblayers shouldn't affect your machine files, other then a layer may contain a conf/machine/...conf file. The BBPATH setting of ${LAYERDIR} allows this directory to be automatically scanned when requesting a conf file.
--Mark
Quoted 7 lines
--rich
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 34 lines · Martin Jansa
Quoted 33 lines · Mark Hatle
Quoted 15 lines · Rich Pixley
Quoted 6 lines · Saul Wold
Quoted 5 lines · Rich Pixley
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
Quoted 8 lines
For bblayers.conf, we bumped the version becase we moved the BBPATH initial setting into the bblayers.conf to ensure we dont accidently pickup things in . because of the way a :: was being parsed. See this commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e3a61b40b7b697d83b41e7e247cd1f94eb7673cNot sure what you mean about local.conf, since I am not sure of your starting point.
Quoted 10 lines
Ok, so I *liked* having BBPATH be relative. The alternative, using absolute pathnames, means that you have to bolt absolute path names into all of your binaries, all of your debug symbols, and all of your build configurations. This means that your binary sizes are greater, that debug symbols are significantly greater and more difficult to configure properly in your debuger, and that working directories cannot be moved around or renamed without needing to manually force full rebuilds. It also means that some forms of file system checkpointing can't be used since you can't rely on the build to be in the same place on the file system every build.
BBPATH being relative doesn't affect what ends up in debug symbols, etc.
The BBPATH needs to be absolute, within the scope of a single loaded session to avoid randomly included items, primarily from the CWD. This prevents non-repeatable builds.
Quoted 6 lines
Quoted 3 lines
In a layer, the typical BBPATH is something like:
BBPATH := "${LAYERDIR}:${BBPATH}"
No, please append to it, so order of layers in BBPATH is the same as order of layers in BBLAYERS variable in bblayers.conf
This affects ordering.. in my expample.. I wanted my layer to take precedence over the BBPATH is other layers.
Quoted 2 lines
So typical BBPATH in layer.conf should be:
BBPATH .= ":${LAYERDIR}"
It has to be := and not .=. If it's not immediately resolved, then ${LAYERDIR} will go to undefined later.
If .= is working, I'm surprised.. the semantics may be different when processing BBPATH then other variables.
Quoted 2 lines
This is now consistent in all layers I'm using and quick search in layers I'm not using shows only meta-baryon having it vice versa.
--Mark
Quoted 74 lines
Cheers,
Quoted 60 lines
LAYERDIR is always the path to the layer being processed at any given time... so if a layer also provides addition scripts you can do:
# Add scripts to PATH
PATH := "${PATH}:${LAYERDIR}/scripts"As for the debug items, the system handles all of the debug symbols for you. All target symbols are referenced from the -root- of the target filesystem. If this is not happening in your builds, then you've disabled the debug symbol processing -- or you found a bug in the system... On the target side, debugging on the target that is, everything should 'just work' with no manual settings.
On a remote debug, you just need to tell the system where the relative path is to the root of the filesystem you are debugging, gdb should then be able to add the references to the associated sources and .debug split items.
This is all unchanged behavior for oe-core from when it was made oe-core to present.
Quoted 6 lines
I'll try to roll with the current plan, though.
In the current arrangement, I'm getting confusing messages about not setting MACHINE, even though MACHINE is set in my local.conf. I'm guessing that means that the pathing is busted and it's not finding my local.conf. How is the initial configuration file found? And which
If it says MACHINE isn't configured, then you are lacking a proper BSP/machine configuration file.
There are a couple of checks, but in the end they resolve down to checking that
TUNE_ARCH,TARGET_OS, andTUNE_PKGARCHexit and are reasonable, as well asconf/machine/${MACHINE}.confcan be loaded.Any of the above items not found or not configured properly indicate MACHINE isn't defined, or the
conf/machine/${MACHINE}.confdoesn't exist -- or is incorrectly configured.Quoted 5 lines
configuration file is initial? Is that "
./conf/bblayers.conf"? And if so, does this mean that I need to put my other directory assignments like TOPDIR and TMPDIR in bblayers.conf as well? And if so, then what's the logical distinction between bblayers.conf and local.conf at this point if build policy needs to go into bblayers.conf?bblayers shouldn't affect your machine files, other then a layer may contain a conf/machine/...conf file. The BBPATH setting of ${LAYERDIR} allows this directory to be automatically scanned when requesting a conf file.
--Mark
Quoted 7 lines
--rich
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreQuoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 37 lines · Mark Hatle
Quoted 36 lines · Martin Jansa
Quoted 35 lines · Mark Hatle
Quoted 15 lines · Rich Pixley
Quoted 6 lines · Saul Wold
Quoted 5 lines · Rich Pixley
Where can I find a description of the recent changes and what I need to do to bring my files back up to current?
What were the incompatible changes?
Quoted 8 lines
For bblayers.conf, we bumped the version becase we moved the BBPATH initial setting into the bblayers.conf to ensure we dont accidently pickup things in . because of the way a :: was being parsed. See this commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e3a61b40b7b697d83b41e7e247cd1f94eb7673cNot sure what you mean about local.conf, since I am not sure of your starting point.
Quoted 10 lines
Ok, so I *liked* having BBPATH be relative. The alternative, using absolute pathnames, means that you have to bolt absolute path names into all of your binaries, all of your debug symbols, and all of your build configurations. This means that your binary sizes are greater, that debug symbols are significantly greater and more difficult to configure properly in your debuger, and that working directories cannot be moved around or renamed without needing to manually force full rebuilds. It also means that some forms of file system checkpointing can't be used since you can't rely on the build to be in the same place on the file system every build.
BBPATH being relative doesn't affect what ends up in debug symbols, etc.
The BBPATH needs to be absolute, within the scope of a single loaded session to avoid randomly included items, primarily from the CWD. This prevents non-repeatable builds.
In a layer, the typical BBPATH is something like:
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
BBPATH := "${LAYERDIR}:${BBPATH}"
No, please append to it, so order of layers in BBPATH is the same as order of layers in BBLAYERS variable in bblayers.conf
This affects ordering.. in my expample.. I wanted my layer to take precedence over the BBPATH is other layers.
Then move your layer in BBLAYERS variable.
What if someone else would like your layer but doesn't want it to take precedence? If you use append then he can adjust it's priority by adding it in right place in BBLAYER, otherwise he needs to change layer.conf..
Quoted 8 lines
Quoted 2 lines
So typical BBPATH in layer.conf should be:
BBPATH .= ":${LAYERDIR}"It has to be := and not .=. If it's not immediately resolved, then ${LAYERDIR} will go to undefined later.
If .= is working, I'm surprised.. the semantics may be different when processing BBPATH then other variables.
Yes it is or do you suggest that all layers I'm using are not in my BBPATH? :)
Quoted 87 lines
Quoted 3 lines
This is now consistent in all layers I'm using and quick search in layers I'm not using shows only meta-baryon having it vice versa.
--Mark
Quoted 69 lines
Cheers,
Quoted 60 lines
LAYERDIR is always the path to the layer being processed at any given time... so if a layer also provides addition scripts you can do:
# Add scripts to PATH
PATH := "${PATH}:${LAYERDIR}/scripts"As for the debug items, the system handles all of the debug symbols for you. All target symbols are referenced from the -root- of the target filesystem. If this is not happening in your builds, then you've disabled the debug symbol processing -- or you found a bug in the system... On the target side, debugging on the target that is, everything should 'just work' with no manual settings.
On a remote debug, you just need to tell the system where the relative path is to the root of the filesystem you are debugging, gdb should then be able to add the references to the associated sources and .debug split items.
This is all unchanged behavior for oe-core from when it was made oe-core to present.
Quoted 6 lines
I'll try to roll with the current plan, though.
In the current arrangement, I'm getting confusing messages about not setting MACHINE, even though MACHINE is set in my local.conf. I'm guessing that means that the pathing is busted and it's not finding my local.conf. How is the initial configuration file found? And which
If it says MACHINE isn't configured, then you are lacking a proper BSP/machine configuration file.
There are a couple of checks, but in the end they resolve down to checking that
TUNE_ARCH,TARGET_OS, andTUNE_PKGARCHexit and are reasonable, as well asconf/machine/${MACHINE}.confcan be loaded.Any of the above items not found or not configured properly indicate MACHINE isn't defined, or the
conf/machine/${MACHINE}.confdoesn't exist -- or is incorrectly configured.Quoted 5 lines
configuration file is initial? Is that "
./conf/bblayers.conf"? And if so, does this mean that I need to put my other directory assignments like TOPDIR and TMPDIR in bblayers.conf as well? And if so, then what's the logical distinction between bblayers.conf and local.conf at this point if build policy needs to go into bblayers.conf?bblayers shouldn't affect your machine files, other then a layer may contain a conf/machine/...conf file. The BBPATH setting of ${LAYERDIR} allows this directory to be automatically scanned when requesting a conf file.
--Mark
Quoted 7 lines
--rich
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreQuoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreQuoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 2 lines · On Tuesday 03 July 2012 12:51:06 Mark Hatle wrote:
It has to be := and not .=. If it's not immediately resolved, then ${LAYERDIR} will go to undefined later.
I previously thought this too, but it turns out that because we call data.expandVarref('LAYERDIR') in the bitbake layer handling code, these references are expanded immediately after parsing each layer config file, so the := is not needed.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 5 lines · On Tuesday 03 July 2012 18:40:35 Jack Mitchell wrote:
What I did was create a new build directory and do a diff between my current config and the newly generated config.
I couldn't find the reference local.conf file that bitbake tells you to compare against...
It's in meta(-yocto)/conf/local.conf.sample.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 4 lines · Paul Eggleton
Quoted 3 lines · On Tuesday 03 July 2012 18:40:35 Jack Mitchell wrote:
What I did was create a new build directory and do a diff between my current config and the newly generated config.
Quoted 8 lines
Quoted 2 lines
I couldn't find the reference local.conf file that bitbake tells you to compare against...
It's in meta(-yocto)/conf/local.conf.sample.
Cheers,
Paul
Indeed it is, I think I was looking in the bitbake directory originally...
I seem to remember the help message being confusing/contradictory but I can't find it now.
Cheers,
Signature · 5 lines
Jack Mitchell ([email protected]) Embedded Systems Engineer http://www.embed.me.uk --
Quoted 14 lines · Jack Mitchell
Quoted 4 lines · Paul Eggleton
Quoted 3 lines · On Tuesday 03 July 2012 18:40:35 Jack Mitchell wrote:
What I did was create a new build directory and do a diff between my current config and the newly generated config.
Quoted 8 lines
Quoted 2 lines
I couldn't find the reference local.conf file that bitbake tells you to compare against...
It's in meta(-yocto)/conf/local.conf.sample.
Cheers,
Paul
Quoted 6 lines
Indeed it is, I think I was looking in the bitbake directory originally...
I seem to remember the help message being confusing/contradictory but I can't find it now.
Cheers,
Found it:
"Your version of bblayers.conf was generated from an older version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/bblayers.conf conf/bblayers.conf.sample\" is a good way to visualise the changes.\n"
What confused me was that there was no mention of where conf/bblayers.conf.sample file was, I assumed it was a bitbake controlled conf file rather than a distro controlled conf file, hence searching the bitbake directory.
Signature · 5 lines
Jack Mitchell ([email protected]) Embedded Systems Engineer http://www.embed.me.uk --