Ubuntu logo

Packaging Guide

Посібник розробника Ubuntu

Ласкаво просимо у посібник розробника Ubuntu! Це офіційна документація з усіх тем, пов’язаних з розробкою Ubuntu та збиранням пакунків для цієї операційної системи. Після того як прочитаєте цей посібник Ви:

  • будете знати про найважливіші засоби, процеси і команди у розробці Ubuntu,

  • зможете правильно налаштувати Ваше середовище розробки,

  • дізнаєтеся, як долучитися до нашої спільноти,

  • виправите справжню помилку в Ubuntu у процесі вивчення посібника.

Ubuntu — не лише вільна операційна система з відкритим джерельним кодом, її платформа також є відкритою й забезпечує прозорість розробки. Можна легко отримати джерельний код для кожного окремого компонента, й кожну окрему зміну у платформі Ubuntu можна перевірити.

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

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

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

Цей посібник складається з двох розділів:

  • Перелік статтей, заснованих на певних завданнях, які Вам можливо знадобиться виконати.

  • Набір статтей бази знань, у яких детальніше розглядаються використовувані нами інструменти й робочі процеси.

Цей посібник фокусується на методі створення пакунків Ubuntu Distributed Development. Це новий спосіб роботи з пакунками, який використовує гілки розподіленої системи керування версіями. На цей час він має деякі обмеження, тому багато команд Ubuntu як і раніше користуються традиційними методами створення пакунків. Щоб дізнатися про відмінності, дивіться сторінку Вступ в UDD.

Статті

Вступ у розробку Ubuntu

Ubuntu складається з тисяч різних компонентів, написаних великою кількістю мов проґрамування. Кожен компонент — бібліотека, засіб або графічний застосунок — доступний у вигляді пакунку джерельного коду. Пакунки джерельних кодів у більшості випадків складаються з двох частин: сам джерельний код і метадані. Метадані включають у себе залежності пакунку, інформацію про авторське право і ліцензію, а також інструкції зі збирання пакунку. Після того, як пакунок джерельних кодів скомпільований, у процесі збирання ми отримаємо двійкові пакунки, що є .deb файлами, які користувачі можуть встановити.

Кожного разу, коли виходить нова версія додатку, або коли хтось вносить зміни у джерельний код пакунку, що входить у склад Ubuntu, пакунок з джерельним кодом повинен бути завантажений на збірочні комп’ютери Launchpad для компілювання. Готові бінарні пакунки потім потрапляють у сховище ПЗ та його дзеркала у різних країнах. URL в /etc/apt/sources.list є посиланнями на сховище або його дзеркал. Кожного дня збираються образи для різних версій Ubuntu. Вони можуть бути використані у різних умовах. Є образи, які можна записати на USB-носії або на DVD-диски, образи, які можна використовувати для мережевого завантаження й є образи, призначені для встановлення на телефон або планшет. Ubuntu, серверна версія Ubuntu, Kubuntu й інші гілки мають специфічний перелік необхідних пакунків, які потрапляють в образ. Це образи, які потім використовуються для перевірки встановлення й забезпечують зворотній зв’язок для подальшого планування випуску.

Розробка Ubuntu дуже залежить від поточної фази циклу випуску. Ми випускаємо нову версію Ubuntu щопів-року, що можливо лише завдяки тому, що ми встановлюємо точні дати «заморожування». При досягненні кожної дати заморожування очікується, що розробники будуть вносити рідші та менш значущі зміни. Заморожування нових функцій (feature freeze) — це перша велика дата заморожування, що приходить після проходження першої половини циклу розробки. На цьому етапі нові функції повинні бути переважно зреалізовані. У залишкову частину циклу має бути зосередженя на виправленні вад. Після цього «заморожується» користувацький інтерфейс, потім документація, ядро й тощо, після чого випускається бета-версія (beta release), яка інтенсивно тестується. Після того, як випущена бета-версія, виправляються лише критичні помилки, й випускається release candidate, який, якщо він не містить серйозних помилок, стає у подальшому кінцевим випуском.

./_images/cycle-items.png

Тисячі пакунків джерельного коду, мільярди рядків коду, сотні розробників потребують більше спілкування й планування для підтримування високих стандартів якості. На початку й у середині кожного циклу випуску організовується Ubuntu Developer Summit, де розробники та участники збираються разом, щоб планувати нові функції у наступних випусках. Кожна функція обговорюється зацікавленими сторонами, і складається специфікація, що містить детальну інформацію про початкові припущення, реалізації, внесення необхідних змін у інші пакунки, про тестування тощо. Усе це робиться прозоро й відкрито, тож Ви можете взяти участь віддалено, подивитися видивотрансляцію, поспілкуватися з участниками та підписатися на специфікації, щоб завжди знати про те що відбувається.

Втім на нараді можуть бути обмірковані не усі зміни, оскільки Ubuntu залежить від змін, що вносяться у інші проєкти. Тому участники розробки Ubuntu залишаються постійно на зв’язку. Більшість команд або проєктів використовують окремі переліки розсилки, щоб уникнути більшого потоку не пов’язаних з їх спеціялізацією листів. Для більш безпосереднього координування розробники і добровільні участники використовують Internet Relay Chat (IRC). Усі оговорення є відкритими та публічними.

Ще одним важливим інструментом зв’язку є звіти про вади. Якщо у пакунку або частині інфраструктури виявлена помилка, звіт про неї відправляється на Launchpad. У цьому звіті зібрана уся інформація, й при необхідності відомості про важливість, статус помилки, та особа призначена для її усунення оновлюються. Це робить звіт про ваду ефективним засобом відстежування помилок у пакунках або проєктах й оптимізації робочого навантаження.

Велика частина доступних в Ubuntu проґрам створена не самими розробниками Ubuntu. Багато з проґрам написані розробниками з інших проєктів з відкритим джерельним кодом, а потім інтегровані в Ubuntu. Такі проєкти прийнято називати «апстрімом» (від англ. upstream — угору за течією), оскільки їх джерельний код вливається в Ubuntu, де ми «просто» інтегруємо його у систему. Зв’язок з апстрімом дуже важливий для Ubuntu. Не лише Ubuntu отримує проґрамний код з апстріму, але й апстрім отримує від користувачів Ubuntu(й інших дистрибутивів) звіти про вади та латки.

Найважливішим апстрімом для Ubuntu є Debian. Debian — це дистрибутив, на якому заснована Ubuntu, й саме там створені багато інженерних рішень, що стосуються інфраструктури пакунків. За традицією, в Debian для кожного окремого пакунку завжди є супроводжуючий (мейнтейнер) або окрема група супроводу. В Ubuntu теж є команди, зацікавлені у роботі над підмножиною пакунків й, зрозуміло, кожен розробник має власну область компетенції, але участь (і права завантаження змін) зазвичай доступні будь-кому, хто продемонструє здатність та бажання працювати.

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

Розробка відкритого проґрамного забезпечення відбувається у розподіленому світі, у якому у розробників можуть бути різні цілі й різні області інтересів. Наприклад, може бути так, що окремий апстрім зацікавлений у роботі над великим нововведенням, в той час як Ubuntu, внаслідок тісного розкладу релізів, більше зацікавлена у випуску стабільної версії, у якій лише виправлені деякі вади. Тому ми використовуємо «Ubuntu Distributed Development», де робота над кодом ведеться у різних гілках, які потім зливаються один з одним після перевірки коду й достатньої кількості обговорень.

./_images/cycle-branching.png

У приведеному вище прикладі має сенс включити в Ubuntu існуючу версію проєкту, зробити виправлення вад, додати їх у апстрім для наступного випуску проєкту й включити його (якщо він до цього придатний) у наступний випуск Ubuntu. Це буде найкращим компромісом і ситуацією у якій виграють обидві сторони.

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

./_images/cycle-process.png

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

Додаткові кроки, які Ви можете зробити, — це адаптування Вашої зміни для попередніх підтримуваних випусків Ubuntu й відправлення її в апстрім.

Найважливішими вимогами для успішної розробки в Ubuntu є: вміти «примушувати речі знову працювати», не боятися читати документацію й задавати питання, бути командним гравцем та мати певну схильність до роботи детектива.

Відповідними місцями для отримання відповідей на Ваші питання є ubuntu-motu@lists.ubuntu.com і #ubuntu-motu на irc.freenode.net. Там Ви легко знайдете багато нових друзів і людей, які поділяють вашу пристрасть: робити світ кращим, поліпшуючи відкрите проґрамне забезпечення.

Підготовка

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

  • Встановлення проґрам для роботи з пакунками. Вони включають у себе:

    • специфічні для Ubuntu засоби створення пакунків

    • криптографічну проґраму, яка дозволить іншим переконатися, що робота виконана саме Вами

    • додаткові проґрами шифрування, що забезпечують безпечне передавання файлів

  • Створення й налаштування облікового запису на Launchpad

  • Налаштування Вашого середовища розробки для полегшення локальної збірки пакунків, взаємодії з іншими розробниками й відправки Ваших змін на Launchpad.

Примітка

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

Не бентежтеся, Ви можете скористатися Testdrive або chroots для безпечного використання розроблюваної версії (релізу)

Встановлення базового проґрамного забезпечення для створення пакунків

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

$ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file

Нотатка: Починаючи з Ubuntu 11.10 «Oneiric Ocelot» (або якщо увімкнений репозиторій Backports у поточному підтримуваному випуску), наступна команда встановлює усе вищезгадане й інші інструменти, що часто використовуються у розробці Ubuntu:

$ sudo apt-get install packaging-dev

Ця команда встановить такі проґрами:

  • gnupgGNU Privacy Guard містить інструменти, які знадобляться для створення криптографічного ключа, за допомогою якого Ви будете підписувати файли, які бажаєте завантажити на Launchpad

  • pbuilder – інструмент для створення готових до подальшого розповсюдження збірок пакунків у чистому та ізольованому середовищі.

  • ubuntu-dev-tools (і його безпосередня залежність devscripts) – набір інструментів, що спрощують багато завдань зі створення пакунків.

  • bzr-builddeb (і його залежність – bzr) – керування розподіленими версіями за допомогою Bazaar (новий спосіб роботи з пакунками для Ubuntu), що спрощує спільну роботу багатьох людей над одним й тим самим кодом й що дозволяє з легкістю об’єднувати результати їх праці один з одним.

  • apt-file надає простий спосіб знайти двійковий пакунок, що містить заданий файл.

Створення ключа GPG

GPG — абревіятура для GNU Privacy Guard, реалізуючого стандарт OpenPGP, який дозволяє підписувати та шифрувати повідомлення й файли. Це корисно у ряді ситуацій. У нашому випадку важливо, що Ви можете використовувати свій ключ для підписування файлів, щоб можна було переконатися, що саме Ви з ними працювали. Якщо Ви завантажите пакунок джерельного коду на Launchpad, він буде прийнятий лише у тому випадку, якщо можна точно визначити, хто саме відправив пакунок.

Щоб згенерувати новий ключ GPG, наберіть:

$ gpg --gen-key

GPG спочатку спитає, який тип ключа Ви бажаєте створити. Типовий вибір (RSA и DSA) цілком влаштує. Далі він спитає вказати розмір ключа. Типовий розмір (на цей час 2048) влаштує, але 4096 надійніше. Далі, проґрама спитає, чи бажаєте Ви, щоб термін дії ключа вийшов через якийся час. Безпечніше відповісти “0”, що означає, що термін дії не сплине ніколи. Останнє питання буде про Ваше ім’я та адресу електронної пошти. Просто виберіть адресу, якою Ви користуєтеся при розробці Ubuntu, додаткові адреси можна буде додати потім. Додавати коментар не обов’язково. Після цього потрібно вказати надійне парольне гасло (парольне гасло — це просто пароль, у якому дозволяється використовувати пробіли).

Тепер GPG створить для Вас ключ, що може зайняти певний час. Для його створення знадобляться випадкові байти, тому буде просто чудово, якщо Ви задасте своїй системі якусь роботу. Порухайте вказівник миші, наберіть декілька абзаців будь-якого тексту, завантажте будь-яку веб-сторінку.

Коли процес буде завершено, Ви отримаєте повідомлення типу такого:

pub   4096R/43CDE61D 2010-12-06
      Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
uid                  Daniel Holbach <dh@mailempfang.de>
sub   4096R/51FBE68C 2010-12-06

У даному випадку, 43CDE61D — це ідентифікатор ключа (key ID).

Потім потрібно завантажити відкриту (public) частину Вашого ключа на сервер ключів, щоб усі могли ідентифікувати повідомлення і файли, як відправлені Вами. Для цього уведіть:

$ gpg --send-keys --keyserver keyserver.ubuntu.com <KEY ID>

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

Створення ключа SSH

SSH або Secure Shell — це протокол, який дозволяє безпечно обмінюватися даними мережею. Звичайною практикою є використання SSH для доступу й відкриття командної оболонки на іншому комп’ютері й для безпечної пересилки файлів. З нашою метою ми переважно будемо використовувати SSH для безпечної відправки пакунків джерельного коду на Launchpad.

Щоб згенерувати ключ SSH, уведіть:

$ ssh-keygen -t rsa

Типове ім’я файлу цілком влаштує, тож можете залишити його як є. З метою безпеки настійно рекомендується вказати парольне гасло.

Налаштування pbuilder

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

  • Збірка буде виконана у мінімальному й чистому середовищі. Це дасть можливість переконатися, що збірку вдастся успішно відтворити й на інших комп’ютерах, але при цьому допоможе уникнути змін у Вашій локальній системі

  • Зникає необхідність у локальному встановленні усіх збірочних залежностей

  • Можна налаштувати декілька екземплярів для різних випусків Ubuntu і Debian

Налаштувати pbuilder дуже просто. Наберіть

$ pbuilder-dist <release> create

де <release> — це, наприклад raring, saucy, trusty або, у випадку Debian, sid. Виконання команди займе певний час, оскільки будуть завантажені усі пакунки, необхідні для “мінімального встановлення”. Втім, при цьому використовується кешування.

Підготовка до роботи з Launchpad

Після того, як базова локальна конфігурація створена, наступним кроком буде налаштування системи для роботи з Launchpad. У цьому розділі ми сфокусуємося на таких питаннях:

  • Що таке Launchpad й як створити обліковий запис на Launchpad

  • Завантаження Ваших ключів GPG та SSH на Launchpad

  • Налаштування Bazaar для роботи з Launchpad

  • Налаштування Bash для роботи з Bazaar

Відомості про Launchpad

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

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

Крім хостингу Ubuntu, Launchpad може надавати місце для будь-якого вільного проґрамного проєкту. Додаткову інформацію дивіться на Довідкових вікі-сторінках Launchpad

Створення облікового запису на Launchpad

Якщо в Вас ще немає облікового запису на Launchpad, Ви легко можете створити його. Якщо обліковий запис є, але Ви не пам’ятаєте свій Launchpad ID, його можна дізнатися, зайшовши на https://launchpad.net/~ і поглянувши на частину після ~ в URL.

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

