ubuntu focal arm64: rake build stalls because of lintian

[kenhys]

Problem

rake apt:build doesn't finish.

How to reproduce

rake apt:build APT_TARGETS="ubuntu-focal-arm64"

Expected

lintian doesn't stall.

Actual

build process stalls because of lintian.

   dh_builddeb
dpkg-deb: building package 'td-agent' in '../td-agent_3.7.1-1_arm64.deb'.
dpkg-deb: building package 'td-agent-dbgsym' in 'debian/.debhelper/scratch-space/build-td-agent/td-agent-dbgsym_3.7.1-1_arm64.deb'.
        Renaming td-agent-dbgsym_3.7.1-1_arm64.deb to td-agent-dbgsym_3.7.1-1_arm64.ddeb
 dpkg-genbuildinfo
 dpkg-genchanges  >../td-agent_3.7.1-1_arm64.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: full upload (original source is included)
Now running lintian --debug --verbose --profile td-agent/ubuntu td-agent_3.7.1-1_arm64.changes ...

pstree on host:

├─dockerd─┬─docker-containe─┬─docker-containe─┬─build.sh─┬─debuild─┬─lintian─┬─nproc                                                                 
│         │                 │                 │          │         │         └─{lintian}                                                             
│         │                 │                 │          │         ├─tee───{tee}                                                                     
│         │                 │                 │          │         └─{debuild}                                                                       
│         │                 │                 │          └─{build.sh}
│         │                 │                 └─8*[{docker-containe}]
│         │                 └─18*[{docker-containe}]
│         └─19*[{dockerd}] 

Additional Information.

ref. #62

rake yum:build A brief survey:

https://packages.ubuntu.com/search?suite=focal&arch=arm64&searchon=names&keywords=lintian
lintian 2.62 is used.
https://bugs.launchpad.net/ubuntu/+source/lintian
It seems that it is not already known issue.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;repeatmerged=on;src=lintian
It seems that it is not already known issue even though archive.(I've expected something to do with 2.62-2.76)

UPDATE: 2020/11/01, This issue will be fixed in Ubuntu 21.04. (lintian 2.92.0 or later version)

[kenhys]

Even though ---debug --verbose options are specified, there is no debug messages at all. 😞

[kenhys]

I've checked whether this issue is reproducible on unstable or not.
I've used to arm64v8/debian:unstable && apt upgrade

It is reproducible on arm64v8/debian on unstable too. lintian version is:

root@f1123001d735:~# dpkg -l | grep lintian
ii  lintian                          2.76.0                         all          Debian package checker

It has nothing to do with --profile/ without --profile option. (both of them stalls)

[kenhys]

Even though lintian -h seems stop. (arm64v8/debian:unstable)

[kenhys]

It seems that lintian bugs on arm64:(arm64v8/debian:unstable)

file /usr/bin/lintian
/usr/bin/lintian: symbolic link to ../share/lintian/frontend/dplint
root@f1123001d735:~# file ../share/lintian/frontend/dplint
../share/lintian/frontend/dplint: cannot open `../share/lintian/frontend/dplint' (No such file or directory)

[kenhys]

In contrast to unstable/amd64, lintian is perl script on amd64 (expected)

% file /usr/share/lintian/frontend/dplint
/usr/share/lintian/frontend/dplint: Perl script text executable

[kenhys]

On arm64v8/ubuntu:focal, lintian -h also stops even though dplint is perl script:

# file /usr/bin/lintian
/usr/bin/lintian: symbolic link to ../share/lintian/frontend/dplint
root@58022cde8896:/# file /usr/share/lintian/frontend/dplint 
/usr/share/lintian/frontend/dplint: Perl script text executable

[kenhys]

On arm64v8/ubuntu:focal dplint --print-version or --help works.

# /usr/share/lintian/frontend/dplint --print-version
2.62.0
root@58022cde8896:/# /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

[kenhys]

On arm64v8/ubuntu:focal, something wrong with lintian:

root@58022cde8896:/# lintian --print-version
^C
root@58022cde8896:/# lintian --version
^C
root@58022cde8896:/# lintian --help   
^C
root@58022cde8896:/# lintian -v    
^C
root@58022cde8896:/# lintian -h
^C

[kenhys]

On arm64v8/ubuntu:focal, main() doesn't return. debugging with perl -d /usr/bin/lintian --print-version
It is caused around TOOL_RUNNER->($tool_pm_path);

120:	            $TOOL_RUNNER->($tool_pm_path);
  DB<2> p $tool_pm_path 
/usr/share/lintian/commands/lintian.pm
  DB<3> n
^CIO::Async::Loop::Epoll::loop_once(/usr/share/perl5/IO/Async/Loop/Epoll.pm:181):
181:	   return undef if !defined $ret and $! != EINTR;
  DB<3> p $TOOL_RUNNER

# file /usr/share/lintian/commands/lintian.pm 
/usr/share/lintian/commands/lintian.pm: Perl script text executable

[kenhys]

I've reported this issue to upstream

arm64v8 focal: lintian will get stuck with it
https://bugs.launchpad.net/cloud-images/+bug/1881217

[kenhys]

It seems that https://bugs.launchpad.net/cloud-images/+bug/1881217/comments/4 should be a lintian bug.

[kenhys]

It seems that here is the reproducible code extracted from /usr/share/perl5/Lintian/Util.pm
lintian v2.80.0.

use v5.20;
use warnings;
use utf8;
use autodie;

use IO::Async::Loop;
use IO::Async::Process;

my $loop = IO::Async::Loop->new;
my $future = $loop->new_future;
my $status;

my @command = ("nproc");
print $future;

$loop->run_child(
    command => [@command],
    on_finish => sub {
	my ($pid, $exitcode, $stdout, $stderr) = @_;
	$status = ($exitcode >> 8);

	if ($status) {
	    my $message = "Command @command exited with status $status";
	    $message .= ": $stderr" if length $stderr;
	    $future->fail($message);
	    return;
	}

	$future->done($stdout);
    });

$loop->await($future);

[kenhys]

It seems that $future may be valid compared to amd64 case.
use Data::Dumper;

root@0104ff753c95:/# perl epoll.pl 
$VAR1 = bless( {
                 'ready' => 0,
                 'loop' => bless( {
                                    'timequeue' => undef,
                                    'sigattaches' => {},
                                    'masks' => {},
                                    'threadwatches' => {},
                                    'sigmask' => bless( do{\(my $o = '')}, 'POSIX::SigSet' ),
                                    'refaddr_for_fileno' => {},
                                    'epoll' => bless( \*Linux::Epoll::_GEN_0, 'Linux::Epoll' ),
                                    'fakeevents' => {},
                                    'signals' => {},
                                    'iowatches' => {},
                                    'pid' => 42102,
                                    'deferrals' => [],
                                    'old_timer' => '',
                                    'notifiers' => {},
                                    'childwatches' => {},
                                    'os' => {},
                                    'maxevents' => 8,
                                    'childmanager' => undef
                                  }, 'IO::Async::Loop::Epoll' ),
                 'callbacks' => []
               }, 'IO::Async::Future' );

[kenhys]

I've reported with this issue as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964770
I hope the upstream will fix this issue sooner or later.