Merge lp:~dholbach/snappy/more-markdown-fixes into lp:~snappy-dev/snappy/snappy-moved-to-github

[Daniel Holbach]

- fix small typos
- use <code> for configuration keywords
- it’s → its
- break large sentence into two
- italicise Note:/Caution:

[John Lenton (chipaca)]

review: Approve

[Snappy Tarmac (snappydevtarmac)]

The attempt to merge lp:~dholbach/snappy/more-markdown-fixes into lp:snappy failed. Below is the output from the failed tests.

Checking formatting
Installing godeps

# we always run in a fresh dir in tarmac
export GOPATH=$(mktemp -d)
trap 'rm -rf "$GOPATH"' EXIT

# this is a hack, but not sure tarmac is golang friendly
mkdir -p $GOPATH/src/launchpad.net/snappy
cp -a . $GOPATH/src/launchpad.net/snappy/
cd $GOPATH/src/launchpad.net/snappy

./run-checks

if which goctest >/dev/null; then
    goctest="goctest"
else
    goctest="go test"
fi

echo Checking formatting
fmt=$(gofmt -l .)

if [ -n "$fmt" ]; then
    echo "Formatting wrong in following files"
    echo $fmt
    exit 1
fi

echo Installing godeps
go get launchpad.net/godeps
# cd .; bzr branch https://launchpad.net/godeps /tmp/tmp.1X9HujsbNN/src/launchpad.net/godeps
bzr: ERROR: http://bazaar.launchpad.net/%2Bbranch-id/769359/.bzr/repository/packs/82a0588ac18ed8994f614f8142ee921f.pack is redirected to https://launchpad.net
package launchpad.net/godeps: exit status 3

[lp:~dholbach/snappy/more-markdown-fixes]

417. By Daniel Holbach on 2015-04-22

- fix small typos
- use <code> for configuration keywords
- it’s → its
- break large sentence into two
- italicise Note:/Caution: by dholbach approved by chipaca

=== modified file 'docs/meta.md'
--- docs/meta.md	2015-04-18 18:17:21 +0000
+++ docs/meta.md	2015-04-22 13:42:58 +0000
@@ -1,13 +1,13 @@
 # Package metadata
 
 This document describes the meta data of a snappy package. All files
-are located under the meta/ directory. 
+are located under the `meta/` directory. 
 
 The following files are supported:
 
 ## readme.md
 
-The readme.md file contains a description of the snap. The snappy
+The `readme.md` file contains a description of the snap. The snappy
 tools will automatically extract the heading as the short summary for
 the snap and the first paragraph as the description in the store.
 
@@ -16,69 +16,69 @@
 This file describes the snap package and is the most important file
 for a snap package. The following keys are mandatory:
 
- * name: the name of the snap (only [a-z0-9][a-z0-9+.-])
- * version: the version of the snap (only [a-zA-Z0-9.+~-] are allowed)
- * vendor: the vendor of the snap
+ * `name`: the name of the snap (only `[a-z0-9][a-z0-9+.-]`)
+ * `version`: the version of the snap (only `[a-zA-Z0-9.+~-]` are allowed)
+ * `vendor`: the vendor of the snap
 
 The following keys are optional:
 
- * icon: a svg icon for the snap that is displayed in the store
- * explicit-license-agreement: set to `Y` if the user needs to accept a
-   special meta/license.txt before the snap can be installed
- * license-version: a string that, when it changes and
+ * `icon`: a SVG icon for the snap that is displayed in the store
+ * `explicit-license-agreement`: set to `Y` if the user needs to accept a
+   special `meta/license.txt` before the snap can be installed
+ * `license-version`: a string that, when it changes and
    `explicit-license-agreement` is `Y`, prompts the user to accept the
    license again.
