7631 2015-04-20 12:46:01 +0000 wic complains about not finding mkdosfs and has poor message 2015-10-09 15:41:02 +0000 1 1 7 Build System, Metadata & Runtime OE-Core deployment unspecified x86 Multiple VERIFIED FIXED Medium normal 1.9 1 philip eduard.bartosh bogdanx.a.voiculescu daniel.alexandrux.istrate eduard.bartosh daniel.alexandrux.istrate --- --- No (bug/feature does not impact docs) oldest_to_newest 50412 0 philip 2015-04-20 12:46:01 +0000 [balister@thuvia build]$ wic create ../meta-sdr/contrib/wks/sdimage-8G.wks -e gnuradio-dev-image -o images/$MACHINE Checking basic build environment... Done. Creating image(s)... Error: A native program mkdosfs required to build the image was not found (see details above). Please make sure it's installed and try again. This led me to try: bitbake mkdosfs-native Which doesn't exist. bitbake dosfstools-native Did work. Same issue for mcopy, run mtools-native. I wouldn't be so picky, but the message says to check the details above and there are none. 50413 1 philip 2015-04-20 12:47:20 +0000 I am using openembedded-core, not oe-classic. 50654 2 philip 2015-04-30 14:51:36 +0000 Any interest in a simple bbclass images can inherit so that these utilities get built at image time? 50793 3 eduard.bartosh 2015-05-05 15:17:25 +0000 I'm not sure we should create some artificial images as people might not use them. I'd rather implement dependency check in wic. 50794 4 philip 2015-05-05 15:44:53 +0000 Do we want wic running bitbake to fufill the dependencies? The key is making it easy to build images, without turning bitbake into skynet. I'm also thinking we could add some tasks to a wic bbclass to run wic. 50800 5 philip 2015-05-05 17:06:43 +0000 (In reply to comment #3) > I'm not sure we should create some artificial images as people might not use > them. I'd rather implement dependency check in wic. Ed, the idea is to use a bbclass that an image recipe would inherit that adds DEPENDS on the bits wic needs to assemble the image. THe downside is slightly longer build time for people using the image recipe, but not wic. 50819 6 eduard.bartosh 2015-05-06 11:23:13 +0000 Thank you for explaining your idea. That makes sense to do, but I doubt it can be accepted because of longer build time. Maintainers are really picky about buld time regressions nowadays :) 50820 7 philip 2015-05-06 11:36:57 +0000 Well, it screws my build time, because I need to remember what recipes to build so I can make an image. Doing it automatically saves time. 51185 8 eduard.bartosh 2015-05-21 10:37:27 +0000 Would it be ok if I add optional command line option to wic to bake parted-native dosfstools-native and mtools-native? 51191 9 philip 2015-05-21 12:10:18 +0000 1) The error message should tell the user what recipes to build so he does not need to hunt around. 2) I still prefer a wic class. This also gives us a path for letting bitbake run wic via a task append. 51604 10 eduard.bartosh 2015-06-10 10:59:38 +0000 Bug 7672 (In reply to comment #9) > 1) The error message should tell the user what recipes to build so he does > not need to hunt around. Completely agree. Unfortunately this is hard to implement without integrating bitbake and wic. Bug 7672 is about this integration. As soon as users will have bitbake recipies for partitioned images it would be just a matter of adding dependencies to the recipe. > 2) I still prefer a wic class. This also gives us a path for letting bitbake > run wic via a task append. wic class is too generic solution for this class from my point of view as some of wic runtime dependencies depend on the type of the image, bootloader and other image details. PS: Added dependency to bug 7672 52785 11 eduard.bartosh 2015-08-03 13:59:36 +0000 I decided to go simple way: I put executable->recipe pairs for all tools to misc.py and made exec_native_cmd to suggest how to build them. Please, review: http://lists.openembedded.org/pipermail/openembedded-core/2015-August/108258.html 52921 12 eduard.bartosh 2015-08-09 09:57:04 +0000 My fix is accepted: http://cgit.openembedded.org/openembedded-core/commit/?id=1274379c91ee8e2fb9fbb34a6445cd5767eb4a35 53885 13 daniel.alexandrux.istrate 2015-09-09 13:36:15 +0000 Verified on master db92bc23880794be77373b0f2d8c26279dcecb84 [daniel@fedora-ws build]$ wic create directdisk -e core-image-minimal Checking basic build environment... Done. Creating image(s)... Error: A native program mkdosfs required to build the image was not found (see details above). Please bake it with 'bitbake dosfstools-native' and try again. [daniel@fedora-ws build]$ bitbake dosfstools-native Loading cache: 100% |#################################################################################| ETA: 00:00:00 Loaded 1319 entries from dependency cache. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "1.27.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Fedora-21" TARGET_SYS = "x86_64-poky-linux" MACHINE = "genericx86-64" DISTRO = "poky" DISTRO_VERSION = "1.8+snapshot-20150909" TUNE_FEATURES = "m64 core2" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp = "master:db92bc23880794be77373b0f2d8c26279dcecb84" NOTE: Preparing RunQueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 72 tasks of which 71 didn't need to be rerun and all succeeded. [daniel@fedora-ws build]$ [daniel@fedora-ws build]$ [daniel@fedora-ws build]$ wic create directdisk -e core-image-minimal Checking basic build environment... Done. Creating image(s)... Info: The new image(s) can be found here: /var/tmp/wic/build/directdisk-201509091633-sda.direct The following build artifacts were used to create the image(s): ROOTFS_DIR: /home/daniel/poky-M2/build/tmp/work/genericx86_64-poky-linux/core-image-minimal/1.0-r0/rootfs BOOTIMG_DIR: /home/daniel/poky-M2/build/tmp/sysroots/genericx86-64/usr/share KERNEL_DIR: /home/daniel/poky-M2/build/tmp/deploy/images/genericx86-64 NATIVE_SYSROOT: /home/daniel/poky-M2/build/tmp/sysroots/x86_64-linux The image(s) were created using OE kickstart file: /home/daniel/poky-M2/scripts/lib/wic/canned-wks/directdisk.wks 55128 14 daniel.alexandrux.istrate 2015-10-09 15:41:02 +0000 *** Bug 8474 has been marked as a duplicate of this bug. ***