ubuntu-packaging-guide - en to ru translation catalogue (467 entries)

en: autopkgtest: Automatic testing for packages
ru: autopkgtest: Автоматическое тестирование пакетов

en: 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:
ru: `Спецификация DEP 8 <DEP8_>`_ определяет, как можно легко интегрировать автоматическое тестирование в ваши пакеты. Для этого, необходимо:

en: add a file called ``debian/tests/control`` which specifies the requirements for the testbed,
ru: добавить файл ``debian/tests/control``, который определяет требования к тестовому окружению,

en: add the tests in ``debian/tests/``.
ru: добавить тесты в ``debian/tests``.

en: Testbed requirements
ru: Требования к тестовому окружению

en: 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.
ru: В файле ``debian/tests/control`` вы можете определить требования к тестовому окружению. Например, если тесты не проходят при сборке, или требуются права ``root`` -- вы перечисляете необходимые для тестов пакеты. В `Спецификации DEP 8 <DEP8_>`_  вы найдёте все доступные опции.

en: Below we are having a look at the ``glib2.0`` source package. In a very simple case the file would look like this::
ru: Ниже мы рассмотрим пакет исходного кода ``glib2.0``. В очень простом случае он будет выглядеть так::

en: For the test in ``debian/tests/build`` this would ensure that the packages ``libglib2.0-dev`` and ``build-essential`` are installed.
ru: Это будет означать, что для теста ``debian/tests/build`` требуются пакеты ``libglib2.0-dev`` и ``build-essential``.

en: 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.
ru: В поле ``Depends`` можно указать ``@``, если вы хотите установки всех бинарных пакетов, собранных из рассматриваемого пакета исходного кода.

en: The actual tests
ru: Настоящие тесты

en: The accompanying test for the example above might be:
ru: Тест, соответствующий рассмотренному выше примеру, будет выглядеть так:

en: 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.
ru: Здесь небольшая программа на языке C копируется во временную директорию, затем компилируется с использованием системных библиотек (с использованием флагов и путей к библиотекам, определённых через ``pkg-config``). Затем запускается скомпилированный файл, который запускает несколько основных функций glib.

en: 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.
ru: Хотя этот тест очень маленький и простой, он проверяет многое: что ваш -dev пакет имеет все необходимые зависимости, что ваш пакет устанавливает рабочие файлы pkg-config, заголовочные файлы и библиотеки помещаются в нужное место, или что компилятор и компоновщик работают. Это помогает обнаружить критические ошибки на ранней стадии.

en: Executing the test
ru: Выполнение теста

en: 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::
ru: Система непрерывной интеграции Ubuntu CI использует эмулятор QEMU и запускает тесты из пакетов в архиве, с включённом флагом ``-proposed``. Чтобы вручную получить то же окружение, сначала необходимо установить следующие пакеты:

en: Now build a testbed with::
ru: Теперь выполните сборку тестового окружения, выполнив следующее:

en: (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``.
ru: (Более подробно о выборе других релизов, архитектур, целевых директорий, и об использовании прокси -- в manpage и в выводе опции ``--help``). Эта команда выполнит сборку, например ``adt-trusty-amd64-cloud.img``.

en: Then run the tests of a source package like ``libpng`` in that QEMU image::
ru: Теперь запустите тесты исходного пакета, например ``libpng``, в образе QEMU::

en: Further examples
ru: Дальнейшие примеры

en: This list is not comprehensive, but might help you get a better idea of how automated tests are implemented and used in Ubuntu.
ru: Этот список не полон, но может помочь вам получить представление о том, как автоматические тесты реализованы, и как они используются в Ubuntu.

en: The `libxml2 tests <libxml2_>`_ are very similar. They also run a test-build of a simple piece of C code and execute it.
ru: Для библиотеки `libxml2 <libxml2_>`_ , тесты очень похожи. Они так же запускают тестовую сборку простого кода на C и выполняют его.

en: 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.
ru: `Тесты пакета gtk+3.0 <gtk3_>`_ также компилируют/линкуют/запускают проверку в тесте "build". Также есть дополнительный тест "python3-gi", проверяющий что библиотека GTK может быть использована из языка Python.

en: In the `ubiquity tests <ubiquity_>`_ the upstream test-suite is executed.
ru: В пакете `ubiquity tests <ubiquity_>`_ используется набор тестов родительского пакета

en: 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.
ru: Пакет  `gvfs tests <gvfs_>`_ -- очень интересный пример: он тестирует свой функционал "по полной", включая эмуляцию CD, Samba, DAV и прочих компонентов.

en: Ubuntu infrastructure
ru: Инфраструктура Ubuntu

en: 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.
ru: Пакеты с включённым ``autopkgtest`` будут тестироваться при выгрузке, или если обновятся какие-либо зависимости. Результат работы `автоматического запуска тестов autopkgtest  <jenkins_>`_ может быть просмотрен на сайте, и он регулярно обновляется.

en: Getting the test into Ubuntu
ru: Добавление теста в Ubuntu

en: 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:
ru: Процесс добавления и отправки autopkgtest-теста для пакетов очень похож на :doc:`процесс исправления ошибок в Ubuntu<./fixing-a-bug>`. Достаточно лишь:

en: run ``bzr branch ubuntu:<packagename>``,
ru: выполните ``bzr branch ubuntu:<имя_пакета>``,

en: edit ``debian/control`` to enable the tests,
ru: включите тесты в ``debian/control``,

en: add the ``debian/tests`` directory,
ru: создайте директорию ``debian/tests``,

en: write the ``debian/tests/control`` based on the `DEP 8 Specification <dep8_>`_,
ru: создайте ``debian/tests/control``, основываясь на `Спецификации DEP 8 <dep8_>`_,

en: add your test case(s) to ``debian/tests``,
ru: добавьте ваши тесты в ``debian/tests``,

en: commit your changes, push them to Launchpad, propose a merge and get it reviewed just like any other improvement in a source package.
ru: закоммитьте ваши изменения, отправьте их на Launchpad, предложите merge и дождитесь его рассмотрения  и дождаться, -- в точности как с любыми другими улучшениями в исходных пакетах.

en: What you can do
ru: Чем вы можете помочь

en: 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.
ru: Команда Ubuntu Engineering собрала `список необходимых тестов <requiredtests_>`_, в котором пакеты, нуждающиеся в тестировании, распределены по категориям. Там можно найти примеры таких тестов и взять их на себя.

en: 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.
ru: Если вы столкнётесь с проблемами, присоединяйтесь к IRC на канал  `#ubuntu-quality IRC channel <qualityirc_>`_: разработчики наверняка вам помогут.

en: Backporting software updates
ru: Бэкпортирование обновлений программ

en: 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.
ru: Порой может потребоваться добавить функционал в стабильный релиз, который не связан с исправлением критических проблем. В подобных случаях, есть два варианта: либо вы `загрузите его в PPA <ppadoc_>`_, или подготовите бэкпорт (backport).

en: Personal Package Archive (PPA)
ru: Персональные архивы пакетов (PPA)

en: 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.
ru: Использование PPA имеет ряд преимуществ. Это достаточно просто, вам не понадобится одобрение от кого бы то ни было, но недостаток в том, что пользователям придётся вручную подключать PPA. Это нестандартный источник приложений.

en: The `PPA documentation on Launchpad <ppadoc_>`_ is fairly comprehensive and should get you up and running in no time.
ru: `Документация к PPA на Launchpad <ppadoc_>`_ достаточно исчерпывающая и поможет вам быстро начать работу с ним.

en: Official Ubuntu Backports
ru: Официальные бэкпорты Ubuntu

en: 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.
ru: Целью проекта Backports является предоставление пользователям новой функциональности. Из-за рисков уменьшения стабильности при портировании новшеств, бэкпорты недоступны пользователям, пока они не включат их. Поэтому бэкпорты не являются местом для исправления ошибок. Если в пакете Ubuntu обнаружена ошибка, она должна быть исправлена через :doc:`обновления безопасности и стабильности<./security-and-stable-release-updates>`.

en: 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.
ru: Когда вы определите, требуется ли вам адаптировать ваши изменения для стабильного релиза, вам будет необходимо собрать и протестировать ваш пакет на данном релизе. Команда ``pbuilder-dist`` (из пакета ``ubuntu-dev-tools``) поможет вам сделать это.

en: 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.
ru: Чтобы подать заявку на бэкпорт, можно использовать утилиту ``requestbackport`` (также из пакета ``ubuntu-dev-tools``). Она определит все промежуточные выпуски, для которых пакет также придётся бэкпортировать, покажет, какие пакеты зависят от данного, и создаст заявку. Она также включит список требуемых тестов в заявку.

en: Using Chroots
ru: Использование chroot-окружений

en: 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``.
ru: Если вы пользуетесь одной из версий Ubuntu, но работаете над пакетами для другой версии, вы можете создать среду другой версии с помощью ``chroot``.

en: 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.
ru: Использование ``chroot`` позволит вам иметь в распоряжении полную файловую систему другого дистрибутива для удобства работы. Это позволяет избежать затрат, связанных с установкой виртуальной машины.

en: Creating a Chroot
ru: Создание chroot

en: Use the command ``debootstrap`` to create a new chroot::
ru: Используйте команду ``debootstrap``, чтобы создать новый chroot::

en: This will create a directory ``trusty`` and install a minimal trusty system into it.
ru: Это создаст папку ``trusty`` и установит минимальный образ trusty в неё.

en: If your version of ``debootstrap`` does not know about Trusty you can try upgrading to the version in ``backports``.
ru: Если ваша версия ``debootstrap`` не определит Trusty, попробуйте обновиться до версии в ``backports``.

en: You can then work inside the chroot::
ru: После этого вы можете работать внутри chroot::

en: Where you can install or remove any package you wish without affecting your main system.
ru: Где можно установить или удалить любой пакет, который вы хотите, без ущерба для основной системы.

en: You might want to copy your GPG/ssh keys and Bazaar configuration into the chroot so you can access and sign packages directly::
ru: Вы можете скопировать свои ключи GPG и SSH, а также конфигурацию Bazaar в chroot, чтобы получать доступ и подписывать пакеты непосредственно оттуда::

en: To stop apt and other programs complaining about missing locales you can install your relevant language pack::
ru: Чтобы apt и другие программы не жаловались на отсутствующие локали, можно установить соответствующий языковой пакет::

en: If you want to run X programs you will need to bind the /tmp directory into the chroot, from outside the chroot run::
ru: Если вам нужно запускать программы, использующие X-сервер, вам нужно добавить в chroot директорию /tmp, для этого снаружи chroot запустите::

en: Some programs may need you to bind /dev or /proc.
ru: Для некоторых программ, возможно, понадобится привязать /dev или /proc.

en: For more information on chroots see our `Debootstrap Chroot wiki page <DebootstrapChroot_>`_.
ru: На странице `Debootstrap Chroot вики <DebootstrapChroot_>`_ вы найдёте более подробную информацию о chroot-окружении.

en: Alternatives
ru: Альтернативы

en: 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.
ru: SBuild -- система, похожая на PBuilder, используемая для создания окружения, в котором выполняются тестовые сборки пакета. Она близка к той, которую использует Launchpad для сборки пакетов, но её установка несколько сложнее, чем PBuilder. Более полную информацию можно найти на викистранице `Система Сборки Security Team <SecurityEnv_>`_.

en: 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.
ru: Полные виртуальные машины могут быть полезны для создания пакетов и тестирования программ.  TestDrive — это программа, позволяющая автоматизировать синхронизацию и запуск ежедневных ISO-образов. Подробнее смотрите `wiki-страницу TestDrive <TestDrive_>`_.

en: 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.
ru: Можно также настроить pbuilder так, чтобы он приостанавливался при обнаружении ошибки сборки.  Скопируйте C10shell из /usr/share/doc/pbuilder/examples в каталог и используйте аргумент ``--hookdir=``, чтобы указать на него.

en: 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.
ru: Облачный сервис `Amazon EC2 <EC2_>`_ позволит вам приобрести компьютер в облаке, цена за который -- всего несколько центов в час. Там вы можете установить Ubuntu любой поддерживаемой версии и работать с пакетами удалённо, что очень удобно, если требуется сборка множества пакетов одновременно, или если нужно преодолеть медленную скорость Интернет-подключения.

en: Communication in Ubuntu Development
ru: Коммуникация при Разработке в Ubuntu

en: 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.
ru: В проекте, где подвергаются изменениям тысячи строк кода, принимается множество решений, и где сотни людей должны взаимодействовать каждый день, важно иметь эффективную связь.

en: Mailing lists
ru: Почтовые рассылки

en: 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.
ru: Почтовые рассылки — это достаточно эффективный инструмент, если вы хотите обсудить идеи в команде и убедиться что вы оповестили всех, несмотря на различия в часовых поясах.

en: In terms of development, these are the most important ones:
ru: С точки зрения разработки, это наиболее важные из рассылок:

en: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (announce-only, the most important development announcements go here)
ru: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (только анонсы, самые важные объявления разработки попадают сюда)

en: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (general Ubuntu development discussion)
ru: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (главная дискуссия разработчиков Ubuntu )

en: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (MOTU Team discussion, get help with packaging)
ru: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (обсуждения команды MOTU, получение справки по созданию пакетов)

en: IRC Channels
ru: Каналы IRC

en: For real-time discussions, please connect to irc.freenode.net and join one or any of these channels:
ru: Для онлайн-дискуссии подключитесь к irc.freenode.net и присоединяйтесь к любому из каналов:

en: #ubuntu-devel (for general development discussion)
ru: #ubuntu-devel (для главной дискуссии разработчиков)

en: #ubuntu-motu (for MOTU team discussion and generally getting help)
ru: #ubuntu-motu (для обсуждений команды MOTU и получения помощи)

en: Basic Overview of the ``debian/`` Directory
ru: Общий обзор каталога ``debian/``

en: 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.
ru: Эта статья даёт краткие пояснения к различным файлам, важным для создания пакетов Ubuntu, которые содержатся в каталоге ``debian/``. Самыми важными из них являются ``changelog``, ``control``, ``copyright``, and ``rules``. Они требуются для всех пакетов. Многие дополнительные файлы в ``debian/`` могут использоваться для настройки и изменения поведения пакета. Некоторые из этих файлов обсуждаются в этой статье, но это далеко не полный список.

en: The changelog
ru: Файл changelog

en: 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``::
ru: Этот файл, как следует из его названия — это список изменений, внесённых в каждую версию. Он имеет особый формат, который показывает имя пакета, версию, дистрибутив, изменения, и кто вносил изменения в данное время. Если у вас есть ключ GPG (смотрите: :doc:`Подготовка<./getting-set-up/>`), убедитесь, что вы используете в ``changelog`` те же имя и адрес электронной почты, что и в вашем ключе. Ниже приведен шаблон ``changelog``::

en: 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.
ru: Формат (особенно даты) важен. Дата должна быть в формате :rfc:`5322`, который можно увидеть при выполнении команды ``date -R``. Для удобства, можно использовать для редактирования changelog команду ``dch``. Она обновит дату автоматически.

en: Minor bullet points are indicated by a dash "-", while major points use an asterisk "*".
ru: Пункты с незначительными изменениями отмечаются дефисом «-», в то время как в важных пунктах используется звездочка «*».

en: If you are packaging from scratch, ``dch --create`` (``dch`` is in the ``devscripts`` package) will create a standard ``debian/changelog`` for you.
ru: Если вы создаёте пакет «с нуля», ``dch --create`` (``dch`` находится в пакете ``devscripts``) создаст для вас стандартный файл ``debian/changelog``.

en: Here is a sample ``changelog`` file for hello::
ru: Вот пример файла ``changelog`` для hello::

en: 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.
ru: Обратите внимание, что версия имеет ``-0ubuntu1`` добавленный к нему, это - distro версия, используемая так, чтобы упаковка могла быть обновлена (чтобы исправить ошибки, например) с новыми закачками в той же исходной версии выпуска.

en: 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``).
ru: Ubuntu и Debian используют немного различающиеся схемы нумерации версий пакетов, чтобы избежать конфликта пакетов с одной и той же исходной версией. Если пакет Debian был изменён в Ubuntu, к концу Debian-версии добавляется ``ubuntuX`` (где ``X`` — номер редакции в  Ubuntu). Таким образом, если пакет Debian hello ``2.6-1`` был изменён в Ubuntu, номер версии будет ``2.6-1ubuntu1``. Если пакет приложения в Debian не существует, то редакция Debian равна ``0`` (например, ``2.6-0ubuntu1``).

