openSUSE GNOME

OSC Collaboration 编辑

通过构建服务协同工作的介绍，现在每个人都可以帮忙在openSUSE上打包。拿GNOME来说，开发工作在 GNOME:Factory (G:F) 项目中进行，而且提交到那的软件包而后将要提交到 Factory 分发的地方： openSUSE:Factory (oS:F)。

然而，所有的命令行对于初次使用的用户来说可能有那么点困难，并且一些通用的工作流程能够自动化。这就是我们创建 osc collab 插件的原因。该插件提供3个极其有用的命令：osc collab todo, osc collab update 以及 osc collab setup。一些其他的命令也可用。

注意： osc collab 现在不再特别针对 GNOME 相关的项目，它可以用在 任何其他的项目。它能帮你在项目中组织你的工作！对于高级特性（例如 todo, update, buildsubmit），你可能需要在服务器端设置。

一个典型的工作流程示例

首先，让我们看一下对于 GNOME:Factory 项目能做什么（示例中 todo 命令的输出已截断）：

 lingchax@linux-yeoz ~ -> osc collab todo --project GNOME:Factory
Downloading data in a cache. It might take a few seconds...
Package         | openSUSE:Factory | GNOME:Factory    | Upstream        
----------------+------------------+------------------+-----------------
PackageKit      | 0.7.4            | 0.7.4            | 0.8.3           
accountsservice | 0.6.23           | 0.6.24 (c)       | 0.6.25 (c)      
anjuta          | 3.4.4            | 3.5.91           | 3.6.0           
anjuta-extras   | 3.4.0            | 3.5.4            | 3.6.0           
dconf           | 0.12.1           | 0.13.90 (s)      | 0.14.0 (s)      
gdl             | 3.4.2            | 3.5.91           | 3.6.0 (r)

