cwd_enoent.t fails on DragonFly BSD

[p5pRT]

Migrated from rt.perl.org#133141 (status was 'open')

Searchable as RT133141$

[p5pRT]

From @xenu

On the latest blead​:

---

% ./perl -I ../lib ../dist/PathTools/t/cwd_enoent.t 1..8 not ok 1 - regular getcwd result on non-existent directory # Failed test 'regular getcwd result on non-existent directory' # at ../dist/PathTools/t/cwd_enoent.t line 34. # got​: '/tmp/LPDQmQvz61/testdir' # expected​: undef not ok 2 - regular getcwd errno on non-existent directory # Failed test 'regular getcwd errno on non-existent directory' # at ../dist/PathTools/t/cwd_enoent.t line 35. # got​: '0' # expected​: '2' not ok 3 - regular abs_path result on non-existent directory # Failed test 'regular abs_path result on non-existent directory' # at ../dist/PathTools/t/cwd_enoent.t line 39. # got​: '/tmp/LPDQmQvz61/testdir' # expected​: undef not ok 4 - regular abs_path errno on non-existent directory # Failed test 'regular abs_path errno on non-existent directory' # at ../dist/PathTools/t/cwd_enoent.t line 40. # got​: '0' # expected​: '2' ok 5 - perl getcwd result on non-existent directory ok 6 - perl getcwd errno on non-existent directory ok 7 - perl abs_path result on non-existent directory ok 8 - perl abs_path errno on non-existent directory # Looks like you failed 4 tests of 8.

---

The problem is similar to #132733, getcwd() doesn't fail on non-existent directories on DragonFly BSD.

I'm sure it's a bug in DragonFly, but I think we should skip failing tests until it's fixed upstream.

[p5pRT]

From @xenu

The patch is attached.

[p5pRT]

From @xenu

0001-getcwd-doesn-t-fail-on-non-existent-directories-on-D.patch

From 0db64c5b2058a7a3c33e2e9a58ff4bda04a30833 Mon Sep 17 00:00:00 2001
From: Tomasz Konojacki <[email protected]>
Date: Sun, 22 Apr 2018 23:49:59 +0200
Subject: [PATCH 1/1] getcwd() doesn't fail on non-existent directories on
 DragonFly BSD.

Until it's fixed upstream, we should skip tests that don't expect
this behaviour.