en: For further information, see the `changelog section (Section 4.4) <policy-changelog_>`_ of the Debian Policy Manual.
ru: Более подробную информацию можно найти на странице  `changelog (Глава 4.4) <policy-changelog_>`_ документа Debian Policy Manual.

en: The control file
ru: Файл control

en: 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.
ru: Файл ``control`` содержит информацию, которую использует менеджер пакетов (такой, как ``apt-get``, ``synaptic`` или ``adept``), сборочные зависимости, информацию мэйнтейнера и многое другое.

en: For the Ubuntu ``hello`` package, the ``control`` file looks something like this:
ru: Для пакета Ubuntu ``hello`` файл ``control`` выглядит следующим образом:

en: 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.
ru: Первый абзац описывает исходный пакет, включая список пакетов, требуемых для сборки данного пакета из исходного кода, в поле ``Build-Depends``. Он также содержит некоторую метаинформацию, такую как имя мэйнтейнера, версию Debian Policy, с которой компилируется пакет, местоположение репозитория управления версиями и домашнюю страницу апстрима.

en: 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.
ru: Заметьте, что в Ubuntu мы указываем в поле ``Maintainer`` общий адрес, так как любой человек может изменить любой пакет (в отличие от Debian, где правом изменения пакетов обладают лишь отдельные люди или команда). Пакеты в Ubuntu, как правило, должны в поле ``Maintainer`` содержать  ``Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>``. Если поле Maintainer изменено, старое значение должно быть сохранено в поле ``XSBC-Original-Maintainer``. Это можно сделать автоматически сценарием ``update-maintainer`` из пакета ``ubuntu-dev-tools``. Для дальнейшей информации смотрите `Debian Maintainer Field spec <MaintField_>`_ в Ubuntu wiki.

en: Each additional paragraph describes a binary package to be built.
ru: Каждый дополнительный абзац описывает бинарный пакет, который будет создан.

en: For further information, see the `control file section (Chapter 5) <policy-control_>`_ of the Debian Policy Manual.
ru: Более подробную информацию можно найти на странице  `секции control-файла (Глава 5) <policy-control_>`_ документа Debian Policy Manual.

en: The copyright file
ru: Файл copyright

en: 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``.
ru: Файл содержит информацию о копирайтах исходных кодов и самого пакета. Ubuntu и `Debian Policy (Глава 12.5) <policy-copyright_>`_ требуют, чтобы каждый пакет устанавливал неизменную копию копирайта и информации по лицензированию в папку ``/usr/share/doc/$(имя_пакета)/copyright``

en: 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::
ru: Как правило, информацию об авторских правах можно найти в файле ``COPYING`` в каталоге с исходным кодом программы. Этот файл должен включать такую информацию, как имена автора и упаковщика, URL, из которого получен источник, строку со значком копирайта с указанием года и владельца авторских прав, а также сам текст авторского права. Шаблон для примера::

en: This example follows the `Machine-readable debian/copyright <DEP5_>`_ format. You are encouraged to use this format as well.
ru: Пример испольует `машино-понятный формат debian/copyright <DEP5_>`_, и авторам пакетов также рекомендуется следовать этому формату.

en: The rules file
ru: Файл rules

en: 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.
ru: Последний файл, который мы рассмотрим, это ``rules``. Он выполняет всю работу по сборке нашего пакета. Это Makefile, в котором есть функции компиляции программы, её установки и создания ``.deb``-пакета из установленных файлов. В нём есть также функция очистки файлов сборки, которая удаляет всё, кроме собственно пакета исходного кода.

en: Here is a simplified version of the rules file created by ``dh_make`` (which can be found in the ``dh-make`` package):
ru: Вот упрощённый пример файла rules, созданного ``dh_make`` (который можно найти в пакете ``dh-make``):

en: 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.
ru: Давайте рассмотрим этот файл внимательнее. На каждом этапе сборки ``debian/rules`` вызывается с аргументом, который передаётся ``/usr/bin/dh``, который, в свою очередь, вызывает необходимые команды ``dh_*``.

en: ``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::
ru: ``dh`` запускает последовательность команд debhelper. Поддерживаемые последовательности соответствуют целям файла ``debian/rules``: «build», «clean», «install», «binary-arch», «binary-indep» и «binary». Чтобы увидеть, какие команды выполняются в каждой цели, наберите::

en: 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.
ru: Командам из последовательности ``binary-indep`` передаётся аргумент ``-i``, чтобы они затрагивали только архитектурно-независимые пакеты, а командам из последовательности ``binary-arch`` — аргумент ``-a``, чтобы онм затрагивали только архитектурно-зависимые пакеты.

en: 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.
ru: Каждая команда debhelper  при  её успешном выполненении делает запись в журнале ``debian/package.debhelper.log`` (который затем удаляет dh_clean.) Таким образом dh может определить, какие команды уже были выполнены и для каких пакетов, что помогает избежать повторного выполнения этих команд.

en: 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.
ru: При каждом запуске ``dh`` он изучает журнал, находит добавленные последними команды, которые относятся к указанной последовательности. Затем он продолжает выполнение со следующей команды в этой последовательности. Опции ``--until``, ``--before``, ``--after`` и ``--remaining`` могут изменить это поведение.

en: 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.)
ru: Если в ``debian/rules`` есть функция с именем, похожим на ``override_dh_команда``, то вместо данной команды ``dh`` выполнит данную функцию. Эта функция может запустить ту же команду с другими аргументами, или же совершенно другую команду. (Замечание: для использования этой функциональности при сборке требуется пакет debhelper версии не менее 7.0.50).

en: 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.
ru: За дополнительными примерами обратитесь к ``/usr/share/doc/debhelper/examples/`` и ``man dh``. Смотрите также `раздел о файле  rules (Раздел 4.9) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules>`_ в «Debian Policy Manual».

en: Additional Files
ru: Дополнительные файлы

en: The install file
ru: Файл install

en: The ``install`` file is used by ``dh_install`` to install files into the binary package. It has two standard use cases:
ru: Файл ``install`` используется  ``dh_install`` для установки файлов в двоичный пакет. Он имеет два стандартных варианта использования:

en: To install files into your package that are not handled by the upstream build system.
ru: Для установки в ваш пакет файлов, не установленных оригинальной системой сборки.

en: Splitting a single large source package into multiple binary packages.
ru: Разделение одного большого пакета источника на несколько бинарных пакетов.

en: 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``::
ru: В первом случае файл ``install`` должен содержать одну строку для каждого устанавливаемого файла, указывающую как файл, так и установочный каталог. Например, следующий файл ``install`` установит сценарий ``foo`` из корневого каталога пакета исходного кода в ``usr/bin`` и desktop-файл из каталога ``debian`` в ``usr/share/applications``::

en: 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::
ru: Если пакет исходного кода производит несколько двоичных пакетов, ``dh`` установит файлы в ``debian/tmp`` вместо установки непосредственно в ``debian/<пакет>``. Файлы, установленные в ``debian/tmp`` затем можно переместить в отдельные двоичные пакеты с помощью нескольких файлов ``$имя_пакета.install``. Это часто делается, чтобы разбить большое количество не зависящих от архитектуры данных из зависящих от архитектуры пакетов в пакеты ``Architecture: all``. В этом случае нужно указать только имена устанавливаемых файлов (или каталогов), без установочного каталога. Например, ``foo.install``, содерщащий только зависящие от архитектуры файлы, может выглядеть наподобие::

en: While ``foo-common.install`` containing only the architecture independent file might look like::
ru: В то время как ``foo-common.install``, содержащий только не зависящие от архитектуры файлы, может выглядеть так::

en: This would create two binary packages, ``foo`` and ``foo-common``. Both would require their own paragraph in ``debian/control``.
ru: Будут созданы два двоичных пакета: ``foo`` и ``foo-common``. Для обоих требуется их собственный абзац в ``debian/control``.

en: 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.
ru: Для дополнительных подробностей смотрите ``man dh_install`` и `раздел о файле install (Раздел 5.11) <http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install>`_  в «Debian New Maintainers' Guide».

en: The watch file
ru: Файл watch

en: 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::
ru: Файл ``debian/watch`` позволяет автоматически проверять наличие новых версий в апстриме с помощью инструмента ``uscan`` из пакета ``devscripts``. Первой строкой файла watch должна быть версия формата (3 на момент написания этого руководства), а следующий строки содержат любые URL для анализа. Например::

en: 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::
ru: Запуск ``uscan`` в корневом каталоге исходников сравнит номер апстрим-версии в ``debian/changelog`` с последней доступной в апстриме версией. Если в апстриме найдена новая версия, она будет автоматически загружена. Например::

en: 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::
ru: Если ваши tarball-файлы обитают на Launchpad, файл ``debian/watch`` имеет немного более сложный вид (о том, почему это так, смотрите `Question 21146 <Q21146_>`_ и `Bug 231797 <Bug231797_>`_).  В этому случае используйте нечто вроде::