我们可以看到 PackageKit, accountsservice, anjuta and anjuta-extras dconf gdl都需要一个更新因为上游有更新的版本。我们注意到 gdl 被某人预留，所以我们可以忽略它。类似的，我们注意到有一个提交 dconf 等待 GNOME:Factory 维护者的批准，所以也忽略这个。通过一些参数自动的移除这些行是可行的： osc collab todo --exclude-reserved --exclude-submitted (对于不喜欢敲那么长命令的人们，或者使用 osc collab t --xr --xs ）。

让我们来更新一下 PackageKit:

 lingchax@linux-yeoz home:douglarek -> osc collab update --project GNOME:Factory PackageKit
A    /work/obs/home:douglarek/PackageKit
A    /work/obs/home:douglarek/PackageKit/0001-Change-the-configuration-of-the-cron-script-to-a-sys.patch
A    /work/obs/home:douglarek/PackageKit/0002-Build-against-npapi-sdk-instead-of-xulrunner.patch
A    /work/obs/home:douglarek/PackageKit/0003-Revert-packagekit-qt2-Since-new-methods-and-enums-wh.patch
A    /work/obs/home:douglarek/PackageKit/0004-zypp-use-pre-increment-in-for-loops-to-avoid-tempora.patch
A    /work/obs/home:douglarek/PackageKit/0005-zypp-don-t-waste-time-comparing-zypp-Arch-string-rep.patch
A    /work/obs/home:douglarek/PackageKit/0006-zypp-set-CXXFLAGS-and-use-std-c-0x-as-libzypp-does-b.patch
A    /work/obs/home:douglarek/PackageKit/0007-zypp-fix-missing-dtor.patch
A    /work/obs/home:douglarek/PackageKit/0008-zypp-no-longer-use-the-old-and-deprecated-ZYppCommit.patch
A    /work/obs/home:douglarek/PackageKit/0009-zypp-adjust-PK_FILTER_ENUM_NOT_DEVELOPMENT-bnc-77002.patch
A    /work/obs/home:douglarek/PackageKit/PackageKit-0.7.4.tar.xz
A    /work/obs/home:douglarek/PackageKit/PackageKit-bnc775651-ignore-accept-eula.patch
A    /work/obs/home:douglarek/PackageKit/PackageKit-bnc780058-zypp-backend-match-patches.patch
A    /work/obs/home:douglarek/PackageKit/PackageKit-gstreamer-1.0.patch
A    /work/obs/home:douglarek/PackageKit/PackageKit-zypp-packagesize.patch
A    /work/obs/home:douglarek/PackageKit/PackageKit.changes
A    /work/obs/home:douglarek/PackageKit/PackageKit.spec
A    /work/obs/home:douglarek/PackageKit/baselibs.conf
At revision 47b573b1461f4106aeaff1bc530e39a6.
Package PackageKit has been checked out.
PackageKit.spec has been prepared.
PackageKit.changes has been prepared.
Looking for the upstream tarball...
PackageKit-0.8.3.tar.xz has been downloaded.
Extracting useful diff between tarballs (NEWS, ChangeLog, configure.{ac,in})...
NEWS between PackageKit-0.7.4.tar.xz and PackageKit-0.8.3.tar.xz is available in osc-collab.NEWS
No ChangeLog information found.
Diff in configure.{ac,in} between PackageKit-0.7.4.tar.xz and PackageKit-0.8.3.tar.xz is available in osc-collab.configure
Running quilt...
Patches still apply.
PackageKit-0.7.4.tar.xz has been removed from the package.
A    PackageKit/PackageKit-0.8.3.tar.xz
PackageKit-0.8.3.tar.xz has been added to the package.
Package PackageKit has been prepared for the update.
After having updated PackageKit.changes, you can use 'osc build' to start a local build or 'osc collab build' to start a build on the build service.

这条命令的输出有点罗嗦，但是这样我们能确定正在发生什么。针对这个实例来说，没什么差错，并且看起来你只需要更新 PackageKit.changes.

所以，你首先切换到当前的目录，并通过 cd PackageKit 检出包。然后，你现在可以使用你喜欢的编辑器打开 PackageKit.changes. 你会注意到它已经被填充了：

 +-------------------------------------------------------------------
+Thu Sep 27 07:08:59 UTC 2012 - douglarek@outlook.com
+
+- Update to version 0.8.3:
+  + 
+
 -------------------------------------------------------------------

所以你只需要注意变更了什么。osc-collab.NEWS 以及 osc-collab.ChangeLog 文件应该有所帮助。

现在你已经更新了 PackageKit.changes，你应该确保这个软件包的所有补丁仍旧应用，并且构建以及运行依赖已经最新。没有什么魔法来做这些，所以它们都是手动的工作。

下一步通常是提交你的变更，确保这种情况下的软件包编译正确。你可以使用一个命令搞定：osc collab buildsubmit -m 'Update to 0.8.3 --project GNOME:Factory'。

当 osc collab buildsubmit 成功执行后，这个软件包将默认解除预订，除非你使用 --no-unreserve 选项。你也可以这样解除预订这个软件包：osc collab unreserve PackageKit

编译提交的替代品

如果你不想使用 osc collab buildsubmit，你可以使用下面所说的在构建服务上典型的协作命令。然而，‘'osc collab buildsubmit 大多数情况下已经够用。

首先，你可以提交你的变更到构建服务上：osc commit -m 'Update to 0.8.3'
一旦完成，确保软件包被正确构建 -- 或者检查构建服务生的构建结果（在web页面或者通过 osc results home:douglarek:branches:GNOME:Factory PackageKit) 或者使用 osc build。
如果构建成功，使用下面的命令提交你的包到 GNOME:Factory： osc submitreq create -m 'Update to 0.8.3'

什么出问题了？

如果你试图更新被某人预订的软件包，你会得到一个错误。你可以使用 --ignore-reserved 选项忽略它。这仅在你和这个预约包的人沟通之后才可以这么做。
有时候，一些补丁不再被应用。因为这样，你会看到 'quilt' 步骤失败。你不得不先修复它。

注意： （译者注：）使用osc collab update --project xxx xxx的时候，执行完毕，请务必不要忘记执行osc collab unreserve xxx，因为可能不止你一个人想预订此软件包，如果你占着毛坑不拉屎，会让别人很不爽，有可能还要浪费时间和你沟通。

用户文档

这部分提供从安装运行 osc collab 到应用在几个项目的基本步骤。

安装

安装这个智能插件的简单方法是从 openSUSE:Tools 项目通过 osc-plugin-collab 软件包安装。

你也可以通过 git 安装最新的版本：

