openSUSE:Руководство по использованию службы сборки

(перенаправлено с «Служба сборки/Учебное пособие»)
Перейти к: навигация, поиск
Open Build Service
Для пользователей - Для сборщиков - Для разработчиков - Интеграция с KIWI - Установки - Сотрудничество - Сравнение
Другие статьи
Этот документ предоставит краткий обзор Службы Сборки и учебное пособие о том, как собирать пакеты для различных дистрибутивов с помощью этого отличного инструмента. Мы постараемся показать все действия, на примерах работы с приложением, таким образом, что вы сможете, шаг за шагом, научиться создавать собственные пакеты.

Предпосылки

Вы должны четко понимать, что такое RPM и как они создаются. Посмотрите руководство по сборке для openSUSE или схожие материалы для других поддерживаемых службой систем dpkg. Эти документы не являются полноценной заменой для документации по сборке, которая дана по ссылкам выше.

Localize.png Эта статья содержит фрагменты на иностранном языке. Вы можете помочь переведя её до конца. (cм. руководство по переводу)

You should be familiar with the source code environment your project is using for your package. The Build Service can work around some common mistakes and will try to guide you in case of failures. We have a buildservice-mailinglist which can be a source of help and advice. However, decisions on which patches to apply, what compiler flags to use, etc. are ultimately up to you.

Требования

Для полноценного использования службы сборки, вам нужно войти в систему под вашим аккаунтом openSUSE/SUSE (одинаков для wiki, bugzilla...). Если у вас еще нет аккаунта, нажмите ссылку "sign in (регистрация)" вверху страницы, чтобы получить его. Помните, что если однажды вы смените свой пароль, нужно так же сменить ~/.oscrc, не сделай вы этого и выполнив osc команды работающие с сервером, ваш аккаунт может быть заблокирован после нескольких повторных попыток войти с неверным паролем.

Если сборка запущена под обычным пользователем (что, несомненно, является хорошей практикой) будет выдан запрос пароля пользователя root. Этого можно избежать добавив своего пользователя в /etc/sudoers и выполнил следующие действия:

  1. Добавить строку в файл ~/.oscrc: 
    su-wrapper = sudo
  2. Выполнить команду: 
    sudo /usr/sbin/visudo
  3. Добавить следующую строку заменив LOGIN на имя нужного пользователя: 
    LOGIN    ALL = NOPASSWD: /usr/bin/build
LOGIN    ALL = NOPASSWD: /usr/bin/osc

Терминология

The Build Service contains projects (you can view a list of them). Each project contains the resources needed to build one or more packages (i.e. RPMs/DEBs/etc.). These resources include source archives, patch files, spec files, etc. The output of a project is one or more repositories. A repository is an old familiar concept: simply a bunch of RPMs organized in a directory hierarchy along with some index/meta-data files that make it easy for tools like zypper to search and resolve dependencies. The repositories a project outputs correspond to the different operating system versions such as openSUSE 11.2, etc.

As far as the projects that exist, there are "official" openSUSE projects that build the RPMs provided in the standard openSUSE distributions. The "factory" project is the work-in-progress project that will become the next version of openSUSE. There are also lots of area-specific projects such as Apache and network:telephony. Finally, each user has his own "playground" project named home:username.

RPMs tend to have lots of dependencies on other RPMs, and often these RPMs come from different projects within the Build Service. This has two important implications.

First, if your package depends on some other package at runtime ("Requires"), it will often also depend on it at build time (i.e., "BuildRequires"). The Build Service does not automatically go search and find build dependencies for you (other than what is included in the standard distribution you are building for). So somehow you have to tell the Build Service where to get the required package.

Secondly, a nice goal is for a repository to be transitively closed, i.e. any dependency of any package in the repository is also in the repository (packages in the standard distribution excepted). This makes life easier for people installing the RPMs your project provides. But this is not required: users can always find these dependencies manually using the search interface.

The Build Service provides a few different ways to facilitate handling of these dependencies.

First, you can directly add the required package(s) to your repository. This is certainly the approach you must take if no other project builds the required packages. Typically though, those packages are already being built by some other project. Consider re-using their work.

The second option is to link the other project's repository to your repository. This is called layering. It is done by editing the meta-data of your project. Add the other project/repository as an additional path. This simply adds to the list of repositories in which the Build Service will search for "BuildRequires" dependencies at build time. This will allow your package's build to succeed, addressing the first problem, but it does not address the "transitively closed" goal at all: users will have to go fetch the required package themselves. However, this is a good choice when there are several dependencies from your project into another project and/or users are likely to be pulling from both repositories anyway.

The third option is called linking and is a way to allow your project to re-use a package that already exists in another project. When you link a package into your project, dependent packages will be able to build, and the package will also appear your project's repository, therefore solving both problems without duplicating any work.

There are two types of linking: link and aggregate. When you link, you can optionally modify the way the package is built. You can add patches, and enable the build for additional repositories. Your build of the package's RPM will have a different build number from the original project's build of it. Note, this could cause confusion for users. Really, you are building a different version of a package with the same name.

Unless you need to modify the required package, you should aggregate instead of link. When you aggregate, you are performing a "read-only" link. The package is not built within your project; instead, the already-built package is copied into your project from the original project. So the same RPM (with the same build number) will appear in both projects. For the user, there is less confusion because the RPMs are identical.

The Build Service automatically detects changes in linked packages and triggers rebuilds of any packages depending on them.

В добрый путь

Следующие шаги описывают нормальный рабочий процесс создания проекта и добавления пакетов к нему. Конечно, в некоторых случаях, вы можете потерпеть неудачу. Тогда придётся повторить шаги, вызвавшие затруднения, выявить причины сбоя и завершить начатое. Эта схема просто даст вам представление того, чего мы пытаемся достичь.

Мы покажем вам, если это возможно, два различных способа достижения цели:

  • используя веб-клиент Web client
  • и приложение командной строки Command line
  • Альтернативным методом является использование клиента MonoOSC. Учебник уже существует здесь, поэтому нет необходимости его дублировать.

Шаг 1 — вход и первоначальная настройка (единоразовая) локального проекта

Если у вас уже есть аккаунт openSUSE, то это самый простой шаг.

  • Веб-клиент: Откройте http://build.opensuse.org/ и используйте ссылку "Login" в правом верхнем углу для входа. После этого, перейдите в ваш домашний проект, нажав на "Home Project".
  • Командная строка:

Во-первых, вам придётся установить клиент командной строки на компьютер. Вы можете найти пакет osc для различных дистрибутивов в хранилище программного обеспечения для скачивания OpenSUSE-Tools (да: это тоже проект Службы Сборки). Используйте ваш любимый менеджер пакетов, чтобы установить пакет osc.

После этого, выполните переход командой cd в каталог, что хотите использовать для файлов вашего проекта. Теперь каждый, кто знаком с SVN будет чувствовать себя «как дома». Попробуйте сделать запрос вашего домашнего проекта с использованием команд 

 cd <основной_каталог_проекта>
 osc checkout home:<имя_пользователя>
 cd home:<имя_пользователя>
(пожалуйста, замените <имя_пользователя> вашим логином). Вам будет предложено ввести логин и пароль. После чего, osc постарается запросить пакеты, находящиеся в вашем домашнем проекте и создать новый каталог, который будет называться home:<имя_пользователя>. Вы можете изменить настройки в файле ~/.oscrc.

Шаг 2 — создание пакета и загрузка файлов пакета

