Wed, 08 Apr 2026 17:39:38 +0000 https://bugs.horde.org/ticket/14984 Horde Database Libraries tests fail against fail on MySQL 8.0.19 and later 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 Tue, 28 Jan 2020 12:05:06 +0000 https://bugs.horde.org/ticket/14984#t93626