[RT #133141]
---
 dist/PathTools/t/cwd_enoent.t | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/dist/PathTools/t/cwd_enoent.t b/dist/PathTools/t/cwd_enoent.t
index ee99423cbb..b9adddeab7 100644
--- a/dist/PathTools/t/cwd_enoent.t
+++ b/dist/PathTools/t/cwd_enoent.t
@@ -24,6 +24,10 @@ foreach my $type (qw(regular perl)) {
 	skip "_perl_abs_path() not expected to work", 4
 	    if $type eq "perl" &&
 		!(($Config{prefix} =~ m/\//) && $^O ne "cygwin");
+
+	skip "getcwd() doesn't fail on non-existent directories on this platform", 4
+	    if $type eq 'regular' && $^O eq 'dragonfly';
+
 	no warnings "redefine";
 	local *Cwd::abs_path = \&Cwd::_perl_abs_path if $type eq "perl";
 	local *Cwd::getcwd = \&Cwd::_perl_getcwd if $type eq "perl";
-- 
2.17.0

[p5pRT]

From @jkeenan

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.

Available for smoke-testing in​: smoke-me/jkeenan/xenu/133141-dragonfly

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @khwilliamson

On 04/24/2018 12​:37 PM, James E Keenan via RT wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.

Available for smoke-testing in​: smoke-me/jkeenan/xenu/133141-dragonfly

I support adding skips to tests during the freeze which fix failing smokes. The changes are isolated to the particular .t, and don't affect the functioning of the actual interpreter.

But I'm thinking that skips for OS bugs, like this, should have be written so that they don't apply to any future version of the OS, if we have any hope at all that the vendor will eventually fix it. If the OS gets fixed, the test will automatically happen again; if a new version of the OS is released, and is still broken, we would have to update the test, but could then prod the vendor that this is an issue.

[p5pRT]

From @jkeenan

On Tue, 24 Apr 2018 18​:37​:20 GMT, jkeenan wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.

Available for smoke-testing in​: smoke-me/jkeenan/xenu/133141-dragonfly

Xenu​: It appears that you are the only person smoking on Dragonfly at the moment. Could you please test this branch on those rigs?

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @xenu

On Fri, 27 Apr 2018 11​:38​:17 -0700 "James E Keenan via RT" <perlbug-followup@​perl.org> wrote​:

Xenu​: It appears that you are the only person smoking on Dragonfly at the moment. Could you please test this branch on those rigs?

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

--- via perlbug​: queue​: perl5 status​: open https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133141

Looks good​: http​://perl5.test-smoke.org/report/65465

[p5pRT]

From @iabyn

On Tue, Apr 24, 2018 at 02​:18​:15PM -0600, Karl Williamson wrote​:

On 04/24/2018 12​:37 PM, James E Keenan via RT wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.

Available for smoke-testing in​: smoke-me/jkeenan/xenu/133141-dragonfly

I support adding skips to tests during the freeze which fix failing smokes. The changes are isolated to the particular .t, and don't affect the functioning of the actual interpreter.

But I'm thinking that skips for OS bugs, like this, should have be written so that they don't apply to any future version of the OS, if we have any hope at all that the vendor will eventually fix it. If the OS gets fixed, the test will automatically happen again; if a new version of the OS is released, and is still broken, we would have to update the test, but could then prod the vendor that this is an issue.

While agree in principle, this late in code freeze, I'm happy for that patch to applies as-is (i.e. skip those tests if $^O eq 'dragonfly', regardless of version).

The skip condition can always be softened later.

-- "I used to be with it, but then they changed what ‘it’ was, and now what I’m with isn’t it. And what’s ‘it’ seems weird and scary to me."   -- Grandpa Simpson (It will happen to you too.)

[p5pRT]

From @xsawyerx

On 04/30/2018 03​:27 PM, Dave Mitchell wrote​:

On Tue, Apr 24, 2018 at 02​:18​:15PM -0600, Karl Williamson wrote​:

On 04/24/2018 12​:37 PM, James E Keenan via RT wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached. Available for smoke-testing in​: smoke-me/jkeenan/xenu/133141-dragonfly

I support adding skips to tests during the freeze which fix failing smokes. The changes are isolated to the particular .t, and don't affect the functioning of the actual interpreter.

But I'm thinking that skips for OS bugs, like this, should have be written so that they don't apply to any future version of the OS, if we have any hope at all that the vendor will eventually fix it. If the OS gets fixed, the test will automatically happen again; if a new version of the OS is released, and is still broken, we would have to update the test, but could then prod the vendor that this is an issue. While agree in principle, this late in code freeze, I'm happy for that patch to applies as-is (i.e. skip those tests if $^O eq 'dragonfly', regardless of version).

Go for it.

[p5pRT]

From @iabyn

On Mon, Apr 30, 2018 at 11​:53​:43PM +0300, Sawyer X wrote​:

On 04/30/2018 03​:27 PM, Dave Mitchell wrote​:

On Tue, Apr 24, 2018 at 02​:18​:15PM -0600, Karl Williamson wrote​:

On 04/24/2018 12​:37 PM, James E Keenan via RT wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached. Available for smoke-testing in​: smoke-me/jkeenan/xenu/133141-dragonfly

I support adding skips to tests during the freeze which fix failing smokes. The changes are isolated to the particular .t, and don't affect the functioning of the actual interpreter.

But I'm thinking that skips for OS bugs, like this, should have be written so that they don't apply to any future version of the OS, if we have any hope at all that the vendor will eventually fix it. If the OS gets fixed, the test will automatically happen again; if a new version of the OS is released, and is still broken, we would have to update the test, but could then prod the vendor that this is an issue. While agree in principle, this late in code freeze, I'm happy for that patch to applies as-is (i.e. skip those tests if $^O eq 'dragonfly', regardless of version).

Go for it.

Now applied as v5.27.11-25-g02bf4969b4

-- Fire extinguisher (n) a device for holding open fire doors.

[jkeenan]

@xenu,

In May 2018, we applied this patch from you to skip 4 tests in PathTools t/cwd_enoent.t on DragonflyBSD. Discussion suggested that at some point we might be able to relax that skip condition.

Can we remove the 'skip'?

And, while we're talking about Dragonfly -- are you in a position to submit smoke-test reports on blead on this platform?

Thank you very much. Jim Keenan

[tonycoz]

Can we remove the 'skip'?

It doesn't look like it:

$ git diff ../dist/PathTools/t/cwd_enoent.t | cat
diff --git a/dist/PathTools/t/cwd_enoent.t b/dist/PathTools/t/cwd_enoent.t
index 510c65ed0c..b0bf11ae2a 100644
--- a/dist/PathTools/t/cwd_enoent.t
+++ b/dist/PathTools/t/cwd_enoent.t
@@ -26,8 +26,8 @@ foreach my $type (qw(regular perl)) {
            if $type eq "perl" &&
                !(($Config{prefix} =~ m/\//) && $^O ne "cygwin");

-       skip "getcwd() doesn't fail on non-existent directories on this platfor\
m", 4
-           if $type eq 'regular' && $^O eq 'dragonfly';
+       #skip "getcwd() doesn't fail on non-existent directories on this platfo\
rm", 4
+       #    if $type eq 'regular' && $^O eq 'dragonfly';

        no warnings "redefine";
        local *Cwd::abs_path = \&Cwd::_perl_abs_path if $type eq "perl";
$ ./perl harness ../dist/PathTools/t/cwd_enoent.t 
../dist/PathTools/t/cwd_enoent.t .. 1/8
#   Failed test 'regular getcwd result on non-existent directory'
#   at t/cwd_enoent.t line 39.
#          got: '/tmp/TecsIaSgYF/testdir'
#     expected: undef

#   Failed test 'regular getcwd errno on non-existent directory'
#   at t/cwd_enoent.t line 40.
# Got errno code 0, expected 2, 70

#   Failed test 'regular abs_path result on non-existent directory'
#   at t/cwd_enoent.t line 45.
#          got: '/tmp/TecsIaSgYF/testdir'
#     expected: undef

#   Failed test 'regular abs_path errno on non-existent directory'
#   at t/cwd_enoent.t line 46.
# Got errno code 0, expected 2, 70
# Looks like you failed 4 tests of 8.
../dist/PathTools/t/cwd_enoent.t .. Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/8 subtests

Test Summary Report
-------------------
../dist/PathTools/t/cwd_enoent.t (Wstat: 1024 Tests: 8 Failed: 4)
  Failed tests:  1-4
  Non-zero exit status: 4
Files=1, Tests=8,  0 wallclock secs ( 0.00 usr  0.00 sys +  0.05 cusr  0.01 csys =  0.06 CPU)
Result: FAIL
$ uname -a
DragonFly  5.8-RELEASE DragonFly v5.8.3-RELEASE #10: Thu Sep 24 19:19:45 EDT 2020     [email protected]:/usr/obj/home/justin/release/5_8/sys/X86_64_GENERIC  x86_64

The test passes with the skip in place.

Carlos started smokng dragonfly at some point, which is showing other errors, which I'm following up.

Unfortunately getting a dragonfly bug reporting account isn't a simple web sign-up :-(

[xenu]

Carlos started smokng dragonfly at some point, which is showing other errors, which I'm following up.

I think those failures are filesystem-related. On my UFS VM tests are 100% passing, so it's probably due to Carlos using HAMMER1 or HAMMER2.

[tonycoz]

https://bugs.dragonflybsd.org/projects/dragonfly/repository/2/revisions/d6853f97ded3315b0aafef3d9ab100ea36728373/diff

[jkeenan]

To the extent that we are getting smoke-test results from Dragonfly BSD, they are running green. So I believe this ticket is closable. Anyone disagree?

Thank you very much. Jim Keenan

[tonycoz]

I'll PR some checks to only skip on the broken releases

[tonycoz]

There hasn't been a release number bump yet, so we can't differentiate between the fixed and unfixed versions

[jkeenan]

There hasn't been a release number bump yet, so we can't differentiate between the fixed and unfixed versions

@tonycoz, has there been a release such that this is now closable?

[tonycoz]

yes, I'll check the for the release it ended up in and update the test

[iabyn]

That fix is producing a warning on OSes that don't have exactly two numeric components. It's fixed it up with v5.37.2-10-gf9757a510d

[atoomic]

The fixup in blead is provided by f9757a510d28a063aaf6e6503efaeb09604b2c96

[jkeenan]

That fix is producing a warning on OSes that don't have exactly two numeric components. It's fixed it up with v5.37.2-10-gf9757a510d

Would it be possible to provide URLs to smoke-test reports that (i) show the warning and then (ii) show that the warning is no longer being generated?

[tonycoz]

Does this still need to be open?

[jkeenan]

Does this still need to be open?

We haven't heard anything from the OP warranting keeping the ticket open, so I'm closing it now. Thanks.