[PATCH 0/5] Add weston system containing latest stock weston
by Javier Jardón
REPO: ssh://git@git.baserock.org/baserock/baserock/definitions.git
BRANCH: baserock/jjardon/weston
COMMIT: c463195c365a8255c7818b877e968e861c978a8a
Javier Jardón (5):
strata/wayland-generic: Update to latest xkbcommon (0.5.0)
strata/input-common: Update to latest libinput (0.6.0)
Add weston-common stratum
Add a generic weston system
Add deploy for weston-system-x86_64-generic
clusters/weston-system-x86_64-generic-deploy.morph | 12 ++++++
strata/input-common.morph | 4 +-
strata/wayland-generic.morph | 5 ++-
strata/wayland-generic/libxkbcommon.morph | 5 +++
strata/weston-common.morph | 21 +++++++++++
strata/weston-common/weston.morph | 9 +++++
systems/weston-system-x86_64-generic.morph | 43 ++++++++++++++++++++++
7 files changed, 95 insertions(+), 4 deletions(-)
create mode 100644 clusters/weston-system-x86_64-generic-deploy.morph
create mode 100644 strata/wayland-generic/libxkbcommon.morph
create mode 100644 strata/weston-common.morph
create mode 100644 strata/weston-common/weston.morph
create mode 100644 systems/weston-system-x86_64-generic.morph
--
2.1.2
8 years, 10 months
Public facing Mason instance.
by Pedro Alvarez
Hello all!
As you probably know, we have been thinking about Continuous Delivery and
Continuous Integration. As a result we have started the implemented of Mason.
Today we have deployed a public facing Mason instance so everyone can see it.
What Mason does is:
- Check that the current definition of a devel system (x86_64) can be built.
- Populate an artifact cache server with the artifacts of the previous build.
We are currently working on it, and it will have more improvements soon.
The current IP for Mason is: http://85.199.252.95/
If you want to use the artifacts you only have to add this line to your
morph.conf file:
artifact-cache-server = http://85.199.252.93:8080/
--
Pedro
8 years, 10 months
[PATCH] Add go, docker
by Paul Sherwood
repo: git://git.baserock.org/baserock/baserock/definitions.git
branch: baserock/ps/docker
Now that build-systems exist, and have added ruby and node to
devel-system, I'm proposing we go the whole nine yards of trendiness and
add docker :)
If this is approved I'll work on the equivalent patch for jetson
---
.../bsp-x86_64-generic/linux-x86-64-generic.morph | 11 +++++++++++
strata/go-docker.morph | 23
++++++++++++++++++++++
strata/go-docker/docker.morph | 10 ++++++++++
strata/go-docker/go.morph | 13 ++++++++++++
systems/devel-system-x86_64-generic.morph | 2 ++
5 files changed, 59 insertions(+)
create mode 100644 strata/go-docker.morph
create mode 100644 strata/go-docker/docker.morph
create mode 100644 strata/go-docker/go.morph
diff --git a/strata/bsp-x86_64-generic/linux-x86-64-generic.morph
b/strata/bsp-x86_64-generic/linux-x86-64-generic.morph
index 4b18b53..923727c 100644
--- a/strata/bsp-x86_64-generic/linux-x86-64-generic.morph
+++ b/strata/bsp-x86_64-generic/linux-x86-64-generic.morph
@@ -78,6 +78,17 @@ configure-commands:
- scripts/config -e FB_VESA
- scripts/config -e HOTPLUG_PCI
- scripts/config -e HOTPLUG_PCI_ACPI
+- scripts/config -e DEVPTS_MULTIPLE_INSTANCES
+- scripts/config -e VETH
+- scripts/config -e CGROUP_DEVICE
+- scripts/config -e MACVLAN
+- scripts/config -e NF_NAT_NEEDED
+- scripts/config -e NETFILTER_ADVANCED
+- scripts/config -e NETFILTER_XT_MATCH_ADDRTYPE
+- scripts/config -e NETFILTER_XT_MATCH_CONNTRACK
+- scripts/config -e MEMCG_SWAP
+- scripts/config -e AUFS_FS
+- scripts/config -e DM_THIN_PROVISIONING
- yes '' | make oldconfig
build-commands:
- make $MAKEFLAGS
diff --git a/strata/go-docker.morph b/strata/go-docker.morph
new file mode 100644
index 0000000..1beddab
--- /dev/null
+++ b/strata/go-docker.morph
@@ -0,0 +1,23 @@
+name: go-docker
+kind: stratum
+build-depends:
+- morph: strata/tools.morph
+chunks:
+- name: go
+ repo: upstream:go
+ morph: strata/go-docker/go.morph
+ ref: 536a6e6905993f1270f7a8b742352ce832cbf144
+ unpetrify-ref: go1.3.3
+ build-depends: []
+- name: docker
+ repo: upstream:docker
+ morph: strata/go-docker/docker.morph
+ ref: c78088fe3d1b90640c637d8c3457de3caa0c7a24
+ unpetrify-ref: v1.3.0
+ build-depends:
+ - go
+- name: iptables
+ repo: upstream:iptables
+ ref: 3e6fa55d5e28c93f417afeae7a7d4f349ddffcf4
+ unpetrify-ref: baserock/morph
+ build-depends: []
diff --git a/strata/go-docker/docker.morph
b/strata/go-docker/docker.morph
new file mode 100644
index 0000000..0247e19
--- /dev/null
+++ b/strata/go-docker/docker.morph
@@ -0,0 +1,10 @@
+name: docker
+kind: chunk
+build-commands:
+- export AUTO_GOPATH=1 && export
DOCKER_BUILDTAGS='exclude_graphdriver_devicemapper' && export
TMPDIR=/tmp && ./hack/make.sh binary
+#- export DOCKER_CLIENTONLY=1
+#- ./hack/make.sh dynbinary
+install-commands:
+- mkdir -p "$DESTDIR$PREFIX/bin"
+- cp ./bundles/*/binary/docker "$DESTDIR$PREFIX/bin/docker"
+- cp ./contrib/check-config.sh "$DESTDIR$PREFIX/bin"
diff --git a/strata/go-docker/go.morph b/strata/go-docker/go.morph
new file mode 100644
index 0000000..1c8a979
--- /dev/null
+++ b/strata/go-docker/go.morph
@@ -0,0 +1,13 @@
+name: go
+kind: chunk
+build-commands:
+- export GOROOT_FINAL="$PREFIX/lib/go" && export TMPDIR=/tmp && cd src
&& bash ./make.bash
+install-commands:
+- mkdir -p "$DESTDIR$PREFIX/lib/go"
+- cp -r bin "$DESTDIR$PREFIX/lib/go"
+- cp -r lib "$DESTDIR$PREFIX/lib/go"
+- cp -r src "$DESTDIR$PREFIX/lib/go"
+- cp -r pkg "$DESTDIR$PREFIX/lib/go"
+- mkdir -p "$DESTDIR$PREFIX/bin"
+- ln -s "$PREFIX/lib/go/bin/go" "$DESTDIR$PREFIX/bin/go"
+
diff --git a/systems/devel-system-x86_64-generic.morph
b/systems/devel-system-x86_64-generic.morph
index dcc39ef..eeb826d 100644
--- a/systems/devel-system-x86_64-generic.morph
+++ b/systems/devel-system-x86_64-generic.morph
@@ -26,6 +26,8 @@ strata:
morph: strata/nodejs.morph
- name: ruby
morph: strata/ruby.morph
+- name: go-docker
+ morph: strata/go-docker.morph
configuration-extensions:
- set-hostname
- add-config-files
--
1.8.4
8 years, 10 months
[PATCH 0/2] Lorry Controller: Add lists of all, failed jobs
by Lars Wirzenius
repo: git://git.baserock.org/baserock/baserock/lorry-controller
branch: baserock/liw/lc-list-failed-jobs
commit: c491acc03665213e01e40fc9ef81f5e326cf9ff9
land: master
card: S11751
This adds a list of failed jobs, and another list of all jobs, to the
status page for each lorry specification that Lorry Controller knows
about. This will make it a bit easier to debug lorrying problems on a
Trove.
Lars Wirzenius (2):
Add tests for jobs, failed_jobs attributes in lorry specs
Add lists of failed, all jobs to lorry spec info
lorrycontroller/showlorry.py | 35 +++++++++++++++--------
lorrycontroller/statedb.py | 13 +++++++++
templates/lorry.tpl | 25 +++++++++++++++++
yarns.webapp/040-running-jobs.yarn | 57 ++++++++++++++++++++++++++++++++++++--
4 files changed, 115 insertions(+), 15 deletions(-)
--
1.8.4
8 years, 10 months
[PATCH 0/6] [V2] Move coreutils to its own stratum
by Javier Jardón
REPO: ssh://git@git.baserock.org/baserock/baserock/definitions.git
BRANCH: baserock/jjardon/coreutils
COMMIT: 0cf1dc4a9d4ee0978049dfed4f1a7c525ea2a44b
In this second series Ive moved "patch" to core so we do not have to modify
every single system to not break the upgrade mechanism (ssh-rsync extension)
Javier Jardón (6):
Move coreutils to its own stratum
strata/coreiutils-common.morph: Update to latest patch version (2.7.1)
coreutils.morph: Do not disable coreutils binaries
patch.morph: Install binaries in default location
strata/foundation: Make it depend on coreutils-common
Move "patch" to strata/core from strata/coreutils-common
strata/core.morph | 8 ++++++++
strata/core/patch.morph | 9 +++++++++
strata/coreutils-common.morph | 15 +++++++++++++++
strata/coreutils-common/coreutils.morph | 9 +++++++++
strata/foundation.morph | 8 +-------
strata/foundation/patch.morph | 9 ---------
strata/tools.morph | 6 ------
strata/tools/coreutils.morph | 9 ---------
8 files changed, 42 insertions(+), 31 deletions(-)
create mode 100644 strata/core/patch.morph
create mode 100644 strata/coreutils-common.morph
create mode 100644 strata/coreutils-common/coreutils.morph
delete mode 100644 strata/foundation/patch.morph
delete mode 100644 strata/tools/coreutils.morph
--
2.1.2
8 years, 10 months
[PATCH 0/6] Finish isolating commands
by Richard Maw
This removes the final mount that was causing issues, reworking the
logic to share more code.
Repo: git://git.baserock.org/baserock/baserock/morph.git
Ref: baserock/richardmaw-os/unify-namespace-logic
Sha1: 592d57835516ffb3701266fedaddd38747fc05fc
land: master
Richard Maw (6):
Allow invert_paths to skip the top level directory
Move unsharing and containerising logic to util
Make system-integration commands use containerised_cmdline
Make deployment extensions use unshared_cmdline
Make build commands use containerised_cmdline
stagingarea: Remove vestigial pre-command mounting logic
morphlib/builder2.py | 60 +++--------------------------------
morphlib/extensions.py | 5 +--
morphlib/fsutils.py | 5 +++
morphlib/stagingarea.py | 69 ++++++++++------------------------------
morphlib/util.py | 84 +++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 111 insertions(+), 112 deletions(-)
--
1.9.1
8 years, 10 months
Conditionals and branching in definitions
by Emmet Hikory
In IRC this weekend there were a few discussions about how to
represent a couple complicated constructions in defintions. There
were a number of examples given, but I believe they can be summarised
as follows:
A) Component X can be built two ways, depending on the presence or
absence of Component Y. The upstream build system isn't smart enough
to do this automatically, so we need to hardcode things in definitions,
so that for system P, we X+Y and for system Q, we get X-Y.
B) Component X can be built to use either Component Y or Component Z,
but not both. We want to define a cluster that includes two otherwise
identical systems, one of which is X+Y and the other of which is X+Z,
for synchronised deployment as part of commit test infrastructure.
For case A, I think the right answer is probably to go fix the
upstream build system to behave correctly. That failing, I think
we should focus on having multiple branches of definitions, one for
a class of systems that includes system P, and the other that includes
system Q. Another alternative, known working in jhbuild, is to support
a declarative conditional syntax allowing one to specify differing
conditions to be applied at build time, depending on the initial conditions
supplied.
While I agree entirely this works, I think we should be branching
for two reasons, these being:
1) The first thing we tell users to do when they want to play with baserock
is to branch from master (or otherwise generate a commit containing
variance from the git.baserock.org master branch, even if we sometimes
hide the commit). Therefore if the project itself is not experiencing
working with maintaining multiple branches, none of the user experience
problems immediately presented to all users will be seen by developers.
2) The introduction of any logic or any possibility for different build-time
paths thorugh the system definitions graph requires users to think about
what might be included in a system they build, rather than having it be
explicit in the definitions, without requiring processing by the reader.
This first step is a large one, and once made, it becomes hard to determine
at what point to stop allowing logic (if not stopped, we end up with a
fully turing-complete build system, as most others have already become).
Note that adoption of a branching model quite possibly requires some
thinking about tooling. For distributed coordination of a large number
of changesets, and exchanging changesets between repositories, we already
have a fairly good tool, this being git, but I do not belive we have
much experience using git in the context of applying changes to several
definitions branches as a matter of course, nor do most of us have much
experiencing working simultaneously on multiple branches: if nothing else,
it would behoove us to document the best practices in this area, and ensure
we present this to our users. For that matter, even if we don't decide to
branch definitions ourselves, we should probably do this to reduce the
incentives for users to ignore changes made in upstream definitions until
it is too painful to migrate.
Unfortunately, this stance is hard to keep when considering case B,
as the primary class of users for case B wqould be groups maintaining one
or more sources, and needing to validate changes in their sources against
a wide class of targets. Regardless of the level of tooling we can provide,
this becomes an expensive operation if a separate branch of definitions is
required for each target, not only in terms of maintainance, but more
critically, in terms of deployment, significantly reducing the potential
value of Baserock as the starting point of a comprehensive validation
suite. One can achieve a single cluster definition by having several
different directories containing nearly identical definitions, but in this
case, none of the git tools will help significantly to ensure they are
all aligned (which is a greater hinderance when expected to be operated
primarily by automation, rather than by humans).
For this use, logic in definitions is very attractive, especially if
we can determine a small restrictive set of logic that can be used, and
ensure that we only have declarations of logic, so that we are evaluating
a declarative notation, rather than interpreting a programmatic notation.
My background in computer science is weak enough that I'm not confident of
precisely where to draw a safe line to ensure that definitions remains
trivially decideable, and hope others with stronger knowledge in this
area can contribute sane proposals for the minimal logic set that allows
us to support case B, or suggestions on a way to sanely maintain the
definitions for such a validation cluster in the absence of logic.
--
Emmet HIKORY
8 years, 10 months
[PATCH 0/2] lorry: Obey changes to URL in spec
by Lars Wirzenius
Lorry is given a "spec" (the .lorry file) that tells it what to mirror
or convert. The spec includes a URL specifying the location of the
upstream repository. For some version control systems, this remote
location is stored in the local copy of the cloned repository, and
future version control operations will use that location, unless told
otherwise. Lorry was not always telling otherwise. This meant that
Subversion and Mercurial conversions would stick to the original URL
in the spec file, even if the spec file was changed later.
These patches fix that.
Lars Wirzenius (2):
Make Subversion lorrying obey URL changes
Make hg pulls use URL from spec, not default
lorry | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--
1.9.1
8 years, 11 months
[PATCH 0/3] morph: Improve user experience on slow network connections (slightly)
by Sam Thursfield
Repository: git://git.baserock.org/baserock/baserock/morph
Ref: sam/transfer-status
Sha1: 426526c692fecd520b1946f362e148d043c61441
Mostly, this branch adds a way to see the progress of slow network
operations (pass --verbose to use it). Lack of progress info causes a
lot of pain for users, who experience Morph hanging for hours with no
output as it performs a slow network operation.
Sam Thursfield (3):
Don't say 'Updating git repository xxx' unless we actually are
Remove workaround for an old version of Git
Echo stderr of subcommands that do network IO when --verbose is used
morphlib/cachedrepo.py | 9 +++------
morphlib/git.py | 11 +++++++++++
morphlib/localrepocache.py | 29 +++++++++++++++++++++++------
morphlib/localrepocache_tests.py | 11 ++++++++---
4 files changed, 45 insertions(+), 15 deletions(-)
--
1.9.3
8 years, 11 months
[PATCH] Do not build with tcp-wrappers support
by Javier Jardón
REPO: ssh://git@git.baserock.org/baserock/baserock/definitions.git
BRANCH: baserock/jjardon/tcpwarppers
COMMIT: 6749144f0fed5ce1218151ea4cedde70a85f9f38
Javier Jardón (1):
strata/nfs: Do not build rpcbin and nfs-utils with tcp-wrappers
support
strata/nfs.morph | 8 --------
strata/nfs/nfs-utils.morph | 2 +-
strata/nfs/rpcbind.morph | 2 +-
3 files changed, 2 insertions(+), 10 deletions(-)
--
2.1.2
8 years, 11 months
