# Burmese translation for ubuntu-packaging-guide
# Copyright (c) 2013 Rosetta Contributors and Canonical Ltd 2013
# This file is distributed under the same license as the ubuntu-packaging-guide package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2013.
#
msgid ""
msgstr ""
"Project-Id-Version: ubuntu-packaging-guide\n"
"Report-Msgid-Bugs-To: FULL NAME <EMAIL@ADDRESS>\n"
"POT-Creation-Date: 2017-09-03 14:51-0500\n"
"PO-Revision-Date: 2013-07-14 19:43+0000\n"
"Last-Translator: Launchpad Translations Administrators <Unknown>\n"
"Language-Team: Burmese <my@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Launchpad-Export-Date: 2018-09-21 05:36+0000\n"
"X-Generator: Launchpad (build 18783)\n"

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:3
msgid "autopkgtest: Automatic testing for packages"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:5
msgid ""
"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:"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:9
msgid ""
"add a file called ``debian/tests/control`` which specifies the requirements "
"for the testbed,"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:11
msgid "add the tests in ``debian/tests/``."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:15
msgid "Testbed requirements"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:17
msgid ""
"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."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:22
msgid ""
"Below we are having a look at the ``glib2.0`` source package. In a very "
"simple case the file would look like this::"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:28
msgid ""
"For the test in ``debian/tests/build`` this would ensure that the packages "
"``libglib2.0-dev`` and ``build-essential`` are installed."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:31
msgid ""
"You can use ``@`` in the ``Depends`` line to indicate that you want all the "
"packages installed which are built by the source package in question."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:37
msgid "The actual tests"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:39
msgid "The accompanying test for the example above might be:"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:71
msgid ""
"Here a very simple piece of C code is written to a temporary directory. Then "
"this is compiled with system libraries (using flags and library paths as "
"provided by `pkg-config`). Then the compiled binary, which just exercises "
"some parts of core glib functionality, is run."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:76
msgid ""
"While this test is very small and simple, it covers quite a lot: that your -"
"dev package has all necessary dependencies, that your package installs "
"working pkg-config files, headers and libraries are put into the right "
"place, or that the compiler and linker work. This helps to uncover critical "
"issues early on."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:82
msgid "Executing the test"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:84
msgid ""
"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."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:91
msgid ""
"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."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:97
msgid ""
"The Ubuntu CI system uses the QEMU runner and runs the tests from the "
"packages in the archive, with ``-proposed`` enabled. To reproduce the exact "
"same environment, first install the necessary packages::"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:103
msgid "Now build a testbed with::"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:107
msgid ""
"(Please see its manpage and ``--help`` output for selecting different "
"releases, architectures, output directory, or using proxies). This will "
"build e. g. ``adt-trusty-amd64-cloud.img``."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:111
msgid ""
"Then run the tests of a source package like ``libpng`` in that QEMU image::"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:115
msgid ""
"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::"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:121
msgid "or to run with all packages from ``-proposed``::"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:125
msgid ""
"The ``autopkgtest`` manpage has a lot more valuable information on other "
"testing options."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:130
msgid "Further examples"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:132
msgid ""
"This list is not comprehensive, but might help you get a better idea of how "
"automated tests are implemented and used in Ubuntu."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:135
msgid ""
"The `libxml2 tests <libxml2_>`_ are very similar. They also run a test-build "
"of a simple piece of C code and execute it."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:137
msgid ""
"The `gtk+3.0 tests <gtk3_>`_ also do a compile/link/run check in the "
"\"build\" test. There is an additional \"python3-gi\" test which verifies "
"that the GTK library can also be used through introspection."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:140
msgid ""
"In the `ubiquity tests <ubiquity_>`_ the upstream test-suite is executed."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:141
msgid ""
"The `gvfs tests <gvfs_>`_ have comprehensive testing of their functionality "
"and are very interesting because they emulate usage of CDs, Samba, DAV and "
"other bits."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:146
msgid "Ubuntu infrastructure"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:148
msgid ""
"Packages which have ``autopkgtest`` enabled will have their tests run "
"whenever they get uploaded or any of their dependencies change. The output "
"of `automatically run autopkgtest tests <jenkins_>`_ can be viewed on the "
"web and is regularly updated."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:153
msgid ""
"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."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:159
msgid "Getting the test into Ubuntu"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:161
msgid ""
"The process of submitting an autopkgtest for a package is largely similar to "
":doc:`fixing a bug in Ubuntu<./fixing-a-bug>`. Essentially you simply:"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:164
msgid "run ``bzr branch ubuntu:<packagename>``,"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:165
msgid "edit ``debian/control`` to enable the tests,"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:166
msgid "add the ``debian/tests`` directory,"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:167
msgid ""
"write the ``debian/tests/control`` based on the `DEP 8 Specification "
"<dep8_>`_,"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:168
msgid "add your test case(s) to ``debian/tests``,"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:169
msgid ""
"commit your changes, push them to Launchpad, propose a merge and get it "
"reviewed just like any other improvement in a source package."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:174
msgid "What you can do"
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:176
msgid ""
"The Ubuntu Engineering team put together a `list of required test-cases "
"<requiredtests_>`_, where packages which need tests are put into different "
"categories. Here you can find examples of these tests and easily assign them "
"to yourself."
msgstr ""

#: ../ubuntu-packaging-guide/auto-pkg-test.rst:180
msgid ""
"If you should run into any problems, you can join the `#ubuntu-quality IRC "
"channel <qualityirc_>`_ to get in touch with developers who can help you."
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:3
msgid "Backporting software updates"
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:5
msgid ""
"Sometimes you might want to make new functionality available in a stable "
"release which is not connected to a critical bug fix. For these scenarios "
"you have two options: either you `upload to a PPA <ppadoc_>`_ or prepare a "
"backport."
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:12
msgid "Personal Package Archive (PPA)"
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:14
msgid ""
"Using a PPA has a number of benefits. It is fairly straight-forward, you "
"don't need approval of anyone, but the downside of it is that your users "
"will have to manually enable it. It is a non-standard software source."
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:18
msgid ""
"The `PPA documentation on Launchpad <ppadoc_>`_ is fairly comprehensive and "
"should get you up and running in no time."
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:25
msgid "Official Ubuntu Backports"
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:27
msgid ""
"The Backports Project is a means to provide new features to users. Because "
"of the inherent stability risks in backporting packages, users do not get "
"backported packages without some explicit action on their part. This "
"generally makes backports an inappropriate avenue for fixing bugs. If a "
"package in an Ubuntu release has a bug, it should be fixed either through "
"the :doc:`Security Update or the Stable Release Update process<./security-"
"and-stable-release-updates>`, as appropriate."
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:35
msgid ""
"Once you determined you want a package to be backported to a stable release, "
"you will need to test-build and test it on the given stable release. "
"``pbuilder-dist`` (in the ``ubuntu-dev-tools`` package) is a very handy tool "
"to do this easily."
msgstr ""

#: ../ubuntu-packaging-guide/backports.rst:40
msgid ""
"To report the backport request and get it processed by the Backporters team, "
"you can use the ``requestbackport`` tool (also in the ``ubuntu-dev-tools`` "
"package). It will determine the intermediate releases that package needs to "
"be backported to, list all reverse-dependencies, and file the backporting "
"request.  Also will it include a testing checklist in the bug."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:3
msgid "Using Chroots"
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:5
msgid ""
"If you are running one version of Ubuntu but working on packages for another "
"versions you can create the environment of the other version with a "
"``chroot``."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:9
msgid ""
"A ``chroot`` allows you to have a full filesystem from another distribution "
"which you can work in quite normally.  It avoids the overhead of running a "
"full virtual machine."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:14
msgid "Creating a Chroot"
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:16
msgid "Use the command ``debootstrap`` to create a new chroot::"
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:20
msgid ""
"This will create a directory ``trusty`` and install a minimal trusty system "
"into it."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:23
msgid ""
"If your version of ``debootstrap`` does not know about Trusty you can try "
"upgrading to the version in ``backports``."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:26
msgid "You can then work inside the chroot::"
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:30
msgid ""
"Where you can install or remove any package you wish without affecting your "
"main system."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:33
msgid ""
"You might want to copy your GPG/ssh keys and Bazaar configuration into the "
"chroot so you can access and sign packages directly::"
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:39
msgid ""
"To stop apt and other programs complaining about missing locales you can "
"install your relevant language pack::"
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:44
msgid ""
"If you want to run X programs you will need to bind the /tmp directory into "
"the chroot, from outside the chroot run::"
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:50
msgid "Some programs may need you to bind /dev or /proc."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:52
msgid ""
"For more information on chroots see our `Debootstrap Chroot wiki page "
"<DebootstrapChroot_>`_."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:55
msgid "Alternatives"
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:57
msgid ""
"SBuild is a system similar to PBuilder for creating an environment to run "
"test package builds in.  It closer matches that used by Launchpad for "
"building packages but takes some more setup compared to PBuilder.  See `the "
"Security Team Build Environment wiki page <SecurityEnv_>`_ for a full "
"explanation."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:62
msgid ""
"Full virtual machines can be useful for packaging and testing programs.  "
"TestDrive is a program to automate syncing and running daily ISO images, see "
"`the TestDrive wiki page <TestDrive_>`_ for more information."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:66
msgid ""
"You can also set up pbuilder to pause when it comes across a build failure.  "
"Copy C10shell from /usr/share/doc/pbuilder/examples into a directory and use "
"the ``--hookdir=`` argument to point to it."
msgstr ""

#: ../ubuntu-packaging-guide/chroots.rst:70
msgid ""
"Amazon's `EC2 cloud computers <EC2_>`_ allow you to hire a computer paying a "
"few US cents per hour, you can set up Ubuntu machines of any supported "
"version and package on those.  This is useful when you want to compile many "
"packages at the same time or to overcome bandwidth restraints."
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:3
msgid "Communication in Ubuntu Development"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:5
msgid ""
"In a project where thousands of lines of code are changed, lots of decisions "
"are made and hundreds of people interact every day, it is important to "
"communicate effectively."
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:10
msgid "Mailing lists"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:12
msgid ""
"Mailing lists are a very important tool if you want to communicate ideas to "
"a broader team and make sure that you reach everybody, even across timezones."
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:16
msgid "In terms of development, these are the most important ones:"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:18
msgid ""
"https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (announce-"
"only, the most important development announcements go here)"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:20
msgid ""
"https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (general Ubuntu "
"development discussion)"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:22
msgid ""
"https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (MOTU Team discussion, "
"get help with packaging)"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:27
msgid "IRC Channels"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:29
msgid ""
"For real-time discussions, please connect to irc.freenode.net and join one "
"or any of these channels:"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:32
msgid "#ubuntu-devel (for general development discussion)"
msgstr ""

#: ../ubuntu-packaging-guide/communication.rst:33
msgid "#ubuntu-motu (for MOTU team discussion and generally getting help)"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:2
msgid "Basic Overview of the ``debian/`` Directory"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:4
msgid ""
"This article will briefly explain the different files important to the "
"packaging of Ubuntu packages which are contained in the ``debian/`` "
"directory. The most important of them are ``changelog``, ``control``, "
"``copyright``, and ``rules``. These are required for all packages. A number "
"of additional files in the ``debian/`` may be used in order to customize and "
"configure the behavior of the package. Some of these files are discussed in "
"this article, but this is not meant to be a complete list."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:13
msgid "The changelog"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:15
msgid ""
"This file is, as its name implies, a listing of the changes made in each "
"version. It has a specific format that gives the package name, version, "
"distribution, changes, and who made the changes at a given time. If you have "
"a GPG key (see: :doc:`Getting set up<./getting-set-up/>`), make sure to use "
"the same name and email address in ``changelog`` as you have in your key. "
"The following is a template ``changelog``::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:31
msgid ""
"The format (especially of the date) is important. The date should be in "
":rfc:`5322` format, which can be obtained by using the command ``date -R``. "
"For convenience, the command ``dch`` may be used to edit changelog. It will "
"update the date automatically."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:36
msgid ""
"Minor bullet points are indicated by a dash \"-\", while major points use an "
"asterisk \"*\"."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:39
msgid ""
"If you are packaging from scratch, ``dch --create`` (``dch`` is in the "
"``devscripts`` package) will create a standard ``debian/changelog`` for you."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:43
msgid "Here is a sample ``changelog`` file for hello::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:52
msgid ""
"Notice that the version has a ``-0ubuntu1`` appended to it, this is the "
"distro revision, used so that the packaging can be updated (to fix bugs for "
"example) with new uploads within the same source release version."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:56
msgid ""
"Ubuntu and Debian have slightly different package versioning schemes to "
"avoid conflicting packages with the same source version. If a Debian package "
"has been changed in Ubuntu, it has ``ubuntuX`` (where ``X`` is the Ubuntu "
"revision number) appended to the end of the Debian version. So if the Debian "
"hello ``2.6-1`` package was changed by Ubuntu, the version string would be "
"``2.6-1ubuntu1``. If a package for the application does not exist in Debian, "
"then the Debian revision is ``0`` (e.g. ``2.6-0ubuntu1``)."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:64
msgid ""
"For further information, see the `changelog section (Section 4.4) <policy-"
"changelog_>`_ of the Debian Policy Manual."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:69
msgid "The control file"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:71
msgid ""
"The ``control`` file contains the information that the package manager (such "
"as ``apt-get``, ``synaptic``, and ``adept``) uses, build-time dependencies, "
"maintainer information, and much more."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:75
msgid ""
"For the Ubuntu ``hello`` package, the ``control`` file looks something like "
"this:"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:100
msgid ""
"The first paragraph describes the source package including the list of "
"packages required to build the package from source in the ``Build-Depends`` "
"field. It also contains some meta-information such as the maintainer's name, "
"the version of Debian Policy that the package complies with, the location of "
"the packaging version control repository, and the upstream home page."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:107
msgid ""
"Note that in Ubuntu, we set the ``Maintainer`` field to a general address "
"because anyone can change any package (this differs from Debian where "
"changing packages is usually restricted to an individual or a team). "
"Packages in Ubuntu should generally have the ``Maintainer`` field set to "
"``Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>``. If the "
"Maintainer field is modified, the old value should be saved in the ``XSBC-"
"Original-Maintainer`` field. This can be done automatically with the  "
"``update-maintainer`` script available in the ``ubuntu-dev-tools`` package. "
"For further information, see the `Debian Maintainer Field spec "
"<MaintField_>`_ on the Ubuntu wiki."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:118
msgid "Each additional paragraph describes a binary package to be built."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:120
msgid ""
"For further information, see the `control file section (Chapter 5) <policy-"
"control_>`_ of the Debian Policy Manual."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:125
msgid "The copyright file"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:127
msgid ""
"This file gives the copyright information for both the upstream source and "
"the packaging. Ubuntu and `Debian Policy (Section 12.5) <policy-"
"copyright_>`_ require that each package installs a verbatim copy of its "
"copyright and license information to "
"``/usr/share/doc/$(package_name)/copyright``."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:132
msgid ""
"Generally, copyright information is found in the ``COPYING`` file in the "
"program's source directory. This file should include such information as the "
"names of the author and the packager, the URL from which the source came, a "
"Copyright line with the year and copyright holder, and the text of the "
"copyright itself. An example template would be::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:174
msgid ""
"This example follows the `Machine-readable debian/copyright <DEP5_>`_ "
"format. You are encouraged to use this format as well."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:179
msgid "The rules file"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:181
msgid ""
"The last file we need to look at is ``rules``. This does all the work for "
"creating our package. It is a Makefile with targets to compile and install "
"the application, then create the ``.deb`` file from the installed files. It "
"also has a target to clean up all the build files so you end up with just a "
"source package again."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:189
msgid ""
"Here is a simplified version of the rules file created by ``dh_make`` (which "
"can be found in the ``dh-make`` package):"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:203
msgid ""
"Let us go through this file in some detail. What this does is pass every "
"build target that ``debian/rules`` is called with as an argument to "
"``/usr/bin/dh``, which itself will call all the necessary ``dh_*`` commands."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:207
msgid ""
"``dh`` runs a sequence of debhelper commands. The supported sequences "
"correspond to the targets of a ``debian/rules`` file: \"build\", \"clean\", "
"\"install\", \"binary-arch\", \"binary-indep\", and \"binary\". In order to "
"see what commands are run in each target, run::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:216
msgid ""
"Commands in the binary-indep sequence are passed the \"-i\" option to ensure "
"they only work on binary independent packages, and commands in the binary-"
"arch sequences are passed the \"-a\" option to ensure they only work on "
"architecture dependent packages."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:221
msgid ""
"Each debhelper command will record when it's successfully run in "
"``debian/package.debhelper.log``. (Which dh_clean deletes.) So dh can tell "
"which commands have already been run, for which packages, and skip running "
"those commands again."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:226
msgid ""
"Each time ``dh`` is run, it examines the log, and finds the last logged "
"command that is in the specified sequence. It then continues with the next "
"command in the sequence. The ``--until``, ``--before``, ``--after``, and ``--"
"remaining`` options can override this behavior."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:231
msgid ""
"If ``debian/rules`` contains a target with a name like "
"``override_dh_command``, then when it gets to that command in the sequence, "
"``dh`` will run that target from the rules file, rather than running the "
"actual command. The override target can then run the command with additional "
"options, or run entirely different commands instead. (Note that to use this "
"feature, you should Build-Depend on debhelper 7.0.50 or above.)"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:240
msgid ""
"Have a look at ``/usr/share/doc/debhelper/examples/`` and ``man dh`` for "
"more examples. Also see `the rules section (Section 4.9) "
"<http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules>`_ of "
"the Debian Policy Manual."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:246
msgid "Additional Files"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:249
msgid "The install file"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:251
msgid ""
"The ``install`` file is used by ``dh_install`` to install files into the "
"binary package. It has two standard use cases:"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:254
msgid ""
"To install files into your package that are not handled by the upstream "
"build system."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:255
msgid ""
"Splitting a single large source package into multiple binary packages."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:257
msgid ""
"In the first case, the ``install`` file should have one line per file "
"installed, specifying both the file and the installation directory. For "
"example, the following ``install`` file would install the script ``foo`` in "
"the source package's root directory to ``usr/bin`` and a desktop file in the "
"``debian`` directory to ``usr/share/applications``::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:268
msgid ""
"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::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:281
msgid ""
"While ``foo-common.install`` containing only the architecture independent "
"file might look like::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:289
msgid ""
"This would create two binary packages, ``foo`` and ``foo-common``. Both "
"would require their own paragraph in ``debian/control``."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:292
msgid ""
"See ``man dh_install`` and the `install file section (Section 5.11) "
"<http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install>`_  of "
"the Debian New Maintainers' Guide for additional details."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:297
msgid "The watch file"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:299
msgid ""
"The ``debian/watch`` file allows us to check automatically for new upstream "
"versions using the tool ``uscan`` found in the ``devscripts`` package. The "
"first line of the watch file must be the format version (3, at the time of "
"this writing), while the following lines contain any URLs to parse. For "
"example::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:308
msgid ""
"Running ``uscan`` in the root source directory will now compare the upstream "
"version number in ``debian/changelog`` with the latest available upstream "
"version. If a new upstream version is found, it will be automatically "
"downloaded. For example::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:321
msgid ""
"If your tarballs live on Launchpad, the ``debian/watch`` file is a little "
"more complicated (see `Question 21146 <Q21146_>`_ and `Bug 231797 "
"<Bug231797_>`_ for why this is).  In that case, use something like::"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:328
msgid ""
"For further information, see ``man uscan`` and the `watch file section "
"(Section 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-"
"debianwatch>`_ of the Debian Policy Manual."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:332
msgid ""
"For a list of packages where the ``watch`` file reports they are not in sync "
"with upstream see `Ubuntu External Health Status "
"<http://qa.ubuntuwire.org/uehs/no_updated.html>`_."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:337
msgid "The source/format file"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:339
msgid ""
"This file indicates the format of the source package. It should contain a "
"single line indicating the desired format:"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:342
msgid "``3.0 (native)`` for Debian native packages (no upstream version)"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:344
msgid "``3.0 (quilt)`` for packages with a separate upstream tarball"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:346
msgid "``1.0`` for packages wishing to explicitly declare the default format"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:348
msgid ""
"Currently, the package source format will default to 1.0 if this file does "
"not exist. You can make this explicit in the source/format file. If you "
"choose not to use this file to define the source format, Lintian will warn "
"about the missing file. This warning is informational only and may be safely "
"ignored."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:353
msgid ""
"You are encouraged to use the newer 3.0 source format. It provides a number "
"of new features:"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:356
msgid "Support for additional compression formats: bzip2, lzma and xz"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:358
msgid "Support for multiple upstream tarballs"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:360
msgid ""
"Not necessary to repack the upstream tarball to strip the debian directory"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:362
msgid ""
"Debian-specific changes are no longer stored in a single .diff.gz but in "
"multiple patches compatible with quilt under ``debian/patches/``"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:365
msgid ""
"https://wiki.debian.org/Projects/DebSrc3.0 summarizes additional information "
"concerning the switch to the 3.0 source package formats."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:368
msgid ""
"See ``man dpkg-source`` and the `source/format section (Section 5.21) "
"<policy-format_>`_  of  the Debian New Maintainers' Guide for additional "
"details."
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:372
msgid "Additional Resources"
msgstr ""