en: 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.
ru: Дополнительные сведения смотрите в ``man uscan`` и в `разделе о файле watch (Раздел 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch>`_ «Debian Policy Manual».

en: 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>`_.
ru: Список пакетов, для которых файл ``watch`` сообщает о том, что они не синхронизированы с апстримом, смотрите `Ubuntu External Health Status <http://qa.ubuntuwire.org/uehs/no_updated.html>`_.

en: The source/format file
ru: Файл source/format

en: This file indicates the format of the source package. It should contain a single line indicating the desired format:
ru: Этот файл указывает формат пакета исходного кода. Он должен содержать одну строку, показывающую выбранный формат:

en: ``3.0 (native)`` for Debian native packages (no upstream version)
ru: ``3.0 (native)`` для «родных» пакетов Debian (апстрим-версия отсутствует)

en: ``3.0 (quilt)`` for packages with a separate upstream tarball
ru: ``3.0 (quilt)`` для пакетов с отдельным тарболом из апстрима

en: ``1.0`` for packages wishing to explicitly declare the default format
ru: ``1.0`` для пакетов, желающих явно указать формат по умолчанию

en: 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.
ru: В настоящее время по умолчанию выбирается формат пакета исходного кода 1.0, если этот файл отсутствует. В файле source/format можно указать его явно. Если вы не используете этот файл для указания формата исходного кода, Lintian выдаст предупреждение об отстутствии файла. Это чисто информационное предупреждение и его можно без опасений проигнорировать.

en: You are encouraged to use the newer 3.0 source format. It provides a number of new features:
ru: Рекомендуется использовать более новый формат 3.0. Он предоставляет некоторые новые возможности:

en: Support for additional compression formats: bzip2, lzma and xz
ru: Поддержка дополнительных форматов сжатия: bzip2, lzma и xz

en: Support for multiple upstream tarballs
ru: Поддержка нескольких архивов с оригинальным исходным кодом

en: Not necessary to repack the upstream tarball to strip the debian directory
ru: Необязательно перепаковывать архив с оригинальным исходным кодом, чтобы удалить директорию ``debian``.

en: Debian-specific changes are no longer stored in a single .diff.gz but in multiple patches compatible with quilt under ``debian/patches/``
ru: Специфичные для Debian изменения теперь хранятся не в одном файле .diff.gz, а в виде нескольких патчей, совместимых с quilt, в каталоге ``debian/patches/``

en: https://wiki.debian.org/Projects/DebSrc3.0 summarizes additional information concerning the switch to the 3.0 source package formats.
ru: https://wiki.debian.org/Projects/DebSrc3.0 содержит дополнительную информацию касательно перехода на версию 3.0 формата исходных пакетов.

en: See ``man dpkg-source`` and the `source/format section (Section 5.21) <policy-format_>`_  of  the Debian New Maintainers' Guide for additional details.
ru: Дополнительную информацию можно найти в ``man dpkg-source`` и в `Главе source/format (Глава 5.21) <policy-format_>`_ руководства Debian New Maintainers.

en: Additional Resources
ru: Дополнительные ресурсы

en: 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.
ru: Кроме Debian Policy Manual, на который ссылается статья, руководство Debian New Maintainers' Guide содержит более детальное описание для каждого файла. `Глава 4, "Необходимые файлы в папке debian" <RequiredFiles_>`_ описывает файлы control, changelog, copyright и rules. `Глава 5, "Прочие файлы в папке debian" <OtherFiles_>`_ описывает дополнительные файлы, которые можно использовать.

en: Fixing a bug in Ubuntu
ru: Исправление ошибок в Ubuntu

en: Introduction
ru: Вступление

en: 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.
ru: Если вы следовали инструкциям по :doc:`подготовке к разработке Ubuntu<./getting-set-up>`, всё должно быть уже готово к работе.

en: 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.
ru: Как вы можете видеть на картинке выше, в процессе исправления ошибок в Ubuntu нет никаких сюрпризов: вы находите проблему, получаете код, исправляете его, тестируете, отправляете на Launchpad и просите, чтобы его проверили и объединили с основным кодом. В этом руководстве мы пройдем через все необходимые шаги, один за другим.

en: Finding the problem
ru: Поиск проблемы

en: 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.
ru: Существуют различные способы найти, над чем можно поработать. Это может быть ошибка, которую вы обнаружили сами (что даёт вам отличную возможность проверить своё исправление) или проблема, которую вы заметили где-то ещё, например в отчёте об ошибке.

en: Figuring out what to fix
ru: Выяснение того, что нужно исправить

en: 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.
ru: Если вы не знаете, в каком пакете исходного кода содержится ошибка, но знаете путь к этому приложению в вашей системе, то вы сможете найти пакет исходного кода, над которым требуется поработать.

en: This would print out::
ru: Команда выведет следующую информацию::

en: ``apt-cache`` is part of the standard installation of Ubuntu.
ru: Команда ``apt-cache`` установлена в Ubuntu по умолчанию.

en: Confirming the problem
ru: Подтверждение проблемы

en: 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::
ru: Предположим, в описании пакета ``bumprace`` отсутствует информация о его домашней странице. В качестве первого шага, следует проверить, не исправлена ли уже эта ошибка. Сделать это просто: посмотрите в Центре приложений или запустите::

en: The output should be similar to this::
ru: Вывод команды должен быть примерно следующим::

en: A counter-example would be ``gedit``, which has a homepage set::
ru: В качестве контрпримера можно привести ``gedit``, где домашняя страница указана::

en: 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.
ru: В некоторых случаях вы можете столкнуться с тем, что проблема, решение которой вы ищете, уже кем-то устранена. Чтобы избежать напрасной траты времени и труда, имеет смысл проделать кое-какую детективную работу.

en: Research bug situation
ru: Изучение ситуации с ошибкой

en: 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.
ru: Сначала нужно проверить, не существует ли уже сообщения об этой ошибке в Ubuntu. Возможно, кто-то уже работает над её исправлением, или мы можем как-то внести свой вклад в решение этой проблемы. Для Ubuntu мы взглянем на https://bugs.launchpad.net/ubuntu/+source/bumprace и увидим, что открытого отчёта о нашей ошибке там нет.

en: For Ubuntu the URL ``https://bugs.launchpad.net/ubuntu/+source/<package>`` should always take to the bug page of the source package in question.
ru: Для Ubuntu URL ``https://bugs.launchpad.net/ubuntu/+source/<пакет>`` всегда приводит на страницу ошибок в указанном пакете исходного кода.

en: 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.
ru: В Debian, который является основным источником пакетов Ubuntu мы взглянем на http://bugs.debian.org/src:bumprace и также не найдём там сообщения о нашей ошибке.

en: For Debian the URL ``http://bugs.debian.org/src:<package>`` should always take to the bug page of the source package in question.
ru: Для Debian URL ``http://bugs.debian.org/src:<пакет>`` всегда приводит на страницу ошибок в указанном пакете исходного кода.

en: 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.
ru: Ошибка, над которой мы работаем, необычна в том смысле, что она касается только пакетирования ``bumprace``. Если бы это была ошибка в исходном коде, полезно было бы также проверить систему отслеживания ошибок апстрима. К сожалению, эта процедура часто различается для каждого отдельного пакета, но всегда можно воспользоваться поиском в интернете, и в большинстве случаев вы обнаружите, что она окажется не такой уж сложной.

en: Offering help
ru: Предложение помощи

en: 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?
ru: Если вы обнаружили открытую ошибку, которая ещё никому не назначена, и вы готовы взяться за её устранение, следует написать комментарий с вашим решением. Включите в него как можно больше информации: При каких обстоятельствах появляется ошибка? Как вы её исправили? Тестировали ли вы свой способ устранения ошибки?

en: 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?
ru: Если сообщение об ошибке не было зарегистрировано, вы можете его создать. Подумайте над двумя вещами: Может быть, изменение настолько мало, что достаточно просто попросить кого-нибудь применить его? Может быть, у вас получилось только частично исправить ошибку, и вы хотите поделиться вашей частью?

en: It is great if you can offer help and will surely be appreciated.
ru: Будет замечательно, если вы можете предложить свою помощь, и она, несомненно, будет с готовностью принята.

en: Getting the code
ru: Получение кода

en: Work on a fix
ru: Исправление ошибки

en: 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.
ru: Есть целые книги о нахождении ошибок, их исправлении, тестировании и так далее. Если вы новичок в программировании, попробуйте исправлять лёгкие ошибки, такие как опечатки. Пытайтесь делать ваши изменения минимальными и чётко документировать ваши изменения и предположения.

en: 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:
ru: Перед тем, как работать над ошибкой, убедитесь, что она не исправлена уже кем-то другим, и никто не занимается в данный момент её исправлением. Не помешает проверить следующие источники:

en: Upstream (and Debian) bug tracker (open and closed bugs),
ru: Система отслеживания ошибок апстрима (и Debian) — открытые и закрытые ошибки,

en: Upstream revision history (or newer release) might have fixed the problem,
ru: История версий в апстриме (или в новой версии) может содержать сведения об исправлении ошибки,

en: bugs or package uploads of Debian or other distributions.
ru: отчёты об ошибках и новые версии пакетов в Debian и других дистрибутивах.

en: 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::
ru: Эта команда скопирует файлы, необходимые для сборки пакета, во временную директорию. Вы можете изменять эти файлы в текстовом редакторе или применять патчи из upstream, например::

en: 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``.
ru: После редактирования файла наберите ``exit`` или нажмите ``control-d``, чтобы выйти из временной командной оболочки.  Новый патч будет добавлен в ``debian/patches``.

en: Documenting the fix
ru: Документирование исправления

en: 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.
ru: Очень важно документировать свои изменения в достаточной степени, чтобы разработчикам впоследствии не пришлось гадать, какими были основания и предпосылки сделанных вами изменений. Каждый пакет исходного кода Debian и Ubuntu включает в себя файл ``debian/changelog``, в котором отслеживаются вносимые в пакет изменения.

en: The easiest way to update this is to run::
ru: Самый простой способ обновить его — это выполнить::

en: 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::
ru: Эта команда добавит в файл шаблон записи и запустит редактор, в котором вы сможете добавить недостающую информацию. Вот пример этой записи::

en: ``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.
ru: Команда ``dch`` должна заполнить первую и последнюю строку этой записи в файле changelog. Первая строка содержит имя пакета исходного кода, номер его версии, в какой релиз Ubuntu он загружен, срочность (почти всегда низкая — 'low'). Последняя строка всегда содержит имя, адрес электронной почты и метку времени изменения (в формате :rfc:`5322`).

en: With that out of the way, let's focus on the actual changelog entry itself: it is very important to document:
ru: Теперь давайте сфокусируемся на том, что должно содержаться в самой записи файла changelog. Очень важно задокументировать:

