This is from MR !48. It refuses to update because there is no 'keypass'
or 'keystorepass' in the config. These shouldn't be in the config of any
properly set up existing repo in the first place. They certainly aren't
in any of mine (as a result of which, it refused to work on any of
them!)
support plain paths as a serverwebroot
For use cases where there is a web server running on the same machine where the `fdroid update` is being run, allow plain paths in the serverwebroot list. This is useful for debug repos from build servers, like:
https://dev.guardianproject.info/fdroid
This also includes small change in the `fdroid server update` delete behavior: it delays the delete phase until after the new APKs are uploaded. This is keep things working for a long as possible while the repo is being updated.
See merge request !49
make it really easy to upgrade unsigned repos to signed
As a key step to removing support for unsigned repos from fdroidclient (https://gitlab.com/fdroid/fdroidclient/issues/12), this merge request makes `fdroid update` require a signing key. If there is no keystore, it'll prompt the user to create one using `fdroid update --create-key`.
This closes#13
See merge request !48
This provides the final option in this series, allowing the user to just
add --create-key to `fdroid update, and thereby upgrade an unsigned repo to
a proper signed repo. It also might be useful
closes#13https://gitlab.com/fdroid/fdroidserver/issues/13
This moves the method for generating a new keystore for the repo signing
key to a common function so that it can be used in more subcommands beyond
`fdroid init`. The immediate idea is to make `fdroid update --create-key`
upgrade unsigned repos to signed ones so we can make fdroidclient only use
signed repos.
This makes `fdroid init` create a complete, self-contained repo in a single
folder. That makes it easily transferable, backupable, etc. It also means
that `fdroid update` can add a keystore to an existing unsigned repo
without having to worry about finding the right folder or overwriting any
other existing files.
Otherwise, the test process can pick up lots and lots of APKs from various
places like a ~/fdroid folder or various ~/workspace/fdroidserver Jenkins
projects.
For use cases where there is a web server running on the same machine where
the `fdroid update` is being run, allow plain paths in the serverwebroot
list. This is useful for debug repos from build servers, like:
https://dev.guardianproject.info/fdroid