#: ../ubuntu-packaging-guide/debian-dir-overview.rst:374
msgid ""
"In addition to the links to the Debian Policy Manual in each section above, "
"the Debian New Maintainers' Guide has more detailed descriptions of each "
"file. `Chapter 4, \"Required files under the debian directory\" "
"<RequiredFiles_>`_ further discusses the  control, changelog, copyright and "
"rules files. `Chapter 5, \"Other files under the debian directory\" "
"<OtherFiles_>`_ discusses additional files that may be used."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:3
msgid "Fixing a bug in Ubuntu"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:6
#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:9
msgid "Introduction"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:8
msgid ""
"If you followed the instructions to :doc:`get set up with Ubuntu "
"Development<./getting-set-up>`, you should be all set and ready to go."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:13
msgid ""
"As you can see in the image above, there is no surprises in the process of "
"fixing bugs in Ubuntu: you found a problem, you get the code, work on the "
"fix, test it, push your changes to Launchpad and ask for it to be reviewed "
"and merged. In this guide we will go through all the necessary steps one by "
"one."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:20
msgid "Finding the problem"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:22
msgid ""
"There are a lot of different ways to find things to work on. It might be a "
"bug report you are encountering yourself (which gives you a good opportunity "
"to test the fix), or a problem you noted elsewhere, maybe in a bug report."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:26
msgid ""
"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."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:35
msgid "Figuring out what to fix"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:37
msgid ""
"If you don't know the source package containing the code that has the "
"problem, but you do know the path to the affected program on your system, "
"you can discover the source package that you'll need to work on."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:41
msgid ""
"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::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:47
msgid "This would print out::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:51
msgid ""
"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::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:62
msgid "``apt-cache`` is part of the standard installation of Ubuntu."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:65
msgid "Confirming the problem"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:67
msgid ""
"Once you have figured out which package the problem is in, it's time to "
"confirm that the problem exists."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:70
msgid ""
"Let's say the package ``bumprace`` does not have a homepage in its package "
"description. As a first step you would check if the problem is not solved "
"already. This is easy to check, either take a look at Software Center or "
"run::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:76
msgid "The output should be similar to this::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:102
msgid "A counter-example would be ``gedit``, which has a homepage set::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:107
msgid ""
"Sometimes you will find that a particular problem you are looking into is "
"already fixed. To avoid wasting efforts and duplicating work it makes sense "
"to first do some detective work."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:112
msgid "Research bug situation"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:114
msgid ""
"First we should check if a bug for the problem exists in Ubuntu already. "
"Maybe somebody is working on a fix already, or we can contribute to the "
"solution somehow. For Ubuntu we have a quick look at "
"https://bugs.launchpad.net/ubuntu/+source/bumprace and there is no open bug "
"with our problem there."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:120
msgid ""
"For Ubuntu the URL ``https://bugs.launchpad.net/ubuntu/+source/<package>`` "
"should always take to the bug page of the source package in question."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:124
msgid ""
"For Debian, which is the major source for Ubuntu's packages, we have a look "
"at http://bugs.debian.org/src:bumprace and can't find a bug report for our "
"problem either."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:128
msgid ""
"For Debian the URL ``http://bugs.debian.org/src:<package>`` should always "
"take to the bug page of the source package in question."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:131
msgid ""
"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."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:138
msgid "Offering help"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:140
msgid ""
"If you found an open bug and it is not assigned to somebody and you are in a "
"position to fix it, you should comment on it with your solution. Be sure to "
"include as much information as you can: Under which circumstances does the "
"bug occur? How did you fix the problem? Did you test your solution?"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:145
msgid ""
"If no bug report has been filed, you can file a bug for it. What you might "
"want to bear in mind is: Is the issue so small that just asking for somebody "
"to commit it is good enough? Did you manage to only partially fix the issue "
"and you want to at least share your part of it?"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:150
msgid "It is great if you can offer help and will surely be appreciated."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:155
msgid "Getting the code"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:157
msgid ""
"Once you know the source package to work on, you will want to get a copy of "
"the code on your system, so that you can debug it. The ubuntu-dev-tools "
"package has a tool called ``pull-lp-source`` that a developer can use to "
"grab the source code for any package. For example, to grab the source code "
"for the tomboy package in ``xenial``, you can type this::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:165
msgid ""
"If you do not specify a release such as ``xenial``, it will automatically "
"get the package from the development version."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:168
msgid ""
"Once you've got a local clone of the source package, you can investigate the "
"bug, create a fix, generate a debdiff, and attach your debdiff to a bug "
"report for other developers to review. We'll describe specifics in the next "
"sections."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:173
msgid "Work on a fix"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:175
msgid ""
"There are entire books written about finding bugs, fixing them, testing "
"them, etc. If you are completely new to programming, try to fix easy bugs "
"such as obvious typos first. Try to keep changes as minimal as possible and "
"document your change and assumptions clearly."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:180
msgid ""
"Before working on a fix yourself, make sure to investigate if nobody else "
"has fixed it already or is currently working on a fix. Good sources to check "
"are:"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:183
msgid "Upstream (and Debian) bug tracker (open and closed bugs),"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:184
msgid ""
"Upstream revision history (or newer release) might have fixed the problem,"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:185
msgid "bugs or package uploads of Debian or other distributions."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:190
msgid ""
"You may want to create a patch which includes the fix. The command ``edit-"
"patch`` is a simple way to add a patch to a package. Run::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:195
msgid ""
"This will copy the packaging to a temporary directory.  You can now edit "
"files with a text editor or apply patches from upstream, for example::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:200
msgid ""
"After editing the file type ``exit`` or press ``control-d`` to quit the "
"temporary shell.  The new patch will have been added into ``debian/patches``."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:203
msgid ""
"You must then add a header to your patch containing meta information so that "
"other developers can know the purpose of the patch and where it came from. "
"To get the template header that you can edit to reflect what the patch does, "
"type this::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:210
msgid ""
"This will open the template in a text editor. Follow the template and make "
"sure to be thorough so you get all the details necessary to describe the "
"patch."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:214
msgid ""
"In this specific case, if you just want to edit ``debian/control``, you do "
"not need a patch. Put ``Homepage: http://www.linux-games.com/bumprace/`` at "
"the end of the first section and the bug should be fixed."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:219
msgid "Documenting the fix"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:221
msgid ""
"It is very important to document your change sufficiently so developers who "
"look at the code in the future won't have to guess what your reasoning was "
"and what your assumptions were. Every Debian and Ubuntu package source "
"includes ``debian/changelog``, where changes of each uploaded package are "
"tracked."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:226
msgid "The easiest way to update this is to run::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:230
msgid ""
"This will add a boilerplate changelog entry for you and launch an editor "
"where you can fill in the blanks. An example of this could be::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:239
msgid ""
"``dch`` should fill out the first and last line of such a changelog entry "
"for you already. Line 1 consists of the source package name, the version "
"number, which Ubuntu release it is uploaded to, the urgency (which almost "
"always is 'low'). The last line always contains the name, email address and "
"timestamp (in :rfc:`5322` format) of the change."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:245
msgid ""
"With that out of the way, let's focus on the actual changelog entry itself: "
"it is very important to document:"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:248
msgid "Where the change was done."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:249
msgid "What was changed."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:250
msgid "Where the discussion of the change happened."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:252
msgid ""
"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."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:259
msgid ""
"In order to get it sponsored in the next section, you need to file a bug "
"report in Launchpad (if there isn't one already, if there is, use that) and "
"explain why your fix should be included in Ubuntu. For example, for tomboy, "
"you would file a bug `here`_ (edit the URL to reflect the package you have a "
"fix for). Once a bug is filed explaining your changes, put that bug number "
"in the changelog."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:269
msgid "Testing the fix"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:271
msgid "To build a test package with your changes, run these commands::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:276
msgid ""
"This will create a source package from the branch contents (``-us -uc`` will "
"just omit the step to sign the source package and ``-d`` will skip the step "
"where it checks for build dependencies, pbuilder will take care of that) and "
"``pbuilder-dist`` will build the package from source for whatever "
"``release`` you choose."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:283
msgid ""
"If ``debuild`` errors out with \"Version number suggests Ubuntu changes, but "
"Maintainer: does not have Ubuntu address\" then run the ``update-"
"maintainer`` command (from ubuntu-dev-tools) and it will automatically fix "
"this for you. This happens because in Ubuntu, all Ubuntu Developers are "
"responsible for all Ubuntu packages, while in Debian, packages have "
"maintainers."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:289
msgid ""
"In this case with bumprace, run this to view the package information::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:293
msgid "As expected, there should now be a ``Homepage:`` field."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:296
msgid ""
"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."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:304
msgid "Submitting the fix and getting it included"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:306
msgid ""
"With the changelog entry written and saved, run ``debuild`` one more time::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:310
msgid ""
"and this time it will be signed and you are now ready to get your diff to "
"submit to get sponsored."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:313
msgid ""
"In a lot of cases, Debian would probably like to have the patch as well "
"(doing this is best practice to make sure a wider audience gets the fix). "
"So, you should submit the patch to Debian, and you can do that by simply "
"running this::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:320
msgid ""
"This will take you through a series of steps to make sure the bug ends up in "
"the correct place. Be sure to review the diff again to make sure it does not "
"include random changes you made earlier."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:324
msgid ""
"Communication is important, so when you add some more description to it to "
"the inclusion request, be friendly, explain it well."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:327
msgid ""
"If everything went well you should get a mail from Debian's bug tracking "
"system with more information. This might sometimes take a few minutes."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:330
msgid ""
"It might be beneficial to just get it included in Debian and have it flow "
"down to Ubuntu, in which case you would not follow the below process. But, "
"sometimes in the case of security updates and updates for stable releases, "
"the fix is already in Debian (or ignored for some reason) and you would "
"follow the below process. If you are doing such updates, please read our "
":doc:`Security and stable release updates<./security-and-stable-release-"
"updates>` article. Other cases where it is acceptable to wait to submit "
"patches to Debian are Ubuntu-only packages not building correctly, or Ubuntu-"
"specific problems in general."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:340
msgid ""
"But if you're going to submit your fix to Ubuntu, now it's time to generate "
"a \"debdiff\", which shows the difference between two Debian packages. The "
"name of the command used to generate one is also ``debdiff``. It is part of "
"the ``devscripts`` package. See ``man debdiff`` for all the details. To "
"compare two source packages, pass the two dsc files as arguments::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:348
msgid ""
"In this case, ``debdiff`` the dsc you downloaded with ``pull-lp-source`` and "
"the new dsc file you generated. This will generate a patch that your sponsor "
"can then apply locally (by using ``patch -p1 < /path/to/debdiff``). In this "
"case, pipe the output of the debdiff command to a file that you can then "
"attach to the bug report::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:356
msgid "The format shown in ``1-1.0-1ubuntu1.debdiff`` shows:"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:358
msgid ""
"``1-`` tells the sponsor that this is the first revision of your patch. "
"Nobody is perfect, and sometimes follow-up patches need to be provided. This "
"makes sure that if your patch needs work, that you can keep a consistent "
"naming scheme."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:362
msgid ""
"``1.0-1ubuntu1`` shows the new version being used. This makes it easy to see "
"what the new version is."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:364
msgid ""
"``.debdiff`` is an extension that makes it clear that it is a debdiff."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:366
msgid "While this format is optional, it works well and you can use this."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:368
msgid ""
"Next, go to the bug report, make sure you are logged into Launchpad, and "
"click \"Add attachment or patch\" under where you would add a new comment. "
"Attach the debdiff, and leave a comment telling your sponsor how this patch "
"can be applied and the testing you have done. An example comment can be::"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:376
msgid ""
"Make sure you mark it as a patch (the Ubuntu Sponsors team will "
"automatically be subscribed) and that you are subscribed to the bug report. "
"You will then receive a review anywhere between several housr from "
"submitting the patch to several weeks. If it takes longer than that, please "
"join ``#ubuntu-motu`` on ``freenode`` and mention it there. Stick around "
"until you get an answer from someone, and they can guide you as to what to "
"do next."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:383
msgid ""
"Once you have received a review, your patch was either uploaded, your patch "
"needs work, or is rejected for some other reason (possibly the fix is not "
"fit for Ubuntu or should go to Debian instead). If your patch needs work, "
"follow the same steps and submit a follow-up patch on the bug report, "
"otherwise submit to Debian as shown above."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:389
msgid ""
"Remember: good places to ask your questions are ``ubuntu-"
"motu@lists.ubuntu.com`` and ``#ubuntu-motu`` on freenode. You will easily "
"find a lot of new friends and people with the same passion that you have: "
"making the world a better place by making better Open Source software."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:395
msgid "Additional considerations"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:397
msgid ""
"If you find a package and find that there are a couple of trivial things you "
"can fix at the same time, do it. This will speed up review and inclusion."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-a-bug.rst:400
msgid ""
"If there are multiple big things you want to fix, it might be advisable to "
"send individual patches or merge proposals instead. If there are individual "
"bugs filed for the issues already, this makes it even easier."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:5
msgid "Fixing FTBFS packages"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:7
msgid ""
"Before a package can be used in Ubuntu, it has to build from source. If it "
"fails this, it will probably wait in -proposed and will not be available in "
"the Ubuntu archives. You can find a complete list of packages that are "
"failing to build from source at http://qa.ubuntuwire.org/ftbfs/. There are 5 "
"main categories shown on the page:"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:13
msgid ""
"Package failed to build (F): Something actually went wrong with the build "
"process."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:15
msgid ""
"Cancelled build (X): The build has been cancelled for some reason. These "
"should probably be avoided to start with."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:17
msgid ""
"Package is waiting on another package (M): This package is waiting on "
"another package to either build, get updated, or (if the package is in main) "
"one of it's dependancies is in the wrong part of the archive."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:20
msgid ""
"Failure in the chroot (C): Part of the chroot failed, this is most likely "
"fixed by a rebuild. Ask a developer to rebuild the package and that should "
"fix it."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:23
msgid ""
"Failed to upload (U): The package could not upload. This is usually just a "
"case of asking for a rebuild, but check the build log first."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:27
msgid "First steps"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:28
msgid ""
"The first thing you'll want to do is see if you can reproduce the FTBFS "
"yourself. Get the code either by running ``bzr branch lp:ubuntu/PACKAGE`` "
"and then getting the tarball or running ``dget PACKAGE_DSC`` on the .dsc "
"file from the launchpad page. Once you have that, build it in a schroot."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:35
msgid ""
"You should be able to reproduce the FTBFS. If not, check if the build is "
"downloading a missing dependency, which means you just need to make that a "
"build-dependency in debian/control. Building the package locally can also "
"help find if the issue is caused by a missing, unlisted, dependency (builds "
"locally but fails on a schroot)."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:42
msgid "Checking Debian"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:43
msgid ""
"Once you have reproduced the issue, it's time to try and find a solution. If "
"the package is in Debian as well, you can check if the package builds there "
"by going to http://packages.qa.debian.org/PACKAGE. If Debian has a newer "
"version, you should merge it. If not, check the buildlogs and bugs linked on "
"that page for any extra information on the ftbfs or patches. Debian also "
"maintains a list of command FTBFSs and how to fix them which can be found at "
"https://wiki.debian.org/qa.debian.org/FTBFS, you will want to check it for "
"solutions too."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:53
msgid "Other causes of a package to FTBFS"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:54
msgid ""
"If a package is in main and missing a dependency that is not in main, you "
"will have to file a MIR bug. https://wiki.ubuntu.com/MainInclusionProcess "
"explains the procedure."
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:61
msgid "Fixing the issue"
msgstr ""