en: 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.
ru: В нашем (довольно редком) примере последнему пункту соответствует ``(LP: #123456)``, то есть сслыка на ошибку на Launchpad с номером 123456. Отчёты об ошибках, темы списков рассылки или спецификации обычно являются хорошими источниками информации для обоснования изменений. В качестве дополнительного приза, если вы используете нотацию ``LP: #<номер>`` для ошибок на Launchpad, то ошибка автоматически получит статус закрытой при отправке пакета в Ubuntu.

en: Testing the fix
ru: Тестирование исправления

en: To build a test package with your changes, run these commands::
ru: Чтобы собрать тестовый пакет с вашими изменениями, выполните следующие команды::

en: 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.
ru: В большинстве случаев вам придётся действительно установить пакет, чтобы проверить правильность его работы. Наш случай намного проще. Если сборка завершилась успешно, готовые двоичные пакеты можно будет найти в ``~/pbuilder/<выпуск>_result``. Установите их с помощью ``sudo dpkg -i <пакет>.deb`` или двойного щелчка на них в файловом менеджере.

en: 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.
ru: Эта команда проведёт вас через несколько шагов, необходимых для оформления отчёта об ошибке и отправки его в правильное место. Обязательно просмотрите ваши изменения, чтобы убедиться, что там нет ничего постороннего.

en: Communication is important, so when you add some more description to it to the inclusion request, be friendly, explain it well.
ru: Коммуникация имеет очень большое значение, поэтому при добавлении описания предоставьте хорошее и дружественное объяснение.

en: 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.
ru: Если всё прошло нормально, то вы должны получить почтовое сообщение от системы отслеживания ошибок Debian с дополнительной информацией. Иногда это может занять несколько минут.

en: Additional considerations
ru: Дополнительные замечания

en: 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.
ru: Если вы можете внести в пакет несколько тривиальных исправлений сразу, сделайте это. Это позволит разработчикам быстрее рассмотреть и применить эти изменения.

en: 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.
ru: Если вы хотите внести несколько больших изменений, лучше посылать патчи или запросы на слияние отдельно для каждого изменения. Это проще, если уже созданы индивидуальные сообщения об ошибках.

en: Fixing FTBFS packages
ru: Исправление пакетов FTBFS (Fails To Build From Source)

en: 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:
ru: Перед тем, как пакет можно будет использовать в Ubuntu, он должен быть собран из исходного кода. Если это не удаётся, пакет, вероятно, будет ожидать в -proposed и не будет доступен в архивах Ubuntu. Полный список пакетов, которые не удалось собрать из исходного кода, можно найти на http://qa.ubuntuwire.org/ftbfs/. На этой странице показано 5 основных категорий:

en: Package failed to build (F): Something actually went wrong with the build process.
ru: Package failed to build (F): Что-то действительно пошло не так в процессе сборки.

en: Cancelled build (X): The build has been cancelled for some reason. These should probably be avoided to start with.
ru: Отменённая сборка (X): сборка была отменена по некоторой причине. Для начала, с ними лучше не связываться.

en: 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.
ru: Package is waiting on another package (M): Этот пакет ожидает сборки или обновления другого пакета, или (если это пакет в main) одна из его зависимостей находится не в той части архива.

en: 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.
ru: Проблема в chroot (C): Некоторая операция над chroot-окружением столкнулась с ошибкой. Чаще всего исправляется повторной сборкой. Попросите разработчика запустить пересборку.

en: 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.
ru: Ошибка при загрузке (U): Пакет не может быть загружен на сервер. Обычно в этом случае нужно сделать пересборку, но перед этим -- проверьте логи сборки.

en: First steps
ru: Первые шаги

en: 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.
ru: Первым делом необходимо повторить FTBFS самостоятельно. Скачайте код с помощью ``bzr branch lp:ubuntu/PACKAGE`` и получите tar-архив, или запустите ``dget PACKAGE_DSC`` над .dsc-файлом со страницы проекта на Launchpad. После этого, создайте chroot-окружение.

en: 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).
ru: У вас должно получиться воспроизвести ошибку FTBFS. Если же нет -- проверьте, не качает ли сборка отсутствующую зависимость: в таком случае необходимо в файле debian/control объявить её как build-depends. Другой вариант -- попробовать собрать пакет локально, что позволит проверить отсутствующие или не указанные зависимости (в таком случае локальная сборка должна быть успешна, а в schroot -- нет)

en: Checking Debian
ru: Проверка Debian

en: 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.
ru: В случае, если проблему удалось воспроизвести -- необходимо приступить к поиску решения. Если пакет также находится в Debian, -- проверьте, возможно у них пакет собирается нормально: http://packages.qa.debian.org/PACKAGE. Если в Debian есть более новая версия пакета, его нужно объединить (merge). Если же нет -- проверьте логи сборки и ссылки на известные проблемы: там можеет быть дополнительная информация о FTBFS или патчи. Debian также поддерживает список команд разных FTBFS, в котором также есть варианты решения разнообразных проблем:  https://wiki.debian.org/qa.debian.org/FTBFS.

en: Other causes of a package to FTBFS
ru: Другие причины возникновения FTBFS

en: 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.
ru: Если пакет находится в main, но для него отсутствует зависимость не из main, то необходимо отправить MIR-баг:  страница https://wiki.ubuntu.com/MainInclusionProcess описывает эту процедуру.

en: Fixing the issue
ru: Исправление ошибки

en: 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.
ru: Если удалось исправить проблему, следуйте такой же процедуре как и при любых других проблемах: создайте патч, добавьте его в ветку или баг bzr, подпишите ubuntu-sponsors, а потом попробуйте добиться его добавления в исходный пакет и/или в Debian.

en: Getting Set Up
ru: Подготовка

en: 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:
ru: Существует несколько вещей, которые нужно сделать перед началом разработки в Ubuntu. Эта статья поможет вам подготовить компьютер к работе с пакетами и отправке ваших пакетов на платформу хостинга Ubuntu — Launchpad. Вот что здесь описано:

en: Installing packaging-related software. This includes:
ru: Установка программ для работы с пакетами. Они включают в себя:

en: Ubuntu-specific packaging utilities
ru: специфичные для Ubuntu утилиты создания пакетов

en: Encryption software so your work can be verified as being done by you
ru: криптографическую программу, которая позволит другим удостовериться, что работа выполнена именно вами

en: Additional encryption software so you can securely transfer files
ru: дополнительные программы шифрования, обеспечивающие безопасную передачу файлов

en: Creating and configuring your account on Launchpad
ru: Создание и настройка учётной записи на Launchpad

en: Setting up your development environment to help you do local builds of packages, interact with other developers, and propose your changes on Launchpad.
ru: Настройка вашей среды разработки для облегчения локальной сборки пакетов, взаимодействия с другими разработчиками и отправки ваших изменений на Launchpad.

en: 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.
ru: Рекомендуется выполнять работу по созданию пакетов в текущей разрабатываемой версии Ubuntu. Это позволит вам тестировать изменения в той же среде, в которую они в действительности затем будут внесены.

en: Install basic packaging software
ru: Установка базового программного обеспечения для создания пакетов

en: This command will install the following software:
ru: Эта команда установит следующие программы:

en: ``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.
ru: ``gnupg`` -- `GNU Privacy Guard <GPG_>`_ содержит инструменты, которые понадобятся для создания криптографического ключа, с помощью которого вы будете подписывать файлы, которые хотите загрузить на Launchpad

en: ``pbuilder`` -- a tool to do reproducible builds of a package in a clean and isolated environment.
ru: ``pbuilder`` -- инструмент для создания готовых к дальнейшему распространению сборок пакетов в чистой и изолированной среде.

en: ``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a collection of tools that make many packaging tasks easier.
ru: ``ubuntu-dev-tools`` (и его непосредственная зависимость ``devscripts``) -- набор инструментов, упрощающих многие задачи по созданию пакетов.

en: ``apt-file`` provides an easy way to find the binary package that contains a given file.
ru: ``apt-file`` предоставляет простой способ найти двоичный пакет, содержащий заданный файл.

en: Create your GPG key
ru: Создание ключа GPG

en: 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.
ru: GPG — аббревиатура для `GNU Privacy Guard <GPG_>`_, реализующего стандарт OpenPGP, который позволяет подписывать и шифровать сообщения и файлы. Это полезно в ряде ситуаций. В нашем случае важно, что вы можете использовать свой ключ для подписывания файлов, чтобы можно было удостовериться, что именно вы с ними работали. Если вы загрузите пакет исходного кода на Launchpad, он будет принят только в том случае, если можно точно определить, кто именно отправил пакет.

en: To generate a new GPG key, run::
ru: Чтобы сгенерировать новый ключ GPG, наберите::

en: 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).
ru: GPG сначала спросит, какой тип ключа вы хотите создать. Выбор по умолчанию (RSA и DSA) вполне подойдёт. Далее он попросит указать размер ключа. Размер по умолчанию (в настоящее время 2048) подойдёт, но 4096 надёжнее. Далее, программа спросит, хотите ли вы, чтобы срок действия ключа истёк через какое-то время. Безопаснее ответить "0", что означает, что срок действия не истечёт никогда. Последний вопрос будет о вашем имени и адресе электронной почты. Просто выберите адрес, которым вы пользуетесь при разработке Ubuntu, дополнительные адреса можно будет добавить позже. Добавлять комментарий не обязательно. После этого нужно указать надёжную парольную фразу (парольная фраза — это просто пароль, в котором допускается использовать пробелы).

en: 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.
ru: Теперь GPG создаст для вас ключ, что может занять некоторое время. Для его создания понадобятся случайные байты, поэтому будет просто замечательно, если вы зададите своей системе какую-нибудь работу. Подвигайте указатель мыши, наберите несколько абзацев случайного текста, загрузите любую веб-страницу.

en: Once this is done, you will get a message similar to this one::
ru: Когда процесс будет завершён, вы получите сообщение наподобие следующего::

en: In this case ``43CDE61D`` is the *key ID*.
ru: В данном случае, ``43CDE61D`` — это идентификатор ключа (*key ID*).

en: 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::
ru: Затем нужно загрузить открытую (public) часть вашего ключа на сервер ключей, чтобы все могли идентифицировать сообщения и файлы, как отправленные вами. Для этого введите::

en: 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.
ru: Эта команда отправит ваш ключ на сервер ключей Ubuntu, а сеть серверов ключей автоматически синхронизирует ключ между собой. После того, как эта синхронизация завершится, ваш подписанный открытый ключ будет готов для удостоверения сделанного вами вклада во всём мире.

en: Create your SSH key
ru: Создание ключа SSH

en: 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.
ru: SSH_ или *Secure Shell* — это протокол, позволяющий безопасно обмениваться данными по сети. Обычной практикой является использование SSH для доступа и открытия командной оболочки на другом компьютере и для безопасной пересылки файлов. В наших целях мы в основном будем использовать SSH для безопасной отправки пакетов исходного кода на Launchpad.

en: To generate an SSH key, enter::
ru: Чтобы сгенерировать ключ SSH, введите::

en: 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.
ru: Имя файла по умолчанию обычно вполне годится, так что можете оставить его как есть. Для целей безопасности настоятельно рекомендуется задать парольную фразу.

en: Set up pbuilder
ru: Настройка pbuilder

en: ``pbuilder`` allows you to build packages locally on your machine. It serves a couple of purposes:
ru: ``pbuilder`` позволяет локально собирать пакеты на вашем компьютере. Он служит нескольким целям:

en: 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
ru: Сборка будет выполнена в минимальной и чистой среде. Это даст возможность убедиться, что сборку удастся успешно воспроизвести и на других компьютерах, но при этом поможет избежать изменений в вашей локальной системе

en: There is no need to install all necessary *build dependencies* locally
ru: Отпадает необходимость в локальной установке всех *сборочных зависимостей*

en: You can set up multiple instances for various Ubuntu and Debian releases
ru: Можно настроить несколько экземпляров для различных выпусков Ubuntu и Debian

en: Setting ``pbuilder`` up is very easy, run::
ru: Настроить ``pbuilder`` очень просто. Наберите ::

en: Get set up to work with Launchpad
ru: Подготовка к работе с Launchpad

en: 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:
ru: После того, как базовая локальная конфигурация создана, следующим шагом будет настройка системы для работы с Launchpad. В этом разделе мы сфокусируемся на следующих вопросах:

en: What Launchpad is and creating a Launchpad account
ru: Что такое Launchpad и как создать учётную запись на Launchpad

en: Uploading your GPG and SSH keys to Launchpad
ru: Загрузка ваших ключей GPG и SSH на Launchpad

en: About Launchpad
ru: Сведения о Launchpad

en: 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.
ru: Launchpad является центральным элементом инфраструктуры, используемой нами в Ubuntu. Он хранит не только наши пакеты и наш код, но и такие вещи, как переводы, отчёты об ошибках, а также информацию о людях, работающих над Ubuntu и их принадлежности к различным командам. Вы можете также использовать Launchpad, чтобы опубликовать предлагаемые вами исправления и попросить других разработчиков Ubuntu проверить и поддержать их.

en: 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.
ru: Вам понадобится зарегистрироваться на Launchpad и предоставить некоторое минимальное количество информации о себе. Это позволит вам скачивать или отправлять исходный код, отправлять отчёты об ошибках и т.п.

en: Besides hosting Ubuntu, Launchpad can host any Free Software project. For more information see the `Launchpad Help wiki <https://help.launchpad.net/>`_.
ru: Кроме хостинга Ubuntu, Launchpad может предоставлять место для любого свободного программного проекта. Дополнительную информацию смотрите на `Справочных вики-страницах Launchpad <https://help.launchpad.net/>`_.

en: Get a Launchpad account
ru: Создание учётной записи на Launchpad

en: 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.
ru: Если у вас ещё нет учётной записи на Launchpad, вы легко можете `создать её <LP-AccountCreate_>`_. Если учётная запись есть, но вы не помните свой Launchpad ID, его можно узнать, зайдя на https://launchpad.net/~ и взглянув на часть после `~` в URL.

en: 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.
ru: При регистрации на Launchpad вас попросят выбрать отображаемое имя. Рекомендуется указать здесь ваше настоящее имя, чтобы ваши коллеги - разработчики Ubuntu могли лучше с вами познакомиться.

en: 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.
ru: При регистрации новой учётной записи Launchpad отправит вам письмо со ссылкой, которую нужно открыть в веб-браузере, чтобы подтвердить указанный вами адрес электронной почты. Если вы не получили письмо, проверьте папку нежелательной почты (спама).

en: `The new account help page <LP-AccountHelp_>`_ on Launchpad has more information about the process and additional settings you can change.
ru: `Справочная страница новой учётной записи <LP-AccountHelp_>`_ на Launchpad содержит дополнительную информацию о процессе и дополнительных настройках, которые можно сделать.

