diff --git a/Add_new_software_to_Baserock.mdwn b/Add_new_software_to_Baserock.mdwn
index 29775bf..0a2d859 100644
--- a/Add_new_software_to_Baserock.mdwn
+++ b/Add_new_software_to_Baserock.mdwn
@@ -33,7 +33,7 @@ And if that is successful then deploy to a target with:
 
 Notice that the above example uses a Github repo. If you wish to get your software accepted into upstream baserock then you would need to create a lorry file, as folllows:
 
-    git clone http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git
+    git clone http://git.baserock.org/cgit/baserock/local-config/lorries.git
     cd lorries/open-source-lorries
     vi accounts.lorry
 
diff --git a/Lorry.mdwn b/Lorry.mdwn
index 2d55e48..d5a9288 100644
--- a/Lorry.mdwn
+++ b/Lorry.mdwn
@@ -5,13 +5,13 @@ Lorry
 Lorry is a tool for mirroring upstream source code into
 Baserock Git repositories on our own Git server.
 
-Example lorry are files [here](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/)! If you want to add something to the Baserock trove, write a lorry file and [send it upstream](http://wiki.baserock.org/contributing/).
+Example lorry are files [here](http://git.baserock.org/cgit/baserock/local-config/lorries.git/)! If you want to add something to the Baserock trove, write a lorry file and [send it upstream](http://wiki.baserock.org/contributing/).
 
 The Lorry [README] has a good introduction to its use. See the manual page or `--help` output for details on options.
 
-The source for Lorry is [[here|http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/]]. It is available in Baserock 'trove' and 'devel' reference systems.
+The source for Lorry is [[here|http://git.baserock.org/cgit/baserock/baserock/lorry.git/]]. It is available in Baserock 'trove' and 'devel' reference systems.
 
-[README]: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/tree/README
+[README]: http://git.baserock.org/cgit/baserock/baserock/lorry.git/tree/README
 
 
 Lorry Controller
@@ -19,6 +19,6 @@ Lorry Controller
 
 Lorry Controller is a separate program to Lorry. It takes care of mirroring a large set of repos: running Lorry regularly for each repo, logging any failed jobs, and providing a web frontend for admins to use.
 
-It is documented in its [[README|http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry-controller.git/tree/README]], and within the [[Trove reference manual|Trove/reference#index4h2]].
+It is documented in its [[README|http://git.baserock.org/cgit/baserock/baserock/lorry-controller.git/tree/README]], and within the [[Trove reference manual|Trove/reference#index4h2]].
 
-The source code for Lorry Controller is [[here|http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry-controller.git/]]. It is found in Baserock 'trove' systems.
+The source code for Lorry Controller is [[here|http://git.baserock.org/cgit/baserock/baserock/lorry-controller.git/]]. It is found in Baserock 'trove' systems.
diff --git a/Morph.mdwn b/Morph.mdwn
index 07c8c31..514ab67 100644
--- a/Morph.mdwn
+++ b/Morph.mdwn
@@ -2,7 +2,7 @@
 Morph
 ====
 
-See Morph's code [here](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/)! 
+See Morph's code [here](http://git.baserock.org/cgit/baserock/baserock/morph.git/)! 
 
 Morph is the Baserock workflow tool. It controls the builds and branching
 and merging, and other parts of the process of developing with Baserock.
diff --git a/Trebuchet/tbdiff.mdwn b/Trebuchet/tbdiff.mdwn
index 3bba971..1229c78 100644
--- a/Trebuchet/tbdiff.mdwn
+++ b/Trebuchet/tbdiff.mdwn
@@ -17,7 +17,7 @@ namespace), so its interaction with SMACK and SeLinux haven't
 been tested.
 
 ## Code
-The git repository can be found on [git.baserock.org](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/tbdiff.git/)
+The git repository can be found on [git.baserock.org](http://git.baserock.org/cgit/baserock/baserock/tbdiff.git/)
 
 ## ToDo
 
diff --git a/Trove.mdwn b/Trove.mdwn
index 197cf3f..2646239 100644
--- a/Trove.mdwn
+++ b/Trove.mdwn
@@ -9,7 +9,7 @@ A Trove is a Baserock server appliance which combines a range of functions
 
 Normally a Trove will be configured to collect sources from an upstream Trove and/or other upstream servers.
 
-[git.baserock.org](http://git.baserock.org/cgi-bin/cgit.cgi/) is a public example of a Trove. 
+[git.baserock.org](http://git.baserock.org/cgit/) is a public example of a Trove. 
 
 There are guides on how to deploy a Trove to the following virtualisation systems:
 
diff --git a/Trove/reference.mdwn b/Trove/reference.mdwn
index 667eeac..dae47bf 100644
--- a/Trove/reference.mdwn
+++ b/Trove/reference.mdwn
@@ -376,7 +376,7 @@ There is a more advanced page available, which is not publically visible. In ord
 
 You can then view the advanced status page at: <http://localhost:12765/1.0/status-html>. This allows you to do some administration and view the logs of both successful and failed lorries. If you find that some repositories in your Trove are empty after the lorry-controller has completed its first run, this interface allows you to investigate what went wrong.
 
-Lorry Controller also describes this in [its README file](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry-controller.git/tree/README).
+Lorry Controller also describes this in [its README file](http://git.baserock.org/cgit/baserock/baserock/lorry-controller.git/tree/README).
 
 The Morph Cache Service
 -----------------------
diff --git a/caching.mdwn b/caching.mdwn
index db0d146..0e103fb 100644
--- a/caching.mdwn
+++ b/caching.mdwn
@@ -17,7 +17,7 @@ Another way to look at this is that Debian packages depend on manually-construct
 
 Baserock build tools don't require any manual versioning. Instead, they automatically work out a 'cache identity' for each build, based on all of the things that could cause functional changes. The exact set of factors isn't specified[1], but it includes host machine architecture, commands that will be used to build, Git SHA1 of the commit that will be built, and the cache identity of all dependencies that will be made available when the build runs.
 
-Morph's code to calculate cache identity is currently here: <http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/cachekeycomputer.py#n81>
+Morph's code to calculate cache identity is currently here: <http://git.baserock.org/cgit/baserock/baserock/morph.git/tree/morphlib/cachekeycomputer.py#n81>
 
 YBD's code to calculate cache identity is here: <https://gitlab.com/baserock/ybd/blob/master/ybd/cache.py>
 
diff --git a/definitions.mdwn b/definitions.mdwn
index 9b89016..4eba8b8 100644
--- a/definitions.mdwn
+++ b/definitions.mdwn
@@ -16,7 +16,7 @@ For building definitions, you can use [[Morph]] or [[YBD]].
 
 ## The Baserock reference definitions
 
-We maintain a collection of definitions describing how to build lots of popular free software components. These are in a repository at [git.baserock.org/baserock/baserock/definitions](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/).
+We maintain a collection of definitions describing how to build lots of popular free software components. These are in a repository at [git.baserock.org/baserock/baserock/definitions](http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/).
 
 When modifying or defining your own Baserock systems, normally you will 'fork' this repository and use Git tooling to keep your changes in sync with ours.
 
diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index cf6d921..654ae76 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -31,7 +31,7 @@ See also: <https://en.wikipedia.org/wiki/List_of_build_automation_software>
 ## CPython (the standard interpeter for the Python language)
 
 - Arch Linux: [PKGBUILD](https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python) ([packages/extra/x86_64/python info](https://www.archlinux.org/packages/extra/x86_64/python/))
-- Baserock reference systems: [strata/core/cpython.morph](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/core/python3.morph)
+- Baserock reference systems: [strata/core/cpython.morph](http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/core/python3.morph)
 - buildroot: [package/python3/python3.mk](http://git.buildroot.net/buildroot/tree/package/python3/python3.mk), [package/python3/Config.in](http://git.buildroot.net/buildroot/tree/package/python3/Config.in)
 - Debian: [debian/rules](https://alioth.debian.org/scm/loggerhead/pkg-python/python3-defaults-debian/view/head:/debian/rules), [debian/control](https://alioth.debian.org/scm/loggerhead/pkg-python/python3-defaults-debian/view/head:/debian/control) ([pkg-python project main page](https://alioth.debian.org/projects/pkg-python))
 - Fedora: [python.spec](http://pkgs.fedoraproject.org/cgit/python.git/tree/python.spec)
diff --git a/devel-with.mdwn b/devel-with.mdwn
index 3592540..6993eab 100644
--- a/devel-with.mdwn
+++ b/devel-with.mdwn
@@ -373,9 +373,9 @@ system.
 Unless the build system of the software you're integrating follows a known
 pattern, you will also need to write a 'chunk morphology' describing how to
 build it. You will get an error 'couldn't find morphology' if you need to do this. There are plenty of [existing chunk
-morphologies](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/core)
+morphologies](http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/core)
 in various subdirectories of the 'strata/' directory in
-[definitions.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git).
+[definitions.git](http://git.baserock.org/cgit/baserock/baserock/definitions.git).
 
 There is [[an informal specification|definitions/current]] of the definitions format.
 
diff --git a/doing-stuff-with-baserock.mdwn b/doing-stuff-with-baserock.mdwn
index d0f1229..0c6b494 100644
--- a/doing-stuff-with-baserock.mdwn
+++ b/doing-stuff-with-baserock.mdwn
@@ -45,7 +45,7 @@ Software|Detail|Sponsors
 
 [GENIVI Demo Platform](http://wiki.projects.genivi.org/index.php/GENIVI_Demo_Platform)|   In progress  |  Jonathan Maw, James Thomas
 
-[Gerrit code review](https://code.google.com/p/gerrit/)                               |   [Complete](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/infrastructure.git/tree/baserock_gerrit)   |
+[Gerrit code review](https://code.google.com/p/gerrit/)                               |   [Complete](http://git.baserock.org/cgit/baserock/baserock/infrastructure.git/tree/baserock_gerrit)   |
 
 [GNOME Desktop](http://gnome.org/)                                                    |   [In progress](https://storyboard.baserock.org/#!/story/5)                                          |   Javier Jardón
 
diff --git a/glossary.mdwn b/glossary.mdwn
index b5489d9..eb9fdf7 100644
--- a/glossary.mdwn
+++ b/glossary.mdwn
@@ -41,7 +41,7 @@ See the [[caching]] page for more information.
 
 A minimal Baserock _system_ containing the minimum necessary to have a runnable system. Base _systems_ are defined in _definitions_ beginning
 with `base-system-` e.g.
-[`base-system-x86_64-generic.morph`](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/systems/devel-system-x86_64-generic.morph)
+[`base-system-x86_64-generic.morph`](http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/systems/devel-system-x86_64-generic.morph)
 
 ## Base system image
 
@@ -52,7 +52,7 @@ A _system image_ of a Baserock _base system_.
 A Baserock _system_ containing the tools typically needed to build
 Baserock systems. Build _systems_ are defined in _definitions_ beginning
 with `build-system-` e.g.
-[`build-system-x86_64-generic.morph`](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/systems/build-system-x86_64.morph)
+[`build-system-x86_64-generic.morph`](http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/systems/build-system-x86_64.morph)
 
 ## Build system image
 
@@ -84,7 +84,7 @@ Linux kernel, `systemd`), or a component developed for Baserock itself.
 A _deployment extension_ used to configure the _system_, e.g. by adding
 configuration files or entries in configurations to the _system_'s rootfs.
 Implemented in a `.configure` file in the `extensions/`  directory in the
-[`definitions` repository](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree)
+[`definitions` repository](http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree)
 
 ## Continuous integration and delivery
 
@@ -127,7 +127,7 @@ A Baserock _system_ containing the tools typically used for developing under
 Baserock.  Consists of a _Build System_ with additional support for lanuguages
 including Ruby and Node.js. Development _systems_ are defined in _definitions_
 beginning with `devel-system-` e.g.
-[`devel-system-x86_64-generic.morph`](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/systems/devel-system-x86_64-generic.morph)
+[`devel-system-x86_64-generic.morph`](http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/systems/devel-system-x86_64-generic.morph)

(Diff truncated)

diff --git a/download.mdwn b/download.mdwn
index 160d9f4..bc51e07 100644
--- a/download.mdwn
+++ b/download.mdwn
@@ -40,23 +40,23 @@ Archives
 For information about previous releases see the [[Releases]] page.
 
 For all current and past release files, see
-<http://download.baserock.org/baserock/>.
+<https://download.baserock.org/baserock/>.
 
 
 
-[base-x86-32-raw]: http://download.baserock.org/baserock/baserock-current-base-x86_32.img.gz
-[base-x86-64-raw]: http://download.baserock.org/baserock/baserock-current-base-x86_64.img.gz
+[base-x86-32-raw]: https://download.baserock.org/baserock/baserock-current-base-x86_32.img.gz
+[base-x86-64-raw]: https://download.baserock.org/baserock/baserock-current-base-x86_64.img.gz
 
-[build-x86-32-raw]: http://download.baserock.org/baserock/baserock-current-build-system-x86_32.img.gz
-[build-x86-32-chroot]: http://download.baserock.org/baserock/baserock-current-build-system-x86_32-chroot.tar.gz
+[build-x86-32-raw]: https://download.baserock.org/baserock/baserock-current-build-system-x86_32.img.gz
+[build-x86-32-chroot]: https://download.baserock.org/baserock/baserock-current-build-system-x86_32-chroot.tar.gz
 
-[build-armv7lhf-jetson-raw]: http://download.baserock.org/baserock/baserock-current-build-system-armv7lhf-jetson.img.gz
+[build-armv7lhf-jetson-raw]: https://download.baserock.org/baserock/baserock-current-build-system-armv7lhf-jetson.img.gz
 
-[build-x86-64-raw]: http://download.baserock.org/baserock/baserock-current-build-system-x86_64.img.gz
-[build-x86-64-chroot]: http://download.baserock.org/baserock/baserock-current-build-system-x86_64-chroot.tar.gz
+[build-x86-64-raw]: https://download.baserock.org/baserock/baserock-current-build-system-x86_64.img.gz
+[build-x86-64-chroot]: https://download.baserock.org/baserock/baserock-current-build-system-x86_64-chroot.tar.gz
 
-[genivi-base-x86-64-raw]: http://download.baserock.org/baserock/baserock-current-genivi-baseline-system-x86_64-generic.img.gz
+[genivi-base-x86-64-raw]: https://download.baserock.org/baserock/baserock-current-genivi-baseline-system-x86_64-generic.img.gz
 
-[genivi-base-armv7lhf-jetson-raw]: http://download.baserock.org/baserock/baserock-current-genivi-baseline-system-armv7lhf-jetson.img.gz
+[genivi-base-armv7lhf-jetson-raw]: https://download.baserock.org/baserock/baserock-current-genivi-baseline-system-armv7lhf-jetson.img.gz
 
-[build-armv7lhf-rootfs]: http://download.baserock.org/baserock/baserock-current-build-system-armv7lhf-rootfs.tar.gz
+[build-armv7lhf-rootfs]: https://download.baserock.org/baserock/baserock-current-build-system-armv7lhf-rootfs.tar.gz

diff --git a/bug-reporting.mdwn b/bug-reporting.mdwn
index 0bf30fe..fff6b70 100644
--- a/bug-reporting.mdwn
+++ b/bug-reporting.mdwn
@@ -2,7 +2,7 @@
 Reporting a bug or a problem in Baserock
 ===========================
 
-The Baserock team is always grateful to be told about issues. Baserock uses [GitLab](https://gitlab.com/groups/baserock/issues) to log bugs and suggestions. Please feel free to make a new issue with your bug (though do check it hasn't been submitted already). Alternatively, you can use #baserock on irc.freenode.net or the [[development mailing list|mailinglist]] to contact the team.
+The Baserock team is always grateful to be told about issues. Baserock uses [GitLab](https://gitlab.com/groups/baserock/issues) to log bugs and suggestions. Please feel free to make a new issue with your bug (though do check it hasn't been submitted already). Alternatively, you can use #baserock on irc.libera.chat or the [[development mailing list|mailinglist]] to contact the team.
 
 Including the following information is helpful and makes it easier to work out what's going on.
 
diff --git a/contributing.mdwn b/contributing.mdwn
index b3a42dd..ff13700 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -7,7 +7,7 @@ Contributing to Baserock
 
 Join the conversation
 ------------
-The baserock community members appreciate feedback, ideas, suggestion, bugs and documentation just as much as code. Please join us on `#baserock` on `irc.freenode.net` and our [development list].
+The baserock community members appreciate feedback, ideas, suggestion, bugs and documentation just as much as code. Please join us on `#baserock` on `irc.libera.chat` and our [development list].
 
 We maintain a [[list of ideas for things to do with Baserock|doing-stuff-with-baserock]].
 
@@ -20,7 +20,7 @@ Please submit changes as [[GitLab merge requests|https://gitlab.com/groups/Build
 The Baserock team is always grateful to be told about issues. Baserock uses
 [GitLab] to log bugs and suggestions. Please feel free to make a new
 issue with your bug (though do check it hasn't been submitted already).
-Alternatively, you can use `#baserock` on `irc.freenode.net` or the
+Alternatively, you can use `#baserock` on `irc.libera.chat` or the
 [development list] to contact the team.
 
 ## Submitting changes via the mailing list
diff --git a/index.mdwn b/index.mdwn
index 72a5be1..b80cf2b 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -23,7 +23,7 @@ See the [[quick-start]] guide.
 There are lots of [guides](http://wiki.baserock.org/guides/) for specific use-cases. Some may be out of date!
 
 If you have questions or suggestions please go to our mailing list at [baserock-dev@baserock.org] or
-the #baserock irc channel on freenode.
+the #baserock irc channel on Libera.
 
 ---
 
@@ -63,7 +63,7 @@ Here is Baserock with Linux 3.15, Nouveau and GENIVI components running on NVIDI
 
 [Video Link](http://player.vimeo.com/video/98459024)
 
-Please join the conversation at `#baserock` on `irc.freenode.net`, or on
+Please join the conversation at `#baserock` on `irc.libera.chat`, or on
 our public development mailing list [baserock-dev@baserock.org]. See the
 [[contact|mailinglist]] page for more details.
 
diff --git a/irc-channel.mdwn b/irc-channel.mdwn
index 363a833..a833baa 100644
--- a/irc-channel.mdwn
+++ b/irc-channel.mdwn
@@ -1,3 +1,3 @@
 [[!meta title="Baserock IRC channel"]]
 
-We use the `#baserock` IRC channel on the `irc.freenode.net` network.
+We use the `#baserock` IRC channel on the `irc.libera.chat` network.
diff --git a/mailinglist.mdwn b/mailinglist.mdwn
index a517c3f..c93b1f1 100644
--- a/mailinglist.mdwn
+++ b/mailinglist.mdwn
@@ -14,7 +14,7 @@ We have a separate list just for announcements: [baserock-announce@baserock.org]
 IRC
 ===
 
-We use the `#baserock` IRC channel on the `irc.freenode.net` network.
+We use the `#baserock` IRC channel on the `irc.libera.chat` network.
 
 
 [baserock-dev@baserock.org]: http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/baserock-dev-baserock.org

diff --git a/wiki.setup b/wiki.setup
index 1563452..b207a2c 100644
--- a/wiki.setup
+++ b/wiki.setup
@@ -48,7 +48,6 @@ add_plugins:
 - relativedate
 - theme
 - toc
-- search
 # plugins to disable
 disable_plugins: []
 # additional directory to search for template files

diff --git a/wiki.setup b/wiki.setup
index aba882e..7da41e0 100644
--- a/wiki.setup
+++ b/wiki.setup
@@ -122,7 +122,7 @@ deterministic: 0
 # htmlscrubber plugin
 # PageSpec specifying pages not to scrub
 #htmlscrubber_skip: '!*/Discussion'
-htmlscrubber_skip: 'index or videos'
+htmlscrubber_skip: index or videos or video-archive or meetup
 
 # inline plugin
 # enable rss feeds by default?

diff --git a/wiki.setup b/wiki.setup
index 7da41e0..1563452 100644
--- a/wiki.setup
+++ b/wiki.setup
@@ -8,7 +8,7 @@
 # Remember to re-run ikiwiki --setup any time you edit this file.
 #
 # name of the wiki
-wikiname: wiki
+wikiname: Baserock
 # contact email for wiki
 #adminemail: me@example.com
 # users who are wiki admins
@@ -40,12 +40,15 @@ rcs: 'git'
 # plugins to add to the default configuration
 add_plugins:
 - sidebar
+- goodstuff
+- recentchangesdiff
 - favicon
 - localstyle
 - headinganchors
 - relativedate
 - theme
 - toc
+- search
 # plugins to disable
 disable_plugins: []
 # additional directory to search for template files
@@ -95,7 +98,7 @@ libdir: ''
 # environment variables
 ENV: {}
 # time zone name
-timezone: :/etc/localtime
+timezone: GMT
 # regexp of normally excluded files to include
 #include: ^\.htaccess$
 # regexp of files that should be skipped

diff --git a/wiki.setup b/wiki.setup
index 70d1e27..aba882e 100644
--- a/wiki.setup
+++ b/wiki.setup
@@ -20,7 +20,7 @@ srcdir: '.'
 # where to build the wiki
 destdir: './public'
 # base url to the wiki
-url: ''
+url: 'https://wiki.baserock.org'
 # url to the ikiwiki.cgi
 cgiurl: ''
 # do not adjust cgiurl if CGI is accessed via different URL

diff --git a/templates/page.tmpl b/templates/page.tmpl
index f7e0eed..144cc48 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -22,7 +22,7 @@
 <TMPL_ELSE>
 <link rel="stylesheet" href="<TMPL_VAR BASEURL>local.css" type="text/css" />
 </TMPL_IF>
-<link href='http://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' type='text/css'>
+<link href='https://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' type='text/css'>
 <link href="//netdna.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css" rel="stylesheet">
 <TMPL_IF EDITURL>
 <link rel="alternate" type="application/x-wiki" title="Edit this page" href="<TMPL_VAR EDITURL>" />

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 0000000..c302296
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,13 @@
+image: debian:buster-slim
+
+pages:
+  stage: deploy
+  script:
+  - apt-get update
+  - apt-get -y install ikiwiki git
+  - ikiwiki --setup wiki.setup
+  artifacts:
+    paths:
+    - public
+  only:
+  - master
diff --git a/wiki.setup b/wiki.setup
new file mode 100644
index 0000000..70d1e27
--- /dev/null
+++ b/wiki.setup
@@ -0,0 +1,398 @@
+# IkiWiki::Setup::Yaml - YAML formatted setup file
+#
+# Setup file for ikiwiki.
+# 
+# Passing this to ikiwiki --setup will make ikiwiki generate
+# wrappers and build the wiki.
+# 
+# Remember to re-run ikiwiki --setup any time you edit this file.
+#
+# name of the wiki
+wikiname: wiki
+# contact email for wiki
+#adminemail: me@example.com
+# users who are wiki admins
+adminuser: []
+# users who are banned from the wiki
+banned_users: []
+# where the source of the wiki is located
+srcdir: '.'
+# where to build the wiki
+destdir: './public'
+# base url to the wiki
+url: ''
+# url to the ikiwiki.cgi
+cgiurl: ''
+# do not adjust cgiurl if CGI is accessed via different URL
+reverse_proxy: 0
+# filename of cgi wrapper to generate
+cgi_wrapper: ''
+# mode for cgi_wrapper (can safely be made suid)
+cgi_wrappermode: 06755
+# number of seconds to delay CGI requests when overloaded
+cgi_overload_delay: ''
+# message to display when overloaded (may contain html)
+cgi_overload_message: ''
+# enable optimization of only refreshing committed changes?
+only_committed_changes: 0
+# rcs backend to use
+rcs: 'git'
+# plugins to add to the default configuration
+add_plugins:
+- sidebar
+- favicon
+- localstyle
+- headinganchors
+- relativedate
+- theme
+- toc
+# plugins to disable
+disable_plugins: []
+# additional directory to search for template files
+templatedir: /usr/share/ikiwiki/templates
+# base wiki source location
+underlaydir: /usr/share/ikiwiki/basewiki
+# display verbose messages?
+#verbose: 1
+# log to syslog?
+#syslog: 1
+# create output files named page/index.html?
+usedirs: 1
+# use '!'-prefixed preprocessor directives?
+prefix_directives: 1
+# use page/index.mdwn source files
+indexpages: 0
+# enable Discussion pages?
+discussion: 1
+# name of Discussion pages
+discussionpage: Discussion
+# use elements new in HTML5 like <section>?
+html5: 0
+# only send cookies over SSL connections?
+sslcookie: 0
+# extension to use for new pages
+default_pageext: mdwn
+# extension to use for html files
+htmlext: html
+# strftime format string to display date
+timeformat: '%c'
+# UTF-8 locale to use
+#locale: en_US.UTF-8
+# put user pages below specified page
+userdir: ''
+# how many backlinks to show before hiding excess (0 to show all)
+numbacklinks: 10
+# attempt to hardlink source files? (optimisation for large files)
+hardlink: 0
+# force ikiwiki to use a particular umask (keywords public, group or private, or a number)
+#umask: public
+# group for wrappers to run in
+#wrappergroup: ikiwiki
+# extra library and plugin directories
+libdirs: []
+# extra library and plugin directory (searched after libdirs)
+libdir: ''
+# environment variables
+ENV: {}
+# time zone name
+timezone: :/etc/localtime
+# regexp of normally excluded files to include
+#include: ^\.htaccess$
+# regexp of files that should be skipped
+#exclude: ^(*\.private|Makefile)$
+# specifies the characters that are allowed in source filenames
+wiki_file_chars: -[:alnum:]+/.:_
+# allow symlinks in the path leading to the srcdir (potentially insecure)
+allow_symlinks_before_srcdir: 0
+# cookie control
+cookiejar:
+  file: /root/.ikiwiki/cookies
+# set custom user agent string for outbound HTTP requests e.g. when fetching aggregated RSS feeds
+useragent: ikiwiki/3.20190228-1
+# theme has a responsive layout? (mobile-optimized)
+responsive_layout: 1
+# try harder to produce deterministic output
+deterministic: 0
+
+######################################################################
+# core plugins
+#   (editpage, htmlscrubber, inline, link, meta, parentlinks, templatebody)
+######################################################################
+
+# htmlscrubber plugin
+# PageSpec specifying pages not to scrub
+#htmlscrubber_skip: '!*/Discussion'
+htmlscrubber_skip: 'index or videos'
+
+# inline plugin
+# enable rss feeds by default?
+#rss: 0
+# enable atom feeds by default?
+#atom: 0
+# allow rss feeds to be used?
+#allowrss: 0
+# allow atom feeds to be used?
+#allowatom: 0
+# urls to ping (using XML-RPC) on feed update
+pingurl: []
+
+######################################################################
+# auth plugins
+#   (anonok, blogspam, emailauth, httpauth, lockedit, moderatedcomments,
+#    opendiscussion, openid, passwordauth, signinedit)
+######################################################################
+
+# anonok plugin
+# PageSpec to limit which pages anonymous users can edit
+#anonok_pagespec: '*/discussion'
+
+# blogspam plugin
+# PageSpec of pages to check for spam
+#blogspam_pagespec: postcomment(*)
+# options to send to blogspam server
+#blogspam_options: blacklist=1.2.3.4,blacklist=8.7.6.5,max-links=10
+# blogspam server JSON url
+#blogspam_server: ''
+
+# emailauth plugin
+# email address to send emailauth mails as (default: adminemail)
+#emailauth_sender: ''
+
+# httpauth plugin
+# url to redirect to when authentication is needed
+#cgiauthurl: http://example.com/wiki/auth/ikiwiki.cgi
+# PageSpec of pages where only httpauth will be used for authentication
+#httpauth_pagespec: '!*/Discussion'
+
+# lockedit plugin
+# PageSpec controlling which pages are locked
+#locked_pages: '!*/Discussion'
+
+# moderatedcomments plugin
+# PageSpec matching users or comment locations to moderate
+#moderate_pagespec: '*'
+
+# openid plugin

(Diff truncated)

diff --git a/guides/how-to-cross-bootstrap.mdwn b/guides/how-to-cross-bootstrap.mdwn
index 4167c3b..bcee522 100644
--- a/guides/how-to-cross-bootstrap.mdwn
+++ b/guides/how-to-cross-bootstrap.mdwn
@@ -45,7 +45,8 @@ We need to fix up the stage2 sysroot so that the source-bundle build we are goin
     mkdir usr/bin/
     ln -s /tools/bin/sh ./usr/bin/sh
     ln -s /tools/bin/bash ./usr/bin/bash
-    tar -cvf ../stage2-ppc64b.tar.gz .
+    cd ..
+    tar -cvf ../stage2-ppc64b.tar.gz ./stage2-ppc64b
 
 ## 2. Boot or chroot the stage 2 sysroot
 

diff --git a/guides/how-to-cross-bootstrap.mdwn b/guides/how-to-cross-bootstrap.mdwn
index 9078d7e..4167c3b 100644
--- a/guides/how-to-cross-bootstrap.mdwn
+++ b/guides/how-to-cross-bootstrap.mdwn
@@ -37,7 +37,15 @@ The stage 2 builds can be cross compiled. We start by doing that to produce a "s
 
     bst --target-arch=ppc64b build bootstrap/stage2-sysroot.bst
     bst --target-arch=ppc64b checkout bootstrap/stage2-sysroot.bst ./stage2-ppc64b
-    tar -cvf ./stage2-ppc64b.tar.gz ./stage2-ppc64b
+
+We need to fix up the stage2 sysroot so that the source-bundle build we are going to do works correctly. Having a symlink from /usr/bin -> /tools/bin is harmful because the source-bundle will install stuff straight into /, so we replace it with a proper directory and just add a symlink for hardcoded shell shebangs.
+
+    cd stage2-ppc64b
+    rm usr/bin
+    mkdir usr/bin/
+    ln -s /tools/bin/sh ./usr/bin/sh
+    ln -s /tools/bin/bash ./usr/bin/bash
+    tar -cvf ../stage2-ppc64b.tar.gz .
 
 ## 2. Boot or chroot the stage 2 sysroot
 

diff --git a/guides/how-to-cross-bootstrap.mdwn b/guides/how-to-cross-bootstrap.mdwn
index ca98cae..9078d7e 100644
--- a/guides/how-to-cross-bootstrap.mdwn
+++ b/guides/how-to-cross-bootstrap.mdwn
@@ -9,112 +9,121 @@ This is the rough process for getting Baserock reference systems to build on a n
 
 Note that BuildStream itself has no defined set of architecture names -- it's up to the definitions authors (i.e. Baserock) to define them. BuildStream's `--arch` argument defaults to the output of `uname -m` which doesn't always correspond to the name we use in Baserock -- for example our `ppc64b` architecture comes up as `ppc64` so we need to always pass `--arch=ppc64b` when building on that architecture. The `arches` section of our [project.conf file](https://gitlab.com/baserock/definitions/blob/master/project.conf) gives an idea of the architecture names that Baserock uses.
 
-To do builds of Baserock on a given platform, first you need an actual
-device that can run the builds. You then need two more things:
+The Baserock reference definitions are written under the assumption that each element will be compiled on the same platform that it will execute on. They require a prebuilt sysroot to build from, which creates a chicken-and-egg problem on new platforms as a prebuilt sysroot may not be available.
 
-  * an OS to install on your device that is capable of running BuildStream
-  * a sysroot that can be used as a base to do an initial build of Baserock's gnu-toolchain.bst stack
+The gnu-toolchain.bst/stage2.bst stack contains specially written elements that can be cross-compiled. To bring up a new platform, we start by cross-building a sysroot and toolchain on an existing platform (usually x86\_64), then we compile the remaining components on the target platform. It's simplest to run the sysroot in a container on the target platform, but you can also boot into it directly.
 
-First this guide describes how to get hold of these things. Once you have them, it describes how to do clean builds and make the new platform a first-class citizen.
+Thus the stages are:
 
-## OS to host BuildStream
+  1. cross-build gnu-toolchain/stage2.bst to create a "stage2" sysroot for the target
+  2. boot or chroot into the stage2 sysroot on the target device
+  3. do a source-bundle build of gnu-toolchain.bst inside the "stage 2" sysroot to create a "stage 3" base.
+  4. set up BuildStream on the target device
+  5. cleanly rebuild gnu-toolchain.bst and push the binaries somewhere
 
-There may be a suitable OS already available for your platform. If so, install that OS on your device, [install BuildStream](https://buildstream.gitlab.io/buildstream/install.html) and move on to the next section.
+You will then be set to run BuildStream builds of the Baserock reference systems on your new device.
 
-If there is no OS available for this platform, you need to do a full cross-bootstrap from a platform that can already do BuildStream builds of Baserock. The usual choice is x86_64.
+Each step is described in more detail below. I'm using the `ppc64b` architecture as a placeholder which you should replace with whatever is your actual target.
 
-> This next section uses the ppc64b architecture as a placeholder. Replace `ppc64b` with whatever architecture you are targetting.
+## 1. Cross-building a stage 2 sysroot
 
 Clone the Baserock definitions.git repo and run the ./convert script, as per the README file.
 
-> For now you need to use branch sam/buildstream-bootstrap
+> **NOTE**: For now you need to use branch sam/buildstream-bootstrap
 
-The elements in `gnu-toolchain/stage2.bst` are written in a special way which means they can be cross-compiled. We start by doing that, to produce a "stage2" sysroot for the target architecture.
+The Baserock's `gnu-toolchain.bst` stack builds GCC three times. This is done to ensure that the final builds are independent from the binaries provided by `gnu-toolchain/base.bst`. Each build is considered a separate stage, hence you will see "stage 2" and "stage 3" referred to in this document. (Note that the elements from stage 3 don't have "stage3" in their names anywhere).
+
+The stage 2 builds can be cross compiled. We start by doing that to produce a "stage 2 sysroot" for the target architecture.
 
     bst --target-arch=ppc64b build bootstrap/stage2-sysroot.bst
     bst --target-arch=ppc64b checkout bootstrap/stage2-sysroot.bst ./stage2-ppc64b
     tar -cvf ./stage2-ppc64b.tar.gz ./stage2-ppc64b
 
-You then need to produce a 'source bundle' of all the other components
-that will be needed to get BuildStream running in the target device.
+## 2. Boot or chroot the stage 2 sysroot
+
+If your target device already has a Linux OS installed on it, you can now copy over the sysroot, extract it somewhere, and use `chroot` to enter it as a container.
 
-    bst --target-arch=ppc64b source-bundle systems/build-system-content.bst
+In possible, we recommend using [Bubblewrap](https://github.com/projectatomic/bubblewrap) instead of `chroot`. This gives a number of benefits such as not requiring 'root' priviliges and automatically mounting special filesystems like /dev.  You can do something like this: 
 
-Finally you need a Linux kernel for your target device. There will hopefully be one supplied by the manufacturer that you can build. If not you will need to come up with a suitable kernel config (out of scope for this guide) and cross-build it. You can create a BuildStream element to wrap the build, for bonus points.
+    bwrap --unshare-user --uid 0 --gid 0 \
+          --bind ./stage2-ppc64b / \
+          --dev /dev --proc /proc --tmpfs /tmp \
+          /tools/bin/sh
 
-You now need to set up the bootloader on your device to load the kernel, and boot into the stage2 sysroot. The exact method will be device-specific and is again out of scope for this guide. Make sure you boot off a large,writeable disk -- the bootstrap build takes lots of space, and it will install stuff directory into `/`. There's no real init system here, so you will need to mount /dev, /proc and /tmp manually:
+If there isn't a Linux OS available for your platform, you will need to find or build a suitable Linux kernel. You will then need to set up the bootloader on your device to load the kernel, and boot into the stage2 sysroot. The exact methods will be device-specific and are out of scope for this guide. Make sure you boot off a large, writeable disk -- the bootstrap build takes lots of space, and it will install stuff directory into `/`.
+
+If not using Bubblewrap, you will need to mount /dev, /proc and /tmp manually as we are not using any 'init' system that would automatically do it. You can run these commands before building:
 
     mount -t devtmpfs none /dev
     mount -t proc none /proc
     mount -t tmpfs none /tmp
 
-Copy the build-system-content.tar.gz archive into `/root` and and extract it.  Enter the `build-system-content/` directory and run `build.sh`.
+# 3. Build a stage 3 sysroot
+
+You may have noticed that our stage 2 sysroot is rather weird-looking and contains most of its files installed into `/tools`. It's not really usable for anything except building the final versions of GCC and the other tools that we need. (For the curious, the stage2 sysroot corresponds closely to the ["Constructing a Temporary System"](http://www.linuxfromscratch.org/lfs/view/stable/chapter05/introduction.html) section of the [Linux From Scratch](http://www.linuxfromscratch.org/) book).
 
-Wait.
+We can't run BuildStream inside the stage 2 sysroot, so instead we get BuildStream to generate a "source bundle" on a different machine. This is a tarball containing the source code for each element and a script that runs each build.
 
-All going well you should end up with a rather messy system that can now execute `bst`.
+You generate it like this:
 
-## Base sysroot
+    bst --target=arch=ppc64b source-bundle bootstrap/stage3-sysroot.bst \
+        --except gnu-toolchain/stage2.bst
 
-You now need to a sysroot for your target that can be used as a base for
-the Baserock bootstrap. It needs to have a basic shell environment with
-the GNU C/C++ compiler and GLIBC headers, GNU Awk, and GNU M4.
+This creates a file named `bootstrap-stage3-sysroot.tar.gz` which you now need to copy and extract on the target device inside the stage2 sysroot dir.
 
-> It would be nice if we could use bootstrap/stage2-sysroot.bst here, but the stage2 components can't be built from themselves (without requiring elaborate hacks).
+You now run the build script contained within the tarball. We need to ensure that it installs the results of each build into an empty directory (the default behaviour is to install to `/`, but the stage2 sysroot contains symlinks from /usr to /tools that will break stuff).  The commands to run are:
 
-If you just did a full cross-bootstrap (i.e. there was no existing OS
-available), your simplest option is to create a tarball of your whole
-filesystem, excluding the `/root` directory, the `/tools` and
-`buildstream` directories used during the bootstrap, and the other
-common "special" directories like `/dev`. Run something like this:
+    export PATH=/usr/bin:/usr/sbin/:/tools/bin:/tools/sbin
+    cd /bootstrap-stage3-sysroot
+    ./build.sh
+
+> This will take time; if you are connected by SSH, consider using [nohup](http://linux.101hacks.com/unix/nohup-command/) so that you don't need to worry about dropped connections stopping your build.
+
+Finally we need to create an archive holding the resulting binaries.  The `build.sh` script installs everything right into `/` (inside the chroot), so we need to include only the bits we need. Run something like this (either from / in the chroot, or from the root directory of the chroot if you're in the host machine).
 
-    cd /root
     cat > ./files-to-exclude <<EOF
-    buildstream/*
-    dev/*
-    home/*
-    lost+found
-    mnt/*
-    proc/*
-    root/*
-    sys/*
-    tools/*
-    tmp/*
+    ./bootstrap-stage3-sysroot
+    ./buildstream
+    ./dev/*
+    ./files-to-exclude
+    ./home/*
+    ./lost+found
+    ./mnt/*
+    ./proc/*
+    ./root/*
+    ./sys/*
+    ./tools
+    ./tmp/*
     EOF
-    tar -X ./files-to-exclude -v -C / -c . -f ./sysroot.tar
+    tar -X ./files-to-exclude -v -c . -f ./sysroot.tar
 
-If you bootstrapped from an existing operating system this may also be
-the quickest route to getting a sysroot. Make sure the necessary
-packages are installed (at least gcc, g++, gawk, make, m4) first.
-You might need to exclude more directories when creating the tar file.
+# 4. Set up BuildStream on the target device
 
-Your other options are:
+If you already have a Linux distribution running on your target device, you can hopefully just [install BuildStream](https://buildstream.gitlab.io/buildstream/install.html) and move on to the next section.
 
-  * Find a Docker suitable container 
+If not, you will need to produce a system image that can run BuildStream. The systems/build-system-content.bst element provides just such a thing, but it can only be native-build so we will have to use `bst source-bundle` again. Run this on your x86_64 machine:
 
-  * Download a root filesystem image, unpack it, chroot in and install
-    the necessary packages, then make a tar file from it. Note that
-    "installer" or "live CD / live USB" images won't work here, you need
-    a plain root file system.
+    bst --target-arch=ppc64b systems/build-system-content.bst \
+        --except systems/gnu-toolchain.bst
 
-  * Use [Debootstrap](https://wiki.debian.org/Debootstrap) (Debian and
-    derivatives only)
+Copy the resulting tar.gz over to the target device where you have already built stage3-sysroot.bst and build it in the same manner.
 
-Once you have your `sysroot.tar` file, it's time to do our first proper
-BuildStream build.
+Again, the results are installed to /. You now need to tar up the resulting filesystem image and boot into it on your device. Test that the `bst` command works and move on to the next step.
 
-## Clean build
+# 5. Cleanly build gnu-toolchain.bst
+
+Now that the `bst` command is available on the target device, we can produce the final binaries. These can be pushed to a shared artifact cache so that the bootstrapping process never needs to be done again.
 
 Start from a Git clone of the Baserock definitions.git repo with a clean work tree. We are going to modify `elements/gnu-toolchain/base.bst` to use our temporary sysroot. Again, `ppc64b` architecture is used as a placeholder.
 
 > At time of writing, you will need to modify base-sdk.bst and base-platform.bst instead. In future there will just be a single base.bst element.
 
-Add a new entry to `host-arches` that imports your sysroot tarball. Something like this:
+Add a new entry to `host-arches` that imports your sysroot tarball.  Something like this:
 
     ppc64b:
       sources:
       - kind: tar
-        url: file:///root/sysroot.tar
+        url: file:///path/to/sysroot.tar
 
 Run `bst --arch=ppc64b track gnu-toolchain/base.bst` which will update the `ref` field with the file's checksum.
 
@@ -128,6 +137,7 @@ Once the binaries are available for download, modify `gnu-toolchain/base.bst` ag
 
 If you have done a full cross-bootstrap, now you should write BuildStream elements that can deploy disk images for your device, try them out, and upload the disk images somewhere so that in future people can just download the disk images instead of going through this long-winded process.
 
+
 How to: Cross-bootstrap using Morph
 ===================================
 

diff --git a/guides/how-to-cross-bootstrap.mdwn b/guides/how-to-cross-bootstrap.mdwn
index bcb7ba0..ca98cae 100644
--- a/guides/how-to-cross-bootstrap.mdwn
+++ b/guides/how-to-cross-bootstrap.mdwn
@@ -343,23 +343,3 @@ add a nameserver entry to it.
 [using baserock]: http://wiki.baserock.org/devel-with/ 
 [using the latest morph]: http://wiki.baserock.org/using-latest-morph/
 
-
-How to: Cross-bootstrap using BuildStream
-=========================================
-
-BuildStream is a new build tool which we hope that [Baserock will adopt soon](https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2017-April/013780.html).
-
-The Baserock definitions format can be converted to BuildStream's format using the [defs2bst](https://gitlab.com/BuildStream/defs2bst/) tool; you may be able to use the ongoing conversion in the [sam/buildstream branch of definitions.git](https://gitlab.com/baserock/definitions/commits/sam/buildstream).
-
-You need a couple of BuildStream patches. (For now).
-
-You need to produce a [host tools tarball](https://samthursfield.wordpress.com/2017/06/19/buildstream-and-host-tools/).
-
-Then build a sysroot and kernel for your target. For example:
-
-    bst --target-arch=armv8b64 build gnu-toolchain/stage2.bst
-    bst --target-arch=armv8b64 build bsp/stage2-linux.bst
-
-You can then use `bst checkout` to check out your build results and use them to boot a system.
-
-We are working on a `bst source-bundle` command that can then be used to bootstrap a Baserock 'build' system.

diff --git a/guides/how-to-cross-bootstrap.mdwn b/guides/how-to-cross-bootstrap.mdwn
index df6d3df..bcb7ba0 100644
--- a/guides/how-to-cross-bootstrap.mdwn
+++ b/guides/how-to-cross-bootstrap.mdwn
@@ -1,5 +1,133 @@
 [[!meta title="How To: Cross-bootstrap"]]
 
+How to: Cross-bootstrap using BuildStream
+=========================================
+
+[[BuildStream]] is a new build tool which we hope that [Baserock will adopt soon](https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2017-April/013780.html). The Baserock definitions currently support BuildStream through an automated conversion script that lives in the definitions.git master branch.
+
+This is the rough process for getting Baserock reference systems to build on a new architecture using BuildStream.  There's no "one size fits all" solution -- please proceed with [gumption](http://robertheaton.com/2013/03/11/coding-with-gumption/).
+
+Note that BuildStream itself has no defined set of architecture names -- it's up to the definitions authors (i.e. Baserock) to define them. BuildStream's `--arch` argument defaults to the output of `uname -m` which doesn't always correspond to the name we use in Baserock -- for example our `ppc64b` architecture comes up as `ppc64` so we need to always pass `--arch=ppc64b` when building on that architecture. The `arches` section of our [project.conf file](https://gitlab.com/baserock/definitions/blob/master/project.conf) gives an idea of the architecture names that Baserock uses.
+
+To do builds of Baserock on a given platform, first you need an actual
+device that can run the builds. You then need two more things:
+
+  * an OS to install on your device that is capable of running BuildStream
+  * a sysroot that can be used as a base to do an initial build of Baserock's gnu-toolchain.bst stack
+
+First this guide describes how to get hold of these things. Once you have them, it describes how to do clean builds and make the new platform a first-class citizen.
+
+## OS to host BuildStream
+
+There may be a suitable OS already available for your platform. If so, install that OS on your device, [install BuildStream](https://buildstream.gitlab.io/buildstream/install.html) and move on to the next section.
+
+If there is no OS available for this platform, you need to do a full cross-bootstrap from a platform that can already do BuildStream builds of Baserock. The usual choice is x86_64.
+
+> This next section uses the ppc64b architecture as a placeholder. Replace `ppc64b` with whatever architecture you are targetting.
+
+Clone the Baserock definitions.git repo and run the ./convert script, as per the README file.
+
+> For now you need to use branch sam/buildstream-bootstrap
+
+The elements in `gnu-toolchain/stage2.bst` are written in a special way which means they can be cross-compiled. We start by doing that, to produce a "stage2" sysroot for the target architecture.
+
+    bst --target-arch=ppc64b build bootstrap/stage2-sysroot.bst
+    bst --target-arch=ppc64b checkout bootstrap/stage2-sysroot.bst ./stage2-ppc64b
+    tar -cvf ./stage2-ppc64b.tar.gz ./stage2-ppc64b
+
+You then need to produce a 'source bundle' of all the other components
+that will be needed to get BuildStream running in the target device.
+
+    bst --target-arch=ppc64b source-bundle systems/build-system-content.bst
+
+Finally you need a Linux kernel for your target device. There will hopefully be one supplied by the manufacturer that you can build. If not you will need to come up with a suitable kernel config (out of scope for this guide) and cross-build it. You can create a BuildStream element to wrap the build, for bonus points.
+
+You now need to set up the bootloader on your device to load the kernel, and boot into the stage2 sysroot. The exact method will be device-specific and is again out of scope for this guide. Make sure you boot off a large,writeable disk -- the bootstrap build takes lots of space, and it will install stuff directory into `/`. There's no real init system here, so you will need to mount /dev, /proc and /tmp manually:
+
+    mount -t devtmpfs none /dev
+    mount -t proc none /proc
+    mount -t tmpfs none /tmp
+
+Copy the build-system-content.tar.gz archive into `/root` and and extract it.  Enter the `build-system-content/` directory and run `build.sh`.
+
+Wait.
+
+All going well you should end up with a rather messy system that can now execute `bst`.
+
+## Base sysroot
+
+You now need to a sysroot for your target that can be used as a base for
+the Baserock bootstrap. It needs to have a basic shell environment with
+the GNU C/C++ compiler and GLIBC headers, GNU Awk, and GNU M4.
+
+> It would be nice if we could use bootstrap/stage2-sysroot.bst here, but the stage2 components can't be built from themselves (without requiring elaborate hacks).
+
+If you just did a full cross-bootstrap (i.e. there was no existing OS
+available), your simplest option is to create a tarball of your whole
+filesystem, excluding the `/root` directory, the `/tools` and
+`buildstream` directories used during the bootstrap, and the other
+common "special" directories like `/dev`. Run something like this:
+
+    cd /root
+    cat > ./files-to-exclude <<EOF
+    buildstream/*
+    dev/*
+    home/*
+    lost+found
+    mnt/*
+    proc/*
+    root/*
+    sys/*
+    tools/*
+    tmp/*
+    EOF
+    tar -X ./files-to-exclude -v -C / -c . -f ./sysroot.tar
+
+If you bootstrapped from an existing operating system this may also be
+the quickest route to getting a sysroot. Make sure the necessary
+packages are installed (at least gcc, g++, gawk, make, m4) first.
+You might need to exclude more directories when creating the tar file.
+
+Your other options are:
+
+  * Find a Docker suitable container 
+
+  * Download a root filesystem image, unpack it, chroot in and install
+    the necessary packages, then make a tar file from it. Note that
+    "installer" or "live CD / live USB" images won't work here, you need
+    a plain root file system.
+
+  * Use [Debootstrap](https://wiki.debian.org/Debootstrap) (Debian and
+    derivatives only)
+
+Once you have your `sysroot.tar` file, it's time to do our first proper
+BuildStream build.
+
+## Clean build
+
+Start from a Git clone of the Baserock definitions.git repo with a clean work tree. We are going to modify `elements/gnu-toolchain/base.bst` to use our temporary sysroot. Again, `ppc64b` architecture is used as a placeholder.
+
+> At time of writing, you will need to modify base-sdk.bst and base-platform.bst instead. In future there will just be a single base.bst element.
+
+Add a new entry to `host-arches` that imports your sysroot tarball. Something like this:
+
+    ppc64b:
+      sources:
+      - kind: tar
+        url: file:///root/sysroot.tar
+
+Run `bst --arch=ppc64b track gnu-toolchain/base.bst` which will update the `ref` field with the file's checksum.
+
+Now you can do a build of the bootstrap/stage3-sysroot.bst element:
+
+    bst --arch=ppc64b build bootstrap/stage3-sysroot.bst
+
+At this point, you have produced sysroot capable of cleanly seeding all future Baserock builds on this platform. If you have the necessary access, push it to releases repo at `ostree-releases@ostree.baserock.org/releases/` following the existing naming convention. If you don't have access to do this, contact us.
+
+Once the binaries are available for download, modify `gnu-toolchain/base.bst` again so that it pulls the sysroot from the https://ostree.baserock.org/releases repo. Test that everything works as expected by building systems/build-system-content.bst. Assuming it all goes well, submit a patch for definitions.git with your changes to base.bst.
+
+If you have done a full cross-bootstrap, now you should write BuildStream elements that can deploy disk images for your device, try them out, and upload the disk images somewhere so that in future people can just download the disk images instead of going through this long-winded process.
+
 How to: Cross-bootstrap using Morph
 ===================================
 

diff --git a/BuildStream.mdwn b/BuildStream.mdwn
index b20251e..009ae2d 100644
--- a/BuildStream.mdwn
+++ b/BuildStream.mdwn
@@ -11,11 +11,7 @@ BuildStream definitions
 
 The current Baserock definitions format is not supported by BuildStream, however a [conversion tool](https://gitlab.com/BuildStream/defs2bst/) is provided.
 
-We are working on an [automated conversion](https://gitlab.com/baserock/definitions/merge_requests/43).
-
-You can find a partial BuildStream conversion of the Baserock reference definitions in [branch sam/buildstream of the definitions.git repo](https://gitlab.com/baserock/definitions/tree/sam/buildstream). Assuming you have [installed BuildStream and its dependencies](https://buildstream.gitlab.io/buildstream/install.html#installing), you can produce a bootable devel-system image by running this command in your definitions.git checkout:
-
-    bst build systems/devel-system-image.bst
+We are working on an [automated conversion](https://gitlab.com/baserock/definitions/merge_requests/52).
 
 Prebuilt artifacts
 ------------------

diff --git a/sidebar.mdwn b/sidebar.mdwn
index fa0607a..3a3cae3 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -6,7 +6,6 @@
 * [[Guides|guides]]
 * [[Videos|videos]]
 * [[Tips & Tricks|tips-and-tricks]]
-* [[Old tutorials|old-tutorials]]
 * [[Report a bug|bug-reporting]]
 * [[Contact|mailinglist]]
 * [[Download Baserock|Download]]

diff --git a/contributing.mdwn b/contributing.mdwn
index cb66e80..b3a42dd 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -11,155 +11,15 @@ The baserock community members appreciate feedback, ideas, suggestion, bugs and
 
 We maintain a [[list of ideas for things to do with Baserock|doing-stuff-with-baserock]].
 
-Get a Baserock OpenID
----------------------
+## Submitting code
 
-You will need a Baserock OpenID if you want to submit changes to the Baserock software for review in gerrit. You can also use your  Baserock OpenID to login to this site if you want to [[contribute to the wiki|editing-the-wiki]].
-
-You can get a Baserock OpenID from [openid.baserock.org](http://openid.baserock.org/accounts/register/)
-
-> Note: it is possible to create multiple OpenIDs with the same email. Baserock's instance of StoryBoard, however, can only use one of these. If you're having issues logging in to StoryBoard, check that you're using the right one.
-
-Set up a gerrit account
------------------------
-
-We use gerrit for tracking and reviewing changes to Baserock software (i.e. the projects stored in the `baserock/*` repos on [git.baserock.org]). If you would like to contribute any changes you will need set up an account at gerrit.baserock.org so that you can submit your changes. To setup your gerrit account, you will need an OpenID from [openid.baserock.org](http://openid.baserock.org).
-
-The following steps can be done on your host machine.
-
-1. Register in [gerrit.baserock.org](http://gerrit.baserock.org/#/q/status:open) - use the Sign In button at the top right
-3. Go to the [settings page](http://gerrit.baserock.org/#/settings/)
-4. Set your 'Username'
-5. Upload your public ssh key
-6. Check it has succeeded by sshing to the 'Username' you set in 4
-
-    `ssh -p 29418 <Username>@gerrit.baserock.org`
-
-    If you have successfully added your key you should see the following
-
-        ****    Welcome to Gerrit Code Review    ****
-        Hi <your name>, you have successfully connected over SSH.
-        Unfortunately, interactive shells are disabled.
-        To clone a hosted Git repository, use:
-        git clone ssh://<Username>@gerrit.baserock.org:29418/REPOSITORY_NAME.git
-        Connection to gerrit.baserock.org closed.
-
-
-Developing your change
---------------------
-You develop your change in your development VM.
-
-### Changing `morph`
-
-To contribute a change to `morph`. do the following:
-
-1. Follow the steps in [Using latest version of Morph](http://wiki.baserock.org/using-latest-morph/), (cloning from gerrit.baserock.org rather than git.baserock.org)
-
-    `git clone ssh://<Username>@gerrit.baserock.org:29418/baserock/baserock/morph  --origin=gerrit`
-
-    (The `--origin=gerrit` option will be useful when 'git-review' is available in Baserock as 'git-review' *knows* about the 'gerrit' remote.)
-
-3. Get the commit-msg hook that is needed to automatically generate the Change-Id's that gerrit needs :
-
-    `scp -p -P 29418 <Username>@gerrit.baserock.org:hooks/commit-msg morph/.git/hooks/`
-
-
-    To find this, navigate to gerrit.baserock.org -> Projects -> List (in the top left), then scroll down to baserock/baserock/morph. Click the 'clone with commit message hook' and 'SSH' buttons (under Project/baserock/baserock/morph). Copy the command displayed just below it into your VM (removing the stuff before 'scp -p')). If there is no 'SSH' button displayed, you need to sign in (top right).
-
-4. Create a branch and hack on morph
-
-        cd morph/
-        git checkout -b my-topic-branch
-        ... #do some stuff`
-
-5. Commit your changes
-6. Run the Morph test suite
-
-        cd /path/to/repo/morph
-        # When running into memory issues use `TMPDIR=/src/tmp ./check`
-        ./check
-
-7. Rebase your commits if necessary - see below
-
-8. When all the tests pass, and your change is ready to be reviewed, push the branch to gerrit for review:
-
-    `git push gerrit HEAD:refs/for/master/my-topic-branch`
-
-### Changing systems defined in definitions.git
-
-To change these systems, follow these steps
-
-        # Clone the definitions repository (if you haven't already done so)
-        git clone git://git.baserock.org/baserock/baserock/definitions
-
-        # Add gerrit as a remote
-        cd definitions/
-        git remote add gerrit ssh://<Username>@gerrit.baserock.org:29418/baserock/baserock/definitions
-
-        # Get the commit-msg hook that generates the Change-Id's that gerrit needs
-        scp -p -P 29418 <Username>@gerrit.baserock.org:hooks/commit-msg .git/hooks/
-
-        # Make and commit the changes to the definitions files
-        ...
-
-Build, deploy and test the changes systems as described in the [Simple build-deploy workflow](http://wiki.baserock.org/guides/build-deploy-cycle/), until you are happy with your changes
-
-Rebase your commits if necessary - see below
-
-When all the tests pass, and your change is ready to be reviewed, push the branch to gerrit for review:
-
-     git push gerrit HEAD:refs/for/master/my-topic-branch
-
-### `Unpack failed` error when pushing changes
-
-If you see this error when you push your changes, 
-
-> git push gerrit HEAD:refs/for/master/my-topic-branch
-> Counting objects: 1, done.
-> Writing objects: 100% (1/1), 263 bytes | 0 bytes/s, done.
-> Total 1 (delta 0), reused 0 (delta 0)
-> error: unpack failed: error Missing tree 337dc3b05e50bea244c8fc6c6bb7d82ddcab55dd
-> fatal: Unpack error, check server log
-> To ssh://yourusername@gerrit.baserock.org:29418/baserock/baserock/definitions
->   ! [remote rejected] HEAD -> refs/for/master/my-topic-branch (n/a (unpacker error))
-> error: failed to push some refs to 'ssh://yourusername@gerrit.baserock.org:29418/baserock/baserock/definitions'
-
-then use the `--no-thin` option as a workaround for [this problem](https://stackoverflow.com/questions/16586642/git-unpack-error-on-push-to-gerrit):
-
-    `git push --no-thin gerrit HEAD:refs/for/master/my-topic-branch`
-
-## Rebasing
-
-(This section may need more work when we have more experience of working with gerrit. Particularly the section about making and resubmitting changes after review - use of the commit hook, and topic ids may make this easier)
-
-Rebasing is always permissible for branches that meet the following
-requirements:
-
-1. The branch has not yet been merged into its target
-2. The branch has not been used as the basis for any other changes which have
-   been merged into anywhere else.
-3. The act of rebasing will simplify or clarify the patches in the branch.
-
-If during patch review, changes are required, then rebasing the branch will
-allow for those changes to be applied to the correct parts of the branch rather
-than on top afterwards.
-
-Ideally, if you are being reviewed on the mailing list then always rebase in a separate branch, producing a new ref with a new
-name, deleting the old ref once you are satisfied with the rebase work.  This
-approach means that the non-corrected patches are less likely to be
-accidentally merged by someone.
-
-If you are being reviewed on gerrit, once you have rebased, push the changes in the same way as you previously did. You should keep the same Change-Id: but can change the rest of the commit log.
-
-## Patch series on Gerrit
-
-You may find when submitting patch series to Gerrit, that patches relying on changes in previous commits in the series are labelled with 'Merge Conflict'. This is due to the conflicting patch relying on some changes earlier in the series, which are not yet merged. This is not a problem, as the patches should all be merged when the series gets merged. This is mostly a problem with Gerrit, and its lack of proper support for patch series.
+Please submit changes as [[GitLab merge requests|https://gitlab.com/groups/BuildStream/merge_requests]].
 
 ## Submitting bug reports
 
 The Baserock team is always grateful to be told about issues. Baserock uses
-[Storyboard] to log bugs and suggestions. Please feel free to make a new
-story with your bug (though do check it hasn't been submitted already).
+[GitLab] to log bugs and suggestions. Please feel free to make a new
+issue with your bug (though do check it hasn't been submitted already).
 Alternatively, you can use `#baserock` on `irc.freenode.net` or the
 [development list] to contact the team.
 
@@ -169,14 +29,14 @@ Details of how to do this are [[here|changes-via-ml]]
 
 You may want to do this
 
-- if gerrit is down or unavailable
+- if GitLab is down or unavailable
 - if you are submitting changes to system components which are not Baserock software i.e. projects mirrored in the  `delta/*` repos on [git.baserock.org])
-- if you don't have the time or inclination to register for gerrit
+- if you don't have the time or inclination to register for GitLab
 
 
 ----
 [Debian]: http://www.debian.org/
 [development list]: http://wiki.baserock.org/mailinglist/
-[Storyboard]: https://storyboard.baserock.org/
+[GitLab]: https://gitlab.com/groups/BuildStream/issues
 [git.baserock.org]: http://git.baserock.org/
 

diff --git a/bug-reporting.mdwn b/bug-reporting.mdwn
index be293c9..0bf30fe 100644
--- a/bug-reporting.mdwn
+++ b/bug-reporting.mdwn
@@ -2,7 +2,7 @@
 Reporting a bug or a problem in Baserock
 ===========================
 
-The Baserock team is always grateful to be told about issues. Baserock uses [Storyboard](https://storyboard.baserock.org/) to log bugs and suggestions. Please feel free to make a new story with your bug (though do check it hasn't been submitted already). Alternatively, you can use #baserock on irc.freenode.net or the [[development mailing list|mailinglist]] to contact the team.
+The Baserock team is always grateful to be told about issues. Baserock uses [GitLab](https://gitlab.com/groups/baserock/issues) to log bugs and suggestions. Please feel free to make a new issue with your bug (though do check it hasn't been submitted already). Alternatively, you can use #baserock on irc.freenode.net or the [[development mailing list|mailinglist]] to contact the team.
 
 Including the following information is helpful and makes it easier to work out what's going on.
 

diff --git a/guides/chroot.mdwn b/guides/chroot.mdwn
index 589896c..655a454 100644
--- a/guides/chroot.mdwn
+++ b/guides/chroot.mdwn
@@ -10,7 +10,7 @@ First, install the following packages from your distribution:
 
 Clone the *baserock-chroot* setup git repository:
 
-    $ git clone git://git.baserock.org/baserock/baserock/baserock-chroot
+    $ git clone https://gitlab.com/baserock/baserock-chroot.git
 
 Generate the tools
 ------------------

diff --git a/BuildStream.mdwn b/BuildStream.mdwn
index 075e5c0..b20251e 100644
--- a/BuildStream.mdwn
+++ b/BuildStream.mdwn
@@ -22,7 +22,7 @@ Prebuilt artifacts
 
 The Baserock project has a BuildStream artifact cache set up at: https://ostree.baserock.org/
 
-Currently there is no web frontend there are no automated builders pushing any artifacts to it, but it's a start!
+Currently there is no web frontend. There is some work on setting up GitLab CI builders to push artifacts to the cache.
 
 To check for remote artifacts in that cache when building, add this to your BuildStream [user config](https://buildstream.gitlab.io/buildstream/config.html#config):
 

diff --git a/BuildStream.mdwn b/BuildStream.mdwn
index 1c6fed4..075e5c0 100644
--- a/BuildStream.mdwn
+++ b/BuildStream.mdwn
@@ -3,11 +3,16 @@ BuildStream and Baserock
 
 [BuildStream](https://buildstream.gitlab.io/buildstream/) is a new build tool which takes ideas from previous Baserock build tools ([[ybd]] and [[Morph]]) and makes them accessible to a much wider audience.
 
+We are aiming to [migrate to BuildStream](https://gitlab.com/baserock/definitions/issues/11).
+
+
 BuildStream definitions
 -----------------------
 
 The current Baserock definitions format is not supported by BuildStream, however a [conversion tool](https://gitlab.com/BuildStream/defs2bst/) is provided.
 
+We are working on an [automated conversion](https://gitlab.com/baserock/definitions/merge_requests/43).
+
 You can find a partial BuildStream conversion of the Baserock reference definitions in [branch sam/buildstream of the definitions.git repo](https://gitlab.com/baserock/definitions/tree/sam/buildstream). Assuming you have [installed BuildStream and its dependencies](https://buildstream.gitlab.io/buildstream/install.html#installing), you can produce a bootable devel-system image by running this command in your definitions.git checkout:
 
     bst build systems/devel-system-image.bst

diff --git a/BuildStream.mdwn b/BuildStream.mdwn
index b9e827a..1c6fed4 100644
--- a/BuildStream.mdwn
+++ b/BuildStream.mdwn
@@ -32,4 +32,4 @@ BuildStream has instructions on [setting up a suitable OSTree artifact cache](ht
 
 To push, you need to add correct `push-url` and `push-port` entries to your BuildStream [user config](https://buildstream.gitlab.io/buildstream/config.html#config).
 
-You should then see artifacts being written to the cache when successfully build.
+You should then see artifacts being written to the cache when successfully built.

diff --git a/BuildStream.mdwn b/BuildStream.mdwn
index 9eee44b..b9e827a 100644
--- a/BuildStream.mdwn
+++ b/BuildStream.mdwn
@@ -3,8 +3,33 @@ BuildStream and Baserock
 
 [BuildStream](https://buildstream.gitlab.io/buildstream/) is a new build tool which takes ideas from previous Baserock build tools ([[ybd]] and [[Morph]]) and makes them accessible to a much wider audience.
 
+BuildStream definitions
+-----------------------
+
 The current Baserock definitions format is not supported by BuildStream, however a [conversion tool](https://gitlab.com/BuildStream/defs2bst/) is provided.
 
 You can find a partial BuildStream conversion of the Baserock reference definitions in [branch sam/buildstream of the definitions.git repo](https://gitlab.com/baserock/definitions/tree/sam/buildstream). Assuming you have [installed BuildStream and its dependencies](https://buildstream.gitlab.io/buildstream/install.html#installing), you can produce a bootable devel-system image by running this command in your definitions.git checkout:
 
     bst build systems/devel-system-image.bst
+
+Prebuilt artifacts
+------------------
+
+The Baserock project has a BuildStream artifact cache set up at: https://ostree.baserock.org/
+
+Currently there is no web frontend there are no automated builders pushing any artifacts to it, but it's a start!
+
+To check for remote artifacts in that cache when building, add this to your BuildStream [user config](https://buildstream.gitlab.io/buildstream/config.html#config):
+
+    artifacts:
+        pull-url: https://ostree.baserock.org/cache/
+
+
+Running your own artifact cache
+-------------------------------
+
+BuildStream has instructions on [setting up a suitable OSTree artifact cache](https://buildstream.gitlab.io/buildstream/artifacts.html#artifacts).
+
+To push, you need to add correct `push-url` and `push-port` entries to your BuildStream [user config](https://buildstream.gitlab.io/buildstream/config.html#config).
+
+You should then see artifacts being written to the cache when successfully build.

diff --git a/BuildStream.mdwn b/BuildStream.mdwn
index 54f589a..9eee44b 100644
--- a/BuildStream.mdwn
+++ b/BuildStream.mdwn
@@ -5,3 +5,6 @@ BuildStream and Baserock
 
 The current Baserock definitions format is not supported by BuildStream, however a [conversion tool](https://gitlab.com/BuildStream/defs2bst/) is provided.
 
+You can find a partial BuildStream conversion of the Baserock reference definitions in [branch sam/buildstream of the definitions.git repo](https://gitlab.com/baserock/definitions/tree/sam/buildstream). Assuming you have [installed BuildStream and its dependencies](https://buildstream.gitlab.io/buildstream/install.html#installing), you can produce a bootable devel-system image by running this command in your definitions.git checkout:
+
+    bst build systems/devel-system-image.bst

diff --git a/BuildStream.mdwn b/BuildStream.mdwn
index 8a4726d..54f589a 100644
--- a/BuildStream.mdwn
+++ b/BuildStream.mdwn
@@ -1,7 +1,7 @@
 BuildStream and Baserock
 ========================
 
-BuildStream is a new build tool which takes ideas from previous Baserock build tools ([[ybd]] and [[Morph]]) and makes them accessible to a much wider audience.
+[BuildStream](https://buildstream.gitlab.io/buildstream/) is a new build tool which takes ideas from previous Baserock build tools ([[ybd]] and [[Morph]]) and makes them accessible to a much wider audience.
 
 The current Baserock definitions format is not supported by BuildStream, however a [conversion tool](https://gitlab.com/BuildStream/defs2bst/) is provided.
 

diff --git a/BuildStream.mdwn b/BuildStream.mdwn
new file mode 100644
index 0000000..8a4726d
--- /dev/null
+++ b/BuildStream.mdwn
@@ -0,0 +1,7 @@
+BuildStream and Baserock
+========================
+
+BuildStream is a new build tool which takes ideas from previous Baserock build tools ([[ybd]] and [[Morph]]) and makes them accessible to a much wider audience.
+
+The current Baserock definitions format is not supported by BuildStream, however a [conversion tool](https://gitlab.com/BuildStream/defs2bst/) is provided.
+

diff --git a/index.mdwn b/index.mdwn
index ffb111c..72a5be1 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -13,6 +13,8 @@ systems on `ppc64`, `mips64b` and `mips64l`, `mips32b` and `mips32l`,
 Our objectives are outlined on the [[overview]] and
 [[developer experience|developer-experience]] pages.
 
+Baserock is developed in public [on GitLab](https://gitlab.com/baserock/).
+
 Getting Started
 ---
 

diff --git a/index.mdwn b/index.mdwn
index 9498ea4..ffb111c 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,15 +1,5 @@
 [[!meta title="Baserock"]]
 
-NEWS: Baserock GENIVI Demo Platform Hands On livecast
-=============================
-
-This was livecast from Seoul in Korea early in the morning on 22nd Oct 2015.
-In the room were a bunch of Jetsons, RPi2s and some bleary-eyed automotive
-software folks...
-<iframe width="560" height="315" src="https://www.youtube.com/embed/UxjJQI9SUxg" frameborder="0" allowfullscreen></iframe>
-
-Instructions are at [[genivi/hands-on-seoul]]
-
 Baserock
 ========
 

diff --git a/guides/how-to-cross-bootstrap.mdwn b/guides/how-to-cross-bootstrap.mdwn
index d66a89d..df6d3df 100644
--- a/guides/how-to-cross-bootstrap.mdwn
+++ b/guides/how-to-cross-bootstrap.mdwn
@@ -1,7 +1,7 @@
 [[!meta title="How To: Cross-bootstrap"]]
 
-How to: Cross-bootstrap
-=======================
+How to: Cross-bootstrap using Morph
+===================================
 
 These are the steps to cross-bootstrap Baserock from one architecture
 to another.
@@ -214,3 +214,24 @@ add a nameserver entry to it.
 [GCC]: http://git.baserock.org/cgi-bin/cgit.cgi/delta/gcc-tarball.git/tree/morph-arch-config?h=baserock/build-essential
 [using baserock]: http://wiki.baserock.org/devel-with/ 
 [using the latest morph]: http://wiki.baserock.org/using-latest-morph/
+
+
+How to: Cross-bootstrap using BuildStream
+=========================================
+
+BuildStream is a new build tool which we hope that [Baserock will adopt soon](https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2017-April/013780.html).
+
+The Baserock definitions format can be converted to BuildStream's format using the [defs2bst](https://gitlab.com/BuildStream/defs2bst/) tool; you may be able to use the ongoing conversion in the [sam/buildstream branch of definitions.git](https://gitlab.com/baserock/definitions/commits/sam/buildstream).
+
+You need a couple of BuildStream patches. (For now).
+
+You need to produce a [host tools tarball](https://samthursfield.wordpress.com/2017/06/19/buildstream-and-host-tools/).
+
+Then build a sysroot and kernel for your target. For example:
+
+    bst --target-arch=armv8b64 build gnu-toolchain/stage2.bst
+    bst --target-arch=armv8b64 build bsp/stage2-linux.bst
+
+You can then use `bst checkout` to check out your build results and use them to boot a system.
+
+We are working on a `bst source-bundle` command that can then be used to bootstrap a Baserock 'build' system.

diff --git a/quick-start.mdwn b/quick-start.mdwn
index 8fcbea5..34f2a5c 100644
--- a/quick-start.mdwn
+++ b/quick-start.mdwn
@@ -11,4 +11,4 @@ If you push to a branch of <https://gitlab.com/baserock/definitions/> it will be
 
 You can also [[cut-and-paste the commands|guides/no-frills]] as shown in  this [[video|https://vimeo.com/110085214]].
 
-Here are some [[ideas for things you might want to do|doing-stuff-with-baserock]], and a [[guide to contributing|contributing]].
+Here are some [[ideas for things you might want to do|doing-stuff-with-baserock]].

diff --git a/index.mdwn b/index.mdwn
index cc9df4d..9498ea4 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -26,17 +26,9 @@ Our objectives are outlined on the [[overview]] and
 Getting Started
 ---
 
-To try Baserock out:
+See the [[quick-start]] guide.
 
-1. Set up a virtual machine running a Baserock image (download image [here](http://wiki.baserock.org/download/), instructions [here](http://wiki.baserock.org/guides/vm-setup/))
-
-2. On your new Baserock VM, [configure some settings and upgrade to a development environment](http://wiki.baserock.org/quick-start/)
-
-3. [Build and deploy things](http://wiki.baserock.org/devel-with/)!
-
-Or, you can start by browsing through the [[build/integration/deployment instructions|definitions]] that we maintain for common software components.
-
-There are lots of [guides](http://wiki.baserock.org/guides/) for specific use-cases.
+There are lots of [guides](http://wiki.baserock.org/guides/) for specific use-cases. Some may be out of date!
 
 If you have questions or suggestions please go to our mailing list at [baserock-dev@baserock.org] or
 the #baserock irc channel on freenode.

diff --git a/quick-start.mdwn b/quick-start.mdwn
index aa3f8f8..8fcbea5 100644
--- a/quick-start.mdwn
+++ b/quick-start.mdwn
@@ -5,9 +5,9 @@ Quick Start
 
 [[!toc startlevel=2]]
 
-The Baserock [[reference definitions|https://gitlab.com/baserock/definitions/]] are hosted in the [[Baserock Gitlab project]](https://gitlab.com/baserock/). You can clone this Git repo and build it locally using the [[ybd]] build tool. 
+The Baserock [reference definitions](https://gitlab.com/baserock/definitions/) are hosted in the [Baserock Gitlab project](https://gitlab.com/baserock/). You can clone with `git clone  https://gitlab.com/baserock/definitions/`, and then build an operating system image locally using the [[ybd]] build tool. 
 
-If you push to a branch of https://gitlab.com/baserock/definitions/ it will be [[automatically tested ]](https://gitlab.com/baserock/definitions/pipelines).
+If you push to a branch of <https://gitlab.com/baserock/definitions/> it will be [automatically tested ](https://gitlab.com/baserock/definitions/pipelines).
 
 You can also [[cut-and-paste the commands|guides/no-frills]] as shown in  this [[video|https://vimeo.com/110085214]].
 

diff --git a/quick-start.mdwn b/quick-start.mdwn
index 77e34b6..aa3f8f8 100644
--- a/quick-start.mdwn
+++ b/quick-start.mdwn
@@ -5,212 +5,10 @@ Quick Start
 
 [[!toc startlevel=2]]
 
+The Baserock [[reference definitions|https://gitlab.com/baserock/definitions/]] are hosted in the [[Baserock Gitlab project]](https://gitlab.com/baserock/). You can clone this Git repo and build it locally using the [[ybd]] build tool. 
 
-This page describes how to setup a Baserock x86 development virtual machine
-and make it ready to use. If you just want to get going as fast as possible, you can
-[[cut-and-paste the commands|guides/no-frills]] as shown in  this [[video|https://vimeo.com/110085214]].
+If you push to a branch of https://gitlab.com/baserock/definitions/ it will be [[automatically tested ]](https://gitlab.com/baserock/definitions/pipelines).
 
-If you want to try Baserock on other Linux systems or in the cloud, check out [[ybd]].
-
-Set up the baserock VM
--------------------------
-
-Follow these steps to setup a Baserock x86 virtual machine
-and make it ready to use.
-
-We provide a build system image; you will need to upgrade to the development system, which has development tools
-installed. We do not provide the development system image as a download, due to issues of size and speed. The section 'Upgrade your baserock VM to a devel VM' below gives details of how to do the upgrade.
-
-Follow the instructions in the [['Create a Baserock VM' guide|guides/vm-setup]] to create and run the baserock VM.
-
-Alternatively see
-
-* [[Setting up a chroot Baserock|guides/chroot]] if your host Linux kernel is compatible with Baserock
-* [[How to get a Baserock devel system running in Docker|guides/docker/#index1h2]].
-* [[Set up a Jetson TK1 as a Baserock ARMv7 development machine|guides/baserock-jetson]]
-
-Login to the baserock VM
----------------------------
-
-Now the VM is running and displaying a console window, you can log in, set a password, and setup SSH access.
-
-To login, type `root` at the VM's Login prompt.
-
-Use `passwd` to set a password.
-
-The VM will now be accessible via the host using `ssh`. The VM uses DHCP to get
-an IP address automatically. To see what IP address was assigned, type `ip addr`.
-
-We normally ssh into a Baserock VM and work there. Putting ssh keys into
-the VM is not a good idea so, having set a nominal password for root on the VM
-itself, on your host, using VirtualBox you can
-
-    ssh-add
-    ssh -A root@vm.ip.address
-
-or if you are using KVM or QEMU
-
-    ssh-add
-    ssh -A -p5555 root@localhost
-
-Then,  to be able to ssh from your VM back to your host without being asked for a password each time, in the host run
-
-    ssh-copy-id root@vm.ip.address
-
-or if you are using KVM or QEMU
-
-    ssh-copy-id -p5555 root@localhost
-
-(The above steps assume that you already have ssh keys on your host machine. If you don't you will need to run `ssh-keygen` - and accept the defaults - before you run them.)
-
-You should now be able to use your host key(s) from within the VM during your
-session, and login to the VM from your host without entering a password.
-(See [Using ssh-agent to manage your keys](http://sshkeychain.sourceforge.net/mirrors/SSH-with-Keys-HOWTO/SSH-with-Keys-HOWTO-6.html) for description of what `ssh-add` does)
-
-
-Add a /src partition to your VM
--------------------------------
-
-It's a good idea to have a separate partition for storing git caches and
-the artifacts morph will produce when you run a morph build. Morph by default
-needs at least 8GB for building/deploying systems. In practice you will want
-much more than this, the exact amount depends on usage, but typically something
-between 50 and 100GB is recommended.
-
-To format with ext4:
-
-    mkfs.ext4 -L src /dev/sdb
-    mkdir /src
-
-then add this line to `/etc/fstab`:
-
-    LABEL=src /src ext4 defaults 0 2
-
-Reboot. /dev/sdb should now be mounted under /src.
-
-Configure Morph
---------------
-
-> This step is applicable to [Baserock chroot|guides/chroot] users as well.
-
-Morph is Baserock's build tool. It comes installed with the Baserock build system.
-
-If you want to use 'bleeding edge morph' see [[using the latest Morph|using-latest-morph]].
-If you intend to upgrade your build system to a devel system, as per the instructions in the later section, you **must** upgrade to the latest version of morph.
-
-Before building, you should create a configuration file for Morph.  We
-recommend that the configuration file is stored in `/src/morph.conf` and it
-should contain the following:
-
-    [config]
-    log = /src/morph.log
-    log-max = 200M
-    cachedir = /src/cache
-    tempdir = /src/tmp
-    # optionally get artifacts from cache, rather than build them
-    # this should be faster (unless you have a very slow network)
-    artifact-cache-server = http://cache.baserock.org:8080/
-
-Then create a symlink to it from `/etc`:
-
-    ln -sv /src/morph.conf /etc/morph.conf
-
-This way if you replace your root disk you only need to re-create the symlink.
-
-By default, Morph will use [git.baserock.org](http://git.baserock.org) as its [Trove](http://wiki.baserock.org/Trove/).
-To configure Morph to use a different Trove, add a `trove-host` line in
-your `morph.conf` e.g.
-
-    trove-host = my-trove.my-domain.co.uk
-
-Configure your Git identity
-----------------------
-
-> This step is applicable to [Baserock chroot|guides/chroot] users as well.
-
-Since Baserock uses git to track most things, you must configure git on the VM
-to use your name and email address:
-
-    git config --global user.name "John Doe"
-    git config --global user.email johndoe@example.com
-
-If you fail to do this, then many of morph's commands will display a warning
-and/or refuse to operate until you configure git correctly.
-
-
-Accessing Baserock guest VM filesystem from host via sshfs
---------------------------------------
-
-If you want to use tools from your host machine when working with files on
-your Baserock guest VM, you can run sshfs on your host, to set up a mount on
-the client's filesystem.
-
-For example, on a mac, running the following would allow you to browse and
-edit files on your guest Baserock /src  partition directly from your MacOS host.
-
-    mkdir ~/baserock-src
-    sshfs root@vm.ip.address:/src /Users/<your-username>/baserock-src
-
-If you are using KVM, the following will mount the `/src` directory in the VM
-to `/vm-src` in the host
-
-    sshfs -o idmap=user root@IP:/src /vm-src
-
-Another solution with VirtualBox is configuring VB to proxy the ssh port
-locally, then running
-
-    sshfs -o idmap=user,port=12345 root@localhost:/src /vm-src
-
-FIXME: Some more details about this *may* be useful
-
-Upgrade your baserock VM to a devel VM
---------------------------------------
-
-Your VM is currently a build system; to use many development tools, you now need to upgrade it to a devel system.
-
-This is a quick guide to get you going with a devel system. Upgrading Baserock systems is described in detail in the [['upgrading Baserock systems' guide|guides/upgrades]].
-
-First, get the build instructions (definitions) for the Baserock reference systems. You can use any clone of definitions.git.
-
-    git clone git://git.baserock.org/baserock/baserock/definitions --branch baserock-16.13
-    cd definitions
-
-Second, build it:
-
-    morph build systems/devel-system-x86_64-generic.morph
-
-Now use [clusters/upgrade-devel.morph] to deploy the result of that build as an
-upgrade to your system. Choose a version label that makes sense to you: 'devel'
-is fine, but some people use the current date as the version label, or other
-things. The label you choose must be valid as a filename.
-
-> **NOTE**: Ensure that your root user has passwordless SSH access to 127.0.0.1 with
-`ssh root@127.0.0.1 whoami`. If not, run `ssh-copy-id root@127.0.0.1`.
-
-    morph upgrade clusters/upgrade-devel.morph self.HOSTNAME=$(hostname) self.VERSION_LABEL=devel
-
-If the deployment succeeded, you'll find that `system-version-manager list` shows
-two versions: 'factory' and 'devel'. The running system should be 'factory'
-(this is the initially deployed version, the name comes from ['factory default']).
-The default system should now be 'devel', meaning that when you reboot your VM
-it will boot into the 'devel' version, which will contain some extra components,
-such as those in the [devtools stratum].

(Diff truncated)

diff --git a/caching.mdwn b/caching.mdwn
index 9783aac..db0d146 100644
--- a/caching.mdwn
+++ b/caching.mdwn
@@ -19,9 +19,9 @@ Baserock build tools don't require any manual versioning. Instead, they automati
 
 Morph's code to calculate cache identity is currently here: <http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/cachekeycomputer.py#n81>
 
-YBD's code to calculate cache identity is currently here: <https://github.com/devcurmudgeon/ybd/blob/master/ybd/cache.py>
+YBD's code to calculate cache identity is here: <https://gitlab.com/baserock/ybd/blob/master/ybd/cache.py>
 
-Both tools will first create a Python dict containing all the factors, then will calculate the SHA256 hash of the dict, to produce a 64-character string that uniquely identifies the artifact. YBD also considers the name of the artifact part of the cache key.
+Both tools will first create a Python dict containing all the factors, then will calculate the SHA256 hash of the dict, to produce a 64-character string that uniquely identifies the artifact. YBD features versioning of the cache-key algorithm itself, and supports sharing of cached artifacts via an artifact server, for example the one at <http://artifacts1.baserock.org:8000>
 
 # Caching in other build/integration/packaging tools
 

diff --git a/caching.mdwn b/caching.mdwn
index 3639dd6..9783aac 100644
--- a/caching.mdwn
+++ b/caching.mdwn
@@ -31,6 +31,8 @@ BitBake: [sstate cache](https://wiki.yoctoproject.org/wiki/Enable_sstate_cache)
 
 CMake: possible with [Artifactory.cmake](https://github.com/raumfeld/Artifactory.cmake) (specifically for use with [JFrog Artifactory])
 
+Nix & GUIX: [package substitutes](https://www.gnu.org/software/guix/manual/html_node/Substitutes.html)
+
 # Related projects
 
 ccache: this caches at the level of individual object files, not whole components. It can coexist with the caching in Baserock build tools.

diff --git a/ybd.mdwn b/ybd.mdwn
index 17f30c5..c42a27c 100644
--- a/ybd.mdwn
+++ b/ybd.mdwn
@@ -15,7 +15,7 @@ Getting Started with ybd and Vagrant
 ------------------------------------------
 After installing vagrant from [[http://www.vagrantup.com/downloads]]
 
-    git clone git://github.com/devcurmudgeon/ybd
+    git clone https://gitlab.com/baserock/ybd.git
     cd ybd
     vagrant up
     vagrant ssh
@@ -33,7 +33,7 @@ Getting Started with ybd on AWS
     pip install fs pyyaml sandboxlib jsonschema requests
 
     # Get ybd
-    git clone git://github.com/devcurmudgeon/ybd    
+    git clone https://gitlab.com/baserock/ybd.git    
     # edit ybd/ybd.conf and set base: '/src'
     # if your machine is big enough, ybd can be configured to run parallel instances,
     # by setting instances: to int(cores/8)
@@ -66,7 +66,7 @@ Getting Started with ybd on Scaleway
     pip install fs pyyaml sandboxlib jsonschema requests bottle
 
     cd /src
-    git clone git://github.com/devcurmudgeon/ybd
+    git clone https://gitlab.com/baserock/ybd.git
     git clone git://git.baserock.org/baserock/baserock/definitions
     echo "base: /src" > ybd/ybd.conf
 
@@ -91,7 +91,7 @@ Getting Started with ybd on DataCentred ARM Cloud (ARMv8)
 
     mkdir /src
     cd /src
-    git clone git://github.com/devcurmudgeon/ybd
+    git clone https://gitlab.com/baserock/ybd.git
     git clone git://git.baserock.org/baserock/baserock/definitions
     echo "base: /src" > ybd/ybd.conf
 
@@ -136,7 +136,7 @@ Then in the chroot you can do 'normal' ybd setup...
 
     mkdir /src
     cd /src
-    git clone git://github.com/devcurmudgeon/ybd
+    git clone https://gitlab.com/baserock/ybd.git
     git clone git://git.baserock.org/baserock/baserock/definitions
     echo "base: /src" > ybd/ybd.conf
     /src/ybd/ybd.py systems/build-system-armv7lhf-jetson.morph

diff --git a/ybd.mdwn b/ybd.mdwn
index c01fd8d..17f30c5 100644
--- a/ybd.mdwn
+++ b/ybd.mdwn
@@ -7,7 +7,7 @@ ybd is a re-implementation of the core build and deploy functionality from morph
 
 Note that first time through ybd needs to clone a lot of git repos, which can take quite a long time. And building a whole system can take a lot of time too. If you use current definitions there is an [[artifact cache | ybd/#index6h2]] which can speed up the initial build dramatically.
 
-The recommended 'version' of ybd at any given time is the latest release tag at [[http://github.com/devcurmudgeon/ybd]]
+The recommended 'version' of ybd at any given time is the latest release tag at [[http://gitlab.com/baserock/ybd]]
 
 [[!toc startlevel=2]]
 

diff --git a/guides/baserock-jetson-genivi.mdwn b/guides/baserock-jetson-genivi.mdwn
index ef6a803..82cdf7c 100644
--- a/guides/baserock-jetson-genivi.mdwn
+++ b/guides/baserock-jetson-genivi.mdwn
@@ -1,56 +1,86 @@
-Baserock Genivi baseline on Jetson Quickstart
+[[!meta title="Baserock Genivi Baseline on Jetson TK1"]]
+
+Baserock Genivi Baseline on Jetson TK1
 ================
 
-This describes how to setup a Jetson TK1 to run a Baserock genivi baseline image.
+[[!toc startlevel=2]]
+
+This page describes how to setup a Jetson TK1 to run Baserock Genivi Baseline, by reflashing with a Genivi Baseline rootfs.
+
 The pre-requisites are
- 
+
 - a Jetson TK1
-- micro-USB cable for flashing (there is one provided with the Jetson)
+- a micro-USB cable for flashing (there is one provided with the Jetson)
+- a working Baserock devel machine (or other Linux) to use as host for flashing the Jetson
 
-You may also want to have 
+You may also want to have
 
-- USB keyboard and HDMI screen to work on the Jetson directly
+- USB keyboard and HDMI screen to play with the Baseline system.
 - USB-serial cable if you want to debug what's going on from your host
-- SATA disk or SSD with cables
 
-[[!toc startlevel=2]]
 
-Flash Genivi Image onto the Jetson
+Flash the Baserock Development image onto the Jetson
 ----------------------------
+> If you're running your host in a VM, make sure that it has access to USB
 
-On your Baserock devel machine or other Linux host
-
-    curl -k -O https://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/Tegra124_Linux_R19.3.0_armhf.tbz2
-    tar xvf Tegra124_Linux_R19.3.0_armhf.tbz2
-    cd Linux_for_Tegra/
-    curl -k -O http://download.baserock.org/baserock/scripts/baserock-jetson-flash.sh
-    chmod +x baserock-jetson-flash.sh
-    mkdir baserock
-    cd baserock/
-    curl -k -O http://download.baserock.org/baserock/baserock-current-genivi-baseline-system-armv7lhf-jetson.img.gz
-    curl -k http://download.baserock.org/baserock/baserock-current-genivi-baseline-system-armv7lhf-jetson.u-boot.bin > u-boot.bin
-    chmod +x u-boot.bin
-    gunzip baserock-current-genivi-baseline-system-armv7lhf-jetson.img.gz
+1) Clone and Build the NVIDIA flashing tools
 
-Connect your host machine to the Jetson using the NVIDIA-provided USB/micro-USB cable. 
+You'll need the open source Nvidia flashing tools built first, and you only have
+to do this once, so create a directory for them to go into, e.g ~/nvidia-tools
 
-> If you're running your host in a VM, make sure that it has access to USB
+    mkdir ~/nvidia-tools
+    export TEGRA_TOOLS_DIR=~/nvidia-tools/
+    cd ~/nvidia-tools
+    git clone git://git.baserock.org/delta/nvidia/cbootimage.git
+    git clone git://git.baserock.org/delta/nvidia/cbootimage-configs.git
+    git clone git://git.baserock.org/delta/dtc.git
+    git clone git://git.baserock.org/delta/nvidia/tegrarcm.git
+    git clone git://git.baserock.org/delta/nvidia/tegra-uboot-flasher-scripts.git
 
-Put the Jetson into "recovery mode" - hold down "FORCE RECOVERY", press "RESET", release "FORCE RECOVERY". See [[elinux|http://elinux.org/Tegra/Boards/NVIDIA_Jetson_TK1]] for full details and a picture.
+Install dependencies (on a Debian-like system)
 
-At this point `lsusb` on your host machine should show something like
+    sudo apt-get install dh-autoreconf libusb-1.0-0-dev libcrypto++-dev flex bison
 
-    Bus 002 Device 002: ID 0955:7140 NVidia Corp.
+Now, to build them
 
-Now you can flash the Jetson (run as root unless you have set up udev so you don't have to)
+    cd tegra-uboot-flasher-scripts
+    ./build-tools
 
-    ./baserock-jetson-flash.sh /full/path/to/Linux_for_Tegra/baserock/baserock-14.40-genivi-baseline-system-armv7lhf-jetson.img
+If there are any errors here, it will most likely be due missing build
+dependencies for tegrarcm (e.g libusb). Once you have satisfied these you can
+run the build tools command again.
 
-> Please give the *full path* to the baserock image, and flashing may take a long time, but you'll see occasional progress updates.
+Please note: The flashing script requires gdisk to be installed, make sure you have this installed, e.g:
 
-Once it finishes you can reboot the Jetson and login as root, no password. Make sure you set a password, so you can SSH in.
+    sudo apt-get install gdisk
 
-What next?
-------------
+You should now have a folder _out_tools in TEGRA_TOOLS_DIR that contains the
+following binaries:
 
-You could try running [[Weston|genivi/#index6h2]] and [[IVI shell|genivi/#index7h2]]
+    cbootimage
+    dtc
+    fdtput
+    tegrarcm
+
+Once you have these, you're ready to flash!
+
+2) Flashing the Jetson
+
+The process is pretty straight forward. Download the image you want to flash,
+and run the script! You need to be root to run this, so do this first, e.g:
+
+    sudo -i
+
+Follow the instructions carefully, and make sure you export
+TEGRA_TOOLS_DIR to the folder that contains the _out_tools folder, e.g
+
+    export TEGRA_TOOLS_DIR=~/nvidia-tools/
+
+Make sure the Jetson *isn't* in recovery mode before doing this, you'll be told
+when to do this during the flashing process (to do this hold down "FORCE RECOVERY", press "RESET", release "FORCE RECOVERY". See [[elinux|http://elinux.org/Tegra/Boards/NVIDIA_Jetson_TK1]] )
+
+    git clone https://gitlab.com/jamesthomas/baserock-flashing-tools.git
+    cd baserock-flashing-tools/
+    curl -k -O https://download.baserock.org/baserock/baserock-current-genivi-baseline-system-armv7lhf-jetson.img.gz
+    gunzip baserock-current-genivi-baseline-system-armv7lhf-jetson.img.gz
+    bash baserock-flash.sh baserock-current-genivi-baseline-system-armv7lhf-jetson.img jetson-tk1

diff --git a/templates/page.tmpl b/templates/page.tmpl
index 95ac877..f7e0eed 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -173,7 +173,7 @@ Last edited <TMPL_VAR MTIME>
 </TMPL_UNLESS>
 <!-- from <TMPL_VAR WIKINAME> -->
 
- <p>All content is Copyright © 2011-2015 the page author(s). The text of
+ <p>All content is Copyright © 2011-2016 the page author(s). The text of
      wiki.baserock.org is formally licensed under <a     href="http://creativecommons.org/licenses/by-sa/4.0/"> the Creative Commons
      Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)</a>.</p>
 

diff --git a/gbo.mdwn b/gbo.mdwn
index 92c73ca..27bf52e 100644
--- a/gbo.mdwn
+++ b/gbo.mdwn
@@ -4,11 +4,12 @@ The Baserock project has been mirroring various upstream projects for several ye
 
 The intended use-cases are 
 
-for people who want to consume upstreams as git repos, from a known server rather than the internet in general
-- people/organisations who just want source for a given FOSS component or set of components
-- people/organisations who want to maintain their own mirror of (some of) the same set of upstreams, along with source for other projects (more FOSS, or proprietary).
+- users wanting to consume upstreams as git repos, from a known server rather than the internet in general
+- users wanting reliable access to source for a given FOSS component or set of components (including their changes, on an ongoing basis)
+- downstream users wanting to maintain their own mirror of (some of) the same set of upstreams, along with source for other projects (more FOSS, or proprietary).
 
 Some general principles apply:
+
 - we convert non-git upstreams (eg hg, bzr, cvs, svn, tarballs) into git
 - g.b.o tracks provenance, so we can see where the original upstream is
 - normally we don't delete repositories, and we don't re-write history

diff --git a/gbo.mdwn b/gbo.mdwn
new file mode 100644
index 0000000..92c73ca
--- /dev/null
+++ b/gbo.mdwn
@@ -0,0 +1,24 @@
+# G.B.O (https://git.baserock.org)
+
+The Baserock project has been mirroring various upstream projects for several years now, at a public-facing server we call g.b.o (git.baserock.org). All of the software which delivers the g.b.o functionality is bundled together in a Baserock appliance called a Trove. Some of the software was originated specifically in the Baserock project, but most of it is independently-maintained FOSS (eg gitano, cgit, bottle etc).
+
+The intended use-cases are 
+
+for people who want to consume upstreams as git repos, from a known server rather than the internet in general
+- people/organisations who just want source for a given FOSS component or set of components
+- people/organisations who want to maintain their own mirror of (some of) the same set of upstreams, along with source for other projects (more FOSS, or proprietary).
+
+Some general principles apply:
+- we convert non-git upstreams (eg hg, bzr, cvs, svn, tarballs) into git
+- g.b.o tracks provenance, so we can see where the original upstream is
+- normally we don't delete repositories, and we don't re-write history
+- if an upstream project disappears or moves to a new location, we maintain the history up to that point
+- if an upstream attempts to re-write its history, we notice, and consider how best to deal with it (has it been hacked? etc)
+
+If you are interested in the above, you may want to create your own Trove, rather than using g.b.o. directly. If so, please note
+
+- we recommend that downstream Troves should mirror from g.b.o., but you could mirror directly from the upstreams if you prefer
+
+- the conversions from non-git upstreams are not deterministic, so if your Trove clones directly from upstreams, your Trove's SHAs will be different from g.b.o for some repositories.
+
+- Troves support namespacing, so you could mirror direct from upstreams as well as from g.b.o.

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index 76146cf..cf6d921 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -12,8 +12,8 @@ See also: <https://en.wikipedia.org/wiki/List_of_build_automation_software>
 [BitBake](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html) recipes | [BitBake](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-metadata) | ✔ | [Setscene](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#setscene) | ✔
 [BOSH](https://bosh.io/) | YAML | ✘ | ? | ✘
 [Bazel](https://bosh.io/) | Bazel (Python-like) | ✘ | ? | ✘
-[Buildroot](http://buildroot.uclibc.org/) | Make | ✘ | ✔
-[CMake](http://cmake.org/) [ExternalProject](https://cmake.org/cmake/help/v3.3/module/ExternalProject.html) / [CPM](https://github.com/iauns/cpm) / [Hunter](https://github.com/ruslo/hunter) / [biicode](http://biicode.com/) | CMake | ✘ | ✔
+[Buildroot](http://buildroot.uclibc.org/) | Make | ✘ | ✘ | ✔
+[CMake](http://cmake.org/) [ExternalProject](https://cmake.org/cmake/help/v3.3/module/ExternalProject.html) / [CPM](https://github.com/iauns/cpm) / [Hunter](https://github.com/ruslo/hunter) / [biicode](http://biicode.com/) | CMake | ✘ | ? | ✔
 [Debian](http://debian.org/) | key-value (debian/control, debian/copyright, debian/changelog), Make (debian/rules) | ✔ | [deb packages](https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics) | ✔
 [GNOME Continuous](https://wiki.gnome.org/Projects/GnomeContinuous) | JSON | ✘ | [ostree](https://wiki.gnome.org/Projects/OSTree) repo | ✘
 [GNOME jhbuild](https://wiki.gnome.org/Projects/Jhbuild) | XML | ✘ | ✘

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index 39fa701..76146cf 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -12,7 +12,7 @@ See also: <https://en.wikipedia.org/wiki/List_of_build_automation_software>
 [BitBake](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html) recipes | [BitBake](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-metadata) | ✔ | [Setscene](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#setscene) | ✔
 [BOSH](https://bosh.io/) | YAML | ✘ | ? | ✘
 [Bazel](https://bosh.io/) | Bazel (Python-like) | ✘ | ? | ✘
-[Buildroot](http://buildroot.uclibc.org/) | Make | ✔ | ✔
+[Buildroot](http://buildroot.uclibc.org/) | Make | ✘ | ✔
 [CMake](http://cmake.org/) [ExternalProject](https://cmake.org/cmake/help/v3.3/module/ExternalProject.html) / [CPM](https://github.com/iauns/cpm) / [Hunter](https://github.com/ruslo/hunter) / [biicode](http://biicode.com/) | CMake | ✘ | ✔
 [Debian](http://debian.org/) | key-value (debian/control, debian/copyright, debian/changelog), Make (debian/rules) | ✔ | [deb packages](https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics) | ✔
 [GNOME Continuous](https://wiki.gnome.org/Projects/GnomeContinuous) | JSON | ✘ | [ostree](https://wiki.gnome.org/Projects/OSTree) repo | ✘

diff --git a/devel-with.mdwn b/devel-with.mdwn
index f9a90d4..3592540 100644
--- a/devel-with.mdwn
+++ b/devel-with.mdwn
@@ -23,7 +23,7 @@ smallest commonly useful Baserock system (the "base system").  To do this, you
 can checkout the current release branch of the Baserock system morphologies and build
 from there:
 
-    git clone git://git.baserock.org/baserock/baserock/definitions --branch baserock-15.47.1
+    git clone git://git.baserock.org/baserock/baserock/definitions --branch baserock-16.13
     cd definitions
     morph --verbose build systems/base-system-x86_64-generic.morph
 
@@ -266,7 +266,7 @@ a new feature branch to work in:
 
     $ git clone git://git.baserock.org/baserock/baserock/definitions
     $ cd definitions
-    $ git checkout baserock-15.47.1 -b test-branch
+    $ git checkout baserock-16.13 -b test-branch
 
 This Git repo contains the definitions for the Baserock 'build' or 'devel'
 system that you are running. The system definition will be in the systems/
diff --git a/quick-start.mdwn b/quick-start.mdwn
index fe6d0a8..77e34b6 100644
--- a/quick-start.mdwn
+++ b/quick-start.mdwn
@@ -172,7 +172,7 @@ This is a quick guide to get you going with a devel system. Upgrading Baserock s
 
 First, get the build instructions (definitions) for the Baserock reference systems. You can use any clone of definitions.git.
 
-    git clone git://git.baserock.org/baserock/baserock/definitions --branch baserock-15.47.1
+    git clone git://git.baserock.org/baserock/baserock/definitions --branch baserock-16.13
     cd definitions
 
 Second, build it:

diff --git a/aby.mdwn b/aby.mdwn
index 11f60a3..6ec22f6 100644
--- a/aby.mdwn
+++ b/aby.mdwn
@@ -145,7 +145,9 @@ removed that.
 
 # Just the commands
 
-    # need to install dependencies such as gcc, patch, glibc-static, libstdc++48-static.x86_64
+    # need to install dependencies....
+    # so for AWS
+    yum install libgcc.x86_64 libstdc++48-static.x86_64 squashfs-tools.x86_64
 
     git clone -b extra-changes https://github.com/gtristan/aboriginal
     git clone -b master https://github.com/gtristan/aboriginal-controller

diff --git a/aby.mdwn b/aby.mdwn
index 2ff74c0..11f60a3 100644
--- a/aby.mdwn
+++ b/aby.mdwn
@@ -143,7 +143,9 @@ I did have a 'tail -f build.log > realoutput.log' running on the host
 system at one point, but this was just expensive for nothing so I
 removed that.
 
-# Just the commands (install dependencies such as gcc, patch, glibc-static)
+# Just the commands
+
+    # need to install dependencies such as gcc, patch, glibc-static, libstdc++48-static.x86_64
 
     git clone -b extra-changes https://github.com/gtristan/aboriginal
     git clone -b master https://github.com/gtristan/aboriginal-controller

diff --git a/aby.mdwn b/aby.mdwn
index ef484e4..2ff74c0 100644
--- a/aby.mdwn
+++ b/aby.mdwn
@@ -143,7 +143,7 @@ I did have a 'tail -f build.log > realoutput.log' running on the host
 system at one point, but this was just expensive for nothing so I
 removed that.
 
-# Just the commands (install patch, glibc)
+# Just the commands (install dependencies such as gcc, patch, glibc-static)
 
     git clone -b extra-changes https://github.com/gtristan/aboriginal
     git clone -b master https://github.com/gtristan/aboriginal-controller

diff --git a/aby.mdwn b/aby.mdwn
index ef1ff4e..ef484e4 100644
--- a/aby.mdwn
+++ b/aby.mdwn
@@ -38,7 +38,7 @@ for now.
 
 Definitions wip branch
 =================
-URL:   https://git.baserock.org/git/baserock/baserock/definitions.git
+URL:   git://git.baserock.org/baserock/baserock/definitions.git
 Branch: baserock/tristan/wip/aboriginal
 
 
@@ -142,3 +142,17 @@ should be somewhere like:
 I did have a 'tail -f build.log > realoutput.log' running on the host
 system at one point, but this was just expensive for nothing so I
 removed that.
+
+# Just the commands (install patch, glibc)
+
+    git clone -b extra-changes https://github.com/gtristan/aboriginal
+    git clone -b master https://github.com/gtristan/aboriginal-controller
+    git clone -b aboriginal https://github.com/gtristan/ybd/
+    git clone -b baserock/tristan/wip/aboriginal git://git.baserock.org/baserock/baserock/definitions.git
+
+    cd aboriginal
+    ENABLE_GPLV3=1 CROSS_COMPILER_HOST=x86_64 SYSIMAGE_TYPE=ext2 ./build.sh armv5l
+    cd ../aboriginal-controller && make
+    
+
+   

diff --git a/aby.mdwn b/aby.mdwn
new file mode 100644
index 0000000..ef1ff4e
--- /dev/null
+++ b/aby.mdwn
@@ -0,0 +1,144 @@
+HOWTO Build (for now)
+--------------------------
+There are now a few moving parts, in order to try this out you are
+going to need the following components:
+
+
+Step 1, Getting the source
+------------------------------
+
+Aboriginal fork
+===========
+URL:    https://github.com/gtristan/aboriginal
+Branch: extra-changes
+
+This fork contains all the parts of the work intended for upstreaming
+to aboriginal proper (port to gcc 5.3, some patches to the kernel
+config), some things from the controller (below) may be added to this
+downstream over time as well.
+
+
+Aboriginal Controller
+================
+URL:    https://github.com/gtristan/aboriginal-controller
+Branch: master
+
+This is a wrapper for the aboriginal launch scripts, it allows
+running the qemu environment in the background as a build slave and
+sending some commands to it over an IPC.
+
+YBD Fork
+=======
+URL:    https://github.com/gtristan/ybd/
+Branch: aboriginal
+
+My downstream ybd work branch which contains the experimental support
+for now.
+
+
+Definitions wip branch
+=================
+URL:   https://git.baserock.org/git/baserock/baserock/definitions.git
+Branch: baserock/tristan/wip/aboriginal
+
+
+
+Step 2, Building stuff
+------------------------
+First, remember to take note of the branches I pointed out in the
+previous section.
+
+
+First build aboriginal
+===============
+You will have to choose 2 things at this point:
+
+- HOST:   The arch you are building on
+- TARGET: The arch you are building for
+
+These are file names in ${ABORIGINAL}/sources/targets, but note that
+not all targets are supported with the newer gcc 5.3 toolchain we
+require.
+
+You can safely use intel arches, armv5l (and probably all the
+supported arm variants) and mips.
+
+To build, choose your host and target and run:
+
+cd /path/to/aboriginal
+ENABLE_GPLV3=1 \
+CROSS_COMPILER_HOST=${HOST} \
+SYSIMAGE_TYPE=ext2 \
+./build.sh ${TARGET}
+
+A reasonable invocation is:
+
+ENABLE_GPLV3=1 \
+CROSS_COMPILER_HOST=x86_64 \
+SYSIMAGE_TYPE=ext2 \
+./build.sh armv5l
+
+This will take anywhere between 30min (modern x86_64 quad core cpu
+with plenty of SSD) to 4hours to complete (reported for older
+dual-core x86 laptop and regular HDD).
+
+Now build the controller
+==================
+To build the controller, you need to have mksquashfs installed. To
+run the controller, you will need socat installed.
+
+To build, just:
+
+cd /path/to/aboriginal-controller
+make
+
+And you are done.
+
+
+Configure YBD
+===========
+For now ybd is hooked up to the emulator in a very nasty way, it
+needs to know both the path to the emulator (aboriginal system image)
+and it needs to know the path to the controller.
+
+Edit the file /path/to/ybd/ybd/config/ybd.conf and add the following:
+
+aboriginal-controller: '/path/to/aboriginal-controller'
+aboriginal-system: '/path/to/aboriginal/build/system-image-armv5l'
+
+To run multiple emulators in parallel, you should remember to also
+add:
+
+instances: 2
+
+NOTE: The aboriginal system image and cross compilers dont really
+have to stay in the aboriginal build directory, but the cross
+compiler must be *beside* the system image wherever it is
+located.
+
+
+Build build-essential using YBD / Aboriginal
+=================================
+Now you can run YBD in the regular way, assuming you have the correct
+definitions branch checked out:
+
+cd /path/to/definitions
+/path/to/ybd/ybd.py strata/build-essential.morph armv5l
+
+The first time you run this, startup will take at least a minute,
+this is because the first time you startup an emulator it will create
+a 1GB swap file.
+
+Subsequent YBD invocations once the swap is built will just pause for
+the time it takes to boot up the emulators.
+
+Logging is copied to the regular place after each build command is
+run, however if you are running a long lived build command and want
+to observe the output, you can look in the staging directory which
+should be somewhere like:
+
+~/ybd/tmp/<tmpdir>/build.log
+
+I did have a 'tail -f build.log > realoutput.log' running on the host
+system at one point, but this was just expensive for nothing so I
+removed that.

diff --git a/releases/baserock-16.13.mdwn b/releases/baserock-16.13.mdwn
index f36d72e..0483411 100644
--- a/releases/baserock-16.13.mdwn
+++ b/releases/baserock-16.13.mdwn
@@ -1,4 +1,3 @@
-DRAFT DRAFT DRAFT
 # Baserock 16.13 is released!
 
 ## Definitions compatibility

diff --git a/releases/baserock-16.13.mdwn b/releases/baserock-16.13.mdwn
index e2e782f..f36d72e 100644
--- a/releases/baserock-16.13.mdwn
+++ b/releases/baserock-16.13.mdwn
@@ -50,8 +50,8 @@ This release is full of changes!
   - ...
 
 
-* Other bugfixes and improvements: see the Git logs of [definitions.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock-16.13)
-  and [morph.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=a7f12476d4e7b2025a60be58027b67b9e551f31b) for a full list.
+* Other bugfixes and improvements: see the Git logs of [definitions.git](http://git.baserock.org/cgit/baserock/baserock/definitions.git/log/?h=baserock-16.13)
+  and [morph.git](http://git.baserock.org/cgit/baserock/baserock/morph.git/log/?h=a7f12476d4e7b2025a60be58027b67b9e551f31b) for a full list.
 
 Thanks to everyone who has provided code, documentation, sponsorship or
 feedback for this Baserock release!

diff --git a/releases.mdwn b/releases.mdwn
index 87cca18..fb0dc68 100644
--- a/releases.mdwn
+++ b/releases.mdwn
@@ -2,7 +2,7 @@
 
 # Baserock releases
 
-* [[Baserock 15.47|releases/baserock-16.13]] was released 31 March 2016
+* [[Baserock 16.13|releases/baserock-16.13]] was released 31 March 2016
 * [[Baserock 15.47|releases/baserock-15.47]] was released 20 November 2015
 * [[Baserock 15.34|releases/baserock-15.34]] was released 21 August 2015
 * [[Baserock 15.25|releases/baserock-15.25]] was released 17 June 2015

diff --git a/releases.mdwn b/releases.mdwn
index edcfe52..87cca18 100644
--- a/releases.mdwn
+++ b/releases.mdwn
@@ -2,6 +2,7 @@
 
 # Baserock releases
 
+* [[Baserock 15.47|releases/baserock-16.13]] was released 31 March 2016
 * [[Baserock 15.47|releases/baserock-15.47]] was released 20 November 2015
 * [[Baserock 15.34|releases/baserock-15.34]] was released 21 August 2015
 * [[Baserock 15.25|releases/baserock-15.25]] was released 17 June 2015

diff --git a/releases/baserock-16.13.mdwn b/releases/baserock-16.13.mdwn
index b830ad9..e2e782f 100644
--- a/releases/baserock-16.13.mdwn
+++ b/releases/baserock-16.13.mdwn
@@ -49,6 +49,7 @@ This release is full of changes!
   - freetype to 2.6.2
   - ...
 
+
 * Other bugfixes and improvements: see the Git logs of [definitions.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock-16.13)
   and [morph.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=a7f12476d4e7b2025a60be58027b67b9e551f31b) for a full list.
 

diff --git a/releases/baserock-16.13.mdwn b/releases/baserock-16.13.mdwn
index a65d6bd..b830ad9 100644
--- a/releases/baserock-16.13.mdwn
+++ b/releases/baserock-16.13.mdwn
@@ -1,4 +1,4 @@
-TODO TODO TODO TODO
+DRAFT DRAFT DRAFT
 # Baserock 16.13 is released!
 
 ## Definitions compatibility
@@ -8,45 +8,48 @@ the definitions format. In 15.47, version 6 was used.
 
 The baserock-16.13 tag of definitions can be built with Morph from 15.47.
 
-The version of Morph in Baserock 15.47 can build definitions versions 7 and 8
+The version of Morph in Baserock 16.13 can build definitions versions 7 and 8
 For more information about these versions, see here: <http://wiki.baserock.org/definitions> and <https://docs.baserock.org>
 
 ## Changes since 15.47
 
-This release is packed full of awesome, see below!
-
-Added a generic IVI system and cluster for x86_64 and Jetson TK1 (TODO)
-Upgraded Qt to 5.6
-
-Various upgrades and new components in the GNOME systems.
-
-Upgraded Git to 2.8.0-rc2 for a security issue (TODO)
-
-Libcal to 2.0.0
-xserver to 1.18.2
-Systemd to v229
-Fuse to 2.9.4
-curl to 7.47.1
-connman 1.31
-alsa-lib and alsa-utils v1.0.29
-bluez to 5.37
-libxml2 to v2.9.3
-libcrypt to 1.5.5
-openssl to 1.0.1s for security issues (TODO)
-mesa to 1.11.2
-libdrm 2.4.67
-xdg-app-common to 0.4.13
-weston/wayland to 1.9.0
-dbus to 1.10.6
-upgraded to a version of glibc without a bug (TODO)
-gstreamer components to 1.6.3
-cgit to v.0.12 for security issues (TODO)
-freetype to 2.6.2
-
-Added fail2ban to Trove systems, see how you can configure it here: <http://wiki.baserock.org/guides/configure-fail2ban/>
-
-
-* Other bugfixes and improvements: see the Git logs of [definitions.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock-15.47)
+This release is full of changes!
+
+* A lot of new components added and upgraded to the GNOME systems, and trust me, when I say "a lot", I mean it.
+
+* Some security related upgrades:
+  - OpenSSL to 1.0.1s
+  - Upgraded Git to 2.8.0-rc2
+  - Cgit to v.0.12 for security issues (TODO)
+  - Upgraded to a recent version of glibc 2.22 branch
+
+* Added fail2ban to Trove systems, see how you can configure it here: <http://wiki.baserock.org/guides/configure-fail2ban/>
+
+
+* Added a generic IVI system and cluster for `x86_64` and Jetson.
+
+* Other various upgrades:
+  - Upgraded Qt to 5.6
+  - Libcal to 2.0.0
+  - xserver to 1.18.2
+  - Systemd to v229
+  - Fuse to 2.9.4
+  - curl to 7.47.1
+  - connman 1.31
+  - alsa-lib and alsa-utils v1.0.29
+  - bluez to 5.37
+  - libxml2 to v2.9.3
+  - libcrypt to 1.5.5
+  - mesa to 1.11.2
+  - libdrm 2.4.67
+  - xdg-app-common to 0.4.13
+  - weston/wayland to 1.9.0
+  - dbus to 1.10.6
+  - gstreamer components to 1.6.3
+  - freetype to 2.6.2
+  - ...
+
+* Other bugfixes and improvements: see the Git logs of [definitions.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock-16.13)
   and [morph.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=a7f12476d4e7b2025a60be58027b67b9e551f31b) for a full list.
 
 Thanks to everyone who has provided code, documentation, sponsorship or
@@ -59,9 +62,8 @@ Start with the following page: <http://wiki.baserock.org/quick-start/>
 Those who are up to speed with Baserock already can make use of the
 'cache.baserock.org' cache server, with the `artifact-cache-server =
 http://cache.baserock.org:8080/` option. All artifacts necessary to
-upgrade a 'build' system for x86_32 or x86_64 are present in this
-cache. An arm rootfs is also provided for those wanting to get started
-with arm boards.
+upgrade a 'build' system for `x86_32`, `x86_64` and `armv7lhf` are present in this
+cache.
 
 # How do I get in contact?
 

diff --git a/releases/baserock-16.13.mdwn b/releases/baserock-16.13.mdwn
index 8e49490..a65d6bd 100644
--- a/releases/baserock-16.13.mdwn
+++ b/releases/baserock-16.13.mdwn
@@ -3,54 +3,51 @@ TODO TODO TODO TODO
 
 ## Definitions compatibility
 
-The Baserock reference systems are defined using version 6 of
-the definitions format. In 15.34, version 5 was used.
+The Baserock reference systems are defined using version 7 of
+the definitions format. In 15.47, version 6 was used.
 
-The baserock-15.47 tag of definitions can be built with Morph from 15.34.
+The baserock-16.13 tag of definitions can be built with Morph from 15.47.
 
-The version of Morph in Baserock 15.47 can build definitions versions 6 and 7.
-For more information about these versions, see here: <http://wiki.baserock.org/definitions>
+The version of Morph in Baserock 15.47 can build definitions versions 7 and 8
+For more information about these versions, see here: <http://wiki.baserock.org/definitions> and <https://docs.baserock.org>
 
-## Changes since 15.34
+## Changes since 15.47
 
 This release is packed full of awesome, see below!
 
-* GNOME!
-  Yes that's right we have GNOME now :D
-  This is still work in progress, but the basic components you need
-  to run a gnome desktop are there.
+Added a generic IVI system and cluster for x86_64 and Jetson TK1 (TODO)
+Upgraded Qt to 5.6
+
+Various upgrades and new components in the GNOME systems.
+
+Upgraded Git to 2.8.0-rc2 for a security issue (TODO)
+
+Libcal to 2.0.0
+xserver to 1.18.2
+Systemd to v229
+Fuse to 2.9.4
+curl to 7.47.1
+connman 1.31
+alsa-lib and alsa-utils v1.0.29
+bluez to 5.37
+libxml2 to v2.9.3
+libcrypt to 1.5.5
+openssl to 1.0.1s for security issues (TODO)
+mesa to 1.11.2
+libdrm 2.4.67
+xdg-app-common to 0.4.13
+weston/wayland to 1.9.0
+dbus to 1.10.6
+upgraded to a version of glibc without a bug (TODO)
+gstreamer components to 1.6.3
+cgit to v.0.12 for security issues (TODO)
+freetype to 2.6.2
+
+Added fail2ban to Trove systems, see how you can configure it here: <http://wiki.baserock.org/guides/configure-fail2ban/>
 
-* Python 3 by default
-  (Python 2 will still be selected if you're building any components
-  that require it.)
-
-* locales! All glibc supported locales are now installed by default!
-
-* Schemas for definitions format
-
-* Rawdisk partitioning support
-
-* install-files: allow definition of manifests in multiple variables
-
-* clang installed by default
-
-* llvm 3.7
-
-* linux-user-chroot v2015.1
-
-* git man pages
-
-* Morph updates:
-
-    - Add support for Baserock definitions version 7.
-      Build systems will soon be defined in a DEFAULTS file in definitions,
-      when this happens you'll be able to define your own custom build systems!
-
-    - It's now an error to define two chunks with the same name within
-      the same system.
 
 * Other bugfixes and improvements: see the Git logs of [definitions.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock-15.47)
-  and [morph.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=fad8048de66fe6aeaa0478864914bb773f51ed3e) for a full list.
+  and [morph.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=a7f12476d4e7b2025a60be58027b67b9e551f31b) for a full list.
 
 Thanks to everyone who has provided code, documentation, sponsorship or
 feedback for this Baserock release!

diff --git a/releases/baserock-16.13.mdwn b/releases/baserock-16.13.mdwn
new file mode 100644
index 0000000..8e49490
--- /dev/null
+++ b/releases/baserock-16.13.mdwn
@@ -0,0 +1,80 @@
+TODO TODO TODO TODO
+# Baserock 16.13 is released!
+
+## Definitions compatibility
+
+The Baserock reference systems are defined using version 6 of
+the definitions format. In 15.34, version 5 was used.
+
+The baserock-15.47 tag of definitions can be built with Morph from 15.34.
+
+The version of Morph in Baserock 15.47 can build definitions versions 6 and 7.
+For more information about these versions, see here: <http://wiki.baserock.org/definitions>
+
+## Changes since 15.34
+
+This release is packed full of awesome, see below!
+
+* GNOME!
+  Yes that's right we have GNOME now :D
+  This is still work in progress, but the basic components you need
+  to run a gnome desktop are there.
+
+* Python 3 by default
+  (Python 2 will still be selected if you're building any components
+  that require it.)
+
+* locales! All glibc supported locales are now installed by default!
+
+* Schemas for definitions format
+
+* Rawdisk partitioning support
+
+* install-files: allow definition of manifests in multiple variables
+
+* clang installed by default
+
+* llvm 3.7
+
+* linux-user-chroot v2015.1
+
+* git man pages
+
+* Morph updates:
+
+    - Add support for Baserock definitions version 7.
+      Build systems will soon be defined in a DEFAULTS file in definitions,
+      when this happens you'll be able to define your own custom build systems!
+
+    - It's now an error to define two chunks with the same name within
+      the same system.
+
+* Other bugfixes and improvements: see the Git logs of [definitions.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock-15.47)
+  and [morph.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=fad8048de66fe6aeaa0478864914bb773f51ed3e) for a full list.
+
+Thanks to everyone who has provided code, documentation, sponsorship or
+feedback for this Baserock release!
+
+# How do I get started?
+
+Start with the following page: <http://wiki.baserock.org/quick-start/>
+
+Those who are up to speed with Baserock already can make use of the
+'cache.baserock.org' cache server, with the `artifact-cache-server =
+http://cache.baserock.org:8080/` option. All artifacts necessary to
+upgrade a 'build' system for x86_32 or x86_64 are present in this
+cache. An arm rootfs is also provided for those wanting to get started
+with arm boards.
+
+# How do I get in contact?
+
+   - IRC: freenode #baserock
+   - Public mailing list: baserock-dev@baserock.org
+   - See also: <http://wiki.baserock.org/mailinglist/>
+
+If you find a bug in Baserock, we'd like to hear from you using one of
+the above methods.
+
+The Baserock project welcomes new participants! We hope you enjoy
+experimenting with Baserock and look forward to hearing about any cool
+things you do with Baserock.

diff --git a/guides/configure-fail2ban.mdwn b/guides/configure-fail2ban.mdwn
index 7e6a6e8..c270313 100644
--- a/guides/configure-fail2ban.mdwn
+++ b/guides/configure-fail2ban.mdwn
@@ -16,6 +16,16 @@ the following contents:
     [sshd]
     enabled = true
 
+Now you can enable and/or start `fail2ban`:
+
+    # systemctl enable fail2ban
+    # systemctl start fail2ban
+
+If you want to see if it's working for your use case, you can have a look
+at `fail2ban` logs:
+
+    # tailf  /var/log/fail2ban.log
+
 You can also have a look at `/etc/fail2ban/jail.conf` for more information
 about `fail2ban` and some configuration examples.
 

diff --git a/guides/configure-fail2ban.mdwn b/guides/configure-fail2ban.mdwn
index 7e8d257..7e6a6e8 100644
--- a/guides/configure-fail2ban.mdwn
+++ b/guides/configure-fail2ban.mdwn
@@ -1,3 +1,6 @@
+# Configuring fail2ban
+
+
 Configuring `fail2ban` in Baserock is fairly easy if you already
 have some knowledge about the tool.
 
@@ -16,3 +19,7 @@ the following contents:
 You can also have a look at `/etc/fail2ban/jail.conf` for more information
 about `fail2ban` and some configuration examples.
 
+> Note: For using fail2ban make sure that fail2ban and iptables are
+> installed in the system. Currently these components are provided
+> by connectivity.morph and fail2ba-common.morph and included by default
+> in Trove systems (17-03-2016)

diff --git a/guides/configure-fail2ban.mdwn b/guides/configure-fail2ban.mdwn
new file mode 100644
index 0000000..7e8d257
--- /dev/null
+++ b/guides/configure-fail2ban.mdwn
@@ -0,0 +1,18 @@
+Configuring `fail2ban` in Baserock is fairly easy if you already
+have some knowledge about the tool.
+
+A simple example for configuring it to ban IPs that make to many
+ssh attempts; create a file `/etc/fail2ban/jail.d/ssh.conf` with
+the following contents:
+
+
+    [DEFAULT]
+    bantime = 3600
+    backend = systemd
+
+    [sshd]
+    enabled = true
+
+You can also have a look at `/etc/fail2ban/jail.conf` for more information
+about `fail2ban` and some configuration examples.
+

diff --git a/guides.mdwn b/guides.mdwn
index 4778a4c..b1acee7 100644
--- a/guides.mdwn
+++ b/guides.mdwn
@@ -70,6 +70,7 @@ Or use [[ybd]]
 * [[Deploy Trove to netboot server on Moonshot|guides/deploy-trove-to-moonshot-netboot]]
 * [[Configure Trove|guides/configuring-a-trove/]]
 * [[Upgrade Trove|guides/upgrade-trove/]]
+* [[Configure fail2ban|guides/configure-fail2ban/]]
 
 ## Distbuild
 * [[How to setup an x86 distbuild network|guides/distbuild]]

diff --git a/guides/increase-space.mdwn b/guides/increase-space.mdwn
index 486598e..ae01f6d 100644
--- a/guides/increase-space.mdwn
+++ b/guides/increase-space.mdwn
@@ -22,4 +22,13 @@ So for example to extend extend a /src partition to 50GB for a VirtualBox machin
 
 Or to extend the / partition on a Jetson
 
-     btrfs filesystem resize max /
+    btrfs filesystem resize max /
+
+
+Or to extend 10G the main disk of a VM (qemu)
+   
+    qemu-img resize <path-to-disk-image> +10G
+
+... and then boot the VM and run
+
+    btrfs filesystem resize max /

diff --git a/guides/vm-setup.mdwn b/guides/vm-setup.mdwn
index 1a2ef1d..3f05fec 100644
--- a/guides/vm-setup.mdwn
+++ b/guides/vm-setup.mdwn
@@ -96,7 +96,7 @@ Bring up a shell prompt, navigate there, and do the following:
 Log out and in again.
 
     # unzip the downloaded rawimage
-    gunzip baserock-current-build-x86_64.img.gz
+    gunzip baserock-current-build-system-x86_64.img.gz
 
     # create a second hard drive for your own files
     fallocate -l $((30*1024*1024*1024)) baserock_src.img
@@ -177,7 +177,7 @@ like to store your VM images (e.g. /Users/yourusername/vm-images)
 Start a Terminal session in that directory, navigate there, and do the
 following:
 
-    gunzip baserock-current-build-x86_64.img.gz
+    gunzip baserock-current-build-system-x86_64.img.gz
 
     qemu-img create -f qcow2 baserock_src.img 30g
 

diff --git a/definitions/planned.mdwn b/definitions/planned.mdwn
index 47bb05e..3ca7b3a 100644
--- a/definitions/planned.mdwn
+++ b/definitions/planned.mdwn
@@ -1,11 +1,6 @@
 [[!meta title="Baserock definitions format, planned changes"]]
 
-This page describes *planned* changes to the Baserock definitions format.
-
-Please propose changes on the [[baserock-dev@baserock.org mailing
-list|mailinglist]] for discussion before adding them here -- this page
-is for tracking changes which are already implemented in Morph and/or YBD but
-not yet used in the Baserock reference system definitions.
-
-See also: [[current]] version, and [[historical]] versions of the format.
+The definitions format is now specified in [spec.git](https://git.baserock.org/cgit/baserock/baserock/spec.git).
 
+To propose changes to the format, please follow the [[contributing]] guide, and submit the changes as patches against [spec.git project](https://gerrit.baserock.org/#/admin/projects/baserock/baserock/spec). For major changes, make sure the baserock-dev list is notified, as
+not everybody reads Gerrit.

diff --git a/definitions/historical.mdwn b/definitions/historical.mdwn
index a85be3a..afe6d50 100644
--- a/definitions/historical.mdwn
+++ b/definitions/historical.mdwn
@@ -1,90 +1,7 @@
 [[!meta title="Baserock definitions format, version history"]]
 
-This page describes the history of the Baserock definitions format.
+# The Baserock definitions format changelog
 
-See also: [[current]] version, and [[planned]] versions.
+The definitions format is now specified in [spec.git](https://git.baserock.org/cgit/baserock/baserock/spec.git).
 
-# Version 7
-
-[Version 7](http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-July/013220.html) adds a DEFAULTS file that specifies predefined build systems and predefined splitting rules. Previously it was up to the build tool to define these.
-
-Note that versions of Morph before commit [d5c616d8287](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?id=d5c616d8287d94514d1323c7b5e6d6d2936a942d) do not implement version 7 correctly.
-
-# Version 6
-
-In definitions version 6, build system autodetection no longer happens. This means
-that any chunk that wants to use one of the predefined build systems (those built
-into Morph) must say so explicitly, using the 'build-system' field.
-
-The build-system field for a chunk can now be specified within a stratum that
-contains it. Previously you needed to add a .morph file for a chunk in order
-to specify its build-system, but we want to avoid needing a .morph file for
-components that follow standard patterns.
-
-Previously, if build-system wasn't given, Morph would scan the contents of the chunk's
-Git repo and try to autodetect which build system was used. This could be slow, could
-fail in confusing ways, and meant that to fully parse definitions you needed access to
-some or all of the repos they referenced.
-
-The chosen build-system affects which predefined command sequences are set for a chunk.
-It is valid to omit the field if a chunk has its own build commands defined in a .morph
-file. When listing the chunks included in a stratum, either 'morph' or 'build-system'
-*must* be specified, but not both (to avoid the possibility of conflicting values).
-
-# Version 5
-
-Morph commit [7f2ccd3d3095a79ad0f3cd0215d062415b20e083](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?id=7f2ccd3d3095a79ad0f3cd0215d062415b20e083) introduces version 5 of the definitions format.
-
-Morph supports defining `strip-commands` in chunk definitions to strip debug symbols from binaries in `DESTDIR`, and default strip commands have been set to strip all elf binaries that are executable or named like a shared library.
-
-This also sets `PYTHONPATH` such that write extensions may use libraries from definitions.git. Write extensions which require this functionality may declare that they are version 5 to prevent versions of morph which don't support this functionality, to produce a version mismatch error rather than deployments failing to locate libraries.
-
-# Version 4
-
-Morph commit [c373f5a403b0ec](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?h=c373f5a403b0ec84834d2f04fd1efac3792a7d35) introduces version 4 of the definitions format. In older versions of Morph the install-files.configure extension would crash if it tried to overwrite a symlink. This bug is fixed in the version of Morph that can build definitions version 4.
-
-If you need to overwrite a symlink at deploytime using install-files.configure, please use VERSION to 4 or above in your definitions.git repo so older versions of Morph gracefully refuse to deploy, instead of crashing.
-
-We have now moved all .configure and .write extensions into the definitions.git repository. Changes like this will not require a version numbering change in future.
-
-# Version 3
-
-Since morph commit [154a760fb88](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?h=154a760fb884cee14c2604b8bfbe52b0e7c0d4b1) morph supports a new architecture (armv5)
-
-This is effectively a change in the definitions format, as old morph doesn't recognize this architecture and will fail if a system with this architecture is added to definitions
-
-Version 3 also allows the new `install-essential-files.configure` extension to be used.
-
-
-# Version 2
-
-1. definitions repo commit [db1fe6e41](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=db1fe6e41bebf7da71d11fe9bc492ede1821f57b)
-1. Version 2 makes paths to non-existent chunk morphs invalid, prior to version 2 morph would simply ignore paths to non-existent chunk morphs and either use the morph in the chunk repo (if there was one) or run build system detection.
-
-   With version 2, if morph encounters a path to a chunk morph that doesn't exist it will error with an error message such as:
-
-   "ERROR: Couldn't find morphology: strata/cats/xattr.morph referenced in strata/swift.morph"
-
-
-# Version 1
-
-The 'build-depends' parameter was made optional. It was previously
-mandatory to specify 'build-depends' for a chunk, even if it was an
-empty list.
-
-
-# Version 0
-
-As of [this commit](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?id=c2d6bf758845076eca6eb71af09df77165993270) morph was updated to check for the presence of a VERSION file, and to parse it for version:
-
-Morph will fail if:
-
-- VERSION file exists
-- and it is a yaml file
-- and it is a dict
-- and has the key 'version'
-- and the contents of the key 'version' is an int
-- and that int is in the list of non_supported_versions (empty
-  at the moment)
-
-Otherwise, morph will assume Version 0 until we add future functionality. Thus Version 0 is default behaviour.
+Please go here to read the version history: <https://docs.baserock.org/changelog>.

diff --git a/definitions/current.mdwn b/definitions/current.mdwn
index 03fde9e..749341a 100644
--- a/definitions/current.mdwn
+++ b/definitions/current.mdwn
@@ -1,518 +1,7 @@
 [[!meta title="Baserock definitions format"]]
 
-The Baserock definitions format
-===============================
+# The Baserock definitions format
 
-This page describes the Baserock definitions format (morph files). It is intended to be useful as
-an *informal* specification. It is not guaranteed to be accurate or exhaustive.
+The definitions format is now specified in [spec.git](https://git.baserock.org/cgit/baserock/baserock/spec.git).
 
-If you are just getting started with Baserock, the [[quick-start]], [[devel-with]] and [[guides]] pages provide a more practical introduction.
-
-The allowed YAML constructs are described in json-schema format here: <http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/schemas>.
-
-The data model is described using OWL here: <http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/schemas/baserock.owl>.
-
-The source code of [[Morph]] and [[YBD]] might be more useful if you need a completely accurate description of how the current Baserock definition format is used in practice.
-
-[[!toc startlevel=2 levels=2]]
-
-Versioning
-----------
-
-The current version of the definitions format is version 7.
-
-See also: the [[planned]] versions, and the [[historical]] versions of the
-format.
-
-Please propose changes to the format described here on the
-[[baserock-dev@baserock.org mailing list|mailinglist]]. Ideally, provide a
-patch for this file against the <git://baserock.branchable.com/> repo, but just
-describing the change you want to make is also fine.
-
-Definitions repository
-----------------------
-
-The design of Baserock aims to encourage users to keep *all* the information
-needed to build and deploy their software in one Git repository. This repo is
-often referred to as the 'definitions.git' repo, although nothing forces you
-to call it that.
-
-Some of this information will be Baserock 'definitions files', which describe
-how to build or deploy some software. Baserock tooling should expect that all
-the definitions it needs to process live in one Git repo. The definitions.git
-repo can and should contain any other files needed for build and deployment as
-well, such as configuration data and documentation.
-
-The Baserock Project maintains a set of 'reference system definitions' at
-[git://git.baserock.org/baserock/baserock/definitions] (which can also be
-referred to as [baserock:baserock/definitions], when using the repo aliasing
-feature of [[Morph]]). That repo contains systems that can be built and
-deployed as-is, but it is important that users can fork this repo as well,
-and work on systems in their version using `git merge` or `git rebase` to keep
-up to date with changes from upstream.
-
-Baserock tooling should not mandate anything about the definitions repo that
-the user wants to process, other than the rules defined below.
-
-
-[git://git.baserock.org/baserock/baserock/definitions]: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git
-[baserock:baserock/definitions]: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git
-
-### Structure
-
-Tooling can enforce that the definitions.git repo is actually a Git repo, but
-it can equally just treat it as a tree of files and directories.
-
-The top directory of the repo must contain a file named `VERSION`, that is
-valid [YAML] and contains a dict with key "version" and a value that is an
-integer.
-
-The integer specifies the version of the definitions format that this repo
-uses. A tool should refuse to process a version that it doesn't support, to
-avoid unpredictable errors. See the "Versioning" heading above for more detail
-on versions.
-
-To find all the Baserock definition files in the repo, tooling can recursively
-scan the contents of the repo for files matching the glob pattern "\*.morph".
-
-Deployment tooling should look in the toplevel directory /only/ for files
-matching the following globs. (The purpose of these files is described in the
-"deployment" section below).
-
-  - `\*.check`
-  - `\*.check.help`
-  - `\*.configure`
-  - `\*.configure.help`
-  - `\*.write`
-  - `\*.write.help`
-
-Definitions file syntax
------------------------
-
-[YAML] is used for all Baserock definitions files.
-
-The toplevel entity in a definition is a dict, in all cases. Any syntax errors
-or type errors (such the toplevel entity being a number, or something) should
-be reported to the user.
-
-The [[Morph]] tool raises an error if any unknown dictionary keys are found in
-the definition, mainly so that it reports any spelling errors in key names.
-
-### Common fields
-
-For all definitions, use the following fields:
-
-* `name`: the name of the definition; it must currently match the filename
-  (without the `.morph` suffix); **required**
-* `kind`: the kind of thing being built; **required**
-* `description`: a comment to describe what the definition is for; optional
-
-### Build definitions: Chunks, Systems and Strata
-
-Within this document, consider 'building' to be the act of running a series of
-commands in a given 'environment', where the commands and how to build the
-environment are completely specified by the definitions and the build tool.
-
-For chunks, use the following fields:
-
-* `build-system`: if the program is built using a build system known to
-  `morph`, you can set this field and avoid having to set the various
-  `*-commands` fields; the commands that the build system specifies can
-  be overridden; the following build-systems are known:
-
-  - `autotools`
-  - `python-distutils`
-  - `cpan`
-  - `cmake`
-  - `qmake`
-
-  optional
-
-* `pre-configure-commands`: a list of shell commands to run at
-  the configuration phase of a build, before the list in `configure-commands`;
-  optional
-* `configure-commands`: a list of shell commands to run at the configuraiton
-  phase of a build; optional
-* `post-configure-commands`: a list of shell commands to run at
-  the configuration phase of a build, after the list in `configure-commands`;
-  optional
-
-* `pre-build-commands`: a list of shell commands to run at
-  the build phase of a build, before the list in `build-commands`;
-  optional
-* `build-commands`: a list of shell commands to run to build (compile) the
-  project; optional
-* `post-build-commands`: a list of shell commands to run at
-  the build phase of a build, after the list in `build-commands`;
-  optional
-
-* `pre-test-commands`: a list of shell commands to run at
-  the test phase of a build, before the list in `test-commands`;
-  optional
-* `test-commands`: a list of shell commands to run unit tests and other
-  non-interactive tests on the built but un-installed project; optional
-* `post-test-commands`: a list of shell commands to run at
-  the test phase of a build, after the list in `test-commands`;
-  optional
-
-* `pre-install-commands`: a list of shell commands to run at
-  the install phase of a build, before the list in `install-commands`;
-  optional
-* `install-commands`: a list of shell commands to ; optional
-* `post-install-commands`: a list of shell commands to run at
-  the install phase of a build, after the list in `strip-commands`;
-  optional
-
-* `pre-strip-commands`: a list of shell commands to run at
-  the strip phase of a build, before the list in `strip-commands`;
-  optional
-* `strip-commands`: a list of shell commands to strip debug symbols from binaries;
-  this should strip binaries in the directory named in the `DESTDIR` environment
-  variable, not the actual system; optional
-* `post-strip-commands`: a list of shell commands to run at
-  the strip phase of a build, after the list in `install-commands`;
-  optional
-
-* `max-jobs`: a string to be given to `make` as the argument to the `-j`
-  option to specify the maximum number of parallel jobs; the only sensible
-  value is `"1"` (including the quotes), to prevent parallel jobs to run
-  at all; parallel jobs are only used during the `build-commands` phase,
-  since the other phases are often not safe when run in parallel; `morph`
-  picks a default value based on the number of CPUs on the host system;
-  optional
-
-* `chunks`: a key/value map of lists of regular expressions;
-  the key is the name
-  of a binary chunk, the regexps match the pathnames that will be
-  included in that chunk; the patterns match the pathnames that get installed
-  by `install-commands` (the whole path below `DESTDIR`); every file must
-  be matched by at least one pattern; by default, a single chunk gets
-  created, named according to the definition, and containing all files;
-  optional
-
-For strata, use the following fields:

(Diff truncated)

diff --git a/definitions.mdwn b/definitions.mdwn
index a6dcb7c..9b89016 100644
--- a/definitions.mdwn
+++ b/definitions.mdwn
@@ -5,19 +5,14 @@
 The Baserock definitions format is a way of specifying components that
 need to be built, deployed and distributed in some way.
 
-The current format is partly described here: [[definitions/current]].
-
-Historical changes are listed here: [[definitions/historical]].
-
-Any planned changes are listed here: [[definitions/planned]]. Making
-changes is not as simple as it could be because changes to the format
-cannot be used in the Baserock reference system definitions until there
-is a build tool capable of building those definitions.
+The spec is defined in the [spec.git] repo. You can also read it at
+<https://docs.baserock.org/spec/>.
 
 You can also see a [[comparison with other formats|definitions/comparison-with-other-formats]], and a [[style guide|definitions/best-practices]].
 
-The most widely used tool for working with Baserock definitions is
-[[Morph]]. You can also use [YBD](http://www.github.com/devcurmudgeon/ybd).
+For building definitions, you can use [[Morph]] or [[YBD]].
+
+[spec.git]: https://git.baserock.org/cgit/baserock/baserock/spec.git
 
 ## The Baserock reference definitions
 

diff --git a/ybd.mdwn b/ybd.mdwn
index cc652e5..c01fd8d 100644
--- a/ybd.mdwn
+++ b/ybd.mdwn
@@ -30,7 +30,7 @@ Getting Started with ybd on AWS
 
     # Get dependencies
     yum install make automake gcc gcc-c++ kernel-devel git gawk python-pip
-    pip install pyyaml sandboxlib jsonschema requests
+    pip install fs pyyaml sandboxlib jsonschema requests
 
     # Get ybd
     git clone git://github.com/devcurmudgeon/ybd    
@@ -63,7 +63,7 @@ Getting Started with ybd on Scaleway
 
     wget https://bootstrap.pypa.io/get-pip.py
     python get-pip.py    
-    pip install pyyaml sandboxlib jsonschema requests bottle
+    pip install fs pyyaml sandboxlib jsonschema requests bottle
 
     cd /src
     git clone git://github.com/devcurmudgeon/ybd
@@ -87,7 +87,7 @@ Getting Started with ybd on DataCentred ARM Cloud (ARMv8)
 
     wget https://bootstrap.pypa.io/get-pip.py
     python get-pip.py    
-    pip install pyyaml sandboxlib jsonschema requests bottle
+    pip install fs pyyaml sandboxlib jsonschema requests bottle
 
     mkdir /src
     cd /src
@@ -131,7 +131,7 @@ Then in the chroot you can do 'normal' ybd setup...
 
     wget https://bootstrap.pypa.io/get-pip.py
     python get-pip.py    
-    pip install pyyaml sandboxlib jsonschema requests bottle
+    pip install ps pyyaml sandboxlib jsonschema requests bottle
     #
 
     mkdir /src

diff --git a/genivi.mdwn b/genivi.mdwn
index 79bd524..4496f47 100644
--- a/genivi.mdwn
+++ b/genivi.mdwn
@@ -217,16 +217,7 @@ Boot the new system in the exact same way as the old one:
 How to run Weston in Baserock GENIVI Baseline
 ---------------------------------------------
 
-To run Weston in Baserock GENIVI Baseline you have to first set an XDG variable
-that weston requires:
-
-    export XDG_RUNTIME_DIR=/tmp/runtime-dir
-    mkdir $XDG_RUNTIME_DIR
-    chmod 0700 $XDG_RUNTIME_DIR
-
-Then run weston with the fbdev backend:
-
-    weston --backend=fbdev-backend.so
+    weston
 
 How to run Weston ivi-shell in Baserock GENIVI Baseline
 -------------------------------------------------------

diff --git a/build-times.mdwn b/build-times.mdwn
index 39c6fbc..2d3faf9 100644
--- a/build-times.mdwn
+++ b/build-times.mdwn
@@ -6,7 +6,7 @@ We've had quite a lot of interest in how fast native builds on ARM compare with
 - there are some repeats, so you can see that the time taken to build a specific component can vary
 - some of the variations are likely to be due to network/io
 
-There are a selection of actual build logs from ybd on various machines and configurations at [[devcurmudgeon/build-logs|https://github.com/devcurmudgeon/build-logs]] - if you collect more, please send pull requests :)
+There is a collection of actual build logs from ybd on various machines and configurations at [[devcurmudgeon/build-logs|https://github.com/devcurmudgeon/build-logs]] - if you collect more, please send pull requests :)
 
 [[!toc startlevel=2]]
 

diff --git a/build-times.mdwn b/build-times.mdwn
index 7b2c5a3..39c6fbc 100644
--- a/build-times.mdwn
+++ b/build-times.mdwn
@@ -6,6 +6,8 @@ We've had quite a lot of interest in how fast native builds on ARM compare with
 - there are some repeats, so you can see that the time taken to build a specific component can vary
 - some of the variations are likely to be due to network/io
 
+There are a selection of actual build logs from ybd on various machines and configurations at [[devcurmudgeon/build-logs|https://github.com/devcurmudgeon/build-logs]] - if you collect more, please send pull requests :)
+
 [[!toc startlevel=2]]
 
 ## on x86 i7 MacBookPro (virtual machine)
@@ -2677,4 +2679,3 @@ Then you can use grep to get build times, eg
 To produce these stats, delete all the artifacts[sic] from `/src/cache`, which will force everything to be rebuilt. Delete the morph log. Run the build. Go and do something else for a few hours and, when it eventually completes the build, run the following script on the morph log.
 
     LANG= perl -ne 'if (/\[([^]]+)\] Elapsed time (\d+:\d+:\d+)/) { $x{$2}.="$1 "; } END { for my $t (reverse sort keys %x) { for (sort split(/ /,$x{$t})) { printf "%s [%s]\n", $t, $_; } } }' morph.log
-

diff --git a/build-times.mdwn b/build-times.mdwn
index 8f7253b..7b2c5a3 100644
--- a/build-times.mdwn
+++ b/build-times.mdwn
@@ -2662,10 +2662,19 @@ We've had quite a lot of interest in how fast native builds on ARM compare with
 00:00:08 [fhs-dirs]
 </pre>
 
-## How to produce build times statistics
+## How to produce build times statistics with ybd
+
+ybd outputs lots of elapsed times to its console. To keep that information you can either cut and paste it, or tee it into a file, eg
+
+    ../ybd/ybd.py systems/genivi-baseline-system-armv7lhf-jetson.morph armv7lhf | tee some-memorable-name.log
+
+Then you can use grep to get build times, eg
+
+    cat  some-memorable-name.log | grep Elapsed | grep build
+
+## How to produce build times statistics with morph
 
 To produce these stats, delete all the artifacts[sic] from `/src/cache`, which will force everything to be rebuilt. Delete the morph log. Run the build. Go and do something else for a few hours and, when it eventually completes the build, run the following script on the morph log.
 
     LANG= perl -ne 'if (/\[([^]]+)\] Elapsed time (\d+:\d+:\d+)/) { $x{$2}.="$1 "; } END { for my $t (reverse sort keys %x) { for (sort split(/ /,$x{$t})) { printf "%s [%s]\n", $t, $_; } } }' morph.log
 
-

diff --git a/guides/release-process.mdwn b/guides/release-process.mdwn
index cbf82ef..bc045d0 100644
--- a/guides/release-process.mdwn
+++ b/guides/release-process.mdwn
@@ -145,13 +145,11 @@ scripts are slow and can take several hours!
 2. Generate a license manifest for each baseline system, using the
    `license-check` script in definitions.git:
 
-        scripts/licensecheck.sh systems/genivi-baseline-system-armv7lhf-jetson.morph > \
+        scripts/licensecheck.py systems/genivi-baseline-system-armv7lhf-jetson.morph > \
             /src/release/genivi-baseline-system-armv7lhf-jetson-license-manifest.txt
-        scripts/licensecheck.sh systems/genivi-baseline-system-x86_64-generic.morph > \
+        scripts/licensecheck.py systems/genivi-baseline-system-x86_64-generic.morph > \
             /src/release/genivi-baseline-system-x86_64-generic-license-manifest.txt
 
-   > **NOTE**: You will need the release checkout to run the licensecheck
-       script
 
 3. Extract the kernel zImage file from the ARMv7lhf system, by loopback
    mounting it and copying the file out. (FIXME: there is an unmerged patch in

diff --git a/definitions/historical.mdwn b/definitions/historical.mdwn
index 6dc1bef..a85be3a 100644
--- a/definitions/historical.mdwn
+++ b/definitions/historical.mdwn
@@ -4,6 +4,12 @@ This page describes the history of the Baserock definitions format.
 
 See also: [[current]] version, and [[planned]] versions.
 
+# Version 7
+
+[Version 7](http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-July/013220.html) adds a DEFAULTS file that specifies predefined build systems and predefined splitting rules. Previously it was up to the build tool to define these.
+
+Note that versions of Morph before commit [d5c616d8287](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?id=d5c616d8287d94514d1323c7b5e6d6d2936a942d) do not implement version 7 correctly.
+
 # Version 6
 
 In definitions version 6, build system autodetection no longer happens. This means

diff --git a/definitions/planned.mdwn b/definitions/planned.mdwn
index 926fe7b..47bb05e 100644
--- a/definitions/planned.mdwn
+++ b/definitions/planned.mdwn
@@ -4,11 +4,8 @@ This page describes *planned* changes to the Baserock definitions format.
 
 Please propose changes on the [[baserock-dev@baserock.org mailing
 list|mailinglist]] for discussion before adding them here -- this page
-is for tracking changes which are already implemented in Morph and will
-be used after the next release.
+is for tracking changes which are already implemented in Morph and/or YBD but
+not yet used in the Baserock reference system definitions.
 
 See also: [[current]] version, and [[historical]] versions of the format.
 
-# Version 7
-
-Proposal accepted: <http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-July/013220.html>

diff --git a/definitions/current.mdwn b/definitions/current.mdwn
index ab639a8..03fde9e 100644
--- a/definitions/current.mdwn
+++ b/definitions/current.mdwn
@@ -19,7 +19,7 @@ The source code of [[Morph]] and [[YBD]] might be more useful if you need a comp
 Versioning
 ----------
 
-The current version of the definitions format is version 6.
+The current version of the definitions format is version 7.
 
 See also: the [[planned]] versions, and the [[historical]] versions of the
 format.

diff --git a/conferences.mdwn b/conferences.mdwn
index 97cd3ff..152f640 100644
--- a/conferences.mdwn
+++ b/conferences.mdwn
@@ -19,6 +19,7 @@ None planned at the moment. Go [propose some talks!](http://lwn.net/Calendar/Mon
 
 # Past talks
 
+- [The Story of a Declarative & Structured Format for Build and Integration Instructions](https://fosdem.org/2016/schedule/event/format_for_build_and_integration_instructions/) by Sam Thursfield at [FOSDEM] 2016
 - [Introduction to Baserock](https://www.youtube.com/watch?v=qYGlMCk15hs) by Sam Thursfield at [EuroPython 2015](https://ep2015.europython.eu/en/)
 -   [Live atomic updates](https://fosdem.org/2015/schedule/event/live_atomic_updates/)
 by Richard Maw at [FOSDEM] 2015

diff --git a/subprojects/gnome.mdwn b/subprojects/gnome.mdwn
deleted file mode 100644
index 070ab6f..0000000
--- a/subprojects/gnome.mdwn
+++ /dev/null
@@ -1,84 +0,0 @@
-[[!meta title="Building GnomeOS using Baserock"]]
-
-# WARNING
-
-Baserock is still under development, so this procedure may change. The GNOME
-stratum contains only a minimal set of components and is built mostly from
-master, so it normally doesn't work. However, it's a good way to get started
-building something fun with Baserock and testing the bleeding-edge versions of
-X and GNOME.
-
-Help is available in #baserock, and comments and patches are welcome to
-baserock-dev@baserock.org as well.
-
-# A build VM
-
-Read the [[quick-start]] instructions to set up a Baserock virtual machine.
-Next, follow the [[devel-with]] instructions to turn it into a build
-environment, but with a few changes:
-
-* Instead of using `morph` from master, use the
-  samthursfield/set-configure-args-from-stratum-2 branch. This provides the
-  ability to set configure arguments from a stratum without needing to branch
-  the upstream repository, which has useful for prototyping the GNOME strata
-  and is a feature that will be merged into Morph master at a later date.
-
-* And make sure you always run /src/morph/morph - symlink it to /usr/bin/morph
-  if necessary.
-
-# Running the build
-
-The extra morphologies are in a branch of baserock:baserock/morphs named
-samthursfield/gnomeos. You can't quite build the GnomeOS system directly,
-though, because of a wrinkle in the current version of Baserock. `gcc` is
-branched in the samthursfield/gnomeos branch so that it provides a shared
-libstdc++, which is required for Mesa to build. First you must rebuild the
-devel stratum so that this new gcc is built:
-
-    ./morph build-morphology baserock:baserock/morphs samthursfield/gnomeos devel
-
-Next, retrieve the built gcc artifact from /src/cache/artifacts. You can
-find the correct artifact by running:
-
-    ls -l1t /src/cache/artifacts/*.chunk.gcc
-
-Copy the file at the top of the list (the newest) to /src. Then open
-/src/morph.conf and append the path to the 'staging-filler' line, so it
-reads something like this:
-
-    staging-filler = /src/square-pyramid-x86_64-filler.tar.gz,
-        /src/c8e351421993a4bc42f8a071e144a6fc912f7cd34e9a3aba061e656c86656743.chunk.gcc
-
-We have now overridden the prebuilt gcc from square-pyramid with our own
-version, which allows Mesa to use libstdc++ when building. In the future,
-replacing parts of the staging filler will be handled automatically by Morph,
-so this step will become unnecessary. (We will also be reorganising the
-foundation and devel strata so that libstdc++ is always available).
-
-You should now be able to get a complete build of a system by running:
-
-    ./morph build-morphology baserock:baserock/morphs samthursfield/gnomeos \
-      gnomeos-system-x86_64
-
-Hours will pass, and you will get a new system image as a result that can
-be booted into and played with.
-
-# Development
-
-If you want to go beyond just building the system, this is currently
-a little awkward for people who don't have access to git.baserock.org.
-However, it is possible, and how to do so is described in the
-[[devel-with]] instructions.
-
-# Known issues (beyond "nothing really works")
-
-##  Updating git repos takes a long time
-
-This is because we pull a lot of components from upstream git repos right
-now, instead of mirroring them with Lorry. Use the morph '--no-git-update'
-option to avoid the updating gits phase.
-
-## Mesa fails with "configure: error: LLVM is required to build Gallium R300 on x86 and x86_64"
-
-Make sure you use the samthursfield/set-configure-args-from-stratum-2 branch
-of Morph!

diff --git a/moving-parts.mdwn b/moving-parts.mdwn
index e9bf2a7..cc36f64 100644
--- a/moving-parts.mdwn
+++ b/moving-parts.mdwn
@@ -9,7 +9,7 @@ The main parts of Baserock are:
 - [[Lorry]] - a tool for collecting upstream source, converting into Git if required
 - [[Trove]] - a Baserock appliance to host git repos collected by Lorry, and/or created by Baserock users
 - [git.baserock.org](http://git.baserock.org) - our 'master' instance of a Trove, containing all the upstreams we are integrating
-- [[definitions|the Baserock Definitions format]] - YAML language for describing build+integration instructions
+- [[the Baserock Definitions format|definitions]] - YAML language for describing build+integration instructions
 - [Reference system definitions](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/) - a git repo defining various Baserock reference systems
 - [[Trebuchet]] - a tool for updating Baserock systems, based on BTRFS snapshots
 - [[tbdiff|Trebuchet/tbdiff]] - a tool used by Trebuchet to create binary diffs between directory trees

diff --git a/moving-parts.mdwn b/moving-parts.mdwn
index 6b3ba82..e9bf2a7 100644
--- a/moving-parts.mdwn
+++ b/moving-parts.mdwn
@@ -9,6 +9,7 @@ The main parts of Baserock are:
 - [[Lorry]] - a tool for collecting upstream source, converting into Git if required
 - [[Trove]] - a Baserock appliance to host git repos collected by Lorry, and/or created by Baserock users
 - [git.baserock.org](http://git.baserock.org) - our 'master' instance of a Trove, containing all the upstreams we are integrating
+- [[definitions|the Baserock Definitions format]] - YAML language for describing build+integration instructions
 - [Reference system definitions](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/) - a git repo defining various Baserock reference systems
 - [[Trebuchet]] - a tool for updating Baserock systems, based on BTRFS snapshots
 - [[tbdiff|Trebuchet/tbdiff]] - a tool used by Trebuchet to create binary diffs between directory trees

diff --git a/caching.mdwn b/caching.mdwn
index fd49cff..3639dd6 100644
--- a/caching.mdwn
+++ b/caching.mdwn
@@ -29,14 +29,16 @@ Buildroot: no built-in support
 
 BitBake: [sstate cache](https://wiki.yoctoproject.org/wiki/Enable_sstate_cache)
 
-CMake: possible with [Artifactory.cmake](https://github.com/raumfeld/Artifactory.cmake)
+CMake: possible with [Artifactory.cmake](https://github.com/raumfeld/Artifactory.cmake) (specifically for use with [JFrog Artifactory])
 
 # Related projects
 
 ccache: this caches at the level of individual object files, not whole components. It can coexist with the caching in Baserock build tools.
 
-[JFrog Artifactory](https://www.jfrog.com/artifactory/): commercial artifact cache server. No Baserock build tools integrate with Artifactory, currently.
+[JFrog Artifactory]\: commercial artifact cache server. No Baserock build tools integrate with Artifactory, currently.
 
 [[Trove]]: Baserock server appliance that supports artifact caching (using 'morph-cache-server').
 
 [1]. It probably should be specified!!!
+
+[JFrog Artifactory]: https://www.jfrog.com/artifactory/

diff --git a/caching.mdwn b/caching.mdwn
index a9583d9..fd49cff 100644
--- a/caching.mdwn
+++ b/caching.mdwn
@@ -29,6 +29,8 @@ Buildroot: no built-in support
 
 BitBake: [sstate cache](https://wiki.yoctoproject.org/wiki/Enable_sstate_cache)
 
+CMake: possible with [Artifactory.cmake](https://github.com/raumfeld/Artifactory.cmake)
+
 # Related projects
 
 ccache: this caches at the level of individual object files, not whole components. It can coexist with the caching in Baserock build tools.

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index 7cebfd7..39fa701 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -2,7 +2,7 @@ The Baserock Definitions format aims to be a universal, declarative vocabulary f
 
 I thought it'd be useful to collect existing build instructions of various forms to help us reason about this better.
 
-See also: https://en.wikipedia.org/wiki/List_of_build_automation_software
+See also: <https://en.wikipedia.org/wiki/List_of_build_automation_software>
 
 ## Feature comparison of build+integration instructions formats
 

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index f6ff56a..7cebfd7 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -2,6 +2,8 @@ The Baserock Definitions format aims to be a universal, declarative vocabulary f
 
 I thought it'd be useful to collect existing build instructions of various forms to help us reason about this better.
 
+See also: https://en.wikipedia.org/wiki/List_of_build_automation_software
+
 ## Feature comparison of build+integration instructions formats
 
 [[!table data="""Name | Syntax | Complete OS | Artifact caching | Cross compilation

diff --git a/ybd.mdwn b/ybd.mdwn
index 1bfe085..cc652e5 100644
--- a/ybd.mdwn
+++ b/ybd.mdwn
@@ -5,7 +5,7 @@ If you want to build Baserock definitions on other Linux systems or in the cloud
 
 ybd is a re-implementation of the core build and deploy functionality from morph, designed to run with minimal dependencies on other operating systems. Although it is relatively new, ybd can build and deploy most of the baserock definitions, and it is faster than morph for some use-cases.
 
-Note that first time through ybd needs to clone a lot of git repos, which can take quite a long time. And building a whole system can take a lot of time too. If you use current definitions there is an [[artifact cache | http://wiki.baserock.org/ybd/#index6h2]] which can speed up the initial build dramatically.
+Note that first time through ybd needs to clone a lot of git repos, which can take quite a long time. And building a whole system can take a lot of time too. If you use current definitions there is an [[artifact cache | ybd/#index6h2]] which can speed up the initial build dramatically.
 
 The recommended 'version' of ybd at any given time is the latest release tag at [[http://github.com/devcurmudgeon/ybd]]
 

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index 0f42b61..f6ff56a 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -1,8 +1,8 @@
-The Baserock Definitions format aims to be a universal, declarative vocabulary for software build instructions.
+The Baserock Definitions format aims to be a universal, declarative vocabulary for software build and integration instructions.
 
 I thought it'd be useful to collect existing build instructions of various forms to help us reason about this better.
 
-## Feature comparison
+## Feature comparison of build+integration instructions formats
 
 [[!table data="""Name | Syntax | Complete OS | Artifact caching | Cross compilation
 [Apache Ant](https://ant.apache.org/) + [Apache Ivy](https://ant.apache.org/ivy/) | XML | ✘ | [Maven repo](https://maven.apache.org/guides/introduction/introduction-to-repositories.html) | ✘

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index 3fcc39c..0f42b61 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -2,6 +2,30 @@ The Baserock Definitions format aims to be a universal, declarative vocabulary f
 
 I thought it'd be useful to collect existing build instructions of various forms to help us reason about this better.
 
+## Feature comparison
+
+[[!table data="""Name | Syntax | Complete OS | Artifact caching | Cross compilation
+[Apache Ant](https://ant.apache.org/) + [Apache Ivy](https://ant.apache.org/ivy/) | XML | ✘ | [Maven repo](https://maven.apache.org/guides/introduction/introduction-to-repositories.html) | ✘
+[Baserock definitions](http://wiki.baserock.org/definitions/current/) | YAML | ✔ | [Baserock artifact cache](http://wiki.baserock.org/caching/) | ✘
+[BitBake](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html) recipes | [BitBake](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-metadata) | ✔ | [Setscene](https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#setscene) | ✔
+[BOSH](https://bosh.io/) | YAML | ✘ | ? | ✘
+[Bazel](https://bosh.io/) | Bazel (Python-like) | ✘ | ? | ✘
+[Buildroot](http://buildroot.uclibc.org/) | Make | ✔ | ✔
+[CMake](http://cmake.org/) [ExternalProject](https://cmake.org/cmake/help/v3.3/module/ExternalProject.html) / [CPM](https://github.com/iauns/cpm) / [Hunter](https://github.com/ruslo/hunter) / [biicode](http://biicode.com/) | CMake | ✘ | ✔
+[Debian](http://debian.org/) | key-value (debian/control, debian/copyright, debian/changelog), Make (debian/rules) | ✔ | [deb packages](https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics) | ✔
+[GNOME Continuous](https://wiki.gnome.org/Projects/GnomeContinuous) | JSON | ✘ | [ostree](https://wiki.gnome.org/Projects/OSTree) repo | ✘
+[GNOME jhbuild](https://wiki.gnome.org/Projects/Jhbuild) | XML | ✘ | ✘
+[GNU Guix](https://www.gnu.org/software/guix) | [GUILE](https://www.gnu.org/software/guile/) (Scheme) | ✔ | [hydra](https://nixos.org/hydra/) | ✘
+[Gradle](https://www.gradle.org/) | [Gradle](https://docs.gradle.org/current/dsl/) | ✘ | [Maven repo](https://maven.apache.org/guides/introduction/introduction-to-repositories.html) | ✘
+[Maven](http://maven.apache.org/) | XML | ✘ | [Maven repo](https://maven.apache.org/guides/introduction/introduction-to-repositories.html) | ✘
+[Meson](http://maven.apache.org/) | [Meson](https://github.com/mesonbuild/meson/wiki/Syntax) | ✘ | ✘
+[Nix expressions](https://nixos.org/nix/manual/#chap-writing-nix-expressions) | [Nix Expression Language](https://nixos.org/nix/manual/#ch-expression-language) | ✔ | Nix [Binary Cache](https://nixos.org/wiki/Binary_Cache) | ✘
+[Ports-style](https://en.wikipedia.org/wiki/Ports_collection) | Shell | ✔ | ✘
+[RPM](http://rpm.org/) .spec files | [RPM spec syntax](https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-specfile-syntax.html) | ✔ | [rpm-ostree](https://github.com/projectatomic/rpm-ostree), [rpm packages](http://rpm.org/) | ✔
+[upkg](http://www.paldo.org/wiki/Development#English) | XML | ✔ | upkg packages | ✘
+[xdg-app](https://github.com/alexlarsson/xdg-app) builder | JSON | ✘ | [ostree](https://wiki.gnome.org/Projects/OSTree) repo | ✘
+[ypkg](https://github.com/solus-project/ypkg) and [eopkg](https://github.com/solus-project/package-management) | XML or YAML | ✔ | [eopkg packages](https://wiki.solus-project.com/Packaging) | ✘"""]]
+
 ## CPython (the standard interpeter for the Python language)
 
 - Arch Linux: [PKGBUILD](https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python) ([packages/extra/x86_64/python info](https://www.archlinux.org/packages/extra/x86_64/python/))

diff --git a/moving-parts.mdwn b/moving-parts.mdwn
index 863be1e..6b3ba82 100644
--- a/moving-parts.mdwn
+++ b/moving-parts.mdwn
@@ -9,7 +9,7 @@ The main parts of Baserock are:
 - [[Lorry]] - a tool for collecting upstream source, converting into Git if required
 - [[Trove]] - a Baserock appliance to host git repos collected by Lorry, and/or created by Baserock users
 - [git.baserock.org](http://git.baserock.org) - our 'master' instance of a Trove, containing all the upstreams we are integrating
-- [Definitions](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/) - a git repo defining various Baserock reference systems
+- [Reference system definitions](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/) - a git repo defining various Baserock reference systems
 - [[Trebuchet]] - a tool for updating Baserock systems, based on BTRFS snapshots
 - [[tbdiff|Trebuchet/tbdiff]] - a tool used by Trebuchet to create binary diffs between directory trees
 

diff --git a/guides/baserock-jetson.mdwn b/guides/baserock-jetson.mdwn
index e7f64a3..d02b302 100644
--- a/guides/baserock-jetson.mdwn
+++ b/guides/baserock-jetson.mdwn
@@ -51,7 +51,9 @@ If there are any errors here, it will most likely be due missing build
 dependencies for tegrarcm (e.g libusb). Once you have satisfied these you can
 run the build tools command again.
 
-Please note: The flashing script requires fdisk from util-linux, and *not* GNU fdisk. If you are using GNU fdisk (check with fdisk --version) please install util-linux (source available here <https://www.kernel.org/pub/linux/utils/util-linux/v2.27/>)
+Please note: The flashing script requires gdisk to be installed, make sure you have this installed, e.g:
+
+    sudo apt-get install gdisk
 
 You should now have a folder _out_tools in TEGRA_TOOLS_DIR that contains the
 following binaries:

diff --git a/definitions/current.mdwn b/definitions/current.mdwn
index 8cb0eaa..ab639a8 100644
--- a/definitions/current.mdwn
+++ b/definitions/current.mdwn
@@ -4,10 +4,15 @@ The Baserock definitions format
 ===============================
 
 This page describes the Baserock definitions format (morph files). It is intended to be useful as
-an *informal* specification. It is not guaranteed to be accurate or exhaustive. The source
-code of [[Morph]] and [[YBD]] might be more useful if you need a completely accurate description of how the current
-Baserock definition format is used in practice. If you are just getting started with Baserock, the
-[[quick-start]], [[devel-with]] and [[guides]] pages provide a more practical introduction.
+an *informal* specification. It is not guaranteed to be accurate or exhaustive.
+
+If you are just getting started with Baserock, the [[quick-start]], [[devel-with]] and [[guides]] pages provide a more practical introduction.
+
+The allowed YAML constructs are described in json-schema format here: <http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/schemas>.
+
+The data model is described using OWL here: <http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/schemas/baserock.owl>.
+
+The source code of [[Morph]] and [[YBD]] might be more useful if you need a completely accurate description of how the current Baserock definition format is used in practice.
 
 [[!toc startlevel=2 levels=2]]
 

diff --git a/contributing.mdwn b/contributing.mdwn
index 4e48a6b..cb66e80 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -9,7 +9,7 @@ Join the conversation
 ------------
 The baserock community members appreciate feedback, ideas, suggestion, bugs and documentation just as much as code. Please join us on `#baserock` on `irc.freenode.net` and our [development list].
 
-We maintain a [[list of ideas for things to do with Baserock|doing-stuff-with-baserock]]
+We maintain a [[list of ideas for things to do with Baserock|doing-stuff-with-baserock]].
 
 Get a Baserock OpenID
 ---------------------

diff --git a/contributing.mdwn b/contributing.mdwn
index 5e53be3..4e48a6b 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -9,6 +9,8 @@ Join the conversation
 ------------
 The baserock community members appreciate feedback, ideas, suggestion, bugs and documentation just as much as code. Please join us on `#baserock` on `irc.freenode.net` and our [development list].
 
+We maintain a [[list of ideas for things to do with Baserock|doing-stuff-with-baserock]]
+
 Get a Baserock OpenID
 ---------------------
 

diff --git a/guides/baserock-jetson.mdwn b/guides/baserock-jetson.mdwn
index 389d889..e7f64a3 100644
--- a/guides/baserock-jetson.mdwn
+++ b/guides/baserock-jetson.mdwn
@@ -80,7 +80,7 @@ when to do this during the flashing process (to do this hold down "FORCE RECOVER
 
     git clone https://gitlab.com/jamesthomas/baserock-flashing-tools.git
     cd baserock-flashing-tools/
-    curl -k -O http://download.baserock.org/baserock/baserock-current-build-system-armv7lhf-jetson.img.gz
+    curl -k -O https://download.baserock.org/baserock/baserock-current-build-system-armv7lhf-jetson.img.gz
     gunzip baserock-current-build-system-armv7lhf-jetson.img.gz
     bash baserock-flash.sh baserock-current-build-system-armv7lhf-jetson.img jetson-tk1
 

diff --git a/definitions/current.mdwn b/definitions/current.mdwn
index f5d5450..8cb0eaa 100644
--- a/definitions/current.mdwn
+++ b/definitions/current.mdwn
@@ -217,11 +217,10 @@ For strata, use the following fields:
 
 For systems, use the following fields:
 
-* `strata`: a list of names of strata to be included in the system. Unlike
-  chunks, the stratum morphs must all be in the same Git repository as the
-  system morphology. The value of the `morph` field will be taken as the
-  artifact name; if this causes ambiguity then an `alias` may be specified as
-  well. **required**
+* `strata`: a list of key/value mappings, similar to the 'chunks' field of a
+  stratum. Two fields are allowed (are both required?):
+    - `name`: name of the artifact when the stratum is build
+    - `morph`: path to a stratum .morph file relative to the top of the containing repo
 
 Example chunk (simplified commands):
 

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index 11e11f5..3fcc39c 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -14,5 +14,6 @@ I thought it'd be useful to collect existing build instructions of various forms
 - NixOS: [pkgs/development/interpreters/python/3.4/default.nix](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/interpreters/python/3.4/default.nix)
 - OpenSuSE: [python/python-base.spec](https://build.opensuse.org/package/view_file/openSUSE:Factory/python/python-base.spec?expand=1) ([openSUSE:Factory/python package info](https://build.opensuse.org/package/show/openSUSE:Factory/python))
 - Paldo: [Python.xml](http://paldo.org/paldo/unstable/specs/Python.xml)
+- SolusOS: [programming/python/python3/pspec.xml](https://github.com/solus-project/repository/blob/master/programming/python/python3/pspec.xml)
 - Ubuntu: Debian packaging is used directly. ([Ubuntu python-defaults package info](http://packages.ubuntu.com/source/wily/python-defaults))
 - Yocto: [meta/recipes-devtools/python/python3_3.4.3.bb](https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3_3.5.0.bb)

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index e4cb7fa..11e11f5 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -15,4 +15,4 @@ I thought it'd be useful to collect existing build instructions of various forms
 - OpenSuSE: [python/python-base.spec](https://build.opensuse.org/package/view_file/openSUSE:Factory/python/python-base.spec?expand=1) ([openSUSE:Factory/python package info](https://build.opensuse.org/package/show/openSUSE:Factory/python))
 - Paldo: [Python.xml](http://paldo.org/paldo/unstable/specs/Python.xml)
 - Ubuntu: Debian packaging is used directly. ([Ubuntu python-defaults package info](http://packages.ubuntu.com/source/wily/python-defaults))
-- Yocto: [meta/recipes-devtools/python/python3_3.4.3.bb](https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3_3.4.3.bb)
+- Yocto: [meta/recipes-devtools/python/python3_3.4.3.bb](https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3_3.5.0.bb)

diff --git a/ybd.mdwn b/ybd.mdwn
index 26df623..1bfe085 100644
--- a/ybd.mdwn
+++ b/ybd.mdwn
@@ -5,7 +5,7 @@ If you want to build Baserock definitions on other Linux systems or in the cloud
 
 ybd is a re-implementation of the core build and deploy functionality from morph, designed to run with minimal dependencies on other operating systems. Although it is relatively new, ybd can build and deploy most of the baserock definitions, and it is faster than morph for some use-cases.
 
-Note that first time through ybd needs to clone a lot of git repos, which can take quite a long time. And building a whole system can take a lot of time too. If you use current definitions there is an artifact cache which can speed up the initial build. See [[artifact cache | http://wiki.baserock.org/ybd/#index6h2]] at the bottom of this page.
+Note that first time through ybd needs to clone a lot of git repos, which can take quite a long time. And building a whole system can take a lot of time too. If you use current definitions there is an [[artifact cache | http://wiki.baserock.org/ybd/#index6h2]] which can speed up the initial build dramatically.
 
 The recommended 'version' of ybd at any given time is the latest release tag at [[http://github.com/devcurmudgeon/ybd]]
 
@@ -145,6 +145,9 @@ Then in the chroot you can do 'normal' ybd setup...
 Artifact cache
 ----------------
 
-There is a cache of ybd built artifacts for x86_64 and ARMv7 systems at http://artifacts1.baserock.org:8000. Downloading artifacts can be much faster than building them for some situations so if you want to use the artifact cache, do the following:
+There is a cache of ybd built artifacts for x86_64 and ARMv7 systems at http://artifacts1.baserock.org:8000/*
+
+Downloading artifacts can be much faster than building them for some situations so if you want to use the artifact cache, do the following:
+
+    echo "kbas-url: http://artifacts1.baserock.org:8000/" >> /src/ybd/ybd.conf
 
-    echo "artifact-server: http://artifacts1.baserock.org:8000" >> /src/ybd/ybd.conf

diff --git a/ybd.mdwn b/ybd.mdwn
index 1ed9312..26df623 100644
--- a/ybd.mdwn
+++ b/ybd.mdwn
@@ -5,7 +5,7 @@ If you want to build Baserock definitions on other Linux systems or in the cloud
 
 ybd is a re-implementation of the core build and deploy functionality from morph, designed to run with minimal dependencies on other operating systems. Although it is relatively new, ybd can build and deploy most of the baserock definitions, and it is faster than morph for some use-cases.
 
-Note that first time through ybd needs to clone a lot of git repos, which can take quite a long time. And building a whole system can take a lot of time too.
+Note that first time through ybd needs to clone a lot of git repos, which can take quite a long time. And building a whole system can take a lot of time too. If you use current definitions there is an artifact cache which can speed up the initial build. See [[artifact cache | http://wiki.baserock.org/ybd/#index6h2]] at the bottom of this page.
 
 The recommended 'version' of ybd at any given time is the latest release tag at [[http://github.com/devcurmudgeon/ybd]]
 
@@ -142,3 +142,9 @@ Then in the chroot you can do 'normal' ybd setup...
     /src/ybd/ybd.py systems/build-system-armv7lhf-jetson.morph
     #
 
+Artifact cache
+----------------
+
+There is a cache of ybd built artifacts for x86_64 and ARMv7 systems at http://artifacts1.baserock.org:8000. Downloading artifacts can be much faster than building them for some situations so if you want to use the artifact cache, do the following:
+
+    echo "artifact-server: http://artifacts1.baserock.org:8000" >> /src/ybd/ybd.conf

diff --git a/definitions/comparison-with-other-formats.mdwn b/definitions/comparison-with-other-formats.mdwn
index 1aad81b..e4cb7fa 100644
--- a/definitions/comparison-with-other-formats.mdwn
+++ b/definitions/comparison-with-other-formats.mdwn
@@ -5,7 +5,7 @@ I thought it'd be useful to collect existing build instructions of various forms
 ## CPython (the standard interpeter for the Python language)
 
 - Arch Linux: [PKGBUILD](https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python) ([packages/extra/x86_64/python info](https://www.archlinux.org/packages/extra/x86_64/python/))
-- Baserock reference systems: [strata/core/cpython.morph](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/core/cpython.morph)
+- Baserock reference systems: [strata/core/cpython.morph](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/core/python3.morph)
 - buildroot: [package/python3/python3.mk](http://git.buildroot.net/buildroot/tree/package/python3/python3.mk), [package/python3/Config.in](http://git.buildroot.net/buildroot/tree/package/python3/Config.in)
 - Debian: [debian/rules](https://alioth.debian.org/scm/loggerhead/pkg-python/python3-defaults-debian/view/head:/debian/rules), [debian/control](https://alioth.debian.org/scm/loggerhead/pkg-python/python3-defaults-debian/view/head:/debian/control) ([pkg-python project main page](https://alioth.debian.org/projects/pkg-python))
 - Fedora: [python.spec](http://pkgs.fedoraproject.org/cgit/python.git/tree/python.spec)

diff --git a/download.mdwn b/download.mdwn
index 4dd1d45..160d9f4 100644
--- a/download.mdwn
+++ b/download.mdwn
@@ -8,7 +8,6 @@ Build systems Images
 * x86 64-bit [raw build][build-x86-64-raw] disk image
 * x86 32-bit [raw build][build-x86-32-raw] disk image
 * ARMv7 Jetson [raw build][build-armv7lhf-jetson-raw] disk image
-* ARMv7 [rootfs][build-armv7lhf-rootfs]
 
 Instructions for installing images [are here](http://wiki.baserock.org/guides/vm-setup/).
 
@@ -19,6 +18,10 @@ Build system chroots
 
 Instructions on setting up a chroot [can be found here](http://wiki.baserock.org/guides/chroot).
 
+Rootfs tarballs
+---------------
+* ARMv7 [rootfs][build-armv7lhf-rootfs]
+
 [GENIVI](https://en.wikipedia.org/wiki/GENIVI_Alliance) base images
 ------------------
 * x86 64-bit [raw][genivi-base-x86-64-raw] disk image