patches for Gnats version 3.2
- Date: Sun, 4 Dec 1994 16:13:16 +0100 (MET), noc@localhost, fr-domain-admin@localhost
Dear Benoit,
sorry for the delay - you asked for the patches I made for Gnats version
3.2. Here they are (in text form - I did not use any patch software):
* It soon becomes obvious that Gnats does not allow other users than Gnats
itself to edit TTs - as another user you may call program "edit-pr" but
the changes are not stored. The reason for this is the permission on
the TT files (rw-r--r--). For us it is important that also other users
within the user group of our NOC may edit TTs. To achieve this we included
user gnats in the NOC user group and made two small changes in the source
code of two elements of Gnats:
- pr-edit.c
line 165: change command "umask (022)" to "umask (002)"
- queue-pr.c
line 357: change command "umask (022)" to "umask (002)"
This leads to file permissions (rw-rw-r--) for all Gnats TTs. It is also
necessary to adapt the permissions of the Gnats directories once to allow
access to the programs or data inside.
* When running "edit-pr" and changing the state or responsible person in the
TT, not only the person doing the change should receive the according
notification but the submitter, too. This is done wrong in the original
source code of "edit-pr". The reason is that in lines 234-236 the condition
is tested incorrectly. Instead of
if [ -z "$to_subm" ]; then mail_to="${reply_to}, ${mail_to}" ; fi
if [ -z "$to_old" ] ; then mail_to="${mail_to}, `$PR_ADDR ${old_resp}`" ; fi
if [ -z "$to_new" ] ; then mail_to="${mail_to}, `$PR_ADDR ${new_resp}`" ; fi
these three lines must read
if [ ! -z "$to_subm" ]; ...
if [ ! -z "$to_old" ] ; ...
if [ ! -z "$to_new" ] ; ...
^
With this change "edit-pr" works as described in the documentation.
* In case you run program "edit-pr" for a TT but you do not make any changes
in it, Gnats does not remove two temporary files in directory /tmp. To get
these removed add the lines
rm $new.old
rm $new
following line 148 in the source code.
* On some error conditions, "edit-pr" prints an error message including the
usage information of "edit-pr". To get a correct printout of the usage
message change all lines reading
echo $usage
to
echo "$usage"
* When the state or responsible person in a TT is changed using program
"edit-pr", the person doing the change is asked what the reason for this
change is. The input is read directly from the terminal and written to
a temporary file using the command
cat >> $change_msg
This offers only very poor editing capabilities. Therefore we replaced the
"cat"-commands by the two lines
read bla
$VISUAL $change_msg
This leads to a small change on the behaviour of "edit-pr". After the line
"Why did the state/responsible person change?" the user of "edit-pr" must
hit the <Return>-key to enter the editor (which is given in variable $VISUAL
set at the beginning by "edit-pr"). After having finished editing (do NOT
change the lines "State-Changed-..." in the file!! Just append your text)
the user stores the text and leaves the editor. Program "edit-pr" then pro-
ceeds as before. It is also advisable to change the lines
echo "Why did the ... change? (Ctrl-D to end)'
to something like
echo "Why did the ... change? (hit <Return> to enter editor)'
in "edit-pr" to make the alteration in the behaviour and usage of "edit-pr"
obvious to the user.
* In "send-pr" a template of the TT form is generated which must be filled in
by the submitter. In the comments at the top of the form all error catego-
ries are listed. It is not clear why in this listing category "pending" is
also included (pending TTs only occur at the Gnats site when an invalid
category was found in a TT). At the Gnats site you may remove this "pending"
category from the display by changing line 205 from
CATEGORIES=`grep -v '^#' $DATADIR/gnats/$GNATS_SITE | sort`
to
CATEGORIES=`grep -v '^#' $DATADIR/gnats/$GNATS_SITE |
grep -v "pending" | sort`
For a distribution of "send-pr" to the submitters the easiest way to handle
the problem is to remove the "pending" category from the categories file.
This MUST NOT be done at the Gnats site itself!
* Be careful to remove all remnants of earlier Gnats installations. On
rare occasions, "configure" from a newer version confuses old and new
data (look out for older versions of the file $GNATSROOT/gnats-adm/config
and verify its contents after the installation of Gnats).
* We do not have the complete GNU info package at our site. Therefore
we ran into a problem with the "Makefile" produced by "configure". It
always tries to make an info-file.
make all
works without adapting the Makefile but in order to
make install
I had to put a comment on line 236 of the Makefile. However, you should
note that the length of the Makefile depends on what came out of your
"configure"-run. Therefore, try to find lines
send-pr.info: send-pr.texi version.texi fields.texi s-usage.texi categ.texi
$(MAKEINFO) -I $(srcdir) -o send-pr.info $(srcdir)/send-pr.texi
I put a comment on the second line.
* Be sure to follow the post installation instructions in chapter A of
the documentation. If you miss part of it (setting up certain files
in $GNATS_HOME/gnats-adm for example or aliases) gnats is likely not
to work. Gnats also needs an alias feeding mail into a pipe. If you
have certain security constraints on your site it may be necessary
to allow the pipe for the gnats-programs "queue-pr" and "mail-query"
on your gnats server.
* Program "mkdist" is simply not usable. It should create distribution
editions of program "edit-pr" but does not do it correctly:
- the distribution is tailored according to the configuration necessary to
run "send-pr" on the Gnats site computer - however, it should not be
tailored at all to adapt it to the computer of the user at her/his site
(then a "configure" script should also be included but is not)
- the "Makefile" generated in the distribution has several bugs
Since these bugs are not tolarable, we at DFN-NOC decided to build a
"mkdist" program which fits our specific needs. Unfortunately, it has become
that much specific that it is not desirable to show it here.
* Finally, either there is an error in the documentation or it is a bug in
the code (we decided that it is a documenation error making things much
easier ;-) If someone wants to send supplemental information for a TT in
Gnats this can be done by sending a mail without any specific form to
the Gnats trouble address choosing a very specific contents of the "subject"
field of the mail. Documentation says that the "subject" field should read
Re: PR <TT#>: <original subject>
where <TT#> and <original subject> must be replaced by the respective
value/contents. This is wrong! The string "PR" must not be part of the
"subject" field. Instead is must read
Re: <TT#>: <original subject>
Then everything works fine. (btw: this is exactly the "subject" you find in
the notification mail of Gnats that your TT has safely arrived).
That's about all - not much but it needs some time to find it all. Actually,
there are only two or three bugs (the other changes were made to tailor Gnats
to our needs).
Best regards
Joachim
_____________________________________________________________________________
For any problem reports regarding DFN-IP, please send your e-mail to
>>>>>> noc@localhost <<<<<<
If you have any doubt about the proper delivery of your e-mail
please contact the DFN-NOC by other means (telephone, FAX)
DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart
FAX +711 678 7626 (business hours) Allmandring 30
Bettina Kauth +711 685 5810 kauth@localhost D-70550 Stuttgart
Joachim Schmitz +711 685 5576 schmitz@localhost FRG (Germany)
_____________________________________________________________________________