Closed Bug 343566 Opened 19 years ago Closed 19 years ago

Runtests test 004template.t fails on some systems with a complaint about RELATIVE

Categories

(Bugzilla :: Testing Suite, defect)

2.23
defect
Not set
major

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: bugreport, Assigned: LpSolit)

Details

Attachments

(1 file)

This seems to be a relative of bug 329295, but addint "." or "./" to PATH does not help. On some systems, $file (in t/004) has a leading ./ that causes trouble. Filtering that out seems to help the situation.
I think the problem comes from find_templates() in t/Support/Templates.pm: my $local_dir = File::Spec->abs2rel($File::Find::dir, $File::Find::topdir); On my system, $local_dir is empty if $File::Find::dir and $File::Find::topdir are identical (in the case of Bugzilla, $File::Find::topdir = 'template/en/default'). But joel told me on IRC that his system returns "." in this case: <LpSolit> joel: what is $local_dir when you are in default/ ? <LpSolit> is it empty or set to "."? <joel> It is "." in the top level <joel> the rest have the ./ pruned off He also told me that he is using File::Spec 3.17, while I'm using File::Spec 3.05. And I think this explains the problem, see http://search.cpan.org/src/KWILLIAMS/PathTools-3.18/Changes "3.13 Tue Nov 15 23:50:37 CST 2005 - abs2rel() used to return the empty string when its two arguments were identical, which made no sense. Now it returns curdir()." And that's precisely the problem, because curdir() returns "."! So I think that 004template.t fails on all systems running File::Spec 3.13 or higher. We have to hack find_templates() to remove this leading ".".
Assignee: zach → LpSolit
OS: Linux → All
Hardware: PC → All
Target Milestone: Bugzilla 2.24 → Bugzilla 2.18
Attached patch patch, v1Splinter Review
Attachment #228054 - Flags: review?(bugreport)
Attachment #228054 - Flags: review?(bugreport) → review+
Status: NEW → ASSIGNED
Flags: approval?
Flags: approval2.22?
Flags: approval2.20?
Flags: approval2.18?
Confirmed this on 2.18, 2.20, 2.22, and tip
How many installations run tests, and how often do they do so? Seems like the ones that do (if any) are more likely to be running later releases anyway. This doesn't seem significant enough to stick into very old releases.
Flags: approval?
Flags: approval2.22?
Flags: approval2.22+
Flags: approval2.20?
Flags: approval2.20-
Flags: approval2.18?
Flags: approval2.18-
Flags: approval+
tinderboxes on landfill are burning due to this bug. This won't affect Bugzilla itself anyway. We definitely need this patch.
Flags: approval2.20?
Flags: approval2.20-
Flags: approval2.18?
Flags: approval2.18-
myk, read my previous comment.
Ok, this makes sense to fix build bustage on the older branches.
Flags: approval2.20?
Flags: approval2.20+
Flags: approval2.18?
Flags: approval2.18+
tip: Checking in t/Support/Templates.pm; /cvsroot/mozilla/webtools/bugzilla/t/Support/Templates.pm,v <-- Templates.pm new revision: 1.15; previous revision: 1.14 done 2.22: Checking in t/Support/Templates.pm; /cvsroot/mozilla/webtools/bugzilla/t/Support/Templates.pm,v <-- Templates.pm new revision: 1.14.2.1; previous revision: 1.14 done 2.20.2: Checking in t/Support/Templates.pm; /cvsroot/mozilla/webtools/bugzilla/t/Support/Templates.pm,v <-- Templates.pm new revision: 1.13.10.2; previous revision: 1.13.10.1 done 2.18.5: Checking in t/Support/Templates.pm; /cvsroot/mozilla/webtools/bugzilla/t/Support/Templates.pm,v <-- Templates.pm new revision: 1.13.2.1; previous revision: 1.13 done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Summary: Runtests test 004 fails on some systems with a complaint about RELATIVE → Runtests test 004template.t fails on some systems with a complaint about RELATIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: