m (Redirected page to PackageMaintainers/ru/Как стать владельцем пакета) |
|||
(16 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
#REDIRECT [[PackageMaintainers/ru/Как_стать_владельцем_пакета]] | |||
== Предисловие == | == Предисловие == | ||
Line 7: | Line 9: | ||
Автор выражает надежду, что изложенная информация будет полезна для успешного старта. | Автор выражает надежду, что изложенная информация будет полезна для успешного старта. | ||
--[[User:Tim4dev|Tim4dev]] 13:50, 6 November 2009 (UTC) | |||
== Начало == | == Начало == | ||
Line 144: | Line 147: | ||
rpmbuild -E '%{_bindir}' myfile.spec | rpmbuild -E '%{_bindir}' myfile.spec | ||
</pre> | </pre> | ||
=== секция %install === | |||
Команды этой секции копируют файлы из "build directory" ''%{_builddir}'', обычно это | |||
<pre> | |||
~/rpmbuild/BUILD/something | |||
# пример | |||
~/src/BUILD | |||
</pre> | |||
в ''%{buildroot}'', обычно это | |||
<pre> | |||
/var/tmp/something | |||
# пример | |||
~/src/BUILDROOT/%{name}-%{version}-%{release}.i386 | |||
</pre> | |||
и создают подкаталоги в %{buildroot} если нужно. | |||
{{admon/important| | |||
Внимание, эта терминология очень запутанна.| | |||
* каталоги build (где происходит компиляция в стадии %build) и build root (куда файлы копируются в процессе %install) - это разные каталоги. | |||
* %install скрипт не устанавливает rpm пакет!! Термин %install запутывающий, скрипт устанавливает программу '''НЕ''' в реальную конечную локацию (типа /usr/bin), а в %{buildroot}. | |||
}} | |||
== Сборка == | |||
Быстрое тестирование: | |||
<pre> | |||
rpmlint program.spec | |||
</pre> | |||
Сборка | |||
<pre> | |||
rpmbuild -ba program.spec | |||
</pre> | |||
Это будет попытка выполнить следующие этапы: | |||
* %prep (preparation) этап подготовки. Распаковка и установка исходников и патчей в %_builddir (подкаталог ~/rpmbuild/BUILD) | |||
* %build этап, компиляция файлов, которые будут установлены в _builddir%. Обычно это какой-то эквивалент "make". | |||
* %install этап, копирование файлов из %_builddir (который подкаталог ~/rpmbuild/BUILD) в каталог %{buildroot}. Каталог buildroot ранее установлен в "BuildRoot:"; если вы оставите его в обычном значении начинающемся %{_tmppath}/%{name}..., то buildroot будет внутри /var/tmp. | |||
* создание бинарного и source RPM пакетов (.rpm и .src.rpm). Бинарный RPM создается с использованием информации из %files файлов. | |||
Если что-то пошло не так, вы можете перейти в соответствующий каталог и посмотреть, что осталось. Если вы хотите пропустить более ранние стадии установки советуем использовать опцию "--short-circuit". Это удобно, если у вас была успешна стадия build, но есть ошибка в %install секции. | |||
Например: | |||
<pre> | |||
$ rpmbuild -bi --short-circuit program.spec | |||
</pre> | |||
== Тестирование == | |||
Смотреть список файлов | |||
<pre> | |||
rpmls *.rpm | |||
</pre> | |||
Тест | |||
<pre> | |||
$ rpmlint <имя>.rpm | |||
# или | |||
$ rpmlint -i <имя>.rpm | |||
webacula.noarch: E: htaccess-file /usr/share/webacula/html/.htaccess | |||
webacula.noarch: W: dangling-symlink /usr/share/webacula/library/Zend /usr/share/php/Zend | |||
webacula.noarch: E: executable-marked-as-config-file /etc/cron.daily/webacula_clean_tmp.sh | |||
webacula.noarch: W: file-not-utf8 /usr/share/doc/webacula-3.2.1/INSTALL.es | |||
webacula.noarch: E: zero-length /usr/share/webacula/application/views/scripts/index/index.phtml | |||
</pre> | |||
Просмотреть инфу по ошибке, например | |||
<pre> | |||
$ rpmlint -I htaccess-file | |||
htaccess-file: | |||
You have individual apache configuration .htaccess file(s) in your package. | |||
Replace them by a central configuration file in /etc/, according to the web | |||
application packaging policy for your distribution. | |||
</pre> | |||
Если все ок, то установите пакет | |||
<pre> | |||
rpm -ivp [package].rpm | |||
rpm -e [package] | |||
</pre> | |||
Сбока под '''mock'''. Вы д.б. в группе mock | |||
<pre> | |||
$ cd ~/src/SRPMS | |||
$ mock -r fedora-11-i386 rebuild webacula-3.2.1-1.fc10.src.rpm | |||
</pre> | |||
''Прим''. mock скачивает файлы в /var/lib/mock | |||
Какие типичные ошибки можно сделать, даже хорошо подготовившись, см. [https://bugzilla.redhat.com/show_bug.cgi?id=526855 мой Review Request]. | |||
=== koji === | |||
Если mock отработал ок, то сборка под '''koji'''. Настройка koji описана здесь: [[PackageMaintainers/UsingKoji|Using the Koji build system]], [[PackageMaintainers/Join|Join the package collection maintainers]] | |||
Сгенерить сертификат [https://admin.fedoraproject.org/accounts/user/gencert Fedora Account System]. | |||
Сохранить его под именем <code>~/.fedora.cert</code>, запустить | |||
<pre> | |||
$ fedora-packager-setup | |||
</pre> | |||
Теперь можно логиниться в [http://koji.fedoraproject.org/koji/ Koji Build System] | |||
<pre> | |||
$ koji build --scratch dist-f11 webacula-3.2.1-1.fc10.src.rpm | |||
</pre> | |||
При этом на странице https://koji.fedoraproject.org/koji/ будет виден прогресс и логи. | |||
== Review Request == | |||
Для примера см. [https://bugzilla.redhat.com/show_bug.cgi?id=526855 мой Review Request]. | |||
'''Обязательно''' подписаться на [https://www.redhat.com/mailman/listinfo/fedora-devel-announce fedora-devel-announce@redhat.com] | |||
Также можно подписаться на [https://www.redhat.com/mailman/listinfo/fedora-devel-list fedora-devel-list@redhat.com] | |||
Получить помощь можно также на канале ''#fedora-devel'' на freenode. | |||
Разместить свой SRPM и SPEC файлы где-нибудь в инете. | |||
Создать "Review Request" [https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=extras-review заполнив форму]. | |||
Объяснить в поле 'Review Description', что это первый пакет и нужен поручитель: ''That this is my first package and I need a sponsor.'' | |||
В поле Blocks указать баг <code>FE-NEEDSPONSOR</code>. | |||
См. также [[PackageMaintainers/HowToGetSponsored|How to get sponsored]] | |||
Потенциальные поручители просматривают [https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEEDSPONSOR FE-NEEDSPONSOR] баг в багзилле. | |||
Кто-нибудь рассмотрит ваш пакет. Пока нет рецензента (поручителя) флаг <code>fedora-review flag</code> будет пуст. | |||
fedora-review flag будет установлен в +, когда пакет пройдет рассмотрение. | |||
См. также [[Package_Review_Process#Definitions_for_fedora-review_Flag_Settings|Definitions for fedora-review Flag Settings]] | |||
Подробнее процесс описан в [[Package_Review_Process|Package Review Process]] | |||
Я искал поручителя на irc-каналах в т.ч. русскоязычных. | |||
===Спонсор=== | |||
Когда Review Request одобрен рецензентом (reviewer), надо найти спонсора (sponsor). | |||
{{admon/note||Рассмотрение и утверждение на первый пакет для новых упаковщиков (packagers) должно быть сделано зарегистрированным спонсором. Последующие обзоры (reviews) м.б. сделаны любым сопровождающим (maintainer) пакета. | |||
Неофициальные отзывы всегда может сделать любое заинтересованное лицо.}} | |||
==CVS== | |||
После успешного завершения фазы Review Request надо выполнить [[PackageMaintainers/CVSAdminProcedure|CVS admin requests]] | |||
В том же сам баге установить флаг fedora-cvs в ? и в каменте описать по шаблону | |||
<pre> | |||
New Package CVS Request | |||
======================= | |||
Package Name: webacula | |||
Short Description: Webacula - Web Bacula - web interface of a Bacula backup system | |||
Owners: tim4dev | |||
Branches: F-11 F-12 EL-5 | |||
InitialCC: | |||
</pre> | |||
{{admon/note||Запросы на пакеты для F-(X-2) версий федоры , если версия F-X уже выпущена не будут приняты. | |||
Например, если уже выпущен релиз Fedora 12, то запрос на пакет для Fedora 10 не принимается.}} | |||
Смотреть [https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=fedora-cvs%3F очередь запросов на CVS] | |||
Пришли письма от <code>From: Fedora PackageDB <pkgdb@fedoraproject.org></code> : | |||
<pre> | |||
kevin added a Fedora 12 branch for webacula | |||
kevin added a Fedora 11 branch for webacula | |||
kevin added a Fedora EPEL 5 branch for webacula | |||
/pkgdb/packages/name/webacula | |||
</pre> | |||
Теперь нужно импортировать пакет в CVS. | |||
===Импорт в CVS=== | |||
Создать отдельный каталог | |||
<pre> | |||
mkdir webacula.cvs | |||
</pre> | |||
Можно запустить ssh-add прежде чем делать любые операции в CVS. Это спасет вас от необходимости вводить пароль ключа для каждой операции. Пароль будет запомнен до завершения сеанса или перезагрузки. | |||
<pre> | |||
ssh-add | |||
fedora-cvs webacula | |||
cd webacula | |||
./common/cvs-import.sh PATH_TO_SRPM | |||
</pre> | |||
'''Шаг. 9''' Импорт вашего srpm | |||
Правильнее так (см. также [[PackageMaintainers/NewPackageProcess|New Package Process, п.9]]): | |||
<pre> | |||
./common/cvs-import.sh -m "Initial import (#nnnnnn)." nameofmy.src.rpm | |||
</pre> | |||
где nnnnnn номер вашего package-review-бага в Bugzilla. | |||
Это будет импорт в ветку devel | |||
Исходный тарбол не хранится в CVS, а находится где-то в другом месте. | |||
Вы также захотите сделать дополнительный импорт, например, | |||
<pre> | |||
./common/cvs-import.sh -m "Initial import (#nnnnnn)." -b F-11 PATH_TO_SRPM | |||
</pre> | |||
где nnnnnn номер вашего package-review-бага в Bugzilla. | |||
<pre> | |||
cd devel | |||
cvs update | |||
</pre> | |||
'''Шаг. 10''' Теперь надо импортировать ваш пакет в остальные бранчи. | |||
Самый быстрый способ - скопировать ваш .spec, патчи из devel/ в каждый бранч. | |||
Проверьте наличие Makefile и скопируйте его, если необходимо. После этого | |||
<pre> | |||
cvs add | |||
cvs commit | |||
</pre> | |||
===build=== | |||
'''Шаг. 11''' Сделать тэг для ваших веток. | |||
Перед тем как бранч будет построен в Fedora Package buildsystem, файлы в нем д.б. тэгированы. | |||
Когда вы успешно сделали все коммиты в каждом бранче, идите в каталог бранча и | |||
<pre> | |||
make tag | |||
</pre> | |||
Вы должны увидеть тег ветки с версией и релизом из spec-файла. | |||
Вам необходимо тэгировать все бранчи, которые вы хотите построить. | |||
Если вы только что импортировали SRPM, то вам не нужно делать тэги, cvs-import.sh сделает это за вас. | |||
'''Шаг 12.''' Запрос на builds | |||
См. также про koji | |||
Для каждого тэгированного бранча для которого вы хотите запросить build, идите в каталог бранча (например, cd F-11/) и запустите: | |||
<pre> | |||
make build | |||
</pre> | |||
Если все пойдет хорошо, то бранч должен стать в очередь билдинга, пакет будет построен, и все готово! | |||
Если пакет не построился, сборочная система отправит вам емайл, чтобы сообщить о неудаче и линк к логам. | |||
Закоммитите какие-либо необходимые изменения в CVS, измените в Spec номер релиза, retag бранча, и запросите новый build. | |||
'''Шаг 13''': закройте Bugzilla баг (при условии, что пакет построен успешно). Вы должны закрыть его как NEXTRELEASE. | |||
'''Шаг 15''': Добавьте пакет в [[PackageMaintainers/CompsXml|comps.xml]], если необходимо. | |||
Так что он может быть выбран во время установки и включен в группы пакетов которые обрабатывает Yum. | |||
См. также [[PackageMaintainers/UsingCvsFaq|Cvs Faq]] где есть инструкции для создания новых релизов. | |||
Скопировать spec и файл ''sources'' в другие бранчи | |||
<pre> | |||
cvs add webacula.spec | |||
cvs diff -u | |||
cvs -m "Initial commit" commit | |||
make tag | |||
# или, если будет ругаться, что такой тэг уже есть | |||
TAG_OPTS=-F make tag # такое не приветствуется, в дальнейшем лучше | |||
# изменить номер spec и сделать новый тэг | |||
# чисто для проверки, что все в порядке | |||
make srpm | |||
make build | |||
</pre> | |||
===make update=== | |||
[[PackageMaintainers/UpdatingPackageHowTo]] | |||
Заключительный этап | |||
<pre> | |||
make update | |||
</pre> | |||
Будет предложено ввести описание. Укажите | |||
<pre> | |||
type=newpackage | |||
request=testing | |||
bugs=<здесь № бага Review Request (цифра)> | |||
notes=<укажите описание пакета, скопируйте из %description SPEC-файла> | |||
</pre> | |||
После сабмита, Bodhi автоматически сделает запрос чтобы ваше обновление было протолкнуто в updates-testing. | |||
Если вы считаете, что тестирование не нужно для обновления, вы можете протолкнуть его прямо в стабильный репо обновлений Fedora. | |||
Обратите внимание, что для обновлений безопасности есть несколько иной процесс. | |||
Release Engineer вручную подпишет и протолкнет обновление. | |||
После проталкивания в testing, у людей есть возможность обновлять карму +1/-1 вашего обновления пакета. | |||
Если ваше обновление достигает карма 3, оно автоматически будет протолкнуто в stable. | |||
Аналогично, если она достигает -3, оно будет автоматически unpushed. | |||
Если обновление не получает достаточной обратной связи для автоматического проталкивания в stable, вам придется засабмитить его в качестве финального обновления самого себя. Это можно легко сделать с параметром командной строки, или с веб-интерфейсом. | |||
Затем вы будете уведомлены, когда ваше обновление попадет в stable. | |||
Бодхи закроет все тикеты связанные с ошибками и отправит объявление в | |||
[https://www.redhat.com/archives/fedora-package-announce/ fedora-package-announce] рассылку. | |||
На данный момент, ваше обновление официально выпущено! | |||
Peter Lemenkov: ''когда выполнят твой запрос и переместят его в updates-testing, то там будет кнопочка "mark as stable"'' | |||
===Bodhi=== | |||
Вместо "make update" можно юзать [https://fedorahosted.org/bodhi/wiki/CLI bodhi command-line interface] или [https://admin.fedoraproject.org/updates bodhi веб-интерфейс] | |||
Смотреть инфу по пакету (примеры) | |||
<pre> | |||
bodhi --new -R stable -b 529269 -t newpackage -u atorkhov cmospwd-5.0-1.fc12 | |||
bodhi -u tim4dev -m webacula-3.3-6.fc11 -m webacula-3.3-6.fc12 | |||
bodhi webacula | |||
</pre> | |||
== Окончание == | |||
Ч/з 2-е недели пришло письмо | |||
<pre> | |||
From: updates@fedoraproject.org | |||
Subject: [Fedora Update] [old_testing] webacula-3.3-6.fc11 | |||
To: tim4dev@fedoraproject.org | |||
Date: Fri, 06 Nov 2009 00:00:07 +0000 | |||
X-Mailer: TurboMail TurboGears Extension v.2.1 | |||
The update for webacula-3.3-6.fc11 has been in 'testing' status for over 2 weeks. | |||
This update can be marked as stable after it achieves a karma of 3 | |||
or by clicking 'Push to Stable'. | |||
This is just a courtesy nagmail. Updates may reside in the testing repository | |||
for more than 2 weeks if you deem it necessary. | |||
You can submit this update to be pushed to the stable repository by going to | |||
the following URL: | |||
http://admin.fedoraproject.org/updates/request/stable/webacula-3.3-6.fc11 | |||
or by running the following command with the bodhi-client: | |||
bodhi -R stable webacula-3.3-6.fc11 | |||
================================================================================ | |||
webacula-3.3-6.fc11 | |||
================================================================================ | |||
Update ID: FEDORA-2009-10550 | |||
Release: Fedora 11 | |||
Status: testing | |||
Type: newpackage | |||
Karma: 1 | |||
Notes: Webacula - Web Bacula - web interface of a Bacula backup system. | |||
: Supports the run Job, restore all files or selected | |||
: files, restore the most recent backup for a client, | |||
: restore backup for a client before a specified time, | |||
: mount/umount Storages, show scheduled, running and | |||
: terminated Jobs and more. Supported languages: | |||
: English, French, German, Portuguese Brazil, Russian. | |||
Submitter: tim4dev | |||
Submitted: 2009-10-16 12:38:47 | |||
Comments: tim4dev - 2009-10-16 12:38:49 (karma 0) | |||
This update has been submitted for testing | |||
tim4dev - 2009-10-20 09:58:09 (karma 1) | |||
bodhi - 2009-10-21 00:34:27 (karma 0) | |||
This update has been pushed to testing | |||
http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10550 | |||
</pre> | |||
== Что дальше == | |||
Обновлять сопровождаемый пакет: [[Package_update_HOWTO]] | |||
=== Новый пакет === | |||
Следующие пакеты добавлять по процедуре: [[PackageMaintainers/NewPackageProcess]] | |||
=== Обновление пакета === | |||
[[PackageMaintainers/Package_update_guidelines|Package update guidelines]] | |||
Многие пользователи обновляют Fedora автоматически, поэтому крайне важно, чтобы обновление не причинило вреда или система внезапно не перестала работать. | |||
Обновление с багфиксами как правило, должно быть сначала помещено в "testing" и оно затем попадет в "stable" после того, как наберет достаточо кармы в bodhi. | |||
Новый релиз не обязательно должен быть pushed в release ветку. Rawhide является веткой разработки, куда можно проталкивать обновления перед тем как протолкнуть их в release ветку. | |||
Fedora пользователи, которые не обновляются автоматически должны иметь возможность посмотреть (через PackageKit) описание обновлений, прежде чем решить, должны ли они ставить их. | |||
Поля Bugs и Notes (в бодхи) - это вся инфа, которая доступна юзерам при просмотре обновлений в PackageKit (но не %changelog в rpm). | |||
Надо иметь в виду, что слишком подробное описание может быть столь же бессмысленно, как слишком короткое. | |||
Мантайнер должен иметь в виду, что не все пользователи Fedora имеют хороший канал в Интернет. |
Latest revision as of 12:41, 12 January 2011
Предисловие
Этот конспект я вел исключительно для собственных нужд. Поэтому этот текст не является руководством, это необходимо понять прежде всего - это краткий конспект. Вместо любых разъяснений даны ссылки на исчерпывающие материалы по теме, которые обновляются, как и принято в комьюнити, более сведущими специалистами. В этом тескте также нет правильных переводов терминов.
Конспект написан по причине того, что в федора-вики много информации по теме, и, вместе с тем, некоторые особенности освещены слабо. По крайней мере, это вызвало у меня, как у ньюба, затруднения. Но, в целом, повторюсь, информации по данной теме в федора-вики много, англоязычной, естественно.
Автор выражает надежду, что изложенная информация будет полезна для успешного старта.
--Tim4dev 13:50, 6 November 2009 (UTC)
Начало
Источники:
- Join the package collection maintainers
- How to create an RPM package
- Building Packages Guide
- Packaging:Guidelines
- Packaging:NamingGuidelines
- New package process for existing contributors
Дополнительно
- When Sally met Eddie: The Fedora package story
- CVS access for package maintainers
- Using CVS FAQ for package maintainers
- Использование ssh-agent от SSH1 и OpenSSH
Перво-наперво посмотреть нет ли уже такого пакета в :
- Fedora Package Database
- в списке Review Request
- а также в списке https://bugzilla.rpmfusion.org/ (прим. авт.: я так "накололся" с mocp - "изобрел" spec, который уже был на ревью в rpmfusion)
Можно взять спек от похожей проги (а лучше несколько)
$ yumdownloader --source sourcepackage-name
Настройка системы
# yum groupinstall "Development Tools" # yum install rpmdevtools
Создать отдельного юзера под которым будут собираться пакеты:
# /usr/sbin/useradd makerpm
Создать дерево каталогов, необходимое для сборки
$ rpmdev-setuptree
Имена
Допустимые символы для именования пакета
a--z A--Z 0--9 -._+
При присвоении имен пакетов для Fedora, мантайнеру необходимо использовать -
в качестве разделителя для названия частей. Мантайнер **НЕ** должен юзать _ + .
в качестве разделителя.
Имя spec файла по схеме : %{имя пакета}.spec
. Если имя пакета foo-1.0.0-1.src.rpm, то имя spec файла д.б. foo.spec
%{номер версии}
не нужно писать в имени spec файла.
Поле Version
в спеке должно быть.
release number
(или в старых доках vepoch) начинается с 1. При незначительных изменениях он увеличивается на 1.
При значительных изменениях увеличивается version number
и release number
опять начинается с 1.
См. также Packaging:DistTag.
Pre-Release
Release Tag для Pre-Release Packages:
0.%{X}.%{alphatag}
где %{X} - release number (увеличивается на 1), %{alphatag} строка из версии.
Пример для release candidate 1
#define alphatag rc1
См. также Software release life cycle для общего развития.
Snapshot packages
Нумеруются как Pre-Release packages
0.%{X}.%{alphatag}
где %{X} это release number (увеличивается на 1), %{alphatag} начинается в формате YYYYMMDD и далее, например, хэш Git.
Создание SPEC
См. также :
- RPM Guide (by Eric Foster-Johnson)
- Red Hat RPM Guide - русский перевод (Влад Горелецкий)
- Сборка пакетов. Глава 1. RPM. Часть 2. Подготовка к сборке и обзор spec-файла
Создаем заготовку
$ cd ~/rpmbuild/SPECS $ rpmdev-newspec program $ vi program.spec
Далее см. Spec file pieces explained
Вывести список наименований групп софта (поле Group спека)
less /usr/share/doc/rpm-4.6.1/GROUPS
или
LANG=C; yum grouplist
Смотреть какие пакеты входят в группу, например "System Tools" :
yum groupinfo "System Tools"
Чтобы посмотреть, как разворачивается макрос %makeinstall
rpm --eval '%makeinstall'
Или любой другой макрос для определенного спека, например
rpmbuild -E '%{_bindir}' myfile.spec
секция %install
Команды этой секции копируют файлы из "build directory" %{_builddir}, обычно это
~/rpmbuild/BUILD/something # пример ~/src/BUILD
в %{buildroot}, обычно это
/var/tmp/something # пример ~/src/BUILDROOT/%{name}-%{version}-%{release}.i386
и создают подкаталоги в %{buildroot} если нужно.
Сборка
Быстрое тестирование:
rpmlint program.spec
Сборка
rpmbuild -ba program.spec
Это будет попытка выполнить следующие этапы:
- %prep (preparation) этап подготовки. Распаковка и установка исходников и патчей в %_builddir (подкаталог ~/rpmbuild/BUILD)
- %build этап, компиляция файлов, которые будут установлены в _builddir%. Обычно это какой-то эквивалент "make".
- %install этап, копирование файлов из %_builddir (который подкаталог ~/rpmbuild/BUILD) в каталог %{buildroot}. Каталог buildroot ранее установлен в "BuildRoot:"; если вы оставите его в обычном значении начинающемся %{_tmppath}/%{name}..., то buildroot будет внутри /var/tmp.
- создание бинарного и source RPM пакетов (.rpm и .src.rpm). Бинарный RPM создается с использованием информации из %files файлов.
Если что-то пошло не так, вы можете перейти в соответствующий каталог и посмотреть, что осталось. Если вы хотите пропустить более ранние стадии установки советуем использовать опцию "--short-circuit". Это удобно, если у вас была успешна стадия build, но есть ошибка в %install секции.
Например:
$ rpmbuild -bi --short-circuit program.spec
Тестирование
Смотреть список файлов
rpmls *.rpm
Тест
$ rpmlint <имя>.rpm # или $ rpmlint -i <имя>.rpm webacula.noarch: E: htaccess-file /usr/share/webacula/html/.htaccess webacula.noarch: W: dangling-symlink /usr/share/webacula/library/Zend /usr/share/php/Zend webacula.noarch: E: executable-marked-as-config-file /etc/cron.daily/webacula_clean_tmp.sh webacula.noarch: W: file-not-utf8 /usr/share/doc/webacula-3.2.1/INSTALL.es webacula.noarch: E: zero-length /usr/share/webacula/application/views/scripts/index/index.phtml
Просмотреть инфу по ошибке, например
$ rpmlint -I htaccess-file htaccess-file: You have individual apache configuration .htaccess file(s) in your package. Replace them by a central configuration file in /etc/, according to the web application packaging policy for your distribution.
Если все ок, то установите пакет
rpm -ivp [package].rpm rpm -e [package]
Сбока под mock. Вы д.б. в группе mock
$ cd ~/src/SRPMS $ mock -r fedora-11-i386 rebuild webacula-3.2.1-1.fc10.src.rpm
Прим. mock скачивает файлы в /var/lib/mock
Какие типичные ошибки можно сделать, даже хорошо подготовившись, см. мой Review Request.
koji
Если mock отработал ок, то сборка под koji. Настройка koji описана здесь: Using the Koji build system, Join the package collection maintainers
Сгенерить сертификат Fedora Account System.
Сохранить его под именем ~/.fedora.cert
, запустить
$ fedora-packager-setup
Теперь можно логиниться в Koji Build System
$ koji build --scratch dist-f11 webacula-3.2.1-1.fc10.src.rpm
При этом на странице https://koji.fedoraproject.org/koji/ будет виден прогресс и логи.
Review Request
Для примера см. мой Review Request.
Обязательно подписаться на fedora-devel-announce@redhat.com
Также можно подписаться на fedora-devel-list@redhat.com
Получить помощь можно также на канале #fedora-devel на freenode.
Разместить свой SRPM и SPEC файлы где-нибудь в инете.
Создать "Review Request" заполнив форму.
Объяснить в поле 'Review Description', что это первый пакет и нужен поручитель: That this is my first package and I need a sponsor.
В поле Blocks указать баг FE-NEEDSPONSOR
.
См. также How to get sponsored
Потенциальные поручители просматривают FE-NEEDSPONSOR баг в багзилле.
Кто-нибудь рассмотрит ваш пакет. Пока нет рецензента (поручителя) флаг fedora-review flag
будет пуст.
fedora-review flag будет установлен в +, когда пакет пройдет рассмотрение.
См. также Definitions for fedora-review Flag Settings
Подробнее процесс описан в Package Review Process
Я искал поручителя на irc-каналах в т.ч. русскоязычных.
Спонсор
Когда Review Request одобрен рецензентом (reviewer), надо найти спонсора (sponsor).
CVS
После успешного завершения фазы Review Request надо выполнить CVS admin requests
В том же сам баге установить флаг fedora-cvs в ? и в каменте описать по шаблону
New Package CVS Request ======================= Package Name: webacula Short Description: Webacula - Web Bacula - web interface of a Bacula backup system Owners: tim4dev Branches: F-11 F-12 EL-5 InitialCC:
Смотреть очередь запросов на CVS
Пришли письма от From: Fedora PackageDB <pkgdb@fedoraproject.org>
:
kevin added a Fedora 12 branch for webacula kevin added a Fedora 11 branch for webacula kevin added a Fedora EPEL 5 branch for webacula /pkgdb/packages/name/webacula
Теперь нужно импортировать пакет в CVS.
Импорт в CVS
Создать отдельный каталог
mkdir webacula.cvs
Можно запустить ssh-add прежде чем делать любые операции в CVS. Это спасет вас от необходимости вводить пароль ключа для каждой операции. Пароль будет запомнен до завершения сеанса или перезагрузки.
ssh-add fedora-cvs webacula cd webacula ./common/cvs-import.sh PATH_TO_SRPM
Шаг. 9 Импорт вашего srpm
Правильнее так (см. также New Package Process, п.9):
./common/cvs-import.sh -m "Initial import (#nnnnnn)." nameofmy.src.rpm
где nnnnnn номер вашего package-review-бага в Bugzilla.
Это будет импорт в ветку devel
Исходный тарбол не хранится в CVS, а находится где-то в другом месте.
Вы также захотите сделать дополнительный импорт, например,
./common/cvs-import.sh -m "Initial import (#nnnnnn)." -b F-11 PATH_TO_SRPM
где nnnnnn номер вашего package-review-бага в Bugzilla.
cd devel cvs update
Шаг. 10 Теперь надо импортировать ваш пакет в остальные бранчи.
Самый быстрый способ - скопировать ваш .spec, патчи из devel/ в каждый бранч.
Проверьте наличие Makefile и скопируйте его, если необходимо. После этого
cvs add cvs commit
build
Шаг. 11 Сделать тэг для ваших веток. Перед тем как бранч будет построен в Fedora Package buildsystem, файлы в нем д.б. тэгированы. Когда вы успешно сделали все коммиты в каждом бранче, идите в каталог бранча и
make tag
Вы должны увидеть тег ветки с версией и релизом из spec-файла. Вам необходимо тэгировать все бранчи, которые вы хотите построить. Если вы только что импортировали SRPM, то вам не нужно делать тэги, cvs-import.sh сделает это за вас.
Шаг 12. Запрос на builds
См. также про koji
Для каждого тэгированного бранча для которого вы хотите запросить build, идите в каталог бранча (например, cd F-11/) и запустите:
make build
Если все пойдет хорошо, то бранч должен стать в очередь билдинга, пакет будет построен, и все готово!
Если пакет не построился, сборочная система отправит вам емайл, чтобы сообщить о неудаче и линк к логам. Закоммитите какие-либо необходимые изменения в CVS, измените в Spec номер релиза, retag бранча, и запросите новый build.
Шаг 13: закройте Bugzilla баг (при условии, что пакет построен успешно). Вы должны закрыть его как NEXTRELEASE.
Шаг 15: Добавьте пакет в comps.xml, если необходимо. Так что он может быть выбран во время установки и включен в группы пакетов которые обрабатывает Yum.
См. также Cvs Faq где есть инструкции для создания новых релизов.
Скопировать spec и файл sources в другие бранчи
cvs add webacula.spec cvs diff -u cvs -m "Initial commit" commit make tag # или, если будет ругаться, что такой тэг уже есть TAG_OPTS=-F make tag # такое не приветствуется, в дальнейшем лучше # изменить номер spec и сделать новый тэг # чисто для проверки, что все в порядке make srpm make build
make update
PackageMaintainers/UpdatingPackageHowTo
Заключительный этап
make update
Будет предложено ввести описание. Укажите
type=newpackage request=testing bugs=<здесь № бага Review Request (цифра)> notes=<укажите описание пакета, скопируйте из %description SPEC-файла>
После сабмита, Bodhi автоматически сделает запрос чтобы ваше обновление было протолкнуто в updates-testing. Если вы считаете, что тестирование не нужно для обновления, вы можете протолкнуть его прямо в стабильный репо обновлений Fedora.
Обратите внимание, что для обновлений безопасности есть несколько иной процесс.
Release Engineer вручную подпишет и протолкнет обновление.
После проталкивания в testing, у людей есть возможность обновлять карму +1/-1 вашего обновления пакета. Если ваше обновление достигает карма 3, оно автоматически будет протолкнуто в stable. Аналогично, если она достигает -3, оно будет автоматически unpushed. Если обновление не получает достаточной обратной связи для автоматического проталкивания в stable, вам придется засабмитить его в качестве финального обновления самого себя. Это можно легко сделать с параметром командной строки, или с веб-интерфейсом.
Затем вы будете уведомлены, когда ваше обновление попадет в stable. Бодхи закроет все тикеты связанные с ошибками и отправит объявление в fedora-package-announce рассылку.
На данный момент, ваше обновление официально выпущено!
Peter Lemenkov: когда выполнят твой запрос и переместят его в updates-testing, то там будет кнопочка "mark as stable"
Bodhi
Вместо "make update" можно юзать bodhi command-line interface или bodhi веб-интерфейс
Смотреть инфу по пакету (примеры)
bodhi --new -R stable -b 529269 -t newpackage -u atorkhov cmospwd-5.0-1.fc12 bodhi -u tim4dev -m webacula-3.3-6.fc11 -m webacula-3.3-6.fc12 bodhi webacula
Окончание
Ч/з 2-е недели пришло письмо
From: updates@fedoraproject.org Subject: [Fedora Update] [old_testing] webacula-3.3-6.fc11 To: tim4dev@fedoraproject.org Date: Fri, 06 Nov 2009 00:00:07 +0000 X-Mailer: TurboMail TurboGears Extension v.2.1 The update for webacula-3.3-6.fc11 has been in 'testing' status for over 2 weeks. This update can be marked as stable after it achieves a karma of 3 or by clicking 'Push to Stable'. This is just a courtesy nagmail. Updates may reside in the testing repository for more than 2 weeks if you deem it necessary. You can submit this update to be pushed to the stable repository by going to the following URL: http://admin.fedoraproject.org/updates/request/stable/webacula-3.3-6.fc11 or by running the following command with the bodhi-client: bodhi -R stable webacula-3.3-6.fc11 ================================================================================ webacula-3.3-6.fc11 ================================================================================ Update ID: FEDORA-2009-10550 Release: Fedora 11 Status: testing Type: newpackage Karma: 1 Notes: Webacula - Web Bacula - web interface of a Bacula backup system. : Supports the run Job, restore all files or selected : files, restore the most recent backup for a client, : restore backup for a client before a specified time, : mount/umount Storages, show scheduled, running and : terminated Jobs and more. Supported languages: : English, French, German, Portuguese Brazil, Russian. Submitter: tim4dev Submitted: 2009-10-16 12:38:47 Comments: tim4dev - 2009-10-16 12:38:49 (karma 0) This update has been submitted for testing tim4dev - 2009-10-20 09:58:09 (karma 1) bodhi - 2009-10-21 00:34:27 (karma 0) This update has been pushed to testing http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10550
Что дальше
Обновлять сопровождаемый пакет: Package_update_HOWTO
Новый пакет
Следующие пакеты добавлять по процедуре: PackageMaintainers/NewPackageProcess
Обновление пакета
Многие пользователи обновляют Fedora автоматически, поэтому крайне важно, чтобы обновление не причинило вреда или система внезапно не перестала работать.
Обновление с багфиксами как правило, должно быть сначала помещено в "testing" и оно затем попадет в "stable" после того, как наберет достаточо кармы в bodhi.
Новый релиз не обязательно должен быть pushed в release ветку. Rawhide является веткой разработки, куда можно проталкивать обновления перед тем как протолкнуть их в release ветку.
Fedora пользователи, которые не обновляются автоматически должны иметь возможность посмотреть (через PackageKit) описание обновлений, прежде чем решить, должны ли они ставить их. Поля Bugs и Notes (в бодхи) - это вся инфа, которая доступна юзерам при просмотре обновлений в PackageKit (но не %changelog в rpm).
Надо иметь в виду, что слишком подробное описание может быть столь же бессмысленно, как слишком короткое. Мантайнер должен иметь в виду, что не все пользователи Fedora имеют хороший канал в Интернет.