Closed
Bug 200472
Opened 21 years ago
Closed 21 years ago
Using an array as a reference is deprecated at Date/Format.pm
Categories
(Bugzilla :: Installation & Upgrading, defect)
Bugzilla
Installation & Upgrading
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: andreas, Assigned: justdave)
Details
Attachments
(1 file)
532 bytes,
patch
|
jacob
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.3b) Gecko/20030317 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.3b) Gecko/20030317 My apache error log files are filled with entries like these: [Thu Apr 03 10:37:34 2003] [error] [client 200.221.3.123] Using an array as a reference is deprecated at [Thu Apr 03 10:37:34 2003] [error] [client 200.221.3.123] /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm line 88 (#1) [Thu Apr 03 10:37:34 2003] [error] [client 200.221.3.123] (D deprecated) You tried to use an array as a reference, as in [Thu Apr 03 10:37:34 2003] [error] [client 200.221.3.123] < @foo-[23] >> or < @$ref-[99] >>. Versions of perl <= 5.6.1 used to [Thu Apr 03 10:37:34 2003] [error] [client 200.221.3.123] allow this syntax, but shouldn't have. It is now deprecated, and will be [Thu Apr 03 10:37:34 2003] [error] [client 200.221.3.123] removed in a future version. This is an installation with: apache-2.0.45 perl-5.8.0 bugzilla-2.16.2 Reproducible: Always Steps to Reproduce: 1. Just keep wathing apache's error_log file 2. Use bugzilla to query a bug or enter a new bug Actual Results: Error log filled with that entry. Expected Results: Bugzilla should not use a deprecated perl feature.
Assignee | ||
Comment 1•21 years ago
|
||
uhhh... is Date::Parse broken or are we feeding it something bad?
Comment 2•21 years ago
|
||
I don't see this. What Date::Parse version do you have?
Reporter | ||
Comment 3•21 years ago
|
||
It's perl-timedate-1.10 .
Assignee | ||
Comment 4•21 years ago
|
||
current version is 1.14. Try upgrading it and see if the problem goes away. If so, we probably need to have checksetup require a newer version.
Reporter | ||
Comment 5•21 years ago
|
||
I just upgraded to version 1.14 and this problem did go away. Don't know if it would have worked with a previous version, but anyway, a version check seems to be needed. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 6•21 years ago
|
||
It isn't fixed until we check it in...
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Assignee | ||
Comment 7•21 years ago
|
||
moving to proper component and confirming
Assignee: justdave → zach
Status: UNCONFIRMED → NEW
Component: Bugzilla-General → Installation & Upgrading
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Assignee | ||
Comment 8•21 years ago
|
||
/src/GBARR/TimeDate-1.11/ChangeLog: Change 690 on 2001/12/28 by <gbarr@pobox.com> (Graham Barr) Date::Format - Fix array dereference syntax typo So version 1.11 had this fixed, and it thus the minimum version we need to require. The Date::Format within TimeDate-1.11 is version 2.21.
Assignee | ||
Comment 9•21 years ago
|
||
OK, we're not actually testing for Date::Format in checksetup.pl. We're only testing for Date::Parse, assuming that since it's part of the same distribution package that if you have one you'd automatically have the other. The Date::Parse that's included in TimeDate-1.11 is 2.22 (and the one in TimeDate-1.10 is 2.20). Would it be safe to just look for Date::Parse 2.22 you think? (instead of Date::Parse (any) that we look for currently?) Or would it be better to add an explicit check for Date::Format 2.21?
Comment 10•21 years ago
|
||
Maybe replace Date::Parse (any) with Date::Format (1.22); otherwise, we might wonder why it is that we need the specific min version of Date::Parse someday in the future...
Assignee | ||
Comment 11•21 years ago
|
||
changes version check from Date::Parse (any) to Date::Format (2.21).
Assignee | ||
Updated•21 years ago
|
Attachment #119939 -
Flags: review?(jake)
Updated•21 years ago
|
Attachment #119939 -
Flags: review?(jake) → review+
Assignee | ||
Updated•21 years ago
|
Flags: approval+
Assignee | ||
Comment 13•21 years ago
|
||
Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.226; previous revision: 1.225 done
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Comment 14•21 years ago
|
||
Umm, this checks for version 1.21, not 2.21...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 15•21 years ago
|
||
Doh. Shame on me and Jake. :) Good catch. Fixed. Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.227; previous revision: 1.226 done
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Comment 16•21 years ago
|
||
For some reason I seemed to be pretty convinced that the 1.21 was correct... I just looked at my local doc changes and I had typed 1.21 there, too. Checked in the XML update w/the correct version information.
Assignee | ||
Updated•21 years ago
|
Target Milestone: --- → Bugzilla 2.18
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•