Ubuntu logo

Packaging Guide

4. Виправлення помилок в Ubuntu

4.1. Вступ

Якщо Ви дотримувалися інструкцій з підготовки до розробки Ubuntu, усе повинно бути вже готово до роботи.

./_images/fixing-a-bug.png

Як Ви можете бачити на картинці вище, у процесі виправлення помилок в Ubuntu немає ніяких несподіванок: Ви знаходите проблему, отримуєте код, виправляєте його, тестуєте, відправляєте на Launchpad й прохаєте, щоб його перевірили та об’єднали з основним кодом. У цьому посібнику ми пройдемо через усі необхідні кроки, один за іншим.

4.2. Пошук проблеми

Існують різні способи знайти, над чим можна попрацювати. Це може бути помилка, яку Ви виявили самі (що дає Вам відмінну можливість перевірити своє виправлення) або проблема, яку Ви помітили десь ще, наприклад у звіті про ваду.

Harvest зберігає різні переліки TODO, що стосуються розробки Ubuntu. Це переліки помилок, які були вже виправлені у апстрімі або в Debian, переліки невеликих помилок (ми називаємо їх «bitesize») й так далі. Продивіться їх та знайдіть помилку, виправленням якої Ви бажаєте зайнятися.

4.3. З’ясування того, що потрібно виправити

Якщо Ви не знаєте, у якому пакунку джерельного коду міститься помилка, але знаєте шлях до цього застосунку у Вашій системі, то Ви зможете знайти пакунок джерельного коду, над яким потрібно попрацювати.

Припустимо, Ви виявили помилку в Tomboy, застосунку для створення нотаток на стільниці. Додаток Tomboy можна запустити, виконавши /usr/bin/tomboy у командному рядку. Щоб знайти двійковий пакунок, що містить цей застосунок, використовуйте таку команду:

$ apt-file find /usr/bin/tomboy

Команда виведе таку інформацію:

tomboy: /usr/bin/tomboy

Зверніть увагу на те, що частина, передуюча двокрапці, є іменем двійкового пакунку. Часто буває так, що у пакунку джерельного коду і двійкового пакунку різні імена. Частіше за усе, це відбувається, коли один пакунок джерельного коду використовується, щоб створити декілька різних двійкових пакунків. Щоб знайти джерельний пакунок для певного двійкового пакунку, уведіть:

$ apt-cache showsrc tomboy | grep ^Package:
Package: tomboy
$ apt-cache showsrc python-vigra | grep ^Package:
Package: libvigraimpex

Команда apt-cache встановлена в Ubuntu типово.

4.4. Отримання коду

Коли Ви знаєте, над яким пакунком джерельного коду працювати, Ви можете завантажити копію цього пакунку, й зайнятися налагодженням. При розподіленій розробці Ubuntu це робиться за допомогою клонування bzr-репозиторію цього пакунку. Launchpad підтримує Bazaar-гілки для усіх пакунків в Ubuntu.

Як тільки Ви отримали локальну копію джерельного коду, Ви можете дослідити помилку, виправити її, та відправити своє виправлення на Launchpad, у вигляді Bazaar-гілки. Щойно Ви станете достатньо впевнені у своєму виправленні, Ви можете відправити заявку на злиття, тобто попрохати інших розробників продивитися й схвалити Вашу зміну. У випадку згоди з Вашими змінами вони завантажать Ваші зміни у сховище ПЗ. Від Вашої зміни отримають користь усі — навіть Ви, чиє ім’я буде стояти у переліку змін. Ви тепер відбуваєтеся як розробник Ubuntu!

Ми дамо опис специфіки завантаження коду, відправки змін, та створення заявки на перегляд у наступних розділах.

4.5. Виправлення помилки

Є цілі книги про знаходження помилок, їх виправлення, тестування й так далі. Якщо Ви початківець у проґрамуванні, спробуйте виправляти нескладні помилки, такі як очевидні друкарські помилки. Намагайтеся робити Ваші зміни мінімальними й чітко документувати Ваші зміни та припущення.

Перед тим, як працювати над помилкою, переконайтеся, що вона не виправлена вже кимось іншим, й ніхто не займається на дану мить її виправленням. Не завадить перевірити наступні джерела:

  • Система відстеження помилок апстріму (й Debian) — відкриті та закриті помилки,

  • Історія версій в апстрімі (або у новій версії) може містити відомості про виправлення помилки,

  • звіти про вади й нові версії пакунків в Debian та інших дистрибутивах.

