debbugs 2.4.1.1ubuntu1 / etc / debbugs / html / server-control.html.in

This file is indexed.

/etc/debbugs/html/server-control.html.in is in debbugs 2.4.1.1ubuntu1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below. 

  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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
$gControlHtml = <<HTML_END
<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
  <title>$gProject $gBug system - control mail server commands</title>
  <link rev="made" href="mailto:$gMaintainerEmail">
</head>
<body>

<h1>Introduction to the $gBug control and manipulation mailserver</h1>

<p>In addition to the mailserver on <code>request\@$gEmailDomain</code>
which allows the retrieval of $gBug data and documentation by email,
there is another server on <code>control\@$gEmailDomain</code> which
also allows $gBug reports to be manipulated in various ways.</p>

<p>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.</p>

<p>Please see the
<a href="server-request.html#introduction">introduction to the request
server</a> available on the World Wide Web, in the file
<code>bug-log-mailserver.txt</code>, or by sending
<code>help</code> to either mailserver, for details of the basics of
operating the mailservers and the common commands available when
mailing either address.</p>

<p>The <a href="server-refcard.html">reference card</a> for the
mailservers is available via the WWW, in
<code>bug-mailserver-refcard.txt</code> or by email using the
<code>refcard</code> command.</p>

<h1>Commands available at the control mailserver</h1>

<dl>

<dt><code>reassign</code> <var>bugnumber</var> <var>package</var>

  <dd>Records that $gBug #<var>${gBug}number</var> is a $gBug in <var>package</var>.
  This can be used to set the package if the user forgot the
  pseudo-header, or to change an earlier assignment.  No notifications
  are sent to anyone (other than the usual information in the processing
  transcript).

<dt><code>reopen</code> <var>bugnumber</var>
 [ <var>originator-address</var> | <code>=</code> | <code>!</code> ]

  <dd>Reopens #<var>bugnumber</var> if it is closed.

  <p>By default, or if you specify <code>=</code>, the original submitter is
  still as the originator of the report, so that they will get the ack
  when it is closed again.

  <p>If you supply an <var>originator-address</var> 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 <code>!</code>
  shorthand or specify your own email address.

  <p>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.

  <p>If the $gBug is not closed then reopen won't do anything, not even
  change the originator.  To change the originator of an open $gBug report,
  use the <code>submitter</code> command; note that this will inform the
  original submitter of the change.

<dt><code>submitter</code> <var>bugnumber</var>
<var>originator-address</var> | <code>!</code>

  <dd>Changes the originator of #<var>bugnumber</var> to
  <var>originator-address</var>.

  <p>If you wish to become the new originator of the report you can use
  the <code>!</code> shorthand or specify your own email address.</p>

  <p>While the <code>reopen</code> command changes the originator of other
  bugs merged with the one being reopened, <code>submitter</code> does not
  affect merged bugs.</p>

<dt><code>forwarded</code> <var>bugnumber</var> <var>address</var>

  <dd>Notes that <var>bugnumber</var> has been forwarded to the upstream
  maintainer at <var>address</var>.  This does not actually forward the
  report.  This can be used to change an existing incorrect forwarded-to
  address, or to record a new one for a $gBug that wasn't previously noted
  as having been forwarded.

<dt><code>notforwarded</code> <var>bugnumber</var>

  <dd>Forgets any idea that <var>bugnumber</var> has been forwarded to any
  upstream maintainer.  If the $gBug was not recorded as having been
  forwarded then this will do nothing.

<dt><code>retitle</code> <var>bugnumber</var> <var>new-title</var>

  <dd>Changes the title of a $gBug report to that specified (the default is
  the <code>Subject</code> mail header from the original report).

  <p>Unlike most of the other $gBug-manipulation commands when used on one of
  a set of merged reports this will change the title of only the
  individual $gBug requested, and not all those with which it is merged.

<dt><code>severity</code> <var>bugnumber</var> <var>severity</var>

  <dd>Set the severity level for $gBug report #<var>bugnumber</var> to
  <var>severity</var>.  No notification is sent to the user who reported
  the $gBug.

  <p>For <a href="Developer.html#severities">their meanings</a> please
  consult the general developers' documentation for the $gBug system.