#: ../ubuntu-packaging-guide/fixing-ftbfs.rst:62
msgid ""
"Once you have found a fix to the problem, follow the same process as any "
"other bug. Make a patch, add it to a bzr branch or bug, subscribe ubuntu-"
"sponsors, then try to get it included upstream and/or in Debian."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:3
msgid "Getting Set Up"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:5
msgid ""
"There are a number of things you need to do to get started developing for "
"Ubuntu. This article is designed to get your computer set up so that you can "
"start working with packages, and upload your packages to Ubuntu's hosting "
"platform, Launchpad. Here's what we'll cover:"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:10
msgid "Installing packaging-related software. This includes:"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:12
msgid "Ubuntu-specific packaging utilities"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:13
msgid "Encryption software so your work can be verified as being done by you"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:14
msgid "Additional encryption software so you can securely transfer files"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:16
msgid "Creating and configuring your account on Launchpad"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:17
msgid ""
"Setting up your development environment to help you do local builds of "
"packages, interact with other developers, and propose your changes on "
"Launchpad."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:22
msgid ""
"It is advisable to do packaging work using the current development version "
"of Ubuntu. Doing so will allow you to test changes in the same environment "
"where those changes will actually be applied and used."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:26
msgid ""
"Don't want to install the latest Ubuntu development version of Ubuntu? Spin "
"up an `LXD container <https://help.ubuntu.com/lts/serverguide/lxd.html>`_."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:30
msgid "Install basic packaging software"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:32
msgid ""
"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::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:39
msgid "This command will install the following software:"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:41
msgid ""
"``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."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:44
msgid ""
"``pbuilder`` -- a tool to do reproducible builds of a package in a clean and "
"isolated environment."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:46
msgid ""
"``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a "
"collection of tools that make many packaging tasks easier."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:48
msgid ""
"``apt-file`` provides an easy way to find the binary package that contains a "
"given file."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:53
msgid "Create your GPG key"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:55
msgid ""
"GPG stands for `GNU Privacy Guard <GPG_>`_ and it implements the OpenPGP "
"standard which allows you to sign and encrypt messages and files. This is "
"useful for a number of purposes. In our case it is important that you can "
"sign files with your key so they can be identified as something that you "
"worked on. If you upload a source package to Launchpad, it will only accept "
"the package if it can absolutely determine who uploaded the package."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:62
msgid "To generate a new GPG key, run::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:66
msgid ""
"GPG will first ask you which kind of key you want to generate. Choosing the "
"default (RSA and DSA) is fine. Next it will ask you about the keysize. The "
"default (currently 2048) is fine, but 4096 is more secure. Afterwards, it "
"will ask you if you want it to expire the key at some stage. It is safe to "
"say \"0\", which means the key will never expire. The last questions will be "
"about your name and email address. Just pick the ones you are going to use "
"for Ubuntu development here, you can add additional email addresses later "
"on. Adding a comment is not necessary. Then you will have to set a "
"passphrase, choose a safe one (a passphrase is just a password which is "
"allowed to include spaces)."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:76
msgid ""
"Now GPG will create a key for you, which can take a little bit of time; it "
"needs random bytes, so if you give the system some work to do it will be "
"just fine.  Move the cursor around, type some paragraphs of random text, "
"load some web page."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:81
msgid "Once this is done, you will get a message similar to this one::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:88
msgid "In this case ``43CDE61D`` is the *key ID*."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:90
msgid ""
"Next, you need to upload the public part of your key to a keyserver so the "
"world can identify messages and files as yours. To do so, enter::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:95
msgid ""
"This will send your key to the Ubuntu keyserver, but a network of keyservers "
"will automatically sync the key between themselves. Once this syncing is "
"complete, your signed public key will be ready to verify your contributions "
"around the world."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:102
msgid "Create your SSH key"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:104
msgid ""
"SSH_ stands for *Secure Shell*, and it is a protocol that allows you to "
"exchange data in a secure way over a network. It is common to use SSH to "
"access and open a shell on another computer, and to use it to securely "
"transfer files. For our purposes, we will mainly be using SSH to securely "
"upload source packages to Launchpad."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:110
msgid "To generate an SSH key, enter::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:114
msgid ""
"The default file name usually makes sense, so you can just leave it as it "
"is. For security purposes, it is highly recommended that you use a "
"passphrase."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:119
msgid "Set up pbuilder"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:121
msgid ""
"``pbuilder`` allows you to build packages locally on your machine. It serves "
"a couple of purposes:"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:124
msgid ""
"The build will be done in a minimal and clean environment. This helps you "
"make sure your builds succeed in a reproducible way, but without modifying "
"your local system"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:127
msgid ""
"There is no need to install all necessary *build dependencies* locally"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:128
msgid ""
"You can set up multiple instances for various Ubuntu and Debian releases"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:130
msgid "Setting ``pbuilder`` up is very easy, run::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:134
msgid ""
"where <release> is for example `xenial`, `zesty`, `artful` or in the case of "
"Debian maybe `sid` or `buster`. This will take a while as it will download "
"all the necessary packages for a \"minimal installation\". These will be "
"cached though."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:140
msgid "Get set up to work with Launchpad"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:142
msgid ""
"With a basic local configuration in place, your next step will be to "
"configure your system to work with Launchpad. This section will focus on the "
"following topics:"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:146
msgid "What Launchpad is and creating a Launchpad account"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:147
msgid "Uploading your GPG and SSH keys to Launchpad"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:148
msgid ""
"Configure your shell to recognize you (for putting your name in changelogs)"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:152
msgid "About Launchpad"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:154
msgid ""
"Launchpad is the central piece of infrastructure we use in Ubuntu. It not "
"only stores our packages and our code, but also things like translations, "
"bug reports, and information about the people who work on Ubuntu and their "
"team memberships.  You will also use Launchpad to publish your proposed "
"fixes, and get other Ubuntu developers to review and sponsor them."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:160
msgid ""
"You will need to register with Launchpad and provide a minimal amount of "
"information. This will allow you to download and upload code, submit bug "
"reports, and more."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:164
msgid ""
"Besides hosting Ubuntu, Launchpad can host any Free Software project. For "
"more information see the `Launchpad Help wiki "
"<https://help.launchpad.net/>`_."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:169
msgid "Get a Launchpad account"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:171
msgid ""
"If you don't already have a Launchpad account, you can easily `create one "
"<LP-AccountCreate_>`_. If you have a Launchpad account but cannot remember "
"your Launchpad id, you can find this out by going to https://launchpad.net/~ "
"and looking for the part after the `~` in the URL."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:176
msgid ""
"Launchpad's registration process will ask you to choose a display name. It "
"is encouraged for you to use your real name here so that your Ubuntu "
"developer colleagues will be able to get to know you better."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:180
msgid ""
"When you register a new account, Launchpad will send you an email with a "
"link you need to open in your browser in order to verify your email address. "
"If you don't receive it, check in your spam folder."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:184
msgid ""
"`The new account help page <LP-AccountHelp_>`_ on Launchpad has more "
"information about the process and additional settings you can change."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:191
msgid "Upload your GPG key to Launchpad"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:193
msgid "First, you will need to get your fingerprint and key ID."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:195
msgid "To find about your GPG fingerprint, run::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:199
msgid "and it will print out something like::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:206
msgid "Then run this command to submit your key to Ubuntu keyserver::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:210
msgid ""
"where ``43CDE61D`` should be replaced by your key ID (which is in the first "
"line of output of the previous command). Now you can import your key to "
"Launchpad."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:214
msgid ""
"Head to https://launchpad.net/~/+editpgpkeys and copy the \"Key "
"fingerprint\" into the text box. In the case above this would be ``5C28 0144 "
"FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D``. Now click on \"Import Key\"."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:219
msgid ""
"Launchpad will use the fingerprint to check the Ubuntu key server for your "
"key and, if successful, send you an encrypted email asking you to confirm "
"the key import. Check your email account and read the email that Launchpad "
"sent you. `If your email client supports OpenPGP encryption, it will prompt "
"you for the password you chose for the key when GPG generated it. Enter the "
"password, then click the link to confirm that the key is yours.`"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:226
msgid ""
"Launchpad encrypts the email, using your public key, so that it can be sure "
"that the key is yours. If you are using Thunderbird, the default Ubuntu "
"email client, you can install the `Enigmail plugin <Enigmail_>`_ to easily "
"decrypt the message. If your email software does not support OpenPGP "
"encryption, copy the encrypted email's contents, type ``gpg`` in your "
"terminal, then paste the email contents into your terminal window."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:236
msgid ""
"Back on the Launchpad website, use the Confirm button and Launchpad will "
"complete the import of your OpenPGP key."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:239
msgid ""
"Find more information at "
"https://help.launchpad.net/YourAccount/ImportingYourPGPKey"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:243
msgid "Upload your SSH key to Launchpad"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:245
msgid ""
"Open https://launchpad.net/~/+editsshkeys in a web browser, also open "
"``~/.ssh/id_rsa.pub`` in a text editor. This is the public part of your SSH "
"key, so it is safe to share it with Launchpad. Copy the contents of the file "
"and paste them into the text box on the web page that says \"Add an SSH "
"key\". Now click \"Import Public Key\"."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:251
msgid ""
"For more information on this process, visit the `creating an SSH keypair "
"<genssh_>`_ page on Launchpad."
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:258
msgid "Configure your shell"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:259
msgid ""
"The Debian/Ubuntu packaging tools need to learn about you as well in order "
"to properly credit you in the changelog. Simply open your `~/.bashrc` in a "
"text editor and add something like this to the bottom of it::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:266
msgid "Now save the file and either restart your terminal or run::"
msgstr ""

