-
Notifications
You must be signed in to change notification settings - Fork 542
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
t/io/fs.t failures on NetBSD with noatime mounts #16344
Comments
From @eserteThis is a bug report for perl from slaven@rezic.de, On NetBSD systems t/io/fs.t may fail: # Failed test 30 - atime at t/io/fs.t line 324 Test Summary Report t/io/fs.t (Wstat: 0 Tests: 61 Failed: 4) This happens if the filesystem where the test files are created A related issue with more discussion: Probably it's best to skip this test if $^O eq 'netbsd' and As a side note, it looks like the mtime test is also failing, And as a last note, I don't have a NetBSD machine to test --- the Flags: This perlbug was built using Perl 5.20.2 - Mon Sep 18 18:13:32 UTC 2017 (perl -V output is irrelevant --- sent from a different machine) |
From @jkeenanOn Thu, 28 Dec 2017 15:50:55 GMT, slaven@rezic.de wrote:
While adding some SKIP code to t/io/fs.t would be relatively straightforward, validating that it would work would require (I think) that we have access to NetBSD machines in a variety of configurations and OS versions. This would be logistically difficult, given that we have only person submitting smoke tests on NetBSD -- and I suspect those smokers are VMs with stock configurations.
Is that a problem specific to NetBSD or is it a conceptual flaw which extends across platforms? If you think that this is a significant problem, could you open a perlbug focusing just on this?
Thank you very much. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @sevanIn pkgsrc the following patch is added. |
From @jkeenanOn Thu, 28 Dec 2017 15:50:55 GMT, slaven@rezic.de wrote:
Today I applied a series of patches to t/io/fs.t which were intended to make the code more readable and the test descriptions more self-documenting. In the course of doing so, I noticed one anomaly at precisely the point in the code where Sevan Janiyan has proposed a patch based on what has been used in NetBSD pkgsrc for several years. In blead (as of today), that point is: ##### Note that in lines 522-524 we have a SKIP block which does not contain any tests to be skipped! I've been mulling possible explanations for this. * Should the test on line 525 have been *inside* the skip block? If so, it would never be exercised, because the t/test.pl:skip() function on line 523 has no condition attached to it. It has no 'if' or 'unless' clause after the number of tests to be skipped. * Is this just a roundabout way of guaranteeing that there are 2 tests -- one for 'atime' and one for 'mtim' for each OS? If so, wouldn't a simple 'pass("atime not updated");' have been sufficient? To investigate this, I performed a series of 'git blame' calls. It turns out that this code dates back to 2001: ##### Proper skip tests and VMS unlink (beos is the OS predecessor of haiku.) So the SKIP block without a skip condition or a test to be skipped dates back to 2001. The NetBSD patch (once adapted to apply to blead) would entail changing: elsif ($^O eq 'haiku') { to elsif ( But should we leave the body of that 'elsif' block unchanged? Thank you very much. -- |
From @jkeenanOn Thu, 28 Dec 2017 15:50:55 GMT, slaven@rezic.de wrote:
Today I applied a series of patches to t/io/fs.t which were intended to make the code more readable and the test descriptions more self-documenting. In the course of doing so, I noticed one anomaly at precisely the point in the code where Sevan Janiyan has proposed a patch based on what has been used in NetBSD pkgsrc for several years. In blead (as of today), that point is: ##### Note that in lines 522-524 we have a SKIP block which does not contain any tests to be skipped! I've been mulling possible explanations for this. * Should the test on line 525 have been *inside* the skip block? If so, it would never be exercised, because the t/test.pl:skip() function on line 523 has no condition attached to it. It has no 'if' or 'unless' clause after the number of tests to be skipped. * Is this just a roundabout way of guaranteeing that there are 2 tests -- one for 'atime' and one for 'mtime' for each OS? If so, wouldn't a simple 'pass("atime not updated");' have been sufficient? To investigate this, I performed a series of 'git blame' calls. It turns out that this code dates back to 2001: ##### Proper skip tests and VMS unlink (beos is the OS predecessor of haiku.) So the SKIP block without a skip condition or a test to be skipped dates back to 2001. The NetBSD patch (once adapted to apply to blead) would entail changing: elsif ($^O eq 'haiku') { to elsif ( But should we leave the body of that 'elsif' block unchanged? Thank you very much. |
From @jkeenanOn Wed, 31 Oct 2018 01:56:13 GMT, jkeenan wrote:
In commit b325996 to blead, I adapted the patch suggested by Sevan Janiyan from NetBSD pkgsrc. I changed the 'skip' test which lacked a test to skip to a 'pass'. I'll monitor smoke tests of blead several days before closing the ticket. Thank you very much. -- |
From @jkeenanOn Wed, 31 Oct 2018 23:43:07 GMT, jkeenan wrote:
The only test failure observed in t/io/fs.t (http://perl5.test-smoke.org/report/73374) has been on minix, an operating system on which Sevan has just begun to update Perl 5. That failure did not occur in the section of the test file affected by this commit. So I'm resolving this ticket. Thank you very much. -- |
@jkeenan - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.30.0, this and 160 other issues have been Perl 5.30.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#132663 (status was 'resolved')
Searchable as RT132663$
The text was updated successfully, but these errors were encountered: