|
|
2.
|
|
|
The `DEP 8 specification <DEP8_>`_ defines how automatic testing can very easily be integrated into packages. To integrate a test into a package, all you need to do is:
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:5
|
|
|
6.
|
|
|
In ``debian/tests/control`` you specify what to expect from the testbed. So for example you list all the required packages for the tests, if the testbed gets broken during the build or if ``root`` permissions are required. The `DEP 8 specification <DEP8_>`_ lists all available options.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:17
|
|
|
18.
|
|
|
Now build a testbed with::
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/auto-pkg-test.rst:103
|
|
|
122.
|
|
|
When a source package is producing multiple binary packages ``dh`` will install the files into ``debian/tmp`` rather than directly into ``debian/<package>``. Files installed into ``debian/tmp`` can then be moved into separate binary packages using multiple ``$package_name.install`` files. This is often done to split large amounts of architecture independent data out of architecture dependent packages and into ``Architecture: all`` packages. In this case, only the name of the files (or directories) to be installed are needed without the installation directory. For example, ``foo.install`` containing only the architecture dependent files might look like::
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/debian-dir-overview.rst:268
|
|
|
171.
|
|
|
The problem we are working on is special as it only concerns the packaging-related bits of ``bumprace``. If it was a problem in the source code it would be helpful to also check the Upstream bug tracker. This is unfortunately often different for every package you have a look at, but if you search the web for it, you should in most cases find it pretty easily.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/fixing-a-bug.rst:131
|
|
|
201.
|
|
|
In our (very sparse) example the last point is covered by ``(LP: #123456)`` which refers to Launchpad bug 123456. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the ``LP: #<number>`` notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/fixing-a-bug.rst:252
|
|
|
209.
|
|
|
In a lot of cases you will have to actually install the package to make sure it works as expected. Our case is a lot easier. If the build succeeded, you will find the binary packages in ``~/pbuilder/<release>_result``. Install them via ``sudo dpkg -i <package>.deb`` or by double-clicking on them in your file manager.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/fixing-a-bug.rst:296
|
|
|
257.
|
|
|
Don't want to install the latest development version of Ubuntu? Spin up an `LXD container <https://help.ubuntu.com/lts/serverguide/lxd.html>`_.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/getting-set-up.rst:26
|
|
|
259.
|
|
|
There are a number of tools that will make your life as an Ubuntu developer much easier. You will encounter these tools later in this guide. To install most of the tools you will need run this command::
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/getting-set-up.rst:32
|
|
|
261.
|
|
|
``gnupg`` -- `GNU Privacy Guard <GPG_>`_ contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad.
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
../ubuntu-packaging-guide/getting-set-up.rst:41
|