#: ../ubuntu-packaging-guide/getting-set-up.rst:270
msgid ""
"(If you do not use the default shell, which is `bash`, please edit the "
"configuration file for that shell accordingly.)"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:9
msgid "Ubuntu Packaging Guide"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:11
msgid ""
"Welcome to the Ubuntu Packaging and Development Guide! We are currently "
"developing codename Artful Aardvark, which is to be released in October 2017 "
"as Ubuntu 17.10."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:15
msgid ""
"This is the official place for learning all about Ubuntu Development and "
"packaging. After reading this guide you will have:"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:18
msgid ""
"Heard about the most important players, processes and tools in Ubuntu "
"development,"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:20
msgid "Your development environment set up correctly,"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:21
msgid "A better idea of how to join our community,"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:22
msgid "Fixed an actual Ubuntu bug as part of the tutorials."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:24
msgid ""
"Ubuntu is not only a free and open source operating system, its platform is "
"also open and developed in a transparent fashion. The source code for every "
"single component can be obtained easily and every single change to the "
"Ubuntu platform can be reviewed."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:29
msgid ""
"This means you can actively get involved in improving it and the community "
"of Ubuntu platform developers is always interested in helping peers getting "
"started."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:33
msgid ""
"Ubuntu is also a community of great people who believe in free software and "
"that it should be accessible for everyone. Its members are welcoming and "
"want you to be involved as well. We want you to get involved, to ask "
"questions, to make Ubuntu better together with us."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:38
msgid ""
"If you run into problems: don't panic! Check out the :doc:`communication "
"article<./communication>` and you will find out how to most easily get in "
"touch with other developers."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:42
msgid "The guide is split up into two sections:"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:44
msgid "A list of articles based on tasks, things you want to get done."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:45
msgid ""
"A set of knowledge-base articles that dig deeper into specific bits of our "
"tools and workflows."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:49
msgid "Articles"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:66
msgid "Knowledge Base"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:79
#: ../ubuntu-packaging-guide/libraries.rst:150
msgid "Further Reading"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:81
msgid ""
"You can read this guide offline in different formats, if you install one of "
"the `binary packages <BinPkgs_>`_."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:84
msgid ""
"If you want to learn more about building Debian packages, here are some "
"Debian resources you may find useful:"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:87
msgid "`How to package for Debian <HowToPackage_>`_;"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:88
msgid "`Debian Policy Manual <Policy_>`_;"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:89
msgid ""
"`Debian New Maintainers' Guide <NewMaintGuide_>`_ — available in many "
"languages;"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:90
msgid ""
"`Packaging tutorial <PkgTutorial_>`_ (also available as a `package "
"<PkgTutorialPkg_>`_);"
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:91
msgid "`Guide for Packaging Python Modules <PythonModules_>`_."
msgstr ""

#: ../ubuntu-packaging-guide/index.rst:93
msgid ""
"We are always looking to improve this guide. If you find any problems or "
"have some suggestions, please `report a bug on Launchpad <Bugs_>`_. If you'd "
"like to help work on the guide, `grab the source <Source_>`_ there as well."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:3
msgid "Introduction to Ubuntu Development"
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:5
msgid ""
"Ubuntu is made up of thousands of different components, written in many "
"different programming languages. Every component -  be it a software "
"library, a tool or a graphical application - is available as a source "
"package. Source packages in most cases consist of two parts: the actual "
"source code and metadata. Metadata includes the dependencies of the package, "
"copyright and licensing information, and instructions on how to build the "
"package. Once this source package is compiled, the build process provides "
"binary packages, which are the .deb files users can install."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:14
msgid ""
"Every time a new version of an application is released, or when someone "
"makes a change to the source code that goes into Ubuntu, the source package "
"must be uploaded to Launchpad's build machines to be compiled. The resulting "
"binary packages then are distributed to the archive and its mirrors in "
"different countries. The URLs in ``/etc/apt/sources.list`` point to an "
"archive or mirror. Every day images are built for a selection of different "
"Ubuntu flavours. They can be used in various circumstances. There are images "
"you can put on a USB key, you can burn them on DVDs, you can use netboot "
"images and there are images suitable for your phone and tablet. Ubuntu "
"Desktop, Ubuntu Server, Kubuntu and others specify a list of required "
"packages that get on the image. These images are then used for installation "
"tests and provide the feedback for further release planning."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:27
msgid ""
"Ubuntu's development is very much dependent on the current stage of the "
"release cycle. We release a new version of Ubuntu every six months, which is "
"only possible because we have established strict freeze dates. With every "
"freeze date that is reached developers are expected to make fewer, less "
"intrusive changes. Feature Freeze is the first big freeze date after the "
"first half of the cycle has passed. At this stage features must be largely "
"implemented. The rest of the cycle is supposed to be focused on fixing bugs. "
"After that the user interface, then the documentation, the kernel, etc. are "
"frozen, then the beta release is put out which receives a lot of testing. "
"From the beta release onwards, only critical bugs get fixed and a release "
"candidate release is made and if it does not contain any serious problems, "
"it becomes the final release."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:42
msgid ""
"Thousands of source packages, billions of lines of code, hundreds of "
"contributors require a lot of communication and planning to maintain high "
"standards of quality. At the beginning and in the middle of each release "
"cycle we have the Ubuntu Developer Summit where developers and contributors "
"come together to plan the features of the next releases. Every feature is "
"discussed by its stakeholders and a specification is written that contains "
"detailed information about its assumptions, implementation, the necessary "
"changes in other places, how to test it and so on. This is all done in an "
"open and transparent fashion, so you can participate remotely and listen to "
"a videocast, chat with attendants and subscribe to changes of "
"specifications, so you are always up to date."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:54
msgid ""
"Not every single change can be discussed in a meeting though, particularly "
"because Ubuntu relies on changes that are done in other projects. That is "
"why contributors to Ubuntu constantly stay in touch. Most teams or projects "
"use dedicated mailing lists to avoid too much unrelated noise. For more "
"immediate coordination, developers and contributors use Internet Relay Chat "
"(IRC). All discussions are open and public."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:61
msgid ""
"Another important tool regarding communication is bug reports. Whenever a "
"defect is found in a package or piece of infrastructure, a bug report is "
"filed in Launchpad. All information is collected in that report and its "
"importance, status and assignee updated when necessary. This makes it an "
"effective tool to stay on top of bugs in a package or project and organise "
"the workload."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:68
msgid ""
"Most of the software available through Ubuntu is not written by Ubuntu "
"developers themselves. Most of it is written by developers of other Open "
"Source projects and then integrated into Ubuntu. These projects are called "
"\"Upstreams\", because their source code flows into Ubuntu, where we "
"\"just\" integrate it. The relationship to Upstreams is critically important "
"to Ubuntu. It is not just code that Ubuntu gets from Upstreams, but it is "
"also that Upstreams get users, bug reports and patches from Ubuntu (and "
"other distributions)."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:77
msgid ""
"The most important Upstream for Ubuntu is Debian. Debian is the distribution "
"that Ubuntu is based on and many of the design decisions regarding the "
"packaging infrastructure are made there. Traditionally, Debian has always "
"had dedicated maintainers for every single package or dedicated maintenance "
"teams. In Ubuntu there are teams that have an interest in a subset of "
"packages too, and naturally every developer has a special area of expertise, "
"but participation (and upload rights) generally is open to everyone who "
"demonstrates ability and willingness."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:86
msgid ""
"Getting a change into Ubuntu as a new contributor is not as daunting as it "
"seems and can be a very rewarding experience. It is not only about learning "
"something new and exciting, but also about sharing the solution and solving "
"a problem for millions of users out there."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:91
msgid ""
"Open Source Development happens in a distributed world with different goals "
"and different areas of focus. For example there might be the case that a "
"particular Upstream is interested in working on a new big feature while "
"Ubuntu, because of the tight release schedule, is interested in shipping a "
"solid version with just an additional bug fix. That is why we make use of "
"\"Distributed Development\", where code is being worked on in various "
"branches that are merged with each other after code reviews and sufficient "
"discussion."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:101
msgid ""
"In the example mentioned above it would make sense to ship Ubuntu with the "
"existing version of the project, add the bugfix, get it into Upstream for "
"their next release and ship that (if suitable) in the next Ubuntu release. "
"It would be the best possible compromise and a situation where everybody "
"wins."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:106
msgid ""
"To fix a bug in Ubuntu, you would first get the source code for the package, "
"then work on the fix, document it so it is easy to understand for other "
"developers and users, then build the package to test it. After you have "
"tested it, you can easily propose the change to be included in the current "
"Ubuntu development release. A developer with upload rights will review it "
"for you and then get it integrated into Ubuntu."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:115
msgid ""
"When trying to find a solution it is usually a good idea to check with "
"Upstream and see if the problem (or a possible solution) is known already "
"and, if not, do your best to make the solution a concerted effort."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:119
msgid ""
"Additional steps might involve getting the change backported to an older, "
"still supported version of Ubuntu and forwarding it to Upstream."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:122
msgid ""
"The most important requirements for success in Ubuntu development are: "
"having a knack for \"making things work again,\" not being afraid to read "
"documentation and ask questions, being a team player and enjoying some "
"detective work."
msgstr ""

