| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two versions of setuptools, a bitbucket branch[1]
and a 0.6 branch that lives in sandbox on svn.python.org[2]
0.6 is still maintained but most active development happens
on bitbucket.
This patch moves us onto using setuptools from bitbucket.
We have patched setuptools to allow our import tool to get
information on build dependencies from python packages.
A pull request for our setuptools patch has been submitted upstream[3]
Since there seems to be a bug in setuptools' master branch that prevents
setuptools from being bootstrapped correctly, we are for the moment
based off 7.0 (the most recent release of setuptools)
[1]: https://bitbucket.org/pypa/setuptools
[2]: http://svn.python.org/projects/sandbox/branches/setuptools-0.6/
[3]: https://bitbucket.org/pypa/setuptools/pull-request/106/make-egg_info-command-write-out-setup/diff
|
|\
| |
| |
| |
| |
| | |
Reviewed-by:
- Richard Maw
- Francisco Redondo Marchena
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In mason.configure:
It's not needed to create a separate os.conf file at this point.
In this file we were puting OpenStack credentials used to create
an os.conf file with Ansible. This file was only created when
TEST_INFRASTRUCTURE_TYPE was 'openstack', and Ansible was expecting
it always.
This patch moves the OpenStack credentials to mason.conf, so Ansible
only have to read the variables from one file.
In mason.sh:
The script was always loading /etc/os.conf. This file is only created
when TEST_INFRASTRUCTURE_TYPE is 'openstack'. This patch checks that
the file exists before loading it.
In mason.conf template for Ansible.
OPENSTACK_NETWORK_ID is only present when TEST_INFRASTRUCTURE_TYPE
is 'openstack'. This patch adds a conditon in the template to
skip this value if it doesn't exist.
|
|/
|
|
|
| |
This way, if the Mason system that is being deployed is generic,
it will contain the files needed to setup and run Mason.
|
|\
| |
| |
| |
| | |
Reviewed-by: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
Reviewed-by: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Reviewed-by:
- Francisco Redondo Marchena
- Sam Thursfield
|
| | |
| | |
| | |
| | |
| | | |
Now the build systems have the openstack-clients stratum,
and this system is not longer needed.
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | | |
Reviewed-By: Adam Coldrick <adam.coldrick@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Lorry is used by the Baserock Import tool for fetching source code of
components that are to be imported.
It's also generally useful in devel systems as it can be used for
testing .lorry files prior to pushing them to a Trove.
Additionally, this means that devel systems now contain 'hg', 'bzr',
'svn' and 'cvs', any of which may come in handy.
This increases the size of the devel-system-x86_64-chroot system from
1.4GB to 1.5GB.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: Paul Sherwood <paul.sherwood@codethink.co.uk>
Reviewed-by: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
|
| | | | |
|
| | | | |
|
| |/ /
|/| |
| | |
| | |
| | | |
Reviewed-by: James Thomas <james.thomas@codethink.co.uk>
Reviewed-by: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Paul Sherwood <paul.sherwood@codethink.co.uk>
Conflicts:
systems/devel-system-armv7-highbank.morph
systems/devel-system-armv7-versatile.morph
systems/devel-system-armv7-wandboard.morph
systems/devel-system-armv7b-highbank.morph
systems/devel-system-armv7lhf-highbank.morph
systems/devel-system-armv7lhf-wandboard.morph
systems/devel-system-ppc64-generic.morph
systems/devel-system-x86_32-generic.morph
systems/devel-system-x86_64-generic.morph
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Reviewed-by: Sam Thursfield <sam.thursfield@codethink.co.uk>
Reviewed-by: James Thomas <james.thomas@codethink.co.uk>
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
To remove unneded systemd units
|
| | | | |
| | | | |
| | | | |
| | | | | |
This is automatically configured by systemd
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|/ / / / |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Reviewed-by: Richard Maw
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Reviewed-by: Sam Thursfield
Reviewed-by: Pedro Alvarez
|
| | | | |
| | | | |
| | | | |
| | | | | |
This causes crashes in clickdot in the hmi-controller
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Reviewed-by: Richard Maw
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
This will avoid problems when self-upgrading a system and also
will save time when flashing a JETSON TK1 board.
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Reviewed-by: Richard Maw
Reviewed-by: Sam Thursfield
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add a morph file as well, this way we don't need to modify the source to
build
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This includes the patches from Pedro Alvarez required to make the
release.
Reviewed-by: Pedro Alvarez
Reviewed-by: Sam Thursfield
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Needed for the GPU
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I've branched this from gk20a since this has been forced-pushed before,
so want to ensure this stays around
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This is in a special jetson branch because:
i) it's still a rc, so probably don't want to use this for everything
ii) it contains specific jetson patches (cpufreq)
However the goal will be to maintain a branch all systems will use,
hopefully the 3.18 mainline will include the cpufreq stuff, so we can
start using that for everything
|
| | |_|_|_|/
| |/| | | | |
|
| | | | | | |
|
|\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | | |
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed-By: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
This will make egl weston demos (like weston-simple-egl)
work in a qemu virtual machine
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Reviewed-by: Jim MacArthur
Reviewed-by: Sam Thursfield
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It has 4 modes.
1. Specify PXEBOOT_DEPLOYER_INTERFACE and PXEBOOT_VLAN to
configure the target to pxeboot on a vlan and spawn a dhcp, nfs and
tftp server. This is potentially the fastest, since it doesn't need
to copy data to other servers.
2. Specify PXEBOOT_DEPLOYER_INTERFACE without PXEBOOT_VLAN to
configure do 1, but without creating the vlan interface. This
assumes that you have exclusive access to the interface, such as if
you're plugged in to the device directly, or your interface is
vlanned by your infrastructure team.
This is required if you are serving from a VM and bridging it to the
correct network via macvtap. For this to work, you need to macvtap
bridge to a pre-vlanned interface on your host machine.
3. Specify PXEBOOT_DEPLOYER_INTERFACE and PXEBOOT_CONFIG_TFTP_ADDRESS
to put config on an existing tftp server, already configured by the
dhcp server.
This spawns a tftp server and configures the local nfs server, but
doesn't do a dhcp server. This is useful if you have already got a
dhcp server that serves PXE images.
4. Specify at least PXEBOOT_CONFIG_TFTP_ADDRESS and
PXEBOOT_ROOTFS_RSYNC_ADDRESS to specify existing servers to copy
config, kernels and the rootfs to.
The mode detection can be overridden by specifying PXEBOOT_MODE.
Mode 1 is `spawn-vlan`. Mode 2 is `spawn-novlan`, Mode 3 is
`existing-dhcp` and Mode 4 is `existing-server`.
|