1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
This is Bugzilla. See <http://www.mozilla.org/bugs/>.
==========
DISCLAIMER
==========
This is not very well packaged code. It's not packaged at all. Don't
come here expecting something you plop in a directory, twiddle a few
things, and you're off and using it. Work has to be done to get
there. We'd like to get there, but it wasn't clear when that would
be, and so we decided to let people see it first.
============
INSTALLATION
============
(This section stolen heavily from the Bonsai INSTALL document. It's
also probably incomplete. "We're accepting patches", especially to
this document!)
First, you need some other things:
1) MySQL database server.
2) Perl5.004 or greater, including MySQL support, and modules
Date::Format and Chart::Base available from your nearest
CPAN server. See http://www.perl.com/CPAN.
ftp://ftp.cpan.org/pub/CPAN/authors/id/GBARR/TimeDate-1.08.tar.gz
ftp://ftp.cpan.org/pub/CPAN/authors/id/DBONNER/Chart-0.99.tar.gz
ftp://ftp.cpan.org/pub/CPAN/authors/id/LDS/GD-1.18.tar.gz
3) Some kind of HTTP server so you could use CGI scripts
Earlier versions of Bugzilla required TCL. THIS IS NO LONGER TRUE.
All dependencies on TCL have been removed.
1.1 Getting and setting up MySQL database
Visit MySQL homepage at http://www.tcx.se and grab the latest
stable binary release of the server. Sure, you can get sources and
compile them yourself, but binaries are the easiest and the fastest
way to get it up and running. Follow instructions found in
manual. There is a section about installing binary-only
distributions.
You should create database "bugs". It may be a good idea to make it
writable by all users on your machine and change access level
later. This would save you a lot of time trying to guess whether it's
permissions or a mistake in the script that make things fail.
1.2 HTTP server
You have a freedom of choice here - Apache, Netscape or any other
server on UNIX would do. The only thing - to make configuration easier
you'd better run HTTP daemon on the same machine that you run MySQL
server on. Make sure that you can access 'bugs' database with user
id you're running the daemon with.
globals.pl: $::db = Mysql->Connect("localhost", "bugs", "nobody", "")
In globals.pl, the database connect call uses a mysql account
name "bugs" (third argument to Mysql->Connect) to access the
bugs database. You may have to hack the code to use "nobody"
or whatever your HTTP server is running as.
1.3 Perl
MySQL used to come with a perl module. More recent versions do
not; they count on you grabbing the DBI package from CPAN. So, if you
are installing a new version of MySQL, you will probably also need to
grab the following:
ftp://ftp.cpan.org/pub/CPAN/authors/id/TIMB/DBI-1.06.tar.gz
ftp://ftp.cpan.org/pub/CPAN/authors/id/JWIED/Msql-Mysql-modules-1.2017.tar.gz
For Mysql support, the Msql-Mysql-modules (for 1.2017, at least)
uses DBI, so that will have to be installed first (0.93 or later).
Then, when making the Makefile for the Msql-Mysql modules, you will
be asked which DB to support. Only Mysql is necessary. Also, you
will be asked if you want to install the "MysqlPerl emulation". You
must say yes for Bugzilla to work.
This assumes, of course, that you do not have a version of "MysqlPerl"
already installed.
2. Tweaking the Tools
All scripts look in /usr/bonsaitools/bin for perl. Make
the appropriate links or modify the paths in each script.
Make sure the directory containing the binaries is writable by the
web server. Bugzilla keeps some temporary files here.
Create an empty file in that directory named "comments"; make sure
it is writable by the web server. Also, create empty files named
"nomail" and "mail".
3. Setting up database
First, run mysql, and tell it "create database bugs;".
Now, you should be run all six scripts named make*.sh. This creates the
database tables and populates them a teeny bit.
4. Setting the parameters
At this point, you ought to be able to go and browse some pages. But you'd
like to customize some things.
Create yourself an account. (Try to enter a new bug, and it will
prompt you for your login. Give it your email address, and have it
mail you your password.) Go visit the query page; that ought to force
the creation of the "data/params" file in your installation dir. Edit the
data/params file, and change the line that sets "$::param{'maintainer'}" to
have your email address as the maintainer. Go visit the query page
again; there should now be a link at the bottom that invites you to
edit the parameters. (If you have cookies turned off, you'll have to
go to editparams.cgi manually.)
Tweak the parameters to taste. Be careful.
5. Set up the whining cron job.
It's a good idea to set up a daily cronjob that does
cd <your-installation-dir> ; ./whineatnews.pl
This causes email that gets sent to anyone who has a NEW bug that
hasn't been touched for several days. For more info, see the
whinedays and whinemail parameters.
6. Modifying your running system
Bugzilla optimizes database lookups by storing all relatively static
information in the versioncache file, located in the data/
subdirectory under your installation directory (we said before it
needs to be writable, right?!)
If you make a change to the structural data in your database (the
versions table for example), or to the "constants" encoded in
defparams.pl, you will need to remove the cached content from the data
directory (by doing a "rm data/versioncache"), or your changes won't
show up!
That file gets automatically regenerated whenever it's more than an
hour old, so Bugzilla will eventually notice your changes by itself,
but generally you want it to notice right away, so that you can test
things.
7. Optional: Bug Graphs
Place collectstats.pl in your crontab once/day to take a snapshot
of the number of open, assigned and reopened bugs for every
product. The tool will create a data/mining directory and append
the count to a file named for the product. After at least two points
of data are available, you can view a graph from the Bug Reports page.
|
