Building App::MechaCPAN in alpine docker image failing test

[pattieja1]

I'm using the following Dockerfile:

FROM alpine
RUN apk update && apk upgrade && apk add curl tar make gcc build-base wget gnupg bash perl
SHELL ["/bin/bash", "-c"]

RUN apk add openssh-client
RUN apk add git
RUN apk add which
RUN apk add automake
RUN apk add autoconf
RUN apk add libtool
RUN apk add libxml2-dev
RUN apk add gettext-dev
RUN apk add freetds-dev
RUN apk add expat-dev
RUN apk add openssl
RUN apk add openssl-dev
#RUN apk add pkgconfig
RUN apk add gd-dev
RUN apk add postgresql-dev
RUN apk add libmcrypt-dev
#RUN apk add libtool-ltdl-devel
RUN apk add iproute2

RUN apk add perl-app-cpanminus
RUN apk add perl-try-tiny

#RUN curl -L http://cpanmin.us | perl - App::cpanminus

RUN cpanm App::MechaCPAN

RUN MECHACPAN_TIMEOUT=300 mechacpan perl --threads --skip-tests 5.26

It's failing on test 21:

t/21_install.t ............. 4/? #  - Failed to install 2 modules
t/21_install.t ............. 7/? 
#   Failed test 'Can install /root/.cpanm/work/1580261177.17138/App-MechaCPAN-0.26/t/../test_dists/MBDeps/MBDeps-1.0.tar.gz'
#   at t/21_install.t line 22.
#          got: '-1'
#     expected: '0'

#   Failed test 'Library exists as expected'
#   at t/21_install.t line 24.
t/21_install.t ............. 22/? # Looks like you failed 2 tests of 24.
t/21_install.t ............. Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/24 subtests 

I'm working on converting my centos7 docker build to alpine to make it smaller.

I'm testing building perl after forcing the install of App::MechaCPAN and perl appears to have built okay. I did skip it's tests though.

I did run mechacpan install MIME::Lite@3.030 in the alpine docker image and it installed just fine.

Is this a failure that I can safely ignore or something that's going to come back to bite me later?

alpine 3.11 perl 5.30.1 (from alpine apk repo) App::MechaCPAN 0.26

[atrodo]

That's a good question. It looks like it is failing at installing the Module::Build test package. I'm not entirely sure why that would happen, but I worry that trying to install a Module::Build based module would fail. MIME::Lite appears to be based EU::MM since there is no Build.PL file. Looking for a small Module::Build based module, I found Crypt::Skip32 so you could try and see if that installs correctly with mechacpan.

I've tried replicating locally but doing a cpanm -L local App::MechaCPAN was successful. It could be the lack of the -L portion that is tripping it up, but I haven't had a chance to make sure that I can do that will messing up other things in my development environment. I will try and dig deeper, but any additional logs that you could provide would be helpful.

[pattieja1]

Using my built image, I was able to install Crypt::Skip32 without any issues.

I'll try rebuilding with the above cpanm command and see what happens.

The bulk of issues I'm seeing with tests failing are due to timestamps not in the format the test is expecting. I've seen some talk about that online but no concrete solutions. Currently the real world testing I've done with the final docker image seems to work for what I need, I've just had to skip tests on a handful of packages and force the initial install of App::MechaCPAN.

[atrodo]

I was able to reproduce with an alpine docker image, and it appears that the error is happening because Module::Builder was trying to install itself and failing its own tests. The test specifically were ppm.t and xs.t, both attempting to compile and use an XS module and failing to find EXTERN.h. Turns out that the perl package in alpine does not include the header files required to compile XS modules. When I add the perl-dev package in my tests, I was able to make the error disappear.

I'm going to think about if I could test for that situation and error out, although I'm not sure I can do a reliable enough job nor if that's really the job of a cpan client. In the meantime, I would suggest installing the perl-dev package in your docker, I suspect that you'll have troubles with other XS based packages in the future.

[pattieja1]

Adding perl-dev to the build process has fixed the APP::MechaCPAN install problem. Thanks for figuring that out. The missing header wasn't an obvious issue in the logs/output.

I do use some XS based modules but they didn't have issues building, but I did have to skip their tests (I don't remember why now) to get them to install. They seem to have worked from the testing I've done though.

I'm trying to fix the date related issues by adding

RUN apk add tzdata
RUN cp -f /usr/share/zoneinfo/America/Phoenix /etc/localtime

to the build process but I'm not holding out too much hope based on the google searches I've done.

[pattieja1]

Upon digging further it appears to be a bug in the Time::Piece module included in perl that hasn't been fixed upstream, even though a workaround has been known.

Using a TZ that honors DST should help pass tests for time modules that are trying to test things and leave the tzdata package installed.

I also had to install the procps package so perl didn't have issues with the ps command.

The final failures in the build perl tests were related to UTF and locale assumptions. I didn't dig into them to determine if it's a big problem or not.

Useless use of single ref constructor in void context at op/gv.t line 1191. # parser guessed wrong encoding expected 'CP1252' got 'UTF-8'   #   Failed test 'timelocal year for 1970 1 2 0 0 0' #   at t/Local.t line 109. #          got: '170' #     expected: '70'  #   Failed test 'timegm year for 1970 1 2 0 0 0' #   at t/Local.t line 124. #          got: '170' #     expected: '70' # Looks like you failed 2 tests of 187.  #   Failed test at t/02core_dst.t line 138. #          got: '-14400' #     expected: '-18000'  #   Failed test at t/02core_dst.t line 139. #          got: '2013-01-09 08:07:11 EDT' #     expected: '2013-01-09 07:07:11 EST'  #   Failed test at t/02core_dst.t line 140. #                   '-0400' #     doesn't match '(?^:-0500|EST)' # Looks like you failed 3 tests of 60. Use of uninitialized value $line in split at ../../t/loc_tools.pl line 354, <DATA> line 47. Use of uninitialized value in split at ../../t/loc_tools.pl line 111, <DATA> line 47. Use of uninitialized value $locale_name in split at ../../t/loc_tools.pl line 357, <DATA> line 47. Use of uninitialized value $language_codes in split at ../../t/loc_tools.pl line 369, <DATA> line 47. PROG:  require '../loc_tools.pl'; unless (locales_enabled()) {     print("SKIPPED\n# locales not available\n"),exit; } eval { require POSIX; POSIX->import("locale_h") }; if ($@) {     print("SKIPPED\n# no POSIX\n"),exit; } my $utf8_locale = find_utf8_ctype_locale(); unless ($utf8_locale) {     print("SKIPPED\n# No UTF-8 locale available\n"),exit; } use warnings 'locale'; use locale; setlocale(&POSIX::LC_CTYPE, "C");  "abc def" =~ /\b{wb}.*?/;  "abc def" =~ /\B{wb}.*?/; setlocale(&POSIX::LC_CTYPE, $utf8_locale);  "abc def" =~ /\b{wb}.*?/;  "abc def" =~ /\B{wb}.*?/; EXPECTED: Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 16. Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 16. Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 17. Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 17. Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 17. GOT: Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 16, <DATA> line 47. Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 16, <DATA> line 47. Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 17, <DATA> line 47. Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 17, <DATA> line 47. Use of \b{} or \B{} for non-UTF-8 locale is wrong.  Assuming a UTF-8 locale at - line 17, <DATA> line 47. # Failed test 723 - \b{} in UTF-8 locale at lib/warnings/regexec line 189 make: *** [makefile:832: test_harness] Error 7

[pattieja1]

The locale test issue might be solved in perl 5.30. I'm ignoring it for now.

Thanks again for creating this great piece of software and helping me when I got stuck. :)