При реєстрації нового облікового запису Launchpad відправить Вам листа з посиланням, яке потрібно відкрити у оглядачі тенет, щоб підтвердити вказану Вами адресу електронної пошти. Якщо Ви не отримали листа, перевірте теку небажаної пошти (спаму).

Довідкова сторінка нового облікового запису на Launchpad містить додаткову інформацію про процес та додаткові налаштування, які можна зробити.

Завантаження Вашого ключа GPG на Launchpad

Спочатку потрібно отримати відбиток та ідентифікатор ключа.

Щоб взнати свій відбиток ключа GPG (fingerprint), наберіть:

$ gpg --fingerprint email@address.com

й Ви побачите щось типу:

pub   4096R/43CDE61D 2010-12-06
      Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
uid                  Daniel Holbach <dh@mailempfang.de>
sub   4096R/51FBE68C 2010-12-06

Потім виконайте цю команду для відправки Вашого ключа на сервер ключів Ubuntu:

$ gpg --keyserver keyserver.ubuntu.com --send-keys 43CDE61D

де 43CDE61D слід замінити на Ваш ідентифікатор ключа (він у першому рядку виводу попередньої команди). Тепер можна імпортувати свій ключ на Launchpad.

Зайдіть на https://launchpad.net/~/+editpgpkeys й скопіюйте дані з рядка «Key fingerprint» у текстове поле. У наведеному вище прикладі це буде 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D. Потім клацніть «Import Key».

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

Launchpad шифрує пошту, використовуючи Ваш публічний ключ, тож Ви зможете переконатися, що ключ Ваш. Якщо Ви користуєтеся поштовим клієнтом Thunderbird, який використовується в Ubuntu типово, для дешифрування повідомлення можете встановити доповнення Enigmail. Якщо Ваша поштова проґрама не підтримує шифрування OpenPGP, скопіюйте зашифрований вміст листа у буфер обміну, наберіть у терміналі gpg й вставте вміст листа у вікно терміналу.

Повернувшись на сайт Launchpad, скористайтеся кнопкою «Confirm», щоб Launchpad завершив імпорт Вашого ключа OpenPGP.

Додаткову інформацію можна знайти на https://help.launchpad.net/YourAccount/ImportingYourPGPKey

Завантаження Вашого ключа SSH на Launchpad

Відкрийте у оглядачі тенет https://launchpad.net/~/+editsshkeys, а у текстовому редакторі файл ~/.ssh/id_rsa.pub. Це відкрита частина Вашого ключа SSH, тому можна без побоювань надати до неї спільний доступ на Launchpad. Скопіюйте вміст файлу й вставьте його у текстове поле на веб-сторінці з міткою «Add an SSH key». Потім клацніть «Import Public Key».

Для додаткової інформації про цей процес відвідайте сторінку про створення ключової пари SSH на Launchpad.

Налаштування Bazaar

Bazaar — це інструмент, який ми використовуємо для зберігання змін у коді, у логічний і передбачуваний спосіб, а також обміну пропонованими змінами й їх злиття, навіть у тому випадку, якщо розробка ведеться параллельно декількома людьми. Він використовується у новому методі роботи з пакунками Ubuntu — Ubuntu Distributed Development.

Щоб повідомити Bazaar про те, хто Ви, просто наберіть:

$ bzr whoami "Bob Dobbs <subgenius@example.com>"
$ bzr launchpad-login subgenius

whoami повідомить Bazaar, яке ім’я й адресу електронної пошти він повинен використовувати для Ваших коммітів. За допомогою launchpad-login Ви вказуєте свій Launchpad ID. Це код, який ідентифікує Ваш обліковий запис на Launchpad.

Нотатка: якщо Ви не пам’ятаєте свій ідентифікатор, перейдіть на https://launchpad.net/~ й подивіться, куди Вас переспрямовує ця сторінка. Частина URL після символу «~» — це й є Ваш Launchpad ID.

Налаштування командної оболонки

Як і Bazaar, інструментам створення пакунків Debian/Ubuntu знадобиться деяка інформація про Вас. Просто відкрийте ~/.bashrc у текстовому редакторі й додайте внизу щось типу цього:

export DEBFULLNAME="Bob Dobbs"
export DEBEMAIL="subgenius@example.com"

Потім збережіть файл й перезапустіть термінал або наберіть:

$ source ~/.bashrc

(Якщо Ви не користуєтеся стандартною командною оболонкою bash, відредагуйте конфігураційний файл тієї оболонки, яку Ви полюбляєте використовувати.)

Розподілена розробка Ubuntu — вступ

Цей посібник фокусується на роботі з пакунками з використанням методу Ubuntu Distributed Development (UDD).

Ubuntu Distributed Development (UDD) — це нова технологія розробки пакунків Ubuntu, що використовує інструменти, процеси й послідовності дій, характерні для типової схеми розробки проґрам, заснованій на розподіленій системі керування версіями (DVCS). DVCS, що використовується в UDD — це Bazaar.

Обмеження традиційних методів створення пакунків

Традиційно пакунки Ubuntu зберігаються у архівних tar-файлах. Традиційний пакунок джерельного коду складається з tar-файлу з джерельним кодом із апстріму, “debian” tar-файлу (або стисненого diff-файлу для старіших пакунків), що містить набір вхідних файлів для ствроення пакунку, і файлу .dsc з метаданими. Щоб подивится на традиційний пакунок, виконайте команду:

$ apt-get source kdetoys

Вона завантажить джерельні коди з апстріму kdetoys_4.6.5.orig.tar.bz2, набір вхідних файлів kdetoys_4.6.5-0ubuntu1.debian.tar.gz й метадані kdetoys_4.6.5-0ubuntu1~ppa1.dsc. Якщо в Вас встановлено dpkg-dev, вона витягне їх вміст і надасть Вам пакунок джерельного коду.

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

Розподілена розробка Ubuntu

З Ubuntu Distributed Development усі пакунки у архіві Ubuntu (і Debian) автоматично імпортуються у гілки Bazaar на нашому сайті хостингу коду Launchpad. Зміни можна вносити напряму у ці гілки кроками збільшення будь-яким користувачем, в якого є доступ. Зміни також можна вносити у роздвоєні гілки й з’єднувати їх назад за допомогою Пропозицій та Злиттів (Merge Proposals), коли вони стануть достатньо великими для розгляду, або якщо створені кимось без прямого доступу.

UDD гілки усі знаходяться у стандартному місцезнаходженні, тому налагодження буде легким:

$ bzr branch ubuntu:kdetoys

Історія об’єднань включає дві окремі гілки, одну для джерела апстріму й іншу, яка додасть директорію пакунку debian/:

$ cd kdetoys
$ bzr qlog

(Ця команда використовує у якості графічного інтерфейсу qbzr. Для виводу у консоль, запустіть log замість qlog.)

./_images/kdetoys-udd-branch.png

UDD гілка kdetoys позначає повний пакунок для кожної версії, завантаженій в Ubuntu сірими колами й версії джерела апстріму - зеленими. Версії позначаються або версіями Ubuntu (наприклад, 4:4.2.29-0ubuntu1) або для гілок апстріму - версією апстріму (upstream-4.2.96).

Багато пакунків Ubuntu засновані на пакунках в Debian, UDD також імпортує й пакунок Debian у наші гілки. У гілці kdetoys вище версії Debian з unstable після об’єднання позначені синіми колами, у той час як з Debian experimental після об’єднання позначені жовтими. Релізи Debian позначені номерами своїх версій, наприклад, 4:4.2.2-1.

Таким чином з UDD-гілки Ви можете побачити повну історію змін пакунку й порівняти будь-які дві версії. Наприклад, щоб побачити відмінності між версією 4.2.2 в Debian і 4.2.2 в Ubuntu, використовуйте:

$ bzr qdiff -r tag:4:4.2.2-1..tag:4:4.2.2-1ubuntu1

(Ця команда використовує графічний інтерфейс qbzr. Запустіть diff замість qdiff для виводу у консоль.)

./_images/kdetoys-udd-diff.png

Тут ми можемо ясно побачити, що було змінено в Ubuntu у порівнянні з Debian-версією. Дуже зручно.

Bazaar

Гілки UDD використовують Bazaar — розподілену систему керування версіями, яка проста у використанні для тих, хто знайомий з такими популярними системами, як Subversion, й у той же час уявляє усю міць Git.

Щоб зробити пакунок з UDD Вам потрібно знати основи використання Bazaar для керування файлами. Для отримання базових навичок роботи з Bazaar дивіться П’ятихвилинне навчання Bazaar й Посібник з використання Bazaar.

Обмеження UDD

Ubuntu Distributed Development — новий метод роботи з пакунками Ubuntu. На даний час він має деякі суттєві обмеження:

  • Створення повної гілки з історією може забрати багато часу та мережевих ресурсів. Можливо Вам швидше буде зробити легке налагодження bzr checkout --lightweight ubuntu:kdetoys, але тоді знадобиться мережевий доступ для будь-яких подальших операцій bzr.

  • Робота над латками дуже клопітка. Латки можна розглядати як розгілковану переробку системи керування, таким чином ми отримуємо RCS поверх RCS.

  • Немає способу створювати білди напряму з гілок. Потрібно створювати джерельний пакунок і завантажувати його.

  • Деякі пакунки не були успішно імпортовані у гілки UDD. Останні версії Bazaar автоматично будуть сповіщати Вас у випадку виникнення подібної ситуації. Перед початком роботи з гілкою Ви можете вручну поставити позначку status of the package importer.

Над усім вищеперерахованим наразі ведеться робота й очікується, що UDD незабаром стане основним способом роботи над пакунками Ubuntu. Втім, зараз більшість команд Ubuntu ще не працювали з гілками UDD. Але оскільки UDD гілки є тим самим, що й пакунки у архіві, будь-яка команда має бути у змозі з ними працювати.

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

Вступ

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

./_images/fixing-a-bug.png

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

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

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

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

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

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

Припустимо, Ви виявили помилку в 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 типово.

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

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

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

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

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

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

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

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

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

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

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

$ edit-patch 99-new-patch

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

$ patch -p1 < ../bugfix.patch

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

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

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

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

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

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

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

Дуже важливо документувати свої зміни у достатній мірі, щоб розробникам потім не довелося здогадуватися, якими були причини й передумови зроблених Вами змін. Кожен пакунок джерельного коду 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.

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

Написавши і зберігши запис в 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.

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

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

Демонстрація: виправлення помилки в Ubuntu

Хоч техніка виправлення помилки однакова для будь-яких помилок, кожна помилка все ж у чомусь відрізняється від інших. Даний приклад виправлення конкретної помилки може допомогти Вам зрозуміти, що зазвичай потрібно прийняти до уваги.

Примітка

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

Підтвердження проблеми

Припустимо, у описі пакунку bumprace відсутня інформація про його домашню сторінку. У якості першого кроку, слід перевірити, чи не виправлена вже ця помилка. Зробити це просто: подивіться у Центрі додатків або запустіть:

apt-cache show bumprace

Вивід команди повинен бути приблизно таким:

Package: bumprace
Priority: optional
Section: universe/games
Installed-Size: 136
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Christian T. Steigies <cts@debian.org>
Architecture: amd64
Version: 1.5.4-1
Depends: bumprace-data, libc6 (>= 2.4), libsdl-image1.2 (>= 1.2.10),
         libsdl-mixer1.2, libsdl1.2debian (>= 1.2.10-1)
Filename: pool/universe/b/bumprace/bumprace_1.5.4-1_amd64.deb
Size: 38122
MD5sum: 48c943863b4207930d4a2228cedc4a5b
SHA1: 73bad0892be471bbc471c7a99d0b72f0d0a4babc
SHA256: 64ef9a45b75651f57dc76aff5b05dd7069db0c942b479c8ab09494e762ae69fc
Description-en: 1 or 2 players race through a multi-level maze
 In BumpRacer, 1 player or 2 players (team or competitive) choose among 4
 vehicles and race through a multi-level maze. The players must acquire
 bonuses and avoid traps and enemy fire in a race against the clock.
 For more info, see the homepage at http://www.linux-games.com/bumprace/
Description-md5: 3225199d614fba85ba2bc66d5578ff15
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

У якості контрприкладу можна привести gedit, де домашня сторінка вказана:

$ apt-cache show gedit | grep ^Homepage
Homepage: http://www.gnome.org/projects/gedit/
$

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

Вивчення ситуації з помилкою

Спочатку потрібно перевірити, чи не існує вже повідомлення про цю помилку в Ubuntu. Можливо, хтось вже працює над її виправленням, або ми можемо якось внести свій внесок у вирішення цієї проблеми. Для Ubuntu ми поглянемо на https://bugs.launchpad.net/ubuntu/+source/bumprace й побачимо, що відкритого звіту про нашу ваду там немає.

Примітка

Для Ubuntu URL https://bugs.launchpad.net/ubuntu/+source/<пакунок> завжди приводить на сторінку помилок у вказаномум пакунку джерельного коду.

У Debian, який є основним джерелом пакунків Ubuntu ми поглянемо на http://bugs.debian.org/src:bumprace й також не знайдемо там повідомлення про нашу ваду.

Примітка

Для Debian URL http://bugs.debian.org/src:<пакет> завжди приводить на сторінку помилок у вказаному пакунку джерельного коду.

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

Пропозиція допомоги

Якщо Ви виявили відкриту ваду, яка ще нікому не призначена, й Ви готові взятися за її усунення, слід написати коментар з Вашим вирішенням. Включіть у нього щонайбільше інформації: При яких обставинах з’являється помилка? Як Ви її виправили? Чи тестували Ви свій спосіб усунення помилки?

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

Буде чудово, якщо Ви можете запропонувати свою допомогу, й вона, без сумніву, буде з готовністю прийнята.

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

У даному конкретному прикладі недостатньо просто знайти веб-сайт bumprace й визначити адресу його домашньої сторінки. Потрібно переконатися, що сайт працює, й він не є просто каталогом різних проґрам. http://www.linux-games.com/bumprace/ виглядає відповідним місцем.

Щоб взятися за ваду у пакунку джерельного коду, нам знадобиться цей джерельний код, й ми легко можемо отримати його, набравши:

bzr branch ubuntu:bumprace

Якщо Ви прочитали огляд каталогу Debian, то пам’ятайте, ймовірно, що домашня сторінка вказується у першій частині debian/control, у секції, що починається з Source:.

Тож тепер ми маємо виконати команду:

cd bumprace

й відредагувати debian/control, додавши Homepage: http://www.linux-games.com/bumprace/. У кінці першої секції має бути відповідне місце для цього. Після внесення змін збережіть файл.

Якщо тепер Ви виконаєте:

bzr diff

Ви повинні побачити щось типу цього:

=== modified file 'debian/control'
--- debian/control      2012-05-14 23:38:14 +0000
+++ debian/control      2012-09-03 15:45:30 +0000
@@ -12,6 +12,7 @@
                libtool,
                zlib1g-dev
 Standards-Version: 3.9.3
+Homepage: http://www.linux-games.com/bumprace/

 Package: bumprace
 Architecture: any

Синтаксис diff дуже простий для розуміння. + вказує рядок, який був доданий. У нашому випадку його було додано безпосередньо перед другою секцією, що починається з Package, яка вказує на готовий двійковий пакунок.

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

