如何快速的从官方 obs 上用 osc 拉数据?

别说去镜像下载 src.rpm 。我之前试过,导入后的数据和 obs 上面的不一样。
所以我现在只能 osc co 方式拉数据。
可是这太慢了,有什么加速的方法吗?

另外,如果能在官方 obs 上面编译 mips64el 的 rpm 也可以,但是我看设置里面根本不能选 mips 的东西。没办法实现直接的 rpm 编译吧?

全局翻墙或者反向代理。

@jiangtao9999

如何搭建mipsel 和 mips64的交叉编译环境?

这个帖子看了吗?

你可以把在你的 home project 的 meta 里把这个源加上,然后就编译你要的包呗。

已经靠翻墙拉回来了 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 库。

问题原因应该是找到了:
https://forum.suse.org.cn/t/topic/12063

你想要不 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 的东西,到时候怎么提交包再考虑吧

确实卡,没办法,我都只能路由器翻墙才能拉到数据。

:thinking:
对于我来说,不光是拉回来卡,还一个问题是怎么发布,如果用 obs ,我等于是被卡两次。

找个美国主机反代一下加速,只能这样了。国内连欧洲一直很慢。

问题是那也很慢啊,毕竟 opensuse 的源代码数据就不少。
我只能先本地,之后再用修改的 patch 去单独提交修改的包。
但是 opensuse 这货还需要很多二进制数据做 Bootstrap ……这就很尴尬了。