Patchwork [1/3] wic: Initial code for wic (OpenEmbedded Image Creator)

login
register
mail settings
Submitter tom.zanussi@linux.intel.com
Date Sept. 27, 2013, 2:17 a.m.
Message ID <8dbedc35cbce3319722c012af0dad737773446f6.1380234931.git.tom.zanussi@linux.intel.com>
Download mbox | patch
Permalink /patch/59061/
State Accepted
Commit 53a1d9a788fd9f970af980da2ab975cca60685c4
Headers show

Comments

tom.zanussi@linux.intel.com - Sept. 27, 2013, 2:17 a.m.
Initial implementation of the 'wic' command.

The 'wic' command generates partitioned images from existing
OpenEmbedded build artifacts.  Image generation is driven by
partitioning commands contained in an 'Openembedded kickstart' (.wks)
file specified either directly on the command-line or as one of a
selection of canned .wks files (see 'wic list images').  When applied
to a given set of build artifacts, the result is an image or set of
images that can be directly written onto media and used on a
particular system.

'wic' is based loosely on the 'mic' (Meego Image Creator) framework,
but heavily modified to make direct use of OpenEmbedded build
artifacts instead of package installation and configuration, things
already incorporated int the OE artifacts.

The name 'wic' comes from 'oeic' with the 'oe' diphthong promoted to
the letter 'w', because 'oeic' is impossible to remember or pronounce.

This covers the mechanics of invoking and providing help for the
command and sub-commands; it contains hooks for future commits to
connect with the actual functionality, once implemented.

Help is integrated into the 'wic' command - see that for details on
usage.

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 scripts/lib/image/__init__.py |  22 +++
 scripts/lib/image/engine.py   | 256 ++++++++++++++++++++++++++++++++++
 scripts/lib/image/help.py     | 311 ++++++++++++++++++++++++++++++++++++++++++
 scripts/wic                   | 185 +++++++++++++++++++++++++
 4 files changed, 774 insertions(+)
 create mode 100644 scripts/lib/image/__init__.py
 create mode 100644 scripts/lib/image/engine.py
 create mode 100644 scripts/lib/image/help.py
 create mode 100755 scripts/wic
tom.zanussi@linux.intel.com - Sept. 27, 2013, 2:17 a.m.
This is the starting point for the implemention described in [YOCTO
3847] which came to the conclusion that it would make sense to use
kickstart syntax to implement image creation in OpenEmbedded.  I
subsequently realized that there was an existing tool that already
implemented image creation using kickstart syntax, the Tizen/Meego mic
tool.  As such, it made sense to use that as a starting point - this
commit essentially just copies the relevant Python code from the MIC
tool to the scripts/lib dir, where it can be accessed by the
previously created wic tool.

Most of this will be removed or renamed by later commits, since we're
initially focusing on partitioning only.  Care should be taken so that
we can easily add back any additional functionality should we decide
later to expand the tool, though (we may also want to contribute our
local changes to the mic tool to the Tizen project if it makes sense,
and therefore should avoid gratuitous changes to the original code if
possible).

Added the /mic subdir from Tizen mic repo as a starting point:

 git clone git://review.tizen.org/tools/mic.git

 For reference, the top commit:

 commit 20164175ddc234a17b8a12c33d04b012347b1530
 Author: Gui Chen <gui.chen@intel.com>
 Date:   Sun Jun 30 22:32:16 2013 -0400

    bump up to 0.19.2