en: Upload your GPG key to Launchpad
ru: Загрузка вашего ключа GPG на Launchpad

en: First, you will need to get your fingerprint and key ID.
ru: Сначала нужно получить отпечаток и идентификатор ключа.

en: To find about your GPG fingerprint, run::
ru: Чтобы узнать свой отпечаток ключа GPG (fingerprint), наберите::

en: and it will print out something like::
ru: и вы увидите что-то наподобие::

en: Then run this command to submit your key to Ubuntu keyserver::
ru: Затем выполните эту команду для отправки вашего ключа на сервер ключей Ubuntu::

en: 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.
ru: где ``43CDE61D`` следует заменить на ваш идентификатор ключа (он в первой строке вывода предыдущей команды). Теперь можно импортировать свой ключ на Launchpad.

en: 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".
ru: Зайдите на https://launchpad.net/~/+editpgpkeys и скопируйте данные из строки «Key fingerprint»  в текстовое поле. В приведённом выше примере это будет ``5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D``. Затем щёлкните «Import Key».

en: 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.`
ru: Launchpad воспользуется отпечатком ключа для проверки наличия вашего ключа на сервере ключей Ubuntu и, в случае успеха, отправит вам зашифрованное сообщение электронной почты, предлагающее подтвердить импорт ключа. Проверьте свою почту и прочтите письмо, полученное с Launchpad. `Если ваш клиент электронной почты поддерживает шифрование OpenPGP, он предложит ввести пароль, который вы выбрали при создании ключа GPG. Введите пароль, затем щёлкните на ссылке, чтобы подтвердить, что этот ключ принадлежит вам.`

en: 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.
ru: Launchpad шифрует почту, используя ваш публичный ключ, так что вы сможете убедиться, что ключ ваш. Если вы пользуетесь почтовым клиентом Thunderbird, использующимся в Ubuntu по умолчанию, для дешифровки сообщения можете установить `дополнение Enigmail <Enigmail_>`_. Если ваша почтовая программа не поддерживает шифрование OpenPGP, скопируйте зашифрованное содержимое письма в буфер обмена, наберите в терминале ``gpg`` и вставьте содержимое письма в окно терминала.

en: Back on the Launchpad website, use the Confirm button and Launchpad will complete the import of your OpenPGP key.
ru: Вернувшись на сайт Launchpad, воспользуйтесь кнопкой «Confirm», чтобы Launchpad завершил импорт вашего ключа OpenPGP.

en: Find more information at https://help.launchpad.net/YourAccount/ImportingYourPGPKey
ru: Дополнительную информацию можно найти на https://help.launchpad.net/YourAccount/ImportingYourPGPKey

en: Upload your SSH key to Launchpad
ru: Загрузка вашего ключа SSH на Launchpad

en: 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".
ru: Откройте в веб-браузере https://launchpad.net/~/+editsshkeys, а в текстовом редакторе файл ``~/.ssh/id_rsa.pub``. Это открытая часть вашего ключа SSH, поэтому можно без опасений предоставить к ней общий доступ на Launchpad. Скопируйте содержимое файла и вставьте его в текстовое поле на веб-странице с меткой «Add an SSH key». Затем щёлкните «Import Public Key».

en: For more information on this process, visit the `creating an SSH keypair <genssh_>`_ page on Launchpad.
ru: Для дополнительной информации об этом процессе посетите страницу о `создании ключевой пары SSH <genssh_>`_ на Launchpad.

en: Configure your shell
ru: Настройка командной оболочки

en: Now save the file and either restart your terminal or run::
ru: Затем сохраните файл и перезапустите терминал или наберите::

en: (If you do not use the default shell, which is `bash`, please edit the configuration file for that shell accordingly.)
ru: (Если вы не пользуетесь стандартной командной оболочкой `bash`, отредактируйте конфигурационный файл той оболочки, которую вы предпочитаете использовать.)

en: Ubuntu Packaging Guide
ru: Руководство разработчика Ubuntu

en: 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.
ru: Ubuntu — не только свободная операционная система с открытым исходным кодом, её платформа также является открытой и обеспечивает прозрачность разработки. Можно легко получить исходный код для каждого отдельного компонента, и каждое отдельное изменение в платформе Ubuntu можно проверить.

en: 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.
ru: Это означает, что вы можете принять активное участие в её улучшении, и сообщество разработчиков платформы Ubuntu всегда заинтересовано в привлечении новых участников.

en: 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.
ru: Ubuntu также является сообществом замечательных людей, верящих в то, что программное обеспечение должно быть свободным и доступным для всех. Участники сообщества приветствуют вас и хотят, чтобы вы тоже к ним присоединились. Мы хотим, чтобы вы принимали участие в нашей работе, задавали вопросы, делали Ubuntu лучше вместе с нами.

en: 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.
ru: Если у вас возникнут трудности: не волнуйтесь! Прочтите :doc:`раздел о коммуникации<./communication>`, и вы узнаете, как легко связаться с остальными разработчиками.

en: The guide is split up into two sections:
ru: Это руководство состоит из двух разделов:

en: A list of articles based on tasks, things you want to get done.
ru: Список статей, основанных на определённых задачах, которые вам может понадобиться выполнить.

en: A set of knowledge-base articles that dig deeper into specific bits of our tools and workflows.
ru: Набор статей базы знаний, в которых подробнее рассматриваются используемые нами инструменты и рабочие процессы.

en: Articles
ru: Статьи

en: Knowledge Base
ru: База знаний

en: Further Reading
ru: Информация для дальнейшего чтения

en: You can read this guide offline in different formats, if you install one of the `binary packages <BinPkgs_>`_.
ru: Вы можете прочитать оффлайн-версию этого руководства в различных форматах, если установите один из `двоичных пакетов <BinPkgs_>`_.

en: If you want to learn more about building Debian packages, here are some Debian resources you may find useful:
ru: Если вы желаете узнать больше о сборке пакетов Debian, вот несколько ресурсов Debian, которые могут быть вам полезны:

en: `How to package for Debian <HowToPackage_>`_;
ru: `Как создавать пакеты для Debian <HowToPackage_>`_;

en: `Debian Policy Manual <Policy_>`_;
ru: `Руководство по политике Debian <Policy_>`_;

en: `Debian New Maintainers' Guide <NewMaintGuide_>`_ — available in many languages;
ru: `Руководство начинающего разработчика Debian <NewMaintGuide_>`_ — доступно на различных языках;

en: `Packaging tutorial <PkgTutorial_>`_ (also available as a `package <PkgTutorialPkg_>`_);
ru: `Руководство по созданию пакетов <PkgTutorial_>`_ (также доступно в виде `пакета <PkgTutorialPkg_>`_);

en: `Guide for Packaging Python Modules <PythonModules_>`_.
ru: `Руководство по созданию пакетов для модулей Python <PythonModules_>`_.

en: 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.
ru: Мы всегда стремимся улучшить это руководство. Если вы найдёте какую-либо ошибку, или хотите что-либо предложить, пожалуйста, `создайте отчёт об ошибке на Launchpad <Bugs_>`_. Если вы хотели бы помочь в работе над руководством, его `исходный код <Source_>`_ также доступен на Launchpad.

en: Introduction to Ubuntu Development
ru: Введение в разработку Ubuntu

en: 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.
ru: Ubuntu состоит из тысяч различных компонентов, написанных на множестве языков программирования. Каждый компонент —  библиотека, утилита или графическое приложение — доступен в виде пакета исходного кода. Пакты исходных кодов в большинстве случаев состоят из двух частей: сам исходный код и метаданные. Метаданные включают в себя зависимости пакета, информацию об авторском праве и лицензии, а также инструкции по сборке пакета. После того, как пакет исходных кодов скомпилирован, в процессе сборки мы получим двоичные пакеты, являющиеся .deb файлами, которые пользователи могут установить.

en: 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.
ru: Каждый раз, когда выходит новая версия приложения, или когда кто-то вносит изменения в исходный код пакета, входящего в состав Ubuntu, пакет с исходным кодом должен быть загружен на сборочные компьютеры Launchpad для компиляции. Готовые бинарные пакеты затем попадают в репозиторий и его зеркала в разных странах. URL в ``/etc/apt/sources.list`` являются ссылками на репозиторий или его зеркал. Каждый день собираются образы для различных версий Ubuntu. Они могут быть использованы в различных условиях. Есть образы, которые можно записать на USB-носители или на DVD-диски, образы, которые можно использовать для сетевой загрузки и есть образы, предназначенные для установки на телефон или планшет. Ubuntu, серверная версия Ubuntu, Kubuntu и другие ветки имеют специфичный список необходимых пакетов, которые попадают в образ. Эти образы, которые затем используются для проверки установки и обеспечивают обратную связь для дальнейшего планирования выпуска.

en: 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.
ru: Разработка Ubuntu сильно зависит от текущей фазы цикла выпуска. Мы выпускаем новую версию Ubuntu каждые шесть месяцев, что возможно только благодаря тому, что мы устанавливаем точные даты «заморозки». По достижении каждой даты заморозки ожидается, что разработчики будут вносить более редкие и менее значительные изменения. Заморозка новых функций (feature freeze) — это первая крупная дата заморозки, наступающая после прохождения первой половины цикла разработки. На этом этапе новые функции должны в основном быть реализованы. В оставшуюся часть цикла предполагается сфокусироваться на исправлении ошибок. После этого «замораживается» пользовательский интерфейс, затем документация, ядро и т.п., после чего выпускается бета-версия (beta release), которая подвергается интенсивному тестированию. После того, как выпущена бета-версия, исправляются только критические ошибки, и выпускается release candidate, который, если он не содержит серьёзных ошибок, становится в дальнейшем финальным выпуском.

en: 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.
ru: Тысячи пакетов исходного кода, миллиарды строк кода, сотни разработчиков требуют больше общения и планирования для поддержания высоких стандартов качества. В начале и в середине каждого цикла выпуска организуется Ubuntu Developer Summit, где разработчики и участники собираются вместе, чтобы планировать новые функции в следующих выпусках. Каждая функция обсуждается заинтересованными сторонами, и составляется спецификация, содержащая подробную информацию об исходных предположениях, реализации, внесении необходимых изменений в другие пакеты, о тестировании и так далее. Всё это делается прозрачным и открытым образом, так что вы можете поучаствовать удалённо, посмотреть видеотрансляцию, пообщаться с участниками и подписаться на спецификации, чтобы всегда быть в курсе происходящего.

en: 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.
ru: Однако на совещании могут быть обсуждены не все  изменения, так как Ubuntu зависит от изменений, вносимых в другие проекты. Поэтому участники разработки Ubuntu остаются постоянно на связи. Большинство команд или проектов используют отдельные списки рассылки, чтобы избежать большого потока не связанных с их специализацией писем. Для более непосредственной координации разработчики и добровольные участники используют Internet Relay Chat (IRC). Все обсуждения являются открытыми и публичными.

en: 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.
ru: Ещё одним важным инструментом связи являются отчёты об ошибках. Если в пакете или части инфраструктуры обнаружена ошибка,  отчёт о ней отправляется на Launchpad. В этом отчёте собрана вся информация, и при необходимости сведения о важности, статусе ошибки и лице, назначенном для её устранения, обновляются. Это делает отчёт об ошибке эффективным средством отслеживания ошибок в пакетах или проектах и оптимизации рабочей нагрузки.

en: 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).
ru: Большая часть доступных в Ubuntu программ создана не самими разработчиками Ubuntu. Многие из программ написаны разработчиками из других проектов с открытым исходным кодом, а затем интегрированы в Ubuntu. Такие проекты принято называть «апстримом» (от англ. upstream — вверх по течению), так как их исходный код вливается в Ubuntu, где мы «просто» интегрируем его в систему. Связь с апстримом очень важна для Ubuntu. Не только Ubuntu получает программный код из апстрима, но и апстрим получает от пользователей отчёты об ошибках и патчи от Ubuntu (и других дистрибутивов).

en: 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.
ru: Наиболее важным апстримом для Ubuntu является Debian. Debian — это дистрибутив, на котором основана Ubuntu, и именно там созданы многие инженерные  решения, касающиеся инфраструктуры пакетов. По традиции, в Debian для каждого отдельного пакета всегда имеется сопровождающий (мэйнтейнер) или отдельная группа сопровождения. В Ubuntu тоже есть команды, заинтересованные в работе над подмножеством пакетов и, разумеется, каждый разработчик имеет собственную область компетенции, но участие (и права загрузки изменений) обычно доступны любому, кто продемонстрирует способность и желание работать.

en: 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.
ru: Внести изменение в Ubuntu новому участнику не так трудно, как кажется, и это может быть весьма полезным опытом. Это позволяет не только научиться чему-то новому и увлекательному, но и поделиться своим решением проблемы с миллионами других пользователей.

