别说去镜像下载 src.rpm 。我之前试过，导入后的数据和 obs 上面的不一样。
所以我现在只能 osc co 方式拉数据。
可是这太慢了，有什么加速的方法吗？
另外，如果能在官方 obs 上面编译 mips64el 的 rpm 也可以，但是我看设置里面根本不能选 mips 的东西。没办法实现直接的 rpm 编译吧？
全局翻墙或者反向代理。
已经靠翻墙拉回来了 15.1 。用北美的服务器中专速度还不错，估计中国去欧洲线路太窄，但是路由近所以速度慢。
问题是这个人是 cross 出来的，我要 obs 上本地编译。
其实 qemu 模拟 mips 实现本地也可以。但这需要我开一个 proj 并且设置 obs 系统给 qemu 虚拟机。我的项目怎么写？
如果我在我这里本地编译，我之前已经有 15.0 的 ring 完成的环境，可启动了，只要升级一下软件就行。
当然，现在我确实升级了，但是诡异的问题是 gzip 居然不正常。
gcc 编译过不去，gcc 的 fortran 有 .mod 文件是 gzip 压缩的，编译时说这个文件格式不对。我看了眼文件，居然无法解压缩，crc 错误。
但是 gzip 自己的 make check 正常。
我现在正在尝试各种重编译。15.0 升级 15.1 的 Bootstrap 也一直有问题，居然永远依赖 15.0 的包，即便 15.1 有替代品也不用，我怀疑是这个问题导致的 gzip 强制去掉 15.0 后出问题。
这个问题现在初步定位到了是 zlib 的问题，替换成当初 15.0 bootstrap 的 rpm ，gcc 就编译通过了。
gcc 看来不是调用 gzip ，而是直接用的 zlib 的 libz 库。
你想要不 crossbuild, 需要 worker 支持，worker 就是在 x86_64 的机器上跑 qemu。那个不是你写的，是配置 worker 配置出来的。官方 OBS 不支持 mips 架构，你可以自己搭建 OBS 配置 mips 的 worker。（但我感觉没有必要，一路 crossbuild 就行了，最终安装上去都是一样的）
你现在是有 mips 的硬件，在硬件上原生编译的吧。这样自动化差，还不如趁着包少，批量迁移到 OBS 去 crossbuild。
我不过是弄一个 mips64el 的 opensuse 。
很多 rpm 并不需要修改就能直接用在 mips64el 上，需要修改的并不多。
但是如果要做 cross ，这动静就太大了吧？
至于自动化我就是靠 OBS 自己实现自己编译，开着机器就行了。有错我再去改。
反正 opensuse 官方数据已经都搞定了包之间的问题了，我只需要去处理 mips 相关的事情。
也就是说你在 mips64el 机器上跑了一个自建 OBS？已经有了 mips64el 版的 openSUSE？那我觉得你更应该 contribute 一下，至少在 OBS 上建个源把你改过的代码都丢上去。第一，有人会有跟你一样的需求，众人拾柴火焰高，或许以后你就不用自己维护那么多份包的副本了。或许有人就会愿意去改成 crossbuild 模式，这样你也不用跑自建 OBS 了；二是，以后你不用 openSUSE 了或者不在开源世界了，有东西证明你来过。这些东西不会丢。
问题是访问德国的服务器太卡……
我先弄 rings 的东西，到时候怎么提交包再考虑吧
确实卡，没办法，我都只能路由器翻墙才能拉到数据。
对于我来说，不光是拉回来卡，还一个问题是怎么发布，如果用 obs ，我等于是被卡两次。
找个美国主机反代一下加速，只能这样了。国内连欧洲一直很慢。
问题是那也很慢啊，毕竟 opensuse 的源代码数据就不少。
我只能先本地，之后再用修改的 patch 去单独提交修改的包。
但是 opensuse 这货还需要很多二进制数据做 Bootstrap ……这就很尴尬了。
请问，自己搭建的 obs 服务怎么配置自己的 worker，有没有相关资料可以推荐下
这个网站居然有人讨论 openSUSE 的东西，真稀奇。