The default timeout setup is 1 hour and it's not sufficient for build
jobs. Previously we asked contributor to setup this timeout to 2 hours
in their GitLab preferences, see
https://docs.gitlab.com/ce/ci/pipelines/settings.html#timeout and
https://wiki.debian.org/Teams/MySQL/patches.

Since GitLab 12.3, the timeout can be specified directly on job
defintion, see https://docs.gitlab.com/ce/ci/yaml/README.html#timeout.

Plus fix a typo.

A major sync of upstream pacakging accidentally included some lines that
were ancient and should not have been imported on 10.5 in Debian:
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2039c2755d0c642718dcc8be852174205577542b

Upstream packaging seems to have introduced this line 9 years ago:
https://github.com/MariaDB/server/commit/cfd4fcb0bc3d469dfca74dae30d17250d65fdd91#diff-733e7d6cfbf529c0530e7b06c97071e2c7dafa6d8b673495fecdce3f1d57015bR139

These lines are now also being removed upstream in:
https://github.com/MariaDB/server/pull/1825

Forward-ported from https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/85a20660861cca13c62e58468400f3420b970551

- Drop riscv64 patch applied upstream.
- Drop spelling fixes applied upstream.
- Update symbols to include new one from MariaDB Client 3.1.13.
- Remove obsolete sql file removed by upstream (MDEV-24586).

Update to upstream version '10.5.10'
with Debian dir 47fffb242f85a3917a305d3dc1794214d21bc128

Checking for the existence of the systemctl command only tells us that
systemd is installed, however it does not tell us if systemd is running.
What we really want to do here is reload systemd if it's installed AND
if it's running. The usual way to check if systemd is running is to
check for the existence of '/run/systemd/system'.

Why would systemd be installed but not running? This is something that
happens when one sets up or upgrade a system in a chroot or container.

For more details refer to the bug report:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983563>

mark systemd files [linux-any] in debian/*.install

See merge request mariadb-team/mariadb-10.5!3

(restore tag that was mistakenly dropped in 2039c275)

chmod a+x debian/mariadb-server-10.5.install
add #!/usr/bin/dh-exec to top of debian/mariadb-server-10.5.install

Reference: "General Porting Issues" section of
  https://www.debian.org/ports/hurd/hurd-devel-debian

- Since cb793cf8 the whole autopkgtest
  override can be removed as it has no effect.

- Don't allow upgrade test from Ubuntu 20.04 MySQL 8.0 to fail anymore as
  it should always pass now.

- Install procps to avoid failure in the Debian Sid MySQL 8.0 installation
  step so where the postinst script often fails if process check is lacking.

- Exclude mariadb-plugin-columnstore in when installing MariaDB 10.5 from
  MariaDB.org repository as it is not available for 10.5.9

Amend old changelog entry with CVE-2020-28912.

MySQL 5.7 has been removed from Debian Sid, so this test cannot work
anymore. There is still the Ubuntu Bionic MySQL 5.7 ugprade test, which
was the last Ubuntu LTS version to include MySQL 5.7.

- Drop mysql-test/main/drop.test patch applied upstream

Update to upstream version '10.5.9'
with Debian dir 7cdfb6c60b9c82c08036a646c5b81deecec41af8

The older MariaDB.org packages were built against libreadline5 and depend
on it to install. As it was removed from Sid (and Bullseye), fetch and
install it from Buster.

This can eventually be removed once we stop backwards compat testing for
older MariaDB versions (new ones don't depend on it).

- chrpath is not used at all
- cracklib-runtime is only used for testing
- apparmor is disabled, thus dh-apparmor is unused
- gdb is only used for testing
- libarchive-dev is only used in ds_archive.cc, which is not built

Also add testing for MySQL 5.7 upgrades since Debian Sid contains both
MySQL 8.0 and MySQL 5.7.

This is no longer needed since the Debian Testing archive no longer
has mariadb-10.3 not the libmariadbclient-dev empty metapackage it had.

Turns out we still need libmariadbclient-dev to have mariadb-10.5
migrate from unstable to testing, otherwise some archs will refuse
the migration as they still expect a replacement for libmariadbclient-dev
from mariadb-10.3.

From https://release.debian.org/britney/update_output.txt

  trying: mariadb-10.5
  skipped: mariadb-10.5 (1, 0, 34)
    got: 31+0: a-1:a-27:a-1:a-0:i-1:m-0:m-0:p-0:s-1
    * i386: libmariadbclient-dev

This reverts commit 03865965.

The test main.drop 'innodb' failed with:

  CURRENT_TEST: main.drop
  --- /<<PKGBUILDDIR>>/mysql-test/main/drop.result	2020-11-10 13:14:54.000000000 +0000
  +++ /<<PKGBUILDDIR>>/mysql-test/main/drop.reject	2020-11-14 15:52:14.649154562 +0000
  @@ -135,7 +135,7 @@
   use mysql_test;
   create table t1(c int);
   drop database mysql_test;
  -ERROR HY000: Error dropping database (can't rmdir './mysql_test', errno: 39 "Directory not empty")
  +ERROR HY000: Error dropping database (can't rmdir './mysql_test', errno: 93 "Directory not empty")
   select database();
   database()
   mysql_test

  mysqltest: Result content mismatch

In mips however '93' is a valid value, so fix the test.

Update to upstream version '10.5.8'
with Debian dir e84dde1fdfc5bfec75a7c646e72a378006a86c2f