Вы можете использовать свой домашний проект как "площадку" для тестирования пакетов, которые будут переведены, если всё в порядке, на другие, более заметные проекты.

  • Веб-клиент: Нажмите на "Home Project", чтобы открыть домашний проект, а затем нажмите на кнопку "Create package" на вкладке "Packages". Вы должны будете заполнить следующие три текстовых поля: "Name (Имя)" (обязательно), "Title (Заголовок)" и "Description (Описание)". Просто используйте имя пакета, как "Имя", краткое содержание в качестве "Заголовка" и описание пакета, как "Описание".

После того, как пакет создан, перейдите на вкладку "Source Files (Исходные файлы)", чтобы добавить файлы для вашего пакета. Вам нужно загрузить, по меньшей мере, исходный код пакета и файл спецификации (см. также openSUSE:Packaging_guidelines).

  • Командная строка:
osc meta pkg -e home:<имя_пользователя> <имя_пакета>

osc откроет файл шаблон в формате XML в вашем любимом редакторе, заданном в переменной окружения EDITOR, и вы сможете просто добавить, в точности как описано выше - Имя, Заголовок и Описание.

Теперь вызовите 

osc up home:<username>

для того, чтобы создать каталог с названием совпадающим с именем нового пакета. Для добавления файлов с помощью командной строки, просто перейдите в новый каталог командой cd, скопируйте соответствующие файлы с исходным кодом (обычно .tar.xz и других поддерживаемых форматов) и файл спецификации.

RPM-пакеты openSUSE имеют свои инструкции по сборке, записанные в файле спецификации. См. packaging guidelines, как создать такой файл. Простой подход - это скопировать и адаптировать файл спецификации от аналогичного пакета, или из tar-архива, если таковой файл в нём имеется. Когда файлы готовы, вызовите 

osc add *

это будет означать, что файлы добавлены в каталог для последующей отправки. Чтобы отправить файлы, вызовите 

osc commit

Эта команда автоматически запускает процесс сборки. Вы можете отложить запуск процесса сборки до тех пор, пока успешно не построите пакет локально, см. ниже.

Шаг 3 — выбор целей сборки

Теперь вы должны выбрать для каких дистрибутивов (например: openSUSE 11.3, Ubuntu 10.04 и т.д.) будут построены ваши пакеты.

  • Веб-клиент: Зайдите в раздел "Repositories (Репозитории)" вашего проекта, нажмите на кнопку "Add repositories (Добавить репозитории)" и выберите один из доступных дистрибутивов, и архитектур.
  • Командная строка: сначала нужно получить список доступных репозиториев
osc ls

затем редактировать метаданные проекта: 

osc meta prj -e home:<имя_пользователя>

и добавить репозиторий, так: 

 <repository name="openSUSE_Factory">
   <path project="openSUSE:Factory" repository="standard" />
   <arch>x86_64</arch>
   <arch>i586</arch>
 </repository>

project может быть openSUSE:Factory, openSUSE:11.3, SUSE:SLE-11:SP1 и тому подобные. repository="standard" только для будущих расширений (ответвлений от репозитория).

Шаг 4 — сборка вашего пакета

После отправки ваш пакет становится в очередь на автоматическую сборку. Если какой-либо зависимый пакет пересобирается, ваш пакет также будет пересобран автоматически.

Вы также можете собрать пакет вручную, если возникнет необходимость: 

osc rebuildpac <project> <package> [<repo> [<arch>]]

С помощью аргументов <repo> и <arch>, сборку можно ограничить определенной архитектурой и репозиториями.

Если ваш проект называется home:<имя_пользователя>, его можно найти по адресу http://download.opensuse.org/repositories/home:/имя_пользователя/

Локальная сборка пакетов

В некоторых случаях, собрать пакет на локальной машине будет быстрее, чем ждать результат от службы сборки. osc поддерживает локальную сборку, если это позволяет ваше оборудование (на системах x86_64 вы можете собрать пакеты для i586 и x86_64, на i586 системах только для i586).

Обязательно проверьте существование изменений

Используйте osc checkout (osc co) или osc up для получения свежих версий исходного кода.

