[PATCH] Make the morphologies of Mesa generic.
by Pedro Alvarez
Repo: upstream:mesa
Branch: baserock/genivi/morph-generic
Sha1: d880498b44107e847a5da94b37a61b60fb0db446
With this change, the mesa chunk morphology will be generic for
armv7 and x86. As a consecuence can drop one of the following strata
morphologies:
- wayland-armv7-versatile.morph
- wayland-x86_64-versatile.morph
Pedro Alvarez (1):
Make the morphologies genieric.
mesa-wayland.morph | 2 +-
mesa-x.morph | 2 +-
morph-arch-config | 10 ++++++++++
3 files changed, 12 insertions(+), 2 deletions(-)
create mode 100644 morph-arch-config
--
1.7.10.4
8 years, 11 months
WIP Gitlab on baserock...
by Paul Sherwood
Hi folks,
I've been experimenting with getting Gitlab[0] onto a Baserock system.
The community edition is fully open source, and has lots of interesting
capabilities which might be of interest such as issue tracking, wiki etc.
There are some install instructions for installing the community edition
on Linux [1], which I've been tweaking as a work-in-progress to get
Gitlab onto my proto-web baserock system [2]
This is a Work In Progress - the install process is still rather
labour-intensive and could do with scripting, but I've managed to get to
a system where the upstream Gitlab check script thinks everything is up
and running :-)
Currently I'm stuck on getting nginx and unicorn to actually allow me to
log in, and I've not yet understood how to get services to start at
boot-time in baserock.
I've put my notes on the steps I'm following in a gist on github [3],
along with various .service files which may or may not work.
I probably won't get a chance to do anything more on this for a while -
but I can answer questions if anyone else starts down this path.
br
Paul
[0] https://www.gitlab.com/gitlab-ce/
[1]
https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md
[2]
http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.gi...
[3] https://gist.github.com/devcurmudgeon/d4875e31c608d6d0e302
--
Paul Sherwood Codethink Ltd.
Tel: +44 788 798 4900 302 Ducie House, Ducie Street,
http://www.codethink.co.uk/ Manchester, M1 2JW, United Kingdom.
Codethink provides advanced software design, development, integration &
test services: from embedded systems to high performance apps to cloud.
9 years
eglibc ref in definitions.git master
by Sam Thursfield
Hi all!
I just gave a couple of hours training on how to merge in upstream
changes to a fork of baserock:baserock/definitions.git. In the process
we noticed something weird that was merged in the past month:
- name: eglibc
repo: upstream:eglibc2
ref: e57ce33023d37183847a0c2f692645887691576a
unpetrify-ref: baserock/2.15-build-essential
Branch baserock/2.15-build-essential doesn't contain commit
e57ce33023d37183847a0c2f692645887691576a: see [1], the top commit is
43ee5d250ad47d2bee8ec17954efb7f22d2b804c. That commit exists in branch
baserock/richardmaw/S10442/cross-toolchain-V2, though [2]. I guess
that's not intentional and whoever merged that system branch didn't
merge the system-branch ref to a stable branch in the eglibc2 repo.
We shouldn't be pointing at personal branches in definitions, I think. I
imagine this was a mistake. Should I fix this, by merging the personal
branch to 'baserock/2.15-build-essential.git' in the eglibc.git repo and
updating 'unpetrify-ref' in definitions.git?
It was rather time-consuming to investigate what had happened (there are
several possible reasons for having an out of date branch locally), and
we don't have any tooling to assist when merging system-branches so this
will no doubt happen again.
It would also be very useful to have a `morph diff` command for
evaluating merges in definitions.git. The manual approach depends on the
nominally optional 'unpetrify-ref' field, and on copying a lot of SHA1s
to and from the clipboard to paste into 'git diff' commandlines. It
doesn't encourage users to spend the time to stay up to date with our
changes in baserock:baserock/definitions.git.
Sam
1.
http://git.baserock.org/cgi-bin/cgit.cgi/delta/eglibc2.git/commit/?h=base...
2.
http://git.baserock.org/cgi-bin/cgit.cgi/delta/eglibc2.git/log/?h=baseroc...
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
9 years, 1 month
New lorry controller
by Sam Thursfield
Hi!
As a demo of how to do update & rollback on a Trove, we updated our
Trove to the latest 'master', which includes the new Lorry Controller.
The upgrade went well but the new Lorry Controller status page seems to
contain a bunch of links which 404. I assume this is something broken,
but didn't have time to investigate (it's an unreleased version so this
isn't a big issue). We rolled back to the previous Trove deployment that
is known-good. However, we did not see the old Lorry Controller status
page. It turned out that the crontab entry for running lorry-controller
was not present in the old system version any more. Was it removed as
part of the upgrade somehow? crontab is in /var, which is shared between
all system versions, so if it was that would explain why the rollback
didn't work.
Basically I'm reporting two bugs in this mail:
- links on new lorry-controller page do not work
- rollback to old lorry-controller doesn't work
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
9 years, 1 month
gawk and Busybox awk
by Sam Thursfield
hi
I noticed this morning that we have two chunks that include /usr/bin/awk
: busybox and gawk. (Actually we have four: stage2-busybox and
stage2-gawk also include it, but are overwritten by the others).
Something changed over the last month such that a build that previously
used gawk now uses Busybox awk, and fails as a result. The commit that I
think could have caused this is:
http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.gi...
("Merge remote-tracking branch
'remotes/origin/baserock/richardmaw/S10786-finer-splitting-v2'"). There
were no changes to busybox or gawk.
Looking back at when this change was originally done:
http://vlists.pepperfish.net/pipermail/baserock-dev-baserock.org/2013-Jul...
It seems the 'strip-gplv3.configure' extension was responsible for
changing /usr/bin/awk to point at busybox awk:
http://vlists.pepperfish.net/pipermail/baserock-dev-baserock.org/2013-Jul...
Am I correct in thinking that the original patch should have removed the
'/usr/bin/awk' symlink created by Busybox as part of the Busybox-install
commands? That way we'd not have the overlap. Or is there a better way
to fix this now involving chunk splitting Busybox awk into a
busybox-nogplv3 artifact or some such?
Thanks
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
9 years, 1 month
distbuild: Include .build-log when copying chunk artifacts to the Trove
by Sam Thursfield
Repository: git://git.baserock.org/baserock/baserock/morph
Ref: baserock/sam/distbuild-logs
Sha1: f604c06d8b5a12ba347e41d59e12bed0558d715b
This still requires the user to have root access on Trove to see the logs,
but they do not have to log into the actual distbuild node now, at least.
In future we can add a morph show-build-log command, but that is not trivial
as it must navigate the temporary build ref correctly.
We should add build logs for systems, too, since they now can run
integration-commands which may fail or produce useful output.
Sam Thursfield (1):
distbuild: Include .build-log when copying chunk artifacts to the
Trove
distbuild/worker_build_scheduler.py | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--
1.8.5.3
9 years, 1 month
'foo-bar' and 'bar-bar' tags in definitions.git
by Sam Thursfield
Are these required for anything or can they be deleted? It's messy
having these appear in every repository that has
baserock:baserock/definitions as a remote.
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
9 years, 1 month
morph bugs: checkout master, then morph edit anything that has an upstream 'master' branch
by Paul Sherwood
hi folks
i've not used morph checkout very much, since morph branch is my normal
use-case.
but in a workspace...
morph checkout baserock:baserock/definitions master
cd master/baserock/baserock/definitions
morph edit <system> <stratum> <chunk>
afaict the edit step fails in most cases, with
2014-04-30 05:35:15 Updating git repository upstream:groff in cache
ERROR: Command failed: git branch master <some SHA1>
fatal: A branch named 'master' already exists.
that's a bug. and i guess it would also happen for any case where the
original checkout is of a branch/tag that already exists in the upstream
that the user proceeds to edit.
if i re-run morph edit, it 'seems' to work (i.e. reports no error), but
the morph file has not been edited. i think it has just stopped because
a repo exists at ../upstream/<chunk>
i think that's a bug too - it should at least report that a repo
already exists, and should probably fail. current behaviour can lead
user to dfo work in upstream/<chunk> and then run a whole build without
realising it's not building the work he/she has done.
br
Paul
9 years, 1 month
[PATCH 0/2] Node.js
by Richard Ipsum
repo: git://git.baserock.org/baserock/baserock/definitions
ref: baserock/richardipsum/node
head: a26afdb650f95868d9227669d7bdedd9ace8d678
Hi,
These are the definitions for a devel-system with node and npm,
npm is included in node.
Richard Ipsum (2):
Add node-js stratum
Add node-js-system
node-js-system-x86_64.morph | 28 ++++++++++++++++++++++++++++
node-js.morph | 11 +++++++++++
2 files changed, 39 insertions(+)
create mode 100644 node-js-system-x86_64.morph
create mode 100644 node-js.morph
--
1.8.4
9 years, 1 month