安装 osc 以及 git：zypper in osc git
检出 osc-plugins 仓库： git clone git://gitorious.org/opensuse/osc-plugin-collab.git 或者 git clone https://git.gitorious.org/opensuse/osc-plugin-collab.git
复制该插件： mkdir -p ~/.osc-plugins/ && cp osc-plugin-collab/osc-collab.py ~/.osc-plugins/

确保该插件是否安装，简单的运行 osc collab --help 一下你应该可以看到此插件的描述信息。

第一次运行该插件执行实际的命令时，它会询问你的邮箱地址。这个邮箱地址保存在 ~/.oscrc ，并且当更新 .changes 文件的时候会用到。

配置

该插件有一些默认的配置可以在 ~/.oscrc (在 [general] 部分) 覆盖掉，或者通过一些命令行选项。注意命令行选项从 ~/.oscrc 加载配置。

变量	默认值	命令行选项	~/.oscrc 改变键	示例
Projects	GNOME:Factory;	`--project`	collab_projects	`collab_projects = GNOME:Factory;X11:common:Factory;GNOME:Contrib;`
Repository	openSUSE_Factory	`--repo`	collab_repo	`collab_repo = openSUSE_11.1`
Architectures	i586;x86_64;	`--arch`	collab_archs	`collab_archs = i586;`
Package tracking	0		collab_do_package_tracking	`collab_do_package_tracking = 1`

作为一个示例，使用 openSUSE 11.1 Moblin的亲应该可以使用 ~/.oscrc 如下的配置：

collab_projects = Moblin:UI;Moblin:Base;
collab_repo = openSUSE_11.1

而使用openSUSE 11.1 GNOME 2.26的亲可以这样：

collab_projects = GNOME:STABLE:2.26;GNOME:Backports:2.26;
collab_repo = openSUSE_11.1

包跟踪的一个注意点

如果你不知道软件包跟踪, 你可以跳过这里 :-)

取决于 osc collab 的工作方式，当使用 setup 以及 update 命令的时候，软件包跟踪特性被禁用： osc collab 检出没有项目结构（不能使用软件包跟踪）的平行目录的软件包。如果作为一个用户，你想强制使用软件包跟踪，你需要恰当的使用 osc collab （为每个项目通过在正确的目录调用它），并且设置 collab_do_package_tracking 选项。

我能做什么？

大团队经常出现的一个问题是人们不知道他们能做什么：有太多的事情要做以至于你因为不知道什么已经做了以及别人在做什么而迷失。命令 osc collab todo 可以帮你。它会显示所以需要更新到上游新版本的所有软件包。这是工作在软件包上一般而最简单的方式。

你可以使用 --exclude-reserved 以及 --exclude-submitted 选项来隐藏他人已经工作的软件包，或者隐藏被提交的软件包。可以通过正常输出的 (r) 以及 (s) 确认。

预订系统

To avoid people duplicating work, we are using a really simple reservation system. When you run osc collab update or osc collab setup, you automatically reserve the package for work. To ignore this reservation step, you can use the --no-reserve option.

A reservation lasts 36 hours. After this time, the reservation expires and is automatically removed. A package is also automatically unreserved after a successuful osc collab buildsubmit, unless you used the --no-unreserve option. To manually remove a reservation, the osc collab unreserve command can be used..

Note that you can manually reserve a package for work with osc collab reserve. This command is provided for completeness only, since you would generally use osc collab update or osc collab setup.

It is possible to see who is working on what with the osc collab listreserved, and you can also check if a package is reserved with the osc collab isreserved command.

将一个包更新到上游的新的版本

The most common task during the early development cycle of a new version of openSUSE is to update packages to new upstream versions. The osc collab update command can be used for that.

This command will do the following:

check if there is an update for the package. If this is not the case, the command stops.
check that nobody is working on the package, unless the --ignore-reserved option is used.
reserve the package for you, unless the --no-reserve option is used.
branch the package from the devel project and check it out in the current directory.
do the required updates that can be determined to the .spec file (usually, update the Version tag).
prepend a new .changes entry that you will later fill.
download the upstream tarball.
extract the relevant NEWS and ChangeLog information for this new upstream tarball.
check that patches in this package still apply with the new upstream tarball.
remove the old tarball from the build service and add the new tarball to the build service.

In general, the only thing left to do after running this command is to fill the .changes file. You also have to make sure that all patches are still relevant and that all the build and runtime dependencies are correct.