Нет никакой необходимости в получении копии всех пакетов проекта: 

cd <your_obs_working_dir>;
osc co <project> <package>

или 

cd <your_obs_working_dir>/<project>;
osc co <package>

или 

cd <your_obs_working_dir>/<project>/<package>;
osc up
Выполнение локальной сборки
 osc build <platform> <arch> <specfile> [--clean|--noinit]

Например: 

~/obs/home:user/project # osc build openSUSE_15.4 x86_64 project.spec

osc соединится с репозиторием OBS и загрузит все нужные RPM-пакеты в директории /var/tmp/osbuild-packagecache/plattform/repository/arch, используемой в качестве кеша. Для минимизации сетевого трафика допускается заранее заполнить кеш пакетами с DVD или iso-образа. Для этого просто скопируйте нужные пакеты.

Например, для репозитория openSUSE_15.4 воспользуемся образом DVD-диска: 

 mount openSUSE-15.4.iso /mnt/ -o loop
 mkdir -p /var/tmp/osbuild-packagecache/openSUSE\:15.4/standard
 cp -r /mnt/suse/* /var/tmp/osbuild-packagecache/openSUSE:15.4/standard

Далее исправим права доступа (файлы на DVD не доступны для записи, но osc необходимы права на запись данных в кеше): 

 find /var/tmp/osbuild-packagecache/openSUSE:15.4 -type d -exec chmod 755 {} \;
 find /var/tmp/osbuild-packagecache/openSUSE:15.4 -type f -exec chmod 644 {} \;

С помощью подобной команды можно запустить локальную сборку: 

 osc build openSUSE_15.4 i586 <some-package-name>.spec

osc создаст chroot-окружение в /var/tmp/build-root/ и запустит сборку пакета. При внесении небольших изменений можно пропустить этап повторного создания сборочного окружения указ флаг --noinit. Для принудительного пересоздания сборочной среды укажите флаг --clean. Каталог chroot-окружения задается в конфигурационном файле, подробности можно узнать из комментариев в файле ~/.oscrc.

osc откажется устанавливать пакеты из не доверенных проектов. Такой вариант возможен при использовании для сборки пакетов из проектов разработки (development project), но система ничего не знает про них. Чтобы это исправить нужно получить GPG-ключ выполнив команду:

sudo rpm --import - <<_END_KEY
$(osc signkey offending-project)
_END_KEY

После завершения сборки пакета в chroot-окружении его можно найти в каталоге /var/tmp/build-root/home/abuild/rpmbuild/RPMS/ (у старых версий rpmbuild для этой цели использовался каталог /usr/src/packages/RPMS/).

Если в пакете используется служба получения архива с исходным кодом по указанному URL, то сначала нужно выполнить следующую команду: 

zypper ar -r http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_15.4/openSUSE:Tools.repo

Полный журнал сборки находится в файле /var/tmp/build-root/.build.log.

Correct Errors in the Local Build Process

The main reason why you would need to compile a new package for openSUSE or any other distro is to assert compatibility if your package has not yet been compiled for your operating system version and release. However, that way you may encounter new errors in the build process which need to be fixed. The easiest way to fix errors is to chroot to the build environment and create a fix there. You may want to use openroot instead of chroot in order to get X11 access and all the other necessary directories mounted. 

 osc chroot openSUSE_12.1 x86_64

or old-fashioned and cumbersome 

 chroot /var/tmp/build-root/
 cd /home/abuild/rpmbuild/BUILD/your-package-dir
 ls
 or:
 openroot /var/tmp/build-root/ 'cd /home/abuild/rpmbuild/ILD/your-package-dir; ls; bash'
 ...
 exit
Зависимости

При получении ошибки неудовлетворенной зависимости добавьте строку с этими пакетоми в spec-файл, например: 

BuildRequires: cmake libkde4-devel

В данном случае, пакеты cmake и libkde4-devel будут установлены заранее, до начала сборки.

Install extra packages to build root

For debugging purposes, you might need to install extra packages to your local build root to debug and fix build related problems. This can be done through the ~/.oscrc file and variable extra-pkgs. For example: 

extra-pkgs = vim gdb strace valgrind
install privileges

If you get an error message like this: 

error: Bad exit status from /var/tmp/rpm-tmp.qrRAn2 (%install)

this means that your %install step has failed (and all others before went well). This can be because of missing write privileges if you try to install to the wrong place. In this case add the following make install command to your spec file: 

make install DESTDIR=%buildroot
submit your work back to OBS

Once you have your <package> directory the way you want it, use the below commands to submit your work back to OBS.

add a new file to the package 

osc add

remove a file from the package 

osc rm

update the change log (ie. *.changes) 

osc vc

submit your updated files back to OBS 

osc commit

Patches

If you plan to patch a file copy it before editing to .orig, retry the desired step in the build process until it succeeds and then create a patch for it. To make the build more verbose you may want to insert a "set -x" in your specfile making bash recite all executed commands (set +x disables reciting afterwards). 

diff -Pdpru /var/tmp/build-root/home/abuild/rpmbuild/BUILD/your-package-dir/Makefile.orig \
               /var/tmp/build-root/home/abuild/rpmbuild/BUILD/your-package-dir/Makefile \
               >/osc/home:user/your-package-dir/my.patch

Now add the patch to the .spec-file by listing "Patch67: my.patch" in the header and then let it be applied at the appropriate position (usually %setup) in the build process by "%patch67 -p7" (-p7 strips seven directory levels if you have not manually edited the file directories in the header of the patch file.).

You may find it easier to use a special program for automatic patch generation like quilt: 

osc co yourproject/yourpackage
cd yourproject/yourpackage
quilt setup -v *spec
cd yourpackage-*/
quilt push -a # apply old patches
quilt new yourpackage-version_fixbuild.patch
quilt edit src/foo.c
quilt refresh

