Adding debian version 3.0~a1-1.

1 files changed, 0 insertions, 391 deletions

diff --git a/includes/lenny/common/doc/bug-maint-mailcontrol.txt b/includes/lenny/common/doc/bug-maint-mailcontrol.txt
deleted file mode 100644
index 56ddd08c0..000000000
--- a/includes/lenny/common/doc/bug-maint-mailcontrol.txt
+++ /dev/null
@@ -1,391 +0,0 @@
-Introduction to the bug control and manipulation mailserver
-
-   Just as request@bugs.debian.org allows the retrieval of bug data and
-   documentation by email, control@bugs.debian.org allows bug reports to
-   be manipulated in various ways.
-
-   The control server works just like the request server, except that it
-   has some additional commands; in fact, it's the same program. The two
-   addresses are only separated to avoid users making mistakes and
-   causing problems while merely trying to request information.
-
-   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.
-
-   Please see the introduction to the request server available on the
-   World Wide Web, in the file bug-log-mailserver.txt, or by sending help
-   to either mailserver, for details of the basics of operating the
-   mailservers and the common commands available when mailing either
-   address.
-
-   The reference card for the mailservers is available via the WWW, in
-   bug-mailserver-refcard.txt or by email using the refcard command.
-
-Commands available at the control mailserver
-
-                    General     Versioning Duplicates Misc.
-
-   reassign
-   severity
-   tag
-   retitle
-   submitter
-
-   found | notfound
-   fixed | notfixed
-   reopen
-
-   merge | unmerge
-   forcemerge
-   clone
-
-   thanks
-   #
-   forwarded | notforwarded
-   owner | noowner
-   block | unblock
-   archive | unarchive
-
-   reassign bugnumber package [ version ]
-          Records that bug #bugnumber is a bug in package. 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).
-
-          If you supply a version, the bug tracking system will note that
-          the bug affects that version of the newly-assigned package.
-
-          You can assign a bug to two packages at once by separating the
-          package names with a comma. However, you should only do this if
-          the bug can be fixed by a change to either package. If this is
-          not the case, you should clone the bug and reassign the clone
-          to the other package.
-
-   reopen bugnumber [ originator-address | = | ! ]
-          Reopens #bugnumber if it is closed.
-
-          By default, or if you specify =, the original submitter is
-          still as the originator of the report, so that they will get
-          the ack when it is closed again.
-
-          If you supply an originator-address the originator will be set
-          to the address you supply. If you wish to become the new
-          originator of the reopened report you can use the ! shorthand
-          or specify your own email address.
-
-          It is usually a good idea to tell the person who is about to be
-          recorded as the originator that you're reopening the report, so
-          that they will know to expect the ack which they'll get when it
-          is closed again.
-
-          If the bug is not closed then reopen won't do anything, not
-          even change the originator. To change the originator of an open
-          bug report, use the submitter command; note that this will
-          inform the original submitter of the change.
-
-          If the bug was recorded as being closed in a particular version
-          of a package but recurred in a later version, it is better to
-          use the found command instead.
-
-   found bugnumber [ version ]
-          Record that #bugnumber has been encountered in the given
-          version of the package to which it is assigned.
-
-          The bug tracking system uses this information, in conjunction
-          with fixed versions recorded when closing bugs, to display
-          lists of bugs open in various versions of each package. It
-          considers a bug to be open when it has no fixed version, or
-          when it has been found more recently than it has been fixed.
-
-          If no version is given, then the list of fixed versions for the
-          bug is cleared. This is identical to the behaviour of reopen.
-
-          This command will only cause a bug to be marked as not done if
-          no version is specified, or if the version being marked found
-          is equal to the version which was last marked fixed. (If you
-          are certain that you want the bug marked as not done, use
-          reopen in conjunction with found.)
-
-          This command was introduced in preference to reopen because it
-          was difficult to add a version to that command's syntax without
-          suffering ambiguity.
-
-   notfound bugnumber version
-          Remove the record that #bugnumber was encountered in the given
-          version of the package to which it is assigned.
-
-          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.
-
-   fixed bugnumber version
-          Indicate that bug #bugnumber was fixed in the given version of
-          the package to which it is assigned.
-
-          This does not 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.
-
-   notfixed bugnumber version
-          Remove the record that bug #bugnumber has been fixed in the
-          given version.
-
-          This command is equivalent to found followed by notfound (the
-          found removes the fixed at a particular version, and notfound
-          removes the found.)
-
-   submitter bugnumber originator-address | !
-          Changes the originator of #bugnumber to originator-address.
-
-          If you wish to become the new originator of the report you can
-          use the ! shorthand or specify your own email address.
-
-          While the reopen command changes the originator of other bugs
-          merged with the one being reopened, submitter does not affect
-          merged bugs.
-
-   forwarded bugnumber address
-          Notes that bugnumber has been forwarded to the upstream
-          maintainer at address. 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.
-
-   notforwarded bugnumber
-          Forgets any idea that bugnumber has been forwarded to any
-          upstream maintainer. If the bug was not recorded as having been
-          forwarded then this will do nothing.
-
-   retitle bugnumber new-title
-          Changes the title of a bug report to that specified (the
-          default is the Subject mail header from the original report).
-
-          Unlike most of the other bug-manipulation commands when used on
-          one of a set of merged reports this will change the title of
-          only the individual bug requested, and not all those with which
-          it is merged.
-
-   severity bugnumber severity
-          Set the severity level for bug report #bugnumber to severity.
-          No notification is sent to the user who reported the bug.
-
-          Severities are critical, grave, serious, important, normal,
-          minor, and wishlist.
-
-          For their meanings please consult the general developers'
-          documentation for the bug system.
-
-   clone bugnumber NewID [ new IDs ... ]
-          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. "New IDs"
-          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.
-
-          Example usage:
-
-          clone 12345 -1 -2
-          reassign -1 foo
-          retitle -1 foo: foo sucks
-          reassign -2 bar
-          retitle -2 bar: bar sucks when used with foo
-          severity -2 wishlist
-          clone 123456 -3
-          reassign -3 foo
-          retitle -3 foo: foo sucks
-          merge -1 -3
-
-   merge bugnumber bugnumber ...
-          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.
-
-          Before bugs can be merged they must be in exactly the same
-          state: either all open or all closed, with the same
-          forwarded-to upstream author address or all not marked as
-          forwarded, all assigned to the same package or package(s) (an
-          exact string comparison is done on the package to which the bug
-          is assigned), and all of the same severity. If they don't start
-          out in the same state you should use reassign, reopen and so
-          forth to make sure that they are before using merge. Titles are
-          not required to match, and will not be affected by the merge.
-          Tags are not required to match, either, they will be joined.
-
-          If any of the bugs listed in a merge command is already merged
-          with another bug then all the reports merged with any of the
-          ones listed will all be merged together. Merger is like
-          equality: it is reflexive, transitive and symmetric.
-
-          Merging reports causes a note to appear on each report's logs;
-          on the WWW pages this is includes links to the other bugs.
-
-          Merged reports are all expired simultaneously, and only when
-          all of the reports each separately meet the criteria for
-          expiry.
-
-   forcemerge bugnumber bugnumber ...
-          Forcibly merges two or more bug reports. The first bug listed
-          is the master bug, and its settings (the settings 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.
-
-          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.
-
-   unmerge bugnumber
-          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.
-
-          If many bug reports are merged and you wish to split them into
-          two separate groups of merged reports you must unmerge each
-          report in one of the new groups separately and then merge them
-          into the required new group.
-
-          You can only unmerge one report with each unmerge command; if
-          you want to disconnect more than one bug simply include several
-          unmerge commands in your message.
-
-   tags bugnumber [ + | - | = ] tag [ tag ... ]
-          Sets tags for the bug report #bugnumber. No notification is
-          sent to the user who reported the bug. Setting the action to +
-          means to add each given tag, - means to remove each given tag,
-          and = means to ignore the current tags and set them afresh to
-          the list provided. The default action is adding.
-
-          Example usage:
-
-          # same as 'tags 123456 + patch'
-          tags 123456 patch
-
-          # same as 'tags 123456 + help security'
-          tags 123456 help security
-
-          # add 'fixed' and 'pending' tags
-          tags 123456 + fixed pending
-
-          # remove 'unreproducible' tag
-          tags 123456 - unreproducible
-
-          # set tags to exactly 'moreinfo' and 'unreproducible'
-          tags 123456 = moreinfo unreproducible
-
-          Available tags currently include patch, wontfix, moreinfo,
-          unreproducible, help, pending, fixed, fixed-in-experimental,
-          fixed-upstream, security, upstream, confirmed, d-i, ipv6, lfs,
-          l10n, potato, woody, sarge, sarge-ignore, etch, etch-ignore,
-          lenny, lenny-ignore, squeeze, squeeze-ignore, sid, and
-          experimental.
-
-          For their meanings please consult the general developers'
-          documentation for the bug system.
-
-   block bugnumber by bug ...
-          Note that the fix for the first bug is blocked by the other
-          listed bugs.
-
-   unblock bugnumber by bug ...
-          Note that the fix for the first bug is no longer blocked by the
-          other listed bugs.
-
-   close bugnumber [ fixed-version ] (deprecated)
-          Close bug report #bugnumber.
-
-          A notification is sent to the user who reported the bug, but
-          (in contrast to mailing bugnumber-done@bugs.debian.org) the
-          text of the mail which caused the bug to be closed is not
-          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 how to close a bug properly.
-
-          If you supply a fixed-version, the bug tracking system will
-          note that the bug was fixed in that version of the package.
-
-   package [ packagename ... ]
-          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.
-
-          Example usage:
-
-          package foo
-          reassign 123456 bar 1.0-1
-
-          package bar
-          retitle 123456 bar: bar sucks
-          severity 123456 normal
-
-          package
-          severity 234567 wishlist
-
-   owner bugnumber address | !
-          Sets address to be the "owner" of #bugnumber. 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.
-
-          If you wish to become the owner of the bug yourself, you can
-          use the ! shorthand or specify your own email address.
-
-   noowner bugnumber
-          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.
-
-   archive bugnumber
-          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.
-
-   unarchive bugnumber
-          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.
-
-   #...
-          One-line comment. The # must be at the start of the line. The
-          text of comments will be included in the acknowledgement sent
-          to the sender and to affected maintainers, so you can use this
-          to document the reasons for your commands.
-
-   quit
-   stop
-   thank
-   thanks
-   thankyou
-   thank you
-   --
-          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.
-     _________________________________________________________________
-
-    Debian BTS administrators <owner@bugs.debian.org>
-
-   Debian bug tracking system
-   Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
-   1994-1997 Ian Jackson.
-     _________________________________________________________________
-