Re: Image generation change

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2012-03-01 at 18:19 -0700, Gary Thomas wrote:
> I'm having a problem after the recent change
>    commit eacedb4f2afa98dbd2f5ea7a9f52e6ea952a72d2
>    Author: Richard Purdie <richard.purdie@linuxfoundation.org>
>    Date:   Wed Feb 29 16:24:26 2012 +0000
> 
>      image_types: Correctness fixes
> 
>      * Add a newline to improve the output formatting
>      * Use set() to turn the list into a set of unique items to prevnt
>        the same image code running twice (for e.g. IMAGE_FSTYPES = "tar.gz tar.bz2")
>      * Support multiple compression extensions such as ".gz.u-boot"
>      * Fix basetype/type typo and fix multiple image generation
> 
>      Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> 
> I build initrd-style images which can be loaded by U-Boot.  This is a multi-step
> process - first create the root image as ext3.gz, then pack it into the U-Boot
> image.  Before this change, I could use this setup:
> 
> IMAGE_FSTYPES = "ext3.gz initrd"
> IMAGE_CMD_initrd = " uboot_initrd;"
> IMAGE_ROOTFS_SIZE = "24576"
> 
> where the 'uboot_initrd' command expected the ext3.gz image to be complete and
> all it does is the U-Boot mkimage magic.
> 
> This no longer works as when uboot_initrd() runs, there is no ext3.gz image
> yet built.  I'm not sure I understand the exact reason, but if I revert just
> these lines, the process works again.
> 
> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> index 5b48a09..8ea170a 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -29,7 +29,7 @@ def get_imagecmds(d):
>       if d.getVar('IMAGE_LINK_NAME', True):
>           cmds += "      rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.*"
> 
> -    for type in set(types):
> +    for type in types:
>           ccmd = []
>           subimages = []
>           localdata = bb.data.createCopy(d)
> 
> If there is another way to solve my problem, i.e. generate the wrapped
> up initrd image, that will still work with the code as is, I'd be happy
> to use it, but I'm not sure how to write such a process.
> 
> Any ideas gladly accepted, thanks

Does the patch "image_types.bbclass: We need to preserve order in the
types variable and avoid set()" fix this problem?

Cheers,

Richard