OpenCloudOS Stream 的所有软件包均记录于:https://gitee.com/OpenCloudOS/rpm_info/blob/master/packages.yaml
该文件以 sig 为单位进行划分,每个 sig 包含 sig 介绍、sig reviewer 和 sig packages。
所有软件包都有且仅有一个所属 sig,同时提供一个 default sig。如果新增软件包不确定应该分类到哪个 sig,则应选择 default sig。
我们欢迎并鼓励开发者参与我们的仓库开发。我们使用一个名为collaborators.yaml
的文件来记录所有参与仓库开发的外部成员,该文件使用 YAML 格式记录。
要申请成为仓库开发者,请按照以下步骤操作:
https://gitee.com/OpenCloudOS/rpm_info
git clone git@gitee.com:<username>/rpm_info.git
collaborators.yaml
文件,添加您的信息。请确保正确填写您的 gitee 用户名称、邮箱和希望加入的仓库名称。第一次申请加入仓库时,需要填写个人信息,请以该模板为参考,在 collaborators.yaml
文件末尾追加以下内容:
- 用户名称: xxx
联系方式: xxx
仓库:
- xxx
- xxx
示例:
- 用户名称: gitee-bot
联系方式: gitee-bot@example.com
仓库:
- setup
字段说明:
用户名称
:Gitee 账户名称,请务必保证与 gitee 用户名称一致,否则无法正确为您修改权限。以 gitee-bot 用户为例,个人主页中,左上角个人介绍中 @gitee-bot
表示该用户名称为 gitee-bot
,与个人空间地址一致,而 Gitee GPG Bot
则是账户昵称,非唯一标识。联系方式
:邮箱或手机号码。用于与团队沟通。仓库
:申请加入的仓库列表。注意事项:
collaborators.yaml
文件时,请不要修改其他成员的信息。
新增仓库、修改仓库 sig/衰退仓库、删除仓库都需要修改 rpm_info/packages.yaml 文件实现,具体操作如下:
https://gitee.com/OpenCloudOS/rpm_info
git clone git@gitee.com:<username>/rpm_info.git
OpenCloudOS Stream 的所有软件包都存储在 https://gitee.com/opencloudos-stream/ 仓库,以 setup
仓库为例介绍参与贡献流程:
mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
> cat mock.cfg
# Auto-generated by the Koji build system
config_opts['basedir'] = '/var/lib/mock'
config_opts['chroot_setup_cmd'] = 'groupinstall build'
config_opts['chroothome'] = '/builddir'
config_opts['dnf_warning'] = False
config_opts['package_manager'] = 'dnf'
config_opts['root'] = 'dist-ocs23-build-repo_latest'
config_opts['rpmbuild_networking'] = False
config_opts['rpmbuild_timeout'] = 86400
config_opts['target_arch'] = 'x86_64'
config_opts['use_host_resolv'] = False
config_opts['yum.conf'] = '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n# repos\n\n[build]\nname=build\nbaseurl=https://build.stream.opencloudos.tech/kojifiles/repos/dist-ocs23-build/latest/x86_64\n'
config_opts['plugin_conf']['ccache_enable'] = False
config_opts['plugin_conf']['root_cache_enable'] = False
config_opts['plugin_conf']['yum_cache_enable'] = False
config_opts['macros']['%_host'] = 'x86_64-koji-linux-gnu'
config_opts['macros']['%_host_cpu'] = 'x86_64'
config_opts['macros']['%_rpmfilename'] = '%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm'
config_opts['macros']['%_topdir'] = '/builddir/build'
config_opts['macros']['%dist'] = '.ocs23'
config_opts['macros']['%distribution'] = 'Koji Testing'
config_opts['macros']['%packager'] = 'Koji'
config_opts['macros']['%vendor'] = 'Koji'
ocspkg clone setup
, 然后进入setup仓库:cd setup
(ocspkg指令需在仓库中执行)ocspkg sources
如果lookaside中无源码包,可上传源码包: ocspkg new-sources setup-x.xx.tar.gz
(非必须步骤,按需执行)ocspkg srpm
ocspkg mockbuild
ocspkg build --scratch --srpm /path/to/xx.src.rpm # 推荐,使用本地srpm编译
ocspkg build --scratch # 从git仓库生成srpm,然后发起编译
ocspkg commit -m "input your message"
ocspkg push
git clone git@gitee.com:<username>/setup.git
sha512sum --tag <tarball_name>
命令获取源码包 sha512 值并写入sources,sources文件需要在末尾保留一个空行,可参考仓库 gcc 的 sources 文件
cp * ~/rpmbuild/SOURCES/
mv ~/rpmbuild/SOURCES/setup.spec ~/rpmbuild/SPECS/
~/rpmbuild/SRPMS
目录:rpmbuild -bs ~/rpmbuild/SPECS/setup.spec
mock -r /path/to/mock.cfg --rebuild ~/rpmbuild/SRPMS/setup-2.13.9.1-4.ocs23.src.rpm
/var/lib/mock/dist-ocs23-build-repo_latest/result
/var/lib/mock/dist-ocs23-build-repo_latest/root/builddir/build/
pr 提交后,CI 会进行一系列检查,包括:编译构建测试、安装/卸载测试、安全合规检验
为避免开发者误上传源码包到 git 仓库,会检查 pull request 中是否包含压缩文件,如包含则会上传到 lookaside 并返回评论提示开发者删除相关压缩包,也是当前为开发者上传源码包的一种解决方案
为确保提交软件包质量,提交 pull request 后会触发编译构建测试,根据提交的代码在 x86_64 以及 aarch64 机器上进行编译构建
为确保提交软件包能够正常使用,通过编译构建测试后会在 x86_64 以及 aarch64 机器上对生成的二进制软件包依次进行安装卸载测试。
为了确保项目的安全性和合规性,引入新软件包后我们还会进行以下安全合规相关检查:
通过进行这些扫描和检查,我们可以最大程度地降低引入新软件包可能带来的安全风险,并确保项目的合规性。我们鼓励所有贡献者和团队成员积极参与这些扫描和检查过程,以共同维护项目的安全和合规标准。
stream 版本提供自动升级工具,对于需要升级的软件包,开发者可以在对应仓库下创建升级 issue,一条命令触发自动升级流水线,完成升级以及相关检查。具体流程如下:
创建升级 issue:默认创建 “升级” 类型 issue,根据模板指引创建 issue,填写升级原因;
触发升级:评论 /upgrade [version]
可触发指定版本升级;也可评论 /upgrade
使用最新版本升级;
流水线结果:
流水线首先返回升级信息,若升级成功则继续触发编译构建及兼容性检查;
若流水线因网络等偶发原因失败,请评论 /reupgrade
重新触发升级流程;
若需要修改代码,通过 clone ocs-bot 仓库进行修改:git clone git@gitee.com:ocs-bot/<repo_name>.git
,完成修改后评论 /recheck
重新进行编译构建及兼容性检查
升级结论:兼容性工具检查结果供参考,请根据 Release Note/ Changelog 及代码,分析并确认兼容性,决定是否进行升级
升级:评论 /pr
即可正式提交 pr
无需升级:请在侧边栏将状态修改为已拒绝
,关闭当前 issue;
延迟升级:请评论 /TBD [days]
命令挂起本次升级,若不指定挂起天数,会在下次大规模升级时统一触发,若指定天数,则在下次大规模升级时,只有达到该天数才会触发升级;
帮助命令:评论 /help
可以获得帮助命令输出
注:目前仅支持当前仓库成员执行自动升级流程,申请加入仓库成为仓库成员,请参考 加入仓库
部分。
当前软件包分属在BaseOS, AppStream 和 EPOL 三个YUM仓库中,在版本演进过程中可能会对各仓库中的软件包进行调整,将特定软件包从一个仓库移入另一个仓库(比如从EPOL仓库移入AppStream)。用户需要通过以下步骤申请软件包移仓。
软件包移动通过修改 rpm_info/*.list 文件实现,具体操作如下,以把一个二进制包从EPOL移入AppStream为例:
fork 仓库:https://gitee.com/OpenCloudOS/rpm_info
clone 仓库:git clone git@gitee.com:<username>/rpm_info.git
修改epol.list, appstream.list
提交 pull request 并提供变更原因
人工审核:是否允许移动该软件包
接受 pull request:触发流水线自动执行YUM源变更操作
验证。通过 dnf list 查询包是否移动成功
在衰退软件包时,除了需要在packages.yaml中移动软件包外,还需要将衰退软件包对应的所有二进制软件,从原始列表移到deprecated.list中,并确认没有其他二进制包依赖该衰退软件包。
比如,假设appstream-data这个软件需要衰退,它存在于appstream.list中,那么就需要删除appstream.list中 appstream-data 所有二进制包,添加到 deprecated.list,才算完成 appstream-data 的衰退操作。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。