perl5
perl5 copied to clipboard
Perl
remove Mingw64 test from github pipeline
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 https://github.com/Perl/perl5/pull/19408#issuecomment-1036510563, 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.
The failure also occasionally shows up in the dists own smokes, e.g. here.
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. None of them exhibit that failure when building Socket-2.032., yet those 5.20.x Strawberry distros of mine have the identical mingw-w64 toolchain as Chorny's 5.20.1. UPDATE: No they don't ... my 5.20.0 is built with gcc-4.8.2, whereas 5.20.3 was built with gcc-4.8.3. Presumably, Chorny's 5.20.1 must have been built with one of those 2 toolchains.
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. Naturally, we don't get to see those results. (In some of my modules that conduct similar probes, I've had the outputs written to a log file, and then added a test script that does nothing other than dump the contents of the log file to STDERR. Something like that could be handy here.)
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.
Yet I have created two PR's of late and both failed for the same reason.
@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. 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.
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, https://github.com/Perl/perl5/pull/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.