Use --verbose if you really want a full traceback with your 'you made a
typo in an package ID' messages.
It would be better to do this based on exception types (i.e. our own
exceptions - MetadataException, BuildException, VCSException) would not
print a traceback, but unexpected exceptions would. But the types are
not available at the 'fdroid' level currently.
* E124 closing bracket does not match visual indentation
* E125 continuation line does not distinguish itself from next logical line
* E126 continuation line over-indented for hanging indent
* E127 continuation line over-indented for visual indent
* E128 continuation line under-indented for visual indent
This allows the user to set the path to their Android SDK from the command
line. This option is named after the standard env var ANDROID_HOME, as used
in the build.xml generated by `android update project`. --android-home
takes precendence over the ANDROID_HOME env var if it is set.
`fdroid init` runs before any config.py exists, but it still needs to have
the default config and the SDK path tests. So split those two bits out of
common.read_config() so that they can be run separately before config.py
is in place.
The .fdroid.*.txt password files are only meant to be a conduit for the
passwords, so blow them away everytime. The canonical password is stored
in config.py.
It might makes sense to replace these files with env vars using
-storepass:env and -keypass:env. I figured that the passwords are already
in a file, config.py, so adding more files in the same location with the
same perms would not increase the risk at all.
* Group apk, jar and zip files in the same case
* Use regex to support more patterns and be more flexible
* Only check for usual suspects in jar files (saves time)
* Also catch unknown zip-like files as warnings
These options are needed to configure Java's keytool and jarsigner to use
a Hardware Security Module aka HSM aka smartcard. The defaults provided
are meant to make things work as easily as possible.
Any process can read the process table, and can therefore see the entire
command line of any other process. That means its a bad idea to ever put
passwords as part of a command line. Python is executing keytool and
jarsigner command lines here, so now instead of putting the password on the
command line, a file is passed instead with suitable file permissions.
This should reduce the exposure a lot. But still, sensitive passwords
should not be written to any text file.
This change requires OpenJDK-7 since the :file option to -storepass and
-keypass was only added in Java 7's keytool and jarsigner.