en: 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.
ru: Разработка открытого программного обеспечения происходит в распределённом мире, в котором у разработчиков могут быть различные цели и различные области интересов. Например, может быть так, что отдельный апстрим заинтересован в работе над крупным нововведением, в то время как Ubuntu, вследствие тесного расписания релизов, более заинтересована в выпуске стабильной версии, в которой лишь исправлены некоторые ошибки. Поэтому мы используем «Ubuntu Distributed Development», где работа над кодом ведётся в различных ветках, которые затем сливаются друг с другом после проверки кода и достаточного количества обсуждений.

en: 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.
ru: В приведённом выше примере имеет смысл включить в Ubuntu существующую версию проекта, сделать исправления ошибок, добавить их в апстрим для следующего выпуска проекта и включить его (если он к этому пригоден) в следующий выпуск Ubuntu. Это будет наилучшим компромиссом и ситуацией, в которой выигрывают обе стороны.

en: 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.
ru: Чтобы исправить ошибку в Ubuntu, нужно сначала получить исходный код пакета, поработать над его исправлением, снабдить свою работу документацией, чтобы другим разработчикам и пользователям было легко понять, что именно вы сделали, а затем собрать пакет и протестировать его. После того, как вы протестировали изменённый пакет, можно предложить включить его в текущий разрабатываемый релиз Ubuntu. Разработчик с правом загрузки проверит ваш пакет и затем интегрирует его в Ubuntu.

en: 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.
ru: При попытке найти решение полезно проверить, известно ли о проблеме, над которой вы работаете, в апстриме и не найдено ли там уже её возможное решение. Если нет, сделайте всё возможное, чтобы решить проблему совместными усилиями.

en: Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream.
ru: Дополнительные шаги, которые вы можете предпринять, — это адаптирование вашего изменения для предыдущих поддерживаемых выпусков Ubuntu и отправление его в апстрим.

en: 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.
ru: Наиболее важные требования для успешной разработки в Ubuntu: уметь «заставлять вещи снова работать», не бояться читать документацию и задавать вопросы, быть командным игроком и иметь некоторую склонность к работе детектива.

en: KDE Packaging
ru: Работа с пакетами KDE

en: 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_>`_.
ru: Созданием пакетов программ KDE в Ubuntu занимаются команды Kubuntu и MOTU.  Связаться с командой Kubuntu можно через `почтовую рассылку Kubuntu <KubuntuML_>`_ и канал Freenode IRC ``#kubuntu-devel``.  Дополнительная информация о разработке Kubuntu доступна на `wiki-странице Kubuntu <Wiki_>`_.

en: 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.
ru: При создании пакетов мы учитываем практику команд `Debian Qt/KDE <QtKDETeam_>`_ и Debian KDE Extras.  Большинство наших пакетов являются производными от пакетов, созданных этими командами Debian.

en: Patching Policy
ru: Политика создания патчей

en: 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.
ru: Kubuntu добавляет патчи в приложения KDE, только если они исходят от оригинальных авторов, либо если они были отправлены в upstream и есть уверенность в их скором принятии, либо если мы обсудили проблемы с разработчиками KDE.

en: 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).
ru: Kubuntu не меняет фирменного оформления пакетов, кроме случаев, когда этого требует апстрим (например, логотип в верхнем левом углу меню Kickoff) или для упрощения (например, удаление показываемых при запуске заставок).

en: Debian packages include some additions to the basic Debhelper usage. These are kept in the ``pkg-kde-tools`` package.
ru: Пакеты Debian включают некоторые дополнения к обычному использованию Debhelper. Они хранятся в пакете ``pkg-kde-tools``.

en: 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::
ru: Пакеты, использующие Debhelper 7, должны добавить опцию ``--with=kde``. Это позволит убедиться в использовании правильных флагов сборки и опций, таких как обработка заданий kdeinit и файлов перевода.

en: 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``.
ru: Некоторые новые пакеты KDE используют систему ``dhmk``, альтернативу ``dh``, созданную командой Debian Qt/KDE.  Прочесть о ней можно в /usr/share/pkg-kde-tools/qt-kde-team/2/README.  Использующие её пакеты будут ``включать /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk`` вместо запуска ``dh``.

en: Translations
ru: Переводы

en: Packages in main have their translations imported into Launchpad and exported from Launchpad into Ubuntu's language-packs.
ru: Переводы пакетов из репозитория main импортируются на Launchpad и экспортируются с Launchpad в языковые пакеты Ubuntu.

en: So any KDE package in main must generate translation templates, include or make available upstream translations and handle ``.desktop`` file translations.
ru: Итак, каждый KDE-пакет в main должен создавать шаблоны переводов, включать оригинальные переводы и обрабатывать переводимые строки в ``.desktop``-файлах.

en: 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``.
ru: Для генерации шаблонов переводов пакет должен содержать файл ``Messages.sh``; если его там нет, обратитесь в апстрим.  Проверить его работу можно, выполнив сценарий ``extract-messages.sh``, который должен создать один или несколько файлов ``.pot`` в каталоге ``po/``.  В процессе сборки это будет сделано автоматически, если вы используете опцию ``--with=kde`` для ``dh``.

en: 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.
ru: Апстрим обычно также помещает файлы переводов ``.po`` в каталог ``po/``.  Если их там нет, проверьте, не выделены ли они в один из отдельных языковых пакетов апстрима, например, в языковые пакеты KDE SC.  Если они в отдельном языковом пакете, на Launchpad необходимо собирать их вместе вручную. Проконсультируйтесь по этому поводу с `Дэвидом Планеллой (David Planella) <dpm_>`_.

en: If a package is moved from universe to main it will need to be re-uploaded before the translations get imported into Launchpad.
ru: Если пакет перемещён из universe в main, его следует перевыгрузить перед импортом переводов на Launchpad.

en: ``.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``.
ru: Файлы ``.desktop`` также требуют перевода.  Мы добавили патч к KDELibs для чтения переводов из ``.po``-файлов, указывающих на строку ``X-Ubuntu-Gettext-Domain=``, добавляемую к файлам ``.desktop`` во время сборки пакета.  Файл .pot для каждого пакета генерируется во время сборки и .po-файлы необходимо скачать из апстрима и включить в пакет или в наши языковые пакеты.  Список  .po-файлов, которые нужно скачать из репозиториев KDE, находится в ``/usr/lib/kubuntu-desktop-i18n/desktop-template-list``.

en: Library Symbols
ru: Библиотечные символы

en: 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.
ru: Библиотечные символы отслеживаются при помощи файлов ``.symbols``, которые позволяют убедиться, что всё на месте. KDE использует библиотеки C++, которые действуют несколько иначе, чем библиотеки C. Для Debian команда Qt/KDE создала скрипты, которые позволяют справиться с этим. Документ `Работа с файлами symbols <SymbolsFiles_>`_ описывает, как создавать и обновлять такие файлы.

en: Shared Libraries
ru: Общие библиотеки

en: Shared libraries are compiled code which is intended to be shared among several different programs.  They are distributed as ``.so`` files in ``/usr/lib/``.
ru: Общие библиотеки — это скомпилированный код, предназначенный для совместного использования несколькими различными программами. Они распространяются в виде файлов ``.so`` в ``/usr/lib/``.

en: 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.
ru: Библиотеки экспортируют символы в скомпилированном виде: функции, классы и переменные. У каждой библиотеки также есть название SONAME, включающее номер её версии, но который не обязательно совпадает с официальным номером релиза.  Программы компилируются с конкретным SONAME библиотеки. Так, если какой-либо из символов библиотеки был удалён или изменён -- небходимо изменить версию с тем, чтобы все зависящие от библиотеки пакеты были перекомпилированы с использованием новой версии. Обычно версии устанавливаются в источнике, и мы используем те же номера версий для двоичных пакетов, называемые "номер ABI", но в случае, если источник не использует вменяемой версионности, создатели пакетов могут использовать отличную, более традиционную нумерацию.

en: 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.
ru: Библиотеки обычно распространяются апстримом в виде отдельных выпусков. Иногда они распространяются, как часть программы. В последнем случае они могут быть включены в двоичный пакет вместе с программой (это называется bundling), если вы не предполагаете использование этих библиотек другими программами, но чаще их всё же следует выделять в отдельные двоичные пакеты.

en: 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``.
ru: Сами библиотеки помещаются в двоичный пакет с именем ``libfoo1``, где ``foo`` — имя библиотеки, а ``1`` — версия из SONAME. Файлы разработки из пакета, такие как заголовочные файлы, необходимые для компиляции программ с библиотекой, помещаются в пакет с именем ``libfoo-dev``.

en: An Example
ru: Пример

en: We will use libnova as an example::
ru: В качестве примера мы используем libnova::

en: To find the SONAME of the library run::
ru: Чтобы найти SONAME библиотеки, выполните::

en: 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.
ru: SONAME в данном случае ``libnova-0.12.so.2``, что соответствует имени файла (как правило, но не всегда). Здесь апстрим поместил номер версии из апстрима, как часть SONAME, и задал ABI-версию ``2``.  Имена библиотечных пакетов должны следовать SONAME библиотеки, которую они содержат. Двоичный библиотечный пакет называется ``libnova-0.12-2``, где ``libnova-0.12`` — имя библиотеки, а ``2`` —  наш ABI-номер.

en: 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.
ru: Если авторы из апстрима внесли несовместимые изменения в свою библиотеку, они должны изменить номер версии SONAME, а мы должны переименовать нашу библиотеку. Любые другие пакеты, использующие наш библиотечный пакет, нужно будет перекомпилировать с новой весрией, это называется переходом (transition) и требует некоторых усилий. Надо надеяться, наш ABI-номер продолжит соответствовать SONAME апстрима, но иногда они вносят несовместимости без изменения их номера версии, а нам нужно изменить наш.

en: Looking in debian/libnova-0.12-2.install we see it includes two files::
ru: Взглянув на debian/libnova-0.12-2.instal, мы увидим, что он включает в себя два файла::

en: 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.
ru: Вторая строчка — настоящая библиотека, с полным номером версии. Первая — символическая ссылка, указывающая на настоящую библиотеку. Программы, использующие библиотеку, как правило, будут пользоваться символической ссылкой.

en: ``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).
ru: ``libnova-dev.install`` содержит все файлы, необходимые для компиляции программы с данной библиотекой. Заголовочные файлы, бинарник конфигурации, файл libtool'a ``.la``, а также ``libnova.so`` -- ещё один симлинк на библиотеку, создаваемый с тем, чтобы программы могли компилироваться вне зависимости от старшего номера версии (при этом, скомпилированное приложение всё равно будет зависеть от версии).

en: ``.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.
ru: ``.la``-файлы libtool'а требуются на некоторых не-Linux системах с ограниченной поддержкой библиотек, но на системах Debian зачастую создают больше проблем, чем решают. `Цель Debian отказаться от .la-файлов <LAFileRemoval_>`_ сегодня весьма актуальна, и вы можете помочь с решением этой задачи.

en: Static Libraries
ru: Статические библиотеки

en: 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.
ru: Пакет -dev также содержит ``usr/lib/libnova.a``.  Это статическая библиотека, альтернатива общей библиотеке.  Любая программа, скомпилированная со статической библиотекой, содержит её код непосредственно в себе.  Это позволяет не беспокоиться о двоичной совместимости библиотеки.  Однако это также означает, что любые ошибки, в том числе уязвимости в безопасности, не будут исправлены за счёт обновления библиотеки, пока программа не будет перекомпилирована.  По этой причине использовать программы со статическими библиотеками не рекомендуется.

en: Symbol Files
ru: Символьные файлы

en: 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.
ru: Когда приложение компилируется с библиотекой, механизм ``shlibs`` добавит к пакету зависимость от этой библиотеки. Именно поэтому большинство программ содержат ``Depends: ${shlibs:Depends}`` в файле ``debian/control``. Этот максов заменяется списком зависимых библиотек при билде. Однако shlibs может только указывать зависимость от старшей ABI-версии , ``2`` в нашем примере с libnova, так что если новые символы будут добавлены в будущей libnova 2.1 -- приложение будет запускаться и с более старой версией libnova ABI 2.0, что приведёт к аварианому завершению.

en: 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.
ru: Чтобы точнее указывать зависимости от библиотек, мы создали файл ``.symbols``, который перечисляет все символы библиотеки и версии, в которых они появились.

en: libnova has no symbols file so we can create one.  Start by compiling the package::
ru: libnova не имеет символьного файла, так что мы можем создать его. Начните с компиляции пакета::

en: 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::
ru: Опция ``-nc`` указывает не удалять сборочные файлы после завершения компиляции.  Перейдите в каталог сборки и выполните  ``dpkg-gensymbols`` для пакета библиотеки::

en: This makes a diff file which you can self apply::
ru: Это создаст diff-файл, который вы сможете применить самостоятельно::

en: 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::
ru: Это создаст файл с именем вида ``dpkg-gensymbolsnY_WWI``, в котором будут перечислены все символы. Он также указывает текущую версию пакета. Версию пакета можно убрать из файла, так как новые символы обычно добавляются не  с новой версией пакета, а разработчиками исходной библиотеки.

en: Now move the file into its location, commit and do a test build::
ru: Теперь переместите файл туда, где он должен находиться, зафиксируйте изменения и выполните тестовую сборку::

en: 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.
ru: Если компиляция выполняется успешно, значит символьный файл не содержит ошибок.  С выходом следующей апстрим-версии libnova вам придётся снова запустить dpkg-gensymbols, чтобы создать diff для обновления символьного файла.

en: C++ Library Symbols Files
ru: Символьные файлы библиотек C++

en: 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.
ru: У языка C++ более строгие стандарты на двоичную совместимость, чем у C. Команда Debian Qt/KDE поддерживает некоторые скрипты, которые помогут справиться с этим: страница `Работа с файлами symbols <SymbolsFiles_>`_ описывает принципы их использования.

en: Junichi Uekawa's `Debian Library Packaging Guide <LibraryGuide_>`_ goes into this topic in more detail.
ru: Статья Junichi Uekawa `Пакетирование библиотек для Debian <LibraryGuide_>`_ рассматривает этот вопрос более детально.

en: Packaging New Software
ru: Создание пакетов для новых программ

en: 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.
ru: Хотя в архиве Ubuntu имеются тысячи пакетов, есть ещё много программ, которыми никто не занимается. Если вы знаете о какой-то замечательной программе, о которой, по вашему мнению, стоит узнать более широкому кругу пользователей, вы можете попробовать приложить свою руку к созданию пакета для Ubuntu или PPA_. Это руководство проведёт вас через этапы создания пакета для новой программы.

en: You will want to read the :doc:`Getting Set Up<./getting-set-up>` article first in order to prepare your development environment.
ru: Сначала вам следует прочитать статью :doc:`Подготовка<./getting-set-up>`, чтобы подготовить свою среду разработки.

en: Checking the Program
ru: Проверка программы

en: 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.
ru: Первым этапом создания пакета является получение tar-файла из апстрима («апстримом» мы называем авторов приложений) и проверка того, что он нормально компилируется и запускается.

en: This guide will take you through packaging a simple application called GNU Hello which has been posted on GNU.org_.
ru: Это руководство проведёт вас через процесс создания пакета для небольшого приложения GNU Hello, доступного на GNU.org_.

en: This application uses the autoconf build system so we want to run ``./configure`` to prepare for compilation.
ru: Это приложение использует систему сборки autoconf, так что нам нужно запустить ``./configure`` для подготовки к компиляции.

en: 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.::
ru: При этом будет проверено наличие необходимых для сборки зависимостей. Поскольку ``hello`` — простой пример, ``build-essential`` обеспечит нас всем, что нужно. Для более сложных программ, команда завершится ошибкой, если у нас нет необходимых библиотек и файлов для разработки. Установите требуемые пакеты и повторите процесс, пока команда не завершится успешно.::

en: Now you can compile the source::
ru: Теперь нужно скомпилировать исходный код::

en: If compilation completes successfully you can install and run the program::
ru: Если компиляция завершилась успешно, можно установить и запустить программу::

en: Starting a Package
ru: Создание пакета

en: 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::
ru: Когда он спросит тип пакета, выберите ``s``: одиночный бинарник. Это импортирует код в ветку и создаст папку ``debian/``. Взгляните на её содержимое: большинство автоматически созданных файлов требуются лишь для специализированных пакетов (например, модули Emacs), так что можно начать с удаления лишних файлов::

en: You should now customise each of the files.
ru: Теперь нужно внести изменения в каждый из файлов.

en: 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``.
ru: Большая часть процесса компиляции пакета совершается скриптами из ``debhelper``. Так как поведение ``debhelper`` меняется при выходе старшей версии, файл compat сообщает ``debhelper``'у какую именно версию использовать. Имеет смысл использовать наиболее свежую версию: ``9``.

en: ``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::
ru: Файл ``control`` содержит все метаданные пакета.  Первый абзац описывает пакет исходных кодов. Второй и следующие абзацы описывают двоичные пакеты, которые должны быть собраны.  Нам понадобится добавить пакеты, необходимые для компиляции приложения в ``Build-Depends:``. Для ``hello`` он должен включать, как минимум::

en: You will also need to fill in a description of the program in the ``Description:`` field.
ru: Также нужно заполнить описание программы в поле ``Description:``.

en: ``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.
ru: ``copyright`` нужно заполнить в соответствии с лицензией на источник из апстрима.  Согласно файлу hello/COPYING, это лицензия GNU GPL 3 или более поздняя её версия.

en: ``docs`` contains any upstream documentation files you think should be included in the final package.
ru: ``docs`` должен содержать любые файлы документации из апстрима, которые, по вашему мнению, должны быть включены в готовый пакет.

en: ``README.source`` and ``README.Debian`` are only needed if your package has any non-standard features, we don't so you can delete them.
ru: ``README.source`` и ``README.Debian`` необходимы, лишь если ваш пакет имеет какие-то нестандартные функции. У нас таких нет, так что можно удалить эти файлы.

en: ``source/format`` can be left as is, this describes the version format of the source package and should be ``3.0 (quilt)``.
ru: ``source/format`` можно оставить как есть, он описывает формат версии пакета исходного кода, который должен быть ``3.0 (quilt)``.

en: ``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.
ru: ``rules`` — самый сложный файл.  Это Makefile, который компилирует код и превращает его в двоичный пакет.  К счастью, основную часть работы в наши дни автоматически выполняет ``debhelper 7``, так что универсальная цель ``%`` просто запускает сценарий ``dh``, который делает всё, что необходимо.

en: All of these file are explained in more detail in the :doc:`overview of the debian directory<./debian-dir-overview>` article.
ru: Все эти файлы подробнее описаны в статье :doc:`обзор каталога debian <./debian-dir-overview>`.

en: Finally commit the code to your packaging branch::
ru: Наконец, закоммитьте код в ветку для пакетов::

en: Building the package
ru: Сборка пакета

en: Now we need to check that our packaging successfully compiles the package and builds the .deb binary package::
ru: Теперь нам нужно проверить, что наши исходные файлы для пакета успешно компилируются и собираются в двоичный .deb-пакет::

en: ``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 ``..``.
ru: ``bzr builddeb`` — это команда для сборки пакета в его текущем местоположении. ``-us -uc`` сообщает что подписывать пакет с помощью  GPG не требуется.  Результат будет помещён в каталог «..».

en: You can view the contents of the package with::
ru: Просмотреть содержимое пакета можно с помощью::

en: Install the package and check it works (later you will be able to uninstall it using ``sudo apt-get remove hello`` if you want)::
ru: Установите пакет и проверьте, что он работает (позднее при желании вы сможете удалить его командой ``sudo apt-get remove hello``)::

en: You can also install all packages at once using::
ru: Можете также установить все пакеты сразу с помощью::

en: Next Steps
ru: Дальнейшие шаги

en: 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::
ru: Даже если двоичный .deb-пакет успешно собирается, ваши исходные файлы для пакета могут содержать ошибки. Многие ошибки могут автоматически обнаруживаться нашим инструментом ``lintian``, который можно применить к файлу метаданных .dsc, двоичным пакетам .deb или файлу .changes::

en: To see verbose description of the problems use ``--info`` lintian flag or ``lintian-info`` command.
ru: Чтобы увидеть подробное описание ошибок, используйте флаг lintian ``--info``  или команду ``lintian-info``.

en: For Python packages, there is also a ``lintian4python`` tool that provides some additional lintian checks.
ru: Для пакетов Python имеется также инструмент ``lintian4python``, осуществляющий некоторые дополнительные проверки lintian.

en: After making a fix to the packaging you can rebuild using ``-nc`` "no clean" without having to build from scratch::
ru: После создания исправления для файлов пакета можно пересобрать его с параметром ``-nc`` ("no clean"), чтобы не начинать сборку с самого начала::

en: 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>`::
ru: Убедившись, что пакет успешно собирается локально, вы должны проверить, правильно ли его сборка будет проходить в чистой системе, с помощью ``pbuilder``. Поскольку вскоре мы собираемся загрузить его в PPA (персональный архив пакетов), эту загрузку нужно снабдить *цифровой подписью*, чтобы Launchpad мог удостовериться, что загрузку сделали вы (узнать о том, что загрузка будет подписана, можно по отсутствию передаваемых ``bzr builddeb`` флагов ``-us`` и ``-uc``, которые мы использовали ранее). Для подписывания своей работы вам понадобится настроить GPG. Если вы ещё не настроили ``pbuilder-dist`` или GPG, :doc:`сделайте это сейчас<./getting-set-up>`::

