| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
These systems are enough to build any other system using baserock.
Other project can have different scheludes, and it doesnt scale
that baserock build all the possible systems as part of its
release process
Other system can still being tested as part of our CIAT process,
of course
Change-Id: I1d4ed907a0eccbe85bdfd2804f2cb9154f881fdf
|
| |
|
|
| |
Change-Id: Ib66b11f52a1673698fa0581d5c79312ad9b6d49d
|
| |
|
|
|
|
|
|
|
| |
This extension allow us to do at configure time:
- Configure different weston.ini files (for GENIVI baseline and GDP)
- Enable weston.service
- Set different backends in weston.service
Change-Id: Idfdb8b3d0e881d2da43eeefe86e42ca6876bb790
|
| |
|
|
|
|
| |
With recent changes 2G is not enough.
Change-Id: I29e0c7c29e3b8a938bdbaf84b475ca4df1aa8dd6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was done using the 'indent' tool, which uses a fork of PyYAML named
'ruamel.yaml' to rewrite YAML files without losing comments, ordering,
or certain elements of formatting.
My aim with doing this is to open the door to automated editing of the
reference system definitions using the 'ruamel.yaml' library. This can
be used to implement automated migration when we want to make changes to
the YAML format that we use to represent Baserock system definitions.
Although this looks drastic, remember that it's actually only altered
65 out of 608 .morph files -- the vast majority already pass unchanged
through my version of ruamel.yaml.
Change-Id: I95ec978714b5bd1c02c90183336a9fbb846cb692
|
| |
|
|
| |
Change-Id: Iffce1a4c25965ca4d7e635534fab16d0e8ccb39b
|
| |
|
|
| |
Change-Id: I12e7c03b30da78da1eb220d2826ce0003d6efe2e
|
| |
|
|
| |
Change-Id: I5ee7098ab77ceb408b3dff5aa8d6dd89dea03db2
|
| |
|
|
| |
Change-Id: I07fad716d823813e91abb0c3f94dd9cec73b339f
|
| |
|
|
| |
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| |
|
|
| |
Change-Id: I041f7d0090b1fbbcfe1634b1635660fda56c9509
|
| |
|
|
|
| |
This will avoid problems when self-upgrading a system and also
will save time when flashing a JETSON TK1 board.
|
| | |
|
| |\
| |
| |
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Daniel Silverstone <daniel.silverstone@codethink.co.uk>
|
| | |
| |
| |
| |
| |
| |
| | |
The build-system is equivalent in functionality to the current
devel-system that we release, but this change allows us to add more
components to the devel-system without increasing the amount of bytes we
have to arrange and transfer when making a release.
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
