| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From [1]:
"Python 2.x is legacy, Python 3.x is the present and future of the language"
As a reference, python3 is already the default python version in Arch,
and other distros like Ubuntu/Debian [2] or Fedora [3] are planning to
switch soon
[1] https://wiki.python.org/moin/Python2orPython3
[2] https://wiki.ubuntu.com/Python/3
[3] https://fedoraproject.org/wiki/Changes/Python_3_as_Default
Change-Id: I6d4d11844d4424bfa49b37fe7d9a3639547c0139
|
|
|
|
| |
Change-Id: I1bcc28de68c9b61b25929cf142e1dd8ea63f8d6f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Ib66f3f56b60cc5dc78d08e28e281d120d83a7b9d
|
|
|
|
| |
Change-Id: I12e7c03b30da78da1eb220d2826ce0003d6efe2e
|
|
|
|
|
|
| |
This is currently hardcoded in morph
Change-Id: I34446bbdf6ad3a7bdd0c34e4fcbd79433ce0fd71
|
|
|
|
|
|
|
|
|
|
| |
This will be used by future versions of Morph.
By adding OSTree to the cross-bootstrap systems we have significantly
increased the size and complexity of them. Some of this can be reduced:
OStree doesn't actually depend on all of 'foundation', just 'glib'.
Change-Id: I89403bf4625178e6f887402b5817f6a727cfcf97
|
|
|
|
|
|
| |
Also make morph depend on PyGObject, it will be needed for OSTree.
Change-Id: Icfa9abb95f884ca9b1dd720648567bd704e74d85
|
|
|
|
|
|
|
|
| |
The lorry-controller webapp uses these, as well as morph-cache-server.
In order to use lorry-controller in systems that don't contain Morph,
we need them to be in a separate stratum.
Change-Id: Ie187c0b506d12ed5e5f8f8ce4a4b91834bf29fe5
|
|
|
|
|
|
|
| |
This allows us to have a system with Lorry and Lorry Controller but
without Morph.
Change-Id: I5164237601d0ff028834c674274f13b6e1f315c9
|
|
|
|
|
| |
six is a python 2 and 3 compatibility library, so move to python-core
should remove dependencies in some strata.
|
|
The installer-x86_64 system is a system that can be used to install other
systems in an storage device. This system is intended to be booted by usb,
pxeboot... to install a Baserock system in your local disk.
The installer system requires the installer.configure extension to generate
a configuration file located in /etc/install.conf. With this extension
you can specify the following variables in a cluster morphology:
- INSTALLER_TARGET_STORAGE_DEVICE: Target storage device to install the
Baserock system.
- INSTALLER_ROOTFS_TO_INSTALL: The location of the root filesystem that
is going to be installed.
- INSTALLER_POST_INSTALL_COMMAND: Commands that will be run after the
installation finishes. It defaults to `reboot -f`.
The installer-utils stratum is required to contain the installer-scripts
chunk. This chunk contains the installer script that is going to be
installed in /usr/lib/installer/installer.py
The clusters/installer-build-system-x86_64.morph file defines the deployment
of a installer system as a rawdisk image. This installer system will
install a build-system-x86_64 located in /rootfs into the /dev/sda device.
Also this cluster defines a subsystem which is the build-system that
is going to end up in /rootfs on the installer system.
|