Важливо пояснити своїм колегам - розробникам, що саме Ви зробили. Якщо Ви наберете:

dch -i

це запустить редактор, з шаблоном запису у changelog, який Вам залишається лише дозаповнити. У нашому випадку повинне підійти щось типу debian/control: Added project's homepage. Потім збережіть файл. Щоб ще раз перевірити, що усе працює, наберіть:

bzr diff debian/changelog

й Ви побачите щось типу цього:

=== modified file 'debian/changelog'
--- debian/changelog    2012-05-14 23:38:14 +0000
+++ debian/changelog    2012-09-03 15:53:52 +0000
@@ -1,3 +1,9 @@
+bumprace (1.5.4-1ubuntu1) UNRELEASED; urgency=low
+
+  * debian/control: Added project's homepage.
+
+ -- Peggy Sue <peggy.sue@example.com>  Mon, 03 Sep 2012 17:53:12 +0200
+
 bumprace (1.5.4-1) unstable; urgency=low

   * new upstream version, sound and music have been removed (closes: #613344)

Декілька додаткових міркувань:

  • Якщо в Вас є посилання на ваду на Launchpad, яку виправляє Ваша зміна, додайте (LP: #<номер помилки>) у запис changelog, наприклад: (LP: #123456).

  • Якщо Ви бажаєте, щоб Ваше виправлення було включено у Debian, синтаксис для вади в Debian буде (Closes: #<номер помилки>), наприклад: (Closes: #123456).

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

  • Намагайтеся робити перенесення рядків після 80 символів.

  • Намагайтеся викладати детально: не варто писати цілий твір, але вкажіть достатньо інформації, щоб зрозуміти могла будь-яка людина (навіть якщо вона не занурювався глибоко у цю проблему).

  • Вкажіть, як і де Ви виправили помилку.

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

Щоб перевірити виправлення, Вам знадобиться налаштувати своє середовище розробки, потім зібрати пакунок, встановити його й перевірити, що проблему усунено. У нашому випадку це будуть наступні дії:

bzr bd -- -S
pbuilder-dist <current Ubuntu release> build ../bumprace_*.dsc
dpkg -I ~/pbuilder/*_result/bumprace_*.deb

Першою командою ми створюємо пакунок джерельного коду з гілки, потім збираємо його за допомогою pbuilder, після чого перевіряємо, чи правильно додано поле домашньої сторінки у пакунку що отримали.

Примітка

У більшості випадків Вам доведеться дійсно встановити пакунок, щоб перевірити правильність його роботи. Наш випадок на багато простіший. Якщо збірка завершилася з успіхом, готові двійкові пакунки можна буде знайти в ~/pbuilder/<випуск>_result. Встановіть їх за допомогою sudo dpkg -i <пакунок>.deb або подвійного клацу на них у файловому менеджері.

Після того, як ми переконалися, що проблема вирішена, наступним кроком буде поділитися своїм рішенням з усім світом.

Застосування виправлення

It makes sense to get the fix included as Upstream as possible. Doing that you can guarantee that everybody can take the Upstream source as-is and don’t need to have local modifications to fix it.

У нашому випадку ми встановили, що помилка відноситься лише до пакунків Ubuntu і Debian. Оскільки Ubuntu заснована на Debian, ми повинні відправити випралення в Debian. Після того, як в Debian з’явиться виправлений пакунок, він потрапляє також і в Ubuntu. Наша помилка не критична, тому можна так зробити. Якщо ж важливо застосувати виправлення як найшвидше, то необхідно відправити виправлення у декілька баг-трекерів (якщо воно зачепає відповідні проєкти).

Щоб відправити латку в Debian, просто наберіть:

submittodebian

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

Комунікація має дуже велике значення, тому при додаванні опису надайте добре та дружнє пояснення.

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

Примітка

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

Додаткові зауваження

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

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

Створення пакунків для нових проґрам

Хоч у архіві Ubuntu є тисячі пакунків, вистачає проґрам, якими ніхто не займається. Якщо Ви знаєте про якусь чудову проґраму, про яку, на Вашу думку, варто взнати ширшому колу користувачів, Ви можете спробувати докласти свою руку до створення пакунку для Ubuntu або PPA. Цей посібник проведе Вас через етапи створення пакунку для нової проґрами.

Спочатку Вам слід прочитати статтю Підготовка, щоб підготувати своє середовище розробки.

Перевірка проґрами

Першим етапом створення пакунку є отримання tar-файлу з апстріму («апстрімом» ми звемо авторів застосунків) й перевірка того, що він нормально компілюється та запускається.

Цей посібник проведе Вас через процес створення пакунку для невеликого застосунку GNU Hello, доступного на GNU.org.

Якщо в Вас ще немає інструментів збірки, встановіть їх. Також встановіть усі необхідні залежності.

Встановимо інструменти збірки:

$ sudo apt-get install build-essential

Стягнемо основний пакунок:

$ wget -O hello-2.7.tar.gz "http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz"

Тепер розпакуємо основний пакунок:

$ tar xf hello-2.7.tar.gz
$ cd hello-2.7

Цей застосунок використовує систему збірки autoconf, тож нам потібно запустити ./configure для підготовки до компілювання.

При цьому буде перевірено наявність необхідних для збірки залежностей. Оскільки hello — простий приклад, build-essential забезпечить нас усім, що потрібно. Для складніших проґрам, команда завершиться помилкою, якщо в нас немає необхідних бібліотек і файлів для розробки. Встановіть потрібні пакунки й повторіть процес, поки команда не завершиться з успіхом.:

$ ./configure

Тепер потрібно скомпілювати джерельний код:

$ make

Якщо компілювання завершилося успішно, можна встановити та запустити проґраму:

$ sudo make install
$ hello

Створення пакунку

bzr-builddeb містить модуль для створення нового пакунку з шаблону. Цей модуль є обгорткою навколо команди dh_make . Він вже повинен бути в Вас, якщо Ви встановили packaging-dev. Запустіть команду, вказавши ім’я пакунку, номер версії та шлях до tar-архіву з апстріму:

$ sudo apt-get install dh-make bzr-builddeb
$ cd ..
$ bzr dh-make hello 2.7 hello-2.7.tar.gz

Коли він спитає тип пакунку, оберіть s: одинарний бінарник. Це імпортує код у гілку й створить теку debian/. Погляньте на її вміст: більшість автоматично створених файлів потрібні лише для спеціялізованих пакунків (наприклад модулі Emacs), тож можна почати з вилучення зайвих файлів:

$ cd hello/debian
$ rm *ex *EX

Тепер потрібно внести зміни у кожен з файлів.

В debian/changelog змініть номер версії на версію Ubuntu: 2.7-0ubuntu1 (апстрім-версія 2.7, версія в Debian 0, версія в Ubuntu 1). Також змініть unstable на поточний розроблюваний випуск Ubuntu, наприклад, trusty.

Велика частина процесу компілювання пакунку здійснюється скриптами з debhelper. Оскільки поведінка debhelper змінюється при виході старшої версії, файл compat повідомляє debhelper яку саме версію використовувати. Має сенс використовувати найсвіжішу версію: 9.

Файл control містить усі метадані пакунку. Перший абзац дає опис пакунку джерельних кодів. Другий та наступні абзаци дають опис двійкових пакунків, які повинні бути зібрані. Нам знадобиться додати пакунки, необхідні для компілювання додатку в Build-Depends:. Для hello він має включати, як мінімум:

Build-Depends: debhelper (>= 9)

Також потрібно заповнити опис проґрами у полі Description:.

copyright потрібно заповнити у відповідності з ліцензією на джерело з апстріму. Згідно файлу hello/COPYING, це ліцензія GNU GPL 3 або пізніша її версія.

docs повинен містити будь-які файли документації з апстріму, які, на Вашу думку, мають бути включені у готовий пакунок.

README.source і README.Debian необхідні, лише якщо Ваш пакунок має якісь нестандартні функції. В нас таких немає, тож можна вилучити ці файли.

source/format можна залишити як є, він дає опис формату версії пакунку джерельного коду, який повинен бути 3.0 (quilt).

rules — найскладніший файл. Це Makefile, який компілює код й перетворює його у двійковий пакунок. На щастя, основну частину роботи на сьогодні автоматично виконує debhelper 7, тож універсальна мета % просто запускає сценарій dh, який робить усе, що потрібно.

Детальніший опис усіх цих фалів у статті огляд каталогу debian.

Нарешті, закоммте код у гілку для пакунків:

$ bzr add debian/source/format
$ bzr commit -m "Initial commit of Debian packaging."

Збірка пакунку

Тепер нам потрібно перевірити, що наші джерельні файли для пакунку успішно компілюються й збираються у двійковий .deb-пакунок:

$ bzr builddeb -- -us -uc
$ cd ../../

bzr builddeb — це команда для збірки пакунку у його поточному місцезнаходженні. -us -uc повідомляє що підписувати пакунок за допомогою GPG не потрібно. Результат буде поміщений у каталог «..».

Продивитися вміст пакунку можна за допомогою:

$ lesspipe hello_2.7-0ubuntu1_amd64.deb

Встановіть пакунок й перевірте, що він працює (пізніше за бажання Ви зможете вилучити його командою sudo apt-get remove hello):

$ sudo dpkg --install hello_2.7-0ubuntu1_amd64.deb

Можете також встановити усі пакунки одразу за допомогою:

$ sudo debi

Наступні кроки

Навіть якщо двійковий .deb-пакунок успішно збирається, Ваші джерельні файли для пакунку можуть містити помилки. Багато помилок можуть автоматично виявлятися нашим інструментом lintian, який можна застосувати до файлу метаданих .dsc, двійкових пакунків .deb або файлу .changes:

$ lintian hello_2.7-0ubuntu1.dsc
$ lintian hello_2.7-0ubuntu1_amd64.deb

Щоб побачити детальний опис вад, використовуйте прапорець lintian --info або команду lintian-info.

Результати перевірок архіву Ubuntu можна знайти у Інтернеті на http://lintian.ubuntuwire.org.

Для пакунків Python є також інструмент lintian4python, здійснюючий деякі додаткові перевірки lintian.

Після створення виправлення для файлів пакунку можна перезібрати його з параметром -nc (“no clean”), щоб не починати збірку з самого початку:

$ bzr builddeb -- -nc -us -uc

Переконавшись, що пакунок успішно збирається локально, Ви повинні перевірити, чи правильно його збирання буде відбуватися у чистій системі, за допомогою pbuilder. Оскільки незабаром ми збираємося завантажити його в PPA (персональний архів пакунків), це завантаження потрібно забезпечити цифровим підписом, щоб Launchpad міг переконатися, що завантаження зробили Ви (дізнатися про те, що завантаження буде підписане, можна за відсутністю передаваних bzr builddeb прапорців -us і -uc, які ми використовували раніше). Для підписування своєї роботи Вам знадобиться налаштувати GPG. Якщо Ви ще не налаштували pbuilder-dist або GPG, зробіть це зараз:

$ bzr builddeb -S
$ cd ../build-area
$ pbuilder-dist trusty build hello_2.7-0ubuntu1.dsc

Після того як Ви залишитеся задоволені отриманим пакунком, потрібно, щоб його перевірили інші люди. Ви можете вивантажити гілку на Launchpad для перевірки:

$ bzr push lp:~<lp-username>/+junk/hello-package

Вивантаження в PPA дозволить переконатися, що пакунок збирається нормально, а також дозволить Вам і решті тестувати бінарні пакунки. Вам знадобиться створити PPA на Launchpad, після чого вивантажити пакунок за допомогою dput:

$ dput ppa:<lp-username>/<ppa-name> hello_2.7-0ubuntu1.changes

Дивіться розділ «Завантаження» для додаткової інформації.

Попрохати провести review можна на каналі IRC #ubuntu-motu, або у переліку розсилки MOTU. У деяких випадках може знадобитися участь конкретної команди: у подібних випадках команда GNU допоможе розібратися.

Відправка на включення

Існує декілька шляхів, якими пакунок може потрапити в Ubuntu. У більшості випадків кращим шляхом може бути проходження спочатку через Debian. Це дозволить Вашому пакунку стати доступним для щонайбільшої кількості користувачів, оскільки він буде доступний не лише в Debian та Ubuntu, але й в усіх дистрибутивах, створених на їх основі. Ось декілька корисних посилань з відправки нових пакунків в Debian:

  • Debian Mentors FAQ - debian-mentors створений для менторства нових і перспективних розробників Debian. Це те місце, де можна знайти спонсора для завантаження Вашого пакунку в архів.

  • Work-Needing and Prospective Packages - інформація про те як відправляти баги “Intent to Package” (Призначення пакунку) і “Request for Package” (Запит пакунку), а також переліки відкритих ITP та RFP.

  • Посібник Розробника Debian, 5.1. Створення пакунків - безцінний документ для творців пакунків як під Ubuntu, так й під Debian. Даний розділ дає опис процесу відправки нових пакунків.

У деяких випадках має сенс відправлятися прямо в Ubuntu. Наприклад, якщо Debian знаходиться у стані “freeze”: тоді Ваш пакунок навряд встигне увійти в Ubuntu до найближчого релізу. Опис цього процесу на сторінці “Нові Пакунки” Ubuntu Wiki.

Знятки екрану

Завантаживши пакунок в Debian, Вам слід додати знятки екрану, аби майбутні користувачі змогли отримати уяву про те, як виглядає інтерфейс проґрами. Знятки потрібно відправляти на http://screenshots.debian.net/upload .

Оновлення безпеки й оновлення стабільних релізів

Виправлення помилок безпеки в Ubuntu

Вступ

Виправлення дірок у безпеці в Ubuntu фактично не відрізняється від виправлення звичайного багу, і припускається, що Ви знайомі з виправленням звичайних багів. Для демонстрації відмінностей ми будемо додавати у пакунок dbus в Ubuntu 12.04 LTS (Precise Pangolin) оновлення для системи безпеки.

Отримання джерельного коду

У даному прикладі ми вже знаємо, що бажаємо виправити пакунок dbus в Ubuntu 12.04 LTS (Precise Pangolin). Тому спочатку потрібно визначити версію пакунку, який бажаєте стягнути. Ми можемо використовувати rmadison у якості допомоги у даній ситуації.

$ rmadison dbus | grep precise
dbus | 1.4.18-1ubuntu1   | precise          | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-security | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-updates  | source, amd64, armel, armhf, i386, powerpc

Зазвичай обирають найостаннішу версію для релізу, який Ви бажаєте залатати, який не в -proposed або -backports. Оскільки ми оновлюємо dbus Precise, Ви стягнете 1.4.18-1ubuntu1.4 з precise-updates:

$ bzr branch ubuntu:precise-updates/dbus
Створення латки

Тепер, коли ми маємо джерельний пакунок, ми повинні зробити латку для виправлення вразливості. Ви можете використовувати будь-який метод, що підходить для даного пакунку, у тому числі методи UDD, але у цьому прикладі будемо використовувати edit-patch (з пакунку ubuntu-dev-tools). edit-patch — це найпростіший спосіб для виправлення пакунків, що працює з будь-якою системою латання, яку Ви можете собі уявити.

Щоб створити латку за допомогою edit-patch:

$ cd dbus
$ edit-patch 99-fix-a-vulnerability

Це застосує усі існуючі латки й помістить пакунок у тимчасовий каталог. Тепер відредагуйте файли для виправлення вразливостей. Зазвичай в апстрімі лежить і латка, тому Ви одразу можете її застосувати:

$ patch -p1 < /home/user/dbus-vulnerability.diff

Після внесення необхідних змін просто натисніть Ctrl-D або наберіть exit, щоб залишити тимчасову командну оболонку.

Форматування файлу changelog і латок

Після застосування латок Вам знадобиться внести зміни в лог. Команда dch використовується для редагування файлу debian/changelog і edit-patch автоматично запустить dch після відкату усіх латок. Якщо Ви не користуєтеся edit-patch, то можете запустити dch -i вручну. На відміну від звичайних латок, Вам слід використовувати наступний формат (зверніть увагу, що в імені дитрибутиву використовується precise-security, оскільки це оновлення безпеки для Precise) для оновлень безпеки:

dbus (1.4.18-2ubuntu1.5) precise-security; urgency=low

  * SECURITY UPDATE: [DESCRIBE VULNERABILITY HERE]
    - debian/patches/99-fix-a-vulnerability.patch: [DESCRIBE CHANGES HERE]
    - [CVE IDENTIFIER]
    - [LINK TO UPSTREAM BUG OR SECURITY NOTICE]
    - LP: #[BUG NUMBER]
...

Оновіть свою латку для використання відповідних тегів. Ваша латка повинна містити як мінімум теги Origin, Description і Bug-Ubuntu. Наприклад, відредагуйте debian/patches/99-fix-a-vulnerability.patch, щоб він мав приблизно такі рядки:

## Description: [DESCRIBE VULNERABILITY HERE]
## Origin/Author: [COMMIT ID, URL OR EMAIL ADDRESS OF AUTHOR]
## Bug: [UPSTREAM BUG URL]
## Bug-Ubuntu: https://launchpad.net/bugs/[BUG NUMBER]
Index: dbus-1.4.18/dbus/dbus-marshal-validate.c
...

Множинні вразливості можна виправити одним завантаженням безпеки, просто переконайтеся що використовуєте різні латки для різних вразливостей.

Перевірка й відправка Вашої праці

На цьому етапі процес такий самий, як при виправленні звичайних вад в Ubuntu. А саме, Вам потрібно:

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

  2. Виконати оновлення з попередньої версії пакунку до нової версії

  3. Переконатися, що новий пакунок латає вразливість й не вносить ніяких погіршень

  4. Відправляйте свою працю через пропозицію про об’єднання Launchpad й відправляйте баг в Launchpad, переконавшись що позначили баг як помилку безпеки, й для підписки ubuntu-security-sponsors

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

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

Звіт про баг також повинен підтверджувати, що вада виправлена у нових версіях Ubuntu за допомогою запропонованого фіксу (у вищевказаному прикладі вище ніж в Precise). Якщо проблема не виправлена у нових версіях Ubuntu, Ви повинні підготувати оновлення й для нових версій.

Оновлення стабільного релізу

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

Процес оновлень стабільного випуску (Stable Release Updates або SRU) такий самий, як і для виправлень помилок безпеки, за виключенням того, що потрібно підписати на звіт про ваду команду ubuntu-sru.

Оновлення потрапить в архів proposed``(наприклад ``precise-proposed), де його перевіряють на здатність виправити проблему й підтверджують, що воно не є наслідком нових проблем. Після тижню роботи без заявлених проблем, оновлення потрапляє у розділ updates.

Дивіться ‘Вікі сторінку Оновлень Стабільного Релізу <SRUWiki>`_ для отримання додаткової інформації.

Латки для пакунків

Інколи розробникам пакунку Ubuntu потрібно змінити джерельний код апстріму, щоб примусити його працювати в Ubuntu належним чином. Приклади включають латки для апстрімів, які ще не потрапили у версію релізу, або зміни до систем білдів апстріму, необхідні лише для їх збірки на Ubuntu. Ми будемо міняти джерельний код апстріму напряму, але такий метод робить складнішим подальше вилучення латок, коли апстрім вже застосував їх, також ускладнюючи витягнення змін для їх відправки у проєкт апстріму. Замість цього, ми будемо зберігати ці зміни як окремі латки у формі diff файлів.

Існують різні способи роботи з латками для пакунків Debian. На щастя, ми зупинимося на одній системі, Quilt, яка наразі використовується більшістю пакунків.

Давайте візьмемо у якості прикладу пакунок kamoso в Trusty:

$ bzr branch ubuntu:trusty/kamoso

Латки зберігаються в debian/patches. Для цього пакунку є одна латка kubuntu_01_fix_qmax_on_armel.diff для виправлення вади компілювання на платформі ARM. Цій латці привласнено ім’я, що дає опис, того що вона робить, номер патчу за порядком (щоб уникнути плутанини, якщо дві латки мають однакове ім’я) й, у даному випадку, команда Kubuntu додала свій власний префікс, щоб показати, що латка походить від них, а не від Debian.

Порядок застосування латок зберігається в debian/patches/series.

Латки за допомогою Quilt

Перед роботою з Quilt потрібно вказати цій системі, де шукати латки. Додайте в ~/.bashrc таке:

export QUILT_PATCHES=debian/patches

Й джерело файлу для застосування нового експорту:

$ . ~/.bashrc

Типово усі латки застосовуються вже з UDD витягнень або завантажуваних пакунків. Ви можете перевірити це за допомогою:

$ quilt applied
kubuntu_01_fix_qmax_on_armel.diff

Якщо Ви бажаєте вилучити латку, потрібно виконати pop:

$ quilt pop
Removing patch kubuntu_01_fix_qmax_on_armel.diff
Restoring src/kamoso.cpp

No patches applied

А щоб застосувати латку, використовуйте push:

$ quilt push
Applying patch kubuntu_01_fix_qmax_on_armel.diff
patching file src/kamoso.cpp

Now at patch kubuntu_01_fix_qmax_on_armel.diff

Додавання нової латки

Для додавання нової латки потрібно вказати Quilt створити нову латку, повідомити йому, які файли ця латка повинна змінити, відредагувати файли, а потім оновити латку:

$ quilt new kubuntu_02_program_description.diff
Patch kubuntu_02_program_description.diff is now on top
$ quilt add src/main.cpp
File src/main.cpp added to patch kubuntu_02_program_description.diff
$ sed -i "s,Webcam picture retriever,Webcam snapshot program,"
src/main.cpp
$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff

Крок quilt add важливий: якщо Ви забудете його зробити, файли не потраплять у латку.

Тепер зміни будуть в debian/patches/kubuntu_02_program_description.diff, а у файл series буде додана інформація про нову латку. Ви повинні додати новий файл у джерельні файли для пакунку:

$ bzr add debian/patches/kubuntu_02_program_description.diff
$ bzr add .pc/*
$ dch -i "Add patch kubuntu_02_program_description.diff to improve the program description"
$ bzr commit

Quilt містить свої мета-дані у директорії ``.pc/`‘, тому зараз Вам потрібно додати у пакунок і її. Це має бути покращено у майбутньому.

Як правило, слід проявляти обережність при додаванні латок до проґрам, якщо вони походять не з апстріму. Часто є вагома причина, з якої зміни ще не були зроблені. У розглянутому вище прикладі змінюється рядок у користувацькому інтерфейсі, тож це може зламати усі переклади. Якщо маєте сумнів, спитайте автора з апстріму перед тим, як додати латку.

Заголовки латок

Ми рекомендуємо додавати до кожної латки заголовки DEP-3, поміщаючи їх у самому верху файлу латки. Ось деякі заголовки, які можна використовувати:

Description:

Опис того, що робить латка. Має формат, аналогічний полю Description в debian/control: перший рядок містить короткий опис, що починається з рядкової літери, решта рядків містять довший опис з пробілом у якості відступу.

Author:

Хто написав латку (наприклад, “Jane Doe <packager@example.com>”).

Origin:

Звідки прийшла ця латка (наприклад, “upstream”), якщо заголовок Author відсутній.

Bug-Ubuntu:

Посилання на інформацію про помилку на Launchpad, бажано, у короткій формі (типу https://bugs.launchpad.net/bugs/XXXXXXX). Якщо також є звіти про вади в апстрімі або системах відстежування помилок Debian, додайте заголовки Bug або Bug-Debian.

Forwarded:

Чи була латка передана в апстрим. Значення: “yes”, “no” або “not-needed”.

Last-Update:

Дата останньої ревізії (у формі “ГГГГ-ММ-ДД”).

Оновлення до нових версій з апстріму

Щоб виконати оновлення до останньої версії, Ви можете використовувати команду bzr merge-upstream:

$ bzr merge-upstream --version 2.0.2 https://launchpad.net/ubuntu/+archive/primary/+files/kamoso_2.0.2.orig.tar.bz2

При запуску цієї команди відбудеться відткат усіх латок, оскільки вони можуть стати застарілими. Можливо знадобиться їх оновити для відповідності новому джерелу апстріму, або знадобиться вилучити їх усі разом. Для полегшення перевірки проблем застосовуйте латки по одній.

$ quilt push
Applying patch kubuntu_01_fix_qmax_on_armel.diff
patching file src/kamoso.cpp
Hunk #1 FAILED at 398.
1 out of 1 hunk FAILED -- rejects in file src/kamoso.cpp
Patch kubuntu_01_fix_qmax_on_armel.diff can be reverse-applied

Якщо для латки вказано it can be reverse-applied, значить латку вже було застосовано апстрімом, тож ми можемо вилучити цю латку:

$ quilt delete kubuntu_01_fix_qmax_on_armel
Removed patch kubuntu_01_fix_qmax_on_armel.diff

Потім продовжуйте:

$ quilt push
Applied kubuntu_02_program_description.diff

Непоганою думкою буде виконати refresh, це оновить латку відносно змін джерельного коду в апстрімі:

$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff

Потім виконайте фіксацію, як звичайно:

$ bzr commit -m "new upstream version"

Створення пакунку з використанням Quilt

Сучасні пакунки використовують Quilt типово, це вбудовано у формат джерельних файлів пакунку. Перевірте, що в debian/source/format вказано 3.0 (quilt).

Для старіших пакунків, що використовують формат 1.0, необхідно використовувати Quilt явно, зазвичай за допомогою включення make-файлу у debian/rules.

Конфігурування Quilt

Ви можете скористатися файлом ~/.quiltrc для конфігурування quilt. Ось декілька опцій, які можуть бути корисні при використанні quilt з пакунками Debian:

# Set the patches directory
QUILT_PATCHES="debian/patches"
# Remove all useless formatting from the patches
QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
# The same for quilt diff command, and use colored output
QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"

Інші системи керування латками

Інші системи латання, що використовуються у пакунках, включають dpatch і cdbs simple-patchsys, принцип роботи яких схожий на Quilt - латки зберігаються в debian/patches, але для їх застосування, скасування або створення потрібні інші команди. Ви можете дізнатися яка система латання використовується у пакунку за допомогою команди what-patch``(у пакунку ``ubuntu-dev-tools). Ви можете використовувати edit-patch, показаний в попередніх розділах, у якості надійного способу для роботи з усіма системами.

У старіших пакунках зміни будуть включені напряму у джерела і зберігатися у джерельному файлі diff.gz. Це робить складнішим процес оновлення до нових версій апстріму або відмінності між латками - ліпше уникати.

Не змінюйте систему латання, не обміркувавши це з супроводжуючим Debian або командою Ubuntu яка має відношення до справи. Якщо існуючої системи латання немає, можете додати Quilt.

Виправлення пакунків FTBFS (Fails To Build From Source)

Перед тим, як пакунок можна буде використовувати в Ubuntu, він повинен бути зібраний з джерельного коду. Якщо це не вдається, пакунок, ймовірно, буде очікувати в -proposed й не буде доступний у архівах Ubuntu. Повний перелік пакунків, які не вдалося зібрати з джерельного коду, можна знайти на http://qa.ubuntuwire.org/ftbfs/. На цій сторінці показано 5 основних категорій:

  • Package failed to build (F): Щось справді пішло не так у процесі збірки.

  • Скасована збірка (X): збірка була скасована з певної причини. Для початку, з ними ліпше не зв’язуватися.

  • Package is waiting on another package (M): Цей пакунок очікує збірки або оновлення іншого пакунку, або (якщо це пакунок в main) одна з його залежностей знаходиться не у тій частині архіву.

  • Проблема в chroot (C): Певна операція над chroot-оточенням зіштовхнулася з помилкою. Частіше за усе виправляється повторним збиранням. Попрохайте розробника запустити перезбірку.

  • Помилка при завантаженні (U): Пакунок не може бути завантажений на сервер. Зазвичай у цьому випадку потрібно зробити перезбирання, але перед цим – перевірте логи збірки.

Перші кроки

Найперше необхідно повторити FTBFS самостійно. Стягніть код за допомогою bzr branch lp:ubuntu/PACKAGE й отримайте tar-архів, або запустіть dget PACKAGE_DSC над .dsc-файлом зі сторінки проєкту на Launchpad. Після цього, створіть chroot-оточення.

В Вас має вийти відтворити помилку FTBFS. Якщо ж ні – перевірте, чи не стягує збірка відсутню залежність: у такому випадку необхідно у файлі debian/control оголосити її як build-depends. Інший варіянт – спробувати зібрати пакунок локально, що дозволить перевірити відсутні або не вказані залежності (у такому випадку локальна збірка повинна бути успішна, а в schroot – ні)

Перевірка Debian

У випадку, якщо проблему вдалося відтворити – необхідно почати пошук вирішення. Якщо пакунок також знаходиться в Debian, – перевірте, можливо в них пакунок збирається нормально: http://packages.qa.debian.org/PACKAGE. Якщо в Debian є новіша версія пакунку, його потрібно об’єднати (merge). Якщо ж ні – перевірте логи збірки й посилання на відомі проблеми: там може бути додаткова інформація про FTBFS або латки. Debian також підтримує перелік команд різних FTBFS, у якому також є варіянти вирішення різноманітних проблем: https://wiki.debian.org/qa.debian.org/FTBFS.

Інші причини виникнення FTBFS

Якщо пакунок знаходиться в main, але для нього відсутня залежність не з main, то необхідно відправити MIR-баг: сторінка https://wiki.ubuntu.com/MainInclusionProcess дає опис цієї процедури.

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

Якщо вдалося виправити проблему, дотримуйтеся такої ж процедури як й при будь-яких інших проблемах: створіть латку, додайте її у гілку або баг bzr, підпишіть ubuntu-sponsors, а потім спробуйте домогтися її додавання у джерельний пакунок і/або в Debian.

Спільні бібліотеки

Спільні бібліотеки — це скомпільований код, призначений для спільного використання декількома різними проґрамами. Вони розповсюджуються у вигляді файлів .so в /usr/lib/.

Бібліотеки експортують символи у скомпільованому вигляді: функції, кляси та змінні. В кожної бібліотеки також є назва SONAME, що включає номер її версії, але який не обов’язково збігається з офіційним номером релізу. Проґрами компілюються з конкретним SONAME бібліотеки. Так, якщо якийсь з символів бібліотеки був вилучений або змінений – небхідно змінити версію з тим, щоб усі залежні від бібліотеки пакунки були перекомпільовані з використанням нової версії. Зазвичай версії встановлюються у джерелі, й ми використовуємо ті ж номери версій для двійкових пакунків, що називаються “номер ABI”, але у випадку, якщо джерело не використовує притомної версійності, творці пакунків можуть використовувати окрему, традиційнішу нумерацію.

Бібліотеки зазвичай розповсюджуються апстрімом у вигляді окремих випусків. Інколи вони розповсюджуються, як частина проґрами. У останньому випадку вони можуть бути включені у двійковий пакунок разом з проґрамою (це зветься bundling), якщо Ви не припускаєте використання цих бібліотек іншими проґрамами, але частіше їх усе ж слід виділяти у окремі двійкові пакунки.

Самі бібліотеки поміщаються у двійковий пакунок з іменем libfoo1, де foo — ім’я бібліотеки, а 1 — версія з SONAME. Файли розробки з пакунку, такі як заголовкові файли, необхідні для компілювання проґрам з бібліотекою, поміщаються у пакунок з іменем libfoo-dev.

Приклад

У якості прикладу ми використовуємо libnova:

$ bzr branch ubuntu:trusty/libnova
$ sudo apt-get install libnova-dev

Щоб знайти SONAME бібліотеки, виконайте:

$ readelf -a /usr/lib/libnova-0.12.so.2 | grep SONAME

SONAME у даному випадку libnova-0.12.so.2, що відповідає імені файлу (як правило, але не завжди). Тут апстрім помістив номер версії з апстріму, як частину SONAME, й задав ABI-версію 2. Імена бібліотекових пакунків повинні слідувати SONAME бібліотеки, яку вони містять. Двійковий бібліотековий пакунок зветься libnova-0.12-2, де libnova-0.12 — ім’я бібліотеки, а 2 — наш ABI-номер.

Якщо автори з апстріму внесли несумісні зміни у свою бібліотеку, вони повинні змінити номер версії SONAME, а ми повинні перейменувати нашу бібліотеку. Будь-які інші пакунки, що використовують наш бібліотековий пакунок, потрібно буде перекомпілювати з новою версією, це зветься переходом (transition) й потребує певних зусиль. Потрібно сподіватися, наш ABI-номер продовжить відповідати SONAME апстріму, але інколи вони вносять несумісності без зміни їх номеру версії, а нам потрібно змінити наш.

Поглянувши на debian/libnova-0.12-2.instal, ми побачимо, що він включає у себе два файли:

usr/lib/libnova-0.12.so.2
usr/lib/libnova-0.12.so.2.0.0

Другий рядок — справжня бібліотека, з повним номером версії. Перше — символьне посилання, що вказує на справжню бібліотеку. Проґрами, що використовують бібліотеку, как правило, будуть користуватися символічним посиланням.

libnova-dev.install містить усі файли, необхідні для компілювання проґрами з даною бібліотекою. Заголовкові файли, бінарник конфігурації, файл libtool’a .la, а також libnova.so – ще один симлінк на бібліотеку, створюваний з тим, щоб проґрами могли компілюватися поза залежністю від старшого номеру версії (при цьому, скомпільваний застосунок все одно буде залежати від версії).

.la-файли libtool’у потрібні на деяких не-Linux системах з обмеженою підтримкою бібліотек, але на системах Debian часто створюють більше проблем, ніж вирішують. Мета Debian відмовитися від .la-файлів сьогодні вельми актуальна, й Ви можете допомогти з вирішенням цього завдання.

Статичні бібліотеки

Пакунок -dev також містить usr/lib/libnova.a. Це статична бібліотека, альтернатива спільній бібліотеці. Будь-яка проґрама, скомпільована зі статичною бібліотекою, містить її код безпосередньо у собі. Це дозволяє не бентежитися про двійкову сумісність бібліотеки. Втім це також значить, що будь-які помилки, у тому числі вразливості у безпеці, не будуть виправлені за рахунок оновлення бібліотеки, поки проґрама не буде перекомпільована. З цієї причини використовувати проґрами з статичними бібліотеками не радимо.

Символьні файли

Коли додаток компілюється з бібліотекою, механізм shlibs додасть до пакунку залежність від цієї бібліотеки. Саме тому більшість проґрам містять Depends: ${shlibs:Depends} у файлі debian/control. Це замінюється переліком залежних бібліотек при білді. Втім shlibs може лише вказувати залежність від старшої ABI-версії , 2 у нашому прикладі з libnova, тож якщо нові символи будуть додані у майбутній libnova 2.1 – застосунок буде запускатися й зі старішою версією libnova ABI 2.0, що призведе до аварійного завершення.

Щоб точніше вказувати залежності від бібліотек, ми створили файл .symbols, який перераховує усі символи бібліотеки й версії, у яких вони з’явилися.

libnova не має символьного файлу, тож ми можемо створити його. Почніть з компілювання пакунку:

$ bzr builddeb -- -nc

Опція -nc вказує не вилучати збірочні файли після завершення компілювання. Перейдіть у каталог збірки й виконайте dpkg-gensymbols для пакунку бібліотеки:

$ cd ../build-area/libnova-0.12.2/
$ dpkg-gensymbols -plibnova-0.12-2 > symbols.diff

Це створить diff-файл, який Ви зможете застосувати самостійно:

$ patch -p0 < symbols.diff

Це створить файл з іменем вигляду dpkg-gensymbolsnY_WWI, у якому будуть перераховані усі символи. Він також вказує поточну версію пакунку. Версію пакунку можна прибрати з файлу, оскільки нові символи зазвичай додаються не з новою версією пакунку, а розробниками початкової бібліотеки.

$ sed -i s,-0ubuntu2,, dpkg-gensymbolsnY_WWI

Тепер перемістіть файл туди, де він має знаходитися, зафіксуйте зміни та виконайте тестову збірку:

$ mv dpkg-gensymbolsnY_WWI ../../libnova/debian/libnova-0.12-2.symbols
$ cd ../../libnova
$ bzr add debian/libnova-0.12-2.symbols
$ bzr commit -m "add symbols file"
$ bzr builddeb

Якщо компілювання виконується успішно, значить символьний файл не містить вад. З виходом наступної апстрім-версії libnova Вам доведеться знову запустити dpkg-gensymbols, щоб створити diff для оновлення символьного файлу.

Символьні файли бібліотек C++

В мови C++ більш суворі стандарти на двійкову сумісність, ніж у C. Команда Debian Qt/KDE підтримує деякі скрипти, які допоможуть подолати це: сторінка Робота з файлами symbols дає опис принципів їх використання.

Матеріяли для подальшого читання

Стаття Junichi Uekawa Пакункування бібліотек для Debian розглядає це питання детальніше.

Бекпортування оновлень проґрам

Буває може знадобитися додати функційності у стабільный реліз, який не пов’язаний з виправленням критичних проблем. У подібних випадках, є два варіянти: або Ви завантажите його в PPA, або підготуєте бекпорт (backport).

Персональні архіви пакунків (PPA)

Використання PPA має ряд переваг. Це достатньо просто, Вам не знадобиться схвалення від кого б то не було, але недолік у тому, що користувачам доведеться вручну під’єднувати PPA. Це нестандартне джерело застосунків.

Документація до PPA на Launchpad має достатньо всеосяжний характер й допоможе Вам швидко почати роботу з ним.

Офіційні бекпорти Ubuntu

Метою проєкту Backports є надання користувачам нової функційності. З-за ризиків зменшення стабільності при портуванні новинок, бекпорти недоступні користувачам, поки вони не задіють їх. Тому бекпорти не є місцем для виправлення помилок. Якщо у пакунку Ubuntu виявлена помилка, вона повинна бути виправлена через оновлення безпеки та стабільності.

Коли Ви визначите, чи потрібно Вам адаптувати Ваші зміни для стабільного релізу, Вам буде необхідно зібрати та протестувати Ваш пакунок на даному релізі. Команда pbuilder-dist (з пакунку ubuntu-dev-tools) допоможе Вам зробити це.

Щоб подати заявку на бекпорт, можна використовувати засіб requestbackport (також з пакунку ubuntu-dev-tools). Він визначить усі проміжні випуски, для яких пакунок також доведеться бекпортувати, покаже, які пакунки залежать від даного, й створить заявку. Він також включить перелік потрібних тестів у заявку.

База знань

Комунікація при Розробці в Ubuntu

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

Поштові розсилки

Поштові розсилки— це достатньо ефективний інструмент, якщо Ви бажаєте обміркувати ідеї в команді та переконатися що Ви сповістили усіх, не дивлячись на відмінності у часових поясах.

З точки зору розробки, це найважиливіші з розсилок:

Канали IRC

Для дискусії у мережі під’єднайтеся до irc.freenode.net і приєднайтеся до будь-якого з каналів:

  • #ubuntu-devel (для головної дискусії розробників)

  • #ubuntu-motu (для обговорень команди MOTU та отримання допомоги)

Загальний огляд каталогу debian/

Ця стаття дає короткі пояснення до різних файлів, важливих для створення пакунків Ubuntu, які містяться у каталозі debian/. Найважливішими з них є changelog, control, copyright, і rules. Вони потрібні для усіх пакунків. Багато додаткових файлів у debian/ можуть використовуватися для налаштування та зміни поведінки пакунку. Деякі з цих файлів обговорюються у цій статті, але це далеко не повний перелік.

Файл changelog

Цей файл, як видко з його назви — це перелік змін, внесених у кожну версію. Він має особливий формат, який показує ім’я пакунку, версію, дистрибутив, зміни, й хто вносив зміни в даний час. Якщо в Вас є ключ GPG (дивіться: Підготовка), переконайтеся, що Ви використовуєте в changelog ті ж ім’я та адресу електронної пошти, що й в Вашому ключі. Нижче наведено шаблон changelog:

package (version) distribution; urgency=urgency

 * change details
  - more change details
 * even more change details

-- maintainer name <email address>[two spaces]  date

Формат (особливо дати) важливий. Дата повинна бути у форматі RFC 5322, який можна побачити при виконанні команди date -R. Для зручності, можна використовувати для редагування changelog команду dch. Вона оновить дату автоматично.

Пункти з незначними змінами позначаються тире «-», у той час як у важливих пунктах використовується зірочка «*».

Якщо Ви створюєте пакунок «з нуля», dch --create (dch знаходиться у пакунку devscripts) створить для Вас стандартний файл debian/changelog.

Ось приклад файлу changelog для hello:

hello (2.8-0ubuntu1) trusty; urgency=low

  * New upstream release with lots of bug fixes and feature improvements.

-- Jane Doe <packager@example.com>  Thu, 21 Oct 2013 11:12:00 -0400

Зверніть увагу, що версія має -0ubuntu1 доданий до нього, це - distro версія, яка використовується так, щоб упаковка могла бути оновлена (щоб виправити помилки, наприклад) з новими завантаженнями у тій же джерельній версії випуску.

Ubuntu і Debian використовують схеми нумерації версій пакунків, що трохи різняться, щоб уникнути конфлікту пакунків з однією й тою самою початковою версією. Якщо пакунок Debian був змінений в Ubuntu, до кінця Debian-версії додається ubuntuX (де X — номер редакції в Ubuntu). Таким чином, якщо пакунок Debian hello 2.6-1 був змінений в Ubuntu, номер версії буде 2.6-1ubuntu1. Якщо пакунок додатку в Debian не існує, то редакція Debian дорівнює 0 (наприклад, 2.6-0ubuntu1).

Детальнішу інформацію можна знайти на сторінці changelog (Розділ 4.4) документу Debian Policy Manual.

Файл control

Файл control містить інформацію, яку використовує менеджер пакунків (такий, як apt-get, synaptic або adept), збірочні залежності, інформацію мейнтейнера і багато іншого.

Для пакунку Ubuntu hello файл control виглядає таким чином:

Source: hello
Section: devel
Priority: optional
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XSBC-Original-Maintainer: Jane Doe <packager@example.com>
Standards-Version: 3.9.5
Build-Depends: debhelper (>= 7)
Vcs-Bzr: lp:ubuntu/hello
Homepage: http://www.gnu.org/software/hello/

Package: hello
Architecture: any
Depends: ${shlibs:Depends}
Description: The classic greeting, and a good example
 The GNU hello program produces a familiar, friendly greeting. It
 allows non-programmers to use a classic computer science tool which
 would otherwise be unavailable to them. Seriously, though: this is
 an example of how to do a Debian package. It is the Debian version of
 the GNU Project's `hello world' program (which is itself an example
 for the GNU Project).

Перший абзац дає опис джерельного пакунку, включаючи перелік пакунків, що потрібні для збірки даного пакунку з джерельного коду, у полі Build-Depends. Він також містить деяку метаінформацію, таку як ім’я мейнтейнера, версію Debian Policy, з якою компілюється пакунок, місцерозташування репозиторію керування версіями та домашню сторінку апстріму.

Зауважте, що в 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 в Ubuntu wiki.

Кожен додатковий абзац дає опис бінарного пакунку, який буде створений.

Детальнішу інформацію можна знайти на сторінці секції control-файлу (Розділ 5) документу Debian Policy Manual.

Файл rules

Останній файл, який ми розглянемо, це rules. Він виконує усю роботу по збірці нашого пакунку. Це Makefile, у якому є функції компілювання проґрами, її встановлення та створення .deb-пакунку з встановлених файлів. У ньому є також функція очистки файлів збірки, яка вилучає усе, крім власне пакунку джерельного коду.

Ось спрощений приклад файлу rules, створеного dh_make (який можна знайти у пакунку dh-make):

#!/usr/bin/make -f
# -*- makefile -*-

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

%:
       dh  $@

Давайте розглянемо цей файл уважніше. На кожному етапі збірки debian/rules викликається з аргументом, який передається /usr/bin/dh, який, у свою чергу, викликає необхідні команди dh_*.

dh запускає послідовність команд debhelper. Підтримувані послідовності відповідають призначенням файлу debian/rules: «build», «clean», «install», «binary-arch», «binary-indep» і «binary». Щоб побачити, які команди виконуються у кожному призначенні, наберіть:

$ dh binary-arch --no-act

Командам з послідовності binary-indep передається аргумент -i, щоб вони зачепали лише архітектурно-незалежні пакунки, а командам з послідовності binary-arch — аргумент -a, щоб вони зачепали лише архітектурно-залежні пакунки.

Кожна команда debhelper при її успішному виконанні робить запис у журналі debian/package.debhelper.log (який потім вилучає dh_clean.) Таким чином dh може визначити, які команди вже були виконані й для яких пакунків, що допомогає уникнути повторного виконання цих команд.

При кожному запуску dh він вивчає журнал, знаходить додані останніми команди, які відносяться до вказаної послідовності. Потім він продовжує виконання з наступної команди у цій послідовності. Опції --until, --before, --after і --remaining можуть змінити цю поведінку.

Якщо в debian/rules є функція з іменем, схожим на override_dh_команда, то замість даної команди dh виконає дану функцію. Ця функція може запустити ту ж команду з іншими аргументами, або ж геть іншу команду. (Зауваження: для використання цієї функційності при збірці потрібен пакунок debhelper версії не менше 7.0.50).

За додатковими прикладами зверніться до /usr/share/doc/debhelper/examples/ і man dh. Дивіться також розділ про файл rules (Розділ 4.9) в «Debian Policy Manual».

Додаткові файли

Файл install

Файл install використовується dh_install для встановлення файлів у двійковий пакунок. Він має два стандартних варіянти використання:

  • Для встановлення у Ваш пакунок файлів, не встановлених оригінальною системою збірки.

  • Розділення одного великого пакунку джерела на декілька бінарних пакунків.

У першому випадку файл install повинен містити один рядок для кожного встановлюваного файлу, що вказує як файл, так і встановлювальний каталог. Наприклад, наступний файл install встановить сценарій foo з кореневого каталогу пакунку джерельного коду в usr/bin і desktop-файл з каталогу debian в usr/share/applications:

foo usr/bin
debian/bar.desktop usr/share/applications

Якщо пакунок джерельного коду продукує декілька двійкових пакунків, dh встановить файли в debian/tmp замість встановлення безпосередньо в debian/<пакунок>. Файли, встановлені в debian/tmp потім можна перемістити у окремі двійкові пакунки за допомогою декількох файлів $ім’я_пакунку.install. Це часто робиться, щоб розбити велику кількість незалежних від архітектури даних з залежних від архітектури пакунків у пакунки Architecture: all. У цьому випадку потрібно вказати лише імена встановлюваних файлів (або каталогів), без встановлювального каталогу. Наприклад, foo.install, що містить лише залежні від архітектури файли, може виглядати наподобі:

usr/bin/
usr/lib/foo/*.so

У той час як foo-common.install, що містить лише не залежні від архітектури файли, може виглядати так:

/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/

Будуть створені два двійкові пакунки: foo і foo-common. Для обох потрібен їх власний абзац в debian/control.

Для додаткових подробиць дивіться man dh_install і розділ про файл install (Розділ 5.11) в «Debian New Maintainers’ Guide».

Файл watch

Файл debian/watch дозволяє автоматично перевіряти наявність нових версій в апстрімі за допомогою інструменту uscan з пакунку devscripts. Першим рядком файлу watch повинна бути версія формату (3 на мить написання цього посібника), а наступні рядки містять будь-які URL для аналізу. Наприклад:

version=3

http://ftp.gnu.org/gnu/hello/hello-(.*).tar.gz

Запуск uscan у кореневому каталозі джерельних кодів порівняє номер апстрім-версії у debian/changelog з останньою доступною в апстрімі версією. Якщо в апстрімі знайдена нова версія, вона буде автоматично завантажена. Наприклад:

$ uscan
hello: Newer version (2.7) available on remote site:
  http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz
  (local version is 2.6)
hello: Successfully downloaded updated package hello-2.7.tar.gz
    and symlinked hello_2.7.orig.tar.gz to it

Якщо Ваші tarball-файли перебувають на Launchpad, файл debian/watch має трохи складніший вигляд (про те, чому це так, дивіться Question 21146 і Bug 231797). У цьому випадку використовуйте щось типу:

version=3
https://launchpad.net/flufl.enum/+download http://launchpad.net/flufl.enum/.*/flufl.enum-(.+).tar.gz

Додаткові відомості дивіться в man uscan і у розділі про файл watch (Розділ 4.11) «Debian Policy Manual».

Перелік пакунків, для яких файл watch повідомляє про те, що вони не синхронізовані з апстрімом, дивіться Ubuntu External Health Status.

Файл source/format

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

  • 3.0 (native) для «рідних» пакунків Debian (апстрім-версія відсутня)

  • 3.0 (quilt) для пакунків з окремим тарболом з апстріму

  • 1.0 для пакунків, бажаючих явно вказати типовий формат

На цей час обирається типовий формат пакунку джерельного коду 1.0, якщо цей файл відсутній. У файлі source/format можна вказати його явно. Якщо Ви не використовуєте цей файл для вказування формату джерельного коду, Lintian видасть попередження про відсутність файлу. Це чисто інформаційне попередження і його можна без побоювань знехтувати.

Рекомендується використовувати більш новий формат 3.0. Він надає деякі нові можливості:

  • Підтримка додаткових форматів стиснення: bzip2, lzma і xz

  • Підтримка декількох архівів з оригінальним джерельним кодом

  • Необов’язково перепаковувати архів з оригінальним джерельним кодом, щоб вилучити директорію debian.

  • Специфічні для Debian зміни тепер зберігаються не в одному файлі .diff.gz, а у вигляді декількох латок, сумісних з quilt, у каталозі debian/patches/

https://wiki.debian.org/Projects/DebSrc3.0 містить додаткову інформацію стосовно переходу на версію 3.0 формату джерельних пакунків.

Додаткову інформацію можна знайти в man dpkg-source і у Розділі source/format (Розділ 5.21) посібника Debian New Maintainers.

Додаткові ресурси

Крім Debian Policy Manual, на який посилається стаття, посібник Debian New Maintainers’ Guide містить більш детальний опис для кожного файлу. Розділ 4, “Необхідні файли у теці debian” дає опис файлів control, changelog, copyright і rules. Розділ 5, “Інші файли у теці debian” дає опис додаткових файлів, які можна використовувати.

autopkgtest: Автоматичне тестування пакунків

Специфікація DEP 8 визначає, як можна легко інтегрувати автоматичне тестування у Ваші пакунки. Для цього, необхідно:

  • додати файл debian/tests/control, який визначає вимоги до тестового оточення,

  • додати тести в debian/tests.

Вимоги до тестового оточення

У файлі debian/tests/control Ви можете визначити вимоги до тестового оточення. Наприклад, якщо тести не проходять при збірці, або потрібні права root – Ви перераховуєте необхідні для тестів пакунки. У Специфікації DEP 8 Ви знайдете усі доступні опції.

Нижче ми розглянемо пакунок джерельного коду glib2.0. У дуже простому випадку він буде виглядати так:

Tests: build
Depends: libglib2.0-dev, build-essential

Це буде означати, що для тесту debian/tests/build потрібні пакунки libglib2.0-dev і build-essential.

Примітка

У полі Depends можна вказати @, якщо Ви бажаєте встановлення усіх бінарних пакунків, зібраних з розглядуваного пакунку джерельного коду.

Поточні тести

Тест, що відповідає розглянутому вище прикладу, буде виглядати так:

#!/bin/sh
# autopkgtest check: Build and run a program against glib, to verify that the
# headers and pkg-config file are installed correctly
# (C) 2012 Canonical Ltd.
# Author: Martin Pitt <martin.pitt@ubuntu.com>

set -e

WORKDIR=$(mktemp -d)
trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
cd $WORKDIR
cat <<EOF > glibtest.c
#include <glib.h>

int main()
{
    g_assert_cmpint (g_strcmp0 (NULL, "hello"), ==, -1);
    g_assert_cmpstr (g_find_program_in_path ("bash"), ==, "/bin/bash");
    return 0;
}
EOF

gcc -o glibtest glibtest.c `pkg-config --cflags --libs glib-2.0`
echo "build: OK"
[ -x glibtest ]
./glibtest
echo "run: OK"

Тут невелика проґрама мовою C копіюється у тимчасову теку, потім компілюється з використанням системних бібліотек (з використанням прапорців та шляхів до бібліотек, визначених через pkg-config). Потім запускається скомпільований файл, який запускає декілька основних функцій glib.

Хоч цей тест дуже маленький і простий, він перевіряє багато: що Ваш -dev пакунок має усі необхідні залежності, що Ваш пакунок встановлює робочі файли pkg-config, заголовкові файли і бібліотеки поміщуються у потрібне місце, або що компілювальник та компонувальник працюють. Це допомогає виявити критичні помилки на початковій стадії.

Виконання тесту

While the test script can be easily executed on its own, it is strongly recommended to actually use autopkgtest from the autopkgtest package for verifying that your test works; otherwise, if it fails in the Ubuntu Continuous Integration (CI) system, it will not land in Ubuntu. This also avoids cluttering your workstation with test packages or test configuration if the test does something more intrusive than the simple example above.

The README.running-tests (online version) documentation explains all available testbeds (schroot, LXD, QEMU, etc.) and the most common scenarios how to run your tests with autopkgtest, e. g. with locally built binaries, locally modified tests, etc.

Система безперервної інтеграції Ubuntu CI використовує емулятор QEMU й запускає тести з пакунків у архіві, з увімкненим прапорцем -proposed. Щоб вручну отримати те ж оточення, спочатку необхідно встановити наступні пакунки:

sudo apt-get install autopkgtest qemu-system qemu-utils

Тепер виконайте збірку тестового оточення, виконавши таке:

autopkgtest-buildvm-ubuntu-cloud -v

(Детальніше про вибір інших релізів, архітектур, цільових директорій, й про використання проксі – в manpage й у виводі опції --help). Ця команда виконає збірку, наприклад adt-trusty-amd64-cloud.img.

Тепер запустіть тести джерельного пакунку, наприклад libpng, у образі QEMU:

autopkgtest libpng --- qemu adt-trusty-amd64-cloud.img

The Ubuntu CI system runs packages with only selected packages from -proposed available (the package which caused the test to be run); to enable that, run:

autopkgtest libpng -U --apt-pocket=proposed=src:foo --- qemu adt-release-amd64-cloud.img

or to run with all packages from -proposed:

autopkgtest libpng -U --apt-pocket=proposed --- qemu adt-release-amd64-cloud.img

The autopkgtest manpage has a lot more valuable information on other testing options.

Подальші приклади

Цей перелік не повний, але може допомогти Вам отримати уяву про те, як автоматичні тести реалізовані, й як вони використовуються в Ubuntu.

  • Для бібліотеки libxml2 , тести дуже схожі. Вони також запускають тестову збірку простого коду на C й виконують його.

  • Пакунок gtk+3.0 tests <gtk3_> також компілює/лінкує/запускає перевірку у тесті “build”. Також є додатковий тест “python3-gi”, який перевіряє що бібліотека GTK може бути використана під час тесту.

  • У пакунку ubiquity tests використовується набір тестів батьківського пакунку

  • Пакунок gvfs tests – дуже цікавий приклад: він тестує свій функціонал “на повну”, включаючи емулювання CD, Samba, DAV та інших компонентів.

Інфраструктура Ubuntu

Пакунки з увімкненим autopkgtest будуть тестуватися при вивантаженні, або якщо оновляться якісь залежності. Результат роботи автоматичний запуск тестів autopkgtest може бути переглянутий на сайті, й він регулярно оновлюється.

Debian also uses autopkgtest to run package tests, although currently only in schroots, so results may vary a bit. Results and logs can be seen on http://ci.debian.net. So please submit any test fixes or new tests to Debian as well.

Додавання тесту в Ubuntu

Процес додавання й відправлення autopkgtest-тесту для пакунків дуже схожий на процес виправлення помилок в Ubuntu. Вистачить лише:

  • виконайте bzr branch ubuntu:<ім’я_пакунку>,

  • увімкніть тести в debian/control,

  • створіть директорію debian/tests,

  • створіть debian/tests/control, основуючись на Специфікації DEP 8,

  • додайте Ваші тести в debian/tests,

  • закомте Ваші зміни, відправте їх на Launchpad, запропонуйте merge й дочекайтеся його розгляду, – у точності як з будь-якими іншими покращеннями у джерельних пакунках.

Чи Ви можете допомогти

Команда Ubuntu Engineering зібрала перелік необхідних тестів, у якому пакунки, що потребують тестування, розподілені за категоріями. Там можна знайти приклади таких тестів й взяти їх на себе.

Якщо Ви зіштовхнетеся з проблемами, приєднуйтеся до IRC на каналу #ubuntu-quality IRC channel: розробники звичайно Вам допоможуть.

Отримання джерельного коду

URL пакунків джерельного коду

Bazaar надає декілька дуже зручних скорочень для доступу до гілок джерельного коду з Launchpad для пакунків як Ubuntu, так і Debian.

Щоб послатися на гілки джерельного коду, використовуйте:

ubuntu:package

де package — ім’я пакунку, який Вам потрібен. Ця URL посилається на пакунки у поточній розроблюваній версії Ubuntu. Щоб послатися на гілку Tomboy у розроблюваній версії, потрібно використовувати:

ubuntu:tomboy

Щоб зробити відсилку до версії джерельного пакунку у старішому релізі Ubuntu просто додайте пакунку префікс з кодовим іменем релізу. Наприклад, для відсилки до джерельного пакунку Tomboy в Saucy використовуйте:

ubuntu:saucy/tomboy

Оскільки перші літери кодових імен не повторюються, можна скоротити ім’я випуску:

ubuntu:s/tomboy

Схожу схему можна використовувати для доступу до гілок джерельного коду в Debian, хоч тут немає скорочень для імен випусків Debian. Щоб отримати доступ до гілки Tomboy у поточному розроблюваному випуску Debian, використовуйте:

debianlp:tomboy

також для доступу до Tomboy в Debian Wheezy використовуйте:

debianlp:wheezy/tomboy

Отримання джерельного коду

Кожен пакунок джерельного коду в Ubuntu пов’язаний з гілкою джерельного коду на Launchpad. Launchpad автоматично оновлює ці гілки джерельного коду, хоч процес не повністю «захищений від дурня».

Є декілька речей, які ми зробимо у першу чергу, щоб зробити робочий процес ефективнішим напотім. Після того, як Ви засвоїте процес, Ви взнаєте, коли є сенс пропускати ці етапи.

Створення загальнодоступного сховища

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

Скористайтеся для цього командою bzr init-repo, передавши їй ім’я каталогу, який Ви бажаєте використовувати:

$ bzr init-repo tomboy

Ви побачите, що у Вашій поточній робочій області створено каталог tomboy. Перейдіть у нього для продовження роботи:

$ cd tomboy
Отримання гілки trunk

Ми використовуємо команду bzr branch для створення локальної гілки пакунку. Каталог призначення назвемо tomboy.dev, просто тому, що так легше запам’ятати:

$ bzr branch ubuntu:tomboy tomboy.dev

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

Перевірка актуальності версії

Коли Ви робите свою bzr branch, то отримаєте повідомлення про те чи є гілка пакунків актуальною. Наприклад:

$ bzr branch ubuntu:tomboy
Most recent Ubuntu version: 1.8.0-1ubuntu1.2
Packaging branch status: CURRENT
Branched 86 revisions.

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

Packaging branch status: OUT-OF-DATE

означає, що імпорт не вдався. Ви можете дізнатися про причину за посиланням: http://package-import.ubuntu.com/status/ й відправити баг в UDD для вирішення проблеми.

Tar-файл з апстріму

Отримати tar з апстріму можна за допомогою:

bzr get-orig-source

Таким чином пробуються декілька методів для потрапляння в tar апстріму, спочатку відтворюючи його з тегу upstream-x.y у архіві bzr, потім стягуючи з архіву Ubuntu, а потім запускаючи debian/rules get-orig-source. Tar апстріму також буде відтворений при використанні bzr для побудови пакунку:

bzr builddeb

У втулки builddeb є декілька опцій конфігурації.

Отримання гілки для певного випуску

Якщо Ви бажаєте зробити щось типу оновлення стабільного релізу (SRU), або просто бажаєте вивчити код у старому релізі, Вам потрібно вибрати гілку, що відповідає певному релізу Ubuntu. Наприклад, щоб отримати пакунок Tomboy для Quantal:

$ bzr branch ubuntu:m/tomboy quantal
Імпорт пакунку джерельного коду Debian

Якщо пакунок, над яким Ви бажаєте працювати, доступний в Debian, але не в Ubuntu - код легко імпортувати у локальну гілку bzr для розробки. Наприклад, Ви бажаєте імпортувати джерельний пакунок newpackage. Ми почнемо із створення загальнодоступного сховища у якості звичайного, але нам також потрібно створити робоче дерево, у яке буде імпортовано джерельний пакунок (не забудьте виконати cd out директорії tomboy, створеній вище):

$ bzr init-repo newpackage
$ cd newpackage
$ bzr init debian
$ cd debian
$ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc

Як Ви бачите - потрібно просто вказати віддалене розташування файлу dsc, а Bazaar зробить решту. Тепер в Вас є джерельна гілка Bazaar.

Робота з пакунком

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

Гілкування для змін

Найперш переконайтеся, що гілка джерельного пакунку актуальна. Якщо Ви її тільки-но перевірили, то вона буде актуальною, якщо ж ні, то зробіть таке:

$ cd tomboy.dev
$ bzr pull

Будуть показані будь-які оновлення стосовно пакунку, які були завантажені з миті налагодження. Ви не бажаєте вносити зміни у цю гілку. Замість цього створіть гілку, яка буде містити лише ті зміни, які Ви збираєтеся внести. Припустімо, Ви бажаєте виправити баг 12345 для проєкту Tomboy. Коли Ви знаходитеся у загальнодоступному сховищі, раніше створеному для Tomboy, Ви можете створити гілку для виправлення вад таким чином:

$ bzr branch tomboy.dev bug-12345
$ cd bug-12345

Тепер Ви можете виконувати усю роботу в директорії bug-12345. Робіть там усі необхідні зміни, не забуваючи заразом відправляти свою роботу. Цей процес схожий з розробкою будь-яких застосунків за допомогою Bazaar. Можна робити проміжні відправки так часто, як забажаєте, а коли Ви закінчили роботу над змінами, використовуйте стандартну команду dch (з пакунку devscripts):

$ dch -i

Ця команда відкриє редактор та додасть запис у файл debian/changelog.

tomboy (1.12.0-1ubuntu3) trusty; urgency=low

  * Don't fubar the frobnicator. (LP: #12345)

 -- Bob Dobbs <subgenius@example.com>  Mon, 10 Sep 2013 16:10:01 -0500

Підтвердити з нормальним:

bzr commit

Хук в bzr-builddeb буде використовувати текст debian/changelog як повідомлення про завершення відправки й встановить тег для позначення багу #12345 у якості фіксованого.

Це працює лише з bzr-builddeb 2.7.5 і bzr 2.4, для старіших версій використовуйте debcommit.

Збірка пакунку

Напевно Ви забажаєте створити свою гілку, щоб Ви могли перевірити її і переконатися, що вона справді виправляє баг.

Щоб створити пакунок, Ви можете використовувати команду bzr builddeb з пакунку bzr-builddeb. Ви можете створити джерельний пакунок за допомогою:

$ bzr builddeb -S

(bd — це псевдонім для builddeb.) Ви можете залишити пакунок непідписаним, додавши до команди -- -uc -us.

Ви можете також використовувати свої звичайні інструменти, якщо вони здатні прибирати каталоги .bzr з пакунку, наприклад:

$ debuild -i -I

Якщо Ви колись зіштовхнетеся з помилкою, пов’язаною зі спробою скласти рідний пакунок без tar-архіву, переконайтеся що там є файл .bzr-builddeb/default.conf, що помилково видає пакунок за рідний. Якщо у версії логу змін є дефіс, то це не рідний пакунок, тому файл конфігурації слід прибрати. Зверніть увагу, якщо в bzr builddeb є оператор --native, то в нього немає оператора --no-native.

Після того, як Ви отримали пакунок джерельного коду, можна зібрати його як звичайно, за допомогою pbuilder-dist (або pbuilder, або sbuild).

Пошук Оглядів та Поручительства

Однією з великих переваг використання робочого процесу UDD - покращення якості шляхом відкликів про зміни від Ваших друзів і коллег. Це працює поза залежністю від того чи є в Вас права на завантаження. Звичайно, якщо в Вас немає прав на завантаження, то Вам потрібно знайти поручителя.

Як тільки Ви задоволені своїм фіксом й Ваша гілка готова до роботи, потрібно зробити наступні кроки для оголошення своєї гілки на Launchpad, прив’язки її до багу, а потім створити пропозицію про злиття (merge proposal) для розгляду іншими користувачами й можливістю завантаження його поручителями.

Вивантаження на Launchpad

Раніше ми показали Вам, як пов’язати Вашу гілку з помилкою, використовуючи команди dch і bzr commit. Втім гілка й помилка насправді не будуть пов’язані, поки Ви не вивантажите гілку на Launchpad командою push.

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

Загальний формат URL, на яку Ви повинні вивантажити свою гілку, має такий вигляд:

lp:~<user-id>/ubuntu/<distroseries>/<package>/<branch-name>

Наприклад, щоб просунути свій фікс для багу 12345 у пакунку Tomboy для Trusty, використовуйте:

$ bzr push lp:~subgenius/ubuntu/trusty/tomboy/bug-12345

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

Але зазвичай цього недостатньо, аби розробники Ubuntu перевірили Вашу зміну й взяли на себе поручительство над ним. Вам потрібно відправити пропозицію злиття (merge proposal).

Для цього відкрийте сторінку помилки у оглядачі тенет, наприклад:

$ bzr lp-open

Якщо зробити це не вдалося, Ви можете використовувати:

$ xdg-open https://code.launchpad.net/~subgenius/ubuntu/trusty/tomboy/bug-12345

де більша частина URL збігається з тією URL, яку Ви вказували у команді bzr push. На цій сторінці Ви побачите посилання Propose for merging into another branch. Наберіть опис Вашої зміни у полі Initial Comment. Потім клацніть Propose Merge, щоб завершити процес.

Пропозиції про злиття для джерельних гілок автоматично підпишуть команду ~ubuntu-branches, чого має бути достатньо для того, щоб привернути увагу розробника Ubuntu, який зможе дати відклик Вашим змінам й стати поручителем.

Створення debdiff

Як було вказано вище, деякі поручителі віддають перевагу перевірці debdiff, прикріпленому до звіту про ваду, замість пропозиції злиття. Якщо вас попрохали включити debdiff, Ви можете створити його наступним чином (з Вашої гілки bug-12345):

$ bzr diff -rbranch:../tomboy.dev

Інший спосіб — відкрити пропозицію злиття й завантажити diff.

Ви повинні переконатися, що diff-файл містить очікувані Вами зміни, не більше й не менше. Дайте йому відповідне ім’я, наприклад, foobar-12345.debdiff і прикріпіть до звіту про ваду.

Робота зі зворотнім зв’язком від поручителів

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

$ bzr commit

Тепер коли Ви просунули свою гілку в Launchpad, Bazaar оновить гілку на Launchpad Вашими останніми змінами. Усе, що Вам потрібно зробити:

$ bzr push

Ви можете відповісти на email з оглядом пропозиції про злиття поясненням того, які зміни Ви внесли, а також можете попрохати провести повторний огляд; або ж Ви можете відправити свою відповідь через Launchpad.

Зверніть увагу - Вас спонсорують через debdiff, прикріплений до звіту про ваду - Вам слід оновлювати його вручну, генеруючи новий diff й прикріплюючи його до звіту про ваду.

Очікування

Розробники Ubuntu склали розклад людей (так званих “patch pilots”), які регулярно перевіряють чергу поручительства й надають зворотній зв’язок з питань роботи з гілками та латками. Але, навіть не дивлячись на це, може пройти декілька днів, поки Ви отримаєте відповідь. Це залежить від їх зайнятості, від стану заморозки поточної версії та інших факторів.

Якщо Ви не отримуєте відповіді протягом тривалого часу, під’єднайтеся до каналу #ubuntu-devel на irc.freenode.net й знайдіть когось, хто може Вам допомогти.

Щоб дізнатися більше про процес поручительства, прочитайте також нашу вікі-документацію: https://wiki.ubuntu.com/SponsorshipProcess

Завантаження пакунку

Як тільки Ваша пропозиція про злиття розглянута й підтверджена, Ви забажаєте завантажити свій пакунок або у архів (якщо в Вас є права), або у свій Персональний Архів Пакунків Personal Package Archive (PPA). Також можливо Ви забажаєте виконати завантаження, якщо спонсоруєте зміни, внесені іншим користувачем.

Вивантаження змін, зроблених Вами

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

Спочатку Вам потрібно переконатися, що в Вас найостанніша версія пакунку у налагодженні дерева пакунку розробки:

$ cd tomboy/tomboy.dev
$ bzr pull

Це застосує будь-які зміни, які були внесені за час Вашої роботи над фіксом. Починаючи з цієї миті в Вас є декілька варіянтів. Якщо Ваші зміни великі й Ви відчуваєте, що їх слід протестувати разом з Вашими змінами - то можна об’єднати їх у гілці виправлення вад і провести тестування там. Якщо ні, то Ви можете продовжити процес злиття у Вашій гілці виправлення вади. Стосовно bzr 2.5 і bzr-builddeb 2.8.1, це працює так само як й стандартна команда merge:

$ bzr merge ../bug-12345

Для старіших версій bzr можна використовувати назамін команду merge-package:

$ bzr merge-package ../bug-12345

Ця команда зіллє два дерева й, можливо, повідомить про конфлікти, які Вам потрібно буде вирішити вручну.

Далі потрібно переконатися у правильності вмісту debian/changelog, тобто, що там правильно вказаний дистрибутив, номер версії тощо.

Як тільки це зроблено, Ви повинні ще раз переперевірити зміни, які бажаєте відправити, за допомогою bzr diff. Це має показати ті ж зміни, як показав би debdiff до завантаження джерельного пакунку.

Наступний крок — зібрати й протестувати змінений пакунок джерельного коду, як Ви це зазвичай робите:

$ bzr builddeb -S

Коли Ви нарешті задоволені своєю гілкою, переконайтеся що відправили усі зміни, а потім позначте гілку номером версії логу змін. Команда bzr tag зробить це автоматично, якщо не вказано жодного аргументу:

$ bzr tag

Цей тег повідомить імпортуючому пакунок, що вміст гілки Bazaar ідентичний вмісту архіву.

Тепер Ви можете вивантажити командою push зміни назад на Launchpad:

$ bzr push ubuntu:tomboy

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

Вам потрібен один останній крок, щоб відправити свої зміни в Ubuntu або Ваш PPA: Вам потрібно завантажити за допомогою dput пакунок джерельного коду у відповідне місце. Наприклад, щоб завантажити зміни в PPA, зробіть таке:

$ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes

або, якщо в Вас є права завантаження до основного архіву:

$ dput tomboy_1.5.2-1ubuntu5_source.changes

Тепер Ви можете вилучити гілку, оскільки вона вже об’єднана, й за необхідності її можна поновій стягнути з Launchpad.

Поручительство над зміною

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

$ bzr merge lp:~subgenius/ubuntu/trusty/tomboy/bug-12345

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

Але якщо із змінами усе добре - підтвердіть, а потім пройдіть частину процесу завантаження що залишилася:

$ bzr commit --author "Bob Dobbs <subgenius@example.com>"

Скасування вивантаження

У будь-який час до виконання дії dput з джерельним пакунком Ви можете скасувати завантаження й зробити відкат усіх змін:

$ bzr revert

Ви можете зробити це якщо помітите, що потрібно ще не багато роботи, або якщо бажаєте попрохати розробника виправити конфлікти (якщо виступаєте його поручителем).

Поручительство над чимось і внесення своїх власних змін

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

Якщо в Вас вже є гілка, у якій Ви працюєте над пакунком й Ви бажаєте включити усі зміни - просто запустіть bzr merge з цієї гілки, замість налагодження пакунку розробки. Потім Ви можете внести зміни й відправити, а потім продовжити роботу із змінами до пакунку.

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

$ bzr branch lp:~subgenius/ubuntu/trusty/tomboy/bug-12345

потім працюйте у цій новій гілці, а після цього виконайте її злиття з головною й завантажте таким чином, як якби завантажували власну роботу. Розробник-участник усе ще буде згаданий у логах змін, і Bazaar належним чином призначить їм внесені ними зміни.

Отримання останніх змін

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

Оновлення Вашої основної гілки

Оновити Вашу копію гілки, що відповідає пакунку у певному випуску, дуже просто: виконайте bzr pull з відповідного каталогу:

$ cd tomboy/tomboy.dev
$ bzr pull

Це працює якщо в Вас є налагодження гілки, тому його можна застосувати для таких речей як гілки saucy, trusty-proposed, тощо.

Отримання останніх змін у Ваші робочі гілки

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

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

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

Щоб виконати злиття змін, Вам потрібно використовувати bzr merge, але спочатку Ви повинні відправити свою поточну роботу:

$ cd tomboy/bug-12345
$ bzr merge ../tomboy.dev

Про будь-які конфлікти буде повідомлятися. Тож Ви зможете їх виправити у подальшому. Щоб розглянути зміни, використовуйте bzr diff. Як тільки Ви закінчили роботу - використовуйте bzr commit.

Відносно версій пакунку

Ви часто будете думати відносно версій пакунку, а не просто про цифри попередніх виправлень в Bazaar. bzr-builddeb для зручності надає специфікатор виправлень. Будь-яка команда, що використовує аргумент -r для вказувань виправлення або діапазону виправлень, буде працювати з цим специфікатором, наприклад, bzr log, bzr diff``тощо. Щоб продивитися версії пакунку, використовуйте специфікатор ``package::

$ bzr diff -r package:0.1-1..package:0.1-2

Ця команда покаже Вам відмінності між версіями пакунку 0.1-1 і 0.1-2.

Злиття — оновлення з Debian та апстріму

Злиття — це одна з найсильніших сторін Bazaar, й ми часто виконуємо його у процесі розробки Ubuntu. Злиття може бути виконано з оновленнями з Debian, з нового випуску у апстрімі й від інших розробників Ubuntu. Зробити це в Bazaar дуже просто, усе засновано на команді bzr merge [1].

Знаходячись у робочому каталозі будь-якої гілки, Ви можете виконати злиття змін з гілки у іншому місці. Спочатку перевірте, що в Вас немає незафіксованих змін:

$ bzr status

Якщо з’явиться звіт, то Вам потрібно або застосувати зміни, зробити відкат, або відкласти вирішення (й повернутися до їх вирішення пізніше).

Злиття з Debian

Потім запустіть bzr merge, передаючи URL гілки для злиття. Наприклад, щоб виконати злиття версій пакунку в Debian Unstable запустіть [2]:

$ bzr merge lp:debian/tomboy

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

$ bzr status
$ bzr diff

Якщо з’явиться звіт про конфлікти, Вам потрібно відредагувати відповідні файли, щоб привести їх до потрібного вигляду, прибравши конфліктуючі маркери (conflict markers). Як тільки Ви це зробите, виконайте:

$ bzr resolve
$ bzr conflicts

Це вирішить проблему з конфліктуючими файлами, які Ви виправляли, й повідомить що ще Вам потрібно зробити.

Після того, як усі конфлікти вирішено, й Ви внесли усі інші необхідні зміни, потрібно додати новий запис у changelog й виконати фіксацію:

$ dch -i
$ bzr commit

як був опис вище.

Втім перед фіксацією завжди бажано перевірити усі зміни, зроблені в Ubuntu, виконавши:

$ bzr diff -r tag:0.6.10-5

Ця команда покаже відмінності між версіями в Debian (0.6.10-5) і Ubuntu (0.6.10-5ubuntu1). Подібно Ви можете виконати порівняння з будь-якими іншими версіями. Щоб побачити усі доступні версії, виконайте:

$ bzr tags

Після перевірки та фіксації злиття, Вам потрібно знайти поручителя або вивантажити пакунок у архів у звичний спосіб.

Якщо Ви збираєтеся створити джерельний пакунок з цієї об’єднаної гілки, то потрібно використовувати опцію -S команди bd. Також Вам закортить розглянути використання опції --package-merge. Це додасть відповідні опції -v і -sa до джерельного пакунку, щоб усі записи у лозі змін після останніх змін в Ubuntu були включені у Ваш файл _source.changes. Наприклад:

$ bzr builddeb -S --package-merge

Злиття з новою версією з апстріму

Коли в апстрімі випускається нова версія (або Ви бажаєте запакувати зняток), Вам потрібно виконати злиття tar-архіву й Вашої гілки.

Це робиться командою bzr merge-upstream. Якщо у Вашому пакунку є файл debian/watch з правильним вмістом, то з каталогу гілки, у яку Ви збираєтеся злити зміни, просто наберіть:

$ bzr merge-upstream

Команда завантажить тарбол й зіллє його у Вашу гілку, автоматично додавши запис в debian/changelog. bzr-builddeb продивляється файл debian/watch, щоб визначити місцезнаходження тарболу з апстріму.

Якщо в Вас відсутній файл debian/watch, то Вам потрібно вручну вказати місцезнаходження тарболу з апстріму й версію:

$ bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz

Опція --version використовується для вказування версії апстріму, з якої виконується злиття, оскільки команда не здатна (поки) дізнатися її самостійно.

Останній параметр — це місцезнаходження тарболу, на який виконується оновлення: це може бути шлях у локальній файловій системі, http, ftp, sftp або інша URI, як показано у прикладі. Команда автоматично завантажить тарбол для Вас, перейменує його відповідним чином й, якщо потрібно, перетворить у .gz.

Команда merge-upstream повідомить або про своє вдале завершення, або про те, що є конфлікти. У будь-якому випадку в Вас буде можливість перевірити зміни перед їх фіксацією у звичний спосіб.

Якщо Ви об’єднуєте реліз апстріму з існуючою гілкою Bazaar, у якій ще не використовуалася розмітка UDD, bzr merge-upstream пройде невдало й з помилкою, що тег попередніх версій апстріму недоступний. Злиття неможна виконати без знання базової версії для злиття. Для роботи з цим, створіть тег у своєму існуючому репозиторії для останньої версії апстріму що там є; наприклад, якщо останній реліз Ubuntu був 1.1-0ubuntu3, створіть тег upstream-1.1, вказуючи на зміну bzr, яку Ви бажаєте використовувати як підказку для гілки апстріму.

[1]

Для роботи з командою merge Вам знадобляться новіші версії bzr та bzr-builddeb. Використовуйте версії з Ubuntu 12.04 (Precise) або розроблювані версії з PPA bzr. Точніше кажучи, Вам знадобиться bzr версії 2.5 beta 5 або новішої, а також bzr-builddeb версії 2.8.1 або новішої. Для старих версій використовуйте назамін команду bzr merge-package.

[2]

Щоб перевірити наявність інших гілок пакунку в Debian, див. сторінку коду пакунку. Наприклад: https://code.launchpad.net/debian/+source/tomboy

Використання chroot-оточень

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

Використання chroot дозволить Вам мати у розпорядженні повну файлову систему іншого дистрибутиву для зручності роботи. Це дозволяє уникнути затрат, пов’язаних з встановленням віртуальної машини.

Створення chroot

Використовуйте команду debootstrap, щоб створити новий chroot:

$ sudo debootstrap trusty trusty/

Це створить теку trusty і встановить мінімальний образ trusty у неї.

Якщо Ваша версія debootstrap не визначить Trusty, спробуйте оновитися до версії в backports.

Після цього Ви можете працювати всередині chroot:

$ sudo chroot trusty

Де можна встановити або вилучити будь-який пакунок, який Ви бажаєте, без шкоди для основної системи.

Ви можете скопіювати свої ключі GPG і SSH, а також конфігурацію Bazaar в chroot, щоб отримувати доступ й підписувати пакунки безпосередньо звідти:

$ sudo mkdir trusty/home/<username>
$ sudo cp -r ~/.gnupg ~/.ssh ~/.bazaar trusty/home/<username>

Щоб apt й інші проґрами не скаржилися на відсутні локалі, можна встановити відповідний мовний пакунок:

$ apt-get install language-pack-en

Якщо Вам потрібно запускати проґрами, що використовують X-сервер, Вам потрібно додати в chroot директорію /tmp, для цього ззовні chroot запустіть:

$ sudo mount -t none -o bind /tmp trusty/tmp
$ xhost +

Для деяких проґрам, можливо, знадобиться прив’язати /dev або /proc.

На сторінці Debootstrap Chroot вікі Ви знайдете детальнішу інформацію про chroot-оточення.

Альтернативи

SBuild – система, схожа на PBuilder, що використовується для створення оточення, у якому виконуються тестові збірки пакунку. Вона близька до тієї, яку використовує Launchpad для збірки пакунків, але її встановлення дещо складніше, ніж PBuilder. Повнішу інформацію можна знайти на вікісторінці Система Збірки Security Team.

Повні віртуальні машини можуть бути корисні для створення пакунків й тестування проґрам. TestDrive — це проґрама, яка дозволяє автоматизувати синхронізацію і запуск щоденних ISO-образів. Детальніше дивіться wiki-сторінку TestDrive.

Можна також налаштувати pbuilder так, щоб він призупинявся при виявленні помилки збірки. Скопіюйте C10shell з /usr/share/doc/pbuilder/examples у каталог й використовуйте аргумент --hookdir=, щоб вказати на нього.

Хмарний сервіс Amazon EC2 дозволить Вам придбати комп’ютер у хмарі, ціна за який – усього декілька центів на годину. Там Ви можете встановити Ubuntu будь-якої підтримуваної версії і працювати з пакунками віддалено, що дуже зручно, якщо потрібна збірка багатьох пакунків одночасно, або якщо потрібно подолати повільну швидкість Інтернет-під’єднання.

Традиційні методи створення пакунків

Велика частина даного посібника відноситься до Ubuntu Distributed Development (UDD), яке використовує розповсюджувану версію системи керування (DVCS) Bazaar для отримання джерел пакунків й відправки фіксів через пропозиції про злиття. У цій статті ми обговоримо так звані “традиційні” методи створення пакунків. До того як Bazaar стали застосовувати у розробках Ubuntu, допомогти Ubuntu можна було стандартними способами.

У деяких випадках Вам може знадобитися використовувати ці інструменти замість UDD. Тому не завадить познайомитися з ними. Перед тим, як продовжити, Вам слід прочитати статтю Підготовка.

Отримання джерельного коду

Щоб отримати пакунок джерельного коду, можна просто набрати:

$ apt-get source <package_name>

Але в цього методу є деякі недоліки. Він стягує версію джерельного коду, яка доступна у Вашій системі. Швидше за усе, в Вас встановлено поточний стабільний випуск, а Ви збираєтеся внести зміни у пакунок у розроблюваному випуску. На щастя, пакунок ubuntu-dev-tools надає допоміжний сценарій:

$ pull-lp-source <package_name>

Типово буде завантажена найсвіжіша версія з розроблюваного выпуску. Можна також вказати версію випуску Ubuntu таким чином:

$ pull-lp-source <package_name> trusty

щоб витягнути джерело з релізу trusty, або:

$ pull-lp-source <package_name> 1.0-1ubuntu1

щоб стягнути версію пакунку 1.0-1ubuntu1. Для отримання додаткової інформації про команду скористайтеся man pull-lp-source.

Для прикладу, уявімо, що ми отримали звіт про ваду, у якому говориться, що замість “colour” у описі``xicc`` має бути “color,” й ми бажаємо це виправити. (Нотатка: це просто приклад чогось, що можна змінити, а не реальна помилка.) Щоб отримати джерельний код, уведіть:

$ pull-lp-source xicc 0.2-3

Створення Debdiff

Файл debdiff показує відмінності між двома пакунками Debian. Ім’я команди, що використовується для його створення, теж debdiff. Вона є частиною пакунку devscripts. Дивіться man debdiff для детальної інформації про неї. Щоб порівняти два пакунки джерельного коду, передайте команді у якості аргументу два файли dsc:

$ debdiff <package_name>_1.0-1.dsc <package_name>_1.0-1ubuntu1.dsc

Щоб продовжити наш приклад, давайте відредагуємо debian/control й «виправимо» нашу «помилку»:

$ cd xicc-0.2
$ sed -i 's/colour/color/g' debian/control

Ми також повинні дотримуватися Специфікацій Обслуговування Debian<MaintFieldSpec_> й редагувати debian/control для заміни:

Maintainer: Ross Burton <ross@debian.org>

на:

Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XSBC-Original-Maintainer: Ross Burton <ross@debian.org>

Для цього можна скористатися інструментом update-maintainer (з пакунку ubuntu-dev-tools).

Не забудьте задокументувати Ваші зміни в debian/changelog за допомогою dch -i, після чого ми можемо згенерувати новый пакунок джерельного коду:

$ debuild -S

Тепер можна перевірити наші зміни за допомогою debdiff:

$ cd ..
$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc | less

Щоб створити файл латки, який можна відправити іншим або прикласти до звіту про ваду для схвалення, виконайте:

$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc > xicc_0.2-3ubuntu1.debdiff

Застосування Debdiff

Щоб застосувати debdiff, потрібно мати джерельний код версії, на основі якої він був створений:

$ pull-lp-source xicc 0.2-3

Потім у терміналі змініть на директорію, куди був розпакований джерельний код:

$ cd xicc-0.2

Фактично, debdiff схожий на звичайний файл латки. Застосуйте його, як завжди, за допомогою:

$ patch -p1 < ../xicc_0.2.2ubuntu1.debdiff

Робота з пакунками KDE

Створенням пакунків проґрам KDE в Ubuntu займаються команди Kubuntu і MOTU. Зв’язатися з командою Kubuntu можна через поштову розсилку Kubuntu й канал Freenode IRC #kubuntu-devel. Додаткова інформація про розробку Kubuntu доступна на wiki-сторінці Kubuntu.

При створенні пакунків ми враховуємо практику команд Debian Qt/KDE і Debian KDE Extras. Більшість наших пакунків є похідними від пакунків, створених цими командами Debian.

Політика створення латок

Kubuntu додає латки у застосунки KDE, лише якщо вони походять від оригінальних авторів, або якщо вони були відправлені в upstream й є впевненість у їх швидкому прийнятті, або якщо ми обміркували проблеми з розробниками KDE.

Kubuntu не змінює фірмового оформлення пакунків, крім випадків, коли цього потребує апстрім (наприклад, логотип у горішньому лівому куту меню Kickoff) або для спрощення (наприклад, вилучення показуваних при запуску заставок).

debian/rules

Пакунки Debian включають деякі доповнення до звичайного використання Debhelper. Вони зберігаються у пакунку pkg-kde-tools.

Пакунки, що використовують Debhelper 7, повинні додати опцію --with=kde. Це дозволить переконатися у використанні правильних прапорців збірки і опцій, таких як обробка завдань kdeinit та файлів перекладу.

%:
    dh $@ --with=kde

Деякі нові пакунки 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.

Переклади

Переклади пакунків з репозиторію main імпортуються на Launchpad і експортуються з Launchpad у мовні пакунки Ubuntu.

Отже, кожен KDE-пакунок в main повинен створювати шаблони перекладів, включати оригінальні переклади і опрацьовувати рядки що перекладаються у .desktop-файлах.

Для генерації шаблонів перекладів пакунок повинен містити файл Messages.sh; якщо його там немає, зверніться в апстрім. Перевірити його роботу можна, виконавши сценарій extract-messages.sh, який повинен створити один або декілька файлів .pot у каталозі po/. У процесі збирання це буде зроблено автоматично, якщо Ви використовуєте опцію --with=kde для dh.

Апстрім зазвичай також поміщає файли перекладів .po у каталог po/. Якщо їх там немає, перевірте, чи не виділені вони у один з окремих мовних пакунків апстріму, наприклад, у мовні пакунки KDE SC. Якщо вони у окремому мовному пакунку, на Launchpad необхідно збирати їх разом вручну. Проконсультуйтеся з цього приводу з Девідом Планеллою (David Planella).

Якщо пакунок переміщений з universe в main, його слід перевивантажити перед імпортом перекладів на Launchpad.

Файли .desktop також потребують перекладу. Ми додали латку до KDELibs для читання перекладів з .po-файлів, що вказують на рядок X-Ubuntu-Gettext-Domain=, що додається до файлів .desktop під час збірки пакунку. Файл .pot для кожного пакунку генерується під час збірки й .po-файли необхідно стягнути з апстріму і включити у пакунок або в наші мовні пакунки. Перелік .po-файлів, які потрібно стягнути зі сховищ KDE, знаходиться в /usr/lib/kubuntu-desktop-i18n/desktop-template-list.

Бібліотекові символи

Бібліотекові символи відстежуються за допомогою файлів .symbols, які дозволяють переконатися, що усе на місці. KDE використовує бібліотеки C++, які діють дещо інакше, ніж бібліотеки C. Для Debian команда Qt/KDE створила скрипти, які дозволяють подолати це. Документ Робота з файлами symbols дає опис, як створювати й оновлювати такі файли.

Матеріяли для подальшого читання

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

Якщо Ви бажаєте дізнатися більше про збирання пакунків Debian, ось декілька ресурсів Debian, які можуть бути Вам корисними:

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