The `force_build_tools` config option was added a long time ago to
brute force the _build-tools_ version by trying to replace the value
in `build.gradle` files. This is never something that should be used
in production, since the app's build metadata should specify this kind
of thing. And now that we're moving towards _androguard_ for
everything except fdroid build and fdroid publish, _build-tools_ will
no longer even be used in the other commands.
latestapps.dat was being used for the old-website, it's not used anymore
Fixes the following crash in production:
```
2020-09-13 19:26:59,000 CRITICAL: Unknown exception found!
Traceback (most recent call last):
File "/home/fbuild/fdroidserver/fdroid", line 22, in <module>
fdroidserver.__main__.main()
File "/home/fbuild/fdroidserver/fdroidserver/__main__.py", line 230,
in main
raise e
File "/home/fbuild/fdroidserver/fdroidserver/__main__.py", line 211,
in main
mod.main()
File "/home/fbuild/fdroidserver/fdroidserver/update.py", line 2451, in
main
app = apps[appid]
KeyError: '45b464b398a7d9fac5a186bd3d3d8dc1e6a25f7f9cd48c7462619b1e5fba87c2'
```
apksigner documents the options as --ks-provider-class and --ks-provider-arg
those seem to be accepted but fail when actually making a signature with
weird internal exceptions. The new options actually work.
From: https://geoffreymetais.github.io/code/key-signing/#scripting
This makes apksigner a hard requirement of the signing procedure.
We'll first try to find a globally installed version from PATH and if
that's not available fall back to using a version from build-tools.
Future TODO: always sign with apksigner, blocked on signature transplant
support for apksigv2/v3
Closesfdroid/fdroidserver#634Closesfdroid/fdroidserver#827
This was accidentally changed in !756 because the functionality was
hidden in `apply_info_from_latest_apk` which is a less than stellar name
for something that also applies infos from app->apk and in this case did
apply info from *oldest* apk->app.
So instead move that into a separate step.
Note: This restores the previous behaviour. There's discussion in #801
on further changes to make the added date also work for repos which
don't keep an archive at all.
There's valid use-cases for setups where set-head --auto fails. This
happens when building an app from a gitlab CI checkout where no remote
tracking branches are setup.
This isn't really a fatal error. When a remote HEAD exists we'll
continue setting it and if none exists and something requires this being
set up later on (either a build script or fdroid checkupdates) then
we'll fail later on with "origin/HEAD not being known to git".
By not failing early we allow the majority of use-cases that don't need
a remote HEAD to continue with just a warning.
The setup in which this can be reproduced is as follows:
(This is roughly what gitlab runner does when setting up a git checkout
for CI)
- mkdir test && cd test
- git init
- git remote add https://gitlab.com/Bubu/fdroidclassic.git
- git fetch --all
- git checkout db0d2a9a5d1d89101a344169013ac5d518185f31
- mkdir nested_repo && cd nested_repo
- git clone .. .
- git remote set-head origin --auto
> error: Cannot determine remote HEAD
A file can be flagged for multiple problems (i.e. multiple unknown maven
repos in one build.gradle file that is included in a scandelete path).
The scanner will try to delete it once for every problem detected, we
don't really care, as long as the file is gone.
fixesfdroid/fdroidserver#759
