fido -> jethro switching problem

fido -> jethro switching problem

[Steffen Sledz]

-----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:sledz@dresearch-fe.de
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-----

Re: fido -> jethro switching problem

[Richard Purdie]

On Fri, 2016-01-15 at 13:03 +0100, Steffen Sledz wrote:
> 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

Re: fido -> jethro switching problem

[Steffen Sledz]

On 15.01.2016 14:06, Richard Purdie wrote:
> On Fri, 2016-01-15 at 13:03 +0100, Steffen Sledz wrote:
>> 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?

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

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: fido -> jethro switching problem

[Steffen Sledz]

On 15.01.2016 14:24, Steffen Sledz wrote:
> 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.

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: fido -> jethro switching problem

[Koen Kooi]

> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sledz@dresearch-fe.de> het volgende geschreven:
> 
>> On 15.01.2016 14:24, Steffen Sledz wrote:
>> 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


> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058

Re: fido -> jethro switching problem

[Richard Purdie]

On Fri, 2016-01-15 at 15:26 +0100, Steffen Sledz wrote:
> On 15.01.2016 14:24, Steffen Sledz wrote:
> > 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

Re: fido -> jethro switching problem

[Steffen Sledz]

On 15.01.2016 15:29, Koen Kooi wrote:
>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sledz@dresearch-fe.de> 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?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: fido -> jethro switching problem

[Koen Kooi]

> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz <sledz@dresearch-fe.de> het volgende geschreven:
> 
> On 15.01.2016 15:29, Koen Kooi wrote:
>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sledz@dresearch-fe.de> 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?

Yes, those ones. 

regards,

Koen

> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058

Re: fido -> jethro switching problem

[Steffen Sledz]

On 18.01.2016 09:41, Koen Kooi wrote:
>> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz <sledz@dresearch-fe.de> het volgende geschreven:
>> On 15.01.2016 15:29, Koen Kooi wrote:
>>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sledz@dresearch-fe.de> 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?
> 
> 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.

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: fido -> jethro switching problem

[Koen Kooi]

> Op 18 jan. 2016 om 11:10 heeft Steffen Sledz <sledz@dresearch-fe.de> het volgende geschreven:
> 
> On 18.01.2016 09:41, Koen Kooi wrote:
>>> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz <sledz@dresearch-fe.de> het volgende geschreven:
>>> On 15.01.2016 15:29, Koen Kooi wrote:
>>>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sledz@dresearch-fe.de> 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?
>> 
>> Yes, those ones.
> 
> If I understand right you only introduced an own DEFAULTUNE override for angstrom to work around the problem. Right?

right

> 
> 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.

> 
> Steffen
> 
> PS: Hi Otavio, I've added you to this discussion as the official meta-fsl-arm maintainer.
> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058

Re: fido -> jethro switching problem

[Steffen Sledz]

On 15.01.2016 15:29, Koen Kooi wrote:
>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sledz@dresearch-fe.de> het volgende geschreven:
>>> On 15.01.2016 14:24, Steffen Sledz wrote:
>>> 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 <----------------

[1] <https://github.com/Angstrom-distribution/meta-angstrom/blob/angstrom-v2015.12-yocto2.0/conf/distro/include/angstrom.inc>

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: fido -> jethro switching problem

[Koen Kooi]

> Op 18 jan. 2016, om 12:55 heeft Steffen Sledz <sledz@dresearch-fe.de> het volgende geschreven:
> 
> On 15.01.2016 15:29, Koen Kooi wrote:
>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sledz@dresearch-fe.de> het volgende geschreven:
>>>> On 15.01.2016 14:24, Steffen Sledz wrote:
>>>> 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 <————————

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