simple-tiles 0.5.0

Closes #31071.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
docker 1.1.2

Closes #31074.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
docker: update 1.1.2 bottle.
davix 0.3.4

Closes #31065.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
davix: update 0.3.4 bottle.
davix: hoist stable block
OrientDB 1.7.7

Closes #31076.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
orientdb: update 1.7.7 bottle.
android-ndk r10

Closes #31070.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Modify "git rev-parse --verify" args in "has_ref?"

Per the `git-rev-parse(1)` manpage:

  --verify Verify that exactly one parameter is provided, and that it
  can be turned into a raw 20-byte SHA-1 that can be used to access the
  object database. If so, emit it to the standard output; otherwise,
  error out.

  If you want to make sure that the output actually names an object in
  your object database and/or can be used as a specific type of object
  For example, git rev-parse "$VAR^{commit}" will make sure $VAR names
  an existing object that is a commit-ish (i.e. a commit, or an
  annotated tag that points at a commit).

That actually means that:

  git rev-parse --verify af8e768e2bd3b4398bca033998f83b0eb8874914

will _always_ return the SHA-1 hash — regardless of whether or not
that's actually a valid reference!

Thus, when `GitDownloadStragtegy#update_repo` tries to check
`has_ref?`, it mistakenly succeeds, and doesn't actually do a `git fetch
origin`.

The fix is to use:

  git rev-parse --verify "af8e768e2bd3b4398bca033998f83b0eb8874914^{commit}"

Fixes #31045.
Closes #31054.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
FreeImage 3.16.0

Closes #30896.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
freeimage: refresh patch to fix dylib name issues
Revert "android-ndk r10"

This reverts commit e603e5a8c97bbfb5fef66b3936a237d541381a08.