Fix gradle adaptation for custom buildToolsVersion configurations
I have ```build_tools = "22.0.1"``` configured in my config.py, however a recent fdroidserver update broke this. This PR fixes it for me.
See merge request !64
final 0.4.0 fixes
Because `setup.py` is broken because `MANIFEST.in` is still pointing to `README` and not `README.md`, the 0.4.0 tag needs to be deleted. This merge requests fixes that and two other minor issues. This has passed multiple runs of the test suite, both on my machine and the jenkins box.
See merge request !61
let setuptools determine the base install path on OSX
This is the last commit from me before the 0.4.0 release. Its ready to go!
A gentle reminder:
* sign the tag: `git tag -s 0.4.0 -m "tagging release 0.4.0"`
* release tags are `0.4.0` format, not `v0.4.0`
* change the version in `setup.py` to match the tag exactly, char by char
Then I'll post the update to pypi.python.org
See merge request !59
Instead of trying to guess which absolute path and .egg name
everything will be installed into, just use a relative path and the
setup process will do the right thing (so far, at least).
BSD/OSX porting and tests
This makes `fdroid init` and `fdroid update` work on BSD/OSX and maybe Cygwin also (I didn't test Cygwin). It also makes the install process more tolerant, like not requiring `python-magic` to run, while using it if its available.
Some fixes and additional tests are also included. The commit messages have more info.
See merge request !56
Since `python setup.py sdist` provides the actual tarball that will be
installed via `easy_install`, `pip install`, etc. it should also be tested.
The existing `pip install -e $WORKSPACE` tests the .egg-link install format
If you run `python setup.py install` from the git repo, then it will be
installed using the .egg-link format, which just points to the git repo.
`fdroid init` needs to handle that when looking for example files to copy.
On OSX, when Java is not installed, it'll fail to create the keystore, but
then give an error from chmod failing. This changes things so that the
missing Java is reported instead.
There are two forms of python-magic, one included in libmagic that is
default on Debian, and another Python wrapper for libmagic that is
called 'python-magic' on pypi. Those both rely on the compiled binary
library libmagic. For platforms without good package management, fallback
to using the built-in 'mimetypes' library if 'magic' is not available.
This supports OSX, Windows, and BSD.
Python libraries work better in Python than running external commands, and
it also makes the code much more portable. For example, the GNU and BSD
sed commands have different, and sometimes conflicting, flags.
This also reworks the regexp patterns to be more tightly focused, and not
change the same variable name in comments or elsewhere.
To make the core tools portable to platforms like Mac OS X and Windows,
remove the dependency on wget and instead use Python Requests, which
probably has better performance anyway.
