Replace moby build with linuxkit build throughout

Signed-off-by: Justin Cormack <justin.cormack@docker.com>

reports/2017-03-19.md

@@ -37,7 +37,7 @@ Welcome everyone, looking forward to your contrinutions and working with you. Pl
 
 ## This week
 
-We are working towards a simpler and better documented basic flow. Early next week the `moby` tool will be changed to have `moby build` and `moby run` subcommands. At least initially the `moby run` flow will only be targeted at running locally (hyperkit and kvm, qemu). We may add a third cluster run option later, using infrakit. @rneugeba has been working on Go hyperkit bindings to make this easier in [#1327](https://github.com/docker/moby/pull/1327).
+We are working towards a simpler and better documented basic flow. Early next week the `moby` tool will be changed to have `linuxkit build` and `moby run` subcommands. At least initially the `moby run` flow will only be targeted at running locally (hyperkit and kvm, qemu). We may add a third cluster run option later, using infrakit. @rneugeba has been working on Go hyperkit bindings to make this easier in [#1327](https://github.com/docker/moby/pull/1327).
 
 There is a `--name` option to the `moby` tool to allow configuring of the image names that are built see [#1318](https://github.com/docker/moby/pull/1318) rather than just using the yaml file name.
 

reports/2017-03-26.md

@@ -18,14 +18,14 @@ A WIP PR for the HPE OKernel work was added [#1373](https://github.com/docker/mo
 
 ## This week
 
-The big change this week was reworking the command line tool, so it now has `moby build` and `moby run` options. The aim of the `moby run` option is to cover the simple cases
+The big change this week was reworking the command line tool, so it now has `linuxkit build` and `moby run` options. The aim of the `moby run` option is to cover the simple cases
 where you want to test out an image you have built; it is not intended as a production tool, just as a simpler workflow for testing. The aim is to have a default option per
 platform, such as the hyperkit option there is for MacOS now, so we will add Qemu/KVM support for Linux and Hyper-V support for Windows. In addition there will be support for
 optional drivers, such as local VMWare Fusion, as discussed in [#1357](https://github.com/docker/moby/pull/1357) which can have their own custom options; we will probably add the GCE
 support here too to make it even simpler to run.
 
-In addition to `moby build` and `moby run` we have previously discussed adding a `moby cluster` type option to simply create a cluster, by default with infrakit, essentially as a
-simple infrakit wrapper. Again this is not intended for production use but just to run simple test and development cases. For production that plan is that `moby build` can produce
+In addition to `linuxkit build` and `moby run` we have previously discussed adding a `moby cluster` type option to simply create a cluster, by default with infrakit, essentially as a
+simple infrakit wrapper. Again this is not intended for production use but just to run simple test and development cases. For production that plan is that `linuxkit build` can produce
 the artifacts you need for your production ops tooling.
 
 A whole lot more code has been moved to Go code this week; in addition to the hyperkit bindings, some of the Docker containers that we were using for build have been removed. The next

reports/2017-04-02.md

@@ -30,7 +30,7 @@ Small changes:
 - `.yaml` files were renamed to `.yml` for consistency with common usage elsewhere
 - fixes for console handling
 - kernel updates, additional driver support
-- `moby build` now logs what it is doing by default, to help debugging. There is a quiet option to disable.
+- `linuxkit build` now logs what it is doing by default, to help debugging. There is a quiet option to disable.
 
 ## Planned for next week
 

reports/2017-04-30.md

@@ -12,7 +12,7 @@ Quite a few changes post DockerCon as we started making more breaking changes.
 
 ### Command move and rename
 
-The `moby` command was split up, into [`moby/tool`](https://github.com/moby/tool/) for just the assembly phase, ie `moby build` and the `linuxkit` tool in the LinuxKit repo for the parts that are specific to VM images. This is not the final arrangement, in particular the build process will probably be reworked into more phases, and be made more modular. The `linuxkit` command had a `push` stage added, which can push VM images to remote store; currently this supports pushing images to Google Cloud but more will be added. A lot of rework is planned with the `moby` tool, and it will move to [https://github.com/moby/moby](https://github.com/moby/moby) soon.
+The `moby` command was split up, into [`moby/tool`](https://github.com/moby/tool/) for just the assembly phase, ie `linuxkit build` and the `linuxkit` tool in the LinuxKit repo for the parts that are specific to VM images. This is not the final arrangement, in particular the build process will probably be reworked into more phases, and be made more modular. The `linuxkit` command had a `push` stage added, which can push VM images to remote store; currently this supports pushing images to Google Cloud but more will be added. A lot of rework is planned with the `moby` tool, and it will move to [https://github.com/moby/moby](https://github.com/moby/moby) soon.
 
 ### CI
 

reports/2017-05-22.md

@@ -51,7 +51,7 @@ Documentation:
 ## Issues of interest
 
 - [linuxkit/linuxkit#1835] Build  my own kernel was closed ([@rneugeba] [@justincormack] [@yankunsam])
-- [linuxkit/linuxkit#1841] Windows moby build failed was closed ([@rneugeba] [@tippexs])
+- [linuxkit/linuxkit#1841] Windows linuxkit build failed was closed ([@rneugeba] [@tippexs])
 - [linuxkit/linuxkit#1845] [Question] Run service container with elevated privileges was closed ([@radu-matei])
 - [linuxkit/linuxkit#1846] Can busybox in the root fs be stripped down more? was closed ([@rneugeba] [@justincormack] [@avsm])
 - [linuxkit/linuxkit#1847] Selection of architecture in config by `moby` tool was closed ([@mor1])
@@ -78,7 +78,7 @@ Documentation:
 - [linuxkit/rtf#13] Add ability to run a single test or a group had 3 events ([@rneugeba] [@dave-tucker])
 - [linuxkit/linuxkit#1839] After halt, it will been blocked  and have no response had 4 events ([@yankunsam] [@avsm] [@rneugeba] [@thebsdbox])
 - [linuxkit/linuxkit#1837] `ctr exec -t` hangs had 6 events ([@FrenchBen] [@avsm] [@rneugeba] [@justincormack])
-- [linuxkit/linuxkit#1421] Add build support for Azure to `moby build` had 7 events ([@justincormack] [@radu-matei])
+- [linuxkit/linuxkit#1421] Add build support for Azure to `linuxkit build` had 7 events ([@justincormack] [@radu-matei])
 
 Other reports in this series can be browsed directly in the repository at [linuxkit/linuxkit:/reports](https://github.com/linuxkit/linuxkit/tree/master/reports/).
 

reports/2017-06-19-summit.md

@@ -5,7 +5,7 @@
 - `moby` tool producing disk images
 - Currently moby tool calls out to linuxkit to do the build
 - moby tool was initially just for building linux images but now it supports docker and other formats
-- Could make `moby build` into a library and other tools like Infrakit could use it [PR opened](https://github.com/moby/tool/pull/91)
+- Could make `linuxkit build` into a library and other tools like Infrakit could use it [PR opened](https://github.com/moby/tool/pull/91)
 - Currently Infrakit shells out to Moby tool
 
 ### What platforms do people want to support for Linuxkit?

reports/sig-security/2017-06-21.md

@@ -43,7 +43,7 @@ Scribe: @mgoelzer
     - integrity
     - freshness
     - survivability after key compromise
-  - Linuxkit yaml files container `trust:` block - tells moby builder that you want to verify all images in a given organization or per image control
+  - Linuxkit yaml files container `trust:` block - tells linuxkit builder that you want to verify all images in a given organization or per image control
   - Moby builder will first check the signatures for all images and validate expiration dates before pulling images
   - Future directions:
     - key pinning for signed packages