remove Mingw64 test from github pipeline #19408
Conversation
The test times out regularly. Lets just disable it for now. If someone cares we can revert this patch.
|
I'm opposed, this is the most important Windows compiler. Also, judging from the results on blead, those failures are pretty rare. Out of 23 runs on the first page only 1 failed. |
|
However, recently GitHub updated their windows-latest images from Windows 2019 to 2022. It's possible it affects our tests, but I don't think there's enough data to tell yet. |
|
On Sat, 12 Feb 2022, 02:45 xenu, ***@***.***> wrote:
I'm opposed, this is the most important Windows compiler. Also, judging
from the results on blead <https://github.com/Perl/perl5/commits/blead>,
those failures are pretty rare. Out of 23 runs on the first page only 1
failed.
Yet I have created two PR's of late and both failed for the same reason,
anecdotal evidence sure but 100% false failure rate for me so far.
I don't mind holding off on this and seeing what further evidence shows.
Maybe I'll push some no op PR's to see.
Yves
—
… Reply to this email directly, view it on GitHub
<#19408 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZ5RYIGQJ7YZ4ZTOCYD43U2VKKZANCNFSM5OD4JJKA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
The failure also occasionally shows up in the dists own smokes, e.g. here. Quite frankly, it smells of an actual bug on our side. |
I have a number of x86, 64bitint builds of Strawberry perl from around that time installed on my Windows 7 PC - specifically 5.18.0, 5.20.0, 5.20.3, 5.22.0. However, I notice that this particular FAIL report was run on Windows XP, and I wonder if the problem lies therein. Socket-2.032 conducts some probing tests before generating the Makefile, and I also wonder if there might be something telling in the results of that testing. Other than that, if someone who can reproduce the failure could post the output of that probing, then we might have something better to work with. |
@demerphq, could you provide a link to (at least one of) those failing PRs. |
|
On Sun, 13 Feb 2022, 10:32 sisyphus, ***@***.***> wrote:
< Yet I have created two PR's of late and both failed for the same reason.
@demerphq <https://github.com/demerphq>, could you provide a link to (at
least one of) those failing PRs.
Yeah, of course.
https://github.com/Perl/perl5/actions/runs/1828252194
FWIW I also forwarded the failing PR mail to p5p list.
Thanks for the follow-up!
Warm regards,
Yves
… |
|
I was hoping that I might hit upon a local system here that reproduces the FAIL when building current blead, but no success with that yet. Basically, the build of Socket-2.032 that occurs during the building of perl is different to the build of Socket-2.032 that is done by that perl after it has been installed. I'm not sure what to make of it. |
|
On Mon, 14 Feb 2022 at 12:40, sisyphus ***@***.***> wrote:
I was hoping that I might hit upon a local system here that reproduces the
FAIL when building current blead, but no success with that yet.
However, I've noticed an inconsistency in the way that Socket-2.032 (and
probably earlier) builds - which I've described at
https://rt.cpan.org/Ticket/Display.html?id=141325
Basically, the build of Socket-2.032 that occurs during the building of
perl is different to the build of Socket-2.032 that is done by that perl
after it has been installed.
I'm not sure what to make of it.
FWIW, #19431 had the same failure.
https://github.com/Perl/perl5/actions/runs/1851927439
cheers,
Yves
…--
perl -Mre=debug -e "/just|another|perl|hacker/"
|
|
On Mon, 14 Feb 2022 at 12:40, sisyphus ***@***.***> wrote:
I was hoping that I might hit upon a local system here that reproduces the
FAIL when building current blead, but no success with that yet.
However, I've noticed an inconsistency in the way that Socket-2.032 (and
probably earlier) builds - which I've described at
https://rt.cpan.org/Ticket/Display.html?id=141325
Basically, the build of Socket-2.032 that occurs during the building of
perl is different to the build of Socket-2.032 that is done by that perl
after it has been installed.
I'm not sure what to make of it.
Repeating what I said in the ticket:
I don't have a way to test this at the moment, but a code analysis of
Makefile.PL reveals
return if $ENV{PERL_CORE};
as the first line of the function check_for() which is used to decide which
defines should be passed in. It looks to me like this is the cause.
Yves
…--
perl -Mre=debug -e "/just|another|perl|hacker/"
|
|
On Thu, 17 Feb 2022 at 02:00, demerphq ***@***.***> wrote:
On Mon, 14 Feb 2022 at 12:40, sisyphus ***@***.***> wrote:
> I was hoping that I might hit upon a local system here that reproduces
> the FAIL when building current blead, but no success with that yet.
> However, I've noticed an inconsistency in the way that Socket-2.032 (and
> probably earlier) builds - which I've described at
> https://rt.cpan.org/Ticket/Display.html?id=141325
>
> Basically, the build of Socket-2.032 that occurs during the building of
> perl is different to the build of Socket-2.032 that is done by that perl
> after it has been installed.
>
> I'm not sure what to make of it.
>
Repeating what I said in the ticket:
I don't have a way to test this at the moment, but a code analysis of
Makefile.PL reveals
return if $ENV{PERL_CORE};
as the first line of the function check_for() which is used to decide
which defines should be passed in. It looks to me like this is the cause.
Commenting it out results in build fails for miniperl on linux:
./miniperl -Ilib make_ext.pl lib/auto/Socket/Socket.so MAKE="make"
LIBPERL_A=libperl.a LINKTYPE=dynamic
Can't load module IO, dynamic loading not available in this perl.
(You may need to build a new perl executable which either supports
dynamic loading or has the IO module statically linked into it.)
at /git_tree/perl/lib/IO/Handle.pm line 268.
Compilation failed in require at /git_tree/perl/lib/IO/Handle.pm line 268.
BEGIN failed--compilation aborted at /git_tree/perl/lib/IO/Handle.pm line
268.
Compilation failed in require at /git_tree/perl/lib/IO/Seekable.pm line 100.
BEGIN failed--compilation aborted at /git_tree/perl/lib/IO/Seekable.pm line
100.
Compilation failed in require at /git_tree/perl/lib/IO/File.pm line 132.
BEGIN failed--compilation aborted at /git_tree/perl/lib/IO/File.pm line 132.
Compilation failed in require at /git_tree/perl/lib/FileHandle.pm line 9.
Compilation failed in require at
/git_tree/perl/lib/Module/Load/Conditional.pm line 11.
BEGIN failed--compilation aborted at
/git_tree/perl/lib/Module/Load/Conditional.pm line 11.
Compilation failed in require at /git_tree/perl/lib/IPC/Cmd.pm line 61.
BEGIN failed--compilation aborted at /git_tree/perl/lib/IPC/Cmd.pm line 61.
Compilation failed in require at
/git_tree/perl/lib/ExtUtils/CBuilder/Base.pm line 9.
BEGIN failed--compilation aborted at
/git_tree/perl/lib/ExtUtils/CBuilder/Base.pm line 9.
Compilation failed in require at
/git_tree/perl/lib/ExtUtils/CBuilder/Platform/Unix.pm line 5.
BEGIN failed--compilation aborted at
/git_tree/perl/lib/ExtUtils/CBuilder/Platform/Unix.pm line 5.
Compilation failed in require at (eval 9) line 1.
BEGIN failed--compilation aborted at (eval 9) line 1.
Compilation failed in require at Makefile.PL line 19.
Unsuccessful Makefile.PL(cpan/Socket): code=65280 at make_ext.pl line 532.
makefile:587: recipe for target 'lib/auto/Socket/Socket.so' failed
make: *** [lib/auto/Socket/Socket.so] Error 2
…--
perl -Mre=debug -e "/just|another|perl|hacker/"
|
|
On Thu, 17 Feb 2022 at 02:17, demerphq ***@***.***> wrote:
On Thu, 17 Feb 2022 at 02:00, demerphq ***@***.***> wrote:
> On Mon, 14 Feb 2022 at 12:40, sisyphus ***@***.***> wrote:
>
>> I was hoping that I might hit upon a local system here that reproduces
>> the FAIL when building current blead, but no success with that yet.
>> However, I've noticed an inconsistency in the way that Socket-2.032 (and
>> probably earlier) builds - which I've described at
>> https://rt.cpan.org/Ticket/Display.html?id=141325
>>
>> Basically, the build of Socket-2.032 that occurs during the building of
>> perl is different to the build of Socket-2.032 that is done by that perl
>> after it has been installed.
>>
>> I'm not sure what to make of it.
>>
> Repeating what I said in the ticket:
>
> I don't have a way to test this at the moment, but a code analysis of
> Makefile.PL reveals
>
> return if $ENV{PERL_CORE};
>
> as the first line of the function check_for() which is used to decide
> which defines should be passed in. It looks to me like this is the cause.
>
> Commenting it out results in build fails for miniperl on linux:
./miniperl -Ilib make_ext.pl lib/auto/Socket/Socket.so MAKE="make"
LIBPERL_A=libperl.a LINKTYPE=dynamic
I also see this:
# TODO: Needs adding to perl5 core before importing dual-life again
check_for(
confkey => "i_netinet_ip",
define => "I_NETINET_IP",
header => "#include <netinet/ip.h>",
);
Which seems related and maybe a bit suspicious.
cheers,
Yves
…--
perl -Mre=debug -e "/just|another|perl|hacker/"
|
|
Is this still an issue? |
It's my very casual impression that the Mingw64 CI setup is now DWIMming, which would obviate the need for this pull request. @demerphq, if you feel this is still needed, could you resolve the merge conflicts so we can move the discussion forward? Thank you very much. |
|
I am going to close this PR, as I think whatever was causing the regular failures seems to have stopped. I havent seen a false positive for ages. |
6 participants
The test times out regularly. Lets just disable it for now.
If someone cares we can revert this patch.