BBMASK not working for me?

BBMASK not working for me?

[chris warth]

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

Can anyone suggest why my BBMASK is not working?
Maybe I'm not putting it into the right file?
Did I construct the regex incorrectly?

In my conf/bblayers.conf I have,

     BBMASK .= "qemu"

Then I wipe out the cache by deleting the "tmp/" directory.

Now I would expect
    bitbake -n -c fetch qemu
to give a 'Nothing PROVIDES' error.

That is not what happens.   Instead it still completes normally.

I am trying to ignore recipes like
     meta-freescale/recipes-devtools/qemu/qemu_qoriq.bb

Thanks in advance for any help.

- Chris

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

Re: BBMASK not working for me?

[Jeremy A. Puhlman]

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



On 3/1/2017 12:06 PM, chris warth wrote:
> Can anyone suggest why my BBMASK is not working?
> Maybe I'm not putting it into the right file?
> Did I construct the regex incorrectly?
>
> In my conf/bblayers.conf I have,
>
>      BBMASK .= "qemu"

This basically concatenates qemu to what ever is already in BBMASK. It 
is a regex expression so you want to treat it as such.
You want to likely do something like:
BBMASK .= "|(qemu)"

OTOH, qemu matches anythin with qemu in the path. You likely want to use 
the full filename:
BBMASK .= "|(qemu_qoriq.bb <http://qemu_qoriq.bb>)"


>
> Then I wipe out the cache by deleting the "tmp/" directory.
>
> Now I would expect
>     bitbake -n -c fetch qemu
> to give a 'Nothing PROVIDES' error.
>
> That is not what happens.   Instead it still completes normally.
>
> I am trying to ignore recipes like
>      meta-freescale/recipes-devtools/qemu/qemu_qoriq.bb 
> <http://qemu_qoriq.bb>
>
> Thanks in advance for any help.
>
> - Chris
>
>

-- 
Jeremy A. Puhlman
jpuhlman@mvista.com


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

Re: BBMASK not working for me?

[Andre McCurdy]

On Wed, Mar 1, 2017 at 12:15 PM, Jeremy A. Puhlman <jpuhlman@mvista.com> wrote:
>
> On 3/1/2017 12:06 PM, chris warth wrote:
>
> Can anyone suggest why my BBMASK is not working?
> Maybe I'm not putting it into the right file?
> Did I construct the regex incorrectly?
>
> In my conf/bblayers.conf I have,
>
>      BBMASK .= "qemu"
>
> This basically concatenates qemu to what ever is already in BBMASK. It is a
> regex expression so you want to treat it as such.
> You want to likely do something like:
> BBMASK .= "|(qemu)"
>
> OTOH, qemu matches anythin with qemu in the path. You likely want to use the
> full filename:
> BBMASK .= "|(qemu_qoriq.bb)"

If you are using Yocto 2.1 or later, it's safer and easier to
construct BBMASK as set of space separated expressions rather than
trying to append to a single regex. e.g. in this case:

  BBMASK += "qemu_qoriq.bb"

> Then I wipe out the cache by deleting the "tmp/" directory.

There's no need to wipe out sstate or tmp to test this. If you try to
build a recipe which doesn't exist or is masked, you'll get an error
regardless of whether the recipe has been built previously.

> Now I would expect
>     bitbake -n -c fetch qemu
> to give a 'Nothing PROVIDES' error.
>
> That is not what happens.   Instead it still completes normally.
>
> I am trying to ignore recipes like
>      meta-freescale/recipes-devtools/qemu/qemu_qoriq.bb
>
> Thanks in advance for any help.
>
> - Chris
>
> --
> Jeremy A. Puhlman
> jpuhlman@mvista.com
>

Re: BBMASK not working for me?

[chris warth]

Thanks, all.  I wanted to share the solution.

This vendor-supplied version of yocto looks like 2.0, so the space
separated expressions are not available.
After putting some print statements in cooker.py I discovered that
appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
effect.  It was not until I modified BBMASK_forcevariable in my
conf/bblayers.conf  that I saw any change in behavior.

BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"

This inability to modify BBMASK unless using _forcevariable was also
noted last year.
https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html

Re: BBMASK not working for me?

[Paul Eggleton]

Hi Chris,

On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
> Thanks, all.  I wanted to share the solution.
> 
> This vendor-supplied version of yocto looks like 2.0, so the space
> separated expressions are not available.
> After putting some print statements in cooker.py I discovered that
> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
> effect.  It was not until I modified BBMASK_forcevariable in my
> conf/bblayers.conf  that I saw any change in behavior.
> 
> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
> 
> This inability to modify BBMASK unless using _forcevariable was also
> noted last year.
> https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html

That sounds strange. Did you use bitbake -e | less to see where your non-
forcevariable setting was being overridden? More than likely you have a layer 
or some other configuration you're bringing in and that's simply setting it 
with = at some point later in parsing than local.conf. The history of the 
BBMASK variable shown through bitbake -e will tell you exactly where that is.

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: BBMASK not working for me?

[chris warth]

Thank you, Paul.  I didn't know about bitbake -e.
As you predicted, it shows that an earlier layer is setting BBMASK
with equals, in this case the
meta-freescale layer.

BBMASK=".*openjre|.*openjdk"

Should I be mad at the vendor for being careless?
Is BBMASK_forcevariable the right workaround for this?
Or is there some layer priority scheme beyond the ordering in the
bblayers.conf file that I should playing nice with?

Thanks for your help, really!

- Chris

On Wed, Mar 1, 2017 at 5:03 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi Chris,
>
> On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
>> Thanks, all.  I wanted to share the solution.
>>
>> This vendor-supplied version of yocto looks like 2.0, so the space
>> separated expressions are not available.
>> After putting some print statements in cooker.py I discovered that
>> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
>> effect.  It was not until I modified BBMASK_forcevariable in my
>> conf/bblayers.conf  that I saw any change in behavior.
>>
>> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
>>
>> This inability to modify BBMASK unless using _forcevariable was also
>> noted last year.
>> https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html
>
> That sounds strange. Did you use bitbake -e | less to see where your non-
> forcevariable setting was being overridden? More than likely you have a layer
> or some other configuration you're bringing in and that's simply setting it
> with = at some point later in parsing than local.conf. The history of the
> BBMASK variable shown through bitbake -e will tell you exactly where that is.
>
> Cheers,
> Paul
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

Re: BBMASK not working for me?

[Paul Eggleton]

On Thursday, 2 March 2017 2:14:13 PM NZDT chris warth wrote:
> <paul.eggleton@linux.intel.com> wrote:
> > On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
> >> This vendor-supplied version of yocto looks like 2.0, so the space
> >> separated expressions are not available.
> >> After putting some print statements in cooker.py I discovered that
> >> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
> >> effect.  It was not until I modified BBMASK_forcevariable in my
> >> conf/bblayers.conf  that I saw any change in behavior.
> >> 
> >> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
> >> 
> >> This inability to modify BBMASK unless using _forcevariable was also
> >> noted last year.
> >> https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html
> > 
> > That sounds strange. Did you use bitbake -e | less to see where your non-
> > forcevariable setting was being overridden? More than likely you have a
> > layer or some other configuration you're bringing in and that's simply
> > setting it with = at some point later in parsing than local.conf. The
> > history of the BBMASK variable shown through bitbake -e will tell you
> > exactly where that is.
>
> Thank you, Paul.  I didn't know about bitbake -e.
> As you predicted, it shows that an earlier layer is setting BBMASK
> with equals, in this case the
> meta-freescale layer.
> 
> BBMASK=".*openjre|.*openjdk"
> 
> Should I be mad at the vendor for being careless?

Personally I think you should, yes. BSP layers really should not be setting 
BBMASK, IMO. Interestingly though I can't see this BBMASK in meta-fsl-arm / 
meta-fsl-ppc either in current master or in the history for master - where is 
this exactly?

