From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mail.openembedded.org (Postfix) with ESMTP id EC7106FDEB for ; Thu, 9 Oct 2014 20:38:19 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 09 Oct 2014 13:38:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,687,1406617200"; d="scan'208,217";a="603013697" Received: from aehernan-devstation.zpn.intel.com (HELO [10.219.4.60]) ([10.219.4.60]) by fmsmga001.fm.intel.com with ESMTP; 09 Oct 2014 13:38:19 -0700 Message-ID: <5436F25E.7080205@linux.intel.com> Date: Thu, 09 Oct 2014 15:38:54 -0500 From: Alejandro Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Christopher Larson References: <1412094118-27406-1-git-send-email-alejandro.hernandez@linux.intel.com> <5436EE92.1010308@linux.intel.com> In-Reply-To: Cc: "bitbake-devel@lists.openembedded.org" Subject: Re: [PATCH v2] fetcher: fix BB_STRICT_CHECKSUM datatype check X-BeenThere: bitbake-devel@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussion that advance bitbake development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 20:38:23 -0000 Content-Type: multipart/alternative; boundary="------------040007070100060206040700" --------------040007070100060206040700 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit That is very true, I will fix that, thanks for pointing it out. On 09/10/14 15:27, Christopher Larson wrote: > > On Thu, Oct 9, 2014 at 1:22 PM, Alejandro Hernandez > > wrote: > > It does not change behavior but it forces the value to be a > string, avoiding related problems when performing comparisons on > "strict", another option as Richard Purdie suggested would be to > import the boolean function from /meta/lib/oe/types.py in OE-Core > into a new types module in bitbake, forcing it to get a "good" > value that we could then use. > > > No, that's incorrect. The second argument of getVar is a boolean > argument named 'expand', which controls whether you get an expanded or > unexpanded value. You're now passing a string in boolean context. > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics --------------040007070100060206040700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit That is very true, I will fix that, thanks for pointing it out.

On 09/10/14 15:27, Christopher Larson wrote:

On Thu, Oct 9, 2014 at 1:22 PM, Alejandro Hernandez <alejandro.hernandez@linux.intel.com> wrote:
It does not change behavior but it forces the value to be a string, avoiding related problems when performing comparisons on "strict", another option as Richard Purdie suggested would be to import the boolean function from /meta/lib/oe/types.py in OE-Core into a new types module in bitbake, forcing it to get a "good" value that we could then use.

No, that's incorrect. The second argument of getVar is a boolean argument named 'expand', which controls whether you get an expanded or unexpanded value. You're now passing a string in boolean context.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

--------------040007070100060206040700--