53 Star 146 Fork 138

openEuler / RISC-V

 / 详情

构建失败分类管理

待办的
任务 成员
创建于  
2021-08-13 17:44

为了方便更多的人知道怎么去解决构建失败的问题,这里我倡议大家共同维护本issue,完成构建失败问题分类及解决思路的整理。
1、怎么去维护本issue?
按照构建失败的原因和解决方法进行分类,贴出以下信息:

  • 失败分类名(先自定义):
  • 失败分类标签(先自定义):

要求简短,不重复。主要目的是为了快速通过issue检索出同类型错误的包

  • 问题原因(可以贴log文件中报错的地方):
  • 错误类型(简单描述一下错误原因):
  • 解决办法(可以贴自己的issue连接):

暂定以上这些信息,有需要的大家一起补充完善。

2、什么时候更新本issue;
当出现了一类本issue中没有总结到的构建错误类型时,可以在解决了问题之后,将自己成功的经验和分析方法再次记录分享。

3、有哪些已知失败原因的包未解决?
对于了解失败原因,但是无时间解决的,可以在本issue的评论中通过回复的方式,将报名列举出来。


此外,补充说明一下:构建失败包问题解决采用认领模式,大家自行选择要解决的包。
第一步:在obs网站上,对构建失败的包通过日志分析(问题的分析和解决可参考本issue分享的原因和解决办法 ),选择一个计划去认领的包。

第二步:在issue中搜索包名,看包是否已经被认领。(主要避免重复工作,如果确有需要对该包进展进行了解的,与issue创建人进行沟通)

第三步:创建一个issue,标题为:[构建失败][失败分类标签] Packagename

[构建失败] Packagename 是标题必须填写的信息,失败分类标签不清楚的时候,可暂时不写,后续修改或者专人维护;

第四步:分析问题并解决,并在Packagename issue中贴出问题原因、错误分析等信息。

  • 按照预期解决问题的:按照流程提交
  • 无法解决问题的:可以将issue的标题中添加[转让]标记;
  • A贡献者关注的包Pag1所依赖的包被B贡献者认领的:A直接找B去沟通,并商议包pag1谁继续推进;

评论 (15)

phoebe 创建了任务
phoebe 关联仓库设置为openEuler/RISC-V
展开全部操作日志

Hey xijing666, Welcome to openEuler Community.
All of the projects in openEuler Community are maintained by @openeuler-ci-bot.
That means the developers can comment below every pull request or issue to trigger Bot Commands.
Please follow instructions at https://gitee.com/openeuler/community/blob/master/en/sig-infrastructure/command.md to find the details.

openeuler-ci-bot 添加了
 
sig/sig-RISC-V
标签
phoebe 置顶等级设置为
phoebe 修改了描述

解决的包名:tss2
失败分类名:找不到/usr/lib64/libibmtssutils.so.1
失败分类标签:File not found
问题原因:RPM build errors:File not found: /home/abuild/rpmbuild/BUILDROOT/tss2-1470-1.oe1.riscv64/usr/lib64/libibmtssutils.so.1
错误类型:初步判断是spec文件中的路径错误。
解决办法:#I45BM6:[构建失败]【待合并】【已解决】tss2

失败分类名:找不到/usr/lib64/libqrencode.so.3*
失败分类标签:File not found
解决的包:qrencode

phoebe 修改了描述

解决的包名:zip、unzip
失败分类名:自动构建未成功
失败分类标签:未同步更新Gitee仓库
问题原因:可能是由于OBS worker的环境改变导致改包已经可以成功,但是OBS尚未触发自动构建。因此像这一类的包在OBS上直接branch到自己的工程名下,修改_service文件为自己的Gitee仓库地址就可以成功构建。
错误类型:未触发自动构建
解决办法:#I45ORW:【构建失败】【已解决】zip、unzip

失败分类名:自动构建未成功
失败分类标签:未同步更新Gitee仓库
解决的包: python-urwid

失败分类名:自动构建未成功
失败分类标签:未同步更新Gitee仓库
解决的包: acpica-tools、libwmf

失败分类名:自动构建未成功
失败分类标签:未同步更新Gitee仓库
解决的包: python-mistune

解决的包名:colord 和 libxcb
失败分类名:依赖的包在依赖源中版本低
失败分类标签:依赖的包在依赖源中版本低
问题原因:colord: meson.build:1:0: ERROR: Meson version is 0.51.1 but project requires >=0.52.0
libcxb: [ 1557s] Package dependency requirement 'xcb-proto >= 1.14' could not be satisfied.
[ 1557s] Package 'xcb-proto' has version '1.13', required version is '>= 1.14'
错误类型:依赖的包在依赖源中版本低
解决办法:[构建失败]【已解决】colord 和 libxcb

涉及的包名:ComputeLibrary
失败分类名:服务器环境中的Python SCons编译器暂不支持riscv64,相关配置信息缺失
失败分类标签:Python SCons编译不支持riscv64
问题原因:scons: *** Invalid value for option arch: riscv64. Valid values are: ('armv7a', 'arm64-v8a', 'arm64-v8.2-a', 'arm64-v8.2-a-sve', 'x86_32', 'x86_64', 'armv8a', 'armv8.2-a', 'armv8.2-a-sve', 'armv8.6-a', 'x86')
错误类型:依赖项Python SCons未成功构建,SConstruct需要改写配置使兼容riscv64
解决办法:ComputeLibrary.spec文件中修改