#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:126
msgid ""
"Good places to ask your questions are ``ubuntu-motu@lists.ubuntu.com`` and "
"``#ubuntu-motu`` on ``freenode.``. You will easily find a lot of new friends "
"and people with the same passion that you have: making the world a better "
"place by making better Open Source software."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:3
msgid "KDE Packaging"
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:5
msgid ""
"Packaging of KDE programs in Ubuntu is managed by the Kubuntu and MOTU "
"teams.  You can contact the Kubuntu team on the `Kubuntu mailing list "
"<KubuntuML_>`_ and ``#kubuntu-devel`` Freenode IRC channel.  More "
"information about Kubuntu development is on the `Kubuntu wiki page <Wiki_>`_."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:10
msgid ""
"Our packaging follows the practices of the `Debian Qt/KDE Team "
"<QtKDETeam_>`_ and Debian KDE Extras Team.  Most of our packages are derived "
"from the packaging of these Debian teams."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:15
msgid "Patching Policy"
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:17
msgid ""
"Kubuntu does not add patches to KDE programs unless they come from the "
"upstream authors or submitted upstream with the expectation they will be "
"merged soon or we have consulted the issue with the upstream authors."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:22
msgid ""
"Kubuntu does not change the branding of packages except where upstream "
"expects this (such as the top left logo of the Kickoff menu) or to simplify "
"(such as removing splash screens)."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:27
msgid "debian/rules"
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:29
msgid ""
"Debian packages include some additions to the basic Debhelper usage. These "
"are kept in the ``pkg-kde-tools`` package."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:32
msgid ""
"Packages which use Debhelper 7 should add the ``--with=kde`` option. This "
"will ensure the correct build flags are used and add options such as "
"handling kdeinit stubs and translations::"
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:39
msgid ""
"Some newer KDE packages use the ``dhmk`` system, an alternative to ``dh`` "
"made by the Debian Qt/KDE team.  You can read about it in /usr/share/pkg-kde-"
"tools/qt-kde-team/2/README.  Packages using this will ``include "
"/usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk`` instead of running "
"``dh``."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:47
msgid "Translations"
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:49
msgid ""
"Packages in main have their translations imported into Launchpad and "
"exported from Launchpad into Ubuntu's language-packs."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:52
msgid ""
"So any KDE package in main must generate translation templates, include or "
"make available upstream translations and handle ``.desktop`` file "
"translations."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:56
msgid ""
"To generate translation templates the package must include a ``Messages.sh`` "
"file; complain to the upstream if it does not.  You can check it works by "
"running ``extract-messages.sh`` which should produce one or more ``.pot`` "
"files in ``po/``.  This will be done automatically during build if you use "
"the ``--with=kde`` option to ``dh``."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:63
msgid ""
"Upstream will usually have also put the translation ``.po`` files into the "
"``po/`` directory.  If they do not, check if they are in separate upstream "
"language packs such as the KDE SC language packs.  If they are in separate "
"language packs Launchpad will need to associate these together manually, "
"contact `David Planella <dpm_>`_ to do this."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:69
msgid ""
"If a package is moved from universe to main it will need to be re-uploaded "
"before the translations get imported into Launchpad."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:72
msgid ""
"``.desktop`` files also need translations.  We patch KDELibs to read "
"translations out of ``.po`` files which are pointed to by a line ``X-Ubuntu-"
"Gettext-Domain=`` added to ``.desktop`` files at package build time.  A .pot "
"file for each package is be generated at build time and .po files need to be "
"downloaded from upstream and included in the package or in our language "
"packs.  The list of .po files to be downloaded from KDE's repositories is in "
"``/usr/lib/kubuntu-desktop-i18n/desktop-template-list``."
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:82
msgid "Library Symbols"
msgstr ""

#: ../ubuntu-packaging-guide/kde.rst:84
msgid ""
"Library symbols are tracked in ``.symbols`` files to ensure none go missing "
"for new releases.  KDE uses C++ libraries which act a little differently "
"compared to C libraries.  Debian's Qt/KDE Team have scripts to handle this. "
"See `Working with symbols files <SymbolsFiles_>`_ for how to create and keep "
"these files up to date."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:3
msgid "Shared Libraries"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:5
msgid ""
"Shared libraries are compiled code which is intended to be shared among "
"several different programs.  They are distributed as ``.so`` files in "
"``/usr/lib/``."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:9
msgid ""
"A library exports symbols which are the compiled versions of functions, "
"classes and variables.  A library has a name called an SONAME which includes "
"a version number.  This SONAME version does not necessarily match the public "
"release version number.  A program gets compiled against a given SONAME "
"version of the library.  If any of the symbols is removed or changes then "
"the version number needs to be changed which forces any packages using that "
"library to be recompiled against the new version.  Version numbers are "
"usually set by upstream and we follow them in our binary package names "
"called an ABI number, but sometimes upstreams do not use sensible version "
"numbers and packagers have to keep separate version numbers."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:21
msgid ""
"Libraries are usually distributed by upstream as standalone releases. "
"Sometimes they are distributed as part of a program.  In this case they can "
"be included in the binary package along with the program (this is called "
"bundling) if you do not expect any other programs to use the library, more "
"often they should be split out into separate binary packages."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:27
msgid ""
"The libraries themselves are put into a binary package named ``libfoo1`` "
"where ``foo`` is the name of the library and ``1`` is the version from the "
"SONAME. Development files from the package, such as header files, needed to "
"compile programs against the library are put into a package called ``libfoo-"
"dev``."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:34
msgid "An Example"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:36
msgid "We will use libnova as an example::"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:41
msgid "To find the SONAME of the library run::"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:45
msgid ""
"The SONAME is ``libnova-0.12.so.2``, which matches the file name (usually "
"the case but not always). Here upstream has put the upstream version number "
"as part of the SONAME and given it an ABI version of ``2``.  Library package "
"names should follow the SONAME of the library they contain. The library "
"binary package is called ``libnova-0.12-2`` where ``libnova-0.12`` is the "
"name of the library and ``2`` is our ABI number."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:52
msgid ""
"If upstream makes incompatible changes to their library they will have to "
"reversion their SONAME and we will have to rename our library.  Any other "
"packages using our library package will need to recompiled against the new "
"version, this is called a transition and can take some effort. Hopefully our "
"ABI number will continue to match upstream's SONAME but sometimes they "
"introduce incompatibilities without changing their version number and we "
"will need to change ours."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:60
msgid ""
"Looking in debian/libnova-0.12-2.install we see it includes two files::"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:65
msgid ""
"The last one is the actual library, complete with minor and point version "
"number.  The first one is a symlink which points to the actual library.  The "
"symlink is what programs using the library will look for, the running "
"programs do not care about the minor version number."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:70
msgid ""
"``libnova-dev.install`` includes all the files needed to compile a program "
"with this library.  Header files, a config binary, the ``.la`` libtool file "
"and ``libnova.so`` which is another symlink pointing at the library, "
"programs compiling against the library do not care about the major version "
"number (although the binary they compile into will)."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:76
msgid ""
"``.la`` libtool files are needed on some non-Linux systems with poor library "
"support but usually cause more problems than they solve on Debian systems.  "
"It is a current `Debian goal to remove .la files <LAFileRemoval_>`_ and we "
"should help with this."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:82
msgid "Static Libraries"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:84
msgid ""
"The -dev package also ships ``usr/lib/libnova.a``.  This is a static "
"library, an alternative to the shared library.  Any program compiled against "
"the static library will include the code directory into itself.  This gets "
"round worrying about binary compatibility of the library.  However it also "
"means that any bugs, including security issues, will not be updated along "
"with the library until the program is recompiled.  For this reason programs "
"using static libraries are discouraged."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:94
msgid "Symbol Files"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:96
msgid ""
"When a package builds against a library the ``shlibs`` mechanism will add a "
"package dependency on that library.  This is why most programs will have "
"``Depends: ${shlibs:Depends}`` in ``debian/control``.  That gets replaced "
"with the library dependencies at build time.  However shlibs can only make "
"it depend on the major ABI version number, ``2`` in our libnova example, so "
"if new symbols get added in libnova 2.1 a program using these symbols could "
"still be installed against libnova ABI 2.0 which would then crash."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:104
msgid ""
"To make the library dependencies more precise we keep ``.symbols`` files "
"that list all the symbols in a library and the version they appeared in."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:107
msgid ""
"libnova has no symbols file so we can create one.  Start by compiling the "
"package::"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:112
msgid ""
"The ``-nc`` will cause it to finish at the end of compilation without "
"removing the built files.  Change to the build and run ``dpkg-gensymbols`` "
"for the library package::"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:119
msgid "This makes a diff file which you can self apply::"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:123
msgid ""
"Which will create a file named similar to ``dpkg-gensymbolsnY_WWI`` that "
"lists all the symbols.  It also lists the current package version.  We can "
"remove the packaging version from that listed in the symbols file because "
"new symbols are not generally added by new packaging versions, but by the "
"upstream developers::"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:130
msgid "Now move the file into its location, commit and do a test build::"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:138
msgid ""
"If it successfully compiles the symbols file is correct.  With the next "
"upstream version of libnova you would run dpkg-gensymbols again and it will "
"give a diff to update the symbols file."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:143
msgid "C++ Library Symbols Files"
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:145
msgid ""
"C++ has even more exacting standards of binary compatibility than C.  The "
"Debian Qt/KDE Team maintain some scripts to handle this, see their `Working "
"with symbols files <SymbolsFiles_>`_ page for how to use them."
msgstr ""