foo-fixbuild.patch will automatically be created in the parent dir. If you work on a package which doesnt have a patch yet. You have to remember to copy the patch from the patch directory to your package directory. Rerun quilt setup to get an initial patch. You can remove patches from your working copy with quilt pop.

An examplery .quiltrc file: 

# Options passed to GNU diff when generating patches
QUILT_DIFF_OPTS="--show-c-function" 
# QUILT_DIFF_OPTS="" 
# Options passed to GNU patch when applying patches
#QUILT_PATCH_OPTS="--ignore-whitespace --unified-reject" 

# Options to pass to commands (QUILT_${COMMAND}_ARGS)
QUILT_PUSH_ARGS="--color=auto" 
QUILT_DIFF_ARGS="--color=auto" 
QUILT_REFRESH_ARGS="--backup -p0"
QUILT_PATCH_OPTS="--unified-reject-files --backup"

Шаг 5 — проверка журнальных файлов

The buildservice produces one big logfile for each build of a package.

  • Web client: Just click on the status of the Build result tab in the package view.
  • Command line: You have a few choices depending on your needs (packagedir is optional if you are in the package directory):
osc prjresults [packagedir]

Shows the aggregated build results of an entire project. Or you can do: 

osc results [packagedir]

Shows the build results of a single package. 

osc buildlog <platform> <arch>

Shows the log file from a package (you need to be inside a package directory).

Create Patterns

Patterns are files which contain a list of packages together with a description of what they are useful for. Additionally the Build Service creates .ymp files for each generated repository pattern. These .ymp files can be used for a One Click Install by the user.

In short, patterns are useful for installing a set of software for a typical need without creating dependencies between packages.

