Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ubuntu focal arm64: rake build stalls because of lintian #65

Closed
kenhys opened this issue May 25, 2020 · 16 comments
Closed

ubuntu focal arm64: rake build stalls because of lintian #65

kenhys opened this issue May 25, 2020 · 16 comments
Labels
bug Something isn't working wontfix This will not be worked on

Comments

@kenhys
Copy link
Contributor

kenhys commented May 25, 2020

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
Copy link
Contributor Author

kenhys commented May 25, 2020

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

@kenhys
Copy link
Contributor Author

kenhys commented May 27, 2020

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
Copy link
Contributor Author

kenhys commented May 27, 2020

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

@kenhys
Copy link
Contributor Author

kenhys commented May 27, 2020

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
Copy link
Contributor Author

kenhys commented May 27, 2020

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
Copy link
Contributor Author

kenhys commented May 27, 2020

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
Copy link
Contributor Author

kenhys commented May 27, 2020

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
Copy link
Contributor Author

kenhys commented May 27, 2020

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
Copy link
Contributor Author

kenhys commented May 27, 2020

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
Copy link
Contributor Author

kenhys commented May 29, 2020

I've reported this issue to upstream

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

@kenhys
Copy link
Contributor Author

kenhys commented Jul 10, 2020

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

@kenhys
Copy link
Contributor Author

kenhys commented Jul 10, 2020

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
Copy link
Contributor Author

kenhys commented Jul 10, 2020

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
Copy link
Contributor Author

kenhys commented Jul 13, 2020

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.

@kenhys kenhys added bug Something isn't working help wanted Extra attention is needed labels Jul 17, 2020
@kenhys kenhys added the wontfix This will not be worked on label Sep 18, 2020
@kenhys
Copy link
Contributor Author

kenhys commented Nov 2, 2020

FYI: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964770

This issue seems to be fixed in lintian 2.92.0. so it will be fixed by next Ubuntu 21.04 “Hirsute Hippo” release.

@kenhys kenhys removed the help wanted Extra attention is needed label Nov 2, 2020
ashie added a commit that referenced this issue Dec 17, 2020
See #65

Signed-off-by: Takuro Ashie <ashie@clear-code.com>
ashie added a commit that referenced this issue Dec 21, 2020
See #65

Signed-off-by: Takuro Ashie <ashie@clear-code.com>
@kenhys
Copy link
Contributor Author

kenhys commented Jan 18, 2021

This issue was fixed in upstream and the workaround is already implemented, so I'll close this issue.

@kenhys kenhys closed this as completed Jan 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant