|
|
15.
|
|
|
While the test script can be easily executed on its own, it is strongly recommended to actually use ``autopkgtest`` from the ``autopkgtest`` package for verifying that your test works; otherwise, if it fails in the Ubuntu Continuous Integration (CI) system, it will not land in Ubuntu. This also avoids cluttering your workstation with test packages or test configuration if the test does something more intrusive than the simple example above.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:84
|
|
|
16.
|
|
|
The `README.running-tests <running_tests_local_>`_ (`online version <DEP8_>`_) documentation explains all available testbeds (schroot, LXD, QEMU, etc.) and the most common scenarios how to run your tests with ``autopkgtest``, e. g. with locally built binaries, locally modified tests, etc.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:91
|
|
|
21.
|
|
|
The Ubuntu CI system runs packages with only selected packages from ``-proposed`` available (the package which caused the test to be run); to enable that, run::
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:115
|
|
|
22.
|
|
|
or to run with all packages from ``-proposed``::
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:121
|
|
|
23.
|
|
|
The ``autopkgtest`` manpage has a lot more valuable information on other testing options.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:125
|
|
|
32.
|
|
|
Debian also uses ``autopkgtest`` to run package tests, although currently only in schroots, so results may vary a bit. Results and logs can be seen on http://ci.debian.net. So please submit any test fixes or new tests to Debian as well.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:153
|
|
|
153.
|
|
|
Take a look at `the bitesize bugs`_ in Launchpad, and that might give you an idea of something to work on. It might also interest you to look at the bugs `triaged`_ by the Ubuntu One Hundred Papercuts team.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/fixing-a-bug.rst:26
|
|
|
156.
|
|
|
Let's say you've found a bug in Bumprace, a racing game. The Bumprace application can be started by running ``/usr/bin/bumprace`` on the command line. To find the binary package containing this application, use this command::
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/fixing-a-bug.rst:41
|
|
|
158.
|
|
|
Note that the part preceding the colon is the binary package name. It's often the case that the source package and binary package will have different names. This is most common when a single source package is used to build multiple different binary packages. To find the source package for a particular binary package, type::
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/fixing-a-bug.rst:51
|
|
|
161.
|
|
|
Once you have figured out which package the problem is in, it's time to confirm that the problem exists.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/fixing-a-bug.rst:67
|
