[Reportbug-commits] r655 - in trunk (9 files)
morph-guest at users.alioth.debian.org
morph-guest at users.alioth.debian.org
Sat Sep 13 23:03:36 UTC 2008
Date: Saturday, September 13, 2008 @ 23:03:35
Author: morph-guest
Revision: 655
* doc/README.*, debian/docs
- moved README.* files under doc/ dir
Added:
trunk/doc/
trunk/doc/README.Users
(from rev 641, trunk/README.Users)
trunk/doc/README.developers
(from rev 641, trunk/README.developers)
trunk/doc/README.source
(from rev 641, trunk/README.source)
Modified:
trunk/debian/changelog
trunk/debian/docs
Deleted:
trunk/README.Users
trunk/README.developers
trunk/README.source
Deleted: trunk/README.Users
===================================================================
--- trunk/README.Users 2008-09-13 22:08:37 UTC (rev 654)
+++ trunk/README.Users 2008-09-13 23:03:35 UTC (rev 655)
@@ -1,37 +0,0 @@
-===============================
-reportbug Information for Users
-===============================
-
-How to use GMail SMTP server
-============================
-
-You have to set these variables in ~/.reportbugrc file:
-
-smtphost smtp.googlemail.com:587
-smtpuser "<your address>@gmail.com"
-smtptls
-
-Thanks to: Raphael Geissert <atomo64 at gmail.com>
-
-How to Usertags a Bug at Report Time
-====================================
-
-If you're filing a bug and you what to usertag it, you can add these
-lines (in the pseudo-header)
-
-User: <user email address>
-Usertags: <tag>
-
-right after
-
-Package: <package>
-Version: <version>
-Severity: <severity>
-
-lines in the bug body.
-
-Please note that if you specify more than 2 tag, then they will be
-ordered alphabetically (so if you use usercategories, it will only
-appears in the first one).
-
-Thanks to: Sandro Tosi <matrixhasu at gmail.com>
Deleted: trunk/README.developers
===================================================================
--- trunk/README.developers 2008-09-13 22:08:37 UTC (rev 654)
+++ trunk/README.developers 2008-09-13 23:03:35 UTC (rev 655)
@@ -1,208 +0,0 @@
-===================================
-reportbug's Features for Developers
-===================================
-
-(Adapted from original "bug" documentation.)
-
-Bug allows maintainers to control the bug reporting process by placing
-files in special places.
-
-Template Information & Interaction with the user
-================================================
-
-If /usr/share/bug/$package is executable, then bug executes it and
-takes what comes out from the file descriptor 3 and puts it in the bug
-template.
-
-The maintainer can then ask questions to the user or run whatever
-information gathering script he likes, and echo all the content to fd 3.
-
-e.g.::
-
- read -p 'color? '
- echo "Color: $REPLY" >&3
- ...
- system-information-tool >&3
-
-If /usr/share/bug/$package is a directory, then
-/usr/share/bug/$package/script is executed.
-
-While the script is executed, the following shell functions are
-available ONLY IF IT IS RUN UNDER /bin/bash::
-
- getkey - asks for a key
- yesno <prompt> "yep"|"nop" - ask for a yes/no answer (with i18n)
- leaves response as yep or nop
- in REPLY. The second argument is
- the default.
-
-If the file /usr/share/bug/$package/presubj exists, its content is
-shown to the user before asking him for the bug's subject.
-
-Note: It's your responsibility to check if the information included
-in the template can put the user in any security risk.
-
-Package redirection
-===================
-
-The package maintainer can control to which packages bug reports are
-submitted, by setting the Package: field of the bug report. This will
-be mainly used to redirect bugs in packages coming from a single
-source to where the maintainer likes to have them.
-
-This is done by having this line in /usr/share/bug/$package/control::
-
- Submit-As: $new-package
-
-Note that bug will not check if the $new-package exists as a valid package.
-
-BTS selection
-=============
-
-Packages not distributed by Debian can take advantage of this utility too.
-They just need to add a "send-to" header to the control file
-/usr/share/bug/$package/control::
-
- Send-To: bugs.myproject.com
-
-`bug' will add `submit@' `quiet@' or `maintonly@' to form the address the
-bug report mail is send to.
-
-(Note: you probably should use dpkg's support for Origin and Bugs tags
-in lieu of this support.)
-
-Nicolás Lichtmaier.-
-nick at debian.org
-
-Related packages
-================
-
-Often programs are distributed across several different packages, for
-example an upstream package 'foo' may be packaged in Debian as foo, libfoo,
-foo-common and foo-data. In such cases it can be useful to include related
-package information in bugreports, to minimise the need for 'moreinfo' requests
-to the submitter :) This is done by adding a "report-with" header to the
-control file::
-
- report-with: foo libfoo foo-common foo-data
-
-Package information will be added to the bug report for each extra package
-listed.
-
-You can also request that the status information for other packages
-(that are not dependencies or recommendations) be included with the
-report using the "package-status" header::
-
- package-status: bar baz
-
-Addendum: Languages other than SH
-=================================
-
-The script in /usr/share/bug/reportbug/script is an example of a bug
-handling script written in Python. You can also write bug handlers in
-many other languages that allow direct access to file descriptors,
-including Perl and C/C++.
-
-Note that the getkey and yesno functions are only available in scripts
-written using /bin/bash as their interpreter; for other shells or
-languages, you will need to write your own input parsing functions.
-
-Source layout
-=============
-
-The source tree for ``reportbug`` is organised this way:
-
-* Top level
-
- * Programs (e.g. ``reportbug``, ``querybts``, etc.).
-
- * Python library modules, used by the programs.
-
- * Manual pages.
-
-* Debian packaging
-
- * ``debian/`` contains the control files used to build the Debian
- source and binary packages.
-
-* `Unit testing framework`_
-
- * ``test/`` contains the unit test suite. Unit test modules are
- discovered and run using the ``nosetests`` program, and are named
- as ``test_*.py``.
-
-* ?? TODO: describe the purpose
-
- * ``checks/`` contains ???
-
-* Internationalisation and localisation
-
- * ``po4a/`` contains configuration and data for localisation of
- source files using the ``po4a`` tool.
-
-Unit testing framework
-======================
-
-The reportbug source package now has a unit testing framework.
-
-The directory ``test/`` contains unit test modules and supporting
-files. New unit test modules should be added to this directory and
-named ``test_*.py``.
-
-The unit test suite depends on the `python-nose` package being
-installed, to make the ``nosetests`` command available. The unit tests
-themselves can be written using either the `unittest` or `doctest`
-modules in the standard Python library.
-
-The `scaffold` module (from the ``test/scaffold.py`` file) contains
-some helper functionality for unit tests, including an extended
-`TestCase` class.
-
-``make`` targets for testing and quality checks
------------------------------------------------
-
-The following ``make`` targets are useful for testing and related
-tasks.
-
-* ``make test`` runs the unit test suite, preceded by a timestamp
- banner, and reports any test failures or "OK" if all tests pass.
-
-* ``make test-continuous`` starts a loop which clears the screen, runs
- ``make test``, then waits for any of the tests or source code to
- change, and starts the loop again.
-
- This is useful to run in a separate terminal during a development
- session, so that whenever a change is made the test suite will be
- run automatically. You might want to keep the window hidden while
- actually editing files, and only look at it when you've created or
- modified a file and want to check its effect on the test run.
-
- This uses the ``inotifywait`` command from the `inotify-tools`
- package to wait for `create` and `modify` events.
-
-* ``make coverage`` runs the test suite and collects test coverage
- information, then reports the current statement coverage of the test
- suite.
-
- This requires the `python-coverage` package to be installed. See its
- documentation for more about its operation.
-
-* ``make pyflakes`` runs the `pyflakes` static code checker on all
- Python files found in the project tree.
-
- This requires the `pyflakes` package to be installed. See its
- documentation for more about its operation.
-
-* ``make pylint`` runs the `pylint` code checker on all code modules
- and programs.
-
- This requires the `pylint` package to be installed. See its
- documentation for more about its operation.
-
-
-..
- Local Variables:
- coding: utf-8
- mode: rst
- End:
- vim: filetype=rst :
Deleted: trunk/README.source
===================================================================
--- trunk/README.source 2008-09-13 22:08:37 UTC (rev 654)
+++ trunk/README.source 2008-09-13 23:03:35 UTC (rev 655)
@@ -1,106 +0,0 @@
-Source layout
-=============
-
-The source tree for ``reportbug`` is organised this way:
-
-* Top level
-
- * Manual pages.
-
-* Debian packaging
-
- * ``debian/`` contains the control files used to build the Debian
- source and binary packages.
-
-* `Programs`_
-
- * ``bin/`` contains the end-user programs (e.g. ``reportbug``,
- ``querybts``).
-
-* `Libraries`_
-
- * ``reportbug/`` contains the Python library module package used by
- the programs.
-
-* `Unit testing framework`_
-
- * ``test/`` contains the unit test suite. Unit test modules are
- discovered and run using the ``nosetests`` program, and are named
- as ``test_*.py``.
-
-* `Internal checking framework`_
-
- * ``checks/`` contains various scripts that ensure reportbug's
- internals are up-to-date with the Debian BTS.
-
-* Internationalisation and localisation
-
- * ``po4a/`` contains configuration and data for localisation of
- source files using the ``po4a`` tool.
-
-Unit testing framework
-======================
-
-The reportbug source package now has a unit testing framework.
-
-The directory ``test/`` contains unit test modules and supporting
-files. New unit test modules should be added to this directory and
-named ``test_*.py``.
-
-The unit test suite depends on the `python-nose` package being
-installed, to make the ``nosetests`` command available. The unit tests
-themselves can be written using either the `unittest` or `doctest`
-modules in the standard Python library.
-
-The `scaffold` module (from the ``test/scaffold.py`` file) contains
-some helper functionality for unit tests, including an extended
-`TestCase` class.
-
-``make`` targets for testing and quality checks
------------------------------------------------
-
-The following ``make`` targets are useful for testing and related
-tasks.
-
-* ``make test`` runs the unit test suite, preceded by a timestamp
- banner, and reports any test failures or "OK" if all tests pass.
-
-* ``make test-continuous`` starts a loop which clears the screen, runs
- ``make test``, then waits for any of the tests or source code to
- change, and starts the loop again.
-
- This is useful to run in a separate terminal during a development
- session, so that whenever a change is made the test suite will be
- run automatically. You might want to keep the window hidden while
- actually editing files, and only look at it when you've created or
- modified a file and want to check its effect on the test run.
-
- This uses the ``inotifywait`` command from the `inotify-tools`
- package to wait for `create` and `modify` events.
-
-* ``make coverage`` runs the test suite and collects test coverage
- information, then reports the current statement coverage of the test
- suite.
-
- This requires the `python-coverage` package to be installed. See its
- documentation for more about its operation.
-
-* ``make pyflakes`` runs the `pyflakes` static code checker on all
- Python files found in the project tree.
-
- This requires the `pyflakes` package to be installed. See its
- documentation for more about its operation.
-
-* ``make pylint`` runs the `pylint` code checker on all code modules
- and programs.
-
- This requires the `pylint` package to be installed. See its
- documentation for more about its operation.
-
-
-..
- Local Variables:
- coding: utf-8
- mode: rst
- End:
- vim: filetype=rst :
Modified: trunk/debian/changelog
===================================================================
--- trunk/debian/changelog 2008-09-13 22:08:37 UTC (rev 654)
+++ trunk/debian/changelog 2008-09-13 23:03:35 UTC (rev 655)
@@ -53,8 +53,10 @@
* checks/compare_pseudo-pkgs_lists.py
- updated location of canonical pseudo-packages list from ftpmaster to
bugs.d.o; thanks to Josip Rodin for the patch; Closes: #498663
+ * doc/README.*, debian/docs
+ - moved README.* files under doc/ dir
- -- Sandro Tosi <matrixhasu at gmail.com> Sat, 13 Sep 2008 23:59:46 +0200
+ -- Sandro Tosi <matrixhasu at gmail.com> Sun, 14 Sep 2008 01:02:57 +0200
reportbug (3.45) unstable; urgency=low
Modified: trunk/debian/docs
===================================================================
--- trunk/debian/docs 2008-09-13 22:08:37 UTC (rev 654)
+++ trunk/debian/docs 2008-09-13 23:03:35 UTC (rev 655)
@@ -1,3 +1,4 @@
-README.developers
-README.Users
+doc/README.developers
+doc/README.Users
+doc/README.source
TODO
Copied: trunk/doc/README.Users (from rev 641, trunk/README.Users)
===================================================================
--- trunk/doc/README.Users (rev 0)
+++ trunk/doc/README.Users 2008-09-13 23:03:35 UTC (rev 655)
@@ -0,0 +1,37 @@
+===============================
+reportbug Information for Users
+===============================
+
+How to use GMail SMTP server
+============================
+
+You have to set these variables in ~/.reportbugrc file:
+
+smtphost smtp.googlemail.com:587
+smtpuser "<your address>@gmail.com"
+smtptls
+
+Thanks to: Raphael Geissert <atomo64 at gmail.com>
+
+How to Usertags a Bug at Report Time
+====================================
+
+If you're filing a bug and you what to usertag it, you can add these
+lines (in the pseudo-header)
+
+User: <user email address>
+Usertags: <tag>
+
+right after
+
+Package: <package>
+Version: <version>
+Severity: <severity>
+
+lines in the bug body.
+
+Please note that if you specify more than 2 tag, then they will be
+ordered alphabetically (so if you use usercategories, it will only
+appears in the first one).
+
+Thanks to: Sandro Tosi <matrixhasu at gmail.com>
Property changes on: trunk/doc/README.Users
___________________________________________________________________
Name: svn:mergeinfo
+
Copied: trunk/doc/README.developers (from rev 641, trunk/README.developers)
===================================================================
--- trunk/doc/README.developers (rev 0)
+++ trunk/doc/README.developers 2008-09-13 23:03:35 UTC (rev 655)
@@ -0,0 +1,208 @@
+===================================
+reportbug's Features for Developers
+===================================
+
+(Adapted from original "bug" documentation.)
+
+Bug allows maintainers to control the bug reporting process by placing
+files in special places.
+
+Template Information & Interaction with the user
+================================================
+
+If /usr/share/bug/$package is executable, then bug executes it and
+takes what comes out from the file descriptor 3 and puts it in the bug
+template.
+
+The maintainer can then ask questions to the user or run whatever
+information gathering script he likes, and echo all the content to fd 3.
+
+e.g.::
+
+ read -p 'color? '
+ echo "Color: $REPLY" >&3
+ ...
+ system-information-tool >&3
+
+If /usr/share/bug/$package is a directory, then
+/usr/share/bug/$package/script is executed.
+
+While the script is executed, the following shell functions are
+available ONLY IF IT IS RUN UNDER /bin/bash::
+
+ getkey - asks for a key
+ yesno <prompt> "yep"|"nop" - ask for a yes/no answer (with i18n)
+ leaves response as yep or nop
+ in REPLY. The second argument is
+ the default.
+
+If the file /usr/share/bug/$package/presubj exists, its content is
+shown to the user before asking him for the bug's subject.
+
+Note: It's your responsibility to check if the information included
+in the template can put the user in any security risk.
+
+Package redirection
+===================
+
+The package maintainer can control to which packages bug reports are
+submitted, by setting the Package: field of the bug report. This will
+be mainly used to redirect bugs in packages coming from a single
+source to where the maintainer likes to have them.
+
+This is done by having this line in /usr/share/bug/$package/control::
+
+ Submit-As: $new-package
+
+Note that bug will not check if the $new-package exists as a valid package.
+
+BTS selection
+=============
+
+Packages not distributed by Debian can take advantage of this utility too.
+They just need to add a "send-to" header to the control file
+/usr/share/bug/$package/control::
+
+ Send-To: bugs.myproject.com
+
+`bug' will add `submit@' `quiet@' or `maintonly@' to form the address the
+bug report mail is send to.
+
+(Note: you probably should use dpkg's support for Origin and Bugs tags
+in lieu of this support.)
+
+Nicolás Lichtmaier.-
+nick at debian.org
+
+Related packages
+================
+
+Often programs are distributed across several different packages, for
+example an upstream package 'foo' may be packaged in Debian as foo, libfoo,
+foo-common and foo-data. In such cases it can be useful to include related
+package information in bugreports, to minimise the need for 'moreinfo' requests
+to the submitter :) This is done by adding a "report-with" header to the
+control file::
+
+ report-with: foo libfoo foo-common foo-data
+
+Package information will be added to the bug report for each extra package
+listed.
+
+You can also request that the status information for other packages
+(that are not dependencies or recommendations) be included with the
+report using the "package-status" header::
+
+ package-status: bar baz
+
+Addendum: Languages other than SH
+=================================
+
+The script in /usr/share/bug/reportbug/script is an example of a bug
+handling script written in Python. You can also write bug handlers in
+many other languages that allow direct access to file descriptors,
+including Perl and C/C++.
+
+Note that the getkey and yesno functions are only available in scripts
+written using /bin/bash as their interpreter; for other shells or
+languages, you will need to write your own input parsing functions.
+
+Source layout
+=============
+
+The source tree for ``reportbug`` is organised this way:
+
+* Top level
+
+ * Programs (e.g. ``reportbug``, ``querybts``, etc.).
+
+ * Python library modules, used by the programs.
+
+ * Manual pages.
+
+* Debian packaging
+
+ * ``debian/`` contains the control files used to build the Debian
+ source and binary packages.
+
+* `Unit testing framework`_
+
+ * ``test/`` contains the unit test suite. Unit test modules are
+ discovered and run using the ``nosetests`` program, and are named
+ as ``test_*.py``.
+
+* ?? TODO: describe the purpose
+
+ * ``checks/`` contains ???
+
+* Internationalisation and localisation
+
+ * ``po4a/`` contains configuration and data for localisation of
+ source files using the ``po4a`` tool.
+
+Unit testing framework
+======================
+
+The reportbug source package now has a unit testing framework.
+
+The directory ``test/`` contains unit test modules and supporting
+files. New unit test modules should be added to this directory and
+named ``test_*.py``.
+
+The unit test suite depends on the `python-nose` package being
+installed, to make the ``nosetests`` command available. The unit tests
+themselves can be written using either the `unittest` or `doctest`
+modules in the standard Python library.
+
+The `scaffold` module (from the ``test/scaffold.py`` file) contains
+some helper functionality for unit tests, including an extended
+`TestCase` class.
+
+``make`` targets for testing and quality checks
+-----------------------------------------------
+
+The following ``make`` targets are useful for testing and related
+tasks.
+
+* ``make test`` runs the unit test suite, preceded by a timestamp
+ banner, and reports any test failures or "OK" if all tests pass.
+
+* ``make test-continuous`` starts a loop which clears the screen, runs
+ ``make test``, then waits for any of the tests or source code to
+ change, and starts the loop again.
+
+ This is useful to run in a separate terminal during a development
+ session, so that whenever a change is made the test suite will be
+ run automatically. You might want to keep the window hidden while
+ actually editing files, and only look at it when you've created or
+ modified a file and want to check its effect on the test run.
+
+ This uses the ``inotifywait`` command from the `inotify-tools`
+ package to wait for `create` and `modify` events.
+
+* ``make coverage`` runs the test suite and collects test coverage
+ information, then reports the current statement coverage of the test
+ suite.
+
+ This requires the `python-coverage` package to be installed. See its
+ documentation for more about its operation.
+
+* ``make pyflakes`` runs the `pyflakes` static code checker on all
+ Python files found in the project tree.
+
+ This requires the `pyflakes` package to be installed. See its
+ documentation for more about its operation.
+
+* ``make pylint`` runs the `pylint` code checker on all code modules
+ and programs.
+
+ This requires the `pylint` package to be installed. See its
+ documentation for more about its operation.
+
+
+..
+ Local Variables:
+ coding: utf-8
+ mode: rst
+ End:
+ vim: filetype=rst :
Property changes on: trunk/doc/README.developers
___________________________________________________________________
Name: svn:mergeinfo
+
Copied: trunk/doc/README.source (from rev 641, trunk/README.source)
===================================================================
--- trunk/doc/README.source (rev 0)
+++ trunk/doc/README.source 2008-09-13 23:03:35 UTC (rev 655)
@@ -0,0 +1,106 @@
+Source layout
+=============
+
+The source tree for ``reportbug`` is organised this way:
+
+* Top level
+
+ * Manual pages.
+
+* Debian packaging
+
+ * ``debian/`` contains the control files used to build the Debian
+ source and binary packages.
+
+* `Programs`_
+
+ * ``bin/`` contains the end-user programs (e.g. ``reportbug``,
+ ``querybts``).
+
+* `Libraries`_
+
+ * ``reportbug/`` contains the Python library module package used by
+ the programs.
+
+* `Unit testing framework`_
+
+ * ``test/`` contains the unit test suite. Unit test modules are
+ discovered and run using the ``nosetests`` program, and are named
+ as ``test_*.py``.
+
+* `Internal checking framework`_
+
+ * ``checks/`` contains various scripts that ensure reportbug's
+ internals are up-to-date with the Debian BTS.
+
+* Internationalisation and localisation
+
+ * ``po4a/`` contains configuration and data for localisation of
+ source files using the ``po4a`` tool.
+
+Unit testing framework
+======================
+
+The reportbug source package now has a unit testing framework.
+
+The directory ``test/`` contains unit test modules and supporting
+files. New unit test modules should be added to this directory and
+named ``test_*.py``.
+
+The unit test suite depends on the `python-nose` package being
+installed, to make the ``nosetests`` command available. The unit tests
+themselves can be written using either the `unittest` or `doctest`
+modules in the standard Python library.
+
+The `scaffold` module (from the ``test/scaffold.py`` file) contains
+some helper functionality for unit tests, including an extended
+`TestCase` class.
+
+``make`` targets for testing and quality checks
+-----------------------------------------------
+
+The following ``make`` targets are useful for testing and related
+tasks.
+
+* ``make test`` runs the unit test suite, preceded by a timestamp
+ banner, and reports any test failures or "OK" if all tests pass.
+
+* ``make test-continuous`` starts a loop which clears the screen, runs
+ ``make test``, then waits for any of the tests or source code to
+ change, and starts the loop again.
+
+ This is useful to run in a separate terminal during a development
+ session, so that whenever a change is made the test suite will be
+ run automatically. You might want to keep the window hidden while
+ actually editing files, and only look at it when you've created or
+ modified a file and want to check its effect on the test run.
+
+ This uses the ``inotifywait`` command from the `inotify-tools`
+ package to wait for `create` and `modify` events.
+
+* ``make coverage`` runs the test suite and collects test coverage
+ information, then reports the current statement coverage of the test
+ suite.
+
+ This requires the `python-coverage` package to be installed. See its
+ documentation for more about its operation.
+
+* ``make pyflakes`` runs the `pyflakes` static code checker on all
+ Python files found in the project tree.
+
+ This requires the `pyflakes` package to be installed. See its
+ documentation for more about its operation.
+
+* ``make pylint`` runs the `pylint` code checker on all code modules
+ and programs.
+
+ This requires the `pylint` package to be installed. See its
+ documentation for more about its operation.
+
+
+..
+ Local Variables:
+ coding: utf-8
+ mode: rst
+ End:
+ vim: filetype=rst :
Property changes on: trunk/doc/README.source
___________________________________________________________________
Name: svn:mergeinfo
+
More information about the Reportbug-commits
mailing list