[PATCH] image_types_wic: add dependency to e2fsprogs-native

[PATCH] image_types_wic: add dependency to e2fsprogs-native

[Ed Bartosh]

Added e2fsprogs-native to the list of default dependencies for
wic (WKS_FILE_DEPENDS_DEFAULT) as all fs-related utilities
have to be in this list.

Thanks to Patrick Ohly for noticing this.

[YOCTO #11817]

Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
---
 meta/classes/image_types_wic.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image_types_wic.bbclass b/meta/classes/image_types_wic.bbclass
index 57ba646..b825b47 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -41,7 +41,7 @@ WKS_FILE_CHECKSUM = "${@'${WKS_FULL_PATH}:%s' % os.path.exists('${WKS_FULL_PATH}
 do_image_wic[file-checksums] += "${WKS_FILE_CHECKSUM}"
 do_image_wic[depends] += "${@' '.join('%s-native:do_populate_sysroot' % r for r in ('parted', 'gptfdisk', 'dosfstools', 'mtools'))}"
 
-WKS_FILE_DEPENDS_DEFAULT = "syslinux-native bmap-tools-native cdrtools-native btrfs-tools-native squashfs-tools-native"
+WKS_FILE_DEPENDS_DEFAULT = "syslinux-native bmap-tools-native cdrtools-native btrfs-tools-native squashfs-tools-native e2fsprogs-native"
 WKS_FILE_DEPENDS_BOOTLOADERS = ""
 WKS_FILE_DEPENDS_BOOTLOADERS_x86 = "syslinux grub-efi systemd-boot"
 WKS_FILE_DEPENDS_BOOTLOADERS_x86-64 = "syslinux grub-efi systemd-boot"
-- 
2.1.4

Re: [PATCH] image_types_wic: add dependency to e2fsprogs-native

[Patrick Ohly]

On Wed, 2017-07-26 at 19:21 +0300, Ed Bartosh wrote:
> Added e2fsprogs-native to the list of default dependencies for
> wic (WKS_FILE_DEPENDS_DEFAULT) as all fs-related utilities
> have to be in this list.
> 
> Thanks to Patrick Ohly for noticing this.
> 
> [YOCTO #11817]
> 
> Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>

Acked-by: Patrick Ohly <patrick.ohly@intel.com>

-- 
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.