diff options
| author | Thomas Lange <lange@debian.org> | 2023-10-06 12:45:37 +0200 |
|---|---|---|
| committer | Thomas Lange <lange@debian.org> | 2023-10-06 12:45:37 +0200 |
| commit | 9f5b551837a8d4c6a8c9346cf4c44755b863a813 (patch) | |
| tree | 0856db540a5d047169c7b6513e04d38306bff237 /greek/Bugs | |
| parent | 794834c196b3285bb39846e22bfab051860258ab (diff) | |
remove a lot of files which are not translations but only copies of the english version
Diffstat (limited to 'greek/Bugs')
| -rw-r--r-- | greek/Bugs/Access.wml | 61 | ||||
| -rw-r--r-- | greek/Bugs/Developer.wml | 471 | ||||
| -rw-r--r-- | greek/Bugs/Reporting.wml | 518 | ||||
| -rw-r--r-- | greek/Bugs/otherpages.inc | 18 | ||||
| -rw-r--r-- | greek/Bugs/pseudo-packages.wml | 25 | ||||
| -rw-r--r-- | greek/Bugs/server-control.wml | 751 | ||||
| -rw-r--r-- | greek/Bugs/server-refcard.wml | 94 | ||||
| -rw-r--r-- | greek/Bugs/server-request.wml | 297 |
8 files changed, 0 insertions, 2235 deletions
diff --git a/greek/Bugs/Access.wml b/greek/Bugs/Access.wml deleted file mode 100644 index 2338be718f5..00000000000 --- a/greek/Bugs/Access.wml +++ /dev/null @@ -1,61 +0,0 @@ -#use wml::debian::template title="Debian BTS — access methods" NOHEADER=yes NOCOPYRIGHT=true -#use wml::debian::translation-check translation="24307c5e15886d4d81e4db3a68318d1824cca824" maintainer="galaxico" - -# the explicit links to https://bugs.debian.org/ without anchors are -# included because of the text version, do not remove them - -<h1>Methods of accessing the bug tracking system logs</h1> - -<h2>Accessing active bug reports</h2> - -<p>Each message received at or sent by the bug processing system is -logged and made available in a number of ways.</p> - -<p>The primary access method is to use the web pages. See the -forms on the <a href="./">main BTS page</a> at -<code>https://bugs.debian.org/</code></p> - -<p>There is a <a href="server-request">mailserver</a> which can send -bug reports as plain text on request. To use it send the word -<code>help</code> as the sole contents of an email to -<code>request@bugs.debian.org</code> (the <code>Subject</code> of the -message is ignored), or read the instructions <a href="server-request">on -the World Wide Web</a> or in the file <code>bug-log-mailserver.txt</code>.</p> - -<h2>Accessing archived bug reports</h2> - -<p>Each closed bug report is archived 28 days after the last message -relating to it is received and filed. This means that it is no longer -possible to access it or change anything about it using the -<code>control</code> and <code>service</code> bots. However, the -reports are still accessible for viewing.</p> - -<p>You can search the bug report archive using the <a href="./">WWW -forms</a> at <code>https://bugs.debian.org/</code>, simply select the -<q>archived bugs</q> option.</p> - -<p>Note that it doesn't contain the oldest closed bug reports, only those -after #40000, approximately.</p> - -<h2>Accessing the raw bug data</h2> - -<p>If you need to get hold of the raw data used by the bug tracking system, -you can mirror it using rsync from bugs-mirror.debian.org. The relevant -modules are bts-spool-db (for the active bug spool), bts-spool-archive (for -bugs that have been closed for a while and thus archived), and -bts-spool-index (for the bug index files).</p> - -<p>As of August 2020, the active spool is about 18GB and the archived -spool is about 105GB. If you only need a sample for testing purposes, please -consider downloading only part of the active spool rather than the whole -thing.</p> - -<p>Please do not rely on *.status files in the bug spools, as they are -obsolete, for compatibility purposes only, and will be removed at some point -in the future. Use the *.summary files instead.</p> - -<hr /> - -#use "otherpages.inc" - -#use "$(ENGLISHDIR)/Bugs/footer.inc" diff --git a/greek/Bugs/Developer.wml b/greek/Bugs/Developer.wml deleted file mode 100644 index 985e63c825d..00000000000 --- a/greek/Bugs/Developer.wml +++ /dev/null @@ -1,471 +0,0 @@ -#use wml::debian::template title="Debian BTS — developer info" NOHEADER=yes NOCOPYRIGHT=true -#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc" -#use wml::debian::translation-check translation="40a57e26c62893be7c80d82f1772999f68d51179" maintainer="galaxico" - -<h1>Information regarding the bug processing system for package - maintainers and bug triagers</h1> - -<p>Initially, a bug report is submitted by a user as an ordinary mail -message to <code>submit@bugs.debian.org</code> which must include - a <code>Package</code> line (see <a href="Reporting">Bug Reporting - Instructions</a> for more information). This will then be -given a number, acknowledged to the user, and forwarded to -<code>debian-bugs-dist</code>. If the <code>Package</code> line contains a -package which has a known maintainer, -the maintainer will get a copy too.</p> - -<p>The <code>Subject</code> line will have -<code>Bug#</code><var>nnn</var><code>:</code> added, and the -<code>Reply-To</code> will be set to include both the submitter of the -report and <var>nnn</var><code>@bugs.debian.org</code>.</p> - -<ul class="toc"> - <li><a href="#closing">Closing bug reports</a></li> - <li><a href="#followup">Followup messages</a></li> - <li><a href="#severities">Severity levels</a></li> - <li><a href="#tags">Tags for bug reports</a></li> - <li><a href="#forward">Recording that you have passed on a bug report</a></li> - <li><a href="#owner">Changing bug ownership</a></li> - <li><a href="#maintincorrect">Incorrectly listed package maintainers</a></li> - <li><a href="#requestserv">Reopening, reassigning and manipulating bugs</a></li> - <li><a href="#subscribe">Subscribing to bugs</a></li> - <li><a href="#subjectscan">More-or-less obsolete subject-scanning feature</a></li> - <li><a href="#x-debian-pr">Obsolete <code>X-Debian-PR: quiet</code> feature</a></li> -</ul> - -<h2><a name="closing">Closing bug reports</a></h2> - -<p>Debian bug reports should be closed when the problem is fixed. Problems -in packages can only be considered fixed once a package that includes the -bug fix enters the Debian archive.</p> - -<p>Normally, the only people that should close a bug report are the -submitter of the bug and the maintainer(s) of the package against which the -bug is filed. There are exceptions to this rule, for example, the bugs filed -against unknown packages or certain generic pseudo-packages. A bug can also -be closed by any contributor if the bug is for an <strong>orphaned</strong> -package or if the maintainer of a package has missed closing it. It is very -important to mention the version in which the bug was fixed. When in doubt, -don't close bugs, first ask for advice on the debian-devel mailing list.</p> - -<p>Bug reports should be closed by sending email to -<var>nnn</var><code>-done@bugs.debian.org</code>. The message body -needs to contain an explanation of how the bug was fixed.</p> - -<p>With the emails received from the bug tracking system, all you need -to do to close the bug is to make a Reply in your mail reader program -and edit the <code>To</code> field to say -<var>nnn</var><code>-done@bugs.debian.org</code> instead of -<var>nnn</var><code>@bugs.debian.org</code> -(<var>nnn</var><code>-close</code> is provided as an alias for -<var>nnn</var><code>-done</code>).</p> - -<p>Where applicable, please supply a <code>Version</code> line in the -<a href="Reporting#pseudoheader">pseudo-header</a> of your message when -closing a bug, so that the bug tracking system knows which releases of the -package contain the fix.</p> - -<p>The person closing the bug, the person who submitted it and the -<code>debian-bugs-closed</code> mailing list will each get a notification -about the change in status of the report. The submitter and the mailing list -will also receive the contents of the message sent to -<var>nnn</var><code>-done</code>.</p> - - -<h2><a name="followup">Followup messages</a></h2> - -<p>The bug tracking system will include the submitter's address and the bug -address (<var>nnn</var><code>@bugs.debian.org</code>) in the <code>Reply-To</code> -header after forwarding the bug report. Please note that these are two -distinct addresses.</p> - -<p> -Any developer wishing to reply to a bug report should simply reply -to the message, respecting the <code>Reply-To</code> header. This will -<strong>not</strong> close the bug.</p> - -<p>Do <em>not</em> use the <q>reply to all recipients</q> or <q>followup</q> -feature of your mailer unless you intend to edit down the recipients -substantially. In particular, see that you don't send followup messages -to <code>submit@bugs.debian.org</code>.</p> - -<p> -Messages can be sent to the following addresses -in order to be filed in the bug tracking system: -</p> - -<ul> -<li> -<var>nnn</var><code>@bugs.debian.org</code> — such messages are also sent -to the package maintainer and forwarded to <code>debian-bugs-dist</code>, -but <strong>not</strong> to the submitter; -</li> -<li> -<var>nnn</var><code>-submitter@bugs.debian.org</code> — these are also sent -to the submitter and forwarded to <code>debian-bugs-dist</code>, -but <strong>not</strong> to the package maintainer; -</li> -<li> -<var>nnn</var><code>-maintonly@bugs.debian.org</code> — these are only sent -to the package maintainer, <strong>not</strong> to the submitter -or <code>debian-bugs-dist</code>; -</li> -<li> -<var>nnn</var><code>-quiet@bugs.debian.org</code> — these are only -filed in the bug tracking system (as are all the above), -<strong>not</strong> sent to anyone else. -</li> -</ul> - -<p>For more information about headers to suppress ACK messages and how -to send carbon copies using the Bug Tracking System, see the -<a href="Reporting">instructions for reporting bugs</a>.</p> - - -<h2><a name="severities">Severity levels</a></h2> - -<p>The bug system records a severity level with each bug report. This is -set to <code>normal</code> by default, but can be overridden either by -supplying a <code>Severity</code> line in the pseudo-header when the -bug is submitted (see the -<a href="Reporting#pseudoheader">instructions for reporting -bugs</a>), or by using the <code>severity</code> command with the -<a href="#requestserv">control request server</a>.</p> - -<p>The severity levels are:</p> - -<dl> -<dt><code>critical</code></dt> -<dd>makes unrelated software on the system (or the whole system) -break, or causes serious data loss, or introduces a security hole on -systems where you install the package.</dd> - -<dt><code>grave</code></dt> -<dd>makes the package in question unusable or mostly so, or causes -data loss, or introduces a security hole allowing access to the -accounts of users who use the package.</dd> - -<dt><code>serious</code></dt> -<dd>is a <a href="$(DOC)/debian-policy/">severe -violation of Debian policy</a> (roughly, it violates a <q>must</q> or <q>required</q> -directive), or, in the package maintainer's or release manager's opinion, makes the package -unsuitable for release.</dd> - -<dt><code>important</code></dt> -<dd>a bug which has a major effect on the usability of a package, without -rendering it completely unusable to everyone.</dd> - -<dt><code>normal</code></dt> -<dd>the default value, applicable to most bugs.</dd> - -<dt><code>minor</code></dt> -<dd>a problem which doesn't affect the package's usefulness, and is -presumably trivial to fix.</dd> - -<dt><code>wishlist</code></dt> -<dd>for any feature request, and also for any bugs that are -very difficult to fix due to major design considerations.</dd> -</dl> - -<p>Certain severities are considered -<em><a href="https://bugs.debian.org/release-critical/">release-critical</a></em>, -meaning the bug will have an impact on releasing the package with the -stable release of Debian. Currently, these are <strong>critical</strong>, -<strong>grave</strong> and <strong>serious</strong>. For complete and -canonical rules on what issues merit these severities, see the list of -<a href="https://release.debian.org/testing/rc_policy.txt">release-critical -issues for the next release</a>.</p> - -<h2><a name="tags">Tags for bug reports</a></h2> - -<p>Each bug can have zero or more of a set of given tags. These tags are -displayed in the list of bugs when you look at a package's page, and when -you look at the full bug log.</p> - -<p>Tags can be set by supplying a <code>Tags</code> line in the -pseudo-header when the bug is submitted (see the -<a href="Reporting#pseudoheader">instructions for reporting bugs</a>), -or by using the <code>tags</code> command with the -<a href="#requestserv">control request server</a>. -Separate multiple tags with commas, spaces, or both.</p> - -<p>The current bug tags are: <bts_tags>. Here is some detailed info -about the tags:</p> - -<dl> - -<dt><code>patch</code></dt> - <dd>A patch or some other easy procedure for fixing the bug is included in - the bug logs. If there's a patch, but it doesn't resolve the bug - adequately or causes some other problems, this tag should not be used.</dd> - -<dt><code>wontfix</code></dt> - <dd>This bug won't be fixed. Possibly because this is a choice between two - arbitrary ways of doing things and the maintainer and submitter prefer - different ways of doing things, possibly because changing the behaviour - will cause other, worse, problems for others, or possibly for other - reasons.</dd> - -<dt><code>moreinfo</code></dt> - <dd>This bug can't be addressed until more information is provided by the - submitter. The bug will be closed if the submitter doesn't provide more - information in a reasonable (few months) timeframe. This is for bugs like - <q>It doesn't work</q>. What doesn't work?</dd> - -<dt><code>unreproducible</code></dt> - <dd>This bug can't be reproduced on the maintainer's system. Assistance - from third parties is needed in diagnosing the cause of the problem.</dd> - -<dt><code>help</code></dt> -<dd>The maintainer is requesting help with dealing with this bug. - Either the maintainer does not have the skills necessary to fix this - bug and desires collaboration, or is overloaded and wants to - delegate this task. This bug might not be suitable for new - contributors unless it is also tagged with the <code>newcomer</code> - tag.</dd> - -<dt><code>newcomer</code></dt> - <dd>This bug has a known solution but the maintainer requests - someone else implement it. This is an ideal task for new - contributors who wish to get involved in Debian, or who wish to - improve their skills.</dd> - -<dt><code>pending</code></dt> - <dd>A solution to this bug has been found and an upload will be made soon.</dd> - -<dt><code>fixed</code></dt> - <dd>This bug is fixed or worked around (by a non-maintainer upload, for - example), but there's still an issue that needs to be resolved. This tag - replaces the old <q>fixed</q> severity.</dd> - -<dt><code>security</code></dt> - <dd>This bug describes a security problem in a package (e.g., bad - permissions allowing access to data that shouldn't be accessible; buffer - overruns allowing people to control a system in ways they shouldn't be - able to; denial of service attacks that should be fixed, etc). Most - security bugs should also be set at critical or grave severity.</dd> - -<dt><code>upstream</code></dt> - <dd>This bug applies to the upstream part of the package.</dd> - -<dt><code>confirmed</code></dt> - <dd>The maintainer has looked at, understands, and basically agrees with - the bug, but has yet to fix it. (Use of this tag is optional; it is - intended mostly for maintainers who need to manage large numbers of open - bugs.)</dd> - -<dt><code>fixed-upstream</code></dt> - <dd>The bug has been fixed by the upstream maintainer, but not yet in the - package (for whatever reason: perhaps it is too complicated to backport - the change or too minor to be worth bothering).</dd> - -<dt><code>fixed-in-experimental</code></dt> - <dd>The bug has been fixed in the package of the experimental - distribution, but not yet in the unstable distribution.</dd> - -<dt><code>d-i</code></dt> - <dd>This bug is relevant to the development of debian-installer. It is - expected that this will be used when the bug affects installer development - but is not filed against a package that forms a direct part of the - installer itself.</dd> - -<dt><code>ipv6</code></dt> - <dd>This bug affects support for Internet Protocol version 6.</dd> - -<dt><code>lfs</code></dt> - <dd>This bug affects support for large files (over 2 gigabytes).</dd> - -<dt><code>l10n</code></dt> - <dd>This bug is relevant to the localisation of the package.</dd> - -<dt><code>a11y</code></dt> - <dd>This bug affects accessibility for users with disabilities. It - particularly impacts usability by people who rely on assistive (or - other adaptive) technology to use the system/package.</dd> - -<dt><code>ftbfs</code></dt> - <dd>The package fails to build from source. If the bug is assigned to a - source package, that package fails to build. If the bug is assigned - to a binary package, the affected source packages fail to build. The - tag is applicable to non-standard build environments (e.g. using - Build-Depends from experimental), but the severity should be below - serious (release critical) in such cases.</dd> - -<dt><bts_release_tags></dt> - <dd>These are release tags, which have two effects. When set on a bug, - the bug can only affect the particular release (though it may also affect - other releases if other release tags are set) but otherwise normal - buggy/fixed/absent rules apply. The bug also should not be - archived until it is fixed in the release.</dd> - -<dt><bts_release_ignore_tags></dt> - <dd>This release-critical bug is to be ignored for the purposes of - releasing the particular release. <strong>These tags should only be used by the release - manager(s); do not set it yourself without explicit authorization from - them.</strong></dd> - -</dl> - -<p>Some info on distribution-specific tags: - the -ignore tags ignore the bug for the purposes - of testing propagation. The release tags indicate that the bug in - question should not be archived until it is fixed in the set of - releases specified. The release tags also indicate that a bug should - only be considered buggy in the set of releases specified. [In other - words, the bug is <strong>absent</strong> in any release whose - corresponding release tag is <strong>not</strong> set if any release - tags are set; otherwise the normal found/fixed rules apply.] -</p> - -<p> - Release tags should <strong>not</strong> be used if proper - versioning of the bug would achieve the desired effect, as they - require manual addition and removal. If you are unsure if a release - tag is required, contact the Debian BTS Administrators - (<email "owner@bugs.debian.org">) or the release team for advice. -</p> - -<h2><a name="forward">Recording that you have passed on a bug report</a></h2> - -<p>When a developer forwards a bug report to the developer of the -upstream source package from which the Debian package is derived, -they should note this in the bug tracking system as follows:</p> - -<p>Make sure that the <code>To</code> field of your message to the author -has only the author(s) address(es) in it; put the person who -reported the bug, -<var>nnn</var><code>-forwarded@bugs.debian.org</code> -and <var>nnn</var><code>@bugs.debian.org</code> in the -<code>CC</code> field.</p> - -<p>Ask the author to preserve the <code>CC</code> to -<var>nnn</var><code>-forwarded@bugs.debian.org</code> when they reply, so that -the bug tracking system will file their reply with the original -report. These messages are only filed and are not sent on; to send a -message as normal, send them -to <var>nnn</var><code>@bugs.debian.org</code> as well.</p> - -<p>When the bug tracking system gets a message at -<var>nnn</var><code>-forwarded</code> it will mark the relevant bug as -having been forwarded to the address(es) in the <code>To</code> field -of the message it gets, if the bug is not already marked as forwarded.</p> - -<p>You can also manipulate the <q>forwarded to</q> information by sending -messages to <a href="server-control"><code>control@bugs.debian.org</code></a>.</p> - - -<h2><a name="owner">Changing bug ownership</a></h2> - -<p>In cases where the person responsible for fixing a bug is not the -assigned maintainer for the associated package (for example, when the -package is maintained by a team), it may be useful to record this fact -in the bug tracking system. To help with this, each bug may -optionally have an owner.</p> - -<p>The owner can be set by supplying an <code>Owner</code> line in the -pseudo-header when the bug is submitted (see the -<a href="Reporting#pseudoheader">instructions for reporting bugs</a>), -or by using the <code>owner</code> and <code>noowner</code> commands -with the <a href="#requestserv">control request server</a>.</p> - - -<h2><a name="maintincorrect">Incorrectly listed package maintainers</a></h2> - -<p>If the maintainer of a package is listed incorrectly, this is -usually because the maintainer has changed recently, and the new -maintainer hasn't yet uploaded a new version of the package with a -changed <code>Maintainer</code> control file field. This will be -fixed when the package is uploaded; alternatively, the archive maintainers -can override the maintainer record of a package manually, for example if -a rebuild and reupload of the package is not expected to be needed soon. -Contact <code>override-change@debian.org</code> for changes to the -override file.</p> - - -<h2><a name="requestserv">Reopening, reassigning and manipulating bugs</a></h2> - -<p>It is possible to reassign bug reports to other packages, to reopen -erroneously-closed ones, to modify the information saying to where, if -anywhere, a bug report has been forwarded, to change the severities -and titles of reports, to set the ownership of bugs, to merge and unmerge -bug reports, and to record the versions of packages in which bugs were -found and in which they were fixed. This is done by sending mail to -<code>control@bugs.debian.org</code>.</p> - -<p>The <a href="server-control">format of these messages</a> is -described in another document available on the World Wide Web or in -the file <code>bug-maint-mailcontrol.txt</code>. A plain text version -can also be obtained by mailing the word <code>help</code> to the -server at the address above.</p> - -<h2><a name="subscribe">Subscribing to bugs</a></h2> - -<p>The bug tracking system also allows bug submitters, developers and other -interested third parties to subscribe to individual bugs. This feature can be -used by those wishing to keep an eye on a bug, without having to subscribe to a -package through the <a href="https://tracker.debian.org">Debian Package -Tracker</a>. All messages that are received at -<var>nnn</var><code>@bugs.debian.org</code>, are sent to subscribers.</p> - -<p>Subscribing to a bug can be done by sending an email to -<var>nnn</var><code>-subscribe@bugs.debian.org</code>. The subject and body of -the email are ignored by the BTS. Once this message is processed, users are -sent a confirmation message that they will need to reply to before they are -sent the messages relating to that bug.</p> - -<p>It is also possible to unsubscribe from a bug. Unsubscribing can be done by -sending an email to <var>nnn</var><code>-unsubscribe@bugs.debian.org</code>. The -subject and body of the email are again ignored by the BTS. Users will be sent -a confirmation message which they must reply to if they wish to be unsubscribed -from the bug.</p> - -<p>By default, the address subscribed is the one found in the <code>From</code> -header. If you wish to subscribe another address to a bug, you will need to -encode the address to be subscribed into the subscription message. This takes the form of: -<var>nnn</var><code>-subscribe-</code>\ -<var>localpart</var><code>=</code>\ -<var>example.com</var><code>@bugs.debian.org</code>. -That example would send <code>localpart@example.com</code> a subscription message -for bug <var>nnn</var>. The <code>@</code> sign must be encoded by changing it -to an <code>=</code> sign. Similarly, an unsubscription takes the form -<var>nnn</var><code>-unsubscribe-</code><var>localpart</var>\ -<code>=</code><var>example.com</var><code>@bugs.debian.org</code>. -In both cases, the subject and body of the email will be forwarded to the email -address within the request for confirmation.</p> - -<h2><a name="subjectscan">More-or-less obsolete subject-scanning feature</a></h2> - -<p>Messages that arrive at <code>submit</code> or <code>bugs</code> whose -Subject starts <code>Bug#</code><var>nnn</var> will be treated as -having been sent to <var>nnn</var><code>@bugs.debian.org</code>. This is both -for backwards compatibility with mail forwarded from the old -addresses, and to catch followup mail sent to <code>submit</code> by -mistake (for example, by using reply to all recipients).</p> - -<p>A similar scheme operates for <code>maintonly</code>, -<code>done</code>, <code>quiet</code> and <code>forwarded</code>, -which treat mail arriving with a Subject tag as having been sent to -the corresponding <var>nnn-whatever</var><code>@bugs.debian.org</code> address.</p> - -<p>Messages arriving at plain <code>forwarded</code> and -<code>done</code> — ie, with no bug report number in the address — and -without a bug number in the Subject will be filed under <q>junk</q> and -kept for a few weeks, but otherwise ignored.</p> - - -<h2><a name="x-debian-pr">Obsolete <code>X-Debian-PR: quiet</code> feature</a></h2> - -<p>It used to be possible to prevent the bug tracking system from -forwarding anywhere messages it received at <code>debian-bugs</code>, -by putting an <code>X-Debian-PR: quiet</code> line in the actual mail -header.</p> - -<p>This header line is now ignored. Instead, send your message to -<code>quiet</code> or <var>nnn</var><code>-quiet</code> (or -<code>maintonly</code> or <var>nnn</var><code>-maintonly</code>).</p> - -<hr /> - -#use "otherpages.inc" - -#use "$(ENGLISHDIR)/Bugs/footer.inc" diff --git a/greek/Bugs/Reporting.wml b/greek/Bugs/Reporting.wml deleted file mode 100644 index 693ccbbe8fa..00000000000 --- a/greek/Bugs/Reporting.wml +++ /dev/null @@ -1,518 +0,0 @@ -#use wml::debian::template title="Debian BTS - reporting bugs" NOHEADER=yes NOCOPYRIGHT=true -#use wml::debian::translation-check translation="387a1b1ba7d55da8110abcaf96b5711187791f78" maintainer="galaxico" - -<h1>How to report a bug in Debian using reportbug</h1> - -<a name="reportbug"></a> -<p>We strongly recommend that you report bugs in Debian using the -<code><a -href="https://packages.debian.org/stable/utils/reportbug">reportbug</a></code> -program.</p> - -<p> -reportbug is installed by default on most systems. -If it is not available, it can be installed using the -package management tool available on your system. -</p> - -<p> -reportbug can be started from the system section of the menu or -by running <code>reportbug</code> via the command-line. -</p> - -<p>It will guide you through the bug reporting process step by step.</p> - -<p>If you have questions that the interactive prompts of reportbug do -not resolve, you can refer to the rest of the documentation below or ask the <a -href="mailto:debian-user@lists.debian.org"> Debian user mailing -list</a>.</p> - - -<h1> How to report a bug in Debian using email - (and advanced usage of reportbug)</h1> - -<h2>Important things to note <strong>before</strong> sending your bug -report</h2> - -<a name="whatpackage"></a> -<h3>What package does your bug report belong to?</h3> -<p>You need to know what package your bug report should be filed -against. See <a href="#findpkgver">this example</a> for -information on how to find this information. (You will use this -information to <a href="#filedalready">see if your bug report -has been filed already.</a>) -</p> - -<p>If you are unable to determine which package your bug report should -be filed against, -please send e-mail to the <a href="mailto:debian-user@lists.debian.org"> -Debian user mailing list</a> asking for advice.</p> - -<p>If your problem doesn't -relate just to one package but some general Debian service, there are -several <a href="pseudo-packages">pseudo-packages</a> or even -<a href="../MailingLists/">mailing lists</a> that you can use -to relay your message to us instead.</p> - -<a name="filedalready"></a> -<h3>Has your bug report been filed already?</h3> -<p>You should check to see if your bug report has already been filed -before submitting it. You can see which bugs have been filed in -a specific package using the -<a href="./#pkgreport">package option of the bug search form</a>. -If there is an existing bug report #<var><number></var>, -you should submit your comments by sending e-mail to -<var><number></var>@bugs.debian.org instead of reporting a -new bug.</p> - -<h3>Send multiple reports for multiple bugs</h3> -<p>Please don't report multiple unrelated bugs — especially ones in -different packages — in a single bug report.</p> - -<h3>Don't file bugs upstream</h3> -<p>If you file a bug in Debian, don't send a copy to the upstream software -maintainers yourself, as it is possible that the bug exists only in -Debian. If necessary, the maintainer of the package will forward the -bug upstream.</p> - -<h2>Sending the bug report via e-mail</h2> - -<p>You can report bugs in Debian by sending an e-mail to -<a href="mailto:submit@bugs.debian.org"><code>submit@bugs.debian.org</code></a> -with a special format described below. <code>reportbug</code> (<a -href="#reportbug">see above</a>) will properly format the e-mails for you; -please use it!</p> - -<h3>Headers</h3> -<p>Like any e-mail you should include a clear, descriptive -<code>Subject</code> line in your main mail header. The subject you -give will be used as the initial bug title in the tracking system, so -please try to make it informative!</p> - -<p>If you'd like to send a copy of your bug report to additional recipients -(such as mailing lists), you shouldn't use the usual e-mail headers, but -<a href="#xcc">a different method, described below</a>.</p> - -<h3><a name="pseudoheader">Pseudo-headers</a></h3> -<p>The first part of the bug report are the pseudo-headers which contain -information about what package and version your bug report applies to. -The first line of the message body has to include a pseudo-header. -It should say:</p> - -<pre> -Package: <packagename> -</pre> - -<p>Replace <code><packagename></code> with the <a href="#whatpackage">name of the package</a> which -has the bug.</p> - -<p>The second line of the message should say:</p> - -<pre> -Version: <packageversion> -</pre> - -<p>Replace <code><packageversion></code> with the version of the package. -Please don't include any text here other than the version itself, as the -bug tracking system relies on this field to work out which releases are -affected by the bug.</p> - -<p>You need to supply a correct <code>Package</code> line in the -pseudo-header in order for the bug tracking system to deliver the message -to the package's maintainer. See <a href="#findpkgver">this example</a> for -information on how to find this information.</p> - -<p>For other valid pseudo-headers, see <a -href="#additionalpseudoheaders">Additional pseudo-headers</a></p> - -<h3>The body of the report</h3> -<p>Please include in your report:</p> - -<ul> -<li>The <em>exact</em> and <em>complete</em> text of any error -messages printed or logged. This is very important!</li> -<li>Exactly what you typed or did to demonstrate the problem.</li> -<li>A description of the incorrect behavior: exactly what behavior -you were expecting, and what you observed. A transcript of an -example session is a good way of showing this.</li> -<li>A suggested fix, or even a patch, if you have one.</li> -<li>Details of the configuration of the program with the problem. -Include the complete text of its configuration files.</li> -<li>The versions of any packages on which the buggy package depends.</li> -<li>What kernel version you're using (type <code>uname -a</code>), your -shared C library (type <code>ls -l /lib/*/libc.so.6</code> or -<code>apt show libc6 | grep ^Version</code>), and any other details about -your Debian system, if it seems appropriate. For example, if you had a -problem with a Perl script, you would want to provide the version of the -`perl' binary (type <code>perl -v</code> or <code>dpkg -s perl | grep -^Version:</code>).</li> -<li>Appropriate details of the hardware in your system. If you're -reporting a problem with a device driver please list <em>all</em> the -hardware in your system, as problems are often caused by IRQ and I/O -address conflicts.</li> -<li>If you have <a -href="https://packages.debian.org/stable/utils/reportbug">reportbug</a> - installed the output of - <code>reportbug --template -T none -s none -S normal -b --list-cc - none -q <package></code> -will also be useful, as it contains the output of maintainer specific -scripts and version information.</li> -</ul> - -<p>Include any detail that seems relevant — you are in very little danger -of making your report too long by including too much information. If -they are small, please include in your report any files you were using -to reproduce the problem. (If they are large, consider making them -available on a publicly available website if possible.)</p> - -<p>For more advice on how to help the developers solve your problem, -please read <a href="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html"> -How to Report Bugs Effectively</a>.</p> - - -<h2><a name="example">An Example Bug Report</a></h2> - -<p>A bug report with header and pseudo-header looks something like this:</p> - -<pre> - To: submit@bugs.debian.org - From: diligent@testing.linux.org - Subject: Hello says `goodbye' - - Package: hello - Version: 1.3-16 - - When I invoke `hello' without arguments from an ordinary shell - prompt it prints `goodbye', rather than the expected `hello, world'. - Here is a transcript: - - $ hello - goodbye - $ /usr/bin/hello - goodbye - $ - - I suggest that the output string, in hello.c, be corrected. - - I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13 - and libc6 2.1.3-10. -</pre> - - -<h2><a name="xcc">Sending copies of bug reports to other addresses</a></h2> - -<p>Sometimes it is necessary to send a copy of a bug report to somewhere -else besides <code>debian-bugs-dist</code> and the package maintainer, -which is where they are normally sent.</p> - -<p>You could do this by CC'ing your bug report to the other address(es), -but then the other copies would not have the bug report number put in -the <code>Reply-To</code> field and the <code>Subject</code> line. -When the recipients reply they will probably preserve the -<code>submit@bugs.debian.org</code> entry in the header and have their -message filed as a new bug report. This leads to many duplicated -reports.</p> - -<p>The <em>right</em> way to do this is to use the -<code>X-Debbugs-CC</code> header. Add a line like this to your -message's mail header:</p> -<pre> - X-Debbugs-CC: other-list@cosmic.edu -</pre> -<p>This will cause the bug tracking system to send a copy of your report -to the address(es) in the <code>X-Debbugs-CC</code> line as well as to -<code>debian-bugs-dist</code>.</p> - -<p>If you want to send copies to more than one address, add them -comma-separated in only one <code>X-Debbugs-CC</code> line.</p> - -<p>Avoid sending such copies to the addresses of other bug reports, as -they will be caught by the checks that prevent mail loops. There is -relatively little point in using <code>X-Debbugs-CC</code> for this -anyway, as the bug number added by that mechanism will just be replaced -by a new one; use an ordinary <code>CC</code> header instead.</p> - -<p>This feature can often be combined usefully with mailing -<code>quiet</code> — see below.</p> - -<a name="additionalpseudoheaders"></a> -<h1>Additional Pseudoheaders</h1> - -<h2><a name="severities">Severity levels</a></h2> - -<p>If a report is of a particularly serious bug, or is merely a feature -request, you can set the severity level of the bug as you report -it. This is not required however, and the package maintainer will assign an -appropriate severity level to your report even if you do not (or pick -the wrong severity).</p> - -<p>To assign a severity level, put a line like this one in the -<a href="#pseudoheader">pseudo-header</a>:</p> - -<pre> -Severity: <<var>severity</var>> -</pre> - -<p>Replace <<var>severity</var>> with one of the available severity -levels, as described in the -<a href="Developer#severities">advanced documentation</a>.</p> - -<h2><a name="tags">Assigning tags</a></h2> - -<p>You can set tags on a bug as you are reporting it. For example, if -you are including a patch with your bug report, you may wish to set the -<code>patch</code> tag. This is not required, however, and the developers -will set tags on your report as and when it is appropriate.</p> - -<p>To set tags, put a line like this one in the -<a href="#pseudoheader">pseudo-header</a>:</p> - -<pre> -Tags: <<var>tags</var>> -</pre> - -<p>Replace <<var>tags</var>> with one or more of the available tags, -as described in the -<a href="Developer#tags">advanced documentation</a>. -Separate multiple tags with commas, spaces, or both.</p> - -<pre> -User: <<var>username</var>> -Usertags: <<var>usertags</var>> -</pre> - -<p>Replace <<var>usertags</var>> with one or more usertags. -Separate multiple tags with commas, spaces, or both. If you specify a -<<var>username</var>>, that user's tags will be set. Otherwise, -the e-mail address of the sender will be used as the username.</p> - -<p>You can set usertags for multiple users at bug submission time by -including multiple User pseudo-headers; each Usertags pseudo-header -sets the usertags for the preceding User pseudo-header. This is especially -useful for setting usertags for a team with multiple users, setting -usertags for multiple teams, or setting the -<a href="https://wiki.debian.org/Teams/Debbugs/ArchitectureTags">architecture usertags</a> -for bugs affecting multiple architectures. -</p> - -<pre> -User: <<var>first-username</var>> -Usertags: <<var>first-username usertags</var>> -User: <<var>second-username</var>> -Usertags: <<var>second-username usertags</var>> -</pre> - -<h2>Setting Forwarded</h2> -<pre> -Forwarded: <var>foo@example.com</var> -</pre> - -<p> -will mark the newly submitted bug as forwarded to foo@example.com. See -<a href="Developer#forward">Recording that you have passed on a bug -report</a> in the developers' documentation for details. -</p> - -<h2>Claiming ownership</h2> -<pre> -Owner: <var>foo@example.com</var> -</pre> - -<p> -will indicate that foo@example.com is now responsible for fixing this -bug. See <a href="Developer#owner">Changing bug ownership</a> in the -developers' documentation for details. -</p> - -<h2>Source Package</h2> -<pre> -Source: <var>foopackage</var> -</pre> - -<p> -the equivalent of <code>Package:</code> for bugs present in the source -package of foopackage; for most bugs in most packages you don't want -to use this option. -</p> - -<h2><a name="control">Control Commands</a></h2> -<pre> -Control: <var>control commands</var> -</pre> - -<p> -Allows for any of the commands which must be sent to -<code>control@bugs.debian.org</code> to work when sent to <code>submit@bugs.debian.org</code> or -<code>nnn@bugs.debian.org</code>. -1 initially refers to the current - bug (that is, the bug created by a mail to submit@ or the bug - messaged with nnn@). Please see <a href="server-control">the - server control documentation</a> for more information on the - control commands which are valid.</p> - -<p>For example, the following pseudoheader in a message sent - to <code>12345@bugs.debian.org</code>:</p> - -<pre> -Control: retitle -1 this is the title -Control: severity -1 normal -Control: summary -1 0 -Control: forwarded -1 https://bugs.debian.org/nnn -</pre> - -<p>would cause 12345 to be retitled, its severity changed, summary set, -and marked as forwarded.</p> - - - -<h2>X-Debbugs- headers</h2> -<p>Finally, if your -<acronym title="Mail User Agent" lang="en">MUA</acronym> -doesn't allow you to edit the headers, you can -set the various <code>X-Debbugs-</code> headers in the -<a href="#pseudoheader">pseudo-headers</a>.</p> - - -<h1>Additional information</h1> - -<h2>Different submission addresses (minor or mass bug reports)</h2> - -<p>If a bug report is minor, for example, a documentation typo or a trivial -build problem, please adjust the severity appropriately and send it to -<code>maintonly@bugs.debian.org</code> instead of <code>submit@bugs.debian.org</code>. -<code>maintonly</code> will forward the report to the package maintainer -only, it won't forward it to the BTS mailing lists.</p> - -<p>If you're submitting many reports at once, you should definitely use -<code>maintonly@bugs.debian.org</code> so that you don't cause too much redundant -traffic on the BTS mailing lists. Before submitting many similar bugs you -may also want to post a summary on <code>debian-bugs-dist</code>.</p> - -<p>If wish to report a bug to the bug tracking system that's already been -sent to the maintainer, you can use <code>quiet@bugs.debian.org</code>. Bugs sent to -<code>quiet@bugs.debian.org</code> will not be forwarded anywhere, only filed.</p> - -<p>When you use different submission addresses, the bug tracking system will -set the <code>Reply-To</code> of any forwarded message so that the replies -will by default be processed in the same way as the original report. That -means that, for example, replies to <code>maintonly</code> will go to -<var>nnn</var><code>-maintonly@bugs.debian.org</code> instead of -<var>nnn</var><code>@bugs.debian.org</code>, unless of course one overrides this -manually.</p> - - -<h2>Acknowledgements</h2> - -<p>Normally, the bug tracking system will return an acknowledgement to you -by e-mail when you report a new bug or submit additional information to an -existing bug. If you want to suppress this acknowledgement, include an -<code>X-Debbugs-No-Ack</code> header or pseudoheader in your e-mail -(the contents of this header do not matter). If you report a new bug -with this header, you will need to check the web interface yourself to -find the bug number.</p> - -<p>Note that this header will not suppress acknowledgements from the -<code>control@bugs.debian.org</code> mailserver, since those acknowledgements may -contain error messages which should be read and acted upon.</p> - -<h2>Spamfighting and missing mail</h2> - -<p>The bug tracking system implements a rather extensive set of rules - designed to make sure that spam does not make it through the BTS. - While we try to minimize the number of false positives, they do - occur. If you suspect your mail has triggered a false positive, feel - free to contact <code>owner@bugs.debian.org</code> for assistance. - Another common cause of mail not making it through to the BTS is - utilizing addresses which match procmail's FROM_DAEMON, which - includes mail from addresses like <code>mail@foobar.com</code>. If - you suspect your mail matches FROM_DAEMON, - see <a href="https://manpages.debian.org/cgi-bin/man.cgi?query=procmailrc">procmailrc(5)</a> - to verify, and then resend the mail using an address which does not - match FROM_DAEMON.</p> - - -<h2>Bug reports against unknown packages</h2> - -<p>If the bug tracking system doesn't know who the maintainer of the -relevant package is it will forward the report to -<code>debian-bugs-dist</code> even if <code>maintonly</code> was used.</p> - -<p>When sending to <code>maintonly@bugs.debian.org</code> or -<var>nnn</var><code>-maintonly@bugs.debian.org</code> you should make sure that -the bug report is assigned to the right package, by putting a correct -<code>Package</code> at the top of an original submission of a report, -or by using <A href="server-control">the -<code>control@bugs.debian.org</code> service</A> to (re)assign the report -appropriately.</p> - - -<h2><a name="findpkgver">Using <code>dpkg</code> to find the package and -version for the report</a></h2> - -<p>When using <code>reportbug</code> to report a bug in a command, say -<code>grep</code>, the following will automatically select the right package -and let you write the report right away: <code>reportbug --file $(which -grep)</code></p> - -<p>You can also find out which package installed it by using <code>dpkg ---search</code>. You can find out which version of a package you have -installed by using <code>dpkg --list</code> or <code>dpkg --status</code>. -</p> - -<p>For example:</p> -<pre> -$ which apt-get -/usr/bin/apt-get -$ type apt-get -apt-get is /usr/bin/apt-get -$ dpkg --search /usr/bin/apt-get -apt: /usr/bin/apt-get -$ dpkg --list apt -Desired=Unknown/Install/Remove/Purge/Hold -| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed -|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) -||/ Name Version Description -+++-==============-==============-============================================ -ii apt 0.3.19 Advanced front-end for dpkg -$ dpkg --status apt -Package: apt -Status: install ok installed -Priority: standard -Section: base -Installed-Size: 1391 -Maintainer: APT Development Team <deity@lists.debian.org> -Version: 0.3.19 -Replaces: deity, libapt-pkg-doc (<< 0.3.7), libapt-pkg-dev (<< 0.3.7) -Provides: libapt-pkg2.7 -Depends: libapt-pkg2.7, libc6 (>= 2.1.2), libstdc++2.10 -Suggests: dpkg-dev -Conflicts: deity -Description: Advanced front-end for dpkg - This is Debian's next generation front-end for the dpkg package manager. - It provides the apt-get utility and APT dselect method that provides a - simpler, safer way to install and upgrade packages. - . - APT features complete installation ordering, multiple source capability - and several other unique features, see the Users Guide in - /usr/doc/apt/guide.text.gz - -</pre> - -<a name="otherusefulcommands"></a> -<h2>Other useful commands and packages</h2> - -<p> -The <kbd>querybts</kbd> tool, available from the same package as -<a href="https://packages.debian.org/stable/utils/reportbug">reportbug</a>, -provides a convenient text-based interface to the bug tracking system.</p> - -<p>Emacs users can also use the debian-bug command provided by the -<code><a href="https://packages.debian.org/stable/utils/debian-el">\ -debian-el</a></code> package. When called with <kbd>M-x -debian-bug</kbd>, it will ask for all necessary information in a -similar way to <code>reportbug</code>.</p> - -<hr /> - -#use "otherpages.inc" - -#use "$(ENGLISHDIR)/Bugs/footer.inc" diff --git a/greek/Bugs/otherpages.inc b/greek/Bugs/otherpages.inc deleted file mode 100644 index 0254c44ac18..00000000000 --- a/greek/Bugs/otherpages.inc +++ /dev/null @@ -1,18 +0,0 @@ -<p>Other BTS pages:</p> - -<ul> - <li><a href="./">Bug tracking system main contents page.</a></li> - <li><a href="Reporting">Instructions for reporting bugs.</a></li> - <li><a href="Access">Accessing the bug tracking system logs.</a></li> - <li><a href="Developer">Information for developers on the bug tracking - system.</a></li> - <li><a href="server-control">Developers' information on manipulation - of bugs using the e-mail control interface.</a></li> - <li><a href="server-refcard">Mailservers' reference card.</a></li> - <li><a href="server-request">Requesting bug reports by e-mail.</a></li> -# <li><a href="db/ix/full.html">Full list of outstanding and recent bug -# reports.</a></li> -# <li><a href="db/ix/packages.html">Packages with bug reports.</a></li> -# <li><a href="db/ix/maintainers.html">Maintainers of packages with bug -# reports.</a></li> -</ul> diff --git a/greek/Bugs/pseudo-packages.wml b/greek/Bugs/pseudo-packages.wml deleted file mode 100644 index f2b5f05c05f..00000000000 --- a/greek/Bugs/pseudo-packages.wml +++ /dev/null @@ -1,25 +0,0 @@ -#use wml::debian::template title="Debian BTS - pseudo-packages" NOHEADER="true" NOCOPYRIGHT=true -#use wml::debian::translation-check translation="482085cdd7ca98a1a3142933dbb60ab68c4c36e5" maintainer="galaxico" - -<H1>Debian bug tracking system pseudo-packages</H1> - -<p>This page lists the pseudo-packages available for use in the -<code>Package:</code> line in bug reports. - -<p>See the <a href="Reporting">instructions for reporting a bug</a> for -details of how to specify a <code>Package:</code> line. - -<hrline> - -# Translators: to get translated descriptions create a file -# $yourlang/Bugs/pseudo-packages.translated-description -# See http://cvs.debian.org/webwml/polish/Bugs/pseudo-packages.translated-description?rev=1.1&cvsroot=webwml&content-type=text/vnd.viewcvs-markup -# for the format - -#use "$(ENGLISHDIR)/Bugs/pseudo-packages.inc" - -<hrline> - -#use "otherpages.inc" - -#use "$(ENGLISHDIR)/Bugs/footer.inc" diff --git a/greek/Bugs/server-control.wml b/greek/Bugs/server-control.wml deleted file mode 100644 index 431d195c24a..00000000000 --- a/greek/Bugs/server-control.wml +++ /dev/null @@ -1,751 +0,0 @@ -#use wml::debian::template title="Debian BTS — control server" NOHEADER=yes NOCOPYRIGHT=true -#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc" -#use wml::debian::translation-check translation="d11193e66dd678156a1f8aa4c02b5ec7ae7eb116" maintainer="galaxico" - -<h1>Introduction to the bug control and manipulation mailserver</h1> - -<p> -Just as <code>request@bugs.debian.org</code> allows the <a -href="server-request">retrieval of bug data and documentation by -email</a>, <code>control@bugs.debian.org</code> allows bug 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> -Since the commands specific to the control server actually change -the status of a bug, a notification about processing the commands is -sent to the maintainer of the package(s) the changed bugs are assigned -to. Additionally the mail to the server and the resulting changes are -logged in the bug report and thereby available in the WWW pages. -</p> - -<p> -Please see the -<a href="server-request#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">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> - - <table style="margin-left:auto;margin-right:auto"> - <tr> - <td align="center">General</td> - <td align="center">Versioning</td> - <td align="center">Duplicates</td> - <td align="center">Misc.</td> - </tr> - <tr> - <!-- General --> - <td valign="top"> - <ul class="nodecoration"> - <li><a href="#reassign">reassign</a></li> - <li><a href="#severity">severity</a></li> - <li><a href="#tag">tags</a></li> - <li><a href="#retitle">retitle</a></li> - <li><a href="#submitter">submitter</a></li> - <li><a href="#affects">affects</a></li> - <li><a href="#summary">summary</a></li> - <li><a href="#outlook">outlook</a></li> - </ul> - </td> - <!-- Versioning --> - <td valign="top"> - <ul class="nodecoration"> - <li><a href="#found">found</a> | <a href="#notfound">notfound</a></li> - <li><a href="#fixed">fixed</a> | <a href="#notfixed">notfixed</a></li> - <li><a href="#reopen">reopen</a></li> - <!-- <dt>(close)</dt> Deprecated --> - </ul> - </td> - <!-- Duplicates --> - <td valign="top"> - <ul class="nodecoration"> - <li><a href="#merge">merge</a> | <a href="#unmerge">unmerge</a></li> - <li><a href="#forcemerge">forcemerge</a></li> - <li><a href="#clone">clone</a></li> - </ul> - </td> - <!-- Misc. --> - <td valign="top"> - <ul class="nodecoration"> - <li><a href="#thanks">thanks</a></li> - <li><a href="#comment">#</a></li> - <li><a href="#forwarded">forwarded</a> | <a href="#notforwarded">notforwarded</a></li> - <li><a href="#owner">owner</a> | <a href="#noowner">noowner</a></li> - <li><a href="#block">block</a> | <a href="#unblock">unblock</a></li> - <li><a href="#archive">archive</a> | <a href="#unarchive">unarchive</a></li> - <li><a href="server-request#user">user</a> | - <a href="server-request#usertag">usertag</a> | - <a href="server-request#usercategory">usercategory</a></li> - </ul> - </td> - </tr> - </table> - -<dl> - <dt><a name="reassign"><code>reassign</code> <var>bugnumber</var> - <var>package</var> [ <var>version</var> ]</a></dt> - <dd> - <p> - Records that bug #<var>bugnumber</var> is a bug 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). - </p> - - <p> - If you supply a <var>version</var>, the bug tracking system will note - that the bug affects that version of the newly-assigned package. - </p> - <p> - You can assign a bug to two packages at once by separating the - package names with a comma. <em>However</em>, you should only do - this if the bug can be fixed by a change to <em>either</em> - package. If this is not the case, you - should <a href="#clone">clone</a> the bug and reassign the clone - to the other package. - </p> - </dd> - - - <dt><a name="reopen"><code>reopen</code> <var>bugnumber</var> - [ <var>originator-address</var> | <code>=</code> | <code>!</code> ]</a></dt> - <dd> - <p> - Reopens #<var>bugnumber</var> and clears all fixed versions if it is closed. - </p> - - <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> - - <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> - - <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> - - <p> - 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 <code>submitter</code> command; note that this will inform the - original submitter of the change. - </p> - - <p> - 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 - <code>found</code> command instead. - </p> - </dd> - - - <dt><a name="found"><code>found</code> <var>bugnumber</var> [ - <var>version</var> ]</a></dt> - <dd> - <p> - Record that #<var>bugnumber</var> has been encountered in the given - <var>version</var> of the package to which it is assigned. - <var>version</var> may be a fully qualified version, - of the form <var>sourcepackagename/version</var>. - </p> - - <p> - 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. - </p> - - <p> - If no <var>version</var> is given, then the list of fixed versions for - the bug is cleared. This is identical to the behaviour of - <code>reopen</code>. - <var>version</var> may be a fully qualified version, of the - form <var>sourcepackagename/version</var>. - </p> - - <p> - This command will only cause a bug to be marked as not done if no - version is specified, or if the <var>version</var> being marked - found is equal to or greater than the highest <var>version</var> - marked fixed. (If you are certain that you want the bug marked as - not done, use <code>reopen</code> in conjunction - with <code>found</code>.) - </p> - - <p> - This command was introduced in preference to <code>reopen</code> - because it was difficult to add a <var>version</var> to that command's - syntax without suffering ambiguity. - </p> - </dd> - - - <dt><a name="notfound"><code>notfound</code> <var>bugnumber</var> - <var>version</var></a></dt> - <dd> - <p> - Remove the record that #<var>bugnumber</var> was encountered in the - given <var>version</var> of the package to which it is assigned. - <var>version</var> may be a fully qualified version, of - the form <var>sourcepackagename/version</var>. - </p> - - <p> - 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. - </p> - </dd> - - - <dt><a name="fixed"><code>fixed</code> <var>bugnumber</var> - <var>version</var></a></dt> - <dd> - <p> - Indicate that bug #<var>bugnumber</var> was fixed in the given - <var>version</var> of the package to which it is assigned. - <var>version</var> may be a fully qualified version, of the - form <var>sourcepackagename/version</var>. - </p> - - <p> - This does <em>not</em> cause the bug to be marked as closed, it - merely adds another version in which the bug was fixed. Use the - bugnumber-done address to close a bug and mark it fixed in a - particular version. - </p> - </dd> - - - <dt><a name="notfixed"><code>notfixed</code> <var>bugnumber</var> - <var>version</var></a></dt> - <dd> - <p> - Remove the record that bug #<var>bugnumber</var> has been fixed in - the given <var>version</var>. - <var>version</var> may be a fully qualified version, of the - form <var>sourcepackagename/version</var>. - </p> - - <p> - This command is equivalent to <code>found</code> followed by - <code>notfound</code> (the found removes the fixed at a particular - version, and notfound removes the found) with the exception that - the bug is not reopened if the found version is greater than any - existing fixed version. It is intended for fixing mistakes in the - record of when a bug was fixed; in most cases, you actually want - <code>found</code>, not <code>notfixed</code>. - </p> - </dd> - - - <dt><a name="submitter"><code>submitter</code> <var>bugnumber</var> - <var>originator-address</var> | <code>!</code></a></dt> - <dd> - <p> - Changes the originator of #<var>bugnumber</var> to - <var>originator-address</var>. - </p> - - <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> - </dd> - - - <dt><a name="forwarded"><code>forwarded</code> <var>bugnumber</var> - <var>address</var></a></dt> - <dd> - <p> - 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 bug that wasn't previously noted - as having been forwarded. <var>address</var> should generally be a - URI, or possibly an email address. Using a URI where possible - allows tools to query a remote bug tracking system (such as - bugzilla) for a bug's status. - </p> - - <p> - Example usage: - </p> - - <pre> - forwarded 12345 http://bugz.illa.foo/cgi/54321 - </pre> - </dd> - - - <dt><a name="notforwarded"><code>notforwarded</code> - <var>bugnumber</var></a></dt> - <dd> - <p> - Forgets any idea that <var>bugnumber</var> has been forwarded to any - upstream maintainer. If the bug was not recorded as having been - forwarded then this will do nothing. - </p> - </dd> - - - <dt><a name="retitle"><code>retitle</code> <var>bugnumber</var> - <var>new-title</var></a></dt> - <dd> - <p> - Changes the title of a bug report to that specified (the default is - the <code>Subject</code> mail header from the original report). - Will also change the titles of all bug reports which this bug is - merged with. - </p> - </dd> - - - <dt><a name="severity"><code>severity</code> <var>bugnumber</var> - <var>severity</var></a></dt> - <dd> - <p> - Set the severity level for bug report #<var>bugnumber</var> to - <var>severity</var>. No notification is sent to the user who reported - the bug. - </p> - - <p> - Severities are <bts_severities>. - </p> - - <p> - For <a href="Developer#severities">their meanings</a> please - consult the general developers' documentation for the bug system. - </p> - </dd> - - <dt><a name="affects"><code>affects</code> <var>bugnumber</var> - [ <code>+</code> | <code>-</code> | <code>=</code> - ] <var>package</var> [ <var>package</var> ... ]</a></dt> - <dd> - <p> - Indicates that a bug affects another package. In the case - where <var>bugnumber</var> causes breakage in <var>package</var> - even though the bug is actually present in the package to which - it is assigned, this causes the bug to be listed by default in - the bug list of <var>package</var>. This should generally be - used where the bug is severe enough to cause multiple reports - from users to be assigned to the wrong package. <code>=</code> - sets the affects to the list of packages given, and is the - default action if no packages are given; <code>-</code> removes - the given packages from the affects list; <code>+</code> adds - the given packages to the affects list, and is the default if - packages are given. - </p> - </dd> - - <dt><a name="summary"><code>summary</code> <var>bugnumber</var> - [<var>message number</var> | <var>summary text</var>]</a></dt> - <dd> - <p> - Selects a message to use as a summary of a bug. The first - non-pseudoheader/non-control paragraph of that message is parsed and set as the - summary of the bug which is displayed on the top of the bug - report page. This is useful in cases where the original report - doesn't correctly describe the problem or the bug has many - messages which make it difficult to identify the actual problem. - </p> - <p> - If <var>message number</var> is not given, clears the - summary. <var>message number</var> is the message number as - listed in the bugreport cgi script output; if - a <var>message number</var> of 0 is given, the current message - is used (that is, the message which was sent to - control@bugs.debian.org which contains the summary control - command). - </p> - <p> - If <var>message number</var> is not numerical and not the empty - string, it is assumed to be the text to set the summary to. - </p> - </dd> - - <dt><a name="outlook"><code>outlook</code> <var>bugnumber</var> - [<var>message number</var> | <var>outlook text</var>]</a></dt> - <dd> - <p> - Selects a message to use as the outlook for fixing a bug (or the - current status of fixing a bug). The first - non-pseudoheader/non-control paragraph of that message is parsed - and set as the outlook of the bug which is displayed on the top - of the bug report page. This is useful to coordinate with others - who are working on fixing this bug (for example, in an bug - squashing party). - </p> - <p> - If <var>message number</var> is not given, clears the - outlook. <var>message number</var> is the message number as - listed in the bugreport cgi script output; if - a <var>message number</var> of 0 is given, the current message - is used (that is, the message which was sent to - control@bugs.debian.org which contains the outlook control - command). - </p> - <p> - If <var>message number</var> is not numerical and not the empty - string, it is assumed to be the text to set the outlook to. - </p> - </dd> - - - <dt><a name="clone"><code>clone</code> <var>bugnumber</var> <var>NewID</var> - [ <var>new IDs</var> ... ]</a></dt> - <dd> - <p> - The clone control command allows you to duplicate a bug report. It is - useful in the case where a single report actually indicates that multiple - distinct bugs have occurred. <q><var>New IDs</var></q> are negative numbers, - separated by spaces, which may be used in subsequent control commands to - refer to the newly duplicated bugs. A new report is generated for each - new ID. - </p> - - <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> - </dd> - - - <dt><a name="merge"><code>merge</code> <var>bugnumber</var> - <var>bugnumber</var> ...</a></dt> - <dd> - <p> - Merges two or more bug reports. When reports are merged opening, - closing, marking or unmarking as forwarded and reassigning any of the - bugs to a new package will have an identical effect on all of the - merged reports. - </p> - - <p> - 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 - <code>reassign</code>, <code>reopen</code> and so forth to make sure - that they are before using <code>merge</code>. Titles are not required - to match, and will not be affected by the merge. Tags are not required - to match, either, they will be joined. - </p> - - <p> - If any of the bugs listed in a <code>merge</code> 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. - </p> - - <p> - Merging reports causes a note to appear on each report's logs; on the - WWW pages this includes links to the other bugs. - </p> - - <p> - Merged reports are all expired simultaneously, and only when all of - the reports each separately meet the criteria for expiry. - </p> - </dd> - - - <dt><a name="forcemerge"><code>forcemerge</code> <var>bugnumber</var> - <var>bugnumber</var> ...</a></dt> - <dd> - <p> - Forcibly merges two or more bug reports. The settings of the first - bug listed which must be equal in a normal merge are assigned to - the bugs listed next. Tags are joined as usual. To avoid typos erroneously merging bugs, - bugs must be in the same package. See the text above for a - description of what merging means. - </p> - - <p> - Note that this makes it possible to close bugs by merging; you - are responsible for notifying submitters with an appropriate close - message if you do this. - </p> - </dd> - - - <dt><a name="unmerge"><code>unmerge</code> <var>bugnumber</var></a></dt> - <dd> - <p> - Disconnects a bug 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 bug explicitly named are removed. - </p> - - <p> - 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. - </p> - - <p> - You can only unmerge one report with each <code>unmerge</code> - command; if you want to disconnect more than one bug simply include - several <code>unmerge</code> commands in your message. - </p> - </dd> - - - <dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>bugnumber</var> [ <code>+</code> | - <code>-</code> | <code>=</code> ] <var>tag</var> [ <var>tag</var> - ... ] [ <code>+</code> | <code>-</code> - | <code>=</code> <var>tag</var> ... ] ]</a></dt> - <dd> - <p> - Sets tags for the bug report #<var>bugnumber</var>. No notification - is sent to the user who reported the bug. Setting the action to - <code>+</code> means to add each <var>tag</var> - following, <code>-</code> means to remove each <var>tag</var> - following, and <code>=</code> means to set the following tags to - the list provided. Intervening <code>+</code>, <code>-</code>, - or <code>=</code> change the action for the tags following. The - default action is adding. - </p> - - <p> - Example usage: - </p> - - <pre> - \# 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 - - \# remove the moreinfo tag and add a patch tag - tags 123456 - moreinfo + patch - </pre> - - <p> - Available tags currently include <bts_tags>. - </p> - - <p> - For <a href="Developer#tags">their meanings</a> please consult the - general developers' documentation for the bug system. - </p> - </dd> - - - <dt><a name="block"><code>block</code> <var>bugnumber</var> <code>by</code> - <var>bug</var> ...</a></dt> - <dd> - Note that the fix for the first bug is blocked by the other listed bugs. - </dd> - - - <dt><a name="unblock"><code>unblock</code> <var>bugnumber</var> - <code>by</code> <var>bug</var> ...</a></dt> - <dd> - Note that the fix for the first bug is no longer blocked by the other - listed bugs. - </dd> - - - <dt><a name="close"><code>close</code> <var>bugnumber</var> [ - <var>fixed-version</var> ] (deprecated)</a></dt> - <dd> - <p> - Close bug report #<var>bugnumber</var>. - </p> - - <p> - A notification is sent to the user who reported the bug, but (in - contrast to mailing <var>bugnumber</var><code>-done@bugs.debian.org</code>) the - text of the mail which caused the bug to be closed is <strong>not</strong> - included in that notification. The maintainer who closes a report - needs to 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. See the - developer's information about <a href="Developer#closing">how to - close a bug properly</a>. - </p> - - <p> - If you supply a <var>fixed-version</var>, the bug tracking system - will note that the bug was fixed in that version of the package. - </p> - </dd> - - - <dt><a name="package"><code>package</code> [ <var>packagename</var> ... - ]</a></dt> - <dd> - <p> - Limits the following commands so that they will only apply to bugs - filed against the listed packages. You can list one or more packages. If - you don't list any packages, the following commands will apply to all - bugs. You're encouraged to use this as a safety feature in case you - accidentally use the wrong bug numbers. - </p> - - <p> - Example usage: - </p> - - <pre> - package foo - reassign 123456 bar 1.0-1 - - package bar - retitle 123456 bar: bar sucks - severity 123456 normal - - package - severity 234567 wishlist - </pre> - </dd> - - - <dt><a name="owner"><code>owner</code> <var>bugnumber</var> - <var>address</var> | <code>!</code></a></dt> - <dd> - <p> - Sets <var>address</var> to be the <q>owner</q> of #<var>bugnumber</var>. - The owner of a bug claims responsibility for fixing it. - This is useful to share out work in cases where a - package has a team of maintainers. - </p> - - <p> - If you wish to become the owner of the bug yourself, you can use the - <code>!</code> shorthand or specify your own email address. - </p> - </dd> - - - <dt><a name="noowner"><code>noowner</code> <var>bugnumber</var></a></dt> - <dd> - Forgets any idea that the bug has an owner other than the usual - maintainer. If the bug had no owner recorded then this will do nothing. - </dd> - - - <dt><a name="archive"><code>archive</code> <var>bugnumber</var></a></dt> - <dd> - Archives a bug that had been archived at some point in the past - but is currently not archived if the bug fulfills - the requirements for archival, ignoring time. - </dd> - - - <dt><a name="unarchive"><code>unarchive</code> <var>bugnumber</var></a></dt> - <dd> - Unarchives a bug that was previously archived. Unarchival should - generally be coupled with reopen and found/fixed as appropriate. Bugs - that have been unarchived can be archived using archive assuming the - non-time based archival requirements are met. You should not be - using unarchive to make trivial changes to archived bugs, such as - changing the submitter; its primary purpose is to allow for the - reopening of bugs which have been archived without the - intervention of BTS administrators. - </dd> - - - <dt><a name="comment"><code>#</code>...</a></dt> - <dd> - One-line comment. The <code>#</code> 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. - </dd> - - - <dt><a name="thanks"><code>quit</code></a></dt> - <dt><code>stop</code></dt> - <dt><code>thank</code></dt> - <dt><code>thanks</code></dt> - <dt><code>thankyou</code></dt> - <dt><code>thank you</code></dt> - <dt><code>--</code></dt> - <!-- #366093, I blame you! --> - <!-- <dt><code>kthxbye</code></dt> --> - <!-- See... I documented it! --> - <dd> - On a line by itself, in any case, possibly followed by - whitespace, 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. - </dd> -</dl> - -<hr /> - -#use "otherpages.inc" - -#use "$(ENGLISHDIR)/Bugs/footer.inc" diff --git a/greek/Bugs/server-refcard.wml b/greek/Bugs/server-refcard.wml deleted file mode 100644 index b8d423b56cf..00000000000 --- a/greek/Bugs/server-refcard.wml +++ /dev/null @@ -1,94 +0,0 @@ -#use wml::debian::template title="Debian BTS — mail server reference card" NOHEADER=yes NOCOPYRIGHT=true -#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc" -#use wml::debian::translation-check translation="edf7479a4ad0dfcf1c56fed4b143f6f261fd1d6d" maintainer="galaxico" - -<h1>Mail servers' reference card</h1> - -<p>Full documentation of the mail servers is available on the WWW, in the -files -<a href="server-request">bug-log-mailserver.txt</a> and -<a href="server-control">bug-maint-mailcontrol.txt</a> or by -sending the word <code>help</code> to each mailserver.</p> - -<h2>Synopsis of commands available at <code>request@bugs.debian.org</code></h2> - -<ul> -<li><code>send</code> <var>bugnumber</var></li> -<li><code>send-detail</code> <var>bugnumber</var></li> -<li><code>index</code> [<code>full</code>]</li> -<li><code>index-summary by-package</code></li> -<li><code>index-summary by-number</code></li> -<li><code>index-maint</code></li> -<li><code>index maint</code> <var>maintainer</var></li> -<li><code>index-packages</code></li> -<li><code>index packages</code> <var>package</var></li> -<li><code>send-unmatched</code> [<code>this</code>|<code>0</code>]</li> -<li><code>send-unmatched</code> <code>last</code>|<code>-1</code></li> -<li><code>send-unmatched</code> <code>old</code>|<code>-2</code></li> -<li><code>getinfo</code> <var>filename</var> <small>(ftp.debian.org/debian/doc/*)</small></li> -<li><code>help</code></li> -<li><code>refcard</code></li> -<li><code><a href="$(BUGS)/server-control#thanks">thanks</a></code></li> -<li><code>#</code>... <em>(comment)</em></li> -<li><code>debug</code> <var>level</var></li> -</ul> - -<h2>Synopsis of extra commands available at <code>control@bugs.debian.org</code></h2> - -<ul> -<li><code>reassign</code> <var>bugnumber</var> <var>package</var> - [ <var>version</var> ]</li> -<li><code>severity</code> <var>bugnumber</var> <var>severity</var></li> -<li><code>reopen</code> <var>bugnumber</var> - [ <var>originator-address</var> | <code>=</code> | <code>!</code> ]</li> -<li><code>found</code> <var>bugnumber</var> [ <var>version</var> ]</li> -<li><code>notfound</code> <var>bugnumber</var> <var>version</var></li> -<li><code>submitter</code> <var>bugnumber</var> - <var>originator-address</var> | <code>!</code></li> -<li><code>forwarded</code> <var>bugnumber</var> <var>address</var></li> -<li><code>notforwarded</code> <var>bugnumber</var></li> -<li><code>owner</code> <var>bugnumber</var> - <var>address</var> | <code>!</code></li> -<li><code>noowner</code> <var>bugnumber</var></li> -<li><code>retitle</code> <var>bugnumber</var> <var>new-title</var></li> -<li><code>clone</code> <var>bugnumber</var> <var>NewID</var> [ <var>new IDs</var> ... ]</li> -<li><code>merge</code> <var>bugnumber</var> <var>bugnumber</var> ...</li> -<li><code>unmerge</code> <var>bugnumber</var></li> -<li><code>forcemerge</code> <var>bugnumber</var> <var>bugnumber</var> ...</li> -<li><code>tags</code> <var>bugnumber</var> - [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var> [ <var>tag</var> ... ]</li> -<li><code>block</code> <var>bugnumber</var> <code>by</code> <var>bug</var> ...</li> -<li><code>unblock</code> <var>bugnumber</var> <code>by</code> <var>bug</var> ...</li> -<li><code>close</code> <var>bugnumber</var> [ <var>fixed-version</var> ] - <strong>(deprecated — you must separately tell originator why, see -<q><a href="Developer#closing">Closing bug reports</a></q> -instead)</strong></li> -</ul> - -<p><code>reopen</code> with <code>=</code> or no originator address leaves -the originator as the original submitter; <code>!</code> sets it to -you, the person doing the reopen.</p> - -<p><a href="Developer#severities">Severities</a> are <bts_severities>.</p> - -<p><a href="Developer#tags">Tags</A> currently include <bts_tags>.</p> - -<h2>Synopsis of bug submission and followup addresses</h2> - -<ul> - <li><var>nnn</var>[ <code>-submit</code> | ]</li> - <li><var>nnn</var><code>-maintonly</code></li> - <li><var>nnn</var><code>-quiet</code></li> - <li><var>nnn</var><code>-forwarded</code></li> - <li><var>nnn</var><code>-request</code></li> - <li><var>nnn</var><code>-submitter</code></li> - <li><var>nnn</var><code>-done</code></li> - <li><var>nnn</var><code>-close</code></li> - <li><var>nnn</var><code>-subscribe</code></li> -</ul> - -<hr /> - -#use "otherpages.inc" - -#use "$(ENGLISHDIR)/Bugs/footer.inc" diff --git a/greek/Bugs/server-request.wml b/greek/Bugs/server-request.wml deleted file mode 100644 index 1499dd6372e..00000000000 --- a/greek/Bugs/server-request.wml +++ /dev/null @@ -1,297 +0,0 @@ -#use wml::debian::template title="Debian BTS - request server" NOHEADER=yes NOCOPYRIGHT=true -#use wml::debian::translation-check translation="ffe142fb8e27c6752fff483899ded27505b6364e" maintainer="galaxico" - -<h1><a name="introduction">Introduction to the bug system request server</a></h1> - -<p>There is a mailserver which can send the bug reports and -indices as plain text on request.</p> - -<p>To use it you send a mail message to -<a href="mailto:request@bugs.debian.org"><code>request@bugs.debian.org</code></a>. -The <code>Subject</code> of the message is ignored, except -for generating the <code>Subject</code> of the reply.</p> - -<p>The body you send should be a series of commands, one per line. -You'll receive a reply which looks like a transcript of your message -being interpreted, with a response to each command. No notifications -are sent to anyone for the commands listed here and the mail isn't -logged anywhere publicly available.</p> - -<p>Any text on a line starting with a hash sign <code>#</code> is -ignored; the server will stop processing when it finds a line with -a <a href="#stopprocessing">control terminator</a> ( -<code>quit</code>, <code>thank you</code>, or two -hyphens are common examples). It will also stop if it -encounters too many unrecognised or badly-formatted commands. If no -commands are successfully handled it will send the help text for the -server.</p> - -<h1>Commands available</h1> - -<dl> -<dt><code>send</code> <var>bugnumber</var></dt> -<dt><code>send-detail</code> <var>bugnumber</var></dt> -<dd> -Requests the transcript for the bug report in question. -<code>send-detail</code> sends all of the <q>boring</q> messages in the -transcript as well, such as the various auto-acks. -</dd> - -<dt><code>index</code> [<code>full</code>]</dt> -<dt><code>index-summary by-package</code></dt> -<dt><code>index-summary by-number</code></dt> -<dd> -Request the full index (with full details, and including done and -forwarded reports), or the summary sorted by package or by number, -respectively. -</dd> - -<dt><code>index-maint</code></dt> -<dd> -Requests the index page giving the list of maintainers with bugs (open -and recently-closed) in the tracking system. -</dd> - -<dt><code>index maint</code> <var>maintainer</var></dt> -<dd> -Requests the index pages of bugs in the system for the maintainer -<var>maintainer</var>. The search term is an exact match. -The bug index will be sent in a separate message. -</dd> - -<dt><code>index-packages</code></dt> -<dd> -Requests the index page giving the list of packages with bugs (open -and recently-closed) in the tracking system. -</dd> - -<dt><code>index packages</code> <var>package</var></dt> -<dd> -Requests the index pages of bugs in the system for the package -<var>package</var>. The search term is an exact match. -The bug index will be sent in a separate message. -</dd> - -<dt><code>send-unmatched</code> [<code>this</code>|<code>0</code>]</dt> -<dt><code>send-unmatched</code> <code>last</code>|<code>-1</code></dt> -<dt><code>send-unmatched</code> <code>old</code>|<code>-2</code></dt> -<dd> -Requests logs of messages not matched to a particular bug report, for -this week, last week and the week before. (Each week ends on a -Wednesday.) -</dd> - -<dt><code>getinfo</code> <var>filename</var></dt> -<dd> -<p> -Request a file containing information about package(s) and or -maintainer(s) - the files available are: -</p> - - <dl> - <dt><code>maintainers</code></dt> - <dd> - The unified list of packages' maintainers, as used by the tracking - system. - This is derived from information in the <code>Packages</code> - files, override files and pseudo-packages files. - </dd> - - <dt><code>override.</code><var>distribution</var></dt> - <dt><code>override.</code><var>distribution</var><code>.non-free</code></dt> - <dt><code>override.</code><var>distribution</var><code>.contrib</code></dt> - <dt><code>override.experimental</code></dt> - <dd> - Information about the priorities and sections of packages and - overriding values for the maintainers. This information is used by - the process which generates the <code>Packages</code> files in the FTP - archive. Information is available for each of the main distribution - trees available, by their codewords. - </dd> - - <dt><code>pseudo-packages.description</code></dt> - <dt><code>pseudo-packages.maintainers</code></dt> - <dd> - List of descriptions and maintainers respectively for pseudo-packages. - </dd> - </dl> -</dd> - -<dt><code>refcard</code></dt> -<dd> -Requests that the mailservers' reference card be sent in plain ASCII. -</dd> - -<dt><a name="user"><code>user</code> <var>address</var></a></dt> -<dd> -Sets <var>address</var> to be the <q>user</q> of all <code>usertag</code> -commands that follow. -</dd> - -<dt><a name="usertag"><code>usertag</code> <var>bugnumber</var> - [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var> - [ <var>tag</var> ... ]</a></dt> -<dd> -Allows to define tags on a per-user basis. The <code>usertag</code> -command works just like the regular <code>tag</code> command, except -that you get to make up whatever tags you like. By default, the address -in the <code>From:</code> or <code>Reply-To:</code> header of your mail -will be used to set the user of the <code>usertag</code>. -</dd> - -<dt><a name="usercategory"><code>usercategory</code> - <var>category-name</var> [ <code>[hidden]</code> ]</a></dt> -<dd> -<p> -Adds, updates or removes a <code>usercategory</code>. By default the user -category is visible, if the optional argument <code>[hidden]</code> -is specified then it will not be visible, but still be available to be -referenced from other user category definitions. -</p> - -<p> -This command is somewhat special, as when adding or updating a user -category it requires a body following immediately after the command. If -the body is empty the user category will get removed instead. The body -is composed of lines starting with any number of spaces. Each category -should start with a line with <code>*</code>, and optionally it can be -followed by several selection lines starting with <code>+</code>. The -complete format is as follows: -</p> - -<div> -* <var>category-name-1</var><br /> -* <var>Category Title 2</var> - [ <code>[</code><var>selection-prefix</var><code>]</code> ]<br /> - + <var>Selection Title 1</var> <code>[</code> - [ <var>order</var><code>:</code> ] - <var>selection-1</var> <code>]</code><br /> - + <var>Selection Title 2</var> <code>[</code> - [ <var>order</var><code>:</code> ] - <var>selection-2</var> <code>]</code><br /> - + <var>Default Selection Title</var> <code>[</code> - [ <var>order</var>: ] <code>]</code><br /> -* <var>category-name-3</var><br /> -</div> - -<p> -The <var>category-names</var> appearing in the command and in the body -are used to make references between them, to avoid unnecessary inlining. -The <var>Category Titles</var> are used in the package report summary. -</p> - -<p> -The optional <var>selection-prefix</var> is prefixed to every -<var>selection</var> on each entry in the category section. The first -<var>selection</var> which matches gets the bug shown under it. The -optional <var>order</var> parameter specifies the position when showing -the selected entries, this is useful when using a match that selects a -superset of the previous ones but that needs to be shown before them. -</p> - -<p> -The <var>category-name</var> <code>normal</code> has the special meaning -of being the default view, so by replacing it with a different user category -for the <var>pkgname</var>@packages.debian.org user one can change the -default classification for a package. -</p> - -<p> -Example usage: -</p> - -<pre> - usercategory dpkg-program [hidden] - * Program - + dpkg-deb [tag=dpkg-deb] - + dpkg-query [tag=dpkg-query] - + dselect [package=dselect] - - usercategory new-status [hidden] - * Status [pending=] - + Outstanding with Patch Available [0:pending+tag=patch] - + Outstanding and Confirmed [1:pending+tag=confirmed] - + Outstanding and More Information Needed [pending+tag=moreinfo] - + Outstanding and Forwarded [pending+tag=forwarded] - + Outstanding but Will Not Fix [pending+tag=wontfix] - + Outstanding and Unclassified [2:pending] - + From other Branch [absent] - + Pending Upload [pending-fixed] - + Fixed in NMU [fixed] - + Resolved [done] - + Unknown Pending Status [] - - \# Change default view - usercategory normal - * new-status - * severity - - usercategory old-normal - * status - * severity - * classification -</pre> -</dd> - -<dt><code>help</code></dt> -<dd> -Requests that this help document be sent by email in plain ASCII. -</dd> - -<dt><a name="stopprocessing"></a><code>quit</code></dt> -<dt><code>stop</code></dt> -<dt><code>thank</code></dt> -<dt><code>thanks</code></dt> -<dt><code>thankyou</code></dt> -<dt><code>thank you</code></dt> -<dt><code>--</code></dt> -<!-- #366093, I blame you! --> -<!-- <dt><code>kthxbye</code></dt> --> -<!-- See... I documented it! --> -<dd> -Stops processing at this point of the message. After this you may -include any text you like, and it will be ignored. You can use this -to include longer comments than are suitable for <code>#</code>, for -example for the benefit of human readers of your message (reading it -via the tracking system logs or due to a <code>CC</code> or -<code>BCC</code>). -</dd> - -<dt><code>#</code>...</dt> -<dd> -One-line comment. The <code>#</code> must be at the start of the -line. -</dd> - -<dt><code>debug</code> <var>level</var></dt> -<dd> -Sets the debugging level to <var>level</var>, which should be a -nonnegative integer. 0 is no debugging; 1 is usually sufficient. The -debugging output appears in the transcript. It is not likely to be -useful to general users of the bug system. -</dd> - -</dl> - -<p>There is a <a href="server-refcard">reference card</a> for the -mailservers, available via the WWW, in -<code>bug-mailserver-refcard.txt</code> or by email using the -<code>refcard</code> command (see above).</p> - -<p>If you wish to manipulate bug reports you should use the -<code>control@bugs.debian.org</code> address, which understands a -<a href="server-control">superset of the commands listed -above</a>. This is described in another document, available on the -<a href="server-control">WWW</a>, -in the file <code>bug-maint-mailcontrol.txt</code>, or by -sending <code>help</code> to <code>control@bugs.debian.org</code>.</p> - -<p>In case you are reading this as a plain text file or via email: an -HTML version is available via the bug system main contents page -<code>https://www.debian.org/Bugs/</code>.</p> - -<hr /> - -#use "otherpages.inc" - -#use "$(ENGLISHDIR)/Bugs/footer.inc" |