The failures are:

There were 2 failures:

1) Horde_Db_Adapter_MysqliTest::testColumns
Failed asserting that null matches expected 10.

/tmp/autopkgtest.qBADD9/build.ebg/src/Horde_Db-2.4.0/test/Horde/Db/Adapter/MysqlBase.php:260

2) Horde_Db_Adapter_Pdo_MysqlTest::testColumns
Failed asserting that null matches expected 10.

/tmp/autopkgtest.qBADD9/build.ebg/src/Horde_Db-2.4.0/test/Horde/Db/Adapter/MysqlBase.php:260



The relevant test is:

     public function testColumns()
     {
         $col = parent::testColumns();
         $this->assertEquals(10, $col->getLimit());
         $this->assertEquals(true, $col->isUnsigned());
         $this->assertEquals('int(10) unsigned', $col->getSqlType());
     }

$col->getLimit() is expected to be, for a column defined as "int(10) 
unsigned", 10. However, according to MySQL's release notes 
(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-19.html):

"Display width specification for integer data types was deprecated in 
MySQL 8.0.17, and now statements that include data type definitions in 
their output no longer show the display width for integer types..."

There are some exceptions but my understanding is that since int(10) 
doesn't make sense for MySQL, if you define a table like that MySQL 
will accept it, but a data dictionary query will not return the "(10)" 
part any more.

So the test's assumption is now wrong. It's not obvious to me if 
adjusting the test will leave the assumption present in other parts of 
production code.

Downstream bug: 
https://bugs.launchpad.net/ubuntu/+source/php-horde-db/+bug/1861099