Submitting patterns is possible using the api directly, or using osc:

  • to open a pattern in $EDITOR (creating it if it doesn't exist yet)
osc meta pattern -e <project> <pattern>
  • to list existing patterns
osc meta pattern <project>
  • get an existing pattern
osc meta pattern <project> <pattern>
  • You can also submit an existing file as below:
osc meta pattern --file <local_file> <project> <pattern>

To test: clicking on the .ymp in konqueror should launch the installer, if you do not have konqueror installed, you can try launching from shell as normal user: 

/sbin/yast2 MetaPackageHandler http://download.opensuse.org/repositories/<project>/<SUSE_Factory or openSUSE_10.2>/<pattern>.ymp

The following file is an example pattern file from the KDE:KDE4 project. You can see the generated .ymp file from it here. 

<pattern
 xmlns="http://novell.com/package/metadata/suse/pattern"
 xmlns:rpm="http://linux.duke.edu/metadata/rpm"
>
    <name>KDE 4 Games</name>
    <summary>KDE 4 Games</summary>
    <description>A number of games for KDE 4.</description>
    <uservisible/>
    <category lang="en">Desktop Functions</category>
    <rpm:recommends>
      <rpm:entry name="kde4-kpat"/>
      <rpm:entry name="kde4-kmahjongg"/>
      <rpm:entry name="kde4-kmines"/>
      <rpm:entry name="kde4-kreversi"/>
      <rpm:entry name="kde4-ksudoku"/>
    </rpm:recommends>
    <rpm:suggests>
      <rpm:entry name="kde4-katomic"/>
      <rpm:entry name="kde4-kbattleship"/>
      <rpm:entry name="kde4-ksquares"/>
      <rpm:entry name="kde4-bovo"/>
      <rpm:entry name="kde4-kiriki"/>
      <rpm:entry name="kde4-kwin4"/>
      <rpm:entry name="kde4-kolf"/>
      <rpm:entry name="kde4-klines"/>
      <rpm:entry name="kde4-ksame"/>
      <rpm:entry name="kde4-lskat"/>
      <rpm:entry name="kde4-kgoldrunner"/>
      <rpm:entry name="kde4-kblackbox"/>
      <rpm:entry name="kde4-kbounce"/>
      <rpm:entry name="kde4-ktuberling"/>
      <rpm:entry name="kde4-knetwalk"/>
      <rpm:entry name="kde4-kjumpingcube"/>
      <rpm:entry name="kde4-kspaceduel"/>
      <rpm:entry name="kde4-konquest"/>
      <rpm:entry name="kde4-kshisen"/>
    </rpm:suggests>
</pattern>

Some Tag descriptions:

Tag Description 
<rpm:requires>
<rpm:entry name="example" />
</rpm:requires>
 Requires RPM example: this package must be installed - otherwise the pattern is not fulfilled. 
<rpm:recommends>
<rpm:entry name="example" />
</rpm:recommends>
 Recommends RPM example: if available and all dependencies of this package are fulfilled, the package would be installed. If the package is not available, there are not error messages. If the package dependencies are not met, the package would be visible but not installed. 
<rpm:suggests>
<rpm:entry name="example" />
</rpm:suggests>
 Suggests RPM example: would be shown in the pattern but not installed per default

A start to end example of a simple change

Note: There are at least two other wiki pages that document the branch/fix/submit patch workflow:

The goal here is to have a specific example that can be used as a tutorial.

Внимание: Всё нижеописанное не закончено или не испытывалось

A common activity is to branch an existing package in an existing project, make a change and submit that change back to the original package.

The basic steps are:

  1. Branch the original package: "osc branch <original_project> <original_package>" This creates a new branch project that is specific for you named home:<your_user_name>:branches:<original_project_name> and therein it creates a new package with the same name as original package that is basically a copy of the original package.
  2. Checkout the branched package: "osc checkout home:<your_user_name>:branches:<original_project_name>/<original_package_name>" This downloads the source files of the branched package from the server into a local sub-directory named home:<your_user_name>:branches:<original_project_name>/<original_package_name>
  3. Go to the local sub-directory: "cd home:<your_user_name>:branches:<original_project_name>/<original_package_name>" and set the usual default umask "umask 0022"
  4. Work on your local copy of the package until it works for you:
    1. Change the local source files (e.g. edit the specfile or create a patch)
    2. Perform a local build
    3. Do a local package installation
    4. Test the local installed package
  5. Update the changes file: "osc vc" This opens an editor (usually 'vi') and creates an appropriate header for a RPM changes entry. If there was a bug report it must be referenced as bnc#123456
  6. If you added new files (e.g. new patches) or removed files (e.g. obsolete patches), update the version control status of the local source files: "osc addremove" and verify with "osc status" that there are no files with problematic version control status like '?' or '!'
  7. Commit the local source files into the branched package: "osc commit" This uploads the local source files into the branched package on the server and that triggers an automated re-build of the branched package.
  8. Review the build results of the branched package for all build repositories that are enabled for the original package: "osc results --verbose home:<your_user_name>:branches:<original_project_name> <original_package_name>" To list the build repositories that are enabled for the original package get its build results: "osc results <original_project> <original_package>"
  9. If the re-build of the branched package "succeeded" for all build repositories that are enabled for the original package, create a request to submit the branched package back to the original package: "osc submitrequest --message='<a short message that describes what you changed plus bnc#123456 if there exists a matching bug report>' home:<your_user_name>:branches:<original_project_name> <original_package_name> <original_project> <original_package>" and remenber the request ID number.
  10. From time to time check what happened with your request: "osc request show <request_ID_number>" If you need to get in direct contact with the maintainers of the original package: "osc maintainer <original_project> <original_package>" shows their user names and "osc whois <user_name>" shows fullname and email of a buildservice user.

It's a few steps, but once you get a hang on it, it becomes second nature.

This assumes you already have an account on OBS. If not, go ahead and set that up at http://build.opensuse.org/ and use the login link on the upper right to login. OBS uses the same authentication system as the rest of the openSUSE infrastructure like bugzilla, so you likely all ready have a account, you just need to login for the first time and the OBS account home project will be automatically created.

Here's a real example:

One time setup from the command line 

sudo zypper in osc
mkdir ~/obs

Then you need to branch a local copy of a package. 

cd ~/obs
umask 0022
osc branch security sleuthkit
osc co home:<your_user_name>:branches:security/sleuthkit
cd ~/obs/home:<your_user_name>:branches:security/sleuthkit

Now that you an existing package already, it's as easy as: 

# this untars the tarball and does some magic
quilt setup sleuthkit.spec
# chdir to sources
cd sleuthkit-3.2.3
# apply all patches
quilt push -a
# add new patch
quilt new testing.patch
# add a file to the patch
quilt add some-file
vi <some-file>
# or alternatively:
quilt edit <some-file>
# and finally
quilt refresh -p1
# copy the patch up to the project dir
cp patches/testing.patch .. 
# and now handle the spec file
cd ..
vi sleuthkit.spec
# Add patch to it by creating a Patch0 entry in the header area and a %patch0 -p1 line to the %prep section

# tell OBS that the package now includes a new file
osc add testing.patch
# update the changes file
osc vc -m "Fix some typos."
# and build, install and test your work
osc build
# perform a local install.  At the end of the osc build output the full path of the RPM file should be shown
zypper in -f <full_path_to_rpm>
# repeat until happy.  Go back to quilt edit if not happy.
# send your edits back to OBS
osc commit
# wait a period of time for new packages to build on OBS
# check the build status via the WebUI for your branched package
# Once published, install the RPM from OBS and test again
# submit your changes back to the original package.  If there is a bugzilla entry, be sure to reference it

Смотрите также

Источник — «https://ru.opensuse.org/index.php?title=openSUSE:Руководство_по_использованию_службы_сборки&oldid=25138»