Translations by Dina Shlyapnikova
Dina Shlyapnikova has submitted the following strings to this translation. Contributions are visually coded: currently used translations, unreviewed suggestions, rejected suggestions.
| ~ |
When you're finally happy with your branch, make sure you've committed all your changes, then tag the branch with the changelog's version number. The ``bzr tag`` command will do this for you automatically when given no arguments::
|
|
| 2014-07-23 |
Когда Вы наконец довольны своей веткой, убедитесь что отправили все изменения, а затем пометьте ветку номером версии лога изменений. Команда ``bzr tag`` сделает это автоматически, если не указано ни одного аргумента::
|
|
| ~ |
This tag will tell the package importer that what is in the Bazaar branch is the same as in the archive.
|
|
| 2014-07-23 |
Этот тег сообщит импортирующему пакет, что содержимое ветка Bazaar идентично содержимому архива.
|
|
| ~ |
Once that is done you should review the change you are about to commit with ``bzr diff``. This should show you the same changes as a debdiff would before you upload the source package.
|
|
| 2014-07-23 |
Как только это сделано, Вы должны еще раз перепроверить изменения, которые хотите отправить, при помощи ``bzr diff``. Это должно показать те же изменения, как показал бы debdiff до загрузки исходного пакета.
|
|
| ~ |
Any updates to the package that have uploaded since your checkout will now be pulled in. You do not want to make changes to this branch. Instead, create a branch that will contain just the changes you're going to make. Let's say you want to fix bug 12345 for the Tomboy project. When you're in the shared repository you previously created for Tomboy, you can create your bug fix branch like this::
|
|
| 2014-07-23 |
Будут показаны любые обновления касательно пакета, которые были загружены с момента отладки. Вы не хотите вносить изменения в эту ветку. Вместо этого создайте ветку, которая будет содержать только те изменения, которые Вы собираетесь внести. Предположим, Вы хотите исправить баг 12345 для проекта Tomboy. Когда Вы находитесь в общедоступном репозитории, ранее созданном для Tomboy, Вы можете создать ветку для исправления багов следующим образом::
|
|
| ~ |
The first thing to do is to make sure your source package branch is up-to-date. It will be if you just checked it out, otherwise do this::
|
|
| 2014-07-23 |
Первым делом убедитесь, что ветка исходного пакета актуальна. Если Вы ее только что проверили, то она будет актуальной, если же нет, то сделайте следующее::
|
|
| ~ |
Now you can do all my work in the ``bug-12345`` directory. You make changes there as necessary, committing as you go along. This is just like doing any kind of software development with Bazaar. You can make intermediate commits as often as you like, and when your changes are finished, you will use the standard ``dch`` command (from the ``devscripts`` package)::
|
|
| 2014-07-23 |
Теперь Вы можете выполнять всю работу в директории ``bug-12345``. Делайте там все необходимые изменения, не забывая по ходу дела отправлять свою работу. Этот процесс схож с разработкой любых приложений при помощи Bazaar. Можно делать промежуточные отправки так часто, как захотите, а когда Вы закончили работу над изменениями, используйте стандартную команду ``dch`` (из пакета ``devscripts``)::
|
|
| ~ |
A hook in bzr-builddeb will use the debian/changelog text as the commit message and set the tag to mark bug #12345 as fixed.
|
|
| 2014-07-23 |
Хук в bzr-builddeb будет использовать текст debian/changelog как сообщение о завершении отправки и установит тег для отметки бага #12345 в качестве фиксированного.
|
|
| ~ |
If there are lots of merge conflicts you would probably want to ask the contributor to fix them up. See the next section to learn how to cancel a pending merge.
|
|
| 2014-07-23 |
Если при слиянии возникает множество конфликтов, возможно Вы захотите попросить разработчика их исправить. Смотрите в следующем разделе как отменить запланированное слияние.
|
|
| ~ |
But if the changes look good, commit and then follow the rest of the uploading process::
|
|
| 2014-07-23 |
Но если с изменениями все в порядке - подтвердите, а затем пройдите оставшуюся часть процесса загрузки::
|
|
| ~ |
Once you have the source package branch in a shared repository, you'll want to create additional branches for the fixes or other work you plan to do. You'll want to base your branch off the package source branch for the distro release that you plan to upload to. Usually this is the current development release, but it may be older releases if you're backporting to an SRU for example.
|
|
| 2014-07-23 |
Как только у Вас есть ветка с исходным пакетом в общедоступном репозитории, Вы захотите создать дополнительные ветки для фиксов или другой запланированной работы. Вы захотите, чтобы Ваша ветка основывалась на пакете исходной ветки релиза distro, куда Вы планируете загружать. Обычно это текущий релиз разработки, но это могут быть и более старые релизы, если Вы, к примеру, выполняете обратный порт на SRU.
|
|
| ~ |
At any time before you `dput` the source package you can decide to cancel an upload and revert the changes::
|
|
| 2014-07-23 |
В любое время до выполнения действия `dput` с исходным пакетом Вы можете отменить загрузку и откатить все изменения::
|
|
| ~ |
You can do this if you notice something needs more work, or if you would like to ask the contributor to fix up conflicts when sponsoring something.
|
|
| 2014-07-23 |
Вы можете сделать это если заметите, что требуется еще немного работы, либо если хотите попросить разработчика исправить конфликты (если выступаете его спонсором).
|
|
| ~ |
then work in this new branch, and then merge it in to the main one and upload as if it was your own work. The contributor will still be mentioned in the changelog, and Bazaar will correctly attribute the changes they made to them.
|
|
| 2014-07-23 |
затем работайте в этой новой ветке, а после этого выполните ее слияние с главной и загрузите таким образом, как если бы загружали собственную работу. Разработчик-участник все еще будет упомянут в логах изменений, и Bazaar должным образом назначит им внесенные ими изменения.
|
|
| ~ |
If you already have a branch where you are working on the package and you would like to include their changes, then simply run the ``bzr merge`` from that branch, instead of the checkout of the development package. You can then make the changes and commit, and then carry on with your changes to the package.
|
|
| 2014-07-23 |
Если у Вас уже есть ветка, в которой Вы работаете над пакетом и Вы хотите включить все изменения - просто запустите ``bzr merge`` из этой ветки, вместо отладки пакета разработки. Затем Вы можете внести изменения и отправить, а затем продолжить работу с изменениями к пакету.
|
|
| ~ |
If you don't have an existing branch, but you know you would like to make changes based on what the contributor provides then you should start by grabbing their branch::
|
|
| 2014-07-23 |
Если у Вас нет существующей ветки, но Вы знаете, что хотели бы внести изменения, основываюсь на данных разработчика, то Вы должны первым делом должны спарсить их ветку::
|
|
| ~ |
You can then reply to the merge proposal review email explaining what you changed, and asking for re-review, or you can reply on the merge proposal page in Launchpad.
|
|
| 2014-07-23 |
Вы можете ответить на email с обзором предложения о слиянии объяснение того, какие изменения Вы внесли, а также можете попросить провести повторный обзор; или же Вы можете отправить свой ответ через Launchpad.
|
|
| ~ |
First, you need to check that you have the latest version of the package in your checkout of the development package trunk::
|
|
| 2014-07-23 |
Сначала Вам нужно убедиться, что у Вас самая последняя версия пакета в отладке древа пакета разработки::
|
|
| ~ |
This pulls in any changes that may have been committed while you were working on your fix. From here, you have several options. If the changes on the trunk are large and you feel should be tested along with your change you can merge them into your bug fix branch and test there. If not, then you can carry on merging your bug fix branch into the development trunk branch. As of bzr 2.5 and bzr-builddeb 2.8.1, this works with just the standard ``merge`` command::
|
|
| 2014-07-23 |
Это применит любые изменения, которые были внесены за время Вашей работы над фиксом. Начиная с этого момента у Вас есть несколько вариантов. Если Ваши изменения большие и Вы чувствуете, что их следует протестировать вместе с Вашими изменениями - то можно объединить их в ветке исправления багов и провести тестирование там. Если нет, то Вы можете продолжить процесс слияния в Вашей ветке исправления бага. Касательно bzr 2.5 и bzr-builddeb 2.8.1, это работает так же как и стандартная команда ``merge``::
|
|
| ~ |
When you have a branch with a change that you would like to upload you need to get that change back on to the main source branch, build a source package, and then upload it.
|
|
| 2014-07-23 |
Когда у Вас есть ветка с изменениями, которые Вы хотите загрузить, то нужно отправить это изменение обратно на исходную ветку, создать исходный пакет, а затем загрузить его.
|
|
| ~ |
Note that if you are sponsored via a debdiff attached to a bug report you need to manually update by generating a new diff and attaching that to the bug report.
|
|
| 2014-07-23 |
Обратите внимание - Вас спонсируют через debdiff, прикрепленный к отчету о баге - Вам следует обновлять его вручную, генерируя новый diff и прикрепляя его у отчету о баге.
|
|
| ~ |
Merge proposals to package source branches will automatically subscribe the `~ubuntu-branches` team, which should be enough to reach an Ubuntu developer who can review and sponsor your package change.
|
|
| 2014-07-23 |
Предложения о слиянии для исходных веток автоматически подпишут команду `~ubuntu-branches`, что должно быть достаточно для того, чтобы привлечь внимание разработчика Ubuntu, который сможет дать отзыв Вашим изменениям и стать спонсором.
|
|
| ~ |
Now when you push your branch to Launchpad, Bazaar will remembered where you pushed to, and will update the branch on Launchpad with your latest commits. All you need to do is::
|
|
| 2014-07-23 |
Теперь когда Вы продвинули свою ветку в Launchpad, Bazaar обновит ветку на Launchpad Вашими последними изменениями. Все, что Вам нужно сделать::
|
|
| ~ |
One of the biggest advantages to using the UDD workflow is to improve quality by seeking review of changes by your peers. This is true whether or not you have upload rights yourself. Of course, if you don't have upload rights, you will need to seek sponsorship.
|
|
| 2014-07-23 |
Один из больших плюсов использования рабочего процесса UDD - улучшение качества путем отзывов об изменениях от Ваших друзей и коллег. Это работает вне зависимости от того есть ли у Вас права на загрузку. Конечно, если у Вас нет прав на загрузку, то Вам нужно найти спонсора.
|
|
| ~ |
Once you are happy with your fix, and have a branch ready to go, the following steps can be used to publish your branch on Launchpad, link it to the bug issue, and create a *merge proposal* for others to review, and sponsors to upload.
|
|
| 2014-07-23 |
Как только Вы довольны своим фиксом и Ваша ветка готова к работе, следует предпринять следующие шаги для публикации своей ветки на Launchpad, привязки ее к багу, а затем создать предложение о слиянии (*merge proposal*) для рассмотрения другими пользователями и возможностью загрузки его спонсорами.
|
|
| ~ |
When upstream releases a new version (or you want to package a snapshot), you have to merge a tarball into your branch.
|
|
| 2014-07-23 |
Когда в апстриме выпускается новая версия (или Вы хотите запаковать скриншот), Вам нужно выполнить слияние tar-архива и Вашей ветки.
|
|
| ~ |
If you are merging an upstream release into an existing Bazaar branch that has not previously used the UDD layout, ``bzr merge-upstream`` will fail with an error that the tag for the previous upstream version is not available; the merge can't be completed without knowing what base version to merge against. To work around this, create a tag in your existing repository for the last upstream version present there; e.g., if the last Ubuntu release was *1.1-0ubuntu3*, create the tag *upstream-1.1* pointing to the bzr revision you want to use as the tip of the upstream branch.
|
|
| 2014-07-23 |
Если Вы объединяете релиз апстрима с существующей веткой Bazaar, в которой еще не использовалась разметка UDD, ``bzr merge-upstream`` пройдет неудачно и с ошибкой, что тег предыдущих версий апстрима недоступен. Слияние нельзя выполнить без знания базовой версии для слияния. Для работы с этим, создайте тег в своем существующем репозитории для последней имеющейся там версии апстрима; например, если последний релиз Ubuntu был *1.1-0ubuntu3*, создайте тег *upstream-1.1*, указывая на изменение bzr, которое Вы хотите использовать как подсказку для ветки апстрима.
|
|
| ~ |
If you are going to build the source package from this merged branch, you would use the ``-S`` option to the ``bd`` command. One other thing you'll want to consider is also using the ``--package-merge`` option. This will add the appropriate ``-v`` and ``-sa`` options to the source package so that all the changelog entries since the last Ubuntu change will be included in your ``_source.changes`` file. For example::
|
|
| 2014-07-23 |
Если Вы собираетесь создать исходный пакет из этой объединенной ветки, то нужно использовать опцию ``-S`` команды ``bd``. Также Вам захочется рассмотреть использование опции ``--package-merge``. Это добавит соответствующие опции ``-v`` и ``-sa`` к исходному пакету, чтобы все записи в логе изменений после последних изменений в Ubuntu были включены в Ваш файл ``_source.changes``. Например::
|
|
| ~ |
Uploading a package
|
|
| 2014-07-22 |
Загрузка пакета
|
|
| ~ |
The merge does have to be done at some point though. The longer it is left, the harder may be, so doing it regularly should keep each merge simple. Even if there are many merges the total effort would hopefully be less.
|
|
| 2014-07-22 |
Слияние следует выполнять в определенный момент. Чем дольше Вы работаете - тем сложнее может быть процесс в дальнейшем. Выполняйте слияние регулярно, чтобы максимально упростить процесс. Если даже слияний много, в итоге нужно применять меньше общих усилий.
|
|
| ~ |
If conflicts are reported then you need to edit those files to make them look how they should, removing the *conflict markers*. Once you have done this, run::
|
|
| 2014-07-22 |
Если появится отчет о конфликтах, Вам нужно отредактировать соответствующие файлы, чтобы привести их к должному виду, убрав конфликтующие маркеры (*conflict markers*). Как только Вы это сделали, выполните::
|
|
| ~ |
To merge the changes you just need to use ``bzr merge``, but you must have committed your current work first::
|
|
| 2014-07-22 |
Чтобы выполнить слияние изменений, Вам нужно использовать ``bzr merge``, но сначала Вы должны отправить свою текущую работу::
|
|
| ~ |
You will often think in terms of versions of a package, rather than the underlying Bazaar revision numbers. `bzr-builddeb` provides a revision specifier that makes this convenient. Any command that takes a ``-r`` argument to specify a revision or revision range will work with this specifier, e.g. ``bzr log``, ``bzr diff``, and so on. To view the versions of a package, use the ``package:`` specifier::
|
|
| 2014-07-22 |
Вы часто будете думать относительно версий пакета, а не просто о цифрах предыдущих поправок в Bazaar. `bzr-builddeb` для удобства предоставляет спецификатор поправок. Любая команда, использующая аргумент ``-r`` для указаний поправки или диапазона поправок. будет работать с этим спецификатором, к примеру, ``bzr log``, ``bzr diff``итд. Чтобы просмотреть версии пакета, используйте спецификатор ``package:``::
|
|
| ~ |
If that reports anything then you will either have to commit the changes, revert them, or shelve them to come back to later.
|
|
| 2014-07-22 |
Если появится отчет, то Вам нужно либо применить изменения, откатить их, либо отложить решения (и возвратиться к их решению позже).
|
|
| ~ |
This will merge the changes since the last merge point and leave you with changes to review. This may cause some conflicts. You can see everything that the ``merge`` command did by running::
|
|
| 2014-07-22 |
Это добавит изменения, внесенные с момента последнего слияния и даст Вам все изменения для обзора. Это может повлечь конфликты. Вы можете увидеть все действия, выполненные командой ``merge``, запустив::
|
|
| ~ |
Doing a full branch with history can take a lot of time and network resources. You may find it quicker to do a lightweight checkout ``bzr checkout --lightweight ubuntu:kdetoys`` but this will need a network access for any further bzr operations.
|
|
| 2014-07-22 |
Создание полной ветки с историей может отнять много времени и сетевых ресурсов. Возможно Вам быстрее будет сделать легкую отладку ``bzr checkout --lightweight ubuntu:kdetoys``, но тогда потребуется сетевой доступ для любых дальнейших операций bzr.
|
|
| ~ |
Many Ubuntu packages are based on the packages in Debian, UDD also imports the Debian package into our branches. In the *kdetoys* branch above the Debian versions from *unstable* are from the merge with blue circles while those from *Debian experimental* are from the merge with yellow circles. Debian releases are tagged with their version number, e.g., ``4:4.2.2-1``.
|
|
| 2014-07-22 |
Многие пакеты Ubuntu основаны на пакетах в Debian, UDD также импортирует и пакет Debian в наши ветки. В ветке *kdetoys* выше версии Debian из *unstable* после объединения помечены синими кружочками, в то время как из *Debian experimental* после объединения помечены желтыми. Релизы Debian помечены номерами своих версий, например, ``4:4.2.2-1``.
|
|
| ~ |
Working with patches is fiddly. Patches can be seen as a branched revision control system, so we end up with RCS on top of RCS.
|
|
| 2014-07-22 |
Работа над патчами очень кропотливая. Патчи можно рассматривать как разветвленную переработку системы управления, таки образом мы получаем RCS поверх RCS.
|
|
| ~ |
There is no way to build directly from branches. You need to create a source package and upload that.
|
|
| 2014-07-22 |
Нет способа создавать билды напрямую из веток. Нужно создавать исходный пакет и загружать его.
|
|
| ~ |
Once you have updated your copy of a distroseries branch, then you may want to merge this in to your working branches as well, so that they are based on the latest code.
|
|
| 2014-07-22 |
Как только Вы обновили свою копию ветки distroseries, то возможно захотите также объединить ее со своими рабочими ветками, чтобы они работали на самом последнем коде.
|
|
| ~ |
You don't have to do this all the time though. You can work on slightly older code with no problems. The disadvantage would come if you were working on some code that someone else changed. If you are not working on the latest version then your changes may not be correct, and may even produce conflicts.
|
|
| 2014-07-22 |
Тем не менее, Вам не нужно делать это каждый раз. Вы можете без проблем работать и со слегка старым кодом. Недостатки могут всплыть если Вы работали над кодом, который изменил кто-то еще. Если Вы работаете не с самой последней версией, Ваши изменения могут быть некорректными, и даже могут стать причиной конфликта.
|
|
| ~ |
The merge history includes two separate branches, one for the upstream source and one which adds the ``debian/`` packaging directory::
|
|
| 2014-07-22 |
История объединений включает две отдельные ветки, одну для источника апстрима и другую, которая добавит директорию пакета ``debian/``::
|
|
| ~ |
This will try a number of methods to get the upstream tar, firstly by recreating it from the ``upstream-x.y`` tag in the bzr archive, then by downloading from the Ubuntu archive, lastly by running ``debian/rules get-orig-source``. The upstream tar will also be recreated when using bzr to build the package::
|
|
| 2014-07-22 |
Таким образом пробуются несколько методов для попадания в tar апстрима, сначала воссоздавая его из тега ``upstream-x.y`` в архиве bzr, затем скачивая из архива Ubuntu, а потом запуская ``debian/rules get-orig-source``. Tar апстрима также будет воссоздан при использовании bzr для построения пакета::
|
|
| ~ |
If the package you want to work on is available in Debian but not Ubuntu, it's still easy to import the code to a local bzr branch for development. Let's say you want to import the `newpackage` source package. We'll start by creating a shared repository as normal, but we also have to create a working tree to which the source package will be imported (remember to cd out of the `tomboy` directory created above)::
|
|
| 2014-07-22 |
Если пакет, над которым Вы хотите работать, доступен в Debian, но не в Ubuntu - код легко импортировать в локальную ветку bzr для разработки. К примеру, Вы хотите импортировать исходный пакет `newpackage`. Мы начнем с создания общедоступного репозитория в качестве обычного, но нам также надо создать рабочее дерево, в которое будет импортирован исходный пакет (не забудьте выполнить cd out директории `tomboy`, созданной выше)::
|
|
| ~ |
This UDD branch of *kdetoys* shows the full packaging for each version uploaded to Ubuntu with grey circles and the upstream source versions with green circles. Versions are tagged with either the version in Ubuntu such as ``4:4.2.29-0ubuntu1`` or for the upstream branch with the upstream version ``upstream-4.2.96``.
|
|
| 2014-07-22 |
UDD ветка *kdetoys* помечает полный пакет для каждой версии, загруженной в Ubuntu серыми кругами и версии источника апстрима - зелеными. Версии помечаются либо версиями Ubuntu (например, ``4:4.2.29-0ubuntu1``) или для веток апстрима - версией апстрима (``upstream-4.2.96``).
|
|
| ~ |
UDD branches are all in a standard location, so doing a checkout is easy::
|
|
| 2014-07-22 |
UDD ветки все находятся в стандартном местоположении, поэтому отладка будет легкой::
|
|
| ~ |
Occasionally the importer fails and packaging branches do not match what is in the archive. A message saying::
|
|
| 2014-07-22 |
Иногда импорт не проходит успешно и ветви пакета не совпадают с теми, что находятся в архиве. Сообщение::
|
|
| ~ |
The majority of this guide deals with :doc:`Ubuntu Distributed Development <./udd-intro>` (UDD) which utilizes the distributed version control system (DVCS) Bazaar for :ref:`retrieving package sources <branching>` and submitting fixes with :ref:`merge proposals. <merge-proposal>` This article will discuss what we will call traditional packaging methods for lack of a better word. Before Bazaar was adopted for Ubuntu development, these were the typical methods for contributing to Ubuntu.
|
|
| 2014-07-22 |
Большая часть данного руководства относится к :doc:`Ubuntu Distributed Development <./udd-intro>` (UDD), которое использует распространяемую версию системы управления (DVCS) Bazaar для :ref:`получения источников пакетов <branching>` и отправки фиксов через :ref:`предложения о слияниях. <merge-proposal>` В этой статье мы обсудим так называемые "традиционные" методы создания пакетов. До того как Bazaar стали применять в разработках Ubuntu, помочь Ubuntu можно было стандартными способами.
|
|
| ~ |
Along the way, you'll want to build your branch so that you can test it to make sure it does actually fix the bug.
|
|
| 2014-07-22 |
По ходу дела Вы захотите создать свою ветку, чтобы Вы могли проверить ее и убедиться, что она действительно исправляет баг.
|
|
| ~ |
In order to build the package you can use the ``bzr builddeb`` command from the ``bzr-builddeb`` package. You can build a source package with::
|
|
| 2014-07-22 |
Чтобы создать пакет, Вы можете использовать команду ``bzr builddeb`` из пакета ``bzr-builddeb``. Вы можете создать исходный пакет при помощи::
|
|
| ~ |
Branching for a change
|
|
| 2014-07-22 |
Ветвление для изменений
|
|
