This patch fixes a bug in the lorry-controller, causing it fail to
read the configuration.
Pedro Alvarez (1):
Fix over-indentation in readconf.py
lorrycontroller/readconf.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Landing in: master
Minions need some configuration to work. This patch is to add the
configuration needed in trove.configure
Pedro Alvarez (1):
Create the minion configuration in trove.configure
trove.configure | 11 +++++++++++
1 file changed, 11 insertions(+)
It's been pointed out that the address for the baserock-dev(a)baserock.org
mailing list is hard to find on the website.
This patch series tries to consolidate the various ways of getting in
touch into the 'mailinglist' page, because baserock-dev(a)baserock.org is
the primary place that we want people to join in with, right now.
Sam Thursfield (5):
Make mailing list addresses more prominent and easier to find.
Add mailing list link to sidebar
Encourage participation on list and make clear that it is public
Make mailinglist page into a generic 'contact' page
Make it clear bug reports should go to mailing list
bug-reporting.mdwn | 19 +++++++------------
bugs.mdwn | 22 +---------------------
index.mdwn | 8 +++++---
mailinglist.mdwn | 26 +++++++++++++++++---------
sidebar.mdwn | 3 ++-
5 files changed, 32 insertions(+), 46 deletions(-)
mode change 100644 => 120000 bugs.mdwn
This adds a systemd timer unit to run the necessary commands to get
GitLab to dump its state (database, git repos) into a tar archive,
which gets put into /home/git/gitlab-backup.tar for retrieval by an
external agent later on.
I've built, deployed, and tested a gitlab-system with these changes,
manually created some changes in the database, waited for the backup
to happen, then restored the backup in another instance, and the
resulting system worked, and had the changes made in gitlab in the
Lars Wirzenius (1):
Add GitLab backup automation
gitlab-server/manifest | 3 +++
.../usr/share/gitlab-install/backup-gitlab | 22 ++++++++++++++++++++++
.../systemd-units/gitlab-backup.service | 11 +++++++++++
.../systemd-units/gitlab-backup.timer | 8 ++++++++
gitlab-server/usr/share/gitlab-setup | 2 +-
5 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 gitlab-server/usr/share/gitlab-install/backup-gitlab
create mode 100644 gitlab-server/usr/share/gitlab-install/systemd-units/gitlab-backup.service
create mode 100644 gitlab-server/usr/share/gitlab-install/systemd-units/gitlab-backup.timer
Today I made a change in my definitions repo that I thought I'd share with
others. Unfortunately, the current patch submission process  entirely
fails to work for me. In this case, it fails because of a national agreement
between local ISPs , but I frequently find myself in environments with
similar classes of restriction (although often locally implemented, rather
than enforced over a large geographic area). Further, there are lots of
folk who don't happen to have access to a mailserver that can accept mail
(even with TLS) on port 25 (or even 587) for various reasons (a common one
might be writing patches at work and having work email only use Exchange,
Notes, Groupwise, etc.). Much thanks to Richard Ipsum for standing in as
a proxy-server to enable me to share the patches.
As a result of this experience, I'd like to propose using something else
for code review. From my researches on the tools available, it seems like a
sensible common set of requirements includes:
1) Use of comfortable tools (git client of choice, editor of choice, etc.).
2) Support for offline reviews (connectivity may be required to post results).
3) Support for a pre-commit workflow.
4) Integration with CI, providing robotic reviews.
5) Robust ACL support (to allow review of embargoed patch series).
6) Support for automated fast-forward on approve (no useless "merge" commits).
7) Sensible API, with available command-line tools for remote use.
8) Open Source, so the ugly bits can be fixed.
9) Allow self-serve account creation and credentials negotiation.
10) Maintain integrity of repository (what is pushed == what is pulled).
11) Allow submission of code on ports 22, 443, or 9418.
12) Doesn't force use of a large set of associated tools.
Looking about, it seems that there are four extant solutions to this
class of problem: Barkeep, Gerrit, GitLab, and Phabricator. From a quick
review of each, I've developed the following opinions:
Barkeep is focused on a post-commit workflow: while there is limited support
for pre-commit, there do not appear to be sensible hooks for CI gating or
Gerrit supports automated merge of patchsets, but doesn't appear to support
automated fast-forward. Gerrit also mangles submitted commits, so that the
hashes merged never match the local hashes (although content may).
Phabricator has weak ACLs, integration of a bug tracker (Maniphest isn't
the best issue tracker, in my opinion), and a wiki (having git-coordinated wiki
is nicer than fussing with Phriction).
Gitlab encourages a pull/merge workflow (rather than rebasing reviewed series),
cluttering project history, includes an issue tracker (with many issues), and
a non-git managed wiki.
Of these, Gerrit and GitLab seem least annoying. I'm personally not a
fan of the pull request/merge workflow, as I don't believe that discussion
of how a change came to be is useful for later users of git-annotate or
similar tools, and disapprove of folk rebasing publically-accessibe git
repos (which the pull requests reference), causing me to lean towards
Gerrit (which encourages rebase, but grants different URLs for different
revisions of a patch series). That said, of the requirements above, number
11 is really the most important for me: blocking of port 25 is *very* common,
587 not uncommon, 9418 merely frequent, 22 unusual, and 443 rare.
If anyone has used any other tools that better match the requirements
above, I'd be pleased to hear about it. Similarly, if anyone has a strong
preference for one of the ones I've listed other than Gerrit, I'd be
interested in discussion. In the absence of discussion, I'd like to
encourage the infrastructure team to set up a Gerrit instance to manage
commits to relevant project repositories (definitions, morph, etc.).
I came across the Semantic Versioning website  today and wondered if
some of the ideas are relevant to us. TBH I wish I'd known about it
before getting involved in the numbering discussion for baserock
releases in the last couple of weeks.
Anyway, even if not useful for Baserock itself, I hope this may be of
interest to others here
With the help form this mail list, I followed the link
successfully run the arm image (genivi-h0.1r2-genivi-baseline-system-armv7-versatile.img.gz, genivi-h0.1r2-genivi-baseline-system-armv7-versatile.zImage) using VMPlayer and Virtual Box on top of a Win7 machine (Dell VOSTRO 3360, i7 with 8GB memory)
However, the performance is hardly comparable with the one shown in
For example, for
"weston-simple-shm-ivi &" give me 5 fps while the video above show 80 fps.
Does the video above is running x86 emulation? How can I improve the performance?
Desay SV Automotive Singapore Pte. Ltd.
Tel : +65-63021744
Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you are not the intended recipient, please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person, delete this e-mail and any attachment from your system immediately. Thank you!
This is the first Baserock release since January 2014.
Major changes since Baserock 13:
* New version numbering system and release policy.
* The format of Baserock system definitions has changed significantly.
* Compliance as a GENIVI Horizon H-1.0 baseline (includes Wayland and
* Artifact splitting has been implemented.
* GNU Compiler Collection version 4.7.
* Lorry Controller (Trove's repo mirroring daemon) has been rewritten.
* Example Node.js stratum and system added.
* OpenStack novaclient added.
* Support for nested deployment.
* system-integration-commands field added to chunk morphologies, which
allows running commands while constructing the final rootfs.
* Various bug fixes and component updates.
* ARMv7 hard float support.
* Distributed building support has been integrated into Morph.
* Documentation in Morph for some deployment extensions.
* Large binary files can be added to chunk repos.
* Support for building cross-compilation SDKs for targetting systems
built with Baserock.
* Support for running Baserock in a chroot.
* Upgrade support added to `morph deploy` (using Btrfs as a root
* Virtualisation stratum.
We do not recommend building Baserock 14.20 with Baserock 13. While not
impossible, we advise all users of Baserock 13 to upgrade by redeploying
their systems from the provided images. Users who have forked the
baserock:baserock/morphs.git repository should transfer their changes to
Please get in touch if you have any issues! See below for contact
# New release policy
Beginning with Baserock 14.20, we have changed to date-based version
numbers. The format is YY.WW, that is, the last two digits of the year
followed by week number. So for example if we make a Baserock release on
January 1st, 2015, that will be Baserock 15.01.
We intend to aim for weekly releases of Baserock eventually.
# Changes to system definitions
System and stratum morphologies are now stored in
All stratum morphologies are in the definitions.git repo. The 'repo' and
'ref' fields are gone from system morphologies. All chunks are
referenced by their commit SHA1, where previously Baserock often used
named refs. These changes make definitions.git the sole master
repository of all systems built from it: the output of building a given
commit of definitions.git will always be the same (modulo certain
timestamps and metadata files).
Previous releases were from [baserock:baserock/morphs]. This repository
is deprecated and may be removed or archived in the future.
Baserock-based projects are recommended to maintain forks of
definitions.git, merging in changes from upstream Baserock as they wish.
# Changes to system branch workspaces
The `morph checkout` and `morph branch` commands now convert ':' to '/'
when creating directories. We found that ':' in path names can trigger
bugs in some build systems.
The following command:
$ morph checkout baserock:baserock/definitions master
Checks out the definitions repo into the following directory:
In Baserock 13 that would have been:
This means that system branch workspaces that were created with old
versions of Morph will need to be pushed, and then checked out again
into a fresh workspace so that you can work on them with Morph from
# New features in detail
## ARMv7 hard float
The ARM GENIVI baseline image is now built with hardware floating point
enabled (`armv7lhf` architecture). Soft float systems can still be built
(`armv7l` and `armv7b` architectures).
## Distributed building
Distbuild is a distributed build system that can be used to build a
number of systems in parallel using a set of workers. Chunks in a system
may also be built in parallel, reducing the build time for a single
system. Distbuild can be used to avoid unnecessary rebuilds, this is
achieved firstly through a shared cache, and secondly through the
distbuild controller's build scheduler. A distbuild uses a Trove
instance on the local network to hold source code and built artifacts.
See the example deployment morphology [example-distbuild-cluster.morph]
if you want to set up a distbuild network.
## Documentation for deployment extensions
In order to make usage of Morph's extensible `morph deploy` command more
easy, you Morph can now list the available deployment extensions with
`morph help-extensions`, and read the documentation for a given
extension with, for example, `morph help tar.write`.
Not all extensions have documentation yet. The Baserock project welcomes
new participants, and this would be a great starting point for getting
## Large binary files
Morph and Trove together wrap the tool [git-fat] with two new commands:
`morph add-binary` and `morph push`.
## SDK generation
See the [sdk-example-cluster.morph] in definitions.git. This produces a
cross-compiler which runs on x86_32 and targets armv7lhf. It can be
adapted to other platforms.
## Baserock in a chroot
This can be used with the Baserock chroot management tools, which wrap
`schroot` and provide helpful tools for working with Baserock chroots.
See the [baserock-chroot README].
## Upgrade support
Baserock's Trove system is now upgradable in-place. Upgrades can be
deployed with `morph deploy --upgrade`. Baserock devel systems can also
be upgraded in place, see `upgrade-devel.morph` in definitions.git.
Btrfs subvolumes are used to share content between the various system
versions. In Baserock 14.20 the following subvolumes are shared: /home,
/opt, /root, /srv and /var. Changes to /etc are also propagated between
versions by doing a 3-way merge.
There are two new tools introduced as part of this functionality:
`system-version-manager`, which allows you to manage the available
system versions, and `baserock-system-config-sync` which is used by
`system-version-manager deploy` to transfer changes between different
There is a new 'virtualisation' stratum in the x86_64 devel system,
which includes libvirt, virt-manager and QEMU. You can now run Baserock
# How do I get started?
Start with the following page: <http://wiki.baserock.org/quick-start/>
# How do I get in contact?
- IRC: freenode #baserock
- Public mailing list: baserock-dev(a)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 our work.