The OSX tests seem to run slower, they often timeout. So only run
the test suite with the installed version of fdroid, instead of the
three rounds that ./complete-ci-tests does.
This reverts commit 5f5d3ea896.
These new scanner rules for JARs causes most builds on fdroiddata to
break. For example, at least the past 20 releases of
org.fdroid.fdroid. fdroiddata needs to be cleaned up and prepared for
this before we can include 5f5d3ea896
I'm running fdroid scanner on the whole archive now, I'll post the log
to an issue once its done. Ignoring test files would eliminate some
of these build failures, at least for most org.fdroid.fdroid builds.
refs #!325
This fixes a problem when there is a broken symlink with the name
AndroidManifest.xml which will then lead to a crash when trying to open
it for trying to remove the debuggable flag.
Wow, this is hacky and weird, but its been there for a long time. I
don't know if its even relevant anymore, but is isolated so it
shouldn't hurt anything. Plus there is a test for it in
tests/complete-ci-tests, so it seems worth fixing.
* `make -C locale` updates all the sources
* `make -C locale compile` can compile the binaries, but the preferred way
is `python3 setup.py compile_catalog`.
The way to officially include a new language in the source tarball is to
add it to the MANIFEST.in. Otherwise, it will not be included in the
source tarball, and therefore won't be installed when using apt, pip, etc.
Java9 is starting to roll out on some of the Travis CI machines, but
the Android SDK does not yet work on Java9, it throws:
java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
The Python argparse library has its own strings, which are translatable
via gettext. This gets those sources strings from the library, and
includes them in this project. Since gettext is invoked and configured
in fdroidserver, fdroidserver needs to handle the translations for the
libraries it uses.
The file context lets the translators know which command the string applies
to. It does not have line numbers, since those are less useful, while
causing lots of merge conflicts.
Running `fdroid verify` I was seeing FDroidExceptions from verify.py:98
that had a tuple rather than a string.
Traceback (most recent call last):
File "/home/hans/code/fdroid/server/fdroid", line 152, in <module>
main()
File "/home/hans/code/fdroid/server/fdroid", line 128, in main
mod.main()
File "/home/hans/code/fdroid/server/fdroidserver/verify.py", line 98, in main
logging.info("...NOT verified - {0}".format(e))
File "/home/hans/code/fdroid/server/fdroidserver/exception.py", line 22, in __str__
ret += "\n==== detail begin ====\n%s\n==== detail end ====" % ''.join(self.detail).strip()
TypeError: sequence item 1: expected str instance, HTTPError found
An app may not have a top-level build.gradle file, while Gradle still
creates top-level .gradle/ directory. When build.gradle is absent,
fdroidserver will not remove .gradle/, scanner will find binaries in it
and fail the whole build.
Fix this by also checking for settings.gradle file (should always exist
in the top-level directory) in addition to build.gradle.
