[OE-core] [PATCH 1/2] image.bbclass: Correct chaining compression support

Patrick Ohly patrick.ohly at intel.com
Mon Jul 24 08:35:37 UTC 2017


On Fri, 2017-07-21 at 18:06 -0400, Tom Rini wrote:
> The fix for this inadvertently broke chaining
> compression/conversion.  First, correct the u-boot conversion code.
> 
> Fixes: 46bc438374de ("image.bbclass: do exact
> match for rootfs type")
> Cc: Zhenhua Luo <zhenhua.luo at nxp.com>
> Cc: Richard Purdie <richard.purdie at linuxfoundation.org>
> Cc: Patrick Ohly <patrick.ohly at intel.com>
> Signed-off-by: Tom Rini <trini at konsulko.com>
> ---
> This change is fairly important and, imho, innocuous and should be
> populated to pyro/etc, once merged to master.  The next part of the
> series is clean-up and while with my U-Boot hat on, I would say
> should
> be pushed more widely, I am biased.
> ---
>  meta/classes/image.bbclass             |  2 +-
>  meta/classes/image_types_uboot.bbclass | 13 +++++--------
>  2 files changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index de535ce6fcff..bd6a5b7b810a 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -453,7 +453,7 @@ python () {
>          rm_tmp_images = set()
>          def gen_conversion_cmds(bt):
>              for ctype in ctypes:
> -                if bt[bt.find('.') + 1:] == ctype:
> +                if bt.endswith("." + ctype)

This reverts 46bc438374de and thus restores the code as I had
originally written it.

Looking at 46bc438374de, it's not clear to me how the commit message
matches the code, i.e. I don't understand the commit. So it was an
incorrect fix for the problem described in that commit message, and the
right one are your changes to the u-boot conversion command?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





More information about the Openembedded-core mailing list