en: When you are happy with your package you will want others to review it.  You can upload the branch to Launchpad for review::
ru: После того как вы останетесь довольны получившимся пакетом, нужно, чтобы его проверили другие люди.  Вы можете выгрузить ветку на Launchpad для проверки::

en: 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``::
ru: Выгрузка в PPA позволит удостовериться, что пакет собирается нормально, а также позволит вам и остальным тестировать бинарные пакеты. Вам потребуется создать PPA на Launchpad, после чего выгрузить пакет с помощью ``dput``::

en: 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.
ru: Попросить провести review можно на канале IRC ``#ubuntu-motu``, или в `списке рассылки MOTU <ubuntu-motu_>`_. В некоторых случаях может потребоваться участие конкретной команды: в подобных случаях команда GNU поможет разобраться.

en: Submitting for inclusion
ru: Отправка на включение

en: 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:
ru: Существует несколько путей, которыми пакет может попасть в Ubuntu. В большинстве случаев лучшим путём может быть прохождение сначала через Debian. Это позволит вашему пакету стать доступным для наибольшего количества пользователей, так как он будет доступен не только в Debian и Ubuntu, но и во всех дистрибутивах, созданных на их основе. Вот несколько полезных ссылок по отправке новых пакетов в Debian:

en: `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.
ru: `Debian Mentors FAQ <MentorsFAQ_>`_ - debian-mentors создан для менторства новых и перспективных разработчиков Debian. Это то место, где можно найти спонсора для загрузки Вашего пакета в архив.

en: `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.
ru: `Work-Needing and Prospective Packages <WNPP_>`_ - информация о том как отправлять баги "Intent to Package" (Назначение пакету) и "Request for Package" (Запрос пакета), а также списки открытых ITP и RFP.

