`pip install` is a relatively common thing for app builds to use in sudo=,
so it should be built into the buildserver. This then builds in the trust
relationship to pypi, since it comes from Debian rather than some random
pip download/install process.
This expands the gradle wrapper shell script used by the buildserver for
usage outside the buildserver environment. It also allows downloading
whitelisted versions of gradle if they are not yet deployed to the
buildserver by simply upsating the copy of fdroidserver (in contrast to
having to reprovision the whole buildserver).
We first move the buildserver/gradle shell script to the repo root
as gradlew-fdroid, as it's an fdroid specific gradle wrapper.
We also now sync it inside the build VM before each build.
We then add a list of whitelisted gradle distributions taken from the
makebuildserver script.
The script additionally now reads two env vars which tell it where to
expect installed versions of gradle and where it might store downloaded
gradle .zip files. Both of those are configurable from config.py. As the
first should normally just be a subdir of the second it's not exposed in
the example config.py but only used by the buildserver config.py.
Default config now uses this internal gradle wrapper but a path to a
custom wrapper or specific gradle distribution can still be set from
config.py.
Closesfdroid/fdroidserver#98
Ref: fdroid/fdroidserver#370
When a new minor version of an NDK is released, it replaces an older one,
e.g. r16 with r16b (see commit 6f295cb). But old NDK package remains in
the cache and provisioning script unpacks it too as it matches the mask.
Fix NDK provisioning to unzip only while-listed versions.
We should be replacing all our custom git shell commands with python3-git,
since it is a common library for doing that. It will receive a lot more
attention and maintenance than our code for doing it. For example, we
should not ever use shell=True, since that opens up a lot of security
risks.
The currently included Qt has known security issues and is outdated. This
can now be replaced by downloading and installing the Qt installer using
the sudo= build field. @relan's provisioner system will also replace this
once that's done. There are only two apps that currently use the Qt stuff:
* csd.qtproject.minesweeper
* org.openorienteering.mapper
We never allow git via SSH or password/key access, and right now, this
causes things to hang forever. This sets things up to fail quickly
with invalid ssh connections.
BatchMode=yes - passphrase/password querying will be disabled.
StrictHostKeyChecking=yes - never automatically prompt, or add host keys to
the ~/.ssh/known_hosts file, and refuse to connect to hosts whose host key
has changed.
Now that fdroidserver requires Python 3, there's no need to tune sshd for
an old version of Paramiko because Ubuntu 14.04 does not have
python3-paramiko package in its repositories:
https://packages.ubuntu.com/search?keywords=python3-paramiko
We can safely assume that Ubuntu 14.04 users have installed a more recent
version of Paramiko from PIP.
The old hash does not work anymore, at least for platform-27. Where this
new one comes from:
1. Download command line tools from
https://developer.android.com/studio/index.html#command-tools
2. Unzip the package
3. Run ./tools/bin/sdkmanager --licenses
4. Read and accept licenses
5. Find the hash in ./licenses/android-sdk-license
Google releases new API SDKs quite rarely (about 2 times a year), but when
they do this, many apps quickly start using it. Allow downloading new API
SDKs to avoid waiting for the next buildserver rebuild.
Now that the download file name and type seems to have stabilized, I
think we no longer need to manually specify each new added release in
this script to unpack.
closes#331
Google is making gradle automatically download Android SDK components that
are needed by the build, but not already present. We need to support that
since it would be a lot of work to fight it. Plus, since each build starts
from the fresh snapshot, it should not be such a big deal to let each
build install stuff during the process.
closes#268
The ever troublesome gpjenkins box needs to use HTTPS mirrors. Plus it
improves the security of the buildserver, since there have been CVEs that
HTTPS would protect against:
https://www.debian.org/security/2016/dsa-3733
Google is pushing gradle towards downloading all the SDK components that it
needs, rather than having a preconfigured SDK installed. The buildserver
strongly supports the old model, with added checksum checking even. We can
still support the old model by pre-configuring the SDK and locking it down
as root. This can then also support the new model by setting the file perms
so that new packages can be auto-installed, but they cannot overwrite any
packages that come pre-installed and pre-verified.
fdroiddata!2096
closes#247
gradle will now automatically download and install missing bits of the
Android SDK. While we prefer to have the SDK packages fully verified, we
should allow this behavior on the buildserver to ensure that builds work
even when the buildserver can't be updated. Since each build starts from a
clean snapshot, this auto-installed build-tools will only be used for the
single build, so it won't affect other apps.
The new ConstraintLayout library in Android Support has some new custom way
of handling the license. I suspect that they are going to use this new way
with all of the bits that gradle downloads. We also have to support it for
apps that use it, including soon fdroidclient.
fdroiddata!2094
ci-images!1
These should be reasonably backwards compatible, and there is already
automake1.11 for those that need a version that old. As for cmake, there
are five apps that seem to it:
com.amaze.filemanager
org.dolphinemu.dolphinemu
org.navitproject.navit
org.yabause.android
org.videolan.vlc
It looks like VLC is the only app that is currently building and using
cmake in the most recent releases. Some of them used to use cmake, but no
longer.
Sometimes, a build process requires newer versions of build tools than are
available in Debian/stable. Oftentimes, using the package straight from
Debian/testing works fine when a package is not available as a backport.
libtool 2.4.6 is needed for building VLC, so it is one example of this.
The preferences file sets up the apt "pinning" so that all updates are not
installed from testing, only the packages that are requested by adding
"/testing" after then package name.
closes#224
In order to install a package from jessie-backports, apt-get has to be told
to get it from there rather than the main archive. It will not use
jessie-backports by default even if it is added as an apt source.
closes#224
buildserver running in qemu/kvm to support KVM on KVM
jenkins.debian.net runs in QEMU/KVM instances, so in order to run the F-Droid buildserver there, it needs to work inside of a KVM guest. The best way I found to do that is to create QEMU/KVM instances via KVM's "nested" virtualization support. This collection of commits enables using QEMU/KVM as the buildserver when `./makebuildserver` detects that it is running inside of KVM. Otherwise, the old behavior is default: running in VirtualBox.
I have run these tests inside of ubuntu/16.04 on bare metal, which uses VirtualBox, and ubuntu/16.04 KVM guest, which uses QEMU/KVM. It'll also run on the Guardian Project jenkins box, which is Debian/jessie.
@mvdan @CiaranG @krt
See merge request !168
I think the `android update sdk` tool is installing all of the m2 files
that are present in the temp cache, and it seems to do it in order of
newest to oldest. Well done, and I thought that tool couldn't get any
worse. So only include the latest version of android_m2repository*.zip in
the temp cache.
The Android SDK by default includes some Google repositories of their
proprietary SDKs. We of course do not want that stuff ever. We also do
not need the emulator images since this process does not currently install
or run an emulator.
This is the last thing using Chef, which adds a lot of time to the time it
takes to fully provision the buildserver. This slows down development on
the things we are actually using, like running all builds on
jenkins.debian.net.
#210#165
This does not have the careful result rechecking that chef has, when it
installs each package in the list one at a time. So to help with failures
caused by a package failing to download, first try downloading all the
package, then run the install. The install pass will try to download any
missing packages.
Really, this should use ansible or perhaps chef again since those include
lots of tricks around this stuff.
This forces the release channel and version of chef-solo to install on the
guest VM. I was getting really massive, odd stacktraces without specifying
this, and chef is only used for Kivy now anyway.
The technique where /var/cache/apt is mounted as a shared folder conflicts
with vagrant-cachier's workings. Therefore, ignore vagrant-cachier if the
user selects ./makebuildserver's custom apt cache. The shared folder way
has the advantage for CI builds of storing the cache outside of
VAGRANT_HOME, which is set to be in the git project. That gets wiped by
`git clean -fdx` on each CI build.
