Undefining a variable in a recipe?

Undefining a variable in a recipe?

[Alex J Lennon]

Hi,

I have an issue with the build of an old u-boot (2009.08) which is
failing a check in poky as both UBOOT_CONFIG and UBOOT_MACHINE are being
defined for some reason.

poky/meta/classes/uboot-config.bbclass

 ubootmachine = d.getVar("UBOOT_MACHINE", True)
 ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')

..

 if ubootmachine and ubootconfigflags:
       raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
UBOOT_CONFIG at the same time.")


I have a .bbappend on the original u-boot recipe and could solve the
problem by undefining UBOOT_MACHINE if I could work out how to do this
in the .bbappend

I've tried setting it to None or an empty string, and I tried an
anonymous python function but those approaches didn't help,

e.g. (in the .bbappend

UBOOT_MACHINE = ""

or

UBOOT_MACHINE = None

or

python __anonymous () {
  bb.data.delVar('UBOOT_MACHINE_imx6qsabresd')
}

I could just copy the original recipe from metal-fsl-arm into my own
layer and change it there I guess but I'd like to understand how to
achieve this with a .bbappend if it is possible as it seems cleaner.

Many thanks,

Alex

Re: Undefining a variable in a recipe?

[Paul Eggleton]

Hi Alex,

On Thursday 01 May 2014 10:42:51 Alex J Lennon wrote:
> I have an issue with the build of an old u-boot (2009.08) which is
> failing a check in poky as both UBOOT_CONFIG and UBOOT_MACHINE are being
> defined for some reason.
> 
> poky/meta/classes/uboot-config.bbclass
> 
>  ubootmachine = d.getVar("UBOOT_MACHINE", True)
>  ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
> 
> ..
> 
>  if ubootmachine and ubootconfigflags:
>        raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
> UBOOT_CONFIG at the same time.")
> 
> 
> I have a .bbappend on the original u-boot recipe and could solve the
> problem by undefining UBOOT_MACHINE if I could work out how to do this
> in the .bbappend
> 
> I've tried setting it to None or an empty string, and I tried an
> anonymous python function but those approaches didn't help,
> 
> e.g. (in the .bbappend
> 
> UBOOT_MACHINE = ""

This should work - the python code above is checking if the value evaluates to 
True, and that shouldn't be the case for an empty string. I suspect something 
else is at work here - either the check is running before your value gets set, 
or the value is being set using an override somewhere and therefore your value 
isn't being used.

(adding Otavio on CC since these are his checks and his layer)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Undefining a variable in a recipe?

[Alex J Lennon]

On 01/05/2014 14:54, Paul Eggleton wrote:
> Hi Alex,
>
> On Thursday 01 May 2014 10:42:51 Alex J Lennon wrote:
>> I have an issue with the build of an old u-boot (2009.08) which is
>> failing a check in poky as both UBOOT_CONFIG and UBOOT_MACHINE are being
>> defined for some reason.
>>
>> poky/meta/classes/uboot-config.bbclass
>>
>>  ubootmachine = d.getVar("UBOOT_MACHINE", True)
>>  ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
>>
>> ..
>>
>>  if ubootmachine and ubootconfigflags:
>>        raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
>> UBOOT_CONFIG at the same time.")
>>
>>
>> I have a .bbappend on the original u-boot recipe and could solve the
>> problem by undefining UBOOT_MACHINE if I could work out how to do this
>> in the .bbappend
>>
>> I've tried setting it to None or an empty string, and I tried an
>> anonymous python function but those approaches didn't help,
>>
>> e.g. (in the .bbappend
>>
>> UBOOT_MACHINE = ""
> This should work - the python code above is checking if the value evaluates to 
> True, and that shouldn't be the case for an empty string. I suspect something 
> else is at work here - either the check is running before your value gets set, 
> or the value is being set using an override somewhere and therefore your value 
> isn't being used.
>
> (adding Otavio on CC since these are his checks and his layer)

Thanks for coming back to me on this Paul. OK, I must be
misunderstanding something.

I was outputting the UBOOT_MACHINE to test and it's not a True value at
any point as you
might expect as it's set to the machine type if set, but my build was
still failing to pick up
my preferred recipe version unless I commented out the if/raise, in
which case all worked
as expected.

Caught up with something at the minute but I will go through this  again
first thing tomorrow.

Thanks again,

Alex

> Cheers,
> Paul
>

Re: Undefining a variable in a recipe?

[Otavio Salvador]

On Thu, May 1, 2014 at 2:34 PM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
>
> On 01/05/2014 14:54, Paul Eggleton wrote:
>> Hi Alex,
>>
>> On Thursday 01 May 2014 10:42:51 Alex J Lennon wrote:
>>> I have an issue with the build of an old u-boot (2009.08) which is
>>> failing a check in poky as both UBOOT_CONFIG and UBOOT_MACHINE are being
>>> defined for some reason.
>>>
>>> poky/meta/classes/uboot-config.bbclass
>>>
>>>  ubootmachine = d.getVar("UBOOT_MACHINE", True)
>>>  ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
>>>
>>> ..
>>>
>>>  if ubootmachine and ubootconfigflags:
>>>        raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
>>> UBOOT_CONFIG at the same time.")
>>>
>>>
>>> I have a .bbappend on the original u-boot recipe and could solve the
>>> problem by undefining UBOOT_MACHINE if I could work out how to do this
>>> in the .bbappend
>>>
>>> I've tried setting it to None or an empty string, and I tried an
>>> anonymous python function but those approaches didn't help,
>>>
>>> e.g. (in the .bbappend
>>>
>>> UBOOT_MACHINE = ""
>> This should work - the python code above is checking if the value evaluates to
>> True, and that shouldn't be the case for an empty string. I suspect something
>> else is at work here - either the check is running before your value gets set,
>> or the value is being set using an override somewhere and therefore your value
>> isn't being used.
>>
>> (adding Otavio on CC since these are his checks and his layer)
>
> Thanks for coming back to me on this Paul. OK, I must be
> misunderstanding something.
>
> I was outputting the UBOOT_MACHINE to test and it's not a True value at
> any point as you
> might expect as it's set to the machine type if set, but my build was
> still failing to pick up
> my preferred recipe version unless I commented out the if/raise, in
> which case all worked
> as expected.
>
> Caught up with something at the minute but I will go through this  again
> first thing tomorrow.

When you debug it let me know and I can try to help in solve it.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Undefining a variable in a recipe?

[Alex J Lennon]

On 01/05/2014 18:54, Otavio Salvador wrote:
> On Thu, May 1, 2014 at 2:34 PM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 01/05/2014 14:54, Paul Eggleton wrote:
>>> Hi Alex,
>>>
>>> On Thursday 01 May 2014 10:42:51 Alex J Lennon wrote:
>>>> I have an issue with the build of an old u-boot (2009.08) which is
>>>> failing a check in poky as both UBOOT_CONFIG and UBOOT_MACHINE are being
>>>> defined for some reason.
>>>>
>>>> poky/meta/classes/uboot-config.bbclass
>>>>
>>>>  ubootmachine = d.getVar("UBOOT_MACHINE", True)
>>>>  ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
>>>>
>>>> ..
>>>>
>>>>  if ubootmachine and ubootconfigflags:
>>>>        raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
>>>> UBOOT_CONFIG at the same time.")
>>>>
>>>>
>>>> I have a .bbappend on the original u-boot recipe and could solve the
>>>> problem by undefining UBOOT_MACHINE if I could work out how to do this
>>>> in the .bbappend
>>>>
>>>> I've tried setting it to None or an empty string, and I tried an
>>>> anonymous python function but those approaches didn't help,
>>>>
>>>> e.g. (in the .bbappend
>>>>
>>>> UBOOT_MACHINE = ""
>>> This should work - the python code above is checking if the value evaluates to
>>> True, and that shouldn't be the case for an empty string. I suspect something
>>> else is at work here - either the check is running before your value gets set,
>>> or the value is being set using an override somewhere and therefore your value
>>> isn't being used.
>>>
>>> (adding Otavio on CC since these are his checks and his layer)
>> Thanks for coming back to me on this Paul. OK, I must be
>> misunderstanding something.
>>
>> I was outputting the UBOOT_MACHINE to test and it's not a True value at
>> any point as you
>> might expect as it's set to the machine type if set, but my build was
>> still failing to pick up
>> my preferred recipe version unless I commented out the if/raise, in
>> which case all worked
>> as expected.
>>
>> Caught up with something at the minute but I will go through this  again
>> first thing tomorrow.
> When you debug it let me know and I can try to help in solve it.
>

Much appreciated thanks Otavio. Will do.

Re: Undefining a variable in a recipe?

[Alex J Lennon]

On 01/05/2014 18:54, Otavio Salvador wrote:
> On Thu, May 1, 2014 at 2:34 PM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 01/05/2014 14:54, Paul Eggleton wrote:
>>> Hi Alex,
>>>
>>> On Thursday 01 May 2014 10:42:51 Alex J Lennon wrote:
>>>> I have an issue with the build of an old u-boot (2009.08) which is
>>>> failing a check in poky as both UBOOT_CONFIG and UBOOT_MACHINE are being
>>>> defined for some reason.
>>>>
>>>> poky/meta/classes/uboot-config.bbclass
>>>>
>>>>  ubootmachine = d.getVar("UBOOT_MACHINE", True)
>>>>  ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
>>>>
>>>> ..
>>>>
>>>>  if ubootmachine and ubootconfigflags:
>>>>        raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
>>>> UBOOT_CONFIG at the same time.")
>>>>
>>>>
>>>> I have a .bbappend on the original u-boot recipe and could solve the
>>>> problem by undefining UBOOT_MACHINE if I could work out how to do this
>>>> in the .bbappend
>>>>
>>>> I've tried setting it to None or an empty string, and I tried an
>>>> anonymous python function but those approaches didn't help,
>>>>
>>>> e.g. (in the .bbappend
>>>>
>>>> UBOOT_MACHINE = ""
>>> This should work - the python code above is checking if the value evaluates to
>>> True, and that shouldn't be the case for an empty string. I suspect something
>>> else is at work here - either the check is running before your value gets set,
>>> or the value is being set using an override somewhere and therefore your value
>>> isn't being used.
>>>
>>> (adding Otavio on CC since these are his checks and his layer)
>> Thanks for coming back to me on this Paul. OK, I must be
>> misunderstanding something.
>>
>> I was outputting the UBOOT_MACHINE to test and it's not a True value at
>> any point as you
>> might expect as it's set to the machine type if set, but my build was
>> still failing to pick up
>> my preferred recipe version unless I commented out the if/raise, in
>> which case all worked
>> as expected.
>>
>> Caught up with something at the minute but I will go through this  again
>> first thing tomorrow.
> When you debug it let me know and I can try to help in solve it.
>

Hi Otavio, Paul,

(Thanks for your advice on this; apologies if I'm posting to the wrong
list but I thought it would be worth maintaining the thread in-situ)

Revisiting the issue, a little background might first be useful to
explain what I'm trying to achieve and why I'm doing what I'm doing.

I am currently working with a board variant based on the Freescale
imx6qsabresd.

I have a board port which a colleague did for an Android project, and
they based on u-boot-imx 2009.08 and linux-imx kernel 3.0.35

My roadmap is to forward port the changes into the newer kernel 3.10.17
for which I understand we'll also need the newer
u-boot 2013.04 for devicetree support. This is because I aim to be in
sync with FSL when Yocto daisy is supported in Q3 or
thereabouts. However I have not completed that work yet, and I need
working images now based on the older u-boot/kernel
to enable us to prove out the hardware and go to higher volume board
manufacture in the short term.

So I'm currently using Yocto poky daisy (5306aaab) and the last
meta-fsl-arm commit before you (Otavio) removed the u-boot 2009.08
recipe (fc8bcfae0)

I have my own layer in which I have various .bbappends to, e.g. modify
SRC_URI / REV / BRANCH to use the custom u-boot, kernel, bring in apps
and so forth.

Build configuration here: http://pastebin.com/M6wL1yhB

Local.conf here: http://pastebin.com/hg4LbLJ5

...

As you can see we're building for MACHINE = imx6qsabresd. Also I have
preferred providers/versions set in local.conf for u-boot-imx 2009.08,
linux-imx 3.0.35

When I run a bitbake of my image I see

NOTE: Resolving any missing task queue dependencies
NOTE: preferred version 2009.08 of u-boot-imx not available (for item
u-boot)
NOTE: versions of u-boot-imx available: 2013.04
NOTE: preferred version 2009.08 of u-boot-imx not available (for item
u-boot-imx)
NOTE: versions of u-boot-imx available: 2013.04
NOTE: preferred version 2009.08 of u-boot-imx not available (for item
u-boot-imx-dev)
NOTE: versions of u-boot-imx available: 2013.04

This is because of the lines in /poky/meta/classes/uboot-config.bbclass

 if ubootmachine and ubootconfigflags:
       raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
UBOOT_CONFIG at the same time.")

WIth these two lines commented out I no longer see the "not available"
notes and can succesfully build u-boot-imx 2009.08

...

If I add in some logging, e.g.

    bb.warn("ubootmachine: %s" %ubootmachine )
    bb.warn("ubootmachine: %s" %ubootconfigflags )

#    if ubootmachine and ubootconfigflags:
#       raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
UBOOT_CONFIG at the same time.")

I see the following,

WARNING: ubootmachine:
mx6q_sabresd_config                                                                                                                                                 
| ETA:  --:--:--
WARNING: ubootmachine: {'sata': 'mx6qsabresd_sata_config', 'mfgtool':
'mx6qsabresd_config', 'defaultval': 'sd', 'sd':
'mx6q_sabresd_android_config,sdcard'}
WARNING: ubootmachine: None
WARNING: ubootmachine: {'sata': 'mx6qsabresd_sata_config', 'sd':
'mx6qsabresd_config,sdcard', 'mfgtool': 'mx6qsabresd_config',
'defaultval': 'sd'}
WARNING: ubootmachine: None
WARNING: ubootmachine: {'sata': 'mx6qsabresd_sata_config', 'sd':
'mx6qsabresd_config,sdcard', 'mfgtool': 'mx6qsabresd_config',
'defaultval': 'sd'}
WARNING: ubootmachine: None
WARNING: ubootmachine: {'sd': 'mx6qsabresd_config,sdcard', 'mfgtool':
'mx6qsabresd_config', 'defaultval': 'sd', 'sata': 'mx6qsabresd_sata_config'}
WARNING: ubootmachine: mx6q_sabresd_config
WARNING: ubootmachine: {'sata': 'mx6qsabresd_sata_config', 'mfgtool':
'mx6qsabresd_config', 'defaultval': 'sd', 'sd':
'mx6q_sabresd_android_config,sdcard'}
WARNING: ubootmachine: None
WARNING: ubootmachine: {'sata': 'mx6qsabresd_sata_config', 'sd':
'mx6qsabresd_config,sdcard', 'mfgtool': 'mx6qsabresd_config',
'defaultval': 'sd'}
WARNING: ubootmachine: None
WARNING: ubootmachine: {'sata': 'mx6qsabresd_sata_config', 'sd':
'mx6qsabresd_config,sdcard', 'mfgtool': 'mx6qsabresd_config',
'defaultval': 'sd'}
WARNING: ubootmachine: None
WARNING: ubootmachine: {'sata': 'mx6qsabresd_sata_config', 'sd':
'mx6qsabresd_config,sdcard', 'mfgtool': 'mx6qsabresd_config',
'defaultval': 'sd'}

I'm not sure why the class is being called multiple times in this way.

...

"This should work - the python code above is checking if the value evaluates to
True, and that shouldn't be the case for an empty string." 

Paul - as you can see, sometimes ubootmachine is being set by
d.getVar("UBOOT_MACHINE", True) but it isn't being set based on a test
for true from what I understand (?)

I can't see any documentation on what the flag parameter actually does,
although I see examples in which it's set to '1' but doesn't seem to do much

I did a quick test as follows,

python __anonymous () {
  bb.data.setVar('TEST', 'testvalue', d)
  print "getVar: %s\n" %bb.data.getVar('TEST', d)
  print "getVar with flag: %s\n" %bb.data.getVar('TEST', d, True)
}

That gives me

getVar: testvalue 
getVar with flag: testvalue

So I don't believe that getVar() is actually doing a test for True (?)

...

Grepping through the sources, UBOOT_MACHINE is set in
meta-fsm-arm/recipes-bsp-u-boot-imx_2009_08.bb

UBOOT_MACHINE_imx6qsabresd = "mx6q_sabresd_config"

I can comment out that line and build u-boot-imx 2009.08 successfully

Similarly, UBOOT_CONFIG is set in conf/machine/imx6qsabresd.conf

UBOOT_CONFIG ??= "sd"
UBOOT_CONFIG[sd] = "mx6qsabresd_config,sdcard"
UBOOT_CONFIG[sata] = "mx6qsabresd_sata_config"
UBOOT_CONFIG[mfgtool] = "mx6qsabresd_config"

If I comment out these lines instead of UBOOT_MACHINE_foo I can also
build u-boot-imx 2009.08 successfully

...

So I guess I'm at the point where I'm wondering if a getVar() with a
flag is behaving as you would expect it to,
or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
isn't defined?

Thanks in advance for any advice,

Alex

Re: Undefining a variable in a recipe?

[Otavio Salvador]

On Fri, May 2, 2014 at 2:24 AM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
...
> So I guess I'm at the point where I'm wondering if a getVar() with a
> flag is behaving as you would expect it to,
> or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
> isn't defined?
>
> Thanks in advance for any advice,

I think we have a simple error error. You are mixing a recipe, which
is old and a metadata layer with new concepts.

The u-boot-imx, in 2009.08 recipe, used to set the UBOOT_MACHINE in
the recipe as it was left as a fallback in case user needed it and the
value was different from newer releases.

In your case, the easier is to make a new yourmachine.conf and use the
UBOOT_CONFIG or UBOOT_MACHINE setting there so it will work just fine.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Undefining a variable in a recipe?

[Alex J Lennon]

On 02/05/2014 13:56, Otavio Salvador wrote:
> On Fri, May 2, 2014 at 2:24 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
> ...
>> So I guess I'm at the point where I'm wondering if a getVar() with a
>> flag is behaving as you would expect it to,
>> or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
>> isn't defined?
>>
>> Thanks in advance for any advice,
> I think we have a simple error error. You are mixing a recipe, which
> is old and a metadata layer with new concepts.
>
> The u-boot-imx, in 2009.08 recipe, used to set the UBOOT_MACHINE in
> the recipe as it was left as a fallback in case user needed it and the
> value was different from newer releases.
>
> In your case, the easier is to make a new yourmachine.conf and use the
> UBOOT_CONFIG or UBOOT_MACHINE setting there so it will work just fine.
>

If I have to do that, then I have to do that.

However if I could just undefine one of the two variables defined in the
meta-fsl-arm
layer then I could continue with what I am doing without having to spend
the time
right now to rework the configuration, which is wasted effort for me, as
I will be moving
up to the new version of u-boot in the near future.

Is there no simple way to undefine a variable in a recipe?

Thanks,

Alex

Re: Undefining a variable in a recipe?

[Otavio Salvador]

On Fri, May 2, 2014 at 10:01 AM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
>
> On 02/05/2014 13:56, Otavio Salvador wrote:
>> On Fri, May 2, 2014 at 2:24 AM, Alex J Lennon
>> <ajlennon@dynamicdevices.co.uk> wrote:
>> ...
>>> So I guess I'm at the point where I'm wondering if a getVar() with a
>>> flag is behaving as you would expect it to,
>>> or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
>>> isn't defined?
>>>
>>> Thanks in advance for any advice,
>> I think we have a simple error error. You are mixing a recipe, which
>> is old and a metadata layer with new concepts.
>>
>> The u-boot-imx, in 2009.08 recipe, used to set the UBOOT_MACHINE in
>> the recipe as it was left as a fallback in case user needed it and the
>> value was different from newer releases.
>>
>> In your case, the easier is to make a new yourmachine.conf and use the
>> UBOOT_CONFIG or UBOOT_MACHINE setting there so it will work just fine.
>>
>
> If I have to do that, then I have to do that.
>
> However if I could just undefine one of the two variables defined in the
> meta-fsl-arm
> layer then I could continue with what I am doing without having to spend
> the time
> right now to rework the configuration, which is wasted effort for me, as
> I will be moving
> up to the new version of u-boot in the near future.
>
> Is there no simple way to undefine a variable in a recipe?

You can change the recipe byhand. This is ugly and I wouldn't do it. I
do think you are wasting more time trying to 'workaround' it than
fixing it.

Comment the UBOOT_MACHINE setting in the u-boot-imx recipe and move
on. The log is clear you're not setting the PREFERRED_VERSION
accordingly and you should.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Undefining a variable in a recipe?

[Alex J Lennon]

On 02/05/2014 14:07, Otavio Salvador wrote:
> On Fri, May 2, 2014 at 10:01 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 02/05/2014 13:56, Otavio Salvador wrote:
>>> On Fri, May 2, 2014 at 2:24 AM, Alex J Lennon
>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>> ...
>>>> So I guess I'm at the point where I'm wondering if a getVar() with a
>>>> flag is behaving as you would expect it to,
>>>> or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
>>>> isn't defined?
>>>>
>>>> Thanks in advance for any advice,
>>> I think we have a simple error error. You are mixing a recipe, which
>>> is old and a metadata layer with new concepts.
>>>
>>> The u-boot-imx, in 2009.08 recipe, used to set the UBOOT_MACHINE in
>>> the recipe as it was left as a fallback in case user needed it and the
>>> value was different from newer releases.
>>>
>>> In your case, the easier is to make a new yourmachine.conf and use the
>>> UBOOT_CONFIG or UBOOT_MACHINE setting there so it will work just fine.
>>>
>> If I have to do that, then I have to do that.
>>
>> However if I could just undefine one of the two variables defined in the
>> meta-fsl-arm
>> layer then I could continue with what I am doing without having to spend
>> the time
>> right now to rework the configuration, which is wasted effort for me, as
>> I will be moving
>> up to the new version of u-boot in the near future.
>>
>> Is there no simple way to undefine a variable in a recipe?
> You can change the recipe byhand. This is ugly and I wouldn't do it. I
> do think you are wasting more time trying to 'workaround' it than
> fixing it.

Or indeed, would be not be reasonable to modify the uboot-config.bbclass
such that
it tested for and discarded empty strings in UBOOT_MACHINE / UBOOT_CONFIG
which would seem to be a more complete test and would eliminate the
problem ?

> Comment the UBOOT_MACHINE setting in the u-boot-imx recipe and move
> on. The log is clear you're not setting the PREFERRED_VERSION
> accordingly and you should.
>

You've lost me. Why am I not setting PREFERRED_VERSION accordingly? I have
two recipes in the checkout and I have configured prefer the older one,
which
seems entirely reasonable.

Re: Undefining a variable in a recipe?

[Otavio Salvador]

On Fri, May 2, 2014 at 10:11 AM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
>
> On 02/05/2014 14:07, Otavio Salvador wrote:
>> On Fri, May 2, 2014 at 10:01 AM, Alex J Lennon
>> <ajlennon@dynamicdevices.co.uk> wrote:
>>> On 02/05/2014 13:56, Otavio Salvador wrote:
>>>> On Fri, May 2, 2014 at 2:24 AM, Alex J Lennon
>>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>> ...
>>>>> So I guess I'm at the point where I'm wondering if a getVar() with a
>>>>> flag is behaving as you would expect it to,
>>>>> or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
>>>>> isn't defined?
>>>>>
>>>>> Thanks in advance for any advice,
>>>> I think we have a simple error error. You are mixing a recipe, which
>>>> is old and a metadata layer with new concepts.
>>>>
>>>> The u-boot-imx, in 2009.08 recipe, used to set the UBOOT_MACHINE in
>>>> the recipe as it was left as a fallback in case user needed it and the
>>>> value was different from newer releases.
>>>>
>>>> In your case, the easier is to make a new yourmachine.conf and use the
>>>> UBOOT_CONFIG or UBOOT_MACHINE setting there so it will work just fine.
>>>>
>>> If I have to do that, then I have to do that.
>>>
>>> However if I could just undefine one of the two variables defined in the
>>> meta-fsl-arm
>>> layer then I could continue with what I am doing without having to spend
>>> the time
>>> right now to rework the configuration, which is wasted effort for me, as
>>> I will be moving
>>> up to the new version of u-boot in the near future.
>>>
>>> Is there no simple way to undefine a variable in a recipe?
>> You can change the recipe byhand. This is ugly and I wouldn't do it. I
>> do think you are wasting more time trying to 'workaround' it than
>> fixing it.
>
> Or indeed, would be not be reasonable to modify the uboot-config.bbclass
> such that
> it tested for and discarded empty strings in UBOOT_MACHINE / UBOOT_CONFIG
> which would seem to be a more complete test and would eliminate the
> problem ?

Like: http://privatepaste.com/8046479967

>> Comment the UBOOT_MACHINE setting in the u-boot-imx recipe and move
>> on. The log is clear you're not setting the PREFERRED_VERSION
>> accordingly and you should.
>>
>
> You've lost me. Why am I not setting PREFERRED_VERSION accordingly? I have
> two recipes in the checkout and I have configured prefer the older one,
> which
> seems entirely reasonable.

Your log say's it looks for u-boot-imx 2013.04 and not for 2009.08.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Undefining a variable in a recipe?

[Otavio Salvador]

On Fri, May 2, 2014 at 10:23 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Fri, May 2, 2014 at 10:11 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> Or indeed, would be not be reasonable to modify the uboot-config.bbclass
>> such that
>> it tested for and discarded empty strings in UBOOT_MACHINE / UBOOT_CONFIG
>> which would seem to be a more complete test and would eliminate the
>> problem ?
>
> Like: http://privatepaste.com/8046479967

Fixed: http://privatepaste.com/3ffec754d4

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Undefining a variable in a recipe?

[Alex J Lennon]

On 02/05/2014 14:25, Otavio Salvador wrote:
> On Fri, May 2, 2014 at 10:23 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Fri, May 2, 2014 at 10:11 AM, Alex J Lennon
>> <ajlennon@dynamicdevices.co.uk> wrote:
>>> Or indeed, would be not be reasonable to modify the uboot-config.bbclass
>>> such that
>>> it tested for and discarded empty strings in UBOOT_MACHINE / UBOOT_CONFIG
>>> which would seem to be a more complete test and would eliminate the
>>> problem ?
>> Like: http://privatepaste.com/8046479967
> Fixed: http://privatepaste.com/3ffec754d4
>

Otavio, thanks for that. Python is not my métier and I had assumed that
the check on  'if ubootmachine' and so forth would check for definition
rather than be a check on a  zero length string.

However given Paul's pointer on Python I've revisited this,

"if len(x) > 0", "if len(x)",  and "if x" are all equivalent tests for empty strings in Python"

I had tried setting UBOOT_CONFIG = "" and UBOOT_MACHINE = "" as that's
what I saw used in the getVar(). This which didn't work for me, and I
wrongly assuming this was because  of the test.

If instead I set the appended machine type, e.g.
UBOOT_MACHINE_im6qsabresd = "", then that works (!) I guess it's being
copied across somewhere.

So thanks again for the advice. I think we've cracked it :)

Cheers,

Alex

Re: Undefining a variable in a recipe?

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Fri, May 2, 2014 at 11:08 AM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
>
> On 02/05/2014 14:25, Otavio Salvador wrote:
>> On Fri, May 2, 2014 at 10:23 AM, Otavio Salvador
> So thanks again for the advice. I think we've cracked it :)

Could you try the attached patch over Poky?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: 0001-uboot-config.bbclass-Fix-checking-of-non-setted-valu.patch --]
[-- Type: text/x-patch, Size: 2322 bytes --]

From 0b0a3f669f7d8beb626729d85e2cba5d85f3e2c0 Mon Sep 17 00:00:00 2001
From: Otavio Salvador <otavio@ossystems.com.br>
Date: Fri, 2 May 2014 12:20:28 -0300
Subject: [PATCH] uboot-config.bbclass: Fix checking of non-setted values in
 UBOOT_CONFIG
Organization: O.S. Systems Software LTDA.

The code were mistakenly checking for UBOOT_CONFIG flags instead of
UBOOT_CONFIG value when verifying for duplicated setting, this made it
hard to be overriden in case it was need in subsequent layers.

Reported-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/classes/uboot-config.bbclass | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/uboot-config.bbclass b/meta/classes/uboot-config.bbclass
index 8ac1b71..3c48657 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -13,24 +13,25 @@
 
 python () {
     ubootmachine = d.getVar("UBOOT_MACHINE", True)
-    ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
-    # The "doc" varflag is special, we don't want to see it here
-    ubootconfigflags.pop('doc', None)
+    ubootconfig = (d.getVar('UBOOT_CONFIG', True) or "").split()
 
-    if not ubootmachine and not ubootconfigflags:
+    if not ubootmachine and not ubootconfig:
         PN = d.getVar("PN", True)
         FILE = os.path.basename(d.getVar("FILE", True))
         bb.debug(1, "To build %s, see %s for instructions on \
                  setting up your machine config" % (PN, FILE))
         raise bb.parse.SkipPackage("Either UBOOT_MACHINE or UBOOT_CONFIG must be set in the %s machine configuration." % d.getVar("MACHINE", True))
 
-    if ubootmachine and ubootconfigflags:
+    if ubootmachine and ubootconfig:
         raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and UBOOT_CONFIG at the same time.")
 
+    ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
+    # The "doc" varflag is special, we don't want to see it here
+    ubootconfigflags.pop('doc', None)
+
     if not ubootconfigflags:
         return
 
-    ubootconfig = (d.getVar('UBOOT_CONFIG', True) or "").split()
     if len(ubootconfig) > 1:
         raise bb.parse.SkipPackage('You can only have a single default for UBOOT_CONFIG.')
     elif len(ubootconfig) == 0:
-- 
2.0.0.rc0

Re: Undefining a variable in a recipe?

[Alex J Lennon]

On 02/05/2014 16:24, Otavio Salvador wrote:
> On Fri, May 2, 2014 at 11:08 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 02/05/2014 14:25, Otavio Salvador wrote:
>>> On Fri, May 2, 2014 at 10:23 AM, Otavio Salvador
>> So thanks again for the advice. I think we've cracked it :)
> Could you try the attached patch over Poky?
>

I tried the patch, but I'm not sure that it makes a difference I'm afraid

- with UBOOT_MACHINE = "" or UBOOT_CONFIG = "" in my .bbappend I still
get the message about 2009.08 not being available
- with UBOOT_MACHINE_imx6qsabresd = "" .bbappend it still works

Best Regards,

Alex

Re: Undefining a variable in a recipe?

[Otavio Salvador]

On Fri, May 2, 2014 at 12:46 PM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
>
> On 02/05/2014 16:24, Otavio Salvador wrote:
>> On Fri, May 2, 2014 at 11:08 AM, Alex J Lennon
>> <ajlennon@dynamicdevices.co.uk> wrote:
>>> On 02/05/2014 14:25, Otavio Salvador wrote:
>>>> On Fri, May 2, 2014 at 10:23 AM, Otavio Salvador
>>> So thanks again for the advice. I think we've cracked it :)
>> Could you try the attached patch over Poky?
>>
>
> I tried the patch, but I'm not sure that it makes a difference I'm afraid
>
> - with UBOOT_MACHINE = "" or UBOOT_CONFIG = "" in my .bbappend I still
> get the message about 2009.08 not being available
> - with UBOOT_MACHINE_imx6qsabresd = "" .bbappend it still works

Yes but this is becase the u-boot-imx_2009.08 has a
UBOOT_MACHINE_imx6qsabresd setting. So it overrides the UBOOT_MACHINE
one. I think without this patch even UBOOT_MACHINE_imx6qsabresd won't
work.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Undefining a variable in a recipe?

[Alex J Lennon]

On 02/05/2014 17:55, Otavio Salvador wrote:
> On Fri, May 2, 2014 at 12:46 PM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 02/05/2014 16:24, Otavio Salvador wrote:
>>> On Fri, May 2, 2014 at 11:08 AM, Alex J Lennon
>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>> On 02/05/2014 14:25, Otavio Salvador wrote:
>>>>> On Fri, May 2, 2014 at 10:23 AM, Otavio Salvador
>>>> So thanks again for the advice. I think we've cracked it :)
>>> Could you try the attached patch over Poky?
>>>
>> I tried the patch, but I'm not sure that it makes a difference I'm afraid
>>
>> - with UBOOT_MACHINE = "" or UBOOT_CONFIG = "" in my .bbappend I still
>> get the message about 2009.08 not being available
>> - with UBOOT_MACHINE_imx6qsabresd = "" .bbappend it still works
> Yes but this is becase the u-boot-imx_2009.08 has a
> UBOOT_MACHINE_imx6qsabresd setting. So it overrides the UBOOT_MACHINE
> one. I think without this patch even UBOOT_MACHINE_imx6qsabresd won't
> work.
>

I do seem to be having some strangeness with what it is actually
building now
but at least it seems to be picking up the right recipe version so I
imagine I can get the
right build settings in the .bbappend now.

Thanks again Otavio (& Paul)

Re: Undefining a variable in a recipe?

[Paul Eggleton]

On Friday 02 May 2014 10:23:10 Otavio Salvador wrote:
> On Fri, May 2, 2014 at 10:11 AM, Alex J Lennon
> 
> <ajlennon@dynamicdevices.co.uk> wrote:
> > On 02/05/2014 14:07, Otavio Salvador wrote:
> >> On Fri, May 2, 2014 at 10:01 AM, Alex J Lennon
> >> 
> >> <ajlennon@dynamicdevices.co.uk> wrote:
> >>> On 02/05/2014 13:56, Otavio Salvador wrote:
> >>>> On Fri, May 2, 2014 at 2:24 AM, Alex J Lennon
> >>>> <ajlennon@dynamicdevices.co.uk> wrote:
> >>>> ...
> >>>> 
> >>>>> So I guess I'm at the point where I'm wondering if a getVar() with a
> >>>>> flag is behaving as you would expect it to,
> >>>>> or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
> >>>>> isn't defined?
> >>>>> 
> >>>>> Thanks in advance for any advice,
> >>>> 
> >>>> I think we have a simple error error. You are mixing a recipe, which
> >>>> is old and a metadata layer with new concepts.
> >>>> 
> >>>> The u-boot-imx, in 2009.08 recipe, used to set the UBOOT_MACHINE in
> >>>> the recipe as it was left as a fallback in case user needed it and the
> >>>> value was different from newer releases.
> >>>> 
> >>>> In your case, the easier is to make a new yourmachine.conf and use the
> >>>> UBOOT_CONFIG or UBOOT_MACHINE setting there so it will work just fine.
> >>> 
> >>> If I have to do that, then I have to do that.
> >>> 
> >>> However if I could just undefine one of the two variables defined in the
> >>> meta-fsl-arm
> >>> layer then I could continue with what I am doing without having to spend
> >>> the time
> >>> right now to rework the configuration, which is wasted effort for me, as
> >>> I will be moving
> >>> up to the new version of u-boot in the near future.
> >>> 
> >>> Is there no simple way to undefine a variable in a recipe?
> >> 
> >> You can change the recipe byhand. This is ugly and I wouldn't do it. I
> >> do think you are wasting more time trying to 'workaround' it than
> >> fixing it.
> > 
> > Or indeed, would be not be reasonable to modify the uboot-config.bbclass
> > such that
> > it tested for and discarded empty strings in UBOOT_MACHINE / UBOOT_CONFIG
> > which would seem to be a more complete test and would eliminate the
> > problem ?
> 
> Like: http://privatepaste.com/8046479967

"if len(x) > 0", "if len(x)",  and "if x" are all equivalent tests for empty 
strings in Python, so this part of the change does nothing but make the code  
slightly harder to read. This part of the test is not where the problem lies.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Undefining a variable in a recipe?

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 4065 bytes --]


On 02/05/2014 14:23, Otavio Salvador wrote:
> On Fri, May 2, 2014 at 10:11 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 02/05/2014 14:07, Otavio Salvador wrote:
>>> On Fri, May 2, 2014 at 10:01 AM, Alex J Lennon
>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>> On 02/05/2014 13:56, Otavio Salvador wrote:
>>>>> On Fri, May 2, 2014 at 2:24 AM, Alex J Lennon
>>>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>>> ...
>>>>>> So I guess I'm at the point where I'm wondering if a getVar() with a
>>>>>> flag is behaving as you would expect it to,
>>>>>> or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
>>>>>> isn't defined?
>>>>>>
>>>>>> Thanks in advance for any advice,
>>>>> I think we have a simple error error. You are mixing a recipe, which
>>>>> is old and a metadata layer with new concepts.
>>>>>
>>>>> The u-boot-imx, in 2009.08 recipe, used to set the UBOOT_MACHINE in
>>>>> the recipe as it was left as a fallback in case user needed it and the
>>>>> value was different from newer releases.
>>>>>
>>>>> In your case, the easier is to make a new yourmachine.conf and use the
>>>>> UBOOT_CONFIG or UBOOT_MACHINE setting there so it will work just fine.
>>>>>
>>>> If I have to do that, then I have to do that.
>>>>
>>>> However if I could just undefine one of the two variables defined in the
>>>> meta-fsl-arm
>>>> layer then I could continue with what I am doing without having to spend
>>>> the time
>>>> right now to rework the configuration, which is wasted effort for me, as
>>>> I will be moving
>>>> up to the new version of u-boot in the near future.
>>>>
>>>> Is there no simple way to undefine a variable in a recipe?
>>> You can change the recipe byhand. This is ugly and I wouldn't do it. I
>>> do think you are wasting more time trying to 'workaround' it than
>>> fixing it.
>> Or indeed, would be not be reasonable to modify the uboot-config.bbclass
>> such that
>> it tested for and discarded empty strings in UBOOT_MACHINE / UBOOT_CONFIG
>> which would seem to be a more complete test and would eliminate the
>> problem ?
> Like: http://privatepaste.com/8046479967
>
>>> Comment the UBOOT_MACHINE setting in the u-boot-imx recipe and move
>>> on. The log is clear you're not setting the PREFERRED_VERSION
>>> accordingly and you should.
>>>
>> You've lost me. Why am I not setting PREFERRED_VERSION accordingly? I have
>> two recipes in the checkout and I have configured prefer the older one,
>> which
>> seems entirely reasonable.
> Your log say's it looks for u-boot-imx 2013.04 and not for 2009.08.
>

I might be misunderstanding what you are saying here, but if you look at
my earlier email, and check the patchbin snippets I provided you will
see I am preferring 2009.08

 1.
    PREFERRED_VERSION_u-boot-imx="2009.08"

The test in uboot-config.bbclass causes this to fail/be unavailable to
the build, which is why the log says I cannot use 2009.08, instead
falling back to the newer version. Removing the two lines checking for
the definition of the two variables results in the 2009.08 build
completing successfully - but I don't want to leave that little bomb in
meta-fsl-arm for colleagues to fall over in future.

I cannot override what meta-fsl-arm is setting because I can't (or don't
know how to) undefine one of those two variables in my bbappend, and
although I believe I _can_ set it to an empty string as  Paul suggested,
I don't believe the the getVar() code in uboot-config.bbclass checks
this, although I'm a bit unclear on the semantics of that function call.

I appreciate the help here Otavio, and I was hoping there was a simple
non-invasive way to solve the problem by undefining the variable in my
layer, as it seemed cleaner.

I don't want to waste any more of your time on this though so if I can't
do that then I'll  just  take the hacky route  as an intermediary step,
copy out your 2009.08 recipe into my layer and mod it there.

Thanks for the time & feedback though,

Alex




[-- Attachment #2: Type: text/html, Size: 6968 bytes --]

Re: Undefining a variable in a recipe?

[Otavio Salvador]

On Fri, May 2, 2014 at 10:35 AM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
> I might be misunderstanding what you are saying here, but if you look at my
> earlier email, and check the patchbin snippets I provided you will see I am
> preferring 2009.08
>
> PREFERRED_VERSION_u-boot-imx="2009.08"
>
> The test in uboot-config.bbclass causes this to fail/be unavailable to the
> build, which is why the log says I cannot use 2009.08, instead falling back
> to the newer version. Removing the two lines checking for the definition of
> the two variables results in the 2009.08 build completing successfully - but
> I don't want to leave that little bomb in meta-fsl-arm for colleagues to
> fall over in future.

I think this should solve your issue. Please give this a try and I can
make a formal patch and send.

http://privatepaste.com/662e15c6b5

> I cannot override what meta-fsl-arm is setting because I can't (or don't
> know how to) undefine one of those two variables in my bbappend, and
> although I believe I _can_ set it to an empty string as  Paul suggested, I
> don't believe the the getVar() code in uboot-config.bbclass checks this,
> although I'm a bit unclear on the semantics of that function call.

I think this had been handled now, in the patch.

> I appreciate the help here Otavio, and I was hoping there was a simple
> non-invasive way to solve the problem by undefining the variable in my
> layer, as it seemed cleaner.
>
> I don't want to waste any more of your time on this though so if I can't do
> that then I'll  just  take the hacky route  as an intermediary step, copy
> out your 2009.08 recipe into my layer and mod it there.

Now I better understood your issue and you really found an issue in
the code. Please give this a try and confirm if it works for yu so I
can send the fix for review.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750