> Is BBMASK_forcevariable the right workaround for this?

You should be able to use _append, provided you are OK with openjre/openjdk 
recipes also being masked out.

> Or is there some layer priority scheme beyond the ordering in the
> bblayers.conf file that I should playing nice with?

I usually describe BBMASK as a huge hammer - it prevents bitbake from even 
reading recipes / bbappends that match it. My recommendation is not to use it 
at all unless there's no other way.

One alternative way of dealing with recipes you don't want to have built is to 
use PNBLACKLIST. You do have to know the exact recipe name (PN) that you want 
to blacklist, you can't do it by regex - but usually that's not too much of a 
problem. The advantage of PNBLACKLIST is that you get to specify a reason why 
the recipe is blacklisted, and thus it is usually much more obvious what's 
going on when the recipe is requested anywhere (be it directly on the bitbake 
command line or indirectly as a dependency) - the reason will be printed in 
the resulting error. The actual filename in this case is qemu-qoriq_git.bb 
meaning that the PN is unique, so you can do this for example:

PNBLACKLIST[qemu-qoriq] = "Not supported by XYZ corp"

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: BBMASK not working for me?

[chris warth]

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

On Wed, Mar 1, 2017 at 5:39 PM, Paul Eggleton <paul.eggleton@linux.intel.com
> wrote:

> On Thursday, 2 March 2017 2:14:13 PM NZDT chris warth wrote:
> > <paul.eggleton@linux.intel.com> wrote:
> > > On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
> > >> This vendor-supplied version of yocto looks like 2.0, so the space
> > >> separated expressions are not available.
> > >> After putting some print statements in cooker.py I discovered that
> > >> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
> > >> effect.  It was not until I modified BBMASK_forcevariable in my
> > >> conf/bblayers.conf  that I saw any change in behavior.
> > >>
> > >> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
> > >>
> > >> This inability to modify BBMASK unless using _forcevariable was also
> > >> noted last year.
> > >> https://lists.yoctoproject.org/pipermail/yocto/2016-
> September/032033.html
> > >
> > > That sounds strange. Did you use bitbake -e | less to see where your
> non-
> > > forcevariable setting was being overridden? More than likely you have a
> > > layer or some other configuration you're bringing in and that's simply
> > > setting it with = at some point later in parsing than local.conf. The
> > > history of the BBMASK variable shown through bitbake -e will tell you
> > > exactly where that is.
> >
> > Thank you, Paul.  I didn't know about bitbake -e.
> > As you predicted, it shows that an earlier layer is setting BBMASK
> > with equals, in this case the
> > meta-freescale layer.
> >
> > BBMASK=".*openjre|.*openjdk"
> >
> > Should I be mad at the vendor for being careless?
>
> Personally I think you should, yes. BSP layers really should not be setting
> BBMASK, IMO. Interestingly though I can't see this BBMASK in meta-fsl-arm /
> meta-fsl-ppc either in current master or in the history for master - where
> is
> this exactly?
>
>
FWIW, This is in a SDK for the LS1046A development board supplied by NXP as
a couple of ISO images and a tarball in late 2016.    For the most part it
seems to be based on publicly accessible sources although the ls1046a-rdb
support comes from cached copies of internal NXP git repos (e.g.
sw-stash.freescale.net/scm/dnnpi).

Here is the bitbake -e output showing BBMASK

# $BBMASK [2 operations]
#   set
/mnt/nxp-sdk/sources/meta-freescale/conf/machine/include/qoriq-arm64.inc:9
#     ".*openjre|.*openjdk"
#   set /mnt/nxp-sdk/sources/poky/meta/conf/documentation.conf:95
#     [doc] "Prevents BitBake from processing specific recipes or recipe
append files. Use the BBMASK variable from within conf/local.conf."
# pre-expansion value:
#   ".*openjre|.*openjdk"
BBMASK=".*openjre|.*openjdk"

 Thanks again for helping me to understand this stuff.

- Chris

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