- ExclusiveArch:  aarch64 x86_64  
+ ExclusiveArch:  aarch64 x86_64 riscv64

在SConstruct中修改

vars.AddVariables(
    BoolVariable("debug", "Debug", False),
    BoolVariable("asserts", "Enable asserts (this flag is forced to 1 for debug=1)", False),
    BoolVariable("logging", "Logging (this flag is forced to 1 for debug=1)", False),
    EnumVariable("arch", "Target Architecture", "armv7a",
 -                 allowed_values=("armv7a", "arm64-v8a", "arm64-v8.2-a", "arm64-v8.2-a-sve", "x86_32", "x86_64", "armv8a", "armv8.2-a", "armv8.2-a-sve", "armv8.6-a", "x86")),
+                 allowed_values=("armv7a", "arm64-v8a", "arm64-v8.2-a", "arm64-v8.2-a-sve", "x86_32", "x86_64", "armv8a", "armv8.2-a", "armv8.2-a-sve", "armv8.6-a", "x86", "riscv64")),

还需要添加riscv64编译指令配置内容,需要等待SCons构建成功后验证

对当前要解决构建失败问题的软件包优先级的原则建议

背景:
两个构建工程进度不同并且分别承载着不同的功能,
openEuler-Mainline-RISC-V:支撑短期内 发布一个能够运行界面 的openEuler RISC-V系统镜像;
baseOS:是支撑22.03LTS正规版本发布,软件包版本保持最新,从最小系统开始构建,达成自举构建目的。

对于两个工程中的软件包,软件版本选型和解决失败问题的优先级取决于上述两个工程的角色定位,即:

  1. 对于openEuler-Mainline-RISC-V工程(以下简称main工程),优先解决阻塞界面运行的软件包所需的软件,例如最新的glibc2.34在main工程尚为编译通过,但是当前在main工程的依赖仓中已有glibc2.31不阻塞其他软件包的编译、镜像制作和运行,所以glibc2.34在main工程中可以不解决。
    具体的软件包范围,可通过在一个可运行界面的系统中,如fedora,debian,获取所安装的软件包范围,然后把支撑这些软件包的编译、运行的所有软件包列表,作为main工程中优先解决的范围。若这个范围中的软件包,在main工程中既没有构建成功,在依赖仓中也没有可用的版本,那么就需要优先解决了,例如mozjs。
  2. 对于baseOS工程,软件包版本由risc-v sig的maintainer 结合src-openEuler 各软件包的master分支的版本情况,选择22.03版本时的软件包版本,这里边的软件包应当是需要从一个最小系统范围做起,解决软件包的构建问题,例如glibc2.34的编译问题应当在baseOS中去解决。

看了下当前失败的软件包,按照一些比较初步的分析,界面相关的包可以优先解决,然后下面这些软件包我看了下应该属于被用到比较多的包,也可以参考优先解决:
failed:
alsa-tools
apr
apr-util
chrony
ck
colord-gtk
crash
gcr
PackageKit
gnome-autoar
gnome-calculator
gnome-online-account
gnome-session
gnulib
gspell
gtk*
gnome*
http-parser
httpd
kexec-tools
isomd5sum
ldns
libappindicator
libmodulemd
pulseaudio

unresolvable:
mozjs

对于这个 界面相关的软件包,建议可以安排同学写一个工具自动分析下,包含的功能包括:

  1. 在可以运行界面的系统中,获取所安装的软件包列表
  2. 获取这些软件包的编译和运行依赖闭包,去重
  3. 与当前main工程的依赖仓、成功、失败、unresolvable状态的包取交集
  4. 对于这些失败、unresolvable状态中的包,优先解决
    理论上如果3中的交集的软件包都解决了,那么界面应该就能跑起来了。

另外,对于main工程的软件包范围,也可以按照上面的思路来精简一下:当前main工程的软件包有4000+,触发构建时有很多包处于阻塞状态,若对于运行界面的构建任务无帮助,则可以去掉相应软件包,这样也有助于减少触发构建时对构建资源的占用和阻塞时间。

这个之前考虑过这个思路:

后来俊强说找到了更加简单的方法,然后就没有继续后续的比对

@phoebe
这样看就xfce少一些,那就可以瞄准xfce 的依赖来搞~

phoebe 置顶等级 修改为不置顶

登录 后才可以发表评论

状态
负责人
项目
里程碑
Pull Requests
关联的 Pull Requests 被合并后可能会关闭此 issue
分支
开始日期   -   截止日期
-
置顶选项
优先级
预计工期 (小时)
参与者(7)
5329419 openeuler ci bot 1632792936 1806569 maximsun 1578960211 9256217 phoebe xi 1650014869
Shell
1
https://gitee.com/openeuler/RISC-V.git
git@gitee.com:openeuler/RISC-V.git
openeuler
RISC-V
RISC-V

搜索帮助

14c37bed 8189591 565d56ea 8189591