arm64v8 focal: lintian will get stuck with it

[Kentaro Hayashi]

= Problem

On arm64v8 focal, lintian which is launched by debuild seems get stuck with it.

= Expected

debuild succeeds without stalling.

= How to reproduce

## lintian hang without debuild
(On Ubuntu Server Focal 20.04 amd64)
# sudo apt update
# sudo apt full-upgrade -y
# sudo apt install qemu-user-static qemu-system-arm binfmt-support docker.io -y
# sudo docker run -it arm64v8/ubuntu:focal /bin/bash
(In the docker container)
# apt update
# apt install -y lintian
# lintian --help

## Original reproducer steps
# docker run -it arm64v8/ubuntu:focal /bin/bash
# sed -i 's/^# deb-src/deb-src/g' /etc/apt/sources.list
# apt update
# apt install -y devscripts debhelper-compat
# apt source hello
# cd hello-2.10
# debuild -uc -us -nc

= Actual

lintian will not finish at all.

...
  dh_builddeb
dpkg-deb: building package 'hello' in '../hello_2.10-2ubuntu2_arm64.deb'.
dpkg-deb: building package 'hello-dbgsym' in 'debian/.debhelper/scratch-space/build-hello/hello-dbgsym_2.10-2ubuntu2_arm64.deb'.
 Renaming hello-dbgsym_2.10-2ubuntu2_arm64.deb to hello-dbgsym_2.10-2ubuntu2_arm64.ddeb
 dpkg-genbuildinfo --build=binary
 dpkg-genchanges --build=binary >../hello_2.10-2ubuntu2_arm64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)
Now running lintian hello_2.10-2ubuntu2_arm64.changes ...

# Additional Information

This issue affects only arm64v8:focal not ubuntu:focal.

It seems that lintian --help doesn't work too. So I guess something broken.

# lintian --help
(NO OUTPUT AT ALL!)

# dpkg -l | grep lintian
ii lintian 2.62.0 all Debian package checker

# ls -la /usr/bin/lintian
lrwxrwxrwx 1 root root 32 Apr 3 01:02 /usr/bin/lintian -> ../share/lintian/frontend/dplint
# ls -la /usr/share/lintian/frontend/dplint
-rwxr-xr-x 1 root root 11283 Apr 3 01:02 /usr/share/lintian/frontend/dplint

# /usr/share/lintian/frontend/dplint --help
Lintian v2.62.0
Usage: dplint [General options] <command> [options/arguments...]
General options:
  --include-dir DIR include checks, libraries (etc.) from DIR
  --[no-]user-dirs whether to use files from user directories

dplint doesn't stall.

[Robert C Jennings (rcj)]

Hello, thank you for the bug report. I have been unable to recreate so far. I've been using AWS' m6g instance family as an ARM64 host. I've attempted to recreate by launching Ubuntu 16.04, 18.04, and 20.04 for host VM image and then installed docker.io from the Ubuntu archive before running the reproducer steps in the description. Each of those attempts succeeded without stalling.

Could you tell me more about the environment so we can recreate this? Thank you.

[Kentaro Hayashi (kenhys)]

Thank you for trying to confirm this issue.

I didn't assumed that it depends on host.
I'm using Debian/unstable. The version of docker.io is:

% dpkg -l | \grep docker.io
ii docker.io 19.03.7+dfsg1-3 amd64 Linux container runtime

And only I changed for docker.io settings is `vsyscall=emulated`, explained at https://hub.docker.com/_/centos

[Robert C Jennings (rcj)]

I've recreated on an amd64 Ubuntu Server 20.04 image on AWS. I've updated the description with a newer set of reproducer instructions that uses lintian itself and details the host setup as well.

[Robert C Jennings (rcj)]

I added a -d flag to the invocation of perl in the shebang line of /usr/share/lintian/frontend/dplint Here is what I got:

# lintian --help

Loading DB routines from perl5db.pl version 1.55
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(/usr/bin/lintian:55): };
  DB<1> c
^CIO::Async::Loop::Epoll::loop_once(/usr/share/perl5/IO/Async/Loop/Epoll.pm:181):
181: return undef if !defined $ret and $! != EINTR;
  DB<1> T
@ = DB::DB called from file '/usr/share/perl5/IO/Async/Loop/Epoll.pm' line 181
. = IO::Async::Loop::Epoll::loop_once(ref(IO::Async::Loop::Epoll)) called from file '/usr/share/perl5/IO/Async/Loop.pm' line 642
. = IO::Async::Loop::await(ref(IO::Async::Loop::Epoll), ref(IO::Async::Future)) called from file '/usr/share/perl5/Lintian/Util.pm' line 691
$ = Lintian::Util::safe_qx('nproc') called from file '/usr/share/perl5/Lintian/Internal/FrontendUtil.pm' line 123
@ = Lintian::Internal::FrontendUtil::default_parallel() called from file '/usr/share/lintian/commands/lintian.pm' line 82
$ = require '/usr/share/lintian/commands/lintian.pm' called from file '/usr/bin/lintian' line 36
. = eval {...} called from file '/usr/bin/lintian' line 36
. = main::__ANON__[/usr/bin/lintian:55]('/usr/share/lintian/commands/lintian.pm') called from file '/usr/bin/lintian' line 120
. = dplint::run_tool('/usr/bin/lintian', 'lintian') called from file '/usr/bin/lintian' line 299
. = dplint::main() called from file '/usr/bin/lintian' line 383

I also ran with tracing and that's attached here as

[Robert C Jennings (rcj)]

Eoan arm64 container on focal amd64 host does not recreate this issue.

[Robert C Jennings (rcj)]

I'm moving this from cloud-images to lintian, this is not an issue specific to the image itself.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[q4a (q4a)]

As I can see, this bug may be related to this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964770
And it was closed, because of fix released in lintian 2.92.0.