工作在一个软件包

The other common task when working on a package is to modify a package, to add a new patch or to fix a packaging issue. The osc collab setup command helps you prepare the package.

This command will do the following:

check that nobody is working on the package, unless the --ignore-reserved option is used.
reserve the package for you, unless the --no-reserve option is used.
branch the package from the devel project and check it out in the current directory.

You can then easily do the work you wanted to do.

构建一个包

Once a change is ready, it's important to make sure that the updated package still compiles. You can compile the package locally with osc build, or you can commit and wait for the build to succeed on the build service. The osc collab build command is a convenience command that will commit the changes on the build service, and will make sure that a build starts there. It will then monitor the build so that you can easily check the status of the build.

The --repo and --arch arguments can be used to specify the target of the build.

构建并且提交一个包

In the usual workflow, you want to submit your change to the parent project if the package builds fine. The osc collab buildsubmit lets you do that: it works exactly like the osc collab build command, but in addition, if the build is successful, it will submit the build to the parent project.

Some people refer to this command as the "fire and forget" command, since you can just do your changes, and then run this command; if everything is fine, you won't have to worry about this package since it will get automatically submitted. You can even use the --forward option to automatically forward to the destination project (see below for a description of the forward feature).

工作在多个项目

In a simple use case, you only need to work on packages living in a single project. However, many users of osc collab will need to interact with packages living in various projects. This usually is completely intuitive since there's no intersection between the packages of those projects (eg, between GNOME:Factory and X11:common:Factory).

Sometimes, though, you need to work with projects that have packages with the same names. A good example of this is GNOME:Factory and GNOME:STABLE:2.26. In such cases, if you use --project GNOME:Factory --project GNOME:STABLE:2.26, all the actions on a package name that exists in both projects will take effect on the first project (here, GNOME:Factory). This should still stay intuitive.

Note that it's always possible to force on which project you want to work by using a single --project option.

其他有用的命令

osc collab 里一些其他的命令可能也是令你感兴趣的。

管理员的任务

osc collab todoadmin lets you do a sanity check of some project. It will display a list of things you might want to do to clean the project. For example, with GNOME:Factory:

packages with a patch that don't apply anymore
packages which are not links to openSUSE:Factory
packages which shouldn't exist in GNOME:Factory (either because they're dead or because they're maintained elsewhere)
packages which should exist in GNOME:Factory (generally, this is new packages that haven't been linked in GNOME:Factory yet)
packages which should be submitted to openSUSE:Factory
etc.

You can use the --exclude-submitted option to hide packages which are submitted to openSUSE:Factory but waiting for a review there.

Generally, the way to fix the issues are trivial to know for an administrator. For reference, the following commands are generally helpful:

osc linkpac openSUSE:Factory $pkg GNOME:Factory: to link a package from openSUSE:Factory to GNOME:Factory
osc checkout -u GNOME:Factory $pkg: to check out a package in unexpanded mode, to fix patches that don't apply anymore, eg.

发送一个包

osc collab forward lets you forward a submitted change directly from a user branch to the destination project, bypassing the step where the change stays in the devel project for a while. Internally, the submission gets accepted to the devel project, and then a new submission is created from the devel project to the destination project.

Here's an example: assuming that submission #12345 is a submission of gnome-panel from home:vuntz:branches:GNOME:Factory to GNOME:Factory, osc collab forward 12345 will accept this submission in GNOME:Factory, and will create a new submission from GNOME:Factory to openSUSE:Factory for the gnome-panel package.

贡献

欢迎每个人对 osc-plugin-collab 插件的开发作出贡献，自由的发送臭虫报告以及补丁到开发邮件列表：

gnome@lists.opensuse.org - openSUSE GNOME Mailing List

订阅 | 退订 | 了解 | 存档列表

你也可以发布你自己的osc-plugin-collab git 分支到网络来简化开发进程合作。

后端细节

现在，osc collab 因为各种脚本创建的数据库而得以工作。这些脚本存在于 osc-plugin-collab/server/，免费查看，而且可以对其改善。

打包者：在这里你可以学习如何提交你的软件包到上游监视器：SDB:Upstream Tracker。（这适用于所有 OBS 上存在的软件包）

openSUSE:Osc Collab

目录