This reverts b637568a62 since it added a
redundant check that broke `fdroid init` when the default version dir of
build_tools does not exist on the local system. It then uses the function
that was already in place for checking the build_tools setup in a way that
does not break `fdroid init`.
Now that the fake android home version is not matching the default version,
the tests will catch this bug in the future.
It seems that paths for rsync must have a trailing slash in order to sync
rather than make a subdir, i.e. this makes a duplicate subdir:
rsync /tmp/fdroid/repo repo
While this syncs the dirs
rsync /tmp/fdroid/repo/ repo/
Before, if repo_icon or archive_icon pointed to a non-existent file, then
`fdroid update` would run through the whole process of building a repo,
then fail at the very end because of the non-existent file. On the next
run, `fdroid update` then starts from the beginning.
This just checks for those files at the beginning, and exits with an error
if they are not found.
This is testing the build-tools version auto-detect in `fdroid init`, so it
should be kept as an older version. This is not meant to test the current
version of the build tools.
This means you can just do `cd tests/ && ./run-tests` to run the tests now.
You can still override the APK source with the first argument, like:
cd tests/ && ./run-tests /path/to/lots/of/apks/dir
If `fdroid server update` is run with config that includes an archive, but
the 'archive' subdir does not exist, create it. This mirrors the code that
is in `fdroid update`. Seems to trivial to move to common.py.
To support a fully offline build/signing machine, there is the "local copy
dir". The repo is generated on the offline machine and then copied to a
local dir where a thumb drive or SD Card is mounted. Then on the online
machine, using `fdroid server update --sync-from-local-copy-dir` allows
the whole server update process to happen in a single command:
0. read config.py on online machine's repo
1. rsync from the local_copy_dir to the current dir
2. copy to serverwebroot, awsbucket, etc.