#: ../ubuntu-packaging-guide/libraries.rst:152
msgid ""
"Junichi Uekawa's `Debian Library Packaging Guide <LibraryGuide_>`_ goes into "
"this topic in more detail."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:3
msgid "Packaging New Software"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:5
msgid ""
"While there are thousands of packages in the Ubuntu archive, there are still "
"a lot nobody has gotten to yet. If there is an exciting new piece of "
"software that you feel needs wider exposure, maybe you want to try your hand "
"at creating a package for Ubuntu or a PPA_. This guide will take you through "
"the steps of packaging new software."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:11
msgid ""
"You will want to read the :doc:`Getting Set Up<./getting-set-up>` article "
"first in order to prepare your development environment."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:15
msgid "Checking the Program"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:17
msgid ""
"The first stage in packaging is to get the released tar from upstream (we "
"call the authors of applications \"upstream\") and check that it compiles "
"and runs."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:20
msgid ""
"This guide will take you through packaging a simple application called GNU "
"Hello which has been posted on GNU.org_."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:23
msgid ""
"If you don't have the build tools lets make sure we have them first.  Also "
"if you don't have the required dependencies lets install those as well."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:26
msgid "Install build tools::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:30
msgid "Download main package::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:34
msgid "Now uncompress main package::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:39
msgid ""
"This application uses the autoconf build system so we want to run "
"``./configure`` to prepare for compilation."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:42
msgid ""
"This will check for the required build dependencies. As ``hello`` is a "
"simple example, ``build-essential`` should provide everything we need. For "
"more complex programs, the command will fail if you do not have the needed "
"libraries and development files. Install the needed packages and repeat "
"until the command runs successfully.::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:50
msgid "Now you can compile the source::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:54
msgid ""
"If compilation completes successfully you can install and run the program::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:60
msgid "Starting a Package"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:62
msgid ""
"``bzr-builddeb`` includes a plugin to create a new package from a template. "
"The plugin is a wrapper around the ``dh_make`` command. You should already "
"have these if you installed ``packaging-dev``. Run the command providing the "
"package name, version number, and path to the upstream tarball::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:71
msgid ""
"When it asks what type of package type ``s`` for single binary. This will "
"import the code into a branch and add the ``debian/`` packaging directory.  "
"Have a look at the contents.  Most of the files it adds are only needed for "
"specialist packages (such as Emacs modules) so you can start by removing the "
"optional example files::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:80
msgid "You should now customise each of the files."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:82
msgid ""
"In ``debian/changelog`` change the version number to an Ubuntu version: "
"``2.7-0ubuntu1`` (upstream version 2.7, Debian version 0, Ubuntu version 1). "
" Also change ``unstable`` to the current development Ubuntu release such as "
"``trusty``."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:87
msgid ""
"Much of the package building work is done by a series of scripts called "
"``debhelper``.  The exact behaviour of ``debhelper`` changes with new major "
"versions, the compat file instructs ``debhelper`` which version to act as.  "
"You will generally want to set this to the most recent version which is "
"``9``."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:93
msgid ""
"``control`` contains all the metadata of the package.  The first paragraph "
"describes the source package. The second and following paragraphs describe "
"the binary packages to be built.  We will need to add the packages needed to "
"compile the application to ``Build-Depends:``. For ``hello``, make sure that "
"it includes at least::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:101
msgid ""
"You will also need to fill in a description of the program in the "
"``Description:`` field."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:104
msgid ""
"``copyright`` needs to be filled in to follow the licence of the upstream "
"source.  According to the hello/COPYING file this is GNU GPL 3 or later."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:107
msgid ""
"``docs`` contains any upstream documentation files you think should be "
"included in the final package."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:110
msgid ""
"``README.source`` and ``README.Debian`` are only needed if your package has "
"any non-standard features, we don't so you can delete them."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:113
msgid ""
"``source/format`` can be left as is, this describes the version format of "
"the source package and should be ``3.0 (quilt)``."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:116
msgid ""
"``rules`` is the most complex file.  This is a Makefile which compiles the "
"code and turns it into a binary package.  Fortunately most of the work is "
"automatically done these days by ``debhelper 7`` so the universal ``%`` "
"Makefile target just runs the ``dh`` script which will run everything needed."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:121
msgid ""
"All of these file are explained in more detail in the :doc:`overview of the "
"debian directory<./debian-dir-overview>` article."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:124
msgid "Finally commit the code to your packaging branch::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:130
msgid "Building the package"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:132
msgid ""
"Now we need to check that our packaging successfully compiles the package "
"and builds the .deb binary package::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:138
msgid ""
"``bzr builddeb`` is a command to build the package in its current location. "
"The ``-us -uc`` tell it there is no need to GPG sign the package.  The "
"result will be placed in ``..``."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:142
msgid "You can view the contents of the package with::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:146
msgid ""
"Install the package and check it works (later you will be able to uninstall "
"it using ``sudo apt-get remove hello`` if you want)::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:151
msgid "You can also install all packages at once using::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:156
msgid "Next Steps"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:158
msgid ""
"Even if it builds the .deb binary package, your packaging may have bugs.  "
"Many errors can be automatically detected by our tool ``lintian`` which can "
"be run on the source .dsc metadata file, .deb binary packages or .changes "
"file::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:166
msgid ""
"To see verbose description of the problems use ``--info`` lintian flag or "
"``lintian-info`` command."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:169
msgid ""
"For Python packages, there is also a ``lintian4python`` tool that provides "
"some additional lintian checks."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:172
msgid ""
"After making a fix to the packaging you can rebuild using ``-nc`` \"no "
"clean\" without having to build from scratch::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:177
msgid ""
"Having checked that the package builds locally you should ensure it builds "
"on a clean system using ``pbuilder``. Since we are going to upload to a PPA "
"(Personal Package Archive) shortly, this upload will need to be *signed* to "
"allow Launchpad to verify that the upload comes from you (you can tell the "
"upload will be signed because the ``-us`` and ``-uc`` flags are not passed "
"to ``bzr builddeb`` like they were before). For signing to work you need to "
"have set up GPG. If you haven't set up ``pbuilder-dist`` or GPG yet, "
":doc:`do so now<./getting-set-up>`::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:190
msgid ""
"When you are happy with your package you will want others to review it.  You "
"can upload the branch to Launchpad for review::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:195
msgid ""
"Uploading it to a PPA will ensure it builds and give an easy way for you and "
"others to test the binary packages.  You will need to set up a PPA in "
"Launchpad and then upload with ``dput``::"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:201
msgid "See :doc:`uploading<./udd-uploading>` for more information."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:203
msgid ""
"You can ask for reviews in ``#ubuntu-motu`` IRC channel, or on the `MOTU "
"mailing list <ubuntu-motu_>`_.  There might also be a more specific team you "
"could ask such as the GNU team for more specific questions."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:208
msgid "Submitting for inclusion"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:210
msgid ""
"There are a number of paths that a package can take to enter Ubuntu. In most "
"cases, going through Debian first can be the best path. This way ensures "
"that your package will reach the largest number of users as it will be "
"available in not just Debian and Ubuntu but all of their derivatives as "
"well. Here are some useful links for submitting new packages to Debian:"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:217
msgid ""
"`Debian Mentors FAQ <MentorsFAQ_>`_ - debian-mentors is for the mentoring of "
"new and prospective Debian Developers. It is where you can find a sponsor to "
"upload your package to the archive."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:221
msgid ""
"`Work-Needing and Prospective Packages <WNPP_>`_ - Information on how to "
"file \"Intent to Package\" and \"Request for Package\" bugs as well as list "
"of open ITPs and RFPs."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:225
msgid ""
"`Debian Developer's Reference, 5.1. New packages <DevRef_>`_ - The entire "
"document is invaluable for both Ubuntu and Debian packagers. This section "
"documents processes for submitting new packages."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:229
msgid ""
"In some cases, it might make sense to go directly into Ubuntu first. For "
"instance, Debian might be in a freeze making it unlikely that your package "
"will make it into Ubuntu in time for the next release. This process is "
"documented on the `\"New Packages\" <NewPackages_>`_ section of the Ubuntu "
"wiki."
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:235
msgid "Screenshots"
msgstr ""

