fido -> jethro switching problem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
for our internal development we use the Angstrom distro with some additional layers. Now we try to switch from fido to jethro branches and hit a problem where we are overchallenged.
Our local.conf contains
DISTRO_FEATURES_remove = "x11 wayland"
what results in
- ------------------> snip <---------------------
ERROR: Overrides could not be expanded into a stable state after 5 iterations, overrides must be being referenced by other overridden variables in some recursive fashion. Please provide your configuration to bitbake-devel so we can laugh, er, I mean try and understand how to make it work.
ERROR: Error parsing configuration files
Traceback (most recent call last):
File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/parse/ast.py", line 88, in DataNode.getFunc(key='DISTRO_FEATURES', data=<bb.data_smart.DataSmart object at 0x7fe7ea9df650>):
else:
> return data.getVar(key, False, noweakdefault=True, parsing=True)
File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 565, in DataSmart.getVar(var='DISTRO_FEATURES', expand=False, noweakdefault=True, parsing=True):
def getVar(self, var, expand=False, noweakdefault=False, parsing=False):
> return self.getVarFlag(var, "_content", expand, noweakdefault, parsing)
File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 737, in DataSmart.getVarFlag(var='DISTRO_FEATURES', flag='_content', expand=False, noweakdefault=True, parsing=True):
removes = []
> self.need_overrides()
for (r, o) in local_var["_remove"]: File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 435, in DataSmart.need_overrides():
else:
> bb.fatal("Overrides could not be expanded into a stable state after 5 iterations, overrides must be being referenced by other overridden variables in some recursive fashion. Please provide your configuration to bitbake-devel so we can laugh, er, I mean try and understand how to make it work.")
File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/__init__.py", line 102, in fatal:
logger.critical(''.join(args), extra=kwargs)
> raise BBHandledException()
BBHandledException
- ------------------> snap <---------------------
And also if we remove this line we end in a similar exception
- ------------------> snip <---------------------
ERROR: Overrides could not be expanded into a stable state after 5 iterations, overrides must be being referenced by other overridden variables in some recursive fashion. Please provide your configuration to bitbake-devel so we can laugh, er, I mean try and understand how to make it work.
ERROR: Unable to parse DEFAULTTUNE_angstrom[:=]
Traceback (most recent call last):
File "arm-defaults.inc", line 2, in arm_tune_handler(d=<bb.data_smart.DataSmart object at 0x7f9f383ea2d0>)
File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 565, in DataSmart.getVar(var='TUNE_FEATURES', expand=True, noweakdefault=False, parsing=False):
def getVar(self, var, expand=False, noweakdefault=False, parsing=False):
> return self.getVarFlag(var, "_content", expand, noweakdefault, parsing)
File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 667, in DataSmart.getVarFlag(var='TUNE_FEATURES', flag='_content', expand=True, noweakdefault=False, parsing=False):
active = {}
> self.need_overrides()
for (r, o) in self.overridedata[var]:
File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 435, in DataSmart.need_overrides():
else:
> bb.fatal("Overrides could not be expanded into a stable state after 5 iterations, overrides must be being referenced by other overridden variables in some recursive fashion. Please provide your configuration to bitbake-devel so we can laugh, er, I mean try and understand how to make it work.")
File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/__init__.py", line 102, in fatal:
logger.critical(''.join(args), extra=kwargs)
> raise BBHandledException()
ExpansionError: Failure expanding variable DEFAULTTUNE_angstrom[:=], expression was ${@arm_tune_handler(d)} which triggered exception BBHandledException:
- ------------------> snap <---------------------
Can someone give some hints what's going wrong here?
Additional info:
BitBake Build Tool Core version 1.28.0 angstrom-v2015.12-yocto2.0 67032251d761f0107322a85595062029b95d788d
Thx,
Steffen
- --
DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:[email protected]
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJWmOACAAoJEIz5slJ1krPhgBoP+gJvuy3bu3s+jC8OvXholWTF iU25kd0aCHixe6qQn5rhvElak+T7/CSnIfgePPC9rz2h3AS6SkRUiernQmKxqvSE zXJCacMkfeOlX3J2Kjw5NZGU7K1flZcWU1gAPEaFjkaKUZfYie9ftGXrwm+uMcwH QgRBIa/xwYokmFDna2opz3Uv+B5Z5k2/PGNGQYEBErSTOSFgFAWjkNVI01jeMtSc bBGzKU9jIpOaWDV2UnHgglWfUr8IEdUnuP61nM2C4uAXfTCAuKQAspo+FtDsaXTy 6nvgZgYV0/4RUl0x/8G+V0Hc8Iwe30c3tDShU8QF2OsNNXxbBtQgBgTciVTUEznr GN6OdosEy7+KHpFWML/vSgwoWieCVk0C6Tnre+da+HTxoYNkQtaNljsar0rYaMX0 YNBgqYbKBPG+dW3mIW5sRR4jzzrXp82t7naTuNP49k5wY0Adkn0hg4jqTz/pgES8 d4iNE9T5dZ7o2wxwD6zSl/QlWjVBLhbQfdOJvCSRd/vjce4kkihBFZTgN1twV9y1 4oTa1m+0A/5uJq2g4IGm/PfeI7QNp6keaOEE3dC3IX+nx0KwTF3Zd1UQFWDOzQIz +WVt6pCNnpHv/HZETkl+TelQePqu2Fb29jg8Ex82TO7CBQhzWwPsVzYiRcH9suwb qPm924F6B+DB3SHmefth
=cOzb
-----END PGP SIGNATURE-----
Quoted 11 lines · Steffen Sledz
Hi all,
for our internal development we use the Angstrom distro with some additional layers. Now we try to switch from fido to jethro branches and hit a problem where we are overchallenged.
Our local.conf contains
DISTRO_FEATURES_remove= "x11 wayland"what results in
The error you pasted means that your setup has some kind of circular override references in it.
Am I correct in understanding that you hit the same error regardless of the above line or not? If so, that means the problem is probably elsewhere in your configuration.
As an example of what would cause this kind of issue:
OVERRIDES = "${VAR1}:${VAR2}"
VAR1 = "VAL1"VAR2 = "VAL2"VAR2_VAL2 = "VAL1"
So bitbake would try and expand OVERRIDES and get "VAL1:VAL2", that would change the value of VAR2 to VAL1, making overrides "VAL1:VAL1", hence VAR2 now becomes VAL2, so OVERRIDES changes and so on.
Rather than infinitely loop, the code exits. There isn't code in there which tries to figure out the circular dependency path since that is rather complicated and there can be multiple levels of indirection rather than just the single level above.
You probably need to track down which OVERRIDES value is causing the problem, then work through the usages of it to find the problem, or instrument the code to see which values are changing and causing the instability.
Cheers,
Richard
Quoted 11 lines · Richard Purdie
Quoted 10 lines · Steffen Sledz
Hi all,
for our internal development we use the Angstrom distro with some additional layers. Now we try to switch from fido to jethro branches and hit a problem where we are overchallenged.
Our local.conf contains
DISTRO_FEATURES_remove= "x11 wayland"
Quoted 7 lines
Quoted 1 line
what results in
The error you pasted means that your setup has some kind of circular override references in it.
Am I correct in understanding that you hit the same error regardless of the above line or not?
Some kind of.
If you look at my original post, with this line the exception is somewhat related to DISTRO_FEATURES. Without the line it is related to TUNE_FEATURES.
And I made another interesting discovery: The exception appears on certain machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 not.
And last but not least with fido we did not had any problems.
Regards,
Steffen
Signature · 7 lines
DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 1 line · Steffen Sledz
And I made another interesting discovery: The exception appears on certain machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 not.
It seems that all machines based on armv5e are affected.
Signature · 7 lines
DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 8 lines
Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <[email protected]> het volgende geschreven:
Quoted 2 lines · Steffen Sledz
And I made another interesting discovery: The exception appears on certain machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 not.
It seems that all machines based on armv5e are affected.
FWIW, I'm seeing the same problem. The last time it happened it was due to the fixup angstrom does for broken arm BSPs
Quoted 9 lines
Signature · 8 lines
-- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 4 lines · Koen Kooi
Quoted 2 lines
Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <[email protected]> het volgende geschreven:
It seems that all machines based on armv5e are affected.FWIW, I'm seeing the same problem. The last time it happened it was due to the fixup angstrom does for broken arm BSPs
What commits do you talking about ("last time it happened")?
https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d ?
https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8 ?
Or something else?
Signature · 7 lines
DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 7 lines
Op 18 jan. 2016, om 09:28 heeft Steffen Sledz <[email protected]> het volgende geschreven:
Quoted 3 lines · Koen Kooi
Quoted 2 lines
Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <[email protected]> het volgende geschreven:
It seems that all machines based on armv5e are affected.
Quoted 8 lines
Quoted 1 line
FWIW, I'm seeing the same problem. The last time it happened it was due to the fixup angstrom does for broken arm BSPs
What commits do you talking about ("last time it happened")?
https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d ?
https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8 ?Or something else?
Yes, those ones.
regards,
Koen
Quoted 9 lines
Signature · 8 lines
-- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 7 lines · Koen Kooi
Quoted 7 lines
Op 18 jan. 2016, om 09:28 heeft Steffen Sledz <[email protected]> het volgende geschreven:
Quoted 4 lines · Koen Kooi
Quoted 2 lines
Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <[email protected]> het volgende geschreven:
It seems that all machines based on armv5e are affected.FWIW, I'm seeing the same problem. The last time it happened it was due to the fixup angstrom does for broken arm BSPs
Quoted 8 lines
Quoted 6 lines
What commits do you talking about ("last time it happened")?
https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d ?
https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8 ?Or something else?
Yes, those ones.
If I understand right you only introduced an own DEFAULTUNE override for angstrom to work around the problem. Right?
Did you identify the parts of meta-fsl-arm which were responsible for these problems?
Steffen
PS: Hi Otavio, I've added you to this discussion as the official meta-fsl-arm maintainer.
Signature · 7 lines
DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 14 lines
Op 18 jan. 2016 om 11:10 heeft Steffen Sledz <[email protected]> het volgende geschreven:
Quoted 9 lines · Koen Kooi
Quoted 9 lines
Op 18 jan. 2016, om 09:28 heeft Steffen Sledz <[email protected]> het volgende geschreven:
Quoted 4 lines · Koen Kooi
Quoted 2 lines
Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <[email protected]> het volgende geschreven:
It seems that all machines based on armv5e are affected.FWIW, I'm seeing the same problem. The last time it happened it was due to the fixup angstrom does for broken arm BSPs
What commits do you talking about ("last time it happened")?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d ?
https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8 ?Or something else?
Yes, those ones.
If I understand right you only introduced an own DEFAULTUNE override for angstrom to work around the problem. Right?
right
Quoted 2 lines
Did you identify the parts of meta-fsl-arm which were responsible for these problems?
The machine includes that tune to cortex-foo instead of armvX. I don't need 5 different versions of bash for 5 'different' armv7 machines.
Quoted 13 lines
Steffen
PS: Hi Otavio, I've added you to this discussion as the official meta-fsl-arm maintainer.
Signature · 7 lines
DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 7 lines · Koen Kooi
Quoted 5 lines
Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <[email protected]> het volgende geschreven:
Quoted 2 lines · Steffen Sledz
And I made another interesting discovery: The exception appears on certain machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 not.
It seems that all machines based on armv5e are affected.
FWIW, I'm seeing the same problem. The last time it happened it was due to the fixup angstrom does for broken arm BSPs
I've identified this line from meta-angstrom/conf/distro/include/angstrom.inc[1] as "trigger" for the exception in the way, that commenting out this line avoids the exception.
--------------> snip <----------------
# Add FEED_ARCH to machine overrides so we get access to e.g. 'armv7a' and 'sh4' # Hopefully we'll never see a machine or arch with 'all' as substring MACHINEOVERRIDES .= ":${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}" --------------> snip <----------------
Signature · 7 lines
DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 12 lines
Op 18 jan. 2016, om 12:55 heeft Steffen Sledz <[email protected]> het volgende geschreven:
Quoted 7 lines · Koen Kooi
Quoted 5 lines
Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <[email protected]> het volgende geschreven:
Quoted 2 lines · Steffen Sledz
And I made another interesting discovery: The exception appears on certain machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 not.
It seems that all machines based on armv5e are affected.
FWIW, I'm seeing the same problem. The last time it happened it was due to the fixup angstrom does for broken arm BSPs
Quoted 7 lines
I've identified this line from meta-angstrom/conf/distro/include/angstrom.inc[1] as "trigger" for the exception in the way, that commenting out this line avoids the exception.
--------------> snip <----------------
# AddFEED_ARCHto machine overrides so we get access to e.g. 'armv7a' and 'sh4' # Hopefully we'll never see a machine or arch with 'all' as substring MACHINEOVERRIDES .= ":${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}" --------------> snip <————————
So that bit doesn’t do what it says it does anymore, this diff after removing it:
-# $MACHINEOVERRIDES [10 operations]
+# $MACHINEOVERRIDES [9 operations]
# set? /build/v2015.12/sources/openembedded-core/meta/conf/bitbake.conf:688
# "${MACHINE}"
# set /build/v2015.12/sources/openembedded-core/meta/conf/bitbake.conf:689
@@ -9106,15 +9106,13 @@
# "${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" ,d)}"
# predot /build/v2015.12/sources/openembedded-core/meta/conf/machine/include/arm/arch-armv4.inc:13
# "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" ,d)}"
-# postdot /build/v2015.12/sources/meta-angstrom/conf/distro/include/angstrom.inc:30
-# ":${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}"
# append /build/v2015.12/sources/meta-angstrom/conf/distro/include/angstrom-core-tweaks.inc:27
# [vardepsexclude] "SOC_FAMILY"
# set /build/v2015.12/sources/openembedded-core/meta/conf/documentation.conf:282
# [doc] "Lists overrides specific to the current machine. By default, this list includes the value of MACHINE."
# pre-expansion value:
-# "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv6", "armv6:", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv7a", "armv7a:", "" ,d)}${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}${MACHINE}:${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}"
-MACHINEOVERRIDES="armv7a:ti33x:beaglebone:armv7at2hf-vfp-neon"
+# "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv6", "armv6:", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv7a", "armv7a:", "" ,d)}${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}${MACHINE}"
+MACHINEOVERRIDES=“armv7a:ti33x:beaglebone"So ‘armv7a’ is already there, 'armv7at2hf-vfp-neon’ isn’t needed since that information is availble from MACHINE_FEATURES already. I’ll drop the bit in jethro and master.
Thanks for tracking this down!
regards,
Koen
Quoted 6 lines · Steffen Sledz
Quoted 3 lines · Steffen Sledz
And I made another interesting discovery: The exception appears on certain machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 not.
It seems that all machines based on armv5e are affected.
Which is a good data point to have and should help narrow it down.
I know that jethro OE-Core doesn't do this. Its unlikely to be machine specific if all armv5e including qemuarm are affected. It therefore sounds like there is something in your distro config related to armv5 is likely the cause...
Cheers,
Richard