Also added the /plugins subdir, moved to under the /mic subdir (to
match the default plugin_dir location in mic.conf.in, which was
renamed to yocto-image.conf (moved and renamed by later patches) and
put into /scripts.

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 scripts/lib/mic/3rdparty/pykickstart/base.py       |  466 ++++++
 .../mic/3rdparty/pykickstart/commands/__init__.py  |   26 +
 .../3rdparty/pykickstart/commands/authconfig.py    |   40 +
 .../mic/3rdparty/pykickstart/commands/autopart.py  |  119 ++
 .../mic/3rdparty/pykickstart/commands/autostep.py  |   55 +
 .../3rdparty/pykickstart/commands/bootloader.py    |  265 ++++
 .../mic/3rdparty/pykickstart/commands/clearpart.py |   86 ++
 .../mic/3rdparty/pykickstart/commands/device.py    |  125 ++
 .../3rdparty/pykickstart/commands/deviceprobe.py   |   40 +
 .../3rdparty/pykickstart/commands/displaymode.py   |   68 +
 .../mic/3rdparty/pykickstart/commands/dmraid.py    |   91 ++
 .../3rdparty/pykickstart/commands/driverdisk.py    |  184 +++
 .../lib/mic/3rdparty/pykickstart/commands/fcoe.py  |  114 ++
 .../mic/3rdparty/pykickstart/commands/firewall.py  |  193 +++
 .../mic/3rdparty/pykickstart/commands/firstboot.py |   62 +
 .../lib/mic/3rdparty/pykickstart/commands/group.py |   88 ++
 .../3rdparty/pykickstart/commands/ignoredisk.py    |  139 ++
 .../3rdparty/pykickstart/commands/interactive.py   |   58 +
 .../lib/mic/3rdparty/pykickstart/commands/iscsi.py |  133 ++
 .../mic/3rdparty/pykickstart/commands/iscsiname.py |   54 +
 .../lib/mic/3rdparty/pykickstart/commands/key.py   |   64 +
 .../mic/3rdparty/pykickstart/commands/keyboard.py  |   55 +
 .../lib/mic/3rdparty/pykickstart/commands/lang.py  |   60 +
 .../3rdparty/pykickstart/commands/langsupport.py   |   58 +
 .../mic/3rdparty/pykickstart/commands/lilocheck.py |   54 +
 .../mic/3rdparty/pykickstart/commands/logging.py   |   66 +
 .../mic/3rdparty/pykickstart/commands/logvol.py    |  304 ++++
 .../3rdparty/pykickstart/commands/mediacheck.py    |   53 +
 .../mic/3rdparty/pykickstart/commands/method.py    |  186 +++
 .../mic/3rdparty/pykickstart/commands/monitor.py   |  106 ++
 .../lib/mic/3rdparty/pykickstart/commands/mouse.py |   70 +
 .../mic/3rdparty/pykickstart/commands/multipath.py |  111 ++
 .../mic/3rdparty/pykickstart/commands/network.py   |  363 +++++
 .../mic/3rdparty/pykickstart/commands/partition.py |  353 +++++
 .../lib/mic/3rdparty/pykickstart/commands/raid.py  |  365 +++++
 .../mic/3rdparty/pykickstart/commands/reboot.py    |   79 +
 .../lib/mic/3rdparty/pykickstart/commands/repo.py  |  249 +++
 .../mic/3rdparty/pykickstart/commands/rescue.py    |   68 +
 .../mic/3rdparty/pykickstart/commands/rootpw.py    |   93 ++
 .../mic/3rdparty/pykickstart/commands/selinux.py   |   64 +
 .../mic/3rdparty/pykickstart/commands/services.py  |   71 +
 .../lib/mic/3rdparty/pykickstart/commands/skipx.py |   54 +
 .../lib/mic/3rdparty/pykickstart/commands/sshpw.py |  105 ++
 .../mic/3rdparty/pykickstart/commands/timezone.py  |   86 ++
 .../mic/3rdparty/pykickstart/commands/updates.py   |   60 +
 .../mic/3rdparty/pykickstart/commands/upgrade.py   |  106 ++
 .../lib/mic/3rdparty/pykickstart/commands/user.py  |  173 +++
 .../lib/mic/3rdparty/pykickstart/commands/vnc.py   |  114 ++
 .../mic/3rdparty/pykickstart/commands/volgroup.py  |  102 ++
 .../mic/3rdparty/pykickstart/commands/xconfig.py   |  184 +++
 .../mic/3rdparty/pykickstart/commands/zerombr.py   |   69 +
 .../lib/mic/3rdparty/pykickstart/commands/zfcp.py  |  134 ++
 scripts/lib/mic/3rdparty/pykickstart/constants.py  |   57 +
 scripts/lib/mic/3rdparty/pykickstart/errors.py     |  103 ++
 .../mic/3rdparty/pykickstart/handlers/control.py   | 1307 ++++++++++++++++
 .../lib/mic/3rdparty/pykickstart/handlers/f10.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f11.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f12.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f13.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f14.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f15.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f16.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f7.py    |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f8.py    |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/f9.py    |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/fc3.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/fc4.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/fc5.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/fc6.py   |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/rhel3.py |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/rhel4.py |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/rhel5.py |   24 +
 .../lib/mic/3rdparty/pykickstart/handlers/rhel6.py |   24 +
 scripts/lib/mic/3rdparty/pykickstart/ko.py         |   37 +
 scripts/lib/mic/3rdparty/pykickstart/options.py    |  204 +++
 scripts/lib/mic/3rdparty/pykickstart/parser.py     |  702 +++++++++
 scripts/lib/mic/3rdparty/pykickstart/sections.py   |  244 +++
 .../3rdparty/pykickstart/urlgrabber/__init__.py    |   53 +
 .../3rdparty/pykickstart/urlgrabber/byterange.py   |  463 ++++++
 .../mic/3rdparty/pykickstart/urlgrabber/grabber.py | 1477 ++++++++++++++++++
 .../3rdparty/pykickstart/urlgrabber/keepalive.py   |  617 ++++++++
 .../mic/3rdparty/pykickstart/urlgrabber/mirror.py  |  458 ++++++
 .../3rdparty/pykickstart/urlgrabber/progress.py    |  530 +++++++
 .../3rdparty/pykickstart/urlgrabber/sslfactory.py  |   90 ++
 scripts/lib/mic/3rdparty/pykickstart/version.py    |  197 +++
 scripts/lib/mic/__init__.py                        |    4 +
 scripts/lib/mic/__version__.py                     |    1 +
 scripts/lib/mic/bootstrap.py                       |  279 ++++
 scripts/lib/mic/chroot.py                          |  343 +++++
 scripts/lib/mic/conf.py                            |  239 +++
 scripts/lib/mic/creator.py                         |  354 +++++
 scripts/lib/mic/imager/baseimager.py               | 1335 ++++++++++++++++
 scripts/lib/mic/imager/fs.py                       |   99 ++
 scripts/lib/mic/imager/livecd.py                   |  750 +++++++++
 scripts/lib/mic/imager/liveusb.py                  |  308 ++++
 scripts/lib/mic/imager/loop.py                     |  418 ++++++
 scripts/lib/mic/imager/raw.py                      |  501 +++++++
 scripts/lib/mic/kickstart/__init__.py              |  892 +++++++++++
 .../lib/mic/kickstart/custom_commands/__init__.py  |   12 +
 .../lib/mic/kickstart/custom_commands/desktop.py   |   95 ++
 .../mic/kickstart/custom_commands/installerfw.py   |   63 +
 .../lib/mic/kickstart/custom_commands/micboot.py   |   49 +
 .../lib/mic/kickstart/custom_commands/micrepo.py   |  127 ++
 .../lib/mic/kickstart/custom_commands/partition.py |   57 +
 scripts/lib/mic/msger.py                           |  309 ++++
 scripts/lib/mic/plugin.py                          |   98 ++
 scripts/lib/mic/pluginbase.py                      |  101 ++
 scripts/lib/mic/plugins/backend/yumpkgmgr.py       |  490 ++++++
 scripts/lib/mic/plugins/backend/zypppkgmgr.py      |  973 ++++++++++++
 scripts/lib/mic/plugins/hook/empty_hook.py         |    3 +
 scripts/lib/mic/plugins/imager/fs_plugin.py        |  143 ++
 scripts/lib/mic/plugins/imager/livecd_plugin.py    |  255 ++++
 scripts/lib/mic/plugins/imager/liveusb_plugin.py   |  260 ++++
 scripts/lib/mic/plugins/imager/loop_plugin.py      |  255 ++++
 scripts/lib/mic/plugins/imager/raw_plugin.py       |  275 ++++
 scripts/lib/mic/rt_util.py                         |  223 +++
 scripts/lib/mic/test                               |    1 +
 scripts/lib/mic/utils/BmapCreate.py                |  298 ++++
 scripts/lib/mic/utils/Fiemap.py                    |  252 ++++
 scripts/lib/mic/utils/cmdln.py                     | 1586 ++++++++++++++++++++
 scripts/lib/mic/utils/errors.py                    |   71 +
 scripts/lib/mic/utils/fs_related.py                | 1029 +++++++++++++
 scripts/lib/mic/utils/gpt_parser.py                |  331 ++++
 scripts/lib/mic/utils/grabber.py                   |   97 ++
 scripts/lib/mic/utils/misc.py                      | 1067 +++++++++++++
 scripts/lib/mic/utils/partitionedfs.py             |  790 ++++++++++
 scripts/lib/mic/utils/proxy.py                     |  183 +++
 scripts/lib/mic/utils/rpmmisc.py                   |  600 ++++++++
 scripts/lib/mic/utils/runner.py                    |  109 ++
 scripts/yocto-image.conf                           |   35 +
 130 files changed, 29216 insertions(+)
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/__init__.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/base.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/__init__.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/authconfig.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/autopart.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/autostep.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/bootloader.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/clearpart.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/device.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/deviceprobe.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/displaymode.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/dmraid.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/driverdisk.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/fcoe.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/firewall.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/firstboot.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/group.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/ignoredisk.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/interactive.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/iscsi.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/iscsiname.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/key.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/keyboard.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/lang.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/langsupport.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/lilocheck.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/logging.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/logvol.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/mediacheck.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/method.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/monitor.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/mouse.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/multipath.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/network.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/partition.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/raid.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/reboot.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/repo.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/rescue.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/rootpw.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/selinux.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/services.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/skipx.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/sshpw.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/timezone.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/updates.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/upgrade.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/user.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/vnc.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/volgroup.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/xconfig.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/zerombr.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/commands/zfcp.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/constants.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/errors.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/__init__.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/control.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f10.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f11.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f12.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f13.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f14.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f15.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f16.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f7.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f8.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/f9.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/fc3.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/fc4.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/fc5.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/fc6.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/rhel3.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/rhel4.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/rhel5.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/handlers/rhel6.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/ko.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/options.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/parser.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/sections.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/urlgrabber/__init__.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/urlgrabber/byterange.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/urlgrabber/grabber.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/urlgrabber/keepalive.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/urlgrabber/mirror.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/urlgrabber/progress.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/urlgrabber/sslfactory.py
 create mode 100644 scripts/lib/mic/3rdparty/pykickstart/version.py
 create mode 100644 scripts/lib/mic/__init__.py
 create mode 100644 scripts/lib/mic/__version__.py
 create mode 100644 scripts/lib/mic/bootstrap.py
 create mode 100644 scripts/lib/mic/chroot.py
 create mode 100644 scripts/lib/mic/conf.py
 create mode 100644 scripts/lib/mic/creator.py
 create mode 100644 scripts/lib/mic/imager/__init__.py
 create mode 100644 scripts/lib/mic/imager/baseimager.py
 create mode 100644 scripts/lib/mic/imager/fs.py
 create mode 100644 scripts/lib/mic/imager/livecd.py
 create mode 100644 scripts/lib/mic/imager/liveusb.py
 create mode 100644 scripts/lib/mic/imager/loop.py
 create mode 100644 scripts/lib/mic/imager/raw.py
 create mode 100644 scripts/lib/mic/kickstart/__init__.py
 create mode 100644 scripts/lib/mic/kickstart/custom_commands/__init__.py
 create mode 100644 scripts/lib/mic/kickstart/custom_commands/desktop.py
 create mode 100644 scripts/lib/mic/kickstart/custom_commands/installerfw.py
 create mode 100644 scripts/lib/mic/kickstart/custom_commands/micboot.py
 create mode 100644 scripts/lib/mic/kickstart/custom_commands/micrepo.py
 create mode 100644 scripts/lib/mic/kickstart/custom_commands/partition.py
 create mode 100644 scripts/lib/mic/msger.py
 create mode 100644 scripts/lib/mic/plugin.py
 create mode 100644 scripts/lib/mic/pluginbase.py
 create mode 100644 scripts/lib/mic/plugins/backend/yumpkgmgr.py
 create mode 100755 scripts/lib/mic/plugins/backend/zypppkgmgr.py
 create mode 100644 scripts/lib/mic/plugins/hook/.py
 create mode 100644 scripts/lib/mic/plugins/hook/empty_hook.py
 create mode 100644 scripts/lib/mic/plugins/imager/fs_plugin.py
 create mode 100644 scripts/lib/mic/plugins/imager/livecd_plugin.py
 create mode 100644 scripts/lib/mic/plugins/imager/liveusb_plugin.py
 create mode 100644 scripts/lib/mic/plugins/imager/loop_plugin.py
 create mode 100644 scripts/lib/mic/plugins/imager/raw_plugin.py
 create mode 100644 scripts/lib/mic/rt_util.py
 create mode 100644 scripts/lib/mic/test
 create mode 100644 scripts/lib/mic/utils/BmapCreate.py
 create mode 100644 scripts/lib/mic/utils/Fiemap.py
 create mode 100644 scripts/lib/mic/utils/__init__.py
 create mode 100644 scripts/lib/mic/utils/cmdln.py
 create mode 100644 scripts/lib/mic/utils/errors.py
 create mode 100644 scripts/lib/mic/utils/fs_related.py
 create mode 100644 scripts/lib/mic/utils/gpt_parser.py
 create mode 100644 scripts/lib/mic/utils/grabber.py
 create mode 100644 scripts/lib/mic/utils/misc.py
 create mode 100644 scripts/lib/mic/utils/partitionedfs.py
 create mode 100644 scripts/lib/mic/utils/proxy.py
 create mode 100644 scripts/lib/mic/utils/rpmmisc.py
 create mode 100644 scripts/lib/mic/utils/runner.py
 create mode 100644 scripts/yocto-image.conf

[
Patch contents have been removed - too large to post.  You can see
the patch contents here:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=tzanussi/wic-v1&id=734affa7ac65895aa9329a04cb31782c8495f810
]
Otavio Salvador - Sept. 27, 2013, 2:01 p.m.
Hello Tom,

On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
<tom.zanussi@linux.intel.com> wrote:
> Initial implementation of the 'wic' command.
>
> The 'wic' command generates partitioned images from existing
> OpenEmbedded build artifacts.  Image generation is driven by
> partitioning commands contained in an 'Openembedded kickstart' (.wks)
> file specified either directly on the command-line or as one of a
> selection of canned .wks files (see 'wic list images').  When applied
> to a given set of build artifacts, the result is an image or set of
> images that can be directly written onto media and used on a
> particular system.
>
> 'wic' is based loosely on the 'mic' (Meego Image Creator) framework,
> but heavily modified to make direct use of OpenEmbedded build
> artifacts instead of package installation and configuration, things
> already incorporated int the OE artifacts.
>
> The name 'wic' comes from 'oeic' with the 'oe' diphthong promoted to
> the letter 'w', because 'oeic' is impossible to remember or pronounce.
>
> This covers the mechanics of invoking and providing help for the
> command and sub-commands; it contains hooks for future commits to
> connect with the actual functionality, once implemented.
>
> Help is integrated into the 'wic' command - see that for details on
> usage.
>
> Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>

Could you please elaborate why to make a new command instead of using
the class system?
tom.zanussi@linux.intel.com - Sept. 27, 2013, 2:21 p.m.
Hi Otavio,

On Fri, 2013-09-27 at 11:01 -0300, Otavio Salvador wrote:
> Hello Tom,
> 
> On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
> <tom.zanussi@linux.intel.com> wrote:
> > Initial implementation of the 'wic' command.
> >
> > The 'wic' command generates partitioned images from existing
> > OpenEmbedded build artifacts.  Image generation is driven by
> > partitioning commands contained in an 'Openembedded kickstart' (.wks)
> > file specified either directly on the command-line or as one of a
> > selection of canned .wks files (see 'wic list images').  When applied
> > to a given set of build artifacts, the result is an image or set of
> > images that can be directly written onto media and used on a
> > particular system.
> >
> > 'wic' is based loosely on the 'mic' (Meego Image Creator) framework,
> > but heavily modified to make direct use of OpenEmbedded build
> > artifacts instead of package installation and configuration, things
> > already incorporated int the OE artifacts.
> >
> > The name 'wic' comes from 'oeic' with the 'oe' diphthong promoted to
> > the letter 'w', because 'oeic' is impossible to remember or pronounce.
> >
> > This covers the mechanics of invoking and providing help for the
> > command and sub-commands; it contains hooks for future commits to
> > connect with the actual functionality, once implemented.
> >
> > Help is integrated into the 'wic' command - see that for details on
> > usage.
> >
> > Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
> 
> Could you please elaborate why to make a new command instead of using
> the class system?
> 

This isn't an either/or thing - the initial requirements were that the
overall deployment effort end up being something that would be usable
both from an external tool as well as from within the class system.

This just happens to be the initial (easier) part of that, the external
tool, and I expect in 1.6 to be doing a lot of the harder part,
integration with the build system.

The most important part, I think, is that this provides a high-level
user-oriented 'language' (the kickstart files) that users can use to
define custom images, rather than having to muck around in class files
or variable settings, or write specialized scripts such as mkefidisk.sh
for example.

Making that available from a standalone tool such as 'wic' is
straightforward, doing the same from within the build system will
require more thought and work, but that's what I'm hoping to do in
1.6...

Tom
David Nyström - Sept. 28, 2013, 12:17 p.m.
On 09/27/2013 04:21 PM, Tom Zanussi wrote:
> Hi Otavio,
>
> On Fri, 2013-09-27 at 11:01 -0300, Otavio Salvador wrote:
>> Hello Tom,
>>
>> On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
>> <tom.zanussi@linux.intel.com> wrote:
>>> Initial implementation of the 'wic' command.
>>>
><snip>
>> Could you please elaborate why to make a new command instead of using
>> the class system?
>>
>
> This isn't an either/or thing - the initial requirements were that the
> overall deployment effort end up being something that would be usable
> both from an external tool as well as from within the class system.

What do you mean when you say "within the class system" here ?
* A tool using only (kickstart for image cfg, partitioning et.c.) + 
(tmp/deploy/ipk|rpm|deb) as input data for image creation ?

Just my five cents,

I would like to see reproducible image creation from both the bitbake/OE 
build env and the nativesdk SDK build env.
This would require a common interface for input distribution data, It 
naturally feels like this interface should be the package repository.
i.e. if X is not packaged as class-target, it can't be included on the 
generated image.
Also, if X is required to generate the image, it should be packaged as 
class-nativesdk.

afaict, the standalone wic tool uses a hybrid approach, using 
OpenEmbedded build artifacts + a package repository as input for rootfs 
generation.
What is the long term plan for wic in regards to the above ?

Br,
David

> This just happens to be the initial (easier) part of that, the external
> tool, and I expect in 1.6 to be doing a lot of the harder part,
> integration with the build system.


> The most important part, I think, is that this provides a high-level
> user-oriented 'language' (the kickstart files) that users can use to
> define custom images, rather than having to muck around in class files
> or variable settings, or write specialized scripts such as mkefidisk.sh
> for example.
>
> Making that available from a standalone tool such as 'wic' is
> straightforward, doing the same from within the build system will
> require more thought and work, but that's what I'm hoping to do in
> 1.6...



>
> Tom
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
tom.zanussi@linux.intel.com - Sept. 30, 2013, 1:11 a.m.
On Sat, 2013-09-28 at 14:17 +0200, David Nyström wrote:
> On 09/27/2013 04:21 PM, Tom Zanussi wrote:
> > Hi Otavio,
> >
> > On Fri, 2013-09-27 at 11:01 -0300, Otavio Salvador wrote:
> >> Hello Tom,
> >>
> >> On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
> >> <tom.zanussi@linux.intel.com> wrote:
> >>> Initial implementation of the 'wic' command.
> >>>
> ><snip>
> >> Could you please elaborate why to make a new command instead of using
> >> the class system?
> >>
> >
> > This isn't an either/or thing - the initial requirements were that the
> > overall deployment effort end up being something that would be usable
> > both from an external tool as well as from within the class system.
> 
> What do you mean when you say "within the class system" here ?
> * A tool using only (kickstart for image cfg, partitioning et.c.) + 
> (tmp/deploy/ipk|rpm|deb) as input data for image creation ?
> 

For me, 'within the class system' just covers what I originally outlined
in the analysis (Bug 3847 - New partitioning description and tooling),
basically providing a more flexible alternative/eventual replacement for
things like boot-directdisk.class/image-vmdk.bbclass and mkefidisk.sh,
and the IMAGE_FSTYPEs mechanism used all over the place for creating
custom images.  At this point, that's the scope of it for me - I'm not
even sure yet where the kickstart interface will hook into things or
exactly how it will presented to users - that's for 1.6.  What I do know
is that the current wic functionality should be sufficient and that it's
pretty well modularized - the 'wic' command itself is just a thin
wrapper that gathers info from the user e.g. paths to the build
artifacts and a kickstart file and invokes the image creator through a
well-defined entry point.

For current work (and presumably also when integrated into the class
system), I'm directly using the target rootfs - my first versions
actually just used the rootfs image e.g. xx.ext3, but because I needed
access to the filesystem for e.g. generating the fstab, and can't do a
loop mount because it requires root, that's what the tool uses.

Using tmp/deploy/ipk|rpm|deb as input for image creation is a step
beyond what I had scoped out for this immediate task - things like image
configuration and package selection from package repositories/feeds are
things I believe other people are interested in; using kickstart/mic as
the underlying infrastructure for those additional capabilities at first
glance seems that it might also make sense in those cases, since those
things are already implemented in some form, but I haven't looked deeply
and that's probably something for those who have the need/interest to
determine...

> Just my five cents,
> 
> I would like to see reproducible image creation from both the bitbake/OE 
> build env and the nativesdk SDK build env.
> This would require a common interface for input distribution data, It 
> naturally feels like this interface should be the package repository.
> i.e. if X is not packaged as class-target, it can't be included on the 
> generated image.
> Also, if X is required to generate the image, it should be packaged as 
> class-nativesdk.
> 
> afaict, the standalone wic tool uses a hybrid approach, using 
> OpenEmbedded build artifacts + a package repository as input for rootfs 
> generation.

Yeah, that's what the tool currently uses, but as you say, some more
thought towards a common interface needs to be done.  I originally had
this for the --source param to the 'part commmand': 

parser.add_option("-s", "--source", action = "append",
                  default = True, help = "define additional wks sources
[sourcename=/path/to/source], referenced in .wks part commands as
--source sourcename")

For the current wic code, I punted on trying to come up with something
more general purpose like this (and as you can see it's not really
general purpose, in my case just allowing multiple filesystem sources
and not very well thought out at that), and simply defined 'rootfs' to
mean the entire /rootfs passed in using the -r option.

I think there needs to be a way to specify arbitrary (user-defined as
well) sources and those sources could really be anything, including
package repositories in whatever form you need them to be.  I don't have
the answer at the moment, just that there needs to be a generic
mechanism for providing and making use of arbitrary sources - any input
you could provide for the use cases it sounds like you've given more
thought to handling would help move that along...

Thanks,

Tom

> What is the long term plan for wic in regards to the above ?
> 
> Br,
> David
> 
> > This just happens to be the initial (easier) part of that, the external
> > tool, and I expect in 1.6 to be doing a lot of the harder part,
> > integration with the build system.
> 
> 
> > The most important part, I think, is that this provides a high-level
> > user-oriented 'language' (the kickstart files) that users can use to
> > define custom images, rather than having to muck around in class files
> > or variable settings, or write specialized scripts such as mkefidisk.sh
> > for example.
> >
> > Making that available from a standalone tool such as 'wic' is
> > straightforward, doing the same from within the build system will
> > require more thought and work, but that's what I'm hoping to do in
> > 1.6...
> 
> 
> 
> >
> > Tom
> >
> >
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
>
David Nyström - Sept. 30, 2013, 12:58 p.m.
On 09/30/2013 03:11 AM, Tom Zanussi wrote:
> On Sat, 2013-09-28 at 14:17 +0200, David Nyström wrote:
>> On 09/27/2013 04:21 PM, Tom Zanussi wrote:
>>> Hi Otavio,
>>>
>>> On Fri, 2013-09-27 at 11:01 -0300, Otavio Salvador wrote:
>>>> Hello Tom,
>>>>
>>>> On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
>>>> <tom.zanussi@linux.intel.com> wrote:
>>>>> Initial implementation of the 'wic' command.
>>>>>
>>> <snip>
>>>> Could you please elaborate why to make a new command instead of using
>>>> the class system?
>>>>
>>>
>>> This isn't an either/or thing - the initial requirements were that the
>>> overall deployment effort end up being something that would be usable
>>> both from an external tool as well as from within the class system.
>>
>> What do you mean when you say "within the class system" here ?
>> * A tool using only (kickstart for image cfg, partitioning et.c.) +
>> (tmp/deploy/ipk|rpm|deb) as input data for image creation ?
>>
>
> For me, 'within the class system' just covers what I originally outlined
> in the analysis (Bug 3847 - New partitioning description and tooling),
> basically providing a more flexible alternative/eventual replacement for
> things like boot-directdisk.class/image-vmdk.bbclass and mkefidisk.sh,
> and the IMAGE_FSTYPEs mechanism used all over the place for creating
> custom images.  At this point, that's the scope of it for me - I'm not
> even sure yet where the kickstart interface will hook into things or
> exactly how it will presented to users - that's for 1.6.  What I do know
> is that the current wic functionality should be sufficient and that it's
> pretty well modularized - the 'wic' command itself is just a thin
> wrapper that gathers info from the user e.g. paths to the build
> artifacts and a kickstart file and invokes the image creator through a
> well-defined entry point.
>
> For current work (and presumably also when integrated into the class
> system), I'm directly using the target rootfs - my first versions
> actually just used the rootfs image e.g. xx.ext3, but because I needed
> access to the filesystem for e.g. generating the fstab, and can't do a
> loop mount because it requires root, that's what the tool uses.
>
> Using tmp/deploy/ipk|rpm|deb as input for image creation is a step
> beyond what I had scoped out for this immediate task - things like image
> configuration and package selection from package repositories/feeds are
> things I believe other people are interested in; using kickstart/mic as
> the underlying infrastructure for those additional capabilities at first
> glance seems that it might also make sense in those cases, since those
> things are already implemented in some form, but I haven't looked deeply
> and that's probably something for those who have the need/interest to
> determine...

I started hacking on a simple test to evaluate dependencies et.c. for 
SDK rootfs + image generation from a repo, similiar to "mic-chroot".

https://github.com/nysan/rootfs-sandbox , dep: (oe-core master-next)

some postinst hooks are OE dependent and require special attention, and 
there is also the need to expand the nativesdk with some postinst 
dependencies to avoid host contamination. et.c.

When I saw the wic/kickstart patches, my hope was that we could, long 
term, share the codebase between the nativeSDK 'mic-like-interface', and 
bitbake/OE 'mic-like-interface', since functionality probably will be 
overlapping.

The nativeSDK 'mic-like-interface' would naturally only have the package 
repo + wks as input data.

Br,
David

>> Just my five cents,
>>
>> I would like to see reproducible image creation from both the bitbake/OE
>> build env and the nativesdk SDK build env.
>> This would require a common interface for input distribution data, It
>> naturally feels like this interface should be the package repository.
>> i.e. if X is not packaged as class-target, it can't be included on the
>> generated image.
>> Also, if X is required to generate the image, it should be packaged as
>> class-nativesdk.
>>
>> afaict, the standalone wic tool uses a hybrid approach, using
>> OpenEmbedded build artifacts + a package repository as input for rootfs
>> generation.
>
> Yeah, that's what the tool currently uses, but as you say, some more
> thought towards a common interface needs to be done.  I originally had
> this for the --source param to the 'part commmand':
>
> parser.add_option("-s", "--source", action = "append",
>                    default = True, help = "define additional wks sources
> [sourcename=/path/to/source], referenced in .wks part commands as
> --source sourcename")
>
> For the current wic code, I punted on trying to come up with something
> more general purpose like this (and as you can see it's not really
> general purpose, in my case just allowing multiple filesystem sources
> and not very well thought out at that), and simply defined 'rootfs' to
> mean the entire /rootfs passed in using the -r option.
>
> I think there needs to be a way to specify arbitrary (user-defined as
> well) sources and those sources could really be anything, including
> package repositories in whatever form you need them to be.  I don't have
> the answer at the moment, just that there needs to be a generic
> mechanism for providing and making use of arbitrary sources - any input
> you could provide for the use cases it sounds like you've given more
> thought to handling would help move that along...
>
> Thanks,
>
> Tom
>
>> What is the long term plan for wic in regards to the above ?
>>
>> Br,
>> David
>>
>>> This just happens to be the initial (easier) part of that, the external
>>> tool, and I expect in 1.6 to be doing a lot of the harder part,
>>> integration with the build system.
>>
>>
>>> The most important part, I think, is that this provides a high-level
>>> user-oriented 'language' (the kickstart files) that users can use to
>>> define custom images, rather than having to muck around in class files
>>> or variable settings, or write specialized scripts such as mkefidisk.sh
>>> for example.
>>>
>>> Making that available from a standalone tool such as 'wic' is
>>> straightforward, doing the same from within the build system will
>>> require more thought and work, but that's what I'm hoping to do in
>>> 1.6...
>>
>>
>>
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>
>
>
tom.zanussi@linux.intel.com - Sept. 30, 2013, 3:15 p.m.
On Mon, 2013-09-30 at 14:58 +0200, David Nyström wrote:
> On 09/30/2013 03:11 AM, Tom Zanussi wrote:
> > On Sat, 2013-09-28 at 14:17 +0200, David Nyström wrote:
> >> On 09/27/2013 04:21 PM, Tom Zanussi wrote:
> >>> Hi Otavio,
> >>>
> >>> On Fri, 2013-09-27 at 11:01 -0300, Otavio Salvador wrote:
> >>>> Hello Tom,
> >>>>
> >>>> On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
> >>>> <tom.zanussi@linux.intel.com> wrote:
> >>>>> Initial implementation of the 'wic' command.
> >>>>>
> >>> <snip>
> >>>> Could you please elaborate why to make a new command instead of using
> >>>> the class system?
> >>>>
> >>>
> >>> This isn't an either/or thing - the initial requirements were that the
> >>> overall deployment effort end up being something that would be usable
> >>> both from an external tool as well as from within the class system.
> >>
> >> What do you mean when you say "within the class system" here ?
> >> * A tool using only (kickstart for image cfg, partitioning et.c.) +
> >> (tmp/deploy/ipk|rpm|deb) as input data for image creation ?
> >>
> >
> > For me, 'within the class system' just covers what I originally outlined
> > in the analysis (Bug 3847 - New partitioning description and tooling),
> > basically providing a more flexible alternative/eventual replacement for
> > things like boot-directdisk.class/image-vmdk.bbclass and mkefidisk.sh,
> > and the IMAGE_FSTYPEs mechanism used all over the place for creating
> > custom images.  At this point, that's the scope of it for me - I'm not
> > even sure yet where the kickstart interface will hook into things or
> > exactly how it will presented to users - that's for 1.6.  What I do know
> > is that the current wic functionality should be sufficient and that it's
> > pretty well modularized - the 'wic' command itself is just a thin
> > wrapper that gathers info from the user e.g. paths to the build
> > artifacts and a kickstart file and invokes the image creator through a
> > well-defined entry point.
> >
> > For current work (and presumably also when integrated into the class
> > system), I'm directly using the target rootfs - my first versions
> > actually just used the rootfs image e.g. xx.ext3, but because I needed
> > access to the filesystem for e.g. generating the fstab, and can't do a
> > loop mount because it requires root, that's what the tool uses.
> >
> > Using tmp/deploy/ipk|rpm|deb as input for image creation is a step
> > beyond what I had scoped out for this immediate task - things like image
> > configuration and package selection from package repositories/feeds are
> > things I believe other people are interested in; using kickstart/mic as
> > the underlying infrastructure for those additional capabilities at first
> > glance seems that it might also make sense in those cases, since those
> > things are already implemented in some form, but I haven't looked deeply
> > and that's probably something for those who have the need/interest to
> > determine...
> 
> I started hacking on a simple test to evaluate dependencies et.c. for 
> SDK rootfs + image generation from a repo, similiar to "mic-chroot".
> 
> https://github.com/nysan/rootfs-sandbox , dep: (oe-core master-next)
> 
> some postinst hooks are OE dependent and require special attention, and 
> there is also the need to expand the nativesdk with some postinst 
> dependencies to avoid host contamination. et.c.
> 
> When I saw the wic/kickstart patches, my hope was that we could, long 
> term, share the codebase between the nativeSDK 'mic-like-interface', and 
> bitbake/OE 'mic-like-interface', since functionality probably will be 
> overlapping.
> 
> The nativeSDK 'mic-like-interface' would naturally only have the package 
> repo + wks as input data.
> 

Looking at your code, it definitely seems there could be a good fit, if
I understand it correctly.

As I understand it, you allow users to interactively specify packages to
include in an image and then generate the image.

If I were going to take a first stab at using the wic infrastructure for
this, I'd probably have the interactive tool start off by having the
user specify a kickstart file and, instead of a pointer to the rootfs as
-r does with 'wic', a pointer to the package repo.

The initial kickstart file would have an initial set of packages that
would automatically be added, using the standard kickstart package
selection syntax e.g.

%packages
@packagegroup-core-boot
%end

http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_3._Package_Selection

Your interactive wrapper would allow the user to select and add packages
from the package repo, which would be dynamically added to the %packages
section of the kickstart file.

Once done, all the packages selected to go into the image would generate
the rootfs at an internally known temporary location that would just be
passed to the existing image creation code in place of the -r option,
which is a previously solved problem ;-)

Well, there would be a lot more details involved but at a high level,
that's one way I could see it working...

Tom


> Br,
> David
> 
> >> Just my five cents,
> >>
> >> I would like to see reproducible image creation from both the bitbake/OE
> >> build env and the nativesdk SDK build env.
> >> This would require a common interface for input distribution data, It
> >> naturally feels like this interface should be the package repository.
> >> i.e. if X is not packaged as class-target, it can't be included on the
> >> generated image.
> >> Also, if X is required to generate the image, it should be packaged as
> >> class-nativesdk.
> >>
> >> afaict, the standalone wic tool uses a hybrid approach, using
> >> OpenEmbedded build artifacts + a package repository as input for rootfs
> >> generation.
> >
> > Yeah, that's what the tool currently uses, but as you say, some more
> > thought towards a common interface needs to be done.  I originally had
> > this for the --source param to the 'part commmand':
> >
> > parser.add_option("-s", "--source", action = "append",
> >                    default = True, help = "define additional wks sources
> > [sourcename=/path/to/source], referenced in .wks part commands as
> > --source sourcename")
> >
> > For the current wic code, I punted on trying to come up with something
> > more general purpose like this (and as you can see it's not really
> > general purpose, in my case just allowing multiple filesystem sources
> > and not very well thought out at that), and simply defined 'rootfs' to
> > mean the entire /rootfs passed in using the -r option.
> >
> > I think there needs to be a way to specify arbitrary (user-defined as
> > well) sources and those sources could really be anything, including
> > package repositories in whatever form you need them to be.  I don't have
> > the answer at the moment, just that there needs to be a generic
> > mechanism for providing and making use of arbitrary sources - any input
> > you could provide for the use cases it sounds like you've given more
> > thought to handling would help move that along...
> >
> > Thanks,
> >
> > Tom
> >
> >> What is the long term plan for wic in regards to the above ?
> >>
> >> Br,
> >> David
> >>
> >>> This just happens to be the initial (easier) part of that, the external
> >>> tool, and I expect in 1.6 to be doing a lot of the harder part,
> >>> integration with the build system.
> >>
> >>
> >>> The most important part, I think, is that this provides a high-level
> >>> user-oriented 'language' (the kickstart files) that users can use to
> >>> define custom images, rather than having to muck around in class files
> >>> or variable settings, or write specialized scripts such as mkefidisk.sh
> >>> for example.
> >>>
> >>> Making that available from a standalone tool such as 'wic' is
> >>> straightforward, doing the same from within the build system will
> >>> require more thought and work, but that's what I'm hoping to do in
> >>> 1.6...
> >>
> >>
> >>
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>>
> >>
> >
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Patch

diff --git a/scripts/lib/image/__init__.py b/scripts/lib/image/__init__.py
new file mode 100644
index 0000000..1ff814e
--- /dev/null
+++ b/scripts/lib/image/__init__.py
@@ -0,0 +1,22 @@ 
+#
+# OpenEmbedded Image tools library
+#
+# Copyright (c) 2013, Intel Corporation.
+# All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# AUTHORS
+# Tom Zanussi <tom.zanussi (at] linux.intel.com>
+#
diff --git a/scripts/lib/image/engine.py b/scripts/lib/image/engine.py
new file mode 100644
index 0000000..a9b530c
--- /dev/null
+++ b/scripts/lib/image/engine.py
@@ -0,0 +1,256 @@ 
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# Copyright (c) 2013, Intel Corporation.
+# All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# DESCRIPTION
+
+# This module implements the image creation engine used by 'wic' to
+# create images.  The engine parses through the OpenEmbedded kickstart
+# (wks) file specified and generates images that can then be directly
+# written onto media.
+#
+# AUTHORS
+# Tom Zanussi <tom.zanussi (at] linux.intel.com>
+#
+
+import os
+import sys
+from abc import ABCMeta, abstractmethod
+import shlex
+import json
+import subprocess
+import shutil
+
+import os, sys, errno
+
+
+def verify_build_env():
+    """
+    Verify that the build environment is sane.
+
+    Returns True if it is, false otherwise
+    """
+    try:
+        builddir = os.environ["BUILDDIR"]
+    except KeyError:
+        print "BUILDDIR not found, exiting. (Did you forget to source oe-init-build-env?)"
+        sys.exit(1)
+
+    return True
+
+
+def get_line_val(line, key):
+    """
+    Extract the value from the VAR="val" string
+    """
+    if line.startswith(key + "="):
+        stripped_line = line.split('=')[1]
+        stripped_line = stripped_line.replace('\"', '')
+        return stripped_line
+    return None
+
+
+def find_artifacts(image_name):
+    """
+    Gather the build artifacts for the current image (the image_name
+    e.g. core-image-minimal) for the current MACHINE set in local.conf
+    """
+    bitbake_env_cmd = "bitbake -e %s" % image_name
+    rc, bitbake_env_lines = exec_cmd(bitbake_env_cmd)
+    if rc != 0:
+        print "Couldn't get '%s' output, exiting." % bitbake_env_cmd
+        sys.exit(1)
+
+    for line in bitbake_env_lines.split('\n'):
+        if (get_line_val(line, "IMAGE_ROOTFS")):
+            rootfs_dir = get_line_val(line, "IMAGE_ROOTFS")
+            continue
+        if (get_line_val(line, "STAGING_KERNEL_DIR")):
+            kernel_dir = get_line_val(line, "STAGING_KERNEL_DIR")
+            continue
+        if (get_line_val(line, "HDDDIR")):
+            hdddir = get_line_val(line, "HDDDIR")
+            continue
+        if (get_line_val(line, "STAGING_DATADIR")):
+            staging_data_dir = get_line_val(line, "STAGING_DATADIR")
+            continue
+        if (get_line_val(line, "STAGING_DIR_NATIVE")):
+            native_sysroot = get_line_val(line, "STAGING_DIR_NATIVE")
+            continue
+
+    return (rootfs_dir, kernel_dir, hdddir, staging_data_dir, native_sysroot)
+
+
+CANNED_IMAGE_DIR = "lib/image/canned-wks" # relative to scripts
+
+def find_canned_image(scripts_path, wks_file):
+    """
+    Find a .wks file with the given name in the canned files dir.
+
+    Return False if not found
+    """
+    canned_wks_dir = os.path.join(scripts_path, CANNED_IMAGE_DIR)
+
+    for root, dirs, files in os.walk(canned_wks_dir):
+        for file in files:
+            if file.endswith("~") or file.endswith("#"):
+                continue
+            if file.endswith(".wks") and wks_file + ".wks" == file:
+                fullpath = os.path.join(canned_wks_dir, file)
+                return fullpath
+    return None
+
+
+def list_canned_images(scripts_path):
+    """
+    List the .wks files in the canned image dir, minus the extension.
+    """
+    canned_wks_dir = os.path.join(scripts_path, CANNED_IMAGE_DIR)
+
+    for root, dirs, files in os.walk(canned_wks_dir):
+        for file in files:
+            if file.endswith("~") or file.endswith("#"):
+                continue
+            if file.endswith(".wks"):
+                fullpath = os.path.join(canned_wks_dir, file)
+                f = open(fullpath, "r")
+                lines = f.readlines()
+                for line in lines:
+                    desc = ""
+                    idx = line.find("short-description:")
+                    if idx != -1:
+                        desc = line[idx + len("short-description:"):].strip()
+                        break
+                basename = os.path.splitext(file)[0]
+                print "  %s\t\t%s" % (basename, desc)
+
+
+def list_canned_image_help(scripts_path, fullpath):
+    """
+    List the help and params in the specified canned image.
+    """
+    canned_wks_dir = os.path.join(scripts_path, CANNED_IMAGE_DIR)
+
+    f = open(fullpath, "r")
+    lines = f.readlines()
+    found = False
+    for line in lines:
+        if not found:
+            idx = line.find("long-description:")
+            if idx != -1:
+                print
+                print line[idx + len("long-description:"):].strip()
+                found = True
+            continue
+        if not line.strip():
+            break
+        idx = line.find("#")
+        if idx != -1:
+            print line[idx + len("#:"):].rstrip()
+        else:
+            break
+
+
+def wic_create(args, wks_file, rootfs_dir, bootimg_dir, kernel_dir,
+               native_sysroot, hdddir, staging_data_dir, scripts_path,
+               image_output_dir, properties_file, properties=None):
+    """
+    Create image
+
+    wks_file - user-defined OE kickstart file
+    rootfs_dir - absolute path to the build's /rootfs dir
+    bootimg_dir - absolute path to the build's boot artifacts directory
+    kernel_dir - absolute path to the build's kernel directory
+    native_sysroot - absolute path to the build's native sysroots dir
+    hdddir - absolute path to the build's HDDDIR dir
+    staging_data_dir - absolute path to the build's STAGING_DATA_DIR dir
+    scripts_path - absolute path to /scripts dir
+    image_output_dir - dirname to create for image
+    properties_file - use values from this file if nonempty i.e no prompting
+    properties - use values from this string if nonempty i.e no prompting
+
+    Normally, the values for the build artifacts values are determined
+    by 'wic -e' from the output of the 'bitbake -e' command given an
+    image name e.g. 'core-image-minimal' and a given machine set in
+    local.conf.  If that's the case, the variables get the following
+    values from the output of 'bitbake -e':
+
+    rootfs_dir:        IMAGE_ROOTFS
+    kernel_dir:        STAGING_KERNEL_DIR
+    native_sysroot:    STAGING_DIR_NATIVE
+    hdddir:            HDDDIR
+    staging_data_dir:  STAGING_DATA_DIR
+
+    In the above case, bootimg_dir remains unset and the image
+    creation code determines which of the passed-in directories to
+    use.
+
+    In the case where the values are passed in explicitly i.e 'wic -e'
+    is not used but rather the individual 'wic' options are used to
+    explicitly specify these values, hdddir and staging_data_dir will
+    be unset, but bootimg_dir must be explicit i.e. explicitly set to
+    either hdddir or staging_data_dir, depending on the image being
+    generated.  The other values (rootfs_dir, kernel_dir, and
+    native_sysroot) correspond to the same values found above via
+    'bitbake -e').
+
+    """
+    try:
+        oe_builddir = os.environ["BUILDDIR"]
+    except KeyError:
+        print "BUILDDIR not found, exiting. (Did you forget to source oe-init-build-env?)"
+        sys.exit(1)
+
+
+def wic_list(args, scripts_path, properties_file):
+    """
+    Print the complete list of properties defined by the image, or the
+    possible values for a particular image property.
+    """
+    if len(args) < 1:
+        return False
+
+    if len(args) == 1:
+        if args[0] == "images":
+            list_canned_images(scripts_path)
+            return True
+        elif args[0] == "properties":
+            return True
+        else:
+            return False
+
+    if len(args) == 2:
+        if args[0] == "properties":
+            wks_file = args[1]
+            print "print properties contained in wks file: %s" % wks_file
+            return True
+        elif args[0] == "property":
+            print "print property values for property: %s" % args[1]
+            return True
+        elif args[1] == "help":
+            wks_file = args[0]
+            fullpath = find_canned_image(scripts_path, wks_file)
+            if not fullpath:
+                print "No image named %s found, exiting.  (Use 'wic list images' to list available images, or specify a fully-qualified OE kickstart (.wks) filename)\n" % wks_file
+                sys.exit(1)
+            list_canned_image_help(scripts_path, fullpath)
+            return True
+        else:
+            return False
+
+    return False
diff --git a/scripts/lib/image/help.py b/scripts/lib/image/help.py
new file mode 100644
index 0000000..cb3112c
--- /dev/null
+++ b/scripts/lib/image/help.py
@@ -0,0 +1,311 @@ 
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# Copyright (c) 2013, Intel Corporation.
+# All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# DESCRIPTION
+# This module implements some basic help invocation functions along
+# with the bulk of the help topic text for the OE Core Image Tools.
+#
+# AUTHORS
+# Tom Zanussi <tom.zanussi (at] linux.intel.com>
+#
+
+import subprocess
+import logging
+
+
+def subcommand_error(args):
+    logging.info("invalid subcommand %s" % args[0])
+
+
+def display_help(subcommand, subcommands):
+    """
+    Display help for subcommand.
+    """
+    if subcommand not in subcommands:
+        return False
+
+    help = subcommands.get(subcommand, subcommand_error)[2]
+    pager = subprocess.Popen('less', stdin=subprocess.PIPE)
+    pager.communicate(help)
+
+    return True
+
+
+def wic_help(args, usage_str, subcommands):
+    """
+    Subcommand help dispatcher.
+    """
+    if len(args) == 1 or not display_help(args[1], subcommands):
+        print(usage_str)
+
+
+def invoke_subcommand(args, parser, main_command_usage, subcommands):
+    """
+    Dispatch to subcommand handler borrowed from combo-layer.
+    Should use argparse, but has to work in 2.6.
+    """
+    if not args:
+        logging.error("No subcommand specified, exiting")
+        parser.print_help()
+    elif args[0] == "help":
+        wic_help(args, main_command_usage, subcommands)
+    elif args[0] not in subcommands:
+        logging.error("Unsupported subcommand %s, exiting\n" % (args[0]))
+        parser.print_help()
+    else:
+        usage = subcommands.get(args[0], subcommand_error)[1]
+        subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
+
+
+##
+# wic help and usage strings
+##
+
+wic_usage = """
+
+ Create a customized OpenEmbedded image
+
+ usage: wic [--version] [--help] COMMAND [ARGS]
+
+ Current 'wic' commands are:
+    create            Create a new OpenEmbedded image
+    list              List available values for options and image properties
+
+ See 'wic help COMMAND' for more information on a specific command.
+"""
+
+wic_help_usage = """
+
+ usage: wic help <subcommand>
+
+ This command displays detailed help for the specified subcommand.
+"""
+
+wic_create_usage = """
+
+ Create a new OpenEmbedded image
+
+ usage: wic create <wks file or image name> [-o <DIRNAME> | --outdir <DIRNAME>]
+            [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>]
+            [-e | --image-name] [-r, --rootfs-dir] [-b, --bootimg-dir]
+            [-k, --kernel-dir] [-n, --native-sysroot] [-s, --skip-build-check]
+
+ This command creates an OpenEmbedded image based on the 'OE kickstart
+ commands' found in the <wks file>.
+
+ The -o option can be used to place the image in a directory with a
+ different name and location.
+
+ See 'wic help create' for more detailed instructions.
+"""
+
+wic_create_help = """
+
+NAME
+    wic create - Create a new OpenEmbedded image
+
+SYNOPSIS
+    wic create <wks file or image name> [-o <DIRNAME> | --outdir <DIRNAME>]
+        [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>]
+        [-e | --image-name] [-r, --rootfs-dir] [-b, --bootimg-dir]
+        [-k, --kernel-dir] [-n, --native-sysroot] [-s, --skip-build-check]
+
+DESCRIPTION
+    This command creates an OpenEmbedded image based on the 'OE
+    kickstart commands' found in the <wks file>.
+
+    In order to do this, wic needs to know the locations of the
+    various build artifacts required to build the image.
+
+    Users can explicitly specify the build artifact locations using
+    the -r, -b, -k, and -n options.  See below for details on where
+    the corresponding artifacts are typically found in a normal
+    OpenEmbedded build.
+
+    Alternatively, users can use the -e option to have 'mic' determine
+    those locations for a given image.  If the -e option is used, the
+    user needs to have set the appropriate MACHINE variable in
+    local.conf, and have sourced the build environment.
+
+    The -e option is used to specify the name of the image to use the
+    artifacts from e.g. core-image-sato.
+
+    The -r option is used to specify the path to the /rootfs dir to
+    use as the .wks rootfs source.
+
+    The -b option is used to specify the path to the dir containing
+    the boot artifacts (e.g. /EFI or /syslinux dirs) to use as the
+    .wks bootimg source.
+
+    The -k option is used to specify the path to the dir containing
+    the kernel to use in the .wks bootimg.
+
+    The -n option is used to specify the path to the native sysroot
+    containing the tools to use to build the image.
+
+    The -s option is used to skip the build check.  The build check is
+    a simple sanity check used to determine whether the user has
+    sourced the build environment so that the -e option can operate
+    correctly.  If the user has specified the build artifact locations
+    explicitly, 'wic' assumes the user knows what he or she is doing
+    and skips the build check.
+
+    When 'wic -e' is used, the locations for the build artifacts
+    values are determined by 'wic -e' from the output of the 'bitbake
+    -e' command given an image name e.g. 'core-image-minimal' and a
+    given machine set in local.conf.  In that case, the image is
+    created as if the following 'bitbake -e' variables were used:
+
+    -r:        IMAGE_ROOTFS
+    -k:        STAGING_KERNEL_DIR
+    -n:        STAGING_DIR_NATIVE
+    -b:        HDDDIR and STAGING_DATA_DIR (handlers decide which to use)
+
+    If 'wic -e' is not used, the user needs to select the appropriate
+    value for -b (as well as -r, -k, and -n).
+
+    The -o option can be used to place the image in a directory with a
+    different name and location.
+
+    As an alternative to the wks file, the image-specific properties
+    that define the values that will be used to generate a particular
+    image can be specified on the command-line using the -i option and
+    supplying a JSON object consisting of the set of name:value pairs
+    needed by image creation.
+
+    The set of properties available for a given image type can be
+    listed using the 'wic list' command.
+"""
+
+wic_list_usage = """
+
+ List available OpenEmbedded image properties and values
+
+ usage: wic list images
+        wic list <image> help
+        wic list properties
+        wic list properties <wks file>
+        wic list property <property>
+                [-o <JSON PROPERTY FILE> | --outfile <JSON PROPERTY_FILE>]
+
+ This command enumerates the set of available canned images as well as
+ help for those images.  It also can be used to enumerate the complete
+ set of possible values for a specified option or property needed by
+ the image creation process.
+
+ The first form enumerates all the available 'canned' images.
+
+ The second form lists the detailed help information for a specific
+ 'canned' image.
+
+ The third form enumerates all the possible values that exist and can
+ be specified in an OE kickstart (wks) file.
+
+ The fourth form enumerates all the possible options that exist for
+ the set of properties specified in a given OE kickstart (ks) file.
+
+ The final form enumerates all the possible values that exist and can
+ be specified for any given OE kickstart (wks) property.
+
+ See 'wic help list' for more details.
+"""
+
+wic_list_help = """
+
+NAME
+    wic list - List available OpenEmbedded image properties and values
+
+SYNOPSIS
+    wic list images
+    wic list <image> help
+    wic list properties
+    wic list properties <wks file>
+    wic list property <property>
+            [-o <JSON PROPERTY FILE> | --outfile <JSON PROPERTY_FILE>]
+
+DESCRIPTION
+    This command enumerates the complete set of possible values for a
+    specified option or property needed by the image creation process.
+
+    This command enumerates the set of available canned images as well
+    as help for those images.  It also can be used to enumerate the
+    complete set of possible values for a specified option or property
+    needed by the image creation process.
+
+    The first form enumerates all the available 'canned' images.
+    These are actually just the set of .wks files that have been moved
+    into the /scripts/lib/image/canned-wks directory).
+
+    The second form lists the detailed help information for a specific
+    'canned' image.
+
+    The third form enumerates all the possible values that exist and
+    can be specified in a OE kickstart (wks) file.  The output of this
+    can be used by the third form to print the description and
+    possible values of a specific property.
+
+    The fourth form enumerates all the possible options that exist for
+    the set of properties specified in a given OE kickstart (wks)
+    file.  If the -o option is specified, the list of properties, in
+    addition to being displayed, will be written to the specified file
+    as a JSON object.  In this case, the object will consist of the
+    set of name:value pairs corresponding to the (possibly nested)
+    dictionary of properties defined by the input statements used by
+    the image.  Some example output for the 'list <wks file>' command:
+
+    $ wic list test.ks
+    "part" : {
+        "mountpoint" : "/"
+        "fstype" : "ext3"
+    }
+    "part" : {
+        "mountpoint" : "/home"
+        "fstype" : "ext3"
+        "offset" : "10000"
+    }
+    "bootloader" : {
+        "type" : "efi"
+    }
+    .
+    .
+    .
+
+    Each entry in the output consists of the name of the input element
+    e.g. "part", followed by the properties defined for that
+    element enclosed in braces.  This information should provide
+    sufficient information to create a complete user interface with.
+
+    The final form enumerates all the possible values that exist and
+    can be specified for any given OE kickstart (wks) property.  If
+    the -o option is specified, the list of values for the given
+    property, in addition to being displayed, will be written to the
+    specified file as a JSON object.  In this case, the object will
+    consist of the set of name:value pairs corresponding to the array
+    of property values associated with the property.
+
+    $ wic list property part
+        ["mountpoint", "where the partition should be mounted"]
+        ["fstype", "filesytem type of the partition"]
+            ["ext3"]
+            ["ext4"]
+            ["btrfs"]
+            ["swap"]
+        ["offset", "offset of the partition within the image"]
+
+"""
diff --git a/scripts/wic b/scripts/wic
new file mode 100755
index 0000000..06e72bb
--- /dev/null
+++ b/scripts/wic
@@ -0,0 +1,185 @@ 
+#!/usr/bin/env python
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# Copyright (c) 2013, Intel Corporation.
+# All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# DESCRIPTION 'wic' is the OpenEmbedded Image Creator that users can
+# use to generate bootable images.  Invoking it without any arguments
+# will display help screens for the 'wic' command and list the
+# available 'wic' subcommands.  Invoking a subcommand without any
+# arguments will likewise display help screens for the specified
+# subcommand.  Please use that interface for detailed help.
+#
+# AUTHORS
+# Tom Zanussi <tom.zanussi (at] linux.intel.com>
+#
+
+__version__ = "0.1.0"
+
+import os
+import sys
+import optparse
+import logging
+
+scripts_path = os.path.abspath(os.path.dirname(os.path.abspath(sys.argv[0])))
+lib_path = scripts_path + '/lib'
+sys.path = sys.path + [lib_path]
+
+from image.help import *
+from image.engine import *
+
+
+def wic_create_subcommand(args, usage_str):
+    """
+    Command-line handling for image creation.  The real work is done
+    by image.engine.wic_create()
+    """
+    parser = optparse.OptionParser(usage = usage_str)
+
+    parser.add_option("-o", "--outdir", dest = "outdir",
+                      action = "store", help = "name of directory to create image in")
+    parser.add_option("-i", "--infile", dest = "properties_file",
+                      action = "store", help = "name of file containing the values for image properties as a JSON file")
+    parser.add_option("-e", "--image-name", dest = "image_name",
+                      action = "store", help = "name of the image to use the artifacts from e.g. core-image-sato")
+    parser.add_option("-r", "--rootfs-dir", dest = "rootfs_dir",
+                      action = "store", help = "path to the /rootfs dir to use as the .wks rootfs source")
+    parser.add_option("-b", "--bootimg-dir", dest = "bootimg_dir",
+                      action = "store", help = "path to the dir containing the boot artifacts (e.g. /EFI or /syslinux dirs) to use as the .wks bootimg source")
+    parser.add_option("-k", "--kernel-dir", dest = "kernel_dir",
+                      action = "store", help = "path to the dir containing the kernel to use in the .wks bootimg")
+    parser.add_option("-n", "--native-sysroot", dest = "native_sysroot",
+                      action = "store", help = "path to the native sysroot containing the tools to use to build the image")
+    parser.add_option("-p", "--skip-build-check", dest = "build_check",
+                      action = "store_false", default = True, help = "skip the build check")
+
+    (options, args) = parser.parse_args(args)
+
+    if len(args) != 1:
+        logging.error("Wrong number of arguments, exiting\n")
+        parser.print_help()
+        sys.exit(1)
+
+    if not options.image_name:
+        options.build_check = False
+
+    if options.build_check and not options.properties_file:
+        print "Checking basic build environment..."
+        if not verify_build_env():
+            print "Couldn't verify build environment, exiting\n"
+            sys.exit(1)
+        else:
+            print "Done.\n"
+
+    print "Creating image(s)...\n"
+
+    bootimg_dir = staging_data_dir = hdddir = ""
+
+    if options.image_name:
+        (rootfs_dir, kernel_dir, hdddir, staging_data_dir, native_sysroot) = \
+            find_artifacts(options.image_name)
+
+    wks_file = args[0]
+
+    if not wks_file.endswith(".wks"):
+        wks_file = find_canned_image(scripts_path, wks_file)
+        if not wks_file:
+            print "No image named %s found, exiting.  (Use 'wic list images' to list available images, or specify a fully-qualified OE kickstart (.wks) filename)\n" % wks_file
+            sys.exit(1)
+
+    image_output_dir = ""
+    if options.outdir:
+        image_output_dir = options.outdir
+
+    if not options.image_name:
+        rootfs_dir = options.rootfs_dir
+        bootimg_dir = options.bootimg_dir
+        kernel_dir = options.kernel_dir
+        native_sysroot = options.native_sysroot
+
+    wic_create(args, wks_file, rootfs_dir, bootimg_dir, kernel_dir,
+               native_sysroot, hdddir, staging_data_dir, scripts_path,
+               image_output_dir, options.properties_file)
+
+
+def wic_list_subcommand(args, usage_str):
+    """
+    Command-line handling for listing available image properties and
+    values.  The real work is done by image.engine.wic_list()
+    """
+    parser = optparse.OptionParser(usage = usage_str)
+
+    parser.add_option("-o", "--outfile", action = "store",
+                      dest = "properties_file",
+                      help = "dump the possible values for image properties to a JSON file")
+
+    (options, args) = parser.parse_args(args)
+
+    if not wic_list(args, scripts_path, options.properties_file):
+        logging.error("Bad list arguments, exiting\n")
+        parser.print_help()
+        sys.exit(1)
+
+
+subcommands = {
+    "create": [wic_create_subcommand,
+               wic_create_usage,
+               wic_create_help],
+    "list":   [wic_list_subcommand,
+               wic_list_usage,
+               wic_list_help],
+}
+
+
+def start_logging(loglevel):
+    logging.basicConfig(filname = 'wic.log', filemode = 'w', level=loglevel)
+
+
+def main():
+    parser = optparse.OptionParser(version = "wic version %s" % __version__,
+                                   usage = wic_usage)
+
+    parser.disable_interspersed_args()
+    parser.add_option("-D", "--debug", dest = "debug", action = "store_true",
+                      default = False, help = "output debug information")
+
+    (options, args) = parser.parse_args()
+
+    loglevel = logging.INFO
+    if options.debug:
+        loglevel = logging.DEBUG
+    start_logging(loglevel)
+
+    if len(args):
+        if args[0] == "help":
+            if len(args) == 1:
+                parser.print_help()
+                sys.exit(1)
+
+    invoke_subcommand(args, parser, wic_help_usage, subcommands)
+
+
+if __name__ == "__main__":
+    try:
+        ret = main()
+    except Exception:
+        ret = 1
+        import traceback
+        traceback.print_exc(5)
+    sys.exit(ret)
+