From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 449D9E00826; Wed, 1 Mar 2017 21:30:32 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-HAM-Report: * 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source * [209.85.217.193 listed in dnsbl.sorbs.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (cswarth[at]gmail.com) * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [209.85.217.193 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-ua0-f193.google.com (mail-ua0-f193.google.com [209.85.217.193]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 64F41E00826 for ; Wed, 1 Mar 2017 21:30:30 -0800 (PST) Received: by mail-ua0-f193.google.com with SMTP id c11so1891988uaa.2 for ; Wed, 01 Mar 2017 21:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GSyq+GguP2Q646pSXvrufU15p01+aizxRDDRkGmpuTw=; b=FUfIdwoXbe3yhu/IVHkWGFaFQpnEES7ALnw/cVRV4YgipbAhRHJuH0TS2eqyN0zVcu bEZrTTJqCNQGkhJ8sApvSv8MdAX7hlDbGalLclPOI261giR4DFtx9slepKLPXkyPv8MU gQ3ngc7NytUOBj2Pv134WrD0UgXSsX9qLsPBgsV/89gBWAwmirZscCagDwMqVvoGbKdx Xu2NDajsWsmVJKLIIr2jW3USuE5zMb4QJFSCC7P39kqDAAgfhNA6rRdpYlJWxHtew4qY rePakRSOZnSOgwKglnJbKeW2smVxsObPWWjq2L8JBn6jDCjtmQZSePMeKkrRqEjmbC3j auiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GSyq+GguP2Q646pSXvrufU15p01+aizxRDDRkGmpuTw=; b=Bb6Kk56gWhjWSc2lDeZjJhPtPMOB6BIfFBmeYOLlljmEvlR5zKrLRSEZT2nxHGhoXz 9zDq2V4q4NU72nof5B4RfpgNgWO9qKsC18JKk5mUaU3x1dAsZ1Lqgl1XHlxgj9UEKgve p2PDS1DgIRH6X7TbbVzpQ4rBO3gm+9euX2qbnSEsQTZB7O+Rjr8+/qSXWJnrw8ICAnBF STGwuJXgHBaWcN/5XwFZLGnqukiJbw+KXnVnPLauq1sd1Q/gTeqmucC6ALVIVpz7Qop8 wfNbE9yF8m7VGBvyV7Lcw+92Wlwm2Z+5ffDdmwBmX/+cllQzHnyzeD6wHdU5S270Bx90 /34w== X-Gm-Message-State: AMke39k1i/+1T+Pi2GrXVje5vw5EV4m5Ckb0toBls82cEQtWpBwDYZa/wTYe9tr13zZnIverGaM7cfo6rMWtlw== X-Received: by 10.176.4.163 with SMTP id 32mr5237632uaw.33.1488432630215; Wed, 01 Mar 2017 21:30:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.105.208 with HTTP; Wed, 1 Mar 2017 21:29:49 -0800 (PST) In-Reply-To: <2555590.9aBZNM2DbW@peggleto-mobl.ger.corp.intel.com> References: <1669316.G5xAQX6A5S@peggleto-mobl.ger.corp.intel.com> <2555590.9aBZNM2DbW@peggleto-mobl.ger.corp.intel.com> From: chris warth Date: Wed, 1 Mar 2017 21:29:49 -0800 Message-ID: To: Paul Eggleton Cc: Yocto discussion list Subject: Re: BBMASK not working for me? X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 05:30:32 -0000 Content-Type: multipart/alternative; boundary=94eb2c124ac0323a570549b8baca --94eb2c124ac0323a570549b8baca Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 5:39 PM, Paul Eggleton wrote: > On Thursday, 2 March 2017 2:14:13 PM NZDT chris warth wrote: > > 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 --94eb2c124ac0323a570549b8baca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 1, 2017 at 5:39 PM, Paul Eggleton <paul.egglet= on@linux.intel.com> wrote:
On Thursday, 2 March 2017 2:14:13 PM NZDT chris warth wr= ote:
> <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.=C2=A0 It was not until I modified BBMASK_forcevariabl= e in my
> >> conf/bblayers.conf=C2=A0 that I saw any change in behavior. > >>
> >> BBMASK_forcevariable =3D ".*openjre|.*openjdk|.*qemu_qoriq"
> >>
> >> This inability to modify BBMASK unless using _forcevariable w= as also
> >> noted last year.
> >> https://lists= .yoctoproject.org/pipermail/yocto/2016-September/032033.html<= br> > >
> > That sounds strange. Did you use bitbake -e | less to see where y= our 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 =3D at some point later in parsing than local.con= f. The
> > history of the BBMASK variable shown through bitbake -e will tell= you
> > exactly where that is.
>
> Thank you, Paul.=C2=A0 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=3D".*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-a= rm /
meta-fsl-ppc either in current master or in the history for master - where = is
this exactly?


FWIW, Th= is is in a SDK for the LS1046A development board supplied by NXP as a coupl= e of ISO images and a tarball in late 2016. =C2=A0 =C2=A0For the most part = it seems to be based on publicly accessible sources although the ls1046a-rd= b support comes from cached copies of internal NXP git repos (e.g. sw-stash.freescale.net/scm/dnn= pi). =C2=A0=C2=A0

Here is the bitbake -e outpu= t showing BBMASK

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

=C2=A0Thanks again for helping me to u= nderstand this stuff.

- Chris
--94eb2c124ac0323a570549b8baca--