en: `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.
ru: `Руководство Разработчика Debian, 5.1. Создание пакетов <DevRef_>`_ - бесценный документ для создателей пакетов как под Ubuntu, так и под Debian. Данная глава описывает процесс отправки новых пакетов.

en: 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.
ru: В некоторых случаях имеет смысл отправляться прямо в Ubuntu. Например, если Debian находится в состоянии "freeze": тогда ваш пакет врядли успеет войти в Ubuntu к ближайшему релизу. Этот процесс описан на странице  `"Новые Пакеты" <NewPackages_>`_ Ubuntu Wiki.

en: Screenshots
ru: Снимки экрана

en: 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 .
ru: Загрузив пакет в Debian, вам следует добавить снимки экрана, чтобы будущие пользователи смогли получить представление о том, как выглядит интерфейс программы. Снимки нужно отправлять на http://screenshots.debian.net/upload .

en: Patches to Packages
ru: Патчи для пакетов

en: 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.
ru: Иногда разработчикам пакета Ubuntu надо изменить исходный код апстрима, чтобы заставить его работать в Ubuntu должным образом. Примеры включают патчи для апстримов, которые еще не попали в версию релиза, либо изменения к системам билдов апстрима, необходимые только для их сборки на Ubuntu. Мы будем менять исходный код апстрима напрямую, но такой метод делает более сложным дальнейшее удаление патчей, когда апстрим уже применил их, также усложняя извлечение изменений для их отправки в проект апстрима. Вместо этого, мы будем хранить эти изменения как отдельные патчи в форме diff файлов.

en: 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.
ru: Существуют различные способы работы с патчами для пакетов Debian. К счастью, мы остановимся на одной системе, `Quilt`_, которая сейчас используется большинством пакетов.

en: Let's look at an example package, ``kamoso`` in Trusty::
ru: Давайте возьмём в качестве примера пакет ``kamoso`` в Trusty::

en: 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.
ru: Патчи хранятся в ``debian/patches``.  Для этого пакета имеется один патч ``kubuntu_01_fix_qmax_on_armel.diff`` для исправления ошибки компиляции на платформе ARM.  Этому патчу присвоено имя, описывающее, что он делает, номер патча по порядку (чтобы избежать  путаницы, если два патча имеют одинаковое имя) и, в данном случае, команда Kubuntu добавила свой собственный префикс, чтобы показать, что патч исходит от них, а не от Debian.

en: The order of patches to apply is kept in ``debian/patches/series``.
ru: Порядок применения патчей хранится в ``debian/patches/series``.

en: Patches with Quilt
ru: Патчи с помощью Quilt

en: Before working with Quilt you need to tell it where to find the patches.  Add this to your ``~/.bashrc``::
ru: Перед работой с Quilt нужно указать этой системе, где искать патчи.  Добавьте в ``~/.bashrc`` следующее::

en: And source the file to apply the new export::
ru: И источник файла для применения нового экспорта::

en: By default all patches are applied already to UDD checkouts or downloaded packages.  You can check this with::
ru: По умолчанию все патчи применяются уже с UDD извлечений или загружаемых пакетов. Вы можете проверить это с помощью::

en: If you wanted to remove the patch you would run ``pop``::
ru: Если вы хотите удалить патч, нужно выполнить ``pop``::

en: And to apply a patch you use ``push``::
ru: А чтобы применить патч, используйте ``push``::

en: Adding a New Patch
ru: Добавление нового патча

en: 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::
ru: Для добавления нового патча нужно указать Quilt создать новый патч, сообщить ему, какие файлы этот патч должен изменить, отредактировать файлы, а затем обновить патч::

en: The ``quilt add`` step is important, if you forget it the files will not end up in the patch.
ru: Шаг ``quilt add`` важен: если вы забудете его сделать, файлы не попадут в патч.

en: 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::
ru: Теперь изменения будут в ``debian/patches/kubuntu_02_program_description.diff``, а в файл ``series`` будет добавлена информация о новом патче.  Вы должны добавить новый файл в исходные файлы для пакета::

en: 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.
ru: Quilt содержит свои мета-данные в директории ``.pc/``, поэтому сейчас вам нужно добавить в пакет и её. Это должно быть улучшено в будущем.

en: 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.
ru: Как правило, следует проявлять осторожность при добавлении патчей к программам, если они исходят не из апстрима. Часто имеется веская причина, по которой изменения ещё не были сделаны.  В рассмотренном выше примере изменяется строка в пользовательском интерфейсе, так что это может поломать все переводы.  Если сомневаетесь, спросите автора из апстрима перед тем, как добавить патч.

en: Patch Headers
ru: Заголовки патчей

en: 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:
ru: Мы рекомендуем добавлять к каждому патчу заголовки DEP-3_, помещая их в самом верху файла патча. Вот некоторые заголовки, которые можно использовать:

en: 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.
ru: Описание того, что делает патч. Имеет формат, аналогичный полю ``Description`` в ``debian/control``: первая строка содержит краткое описание, начинающееся со строчной буквы, остальные строки содержат более длинное описание с пробелом в качестве отступа.

en: Who wrote the patch (i.e. "Jane Doe <packager@example.com>").
ru: Кто написал патч (например, "Jane Doe <packager@example.com>").

en: Where this patch comes from (i.e. "upstream"), when *Author* is not present.
ru: Откуда пришёл этот патч (например, "upstream"), если заголовок *Author* отсутствует.

en: 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.
ru: Ссылка на информацию об ошибке на Launchpad, предпочтительно, в краткой форме (наподобие *https://bugs.launchpad.net/bugs/XXXXXXX*). Если также имеются отчёты об ошибках в апстриме или системах отслеживания ошибок Debian, добавьте заголовки *Bug* или *Bug-Debian*.

en: Whether the patch was forwarded upstream. Either "yes", "no" or "not-needed".
ru: Был ли патч передан в апстрим. Значения: "yes", "no" или "not-needed".

en: Date of the last revision (in form "YYYY-MM-DD").
ru: Дата последней ревизии (в форме "ГГГГ-ММ-ДД").

en: Upgrading to New Upstream Versions
ru: Обновление до новых версий из апстрима

en: To upgrade to the new version, you can use ``bzr merge-upstream`` command::
ru: Чтобы выполнить обновление до последней версии, вы можете использовать команду ``bzr merge-upstream``::

en: 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::
ru: При запуске этой команды произойдет откат всех патчей, так как они могут стать устаревшими. Возможно потребуется их обновить для соответствия новому источнику апстрима, либо потребуется удалить их все вместе. Для облегчения проверки проблем применяйте патчи по одному.

en: If it can be reverse-applied this means the patch has been applied already by upstream, so we can delete the patch::
ru: Если для патча указано ``it can be reverse-applied``, значит патч уже был применён апстримом, так что мы можем удалить этот патч::

en: Then carry on::
ru: Затем продолжайте::

en: It is a good idea to run refresh, this will update the patch relative to the changed upstream source::
ru: Неплохой мыслью будет выполнить refresh, это обновит патч относительно изменений исходного кода в апстриме::

en: Then commit as usual::
ru: Затем выполните фиксацию, как обычно::

en: Making A Package Use Quilt
ru: Создание пакета с использованием Quilt

en: 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)``.
ru: Современные пакеты используют Quilt по умолчанию, это встроено в формат исходных файлов пакета.  Проверьте, что в ``debian/source/format`` указано ``3.0 (quilt)``.

en: Older packages using source format 1.0 will need to explicitly use Quilt, usually by including a makefile into ``debian/rules``.
ru: Для более старых пакетов, использующих формат 1.0, необходимо использовать Quilt явно, обычно с помощью включения make-фала в ``debian/rules``.

en: Configuring Quilt
ru: Конфигурирование Quilt

en: You can use ``~/.quiltrc`` file to configure quilt. Here are some options that can be useful for using quilt with debian/packages:
ru: Вы можете воспользоваться файлом ``~/.quiltrc`` для конфигурирования quilt. Вот несколько опций, которые могут быть полезны при использовании quilt с пакетами Debian:

en: Other Patch Systems
ru: Другие системы управления патчами

en: 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.
ru: Другие системы патчинга, используемые в пакетах, включают ``dpatch`` и ``cdbs simple-patchsys``, принцип работы которых похож на Quilt - патчи хранятся в ``debian/patches``, но для их применения, отмены или создания требуются другие команды. Вы можете узнать какая система патчинга используется в пакете при помощи команды ``what-patch``(в пакете ``ubuntu-dev-tools``). Вы можете использовать ``edit-patch``, показанный в :ref:`предыдущих главах <working-on-a-fix>`, в качестве надежного способа для работы со всеми системами.

en: 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.
ru: В более старых пакетах изменения будут включены напрямую в источники и храниться в исходном файле ``diff.gz``. Это делает сложнее процесс обновления до новых версий апстрима или различия между патчами - лучше избегать.

en: 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.
ru: Не изменяйте систему патчей, не обсудив это с сопровождающим Debian или имеющей отношение к делу командой Ubuntu. Если существующей системы патчей нет, можете добавить Quilt.

en: Security and Stable Release Updates
ru: Обновления безопасности и обновления стабильных релизов

en: Fixing a Security Bug in Ubuntu
ru: Исправление ошибок безопасности в Ubuntu

en: 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.
ru: Исправление дыр в безопасности в Ubuntu фактически не отличается от :doc:`исправления обычного бага<./fixing-a-bug>`, и предполагается, что Вы знакомы с исправлением обычных багов. Для демонстрации отличий мы будем добавлять в пакет dbus в Ubuntu 12.04 LTS (Precise Pangolin) обновления для системы безопасности.

en: Obtaining the source
ru: Получение исходного кода

en: 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::
ru: В данном примере мы уже знаем, что хотим исправить пакет dbus в Ubuntu 12.04 LTS (Precise Pangolin). Поэтому сначала нужно определить версию пакета, который хотите скачать. Мы можем использовать ``rmadison`` в качестве помощи в данной ситуации.

en: 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::
ru: Обычно выбирают самую последнюю версию для релиза, который Вы хотите пропатчить, который не в -proposed или -backports. Так как мы обновляем dbus Precise, Вы скачаете 1.4.18-1ubuntu1.4 с precise-updates::

en: Patching the source
ru: Создание патча

en: To create your patch using ``edit-patch``::
ru: Чтобы создать патч с помощью ``edit-patch``::

en: 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::
ru: Это применит все существующие патчи и поместит пакет во временный каталог. Теперь отредактируйте файлы для исправления уязвимостей. Обычно в апстриме лежит и патч, поэтому Вы сразу можете его применить::

en: After making the necessary changes, you just hit Ctrl-D or type exit to leave the temporary shell.
ru: После внесения необходимых изменений просто нажмите Ctrl-D или наберите exit, чтобы покинуть временную командную оболочку.

en: Formatting the changelog and patches
ru: Форматирование файла changelog и патчей

en: 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::
ru: После применения патчей вам потребуется внести изменения в лог. Команда ``dch`` используется для редактирования файла ``debian/changelog`` и ``edit-patch`` автоматически запустит ``dch`` после отката всех патчей. Если Вы не пользуетесь ``edit-patch``, то можете запустить ``dch -i`` вручную. В отличии от обычных патчей, Вам следует использовать следующий формат (обратите внимание, что в имени дитрибутива используется precise-security, так как это обновление безопасности для Precise) для обновлений безопасности::

en: 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::
ru: Обновите свой патч для использования соответствующих тегов. Ваш патч должен содержать как минимум теги Origin, Description и Bug-Ubuntu. Например, отредактируйте ``debian/patches/99-fix-a-vulnerability.patch``, чтобы он имел приблизительно следующие строки::

en: Multiple vulnerabilities can be fixed in the same security upload; just be sure to use different patches for different vulnerabilities.
ru: Множественные уязвимости можно исправить одной загрузкой безопасности, просто убедитесь что используете разные патчи для разных уязвимостей.

en: Test and Submit your work
ru: Проверка и отправка вашей работы

en: 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:
ru: На этом этапе процесс такой же, как при :doc:`исправлении обычных ошибок в Ubuntu<./fixing-a-bug>`. А именно, вам нужно:

en: Build your package and verify that it compiles without error and without any added compiler warnings
ru: Выполнить сборку пакета и проверить, что он компилируется без ошибок и компилятор не выдаёт никаких дополнительных предупреждений

en: Upgrade to the new version of the package from the previous version
ru: Выполнить обновление с предыдущей версии пакета до новой версии

en: Test that the new package fixes the vulnerability and does not introduce any regressions
ru: Убедиться, что новый пакет закрывает уязвимость и не вносит никаких ухудшений

en: 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``
ru: Отправляйте свою работу через предложение об объединении Launchpad и отправляйте баг в Launchpad, убедившись что пометили баг как ошибку безопасности, и для подписки ``ubuntu-security-sponsors``

en: If the security vulnerability is not yet public then do not file a merge proposal and ensure you mark the bug as private.
ru: Если это уязвимость в безопасности, о которой ещё не объявлено публично, то не отправляйте предложение слияния и убедитесь, что вы пометили свою ошибку, как приватную (private).

en: 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.
ru: Отправленный баг должен содержать Тестовый Пример, т.е. комментарий, который четко показывает как воссоздать баг, запустив старую версию, также показывая как убедиться, что баг больше не существует в новой версии.

en: 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.
ru: Отчет по багу также должен подтверждать, что ошибка исправлена в новых версиях Ubuntu при помощи предложенного фикса (в вышеуказанном примере выше чем в Precise). Если проблема не исправлена в новых версиях Ubuntu, вы должны подготовить обновлениях и для новых версий.

en: Stable Release Updates
ru: Обновления стабильного релиза

en: 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.
ru: Мы также разрешаем вносить обновления в выпуски, в которых пакет содержит серьёзную ошибку, такую как значительная регрессия по сравнению с предыдущим выпуском или ошибка, которая может привести к потере данных.  Из-за того, что такие изменения сами потенциально могут привести к появлению дополнительных ошибок, мы позволяем делать это только там, где изменения легко можно понять и проверить.

en: 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.
ru: Процесс обновлений стабильного выпуска (Stable Release Updates или SRU) такой же, как и для исправлений ошибок безопасности, за исключением того, что нужно подписать на отчёт об ошибке команду ``ubuntu-sru``.

en: 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``.
ru: Обновление попадет в архив  ``proposed``(к примеру ``precise-proposed``), где его проверяют на способность исправить проблему и подтверждают, что оно не является следствием новых проблем.  После недели работы без заявленных проблем, обновление попадает в раздел ``updates``.

en: See the `Stable Release Updates wiki page <SRUWiki_>`_ for more information.
ru: Смотрите 'Вики страницу Обновлений Стабильного Релиза <SRUWiki_>`_ для получения дополнительной информации.
