289742 - No value for param user_verify_class (try running checksetup.pl again) at Bugzilla/Config.pm line 162.

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Colin Ogilvie [:cso]]

A CVS checkout as of about 10 minutes ago (2245 GMT on 9th April) will not run
through checksetup.pl. It keeps giving the errorr:

Precompiling templates ...
No value for param user_verify_class (try running checksetup.pl again) at
Bugzilla/Config.pm line 162.
BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 45.
Compilation failed in require at Bugzilla/User.pm line 44.
BEGIN failed--compilation aborted at Bugzilla/User.pm line 44.
Compilation failed in require at Bugzilla/Template.pm line 35.
BEGIN failed--compilation aborted at Bugzilla/Template.pm line 35.
Compilation failed in require at ./checksetup.pl line 1194.


This is occuring on landfill:
Steps:

1) cvs checkout -d bz-test Bugzilla
2) cd bz-test
3) ./checksetup.pl
4) vi localconfig and set it up.
5) ./checksetup.pl

Expected result: 

DB to be created

Actuall Result:

The above error message and checksetup dying.

Comment 1

[Dave Miller [:justdave]]

Something tells me there's a |use Bugzilla::Config;| that snuck into checksetup.pl.

Should only be a "require" and it needs to be after the section where the params
are created/updated.

Comment 2

[Colin Ogilvie [:cso]]

The first line that gives problems in checksetup.pl is the |require
Bugzilla::Template;| line for Bug 288527.

Adding Max to CC to see if he can provide any insight.

Comment 3

[Max Kanat-Alexander]

This, of course, explains why we didn't do the "use Bugzilla::Template" before,
in checksetup.pl. Here's a line from Bugzilla::Template:

use Bugzilla::Config qw(:DEFAULT $templatedir $datadir);

I believe it should be possible to move template compilation to happen after the
parameters are created. It should be a very straightforward move.

Comment 4

[Max Kanat-Alexander]

By the way, we should also change Bugzilla::Config to not try to read in the
parameters until they're actually needed, I think.

In general, having initialization code outside of a sub is really a bad idea,
because we continuously run into things like this.

That should be a different bug, but I'm just noting it here.

Comment 5

[:glob ✱]

Attachment: patch v1

move template compilation after param creation.

Comment 6

[Gervase Markham [:gerv]]

Comment on attachment 180451 [details] [diff] [review]
patch v1

r=gerv - looks sensible, and fixes the problem for me.

One thing, though: is there any chance you could attach patches with Unix
line-endings? I would expect Linux's version of "patch" to deal with either but
sadly it doesn't, and rejects all the chunks. I have to run dos2unix over every
one. I know most Windows copies of "patch" accept either.

Gerv

Comment 7

[Dave Miller [:justdave]]

Hmm, the patch program on both Mac OS X and on Fedora ore 1 seems to deal with
it fine.  I get a "(Stripping trailing CRs from patch.)" for each hunk of the
patch as the patch applies, but it works.

Comment 8

[Gervase Markham [:gerv]]

I have patch 2.5.9. Which do you have?

Gerv

Comment 9

[Frédéric Buclin]

Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.391; previous revision: 1.390
done

Comment 10

[:glob ✱]

gerv - you're the first to raise issues with the line endings, and patch should
deal with it correctly -- patch v2.5.9 on linux strips the CRs for me.

i'll post all further patches with unix line endings.

Comment 11

[Gervase Markham [:gerv]]

glob: then I'm stumped. Thanks for being so accommodating :-)

Gerv