RT
我在尝试编译 opensuse 的 mips64el 版本。想自建 OBS 试试效果。
已经导入了之前编译完成 minimalX 项目的包。（用 Fedora 的 mock 编译的……）
而且之前测试，确实可以编译成功，单独只有 1 个包的时候，是可以 succeeded 。
但是我导入了 15.0 的 Bootsttap 的那些包后，我发现很多软件包已经编译过了，结果还是被塞进了 scheduled 重新二次编译。
请问这个正常吗？为什么会出现重新编译的问题？
而且我看还有很多 blocked 包。
难道是因为这些没有满足的依赖导致不停的重新编译？
有没有办法解决这个问题？只有一个龙芯 3a3000 ，受不了这不停的重复编译啊，太浪费时间了。
你导入那些包后依赖有变化，当然会重新编译。
问题是重复编译了很多次，单我只是一次全部导入，之后就没再修改。
导入的是本地源还是包括 update 在内的在线源？
你看看是不是出现了 build cycle，比如 A 依赖 B，B 依赖 C，C 依赖 A，这在 bootstrap 里是很容易出现的，这种情况除非手动处理不然永远停不下来的，你可以参考下 openSUSE:Factory 源的 prjconf，看看它是怎么 break 掉 build cycle 的
这种情况确实需要手动 disable 一些包。
好的，我去看看。不过这个依赖循环导致不停重启编译好诡异啊。
本来已经基于某个软件包编译出来的程序，为什么在被依赖的程序 secceeded 后的二次编译，还要重新开始呢……完全没必要啊。
我是之前用 mock 编译完了全部的 minimalX 的包，之后全都扔到 :full 里面的初始化模式的。
之后我现在想明白了，我为啥不用 DoD 模式……反正 obs 已经弄了 apache 的 repo 站点……
我自己再增加个站点不就行了……
大概看了一眼，不行啊。
我是复制 leap15.0 的 conf ，和 factory 的基本一样啊。
leap15.0 是怎么解决的呢？
你先看看你的包的 release number 是不是一直在增长吧…这样应该每次都有新的 rpm 产生。
https://build.opensuse.org/project/prjconf/openSUSE:Leap:15.0
这里面的 Ignore 都是 break build cycle 的。
问题就在这里呗，你的包不完全和 leap 15.0 一样。由于你是个 private instance，只能你自己去查…但是 OBS 的这里应该给点提示：
https://build.opensuse.org/project/repository_state/openSUSE:Leap:15.0/standard
另外你可以观察比如 /srv/obs/log 或者 qmenu 的日志看看它都创建虚拟机编译了哪些包，肯定是能找到规律的，对应去检查 specfile 写 Ignore 就行啦
怎么看 release number ？
另外，我的包完全是从 opensuse 上面直接用 osc 拉下来的 0-Bootstrap 项目的内容。
不存在不完全一样的内容吧？
而且 opensuse 也是把这部分单独做的项目。
我对这些包的修改，也仅限于增加补丁和适应 mips 的需要修改，并没有修改依赖关系。
是不是因为这一部分：
%if "%_project" != "openSUSE:Leap:15.0:Rings:0-Bootstrap"
# remove build-compare support to disable "same result" package dropping
Support: build-compare
# Extracting appdata.xml from desktop files
Support: brp-extract-appdata
%endif
我刚从发现，只有这部分的 project 忘了改成我对应的项目名称。
我看了一下循环编译的包，rel 版本后缀 lp150 后的两个小版本号里面第二位确实增加了。
这怎么解决？
第二位增加就是不同的 rpm 了。那依赖关系变化重新编译很正常啊。现在只能自己去看日志看 build cycle 是什么。
问题是 opensuse 官方怎么解决的啊？
完全是照抄他们的 project config 。软件包我也没改依赖关系。
你都说了你是 private instance 了啊…官方遇到过的问题对应的解决方法都写在 prjconf 里。你用了不好使就证明你的问题很大可能不是官方遇到过的问题。然后你还问官方怎么解决的，官方没遇到过你的问题解决什么。如果说你是完全复制官方的 Leap 15.0 的 x86_64 在你的 instance 上编译出了问题，才有可能是官方的问题。
你现在要做的是用官方解决问题的方法来解决你遇到的问题，第一步是识别，你可以去看日志了，/srv/obs/log/scheduler_*.log。
另外你编译的也不是官方禁止的包啊，为什么不直接到 build.opensuse.org 上去编译，这样我们都能够看到也能帮你识别问题。
PS: OBS 运维现在除了文档只有 opensuse-buildservice 这个 mailing list，所有的开发者都在那里。你执意要用 private instance 的话，我只能说我经验不足，也许他们的经验可以通过你的描述不看日志不登录机器就告诉你问题可能出在哪儿
build.opensuse.org 上去编译 opensuse 的 mips 版吗？
我是有这个想法。但是我一个人做不部过来，所以不想弄个随时可能弃坑的东西放到公共环境上。
这么跟你说吧，我昨天遇到的问题就是 binutils 和 glibc 两个编译完就继续进调度队列。整个队列只有 4 个包，还一个 zlib ，还一个忘了。
如果你说官方遇不到的问题，我因为环境不同导致的，那我就奇怪了这两个东西怎么出现的互相调度？
唉算了，我直接设置 rebuild=“local” 了。
正好我在同步 minimalX ，龙芯机器现在闲置，可以看一眼内容。
目前是改了 obs 的设置，把 rebuild 的参数去掉了。
附件是调度的 log 。
现在正在自动编译 gcc 。
因为刚开机，内容很少。scheduler_mips64.log.bz2 (5.7 KB)
不过我自己看了一下，调度信息感觉有点乱。从里面找对应的关系也太难了。
如果 obs 能给个完全顺序的列表就好了，至少多次重新编译，我也能知道需要重复什么地方吧。