openSUSE:构建服务教程
先决条件
您应该对 RPM 以及它们是如何创建的有一个基本的了解。请参阅 打包指南，了解 openSUSE 或其他受支持的打包系统（例如 dpkg）的类似文档。本文档并非旨在替代打包文档，这些文档可以在上述链接中找到。
您应该熟悉您的项目使用的源代码环境。构建服务可以解决一些常见的错误，并在出现故障时尝试引导您。我们有一个 buildservice-mailinglist，它可以作为帮助和建议的来源。但是，最终决定应用哪些补丁、使用哪些编译器标志等，由您来决定。
要求
要充分利用 构建服务，您需要使用您的 openSUSE/SUSE 帐户登录（与 wiki、bugzilla 相同）。如果您还没有帐户，请单击页面顶部的“注册”链接来创建帐户。请记住，如果您有一天更改了密码，您还需要更改~/.oscrc或~/.config/osc/oscrc，如果您未能这样做，并且仍然运行 osc 命令涉及服务器，则在多次尝试使用错误的密码后，用户帐户可能会被阻止。
此外，如果您以普通用户身份启动构建（一个好主意！），您将被要求提供您本地机器的 root 密码。如果您将您的用户添加到/etc/sudoers可以使用以下过程避免这种情况
- 运行以下命令：
sudo /usr/sbin/visudo
- 添加以下行并替换占位符 LOGIN 为您的登录名
LOGIN ALL = NOPASSWD: /usr/bin/build LOGIN ALL = NOPASSWD: /usr/bin/osc
术语
构建服务包含项目（您可以 查看列表）。每个项目包含构建一个或多个软件包（即 RPM/DEB/等）所需的资源。这些资源包括源代码存档、补丁文件、spec 文件等。项目的输出是一个或多个仓库。仓库是一个熟悉的概念：只是一个组织在目录层次结构中的一组 RPM，以及一些索引/元数据文件，使像 zypper 这样的工具可以轻松搜索和解决依赖关系。项目输出的仓库对应于不同的操作系统版本，例如 openSUSE 15.6 等。
就现有的项目而言，有“官方”openSUSE 项目，它们构建标准 openSUSE 发行版中提供的 RPM。 “factory”项目是正在进行的项目，将成为 openSUSE 的下一个版本。还有许多特定领域的项目，例如 Apache 和 network:telephony。最后，每个用户都有一个名为 home:用户名 的“游乐场”项目。
RPM 往往依赖于其他 RPM，并且这些 RPM 通常来自构建服务内的不同项目。这有两个重要的含义。
首先，如果您的软件包在运行时依赖于其他软件包（“Requires”），它通常也会在构建时依赖于它（即“BuildRequires”）。构建服务不会自动搜索并查找构建依赖项（除了您正在构建的标准发行版中包含的内容）。因此，您必须以某种方式告诉构建服务在哪里获取所需的软件包。
其次，一个好的目标是使仓库传递闭合，即仓库中任何软件包的任何依赖项也在仓库中（标准发行版中的软件包除外）。这使得人们更容易安装您的项目提供的 RPM。但这并非必需：用户始终可以使用 搜索界面手动查找这些依赖项。
构建服务提供了几种不同的方法来促进处理这些依赖项。
首先，您可以直接将所需的软件包添加到您的仓库中。如果其他项目没有构建所需的软件包，这当然是您必须采取的方法。通常，这些软件包已经由其他项目构建。考虑重用他们的工作。
第二个选项是链接其他项目的仓库到您的仓库。这称为分层。通过编辑项目的元数据来完成。将其他项目/仓库作为额外的路径添加。这只是将其他仓库添加到构建服务在构建时搜索“BuildRequires”依赖项的列表中。这将允许您的软件包构建成功，解决第一个问题，但完全不解决“传递闭合”目标：用户必须自己获取所需的软件包。但是，当您的项目有多个依赖项到另一个项目时，或者用户可能无论如何都在从这两个仓库中提取时，这是一个不错的选择。
第三个选项称为链接，是一种允许您的项目重用已经存在于另一个项目中的软件包的方式。当您链接一个软件包时，依赖软件包将能够构建，并且该软件包也将出现在您的项目的仓库中，从而解决了这两个问题，而无需复制任何工作。
有两种类型的链接：link 和 aggregate。当您link 时，您可以选择修改软件包的构建方式。您可以添加补丁，并为其他仓库启用构建。您构建的软件包的 RPM 将具有与原始项目构建的软件包不同的构建号。请注意，这可能会给用户带来困惑。实际上，您正在构建一个具有相同名称的不同版本的软件包。
除非您需要修改所需的软件包，否则您应该aggregate 而不是 link。当您aggregate 时，您正在执行“只读”链接。该软件包不会在您的项目中构建；而是，已经构建的软件包从原始项目中复制到您的项目中。因此，相同的 RPM（具有相同的构建号）将出现在两个项目中。对于用户来说，困惑较少，因为 RPM 是相同的。
构建服务会自动检测链接软件包中的更改并触发依赖于它们的软件包的重建。
工作流程
以下步骤概述了创建项目和向其中添加软件包的正常工作流程。当然，在实际示例中，您可能会在某些步骤中失败，并且必须重复执行直到不再失败为止。此大纲只是为了让您了解我们试图实现的目标。
如果可能，我们将向您展示两种不同的方法
第一步 – 登录和一次性本地项目设置
如果您已经拥有 openSUSE 帐户，这将是最简单的步骤。
- Web 客户端：打开 http://build.opensuse.org/ 并使用右上角的登录链接登录。之后，您的主项目可以通过单击您的用户名来访问。
- 命令行：首先，您必须在您的机器上安装命令行客户端。您可以在 openSUSE-Tools 软件下载仓库中找到 osc 包，用于不同的发行版（是的：这也是一个构建服务项目）。使用您最喜欢的软件包管理器安装 osc 包。
假设您正在使用 openSUSE Tumbleweed，则安装 osc 包如下所示
zypper in osc
之后，cd进入您想要用于项目文件的目录。现在，所有熟悉 SVN 的人都会感到“宾至如归”：尝试使用以下命令检出您的主项目
cd <directory_to_contain_project_root> osc checkout home:<username> cd home:<username>
- （请替换
为您的登录名）。
- 系统将提示您输入您的用户名和密码— 之后，osc 将尝试检出您主项目中的软件包并创建一个名为home:
. - 的新目录。您可以编辑文件~/.oscrc或~/.config/osc/oscrc.
- 中的设置
- 如果您输入错误的密码，您需要删除 osc 用于存储密码的整个 api 部分，以便 osc 再次要求输入密码。
- 如果您设置了plaintext_passwd = 0 并删除了 api 部分，osc 将再次要求输入用户名和密码，并将密码以 base64 编码形式存储。虽然可以轻松解码，但不会一目了然。如果您想使用多个构建服务（或使用其他服务而不是 https://api.opensuse.org），请使用 -A 选项。您可以通过设置-A选项中的别名来缩短选项。您还可以编写一个 my_buildservice 脚本，如下所示exec osc -A https://api.my.build.server "$@"
第二步 – 创建和上传软件包
您可以将您的主项目用作“游乐场”，以测试将在一切正常时转移到其他更可见项目的软件包。
- Web 客户端：在右侧单击“主项目”以打开您的主项目，然后单击“用户”并添加您自己作为维护者。之后，在概述 > 软件包选项卡中单击“创建新软件包”。您应该填写以下三个文本字段：“名称”（必需）、“标题”和“描述”。只需将软件包名称用作“名称”，软件包摘要用作“标题”，软件包描述用作“描述”。
- 创建软件包后，转到“源代码”选项卡以添加软件包的文件。您需要上传软件包的源代码和至少一个 spec 文件（请参阅 打包指南）。
- 命令行:
osc meta pkg -e home:<username> <packagename>
osc 将在您最喜欢的编辑器中打开一个模板 xml 文件（基于EDITOR环境变量) 并且您可以添加相同的信息（名称、标题和描述），如上所述。
现在调用
osc co home:<username> <packagename>
要通过命令行添加文件，只需进入项目目录，复制相关文件（通常是 .tar.xz 和支持文件）。
openSUSE RPM 包的构建说明位于 spec 文件中。请参阅 打包指南，了解如何创建它。更简单的方法是从类似的包中复制并修改 spec 文件，或者（如果可用）从 tar 包中复制。准备好文件后，调用
osc add *
这将为下一次提交标记目录中的文件。要提交文件，请调用
osc commit
提交会自动触发构建过程。您可能希望延迟提交，直到在本地成功构建包之后，请参阅下文。
第三步 – 选择构建目标
现在您需要选择您的包应该为哪些发行版（例如 openSUSE 13.1、Ubuntu 14.04 等）构建。
- Web 客户端：转到您项目的“仓库”选项卡，然后单击添加仓库，并选择可用的发行版和架构之一。
- 命令行：发行版与 OBS 中的任何其他项目没有区别。您需要在项目列表中找到正确的项目名称。对于 openSUSE，可以是 openSUSE:Factory、openSUSE:13.1、SUSE:SLE-11:SP3 等。
$ osc ls / ... openSUSE:Factory openSUSE:Factory:ARM openSUSE:Factory:ARM:Live ...
OBS 服务器管理员还可以配置向用户显示公共发行版列表。如果有这样的列表，您可以使用此命令获取它。
$ osc dists
在找到要构建的针对的项目后，获取其仓库列表
$ osc repositories openSUSE:Factory standard x86_64 standard i586 snapshot x86_64 snapshot i586 ports ppc64le ports ppc64 ports ppc ports armv6l ports armv7l ports aarch64 images local images i586 images x86_64
然后通过编辑您的项目元数据将仓库添加到您的项目中
osc meta prj -e home:<username>
并像这样添加仓库
<repository name="openSUSE_Factory"> <path project="openSUSE:Factory" repository="standard" /> <arch>x86_64</arch> <arch>i586</arch> </repository>
repository="standard" 只是为了未来的扩展（仓库的分支）。
第四步 – 构建您的包
提交后或文件更改后，您的包将自动安排进行构建。如果需要重新构建某个必需的包，您的包也会自动重新构建。
如果您需要，也可以手动触发重新构建
osc rebuildpac <project> <package> [<repo> [<arch>]]
使用可选的 <repo> 和 <arch> 参数，可以限制重新构建到特定的仓库或架构。
如果您的项目名为 home:username，您现在可以在 http://download.opensuse.org/repositories/home:/username/ 找到您的项目
在本地构建您的包
有时，在等待构建服务的结果之前，在本地机器上构建您的包可能会更快。osc支持在您的本地硬件支持的情况下，对您的包进行本地构建（在 x86_64 上，您可以为 i586 和 x86_64 构建，在 i586 上仅为 i586）。
确保您拥有最新的源代码
使用osc checkout (osc co）或osc up以确保您拥有最新版本的源代码。
如果这是您从未检出过的项目/包
cd <your_obs_working_dir> osc co <project> <package> cd <project>/<package>
或者现有已检出项目的新的包
cd <your_obs_working_dir>/<project> osc co <package> cd <package>
或者进入现有的包的本地副本并更新
cd <your_obs_working_dir>/<project>/<package> osc up
执行本地构建
osc build <platform> <arch> <specfile> [--clean|--noinit]
例如
~/obs/home:user/my_project/my-package # osc build openSUSE_Leap_42.1 x86_64 my-package.spec
osc将连接到 OBS 仓库服务器并下载所有需要的 RPM 到/var/tmp/osbuild-packagecache/平台/仓库/架构作为缓存目录。如果您想避免网络流量，可以事先从 DVD 或 iso 中使用 RPM 填充缓存。为此，将 RPM 从 DVD 复制到缓存目录。
osc将在/var/tmp/build-root/中创建一个 chroot 环境，并开始构建您的包。如果您只有小的更改，可以使用该选项避免重新创建构建环境--noinit。如果您怀疑您的 chroot 环境已损坏，可以使用该选项触发完全重新构建--clean。您可以配置 chroot 目录；请参阅您的~/.oscrc或~/.config/osc/oscrc文件中提供相同的供应商和标识信息。
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_11.3/openSUSE:Tools.repo
您的本地构建的完整日志文件存储在 /var/tmp/build-root/.build.log 中。
更正本地构建过程中的错误
您需要为 openSUSE 或任何其他发行版编译新包的主要原因是在您的操作系统版本和发行版上断言兼容性，如果您的包尚未为您的操作系统版本和发行版编译。但是，这样您可能会在构建过程中遇到需要修复的新错误。修复错误的 easiest 方法是在构建环境中 chroot 并进行修复。您可以使用 openroot 代替 chroot，以便获得 X11 访问权限和所有必要的目录挂载。
osc chroot openSUSE_12.1 x86_64
或者老式且繁琐
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
依赖关系
如果在构建过程中遇到依赖错误，请添加包含构建依赖项的行，例如
BuildRequires: cmake libkde4-devel
在这种情况下，cmake 和 libkde4-devel 将在构建您的包之前安装。
安装额外的包到构建根
为了调试目的，您可能需要将额外的包安装到您的本地构建根目录以调试和修复与构建相关的问题。这可以通过 ~/.oscrc 文件和变量 extra-pkgs 来完成。例如
extra-pkgs = vim gdb strace valgrind
安装权限
如果您收到如下错误消息
error: Bad exit status from /var/tmp/rpm-tmp.qrRAn2 (%install)
这意味着您的 %install 步骤失败了（并且之前的步骤都成功了）。这可能是因为如果您尝试安装到错误的位置而缺少写入权限。在这种情况下，将以下 make install 命令添加到您的 spec 文件中
make install DESTDIR=%buildroot
将您的工作提交回 OBS
一旦您拥有<package>目录，您想要的方式，使用以下命令将您的工作提交回 OBS。
添加一个新文件到包
osc add
从包中删除一个文件
osc rm
更新 更改日志（即 *.changes）
osc vc
提交您更新的文件回 OBS
osc commit
补丁
尽可能地，尝试在源代码中进行任何更改，而不是修补服务或应用程序。但有时有必要创建一个补丁来包含上游不可用或特定于 SUSE 部署的修复程序。
有几种方法可以创建新的补丁。例如，您可以使用一个简单的工具 diff 或高级工具 quilt。如果源代码在 git 中可用，那么 git 命令行也可以生成一个补丁。
有关补丁的更多信息，请访问 补丁指南。
使用 diff
如果您计划修补一个文件，请在编辑之前将其复制到 .orig，重试构建过程中的所需步骤直到成功，然后为它创建一个补丁。
为了使构建更详细，您可能希望插入一个set -x在您的 spec 文件中，使 bash 朗诵所有执行的命令（set +x之后禁用朗诵）。
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
现在将补丁添加到 spec 文件中，列出Patch67: my.patch（其中 67 通常替换为补丁的最低未占用数字）在标题中。然后在构建过程中将其应用到适当的位置（通常%setup）通过%patch67 -p7（-p7 如果您没有手动编辑补丁文件中的文件目录，则会剥离七个目录级别）。
使用 git --format-patch
如果更改包含在 git 树的头部的一个提交中，则可以通过运行以下命令生成一个补丁
git format-patch HEAD^
这将生成一个文件0001-<提交消息的第一行>.patch。此文件可以包含在 .spec 文件中，如 使用 diff 部分所述。请注意，补丁中的路径将是一级深度，因此使用-p1在 .spec 文件中。
使用 quilt
您可能会发现使用一个特殊的程序来自动生成补丁，例如 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 将自动在父目录中创建。如果您正在处理一个没有补丁的包，请记住将补丁从补丁目录复制到您的包目录。重新运行 quilt setup 以获取初始补丁。您可以使用 quilt pop 从您的工作副本中删除补丁。
一个例子.quiltrc文件
# 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"
第五步：检查日志文件
构建服务为每个包的构建生成一个大日志文件。
- Web 客户端：只需单击包视图中构建结果选项卡的状态即可。
- 命令行：您有几种选择，具体取决于您的需求（
项目和包是可选的，如果您在包目录中）
osc prjresults [<project>]
显示整个项目的聚合构建结果。或者您可以执行
osc results [<project> <package>]
显示单个包的构建结果。
osc buildlog <platform> <arch>
显示包的日志文件（您需要在包目录中）。
创建模式
自 Code12（SLES-12/openSUSE-13.2）以来，我们使用了一种新的模式定义方法，而不是旧的基于 XML 的模式文件。模式及其依赖项现在由一个 rpm 包表示。模式特定的少数属性由这个模式包提供。不再需要额外的 XML 文件。
有关模式包的更多详细信息可以在 这里 和维护 openSUSE 模式的项目 obs://build.opensuse.org/system:install:head/patterns-openSUSE 中找到。
OBSOLETE SINCE SLES-12/openSUSE-13.2：以下部分指的是使用 XML 文件定义模式的旧方法
模式是包含软件包列表以及描述它们用途的文件。此外，构建服务为每个生成的仓库模式创建 .ymp 文件。这些 .ymp 文件可以用于用户进行 一键安装。
简而言之，模式对于安装一组用于典型需求的软件而无需在软件包之间创建依赖关系很有用。
可以使用 api 或 osc 提交模式
- 以在 $EDITOR 中打开模式（如果不存在则创建它）
osc meta pattern -e <project> <pattern>
- 列出现有的模式
osc meta pattern <project>
- 获取现有的模式
osc meta pattern <project> <pattern>
- 您还可以提交现有的文件，如下所示
osc meta pattern --file <local_file> <project> <pattern>
要测试：单击 konqueror 中的 .ymp 应该启动安装程序，如果您没有安装 konqueror，您可以尝试从 shell 作为普通用户启动
/sbin/yast2 MetaPackageHandler http://download.opensuse.org/repositories/<project>/<SUSE_Factory or openSUSE_10.2>/<pattern>.ymp
以下文件是 KDE:KDE4 项目中的示例模式文件。您可以在 这里 找到由此生成的 .ymp 文件。
<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>
一些标签描述
| 标签 | 描述 |
|---|---|
<rpm:requires> <rpm:entry name="example" /> </rpm:requires> |
Requires RPM 示例：必须安装此包 - 否则模式将无法满足。 |
<rpm:recommends> <rpm:entry name="example" /> </rpm:recommends> |
Recommends RPM 示例：如果可用且此包的所有依赖项都已满足，则将安装该包。如果该包不可用，则不会显示错误消息。如果该包的依赖项未满足，则该包将可见但未安装。 |
<rpm:suggests> <rpm:entry name="example" /> </rpm:suggests> |
Suggests RPM 示例：将显示在模式中，但默认情况下不会安装 |
一个从头到尾的简单更改示例
这里的目标是提供一个可以用作教程的特定示例。
一个常见的活动是在现有项目中分支一个现有包，进行更改并将该更改提交回原始包。
基本步骤是
- 分支原始包osc branch <original_project> <original_package>这将创建一个新的分支项目，该项目特定于您，命名为home:<your_user_name>:branches:<original_project_name>其中它会创建一个与原始包同名的新的包，基本上是原始包的副本。
- 检出分支包osc checkout home:<your_user_name>:branches:<original_project_name>/<original_package_name>这将从服务器下载分支包的源代码到名为home:<your_user_name>:branches:<original_project_name>/<original_package_name>
- 进入本地子目录cd home:<your_user_name>:branches:<original_project_name>/<original_package_name>并设置通常的默认 umaskumask 0022
- 处理您本地包的副本，直到它对您有效
- 更改本地源代码文件（例如，编辑 spec 文件或创建一个补丁）
- 执行本地构建
- 进行本地包安装
- 测试本地安装的包
- 更新更改文件osc vc这将打开一个编辑器（通常是“vi”）并创建一个适当的 RPM 更改条目标题。如果有一个错误报告，它必须引用为 bsc#123456
- 如果您添加了新文件（例如，新补丁）或删除了文件（例如，过时的补丁），请更新本地源代码文件的版本控制状态osc addremove并使用osc status验证没有具有有问题版本控制状态的文件，例如“？”或“！”
- 将本地源代码文件提交到分支包osc commit这会将本地源文件上传到服务器上的分支包，并触发分支包的自动重建。
- 检查分支包的构建结果，包括所有为原始包启用的构建仓库。osc results --verbose home:<你的用户名>:branches:<原始项目名称> <原始包名称>要列出为原始包启用的构建仓库并获取其构建结果，请使用：osc results <原始项目> <原始包>
- 如果分支包的重建对于所有为原始包启用的构建仓库都“成功”，则创建一个请求，将分支包提交回原始包。osc submitrequest --message='<描述你所做的更改的简短消息，如果存在匹配的错误报告，请加上 bsc#123456>' home:<你的用户名>:branches:<原始项目名称> <原始包名称> <原始项目> <原始包>并记住请求 ID 号码。
- 不时检查你的请求的状态。osc request show <请求_ID_号码>如果你需要直接联系原始包的维护者：osc maintainer <原始项目> <原始包>会显示他们的用户名，并且osc whois <用户名>会显示 buildservice 用户的全名和电子邮件地址。
这需要几个步骤，但一旦你熟悉了它，就会变得自然而然。
这假定你已经在 OBS 上拥有一个帐户。如果没有，请前往 http://build.opensuse.org/ 设置一个帐户，并使用右上角的登录链接登录。OBS 使用与 openSUSE 基础设施的其他部分（如 bugzilla）相同的身份验证系统，因此你可能已经拥有一个帐户，只需第一次登录即可，OBS 帐户主项目就会自动创建。
这是一个实际例子
命令行的一次性设置
sudo zypper in osc mkdir ~/obs
然后你需要分支一个本地的包副本。
cd ~/obs umask 0022 osc branch security:forensics sleuthkit osc co home:<your_user_name>:branches:security:forensics/sleuthkit cd ~/obs/home:<your_user_name>:branches:security:forensics/sleuthkit
现在你已经有一个现有的包，操作就像这样简单：
# 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
完成测试后，将更改提交回你分支的原始包。
osc sr