In addition to the mailserver on request@pari.math.u-bordeaux.fr
which allows the retrieval of Bug data and documentation by email,
there is another server on control@pari.math.u-bordeaux.fr which
also allows Bug reports to be manipulated in various ways.
The control server works just like the request server, except that it has some additional commands; in fact, it's the same program. The two addresses are only separated to avoid users making mistakes and causing problems while merely trying to request information.
Please see the
introduction to the request
server available on the World Wide Web, in the file
bug-log-mailserver.txt, or by sending
help to either mailserver, for details of the basics of
operating the mailservers and the common commands available when
mailing either address.
The reference card for the
mailservers is available via the WWW, in
bug-mailserver-refcard.txt or by email using the
refcard command.
reassign bugnumber package
[ version ]
If you supply a version, the Bug tracking system will note that the Bug affects that version of the newly-assigned package.
reopen bugnumber
[ originator-address | = | ! ]
By default, or if you specify =, the original submitter is
still as the originator of the report, so that they will get the ack
when it is closed again.
If you supply an originator-address the originator will be
set to the address you supply. If you wish to become the new
originator of the reopened report you can use the !
shorthand or specify your own email address.
It is usually a good idea to tell the person who is about to be recorded as the originator that you're reopening the report, so that they will know to expect the ack which they'll get when it is closed again.
If the Bug is not closed then reopen won't do anything, not even
change the originator. To change the originator of an open Bug report,
use the submitter command; note that this will inform the
original submitter of the change.
If the Bug was recorded as being closed in a particular version of a
package but recurred in a later version, it is better to use the
found command instead.
found bugnumber [ version ]
The Bug tracking system uses this information, in conjunction with fixed versions recorded when closing bugs, to display lists of bugs open in various versions of each package. It considers a Bug to be open when it has no fixed version, or when it has been found more recently than it has been fixed.
If no version is given, then the list of fixed versions for
the Bug is cleared. This is identical to the behaviour of
reopen.
This command will only cause a bug to be marked as not done if no
version is specified, or if the version being marked found
is equal to the version which was last marked fixed. (If
you are certain that you want the bug marked as not done,
use reopen in conjunction with found.
This command was introduced in preference to reopen
because it was difficult to add a version to that command's
syntax without suffering ambiguity.
notfound bugnumber version
This differs from closing the Bug at that version in that the Bug is not listed as fixed in that version either; no information about that version will be known. It is intended for fixing mistakes in the record of when a Bug was found.
submitter bugnumber
originator-address | !
If you wish to become the new originator of the report you can use
the ! shorthand or specify your own email address.
While the reopen command changes the originator of other
bugs merged with the one being reopened, submitter does not
affect merged bugs.
forwarded bugnumber address
notforwarded bugnumber
retitle bugnumber new-title
Subject mail header from the original report).
Unlike most of the other Bug-manipulation commands when used on one of a set of merged reports this will change the title of only the individual Bug requested, and not all those with which it is merged.
severity bugnumber severity
For their meanings please consult the general developers' documentation for the Bug system.
clone bugnumber NewID [ new IDs ... ]
Example usage:
clone 12345 -1 -2
reassign -1 foo
retitle -1 foo: foo sucks
reassign -2 bar
retitle -2 bar: bar sucks when used with foo
severity -2 wishlist
clone 123456 -3
reassign -3 foo
retitle -3 foo: foo sucks
merge -1 -3
merge bugnumber bugnumber ...
Before bugs can be merged they must be in exactly the same state:
either all open or all closed, with the same forwarded-to upstream
author address or all not marked as forwarded, all assigned to the
same package or package(s) (an exact string comparison is done on the
package to which the Bug is assigned), and all of the same severity.
If they don't start out in the same state you should use
reassign, reopen and so forth to make sure
that they are before using merge. Titles are not required
to match, and will not be affected by the merge.
If any of the bugs listed in a merge command is already
merged with another Bug then all the reports merged with any of the
ones listed will all be merged together. Merger is like equality: it
is reflexive, transitive and symmetric.
Merging reports causes a note to appear on each report's logs; on the WWW pages this includes links to the other bugs.
Merged reports are all expired simultaneously, and only when all of the reports each separately meet the criteria for expiry.
forcemerge bugnumber bugnumber ...
unmerge bugnumber
If many Bug reports are merged and you wish to split them into two separate groups of merged reports you must unmerge each report in one of the new groups separately and then merge them into the required new group.
You can only unmerge one report with each unmerge
command; if you want to disconnect more than one Bug simply include
several unmerge commands in your message.
tags bugnumber [ + | - | = ] tag [ tag ... ]
+ means to add each given tag, -
means to remove each given tag, and = means to
ignore the current tags and set them afresh to the list provided. The
default action is adding.
Example usage:
# same as 'tags 123456 + patch'
tags 123456 patch
# same as 'tags 123456 + help security'
tags 123456 help security
# add 'fixed' and 'pending' tags
tags 123456 + fixed pending
# remove 'unreproducible' tag
tags 123456 - unreproducible
# set tags to exactly 'moreinfo' and 'unreproducible'
tags 123456 = moreinfo unreproducible
Available tags currently include patch, wontfix,
moreinfo, unreproducible, help,
pending, fixed, security,
upstream, potato, woody,
sarge,
sid and experimental.
For their meanings please consult the general developers' documentation for the Bug system.
block|unblock bugnumber by|with bug [ bug ... ]
unblock
to unblock a bug.
Example usage:
# indicates that 7890 cannot be fixed until 123456 is fixed
block 7890 by 123456
# indicates that 7890 can be fixed before 123456 after all
unblock 7890 by 123456
close bugnumber [ fixed-version ]
(deprecated)
A notification is sent to the user who reported the Bug, but (in
contrast to mailing bugnumber-done) the
text of the mail which caused the Bug to be closed is not
included in that notification. The maintainer who closes a report
should ensure, probably by sending a separate message, that the user
who reported the Bug knows why it is being closed.
The use of this command is therefore deprecated.
If you supply a fixed-version, the Bug tracking system will note that the Bug was fixed in that version of the package.
package [ packagename ... ]
Example usage:
package foo
reassign 123456 bar 1.0-1
package bar
retitle 123456 bar: bar sucks
severity 123456 normal
package
severity 234567 wishlist
owner bugnumber address | !
If you wish to become the owner of the Bug yourself, you can use the
! shorthand or specify your own email address.
noowner bugnumber
archive bugnumber
unarchive bugnumber
#...
# must be at the start of the line.
The text of comments will be included in the acknowledgement sent to the
sender and to affected maintainers, so you can use this to document the
reasons for your commands.
quit
stop
thank
thanks
thankyou
thank you
--
Other pages:
Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.