<dt><code>clone</code> <var>bugnumber</var> [ <var>new IDs</var> ]

  <dd>The clone control command allows you to duplicate a $gBug report. It is
  useful in the case where a single report actually indicates that multiple
  distinct $gBugs have occurred. "<var>New IDs</var>" are negative numbers,
  separated by spaces, which may be used in subsequent control commands to
  refer to the newly duplicated $gBugs. A new report is generated for each
  new ID.

  <p>Example usage:</p>

  <pre>
        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
  </pre>

<dt><code>merge</code> <var>bugnumber</var> <var>bugnumber</var> ...

  <dd>Merges two or more $gBug reports.  When reports are merged opening,
  closing, marking or unmarking as forwarded and reassigning any of the
  $gBugs to a new package will have an identical effect on all of the
  merged reports.

  <p>Before $gBugs 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 $gBug is assigned), and all of the same severity.
  If they don't start out in the same state you should use
  <code>reassign</code>, <code>reopen</code> and so forth to make sure
  that they are before using <code>merge</code>.

  <p>If any of the $gBugs listed in a <code>merge</code> command is already
  merged with another $gBug 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.

  <p>Merging reports causes a note to appear on each report's logs; on the
  WWW pages this includes links to the other $gBugs.

  <p>Merged reports are all expired simultaneously, and only when all of
  the reports each separately meet the criteria for expiry.

<dt><code>unmerge</code> <var>bugnumber</var>

  <dd>Disconnects a $gBug report from any other reports with which it may have
  been merged.  If the report listed is merged with several others then
  they are all left merged with each other; only their associations with
  the $gBug explicitly named are removed.

  <p>If many $gBug 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.

  <p>You can only unmerge one report with each <code>unmerge</code>
  command; if you want to disconnect more than one $gBug simply include
  several <code>unmerge</code> commands in your message.

<dt><code>tags</code> <var>bugnumber</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var>

  <dd>Sets a particular tag for the $gBug report #<var>bugnumber</var> to
  <var>tag</var>. No notification is sent to the user who reported the $gBug.
  <code>+</code> means adding, <code>-</code> means subtracting, and
  <code>=</code> means ignoring the current tags and setting them afresh.
  The default action is adding.

  <p>Available tags currently include <code>patch</code>, <code>wontfix</code>,
  <code>moreinfo</code>, <code>unreproducible</code>, <code>help</code>,
  <code>pending</code>, <code>fixed</code>, <code>security</code>,
  <code>upstream</code>, <code>potato</code>, <code>woody</code>,
  <code>sarge</code>,
  <code>sid</code> and <code>experimental</code>.

  <p>For <a href="Developer.html#tags">their meanings</a> please consult the
  general developers' documentation for the $gBug system.

<dt><code>close</code> <var>bugnumber</var>

  <dd>Close $gBug report #<var>bugnumber</var>.

  <p>A notification is sent to the user who reported the $gBug, but (in
  contrast to mailing <var>bugnumber</var><code>-done@$gEmailDomain</code>) the
  text of the mail which caused the $gBug to be closed is <strong>not</strong>
  included in that notification.  The maintainer who closes a report
  should ensure, probably by sending a separate message, that the user
  who reported the $gBug knows why it is being closed.
  The use of this command is therefore deprecated.

<dt><code>quit</code>
<dt><code>stop</code>
<dt><code>thank</code>...
<dt><code>--</code>...

  <dd>Tells the control server to stop processing the message; the remainder
      of the message can include explanations, signatures or anything else,
      none of it will be detected by the control server.

<dt><code>#</code>...

  <dd>One-line comment. The <code>#</code> must be at the start of the line.

</dl>

<hr>

<p>Other pages:
<ul>
  <li><a href="./">$gBug tracking system main contents page.</a>
  <li><a href="Reporting.html">Instructions for reporting $gBugs.</a>
  <li><a href="Access.html">Accessing the $gBug tracking logs other than by WWW.</a>
  <li><a href="Developer.html">Developers' information regarding the $gBug processing system.</a>
  <li><a href="server-request.html">Fundamentals of the mailserver and commands for retrieving $gBugs.</a>
  <li><a href="server-refcard.html">Mailservers' reference card.</a>
  <li><a href="db/ix/full.html">Full list of outstanding and recent $gBug reports.</a>
  <li><a href="db/ix/packages.html">Packages with $gBug reports.</a>
  <li><a href="db/ix/maintainers.html">Maintainers of packages with $gBug reports.</a>
$gHTMLOtherPageList
</ul>

$gHTMLTail

HTML_END

APT Browse - Built by Thomas Orozco.