- * type: (optional) the type of the snap, can be:
-   * app - the default if empty
-   * oem - a special snap that OEMs can use to customize snappy for
-           their hardware
-   * framework - a specialized snap that extends the system that other
-                 snaps may use
-
- * architectures: (optional) a yaml list of supported architectures
-                  ["all"] if empty
- * frameworks: a list of the frameworks the snap needs as dependencies
-
- * services: the servies (daemons) that the snap provides
-   * name: (required) name of the service (only [a-zA-Z0-9+.-])
-   * description: (required) description of the service
-   * start: (required) the command to start the service
-   * stop: (optional) the command to stop the service
-   * stop-timeout: (optional) the time in seconds to wait for the
-                   service to stop
-   * poststop: a command that runs after the service has stopped
-   * caps: (optional) list of additional security policies to add.
-           See security.md for details
-   * security-template: (optional) alternate security template to use
-                        instead of `default`. See security.md for details 
-   * security-override: (optional) high level overrides to use when
-                        `security-template` and `caps` are not
-                        sufficient.  See security.md for details
-   * security-policy: (optional) hand-crafted low-level raw security
-                      policy to use instead of using default
-                      template-based  security policy. See
-                      security.md for details
-   * ports: (optional) define what ports the service will work
-     * internal: the ports the service is going to connect to
-       * tagname: a free form name
-         * port: (optional) number/protocol, e.g. 80/tcp
-         * negotiable: (optional) Y if the app can use a different port
-     * external: the ports the service offer to the world
-       * tagname: a free form name, some names have meaning like "ui"
-         * port: (optional) see above
-         * negotionalble: (optional) see above
-   * bus-name: (optional) message bus connection name for the service.
+ * `type`: (optional) the type of the snap, can be:
+   * `app` - the default if empty
+   * `oem` - a special snap that OEMs can use to customize snappy for
+             their hardware
+   * `framework` - a specialized snap that extends the system that other
+                   snaps may use
+
+ * `architectures`: (optional) a yaml list of supported architectures
+                    `["all"]` if empty
+ * `frameworks`: a list of the frameworks the snap needs as dependencies
+
+ * `services`: the servies (daemons) that the snap provides
+   * `name`: (required) name of the service (only `[a-zA-Z0-9+.-]`)
+   * `description`: (required) description of the service
+   * `start`: (required) the command to start the service
+   * `stop`: (optional) the command to stop the service
+   * `stop-timeout`: (optional) the time in seconds to wait for the
+                     service to stop
+   * `poststop`: a command that runs after the service has stopped
+   * `caps`: (optional) list of additional security policies to add.
+             See `security.md` for details
+   * `security-template`: (optional) alternate security template to use
+                          instead of `default`. See `security.md` for details 
+   * `security-override`: (optional) high level overrides to use when
+                          `security-template` and `caps` are not
+                          sufficient.  See security.md for details
+   * `security-policy`: (optional) hand-crafted low-level raw security
+                        policy to use instead of using default
+                        template-based  security policy. See
+                        security.md for details
+   * `ports`: (optional) define what ports the service will work
+     * `internal`: the ports the service is going to connect to
+       * `tagname`: a free form name
+         * `port`: (optional) number/protocol, e.g. `80/tcp`
+         * `negotiable`: (optional) Y if the app can use a different port
+     * `external`: the ports the service offer to the world
+       * `tagname`: a free form name, some names have meaning like "ui"
+         * `port`: (optional) see above
+         * `negotiable`: (optional) see above
+   * `bus-name`: (optional) message bus connection name for the service.
      May only be specified for snaps of 'type: framework' (see above).
 
- * binaries: the binaries (executables) that the snap provies
-   * name: (required) the name of the binary, the user will be able to
-           call it as $name.$pkgname (only [a-zA-Z0-9+.-])
-   * exec: the program that gets execute (can be omited if name points
-           to a binary already)
-   * caps: (optional) see entry in services (above)
-   * security-template: (optional) see entry in services (above)
-   * security-override: (optional) see entry in services (above)
-   * security-policy: (optional) see entry in services (above)   
+ * `binaries`: the binaries (executables) that the snap provides
+   * `name`: (required) the name of the binary, the user will be able to
+             call it as $name.$pkgname (only `[a-zA-Z0-9+.-]`)
+   * `exec`: the program that gets executed (can be omited if name points
+             to a binary already)
+   * `caps`: (optional) see entry in `services` (above)
+   * `security-template`: (optional) see entry in `services` (above)
+   * `security-override`: (optional) see entry in `services` (above)
+   * `security-policy`: (optional) see entry in `services` (above)   
  
 ## license.txt
 
@@ -87,7 +87,7 @@
 
 ## hooks/ directory
 
-See config.md for details.
+See `config.md` for details.
 
 # Examples
 

=== modified file 'docs/oem.md'
--- docs/oem.md	2015-04-14 16:46:57 +0000
+++ docs/oem.md	2015-04-22 13:42:58 +0000
@@ -3,7 +3,7 @@
 The `oem` snappy package is a snappy package `type` that is used to setup and
 personalize the system according to an OEM.
 
-It covers a broad range, such as the software stack with it’s configuration and
+It covers a broad range, such as the software stack with its configuration and
 hardware enablement.
 
 There can only be *one* snappy package of `type` `oem` and it can only be
@@ -12,7 +12,7 @@
 ## Nomenclature
 
 Some parts of this text refer to pure snappy packages, and `device` or
-`ubuntu-core` packages, the intent is that in the future, `device` and
+`ubuntu-core` packages. The intent is that in the future, `device` and
 `ubuntu-core` would migrate to being pure snappy packages in the future. This
 has been generalized in some text with the concept of `parts`, in this writing
 everything is a *package*.
@@ -41,7 +41,7 @@
 each package that is to be configured.
 
 On first boot of the system, this `config.yaml` file will be processed and the
-described configuration will be applied. Note: factory resetting the system
+described configuration will be applied. *Note:* factory resetting the system
 will create a first boot scenario and therefore `config.yaml` will be
 processed.
 
@@ -87,7 +87,7 @@
 system to boot.
 
 While these assets are typically used during provisioning, they may also be
-used against a running system. Caution: updating these assets on a running
+used against a running system. *Caution:* updating these assets on a running
 system may lead to a broken system unless redundancy or fallback machanisms
 aren't provided by the OEM.