We can rely on the debian:testing job to test the bleeding edge, and it is
a lot easier to troubleshoot.
The Fedora job is a lot harder to troubleshoot than the Debian-based jobs,
and they are often quite bleeding edge. Currently, there is a change to
either Python or an image processing lib (Pillow?) that now compresses PNGs
differently than all previous releases. That breaks the tests based on
processing images and checking the SHA-256 matches.
70e7e720b9
fdroidserver!669
This has been in place in a number of other places and has proven stable,
so I'm introducing it here, since the "docker" job actually publishes
docker images that are publicly used. So little painless security fixes
are worthwhile.
https://gitlab.com/fdroid/fdroidserver/-/jobs/4466370098
$ pip install -e .[test]
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try 'pacman -S
python-xyz', where xyz is the package you are trying to
install.
If you wish to install a non-Arch-packaged Python package,
create a virtual environment using 'python -m venv path/to/venv'.
Then use path/to/venv/bin/python and path/to/venv/bin/pip.
If you wish to install a non-Arch packaged Python application,
it may be easiest to use 'pipx install xyz', which will manage a
virtual environment for you. Make sure you have python-pipx
installed via pacman.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
If there was a global default on a machine that was something other than
'master', these things would crash with:
Traceback (most recent call last):
File "/home/hans/code/fdroid/server/fdroid", line 22, in <module>
fdroidserver.__main__.main()
File "/home/hans/code/fdroid/server/fdroidserver/__main__.py", line 230, in main
raise e
File "/home/hans/code/fdroid/server/fdroidserver/__main__.py", line 211, in main
mod.main()
File "/home/hans/code/fdroid/server/fdroidserver/deploy.py", line 833, in main
push_binary_transparency(BINARY_TRANSPARENCY_DIR,
File "/home/hans/code/fdroid/server/fdroidserver/deploy.py", line 705, in push_binary_transparency
local.pull('master')
File "/usr/lib/python3/dist-packages/git/remote.py", line 1045, in pull
res = self._get_fetch_info_from_stderr(proc, progress, kill_after_timeout=kill_after_timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/git/remote.py", line 848, in _get_fetch_info_from_stderr
proc.wait(stderr=stderr_text)
File "/usr/lib/python3/dist-packages/git/cmd.py", line 604, in wait
raise GitCommandError(remove_password_if_present(self.args), status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(1)
cmdline: git pull -v -- local master
stderr: 'fatal: couldn't find remote ref master'
I think most fdroidserver core devs are working on bookworm these days, and
the bullseye version is erroring on things that the bookworm version does
not.
fdroidserver/metadata.py:777 in public function `post_parse_yaml_metadata`:
D202: No blank lines allowed after function docstring (found 1)
It turns out that the maven: field was originally declared as a TYPE_STRING,
given that it was not given a different type in metadata.py's flagtypes.
The code was confused because it was given a default value of `False` rather
than `None` as the rest of the TYPE_STRING fields have.
This construct in build.py means maven: should always be a string:
if '@' in build.maven:
maven_dir = os.path.join(root_dir, build.maven.split('@', 1)[1])
else:
maven_dir = root_dir
Things like apksigner and @obfusk's tools handle this now.
jarsigner is used in the test, since that's the most common use of
`common.find_sdk_tools_cmd()`.
closes#1100
