diff options
| author | galaxico <galaxico@quteity.cti> | 2019-07-27 17:31:01 +0300 |
|---|---|---|
| committer | galaxico <galaxico@quteity.cti> | 2019-07-27 17:31:01 +0300 |
| commit | d1faaff4691ce303281aef03d4cd89f53a855b5d (patch) | |
| tree | 8097dd5945647c26d798666e6b3edfef93275954 /greek/Bugs | |
| parent | a4b1a79838b5e9dae7d6fef4ea3882c245e3421a (diff) | |
additions to Greek translations
Diffstat (limited to 'greek/Bugs')
| -rw-r--r-- | greek/Bugs/Access.wml | 61 | ||||
| -rw-r--r-- | greek/Bugs/Developer.wml | 466 | ||||
| -rw-r--r-- | greek/Bugs/Makefile | 1 | ||||
| -rw-r--r-- | greek/Bugs/Reporting.wml | 502 | ||||
| -rw-r--r-- | greek/Bugs/index.wml | 184 | ||||
| -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 |
9 files changed, 2381 insertions, 0 deletions
diff --git a/greek/Bugs/Access.wml b/greek/Bugs/Access.wml new file mode 100644 index 00000000000..26f184b39a4 --- /dev/null +++ b/greek/Bugs/Access.wml @@ -0,0 +1,61 @@ +#use wml::debian::template title="Debian BTS — access methods" NOHEADER=yes NOCOPYRIGHT=true +#use wml::debian::translation-check translation="0c51b8ff34c17868bd2f86ac91fef7abc581e1e9" 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>At the time of writing, the active spool is about 2.5GB and the archived +spool is about 10GB. 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 new file mode 100644 index 00000000000..75f6be9b973 --- /dev/null +++ b/greek/Bugs/Developer.wml @@ -0,0 +1,466 @@ +#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="859f960fa633147bac5504a51b2e29800627217a" 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. 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 is relevant to the accessibility of the 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/Makefile b/greek/Bugs/Makefile new file mode 100644 index 00000000000..c26323c0c92 --- /dev/null +++ b/greek/Bugs/Makefile @@ -0,0 +1 @@ +include $(subst webwml/greek,webwml/english,$(CURDIR))/Makefile diff --git a/greek/Bugs/Reporting.wml b/greek/Bugs/Reporting.wml new file mode 100644 index 00000000000..842abac2dc2 --- /dev/null +++ b/greek/Bugs/Reporting.wml @@ -0,0 +1,502 @@ +#use wml::debian::template title="Debian BTS - reporting bugs" NOHEADER=yes NOCOPYRIGHT=true +#use wml::debian::translation-check translation="202593fcedf9621040700a1fa80a3754a8fd1cf5" 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="http://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> + +<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: forward -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/index.wml b/greek/Bugs/index.wml new file mode 100644 index 00000000000..ba167a22939 --- /dev/null +++ b/greek/Bugs/index.wml @@ -0,0 +1,184 @@ +#use wml::debian::template title="Debian bug tracking system" BARETITLE=true NOCOPYRIGHT=true +#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc" +#{#style#:<link rel="stylesheet" href="https://bugs.debian.org/css/bugs.css" type="text/css">:##} +#use wml::debian::translation-check translation="07162807462d48f6282cbf61386e273d9a8544fd" maintainer="galaxico" +{#meta#: +<script type="text/javascript" src="hashbug_redirect.js"></script> +:#meta#} + +<p>Debian has a bug tracking system (BTS) in which we file +details of bugs reported by users and developers. Each bug is given a +number, and is kept on file until it is marked as having been dealt +with.</p> + +<h2>How to report a bug in Debian</h2> + +<p>A separate page has instructions and tips on <a href="Reporting">how to +report a bug</a> if you encounter problems in the Debian distribution.</p> + +<h2>Bug tracking system documentation</h2> + +<ul> + <li><a href="Developer">Advanced information on how to use the system</a></li> + <li><a href="server-control">Information on manipulating bugs by email</a></li> + <li><a href="server-refcard">Mailservers' reference card</a></li> + <li><a href="Access">Ways of accessing the bug report logs</a></li> + <li><a href="server-request">Requesting bug reports by email</a></li> +</ul> + +<h2>Viewing bug reports on the WWW</h2> + +<p style="text-align:center"> +<img src="https://qa.debian.org/data/bts/graphs/all.png?m=0.8&h=250&w=600" +alt="Bug count for all" /> +</p> + +<p>Find a bug by <strong>number</strong>: + <br /> + <a name="bugreport"></a> + <form method="get" action="https://bugs.debian.org/cgi-bin/bugreport.cgi"> + <p> + <input type="text" size="9" name="bug" value=""> + <label><input type="checkbox" name="mbox" value="yes"> as mbox</label> + <label><input type="checkbox" name="trim" value="no"> show all headers</label> + <label><input type="checkbox" name="boring" value="yes"> show boring messages</label> + <input type="submit" value="Find"> + </p> + </form> + +<h2>Select bug reports on the WWW</h2> +<a name="pkgreport"></a> + +<bts_main_form> + +<table class="forms"> + +<tr><td><h2>Select bugs</h2> +</td> +<td> +<bts_select_form> +</td> +<td> +<p>More selections can be added after the first search. If a later selection + is on the same search field, the results are ORed. If it is on a different + field, the results are ANDed.</p> +<p>Valid severities are <bts_severities_all>.</p> +<p>Valid tags are <bts_tags>.</p> +</td> +</tr> + +<tr><td><h2>Include Bugs</h2></td> +<td> +<bts_include_form> +</td> +<td> +</td> +</tr> + +<tr><td><h2>Exclude Bugs</h2></td> +<td> +<bts_exclude_form> +</td> +<td></td> +</tr> + +<tr><td><h2>Categorize using</h2></td> +<td></td> +</tr> +<tr><td><h2>Order by</h2></td> +<td> +<bts_orderby_form> +</td> +<td></td> +</tr> + +<tr><td><h2>Misc options</h2></td> +<td> +<bts_miscopts_form> +</td> +</tr> + +<tr><td><h2>Submit</h2></td><td colspan=2> +<input type="submit" name="submit" value="Submit"> +</td></tr> + +</table> +</form> + +<p>The above queries can also be made by visiting URLs of the following +forms, respectively:</p> +<ul> + <li><tt>https://bugs.debian.org/<var>number</var></tt></li> + <li><tt>https://bugs.debian.org/mbox:<var>number</var></tt></li> + <li><tt>https://bugs.debian.org/<var>package</var></tt></li> + <li><tt>https://bugs.debian.org/src:<var>sourcepackage</var></tt></li> + <li><tt>https://bugs.debian.org/<var>maintainer@email.address</var></tt></li> + <li><tt>https://bugs.debian.org/from:<var>submitter@email.address</var></tt></li> + <li><tt>https://bugs.debian.org/severity:<var>severity</var></tt></li> + <li><tt>https://bugs.debian.org/tag:<var>tag</var></tt></li> +</ul> + +<h2>Searching bug reports</h2> + +## Link to bugs-search.d.o removed because of Bug#629645 (service down): +# <p>You can search bug reports using +# our <a href="https://bugs.debian.org/cgi-bin/search.cgi">HyperEstraier +# based search engine.</a></p> + +<p>The Ultimate Debian Database (UDD) provides a multi-criteria +<a href="https://udd.debian.org/bugs/">search engine for bugs</a>.</p> + +<p>Another way to search bug reports is to use +<a href="https://groups.google.com/d/forum/linux.debian.bugs.dist">Google Groups</a>. +The period to be searched can be limited by using the +<a href="https://groups.google.com/d/search/group%3Alinux.debian.bugs.dist">\ +advanced search</a> option.</p> + +<p>Alternative sites that allow searching for bug reports include +<a href="http://www.mail-archive.com/debian-bugs-dist%40lists.debian.org/">The +Mail Archive</a>.</p> + +<h2>Supplementary information</h2> + +<p>The current list of <a href="https://bugs.debian.org/release-critical/"> +Release Critical Bugs</a>.</p> + +<p>The current list of <a href="pseudo-packages">pseudo-packages</a> +recognized by the Debian bug tracking system.</p> + +<p>The following bug report indices are available:</p> + +<ul> + <li>Packages with + <a href="https://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=pkg">active</a> + and + <a href="https://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=pkg&archive=yes">archived</a> + bug reports.</li> + <li>Source packages with + <a href="https://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=src">active</a> + and + <a href="https://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=src&archive=yes">archived</a> + bug reports.</li> + <li>Maintainers of packages with + <a href="https://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=maint">active</a> + and + <a href="https://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=maint&archive=yes">archived</a> + bug reports.</li> + <li>Submitters of + <a href="https://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=submitter">active</a> + and + <a href="https://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=submitter&archive=yes">archived</a> + bug reports.</li> +</ul> + +<p><strong>Note:</strong> some of the previously available indices of bug +reports aren't available due to internal problems with the program that +generated them. We apologize for the inconvenience.</p> + +<h2>Spam Reports</h2> +<p>The Bug Tracking system often receives spam. To report spam in the + bug tracking system, find the bug report <a href="#bugreport">by + number</a>, and click "this bug log contains spam" near the + bottom.</p> + +#include "$(ENGLISHDIR)/Bugs/footer.inc" diff --git a/greek/Bugs/pseudo-packages.wml b/greek/Bugs/pseudo-packages.wml new file mode 100644 index 00000000000..f2b5f05c05f --- /dev/null +++ b/greek/Bugs/pseudo-packages.wml @@ -0,0 +1,25 @@ +#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 new file mode 100644 index 00000000000..bf6f9f6bffb --- /dev/null +++ b/greek/Bugs/server-control.wml @@ -0,0 +1,751 @@ +#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="af6db568fa508f5c59388f1ddb1a44165e40a276" 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> 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 is 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. 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 new file mode 100644 index 00000000000..7fd37ff0f08 --- /dev/null +++ b/greek/Bugs/server-refcard.wml @@ -0,0 +1,94 @@ +#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="d57880fc68c4033938ec5f4b76af957cf31ea743" 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>tag</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 new file mode 100644 index 00000000000..8018a97883d --- /dev/null +++ b/greek/Bugs/server-request.wml @@ -0,0 +1,297 @@ +#use wml::debian::template title="Debian BTS - request server" NOHEADER=yes NOCOPYRIGHT=true +#use wml::debian::translation-check translation="8da95139c3595d47371ba8d288784086ae2ebacd" 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</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" |