Add a workaround to open apkcache created with Py2
A workaround for #163.
*May* help in some rare cases, should not break anything.
See merge request !120
This fixes fdroid build com.umang.dashnotifier:18:
ERROR: Could not build app com.umang.dashnotifier due to unknown error: Traceback (most recent call last):
File "/home/mvdan/git/fsr/fdroidserver/build.py", line 1121, in main
options.onserver, options.refresh):
File "/home/mvdan/git/fsr/fdroidserver/build.py", line 950, in trybuild
build_local(app, build, vcs, build_dir, output_dir, srclib_dir, extlib_dir, tmp_dir, force, onserver, refresh)
File "/home/mvdan/git/fsr/fdroidserver/build.py", line 480, in build_local
extlib_dir, onserver, refresh)
File "/home/mvdan/git/fsr/fdroidserver/common.py", line 1335, in prepare_source
srclibpaths.append(getsrclib(lib, srclib_dir, build, preponly=onserver, refresh=refresh))
File "/home/mvdan/git/fsr/fdroidserver/common.py", line 1258, in getsrclib
cmd = replace_config_vars(srclib["Prepare"], None)
File "/home/mvdan/git/fsr/fdroidserver/common.py", line 1822, in replace_config_vars
cmd = cmd.replace('$$NDK$$', build.ndk_path())
AttributeError: 'NoneType' object has no attribute 'ndk_path'
get_ndk_path was removed long ago when App and Build were introduced.
Now Build.ndk_path() should be used. Trying to use the object as a dict
resulted in a nasty crash:
TypeError: 'Build' object is not subscriptable
This is probably a result from faulty rebasing and not enough test
coverage.
CI: Use the new base image
Lighter, since it doesn't include all the stuff required to build and
test the client that we don't need here.
See merge request !116
run `fdroid build` straight out of an app's git repo
This creates a new metadata file type that is meant to be included in the git repo of the app to be built. It uses the same formats as `metadata/`, e.g. `.txt`, JSON, XML, YAML. The filename is instead `.fdroid.(json|txt|xml|yml)`. This metadata then lets the user run `fdroid build` directly in the git repo of the app, and it will run the build as any other fdroid build.
@mvdan @CiaranG @krt @pserwylo @NicoAlt @parmegv feedback, flames, comments wanted
Given the very raw state of testing Android apps with gitlab-ci, I think this is a great opportunity for fdroidserver to become the standard method for testing Android apps with gitlab-ci, starting with this merge request to provide fdroid metadata embedded in the project. What still needs to added is something like `fdroid builddepends debian` and `fdroid builddepends android` which reads the metadata and dumps out a list to be fed to `apt-get install` and `android update sdk --no-ui --filter` respectively, so that a *.gitlab-ci.yml* can look like:
```
apt-get -y install fdroidserver
apt-get -y install `fdroid builddepends debian`
echo y | android update sdk --no-ui --all --filter `fdroid builddepends android`
fdroid build
```
Then that would become a template *.gitlab-ci.yml* that should work on most Android apps.
This was marked Work-In-Progress because it depends on !57
See merge request !62
Though the YAML people recommend .yaml for the file extension, in Android
land it seems clear that .yml has won out:
* .travis.yml
* .gitlab-ci.yml
* .circle.yml
* Ansible main.yml
This adds a new method for `fdroid import` that will generate the fdroidserver
metadata based on a local git repo. This new mode generates the metadata in
the new .fdroid.yaml format in the git repo itself. It is intended as a quick
way to get starting building apps using the fdroidserver tools.
This changes the function name to include the format of the metadata file,
and also changes the order of the args to match the parse_*_metadata()
functions.
The default config for .fdroid.* metadata that is included in a git repo is
different than for the standard metadata/ layout because the expectations
are different. In this case, the most common user will be the app
developer working on the latest update of the app on their own machine.
Since you can have a .fdroid.* metadata file included directly in an
app's git repo, it seems annoying to force developers to also include
a blank config.py in order to run `fdroid build` from their git repo.
The next step after this is some kind of global config file for
setting paths and things that need to be customized that would apply
to all git repos, for example, to enable using a buildserver.
This also required moving all of the env setting for FDroidPopen into
a single place so that it is properly setup when using the local
metadata.
The start up sequence of processes that are based on the .fdroid.* metadata
is a bit different, so this ensures that the environment variables get
properly initialized in all cases.
This also creates a single function where the environment is set. Before
it was being set in multiple places across multiple files.
This allows app makers to include a .fdroid.(json|xml|yaml|txt) metadata
file in the root of the git repo of their app, then they can build it using
`fdroid build`. This is useful for developers who want to maintain the
fdroid build recipe themselves, and run the fdroid build process for their
own builds.
CI: Bump image, now has -dev and gcc
Also, use a specific tag instead of "latest" to avoid breaking old
tags/commits when updating the image.
See merge request !111
If multiple tags point at the same commit, limiting the regex search to
one tag per line would only catch one tag. This broke org.wikipedia's
update check.
py3 fixes for the buildserver
some fixes to get the buildserver working with the new py3 changes. I'm assigning it to @mvdan since he did most of the py3 stuff, but @CiaranG will probably be the user of these changes.
See merge request !113
org.xcsoar hosts its own git repo. Self-hosted git repos can be flaky, and
they are blocked by the Guardian Project jenkins server, so use an app from
github.com instead.
File "/var/lib/jenkins/workspace/fdroidserver-makebuildserver/fdroidserver/build.py", line 1119, in main
options.onserver, options.refresh):
File "/var/lib/jenkins/workspace/fdroidserver-makebuildserver/fdroidserver/build.py", line 954, in trybuild
build_server(app, build, vcs, build_dir, output_dir, force)
File "/var/lib/jenkins/workspace/fdroidserver-makebuildserver/fdroidserver/build.py", line 403, in build_server
output += get
TypeError: Can't convert 'bytes' object to str implicitly
closes#164https://gitlab.com/fdroid/fdroidserver/issues/164
Fixes a couple errors like:
File "./makebuildserver", line 30, in vagrant
out += line
TypeError: Can't convert 'bytes' object to str implicitly
If universal_newlines=False, the default, then Popen will return bytes if
the newlines in the data do not match the system's newlines. Setting it to
true enables auto-conversion, and then guarantees that the data is always
str.
"If universal_newlines is True, the file objects stdin, stdout and stderr
are opened as text streams in universal newlines mode, as described above
in Frequently Used Arguments, otherwise they are opened as binary streams."
https://docs.python.org/3/library/subprocess.html#subprocess.Popen
on the GP jenkins, I got this:
+ git pull
From https://gitlab.com/fdroid/fdroiddata
1df2d03..621ef4f master -> origin/master
You are not currently on a branch. Please specify which
branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
makebuildserver: support running VirtualBox in a VM
For debian.jenkins.net, our test environment is a kvm instance that does not expose the hardware virtualization instructions. So this auto-detects whether the current machine, virtual or not, supports the hardware virtualization. If not, it uses VirtualBox's software emulator, which should run everywhere, even in a kvm instance.
See merge request !108
Python 3
I tried to keep commits separate, so if anything causes trouble, it can be reverted or changed easily.
* pre-commit hooks pass
* all tests pass
* My use of `build`, `checkupdates`, `lint`, `import`, `publish` and `update` work as usual
* 2to3 does not report anything useful anymore (only useless parentheses and list() encapsulation of iterators)
* rewritemeta works exactly as usual
CC @eighthave
See merge request !88
checkupdates: sort tags by date in one go
This greatly speeds up checkupdates when UCM:Tags is used on git
repositories, especially on ones with lots of tags. The old method ran a
command per tag. The new method runs a single command and doesn't
require any sorting.
Test runs show that `fdroid checkupdates org.adaway` is down from ~13s
to ~10s on my laptop.
See merge request !109
