在国内的网络环境下，克隆 LibreOffice 的源代码仓库、克隆翻译子模块仓库，编译时获取依赖的 external_tarballs，以及参与 bug 诊断时获取 “二进制二分查找 (bibisect) ” 仓库，都存在很大的困难，严重影响了大家的参与度。
通过折腾，我把我手头的一些资源放在了自己的墙内服务器上，供需要的人自由获取，以方便大家参与。注意这里的很多资源都支持 IPv6 访问。
https://go.suokunlong.cn:88/cgit
一、源代码、子模块
- 官方只读：https://cgit.freektop.org/libreoffice/core （国外，慢）
- 官方代码 push 审核：https://gerrit.libreoffice.org/（国外，慢）
- Github 只读镜像：https://github.com/LibreOffice/core（国外，慢）
- 中文社区镜像1：https://git.libreofficechina.org （国内，快）
- 中文社区镜像2：https://go.suokunlong.cn:88/cgit（国内，快）
克隆地址可在以上链接各项目页面的 clone 部分找到。比如：
git clone git://go.suokunlong.cn:88/lo/core
编译时如果在 autogen.input 中（或者 ./autogen.sh 的命令行参数中）启用 –with-lang=zh-CN 或者其他语言，则会用到 translations 子模块，make 时默认是从 gerrit 克隆这个子模块，墙内访问会卡在这个环节。此时，可以按下 Ctrl-C 键终止 make，然后将 .git/config 中 [submodule “translations”] 段的 url 改为镜像地址（见以上列出的镜像仓库 translations 页面中的 clone 部分），比如：
# git/config 中 [submodule "translations"] 段的 url 改为： url = git://go.suokunlong.cn/lo/translations # core源代码中 g 工具默认是没有开启 submodule update 中的 --progress 参数的。手动通过以下命令来更新子模块，可以显示进度： git submodule update --progress
如果您要参与代码贡献，需要知道官方的代码 review 是统一在 https://gerrit.libreoffice.org 上进行的，不能在这些只读镜像上 git push，也不能在 github 上提交 PR. 具体方式请参考 wiki: https://wiki.documentfoundation.org/Development
二、external_tarballs (编译时需要从 dev-www.libreoffice.org/src/ 下载的第三方源代码包）
这是编译时的依赖包，各种各样的，官方统一放到 https://dev-www.libreoffice.org/src/ 中，编译时会自动从这里去抓取。但是，服务器在德国，墙内如果不科学上网的话下载一个月也下不完。我将我目前用到的缓存包统一放到了如下位置。需要的可以在编译时显示正在下载某个包时按下 Ctrl-C 键，然后手动通过浏览器在以下位置找到这个包下载，放到对应的位置，然后再运行 make, 再获取另一个包时再中断然后…（默认是放在源代码根目录下的 external/tarballs 文件夹，但是您可以在 autogen.input 中通过 –with-external-tar = … 来指定其他位置，从而在不同分支的编译中共享这个目录）。
https://go.suokunlong.cn:88/dl/libreoffice/external_tarballs/
三、“二进制二分查找”（bibisect）仓库
LibreOffice 的 QA（质量控制）团队有一个很神奇的工具，叫做 bibisect。熟悉 git 的同学应该知道，git 里有一个 bisect（二分查找），但这里我们所说的是 bibisect（二进制二分查找），两个 bi.
简单说，就是：git 的 bisect 是源代码层面的二分查找，目的是通过二分树算法来快速找到造成某个“倒退”问题的 commit。但是，LibreOffice 的源代码编译很费时间，我们从源代码层面去 bisect 是几乎不可能的。因此，有人就发明了 bibisect，其原理是按照 libreoffice 的源代码 commit 的原有顺序先编译，然后将每一次编译所得的可直接运行的二进制文件作为一次 commit，放到一个 git 仓库中。这样，QA 团队就能直接通过 git bisect 命令进行 bug 诊断，而不用多次去编译源代码了。
在实际中，每个 bibisect 仓库可能是每隔 n 个源代码 commit 进行一次编译（为了节省 bibisect 仓库的体积），这样的情况下 bibisect 的结果是只能将源代码 commit 范围锁定在一个比较小的范围内，再由开发者去判断到底是哪个 commit 造成了 bug（在 bugzilla 上会将这个 bug 标记关键词为 bibisected）。但是最新的几个bibisect 仓库中基本上都是每个源代码 commit 编译一次并放到 bibisect 仓库中，这种情况下 bibisect 完成后实际上就已经 bisect 了（这个 bug 可以被同时标记为 bibisect和 bisect）。
Bibisect 的详细说明，以及QA 团队的官方 bibisect 仓库可以在 wiki 页面上找到（中文翻译）：
https://wiki.documentfoundation.org/QA/Bibisect/zh-hans
由于每个 bibisect 仓库体积会很大，所以墙内的网速根本无法克隆，影响大家的参与度。我很早之前通过科学方式克隆了几个，最近又在自己通过源代码构建的方式自己做 bibisect 仓库，现分享如下，见以下链接中以 “bibisect” 开头的仓库：
https://go.suokunlong.cn:88/cgit # 克隆方式请见各仓库下面的 clone
其中：
- bibisect-linux-64-6.0：涵盖从 libreoffice-5-4-branch-point 到 libreoffice-6-0-branch-point 之间的源代码 commit 对应的二进制构建，以及后续 libreoffice-6-0 分支上的构建。
- bibisect-linux-64-6.1：暂缺，最近一段时间国外网站访问速度太太太慢了，欢迎补充。
- bibisect-linux-64-6.2：涵盖从 libreoffice-6-1-branch-point 到 libreoffice-6-2-branch-point，以及后续 libreoffice-6-2 分支。
- bibisect-linux-64-6.3：涵盖从 libreoffice-6-2-branch-point 到 libreoffice-6-3-branch-point，以及后续 libreoffice-6-3 分支。
- bibisect-linux-64-7.0-CN：我自己构建的仓库，涵盖从 libreoffice-6-4-branch-point 到将来的 libreoffice-7-0-branch-point，仅包含 master 分支，启用了简体中文和繁体中文界面。
我用于构建 bibisect 仓库的 Python 源代码可以在以下位置找到：
https://go.suokunlong.cn:88/cgit/lo/bibisect_tool/
四、每日构建版
Windows 下的我没有，自己去 https://dev-builds.libreoffice.org/ 下载吧，墙外。
Linux 下，如果你不想克隆整个的 bibisect 仓库，又想测试master分支上的最新版本，那最简单的方法是：
# 使用 --depth=1 可以只克隆最近一次的版本，检出前大小为 200 多 MB。 git clone --depth=1 git://go.suokunlong.cn/lo/bibisect-linux-64-7.0-CN # 后续可以再通过 git pull 抓取新的： cd bibisect-linux-64-7.0-CN git pull
五、带调试符号 debug symbol 的版本
debug 版本可以用来在程序崩溃时很容易地生成 backtrace。这个不会频繁构建，只是偶尔更新：
https://go.suokunlong.cn:88/dl/libreoffice/dbg/
有问题请直接在下面或者论坛留言。
Leave a Reply