Тепер можна створити латку, яка містить виправлення помилки. Команда edit-patch — найпростіший спосіб додати латку до пакунку. Виконайте:

$ edit-patch 99-new-patch

Ця команда скопіює файли, необхідні для збірки пакунку, у тимчасову директорію. Ви можете змінювати ці файли у текстовому редакторі або застосовувати латки з upstream, наприклад:

$ patch -p1 < ../bugfix.patch

Після редагування файлу наберіть exit або натисніть control-d, щоб вийти з тимчасової командної оболонки. Нова латка буде додана в debian/patches.

4.6. Тестування виправлення

Щоб зібрати тестовий пакунок з Вашими змінами, виконайте такі команди:

$ bzr builddeb -- -S -us -uc
$ pbuilder-dist <release> build ../<package>_<version>.dsc

Це створить пакунок джерельного коду з вмісту гілки (-us -uc просто дозволяє пропустити етап підписування пакунку джерельного коду), а pbuilder-dist збере пакунок із джерельного коду для будь-якого вибраного Вами релізу.

Після успішного завершення збірки встановіть пакунок з ~/pbuilder/<release>_result/ (за допомогою sudo dpkg -i <пакунок>_<версія>.deb). Потім перевірте, чи вдалося усунути помилку.

4.6.1. Документування виправлення

Дуже важливо документувати свої зміни у достатній мірі, щоб розробникам потім не довелося здогадуватися, якими були причини й передумови зроблених Вами змін. Кожен пакунок джерельного коду Debian та Ubuntu включає у себе файл debian/changelog, у якому відстежуються вносювані у пакунок зміни.

Найпростіший спосіб оновити його — це виконати:

$ dch -i

Ця команда додасть у файл шаблон запису й запустить редактор, у якому Ви зможете додати інформацію якої бракує. Ось приклад цього запису:

specialpackage (1.2-3ubuntu4) trusty; urgency=low

  * debian/control: updated description to include frobnicator (LP: #123456)

 -- Emma Adams <emma.adams@isp.com>  Sat, 17 Jul 2010 02:53:39 +0200

Команда dch повинна заповнити перший і останній рядок цього запису у файлі changelog. Перший рядок містить ім’я пакунку джерельного коду, номер його версії, у який реліз Ubuntu він завантажений, терміновість (майже завжди низька — ‘low’). Останній рядок завжди містить ім’я, адресу електронної пошти та мітку часу змінювання (у форматі RFC 5322).

Тепер давайте сфокусуємося на тому що має міститися у самому запису файлу changelog. Дуже важливо задокументувати:

  1. де зроблено зміну

  2. що було змінено

  3. де відбувалося обговорення цієї зміни

У нашому (досить поодинокому) прикладі останньому пункту відповідає (LP: #123456), тобто посилання на помилку на Launchpad з номером 123456. Звіти про вади, теми переліків розсилки або специфікації зазвичай є добрими джерелами інформації для обґрунтування змін. У якості додаткового заохочення, якщо Ви використовуєте нотацію LP: #<номер> для помилок на Launchpad, то помилка автоматично отримає статус закритої при відправці пакунку в Ubuntu.

4.6.2. Закріплення зміни

Написавши і зберігши запис в changelog, ми можемо просто запустити:

debcommit

й зміну буде залито (локально) з Вашим записом changelog у якості повідомлення комміту.

Для Launchpad-сховища, у який відправляти Ваші зміни, використовуйте таке ім’я:

lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>

Це може бути, наприклад:

lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456

Тож, якщо Ви просто виконаєте:

bzr push lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456
bzr lp-propose

усе повинно бути готово. Команда push виконає відправку на Launchpad, а друга команда відкриє сторінку віддаленої гілки на Launchpad у Вашому оглядачі. Найдіть там посилання «(+) Propose for merging» й клацніть на ньому, щоб хтось перевірив зміну і включив її в Ubuntu.

Наша стаття про пошук поручительства надає додаткові подробиці про отримання зворотнього зв’язку для запропонованих Вами змін.

Якщо Ваша гілка виправляє помилку у стабільному випуску або це виправлення безпеки, прочитайте нашу статтю Оновлення безпеки й стабільних випусків.