!822
The gpg dependencies are complicated. The previous setup was always
failing with:
The following information may help to resolve the situation:
The following packages have unmet dependencies:
gpg : Depends: gpgconf (= 2.2.20-1~bpo9+1)
Depends: libassuan0 (>= 2.5.0) but 2.4.3-2 is to be installed
Depends: libgpg-error0 (>= 1.35) but 1.26-2 is to be installed
Thanks to @izzysoft to spotting this.
Up until now, the buildserver has not included androguard. Since a
good version of androguard (v3.3.3+) is included in stretch-backports
and the buildserver is already setup to use stretch-backports, this
sets up the buildserver with androguard.
closes#627
https://gitlab.com/eighthave/fdroiddata/-/jobs/611438997
Otherwise it fails to install:
```
gpg : Depends: gpgconf (= 2.2.20-1~bpo9+1)
Depends: libassuan0 (>= 2.5.0) but 2.4.3-2 is to be installed
Depends: libgpg-error0 (>= 1.35) but 1.26-2 is to be installed
```
* 7e8c244473
* !769
The basebox currently provides sudo, but that may not always be the case.
This makes the sudo dependency explicit, so that this provisioning script
can also be used in other settings, like GitLab CI.
Right now, the only thing that Briar needs in sudo: in order to be built
reproducibly is `apt-get install disorderfs`. This includes it in the
standard image to make it easy to spread that technique to many builds.
@grote
`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.
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
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
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
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.
