This adds a new method for `fdroid import` that will generate the fdroidserver
metadata based on a local git repo. This new mode generates the metadata in
the new .fdroid.yaml format in the git repo itself. It is intended as a quick
way to get starting building apps using the fdroidserver tools.
1. It is packaged in modern versions of distros, update docs accordingly
2. 1.1 is hopelessly outdated - support 1.4 onwards
3. Check the version properly, and write a better config (previously it
wrote the 1.1 config for 1.1 and 1.3+
4. Ensure that the default share from later versions is not present when
building, it's only required for provisioning.
docs: Add information on binary verification
I added a section about `Binaries:` metadata field. However, my information might be wrong or outdated, since I barely used it by now. Maybe even this field was left out on purpose...
See merge request !83
Use the SOURCE_DATE_EPOCH timestamp [1] if it is available for
timestamps in the tarballs and the HTML documentation.
Also fix permissions inside tarballs to normalize umask
variations.
[1]: https://reproducible-builds.org/specs/source-date-epoch/
Initially, the scanner used libmagic which used magic numbers in the file's
content to detect what kind of file it appears to be. Since that library isn't
available on all systems, we added support for two other libraries, mimetypes
amongst them.
The issue with mimetypes is that it only uses the file's extension, not its
actual content. So this ends in variable behaviour depending on what system
you're using fdroidserver on. For example, an executable binary without
extension would be ignored if mimetypes was being used.
We now drop all libraries - mimetypes too as it depends on the system's
mime.types file - and instead check extensions ourselves. On top of that, do
a simple binary content check to find binary executables that don't have an
extension.
The new in-house code without any dependencies doesn't add any new checks, so
no builds should break. The current checks still work:
% fdroid scanner app.openconnect:1029
[...]
Found executable binary at assets/raw/armeabi/curl
Found executable binary at assets/raw/mips/curl
Found executable binary at assets/raw/x86/curl
Found JAR file at lib/XposedBridgeApi-54.jar
Found JAR file at libs/acra-4.5.0.jar
Found JAR file at libs/openconnect-wrapper.jar
Found JAR file at libs/stoken-wrapper.jar
Found shared library at libs/armeabi/libopenconnect.so
Found shared library at libs/armeabi/libstoken.so
Found shared library at libs/mips/libopenconnect.so
Found shared library at libs/mips/libstoken.so
Found shared library at libs/x86/libopenconnect.so
Found shared library at libs/x86/libstoken.so
Add optional support for vagrant-cachier plugin
Building the basebox is excruciating for people on slow connections. I'm particularly sensitive to this after living in Central America for awhile :)
This won't affect anyone who hasn't installed the plugin. For those who do, it creates a persistent shared folder for each box (ie. testing23.box) and detects directories to cache between VM builds (apt, gems, pip, chef cache, etc.)
(The only downside is that, for those following server setup does who are not aware what vagrant-cachier does, it might be unexpected that artifacts persist between vagrant destroys.)
See merge request !25
Update Vagrantfile and docs to clarify v1.4.3 is ok
Saw in the server docs that we were recommending 1.3.x and saying 1.4.x was broken. I've confirmed that 1.4.x works, and updated things accordingly. Higher version might work, but figured minimal change to build stuff was best :)
See merge request !24
The timestamps in the .gz files are not used for anything, and they break
the reproducibility of the build. Giving --no-name means gzip will not
save the filename and timestamp in the gz file itself. When gunziping, the
current file name will be used, minus the .gz suffix.