#: ../ubuntu-packaging-guide/packaging-new-software.rst:237
msgid ""
"Once you have uploaded a package to debian, you should add screenshots to "
"allow propective users to see what the program is like. These should be "
"uploaded to http://screenshots.debian.net/upload ."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:3
msgid "Patches to Packages"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:5
msgid ""
"Sometimes, Ubuntu package maintainers have to change the upstream source "
"code in order to make it work properly on Ubuntu.  Examples include, patches "
"to upstream that haven't yet made it into a released version, or changes to "
"the upstream's build system needed only for building it on Ubuntu.  We could "
"change the upstream source code directly, but doing this makes it more "
"difficult to remove the patches later when upstream has incorporated them, "
"or extract the change to submit to the upstream project.  Instead, we keep "
"these changes as separate patches, in the form of diff files."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:14
msgid ""
"There are a number of different ways of handling patches in Debian packages, "
"fortunately we are standardizing on one system, `Quilt`_, which is now used "
"by most packages."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:18
msgid "Let's look at an example package, ``kamoso`` in Trusty::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:22
msgid ""
"The patches are kept in ``debian/patches``.  This package has one patch "
"``kubuntu_01_fix_qmax_on_armel.diff`` to fix a compile failure on ARM.  The "
"patch has been given a name to describe what it does, a number to keep the "
"patches in order (two patches can overlap if they change the same file) and "
"in this case the Kubuntu team adds their own prefix to show the patch comes "
"from them rather than from Debian."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:29
msgid "The order of patches to apply is kept in ``debian/patches/series``."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:32
msgid "Patches with Quilt"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:34
msgid ""
"Before working with Quilt you need to tell it where to find the patches.  "
"Add this to your ``~/.bashrc``::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:39
msgid "And source the file to apply the new export::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:43
msgid ""
"By default all patches are applied already to UDD checkouts or downloaded "
"packages.  You can check this with::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:49
msgid "If you wanted to remove the patch you would run ``pop``::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:57
msgid "And to apply a patch you use ``push``::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:67
msgid "Adding a New Patch"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:69
msgid ""
"To add a new patch you need to tell Quilt to create a new patch, tell it "
"which files that patch should change, edit the files then refresh the patch::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:81
msgid ""
"The ``quilt add`` step is important, if you forget it the files will not end "
"up in the patch."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:84
msgid ""
"The change will now be in "
"``debian/patches/kubuntu_02_program_description.diff`` and the ``series`` "
"file will have had the new patch added to it.  You should add the new file "
"to the packaging::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:94
msgid ""
"Quilt keeps its metadata in the ``.pc/`` directory, so currently you need to "
"add that to the packaging too.  This should be improved in future."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:97
msgid ""
"As a general rule you should be careful adding patches to programs unless "
"they come from upstream, there is often a good reason why that change has "
"not already been made.  The above example changes a user interface string "
"for example, so it would break all translations.  If in doubt, do ask the "
"upstream author before adding a patch."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:105
msgid "Patch Headers"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:107
msgid ""
"We recommend that you tag every patch with DEP-3_ headers by putting them at "
"the top of patch file. Here are some headers that you can use:"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:0
msgid "Description"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:110
msgid ""
"Description of what the patch does. It is formatted like ``Description`` "
"field in ``debian/control``: first line is short description, starting with "
"lowercase letter, the next lines are long description, indented with a space."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:0
msgid "Author"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:114
msgid "Who wrote the patch (i.e. \"Jane Doe <packager@example.com>\")."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:0
msgid "Origin"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:115
msgid ""
"Where this patch comes from (i.e. \"upstream\"), when *Author* is not "
"present."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:0
msgid "Bug-Ubuntu"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:117
msgid ""
"A link to Launchpad bug, a short form is preferred (like "
"*https://bugs.launchpad.net/bugs/XXXXXXX*). If there are also bugs in "
"upstream or Debian bugtrackers, add *Bug* or *Bug-Debian* headers."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:0
msgid "Forwarded"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:121
msgid ""
"Whether the patch was forwarded upstream. Either \"yes\", \"no\" or \"not-"
"needed\"."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:0
msgid "Last-Update"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:123
msgid "Date of the last revision (in form \"YYYY-MM-DD\")."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:127
msgid "Upgrading to New Upstream Versions"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:129
msgid ""
"To upgrade to the new version, you can use ``bzr merge-upstream`` command::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:133
msgid ""
"When you run this command, all patches will be unapplied, because they can "
"become out of date. They might need to be refreshed to match the new "
"upstream source or they might need to be removed altogether. To check for "
"problems, apply the patches one at a time::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:145
msgid ""
"If it can be reverse-applied this means the patch has been applied already "
"by upstream, so we can delete the patch::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:151
msgid "Then carry on::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:156
msgid ""
"It is a good idea to run refresh, this will update the patch relative to the "
"changed upstream source::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:162
msgid "Then commit as usual::"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:168
msgid "Making A Package Use Quilt"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:170
msgid ""
"Modern packages use Quilt by default, it is built into the packaging format. "
" Check in ``debian/source/format`` to ensure it says ``3.0 (quilt)``."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:174
msgid ""
"Older packages using source format 1.0 will need to explicitly use Quilt, "
"usually by including a makefile into ``debian/rules``."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:179
msgid "Configuring Quilt"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:181
msgid ""
"You can use ``~/.quiltrc`` file to configure quilt. Here are some options "
"that can be useful for using quilt with debian/packages:"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:195
msgid "Other Patch Systems"
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:197
msgid ""
"Other patch systems used by packages include ``dpatch`` and ``cdbs simple-"
"patchsys``, these work similarly to Quilt by keeping patches in "
"``debian/patches`` but have different commands to apply, un-apply or create "
"patches. You can find out which patch system is used by a package by using "
"the ``what-patch`` command (from the ``ubuntu-dev-tools`` package). You can "
"use ``edit-patch``, shown in :ref:`previous chapters <working-on-a-fix>`, as "
"a reliable way to work with all systems."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:205
msgid ""
"In even older packages changes will be included directly to sources and kept "
"in the ``diff.gz`` source file.  This makes it hard to upgrade to new "
"upstream versions or differentiate between patches and is best avoided."
msgstr ""

#: ../ubuntu-packaging-guide/patches-to-packages.rst:209
msgid ""
"Do not change a package's patch system without discussing it with the Debian "
"maintainer or relevant Ubuntu team.  If there is no existing patch system "
"then feel free to add Quilt."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:3
msgid "Security and Stable Release Updates"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:6
msgid "Fixing a Security Bug in Ubuntu"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:11
msgid ""
"Fixing security bugs in Ubuntu is not really any different than :doc:`fixing "
"a regular bug in Ubuntu<./fixing-a-bug>`, and it is assumed that you are "
"familiar with patching normal bugs. To demonstrate where things are "
"different, we will be updating the dbus package in Ubuntu 12.04 LTS (Precise "
"Pangolin) for a security update."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:19
msgid "Obtaining the source"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:21
msgid ""
"In this example, we already know we want to fix the dbus package in Ubuntu "
"12.04 LTS (Precise Pangolin). So first you need to determine the version of "
"the package you want to download. We can use the ``rmadison`` to help with "
"this::"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:30
msgid ""
"Typically you will want to choose the highest version for the release you "
"want to patch that is not in -proposed or -backports. Since we are updating "
"Precise's dbus, you'll download 1.4.18-1ubuntu1.4 from precise-updates::"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:38
msgid "Patching the source"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:39
msgid ""
"Now that we have the source package, we need to patch it to fix the "
"vulnerability. You may use whatever patch method that is appropriate for the "
"package, including :doc:`UDD techniques<./udd-intro>`, but this example will "
"use ``edit-patch`` (from the ubuntu-dev-tools package). ``edit-patch`` is "
"the easiest way to patch packages and it is basically a wrapper around every "
"other patch system you can imagine."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:46
msgid "To create your patch using ``edit-patch``::"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:51
msgid ""
"This will apply the existing patches and put the packaging in a temporary "
"directory. Now edit the files needed to fix the vulnerability.  Often "
"upstream will have provided a patch so you can apply that patch::"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:57
msgid ""
"After making the necessary changes, you just hit Ctrl-D or type exit to "
"leave the temporary shell."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:61
msgid "Formatting the changelog and patches"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:63
msgid ""
"After applying your patches you will want to update the changelog. The "
"``dch`` command is used to edit the ``debian/changelog`` file and ``edit-"
"patch`` will launch ``dch`` automatically after un-applying all the patches. "
"If you are not using ``edit-patch``, you can launch ``dch -i`` manually. "
"Unlike with regular patches, you should use the following format (note the "
"distribution name uses precise-security since this is a security update for "
"Precise) for security updates::"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:80
msgid ""
"Update your patch to use the appropriate patch tags. Your patch should have "
"at a minimum the Origin, Description and Bug-Ubuntu tags. For example, edit "
"debian/patches/99-fix-a-vulnerability.patch to have something like::"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:91
msgid ""
"Multiple vulnerabilities can be fixed in the same security upload; just be "
"sure to use different patches for different vulnerabilities."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:95
msgid "Test and Submit your work"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:97
msgid ""
"At this point the process is the same as for :doc:`fixing a regular bug in "
"Ubuntu<./fixing-a-bug>`. Specifically, you will want to:"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:100
msgid ""
"Build your package and verify that it compiles without error and without any "
"added compiler warnings"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:102
msgid "Upgrade to the new version of the package from the previous version"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:103
msgid ""
"Test that the new package fixes the vulnerability and does not introduce any "
"regressions"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:105
msgid ""
"Submit your work via a Launchpad merge proposal and file a Launchpad bug "
"being sure to mark the bug as a security bug and to subscribe ``ubuntu-"
"security-sponsors``"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:109
msgid ""
"If the security vulnerability is not yet public then do not file a merge "
"proposal and ensure you mark the bug as private."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:112
msgid ""
"The filed bug should include a Test Case, i.e. a comment which clearly shows "
"how to recreate the bug by running the old version then how to ensure the "
"bug no longer exists in the new version."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:116
msgid ""
"The bug report should also confirm that the issue is fixed in Ubuntu "
"versions newer than the one with the proposed fix (in the above example "
"newer than Precise).  If the issue is not fixed in newer Ubuntu versions you "
"should prepare updates for those versions too."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:123
msgid "Stable Release Updates"
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:125
msgid ""
"We also allow updates to releases where a package has a high impact bug such "
"as a severe regression from a previous release or a bug which could cause "
"data loss.  Due to the potential for such updates to themselves introduce "
"bugs we only allow this where the change can be easily understood and "
"verified."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:130
msgid ""
"The process for Stable Release Updates is just the same as the process for "
"security bugs except you should subscribe ``ubuntu-sru`` to the bug."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:133
msgid ""
"The update will go into the ``proposed`` archive (for example ``precise-"
"proposed``) where it will need to be checked that it fixes the problem and "
"does not introduce new problems.  After a week without reported problems it "
"can be moved to ``updates``."
msgstr ""

#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:138
msgid ""
"See the `Stable Release Updates wiki page <SRUWiki_>`_ for more information."
msgstr ""

msgid "translator-credits"
msgstr ""