Bug#980640: libdbd-mariadb-perl: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Lucas Nussbaum]

Source: libdbd-mariadb-perl
Version: 1.21-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20210120 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

Relevant part (hopefully):
> 2021-01-20 14:14:45 0 [Note] InnoDB: Loading buffer pool(s) from /<<PKGBUILDDIR>>/t/testdb/ib_buffer_pool
> 2021-01-20 14:14:45 0 [Note] InnoDB: Buffer pool(s) load completed at 210120 14:14:45
> 2021-01-20 14:14:45 0 [Note] Reading of all Master_info entries succeeded
> 2021-01-20 14:14:45 0 [Note] Added new Master_info '' to hash table
> 2021-01-20 14:14:45 0 [Note] /usr/sbin/mysqld: ready for connections.
> Version: '10.5.8-MariaDB-3'  socket: '/<<PKGBUILDDIR>>/t/testdb/mysql.sock'  port: 0  Debian buildd-unstable
> 2021-01-20 14:14:48 3 [Warning] Access denied for user 'root'@'localhost'
> /usr/bin/mysqladmin: connect to server at 'localhost' failed
> error: 'Access denied for user 'root'@'localhost''
> 2021-01-20 14:14:48 4 [Warning] Access denied for user 'root'@'localhost'
> ERROR 1698 (28000): Access denied for user 'root'@'localhost'
> make[1]: *** [debian/rules:30: override_dh_auto_test] Error 1
> make[1]: Leaving directory '/<<PKGBUILDDIR>>'
> make: *** [debian/rules:22: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> E: Build killed with signal TERM after 150 minutes of inactivity

The full build log is available from:
   http://qa-logs.debian.net/2021/01/20/libdbd-mariadb-perl_1.21-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.