去 openSUSE factory 邮件列表大声吼，就说 golang-packaging 向前不兼容。吼到越多人知道越好。
个人不喜欢 openSUSE 现在的 golang 维护团队，因为去年就是他们趁我短期不在，把我的 github 个人项目先 fork，然后在软件包里改掉 upstream url，从我手里硬抢走 golang-packaging 维护权，又用 shell 重写的。所以我个人跟这样不尊重开源世界第一作者权利的团队可能无法合作。
或者如果你只是想让 openSUSE 也用上 deepin 而不想去提交到 factory 变成官方支持的 DE 的话，你可以重新包一份 golang-org-x-text 提交到 X11:Deepin，至少我会 accept。
从我的 iPhone 发送，使用 Tapatalk
怪不得之前的版本用的是 rb， 后来是 gobuild.sh 了。 顶 苏女王，现在许多 go 包都需要更新， 但 pkger 好像不是特别勤劳。 哎
（我感觉 suse golang 这套打包方式挺好的， Fedora 就跟没有一样， 所有的 Provides Requires 都需要自己写。 Fedora golang packaging 现在还是个半成品，但是 pkger 特别勤劳，反而 大部分 go 包没什么问题。当然 Fedora 本身只打包 go 源码，没什么出错的概率）
X11:Deepin 不是官方源么？它是类似 Copr 的第三方源么？
我看了一下 devel:languages:go 里面的包，都很新啊。
Fedora 打包者的工程是用 git 保存的，原理应该是背后有个编译机，编译出 srpm。打包者提交到 rawhide，然后 rawhide 用 srpm 重新编译。（不知道说得对不对）那个编译机的返回状态和日志，就像 travis 一样，打包者是能看见的，但是编译机编译成功后产生的待提交 rawhide 的 rpm 们是不可见的，无法下载测试，也无法放在一个在线源里。
openSUSE 的 Factory 相当于 rawhide，但是 openSUSE 同时还开放了那些编译机产生的 rpm 并推送到相应的下载源。这个就是 X11:Deepin 的位置，不是 Copr 那样的第三方源，也是官方的二级开发源，只是还没有像 rawhide 那样进行统一的整合测试，里面成功编译产生的 rpm 只是本身能用。但如果同时装它，再从别的二级开发源装依赖，可能就会彼此不兼容。
二级开发源的模式是让你 fork 的，在你的 fork 里搞定一切，再推过去，所以正常情况下，二级开发源里的包都是能够编译成功的。
Copr 对应的是 Packman，是以上整个体制的一个拷贝，只是容忍了出于各种原因无法在官方源维护的包。
你仔细想想就会发现，二级开发源里的包如果够多，包含了除 gcc 这些基础包的绝大部份依赖（好比一整个 DE 的全部包），那在基础包基本无变化的情况下，它自己的作用跟 Factory 也差不多。其实二级开发源本身就是 factory 按照类别拆出来的一个个小 factory。对用户来说也是能够保证完整性和健壮性的。
从我的 iPhone 发送，使用 Tapatalk
他应该说的是已经在 42.3 oss 里面的 golang-* 包。后来 golang-packaging 又规定了新的位置。导致 TW 里，某个宏指向的位置，跟 42.3 里指向的位置不一样。
还有一个可能就是为了省编译资源，好比因为 golang-packaging 变动导致依赖它的包产生的变动，如果之前编译成功，之后也编译成功，可能就会默认不覆盖。
从我的 iPhone 发送，使用 Tapatalk
rawhide 相当于一锅粥，没有二级开发源。 编译机可以返回状态和日志，以及生成的 rpm/srpm （可下载，但没有放到一个二级源里）。一旦一个包被批准了， 可以很快加入 rawhide。
所以 Fedora 才总跳票啊…
openSUSE 不会，因为所有提交 Factory 的包都要过 openQA，openQA 不是你的包单独分配一个 testcase，而是相关的包归到一个 testcase。比如你的包是 GNOME 相关，而 GNOME 恰好也提交了版本更新，那可能就会等很久。或者说十五个新包放一起，别的包有问题没过编译或者别的毛病，等那个维护者提交修复，这样也会很久的。
从我的 iPhone 发送，使用 Tapatalk
138s] Wrote: /home/abuild/rpmbuild/SRPMS/deepin-mutter-3.20.21-20.1.src.rpm
140s] Wrote: /home/abuild/rpmbuild/RPMS/x86_64/deepin-mutter-3.20.21-20.1.x86_64.rpm
141s] Wrote: /home/abuild/rpmbuild/RPMS/x86_64/deepin-mutter-debugsource-3.20.21-20.1.x86_64.rpm
141s] Wrote: /home/abuild/rpmbuild/RPMS/x86_64/deepin-mutter-devel-3.20.21-20.1.x86_64.rpm
143s] Wrote: /home/abuild/rpmbuild/RPMS/x86_64/deepin-mutter-debuginfo-3.20.21-20.1.x86_64.rpm
143s] Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.oL0rVs
143s] + umask 022
143s] + cd /home/abuild/rpmbuild/BUILD
143s] + cd deepin-mutter-3.20.21
143s] + /usr/bin/rm -rf /home/abuild/rpmbuild/BUILDROOT/deepin-mutter-3.20.21-20.1.x86_64
143s] + exit 0
143s] ... checking for files with abuild user/group
143s] ... running 00-check-install-rpms
143s] ... installing all built rpms
143s] Preparing packages...
143s] deepin-mutter-3.20.21-20.1.x86_64
143s] deepin-mutter-devel-3.20.21-20.1.x86_64
143s] deepin-mutter-debugsource-3.20.21-20.1.x86_64
144s] deepin-mutter-debuginfo-3.20.21-20.1.x86_64
144s] ... running 01-check-debuginfo
144s] ... testing for empty debuginfo packages
144s] ... running 02-check-gcc-output
144s] ... testing for serious compiler warnings
144s] (using /usr/lib/build/checks-data/check_gcc_output)
144s] (using //.build.log)
144s]
144s] I: Program is using implicit definitions of functions getting
144s] pointers or implemented by macros. These functions need to use their
144s] correct prototypes to allow correct argument passing on e.g. x86_64 .
144s] - Implicit memory/string functions need #include <string.h>.
144s] - Implicit *printf functions need #include <stdio.h>.
144s] - Implicit *printf functions need #include <stdio.h>.
144s] - Implicit *read* functions need #include <unistd.h>.
144s] - Implicit *recv* functions need #include <sys/socket.h>.
144s] W: deepin-mutter implicit-pointer-decl compositor/meta-blurred-background-actor.c:301
144s]
144s] I: A function uses a 'return;' statement, but has actually a value
144s] to return, like an integer ('return 42;') or similar.
144s] W: deepin-mutter voidreturn compositor/meta-blur-actor.c:359
144s] E: deepin-mutter 64bit-portability-issue core/prefs.c:1314
女王大人， deepin-mutter 已经编译通过，但是 check fail，被最后那个错误。。。
我想报个 bug，但是 check 提供的信息又太简单， 有 debug 模式么？
New：
我先暂时关闭了 post-build-checks，并发了 issue github.com/linuxdeepin/deepin-mutter/issues/5 。
openSUSE 也有问题，43/42/41 的 clutter-devel 包 缺 /usr/include/clutter-1.0/clutter/evdev/clutter-evdev.h 头文件。 先记录在这里吧
这是一条错误。你去看 meta-blurred-background-actor.c，301 行，肯定用了上面说的 printf/read/recv 这些函数中的一个，却没有包含对应的头文件。
这又是一条错误，meta-blur-actor.c 的 359 行是一个 “return;”，但这个函数是有返回值的，不是 void。你改成 return 0; 应该就能过。
这是一条错误，意思是那行在 64 位平台上可能会出错，一般来说是很简单的溢出问题，比如 int 的 byte 数，开发者默认成 2 了，这样。
这本身就是 debug 模式啊，在会写 C 的人的眼睛里这就是“显然”的错误。想报 bug 直接报就行。一般我都是直接顺手修了然后去交 PR 的。
至于 openSUSE 的那个 clutter 问题，你可以自己做一个 update stack 然后 maintenance request，或者报个 bug 好好说说，应该就能通过更新加上那个头文件。之前没有，可能是因为没有用那个头文件的程序，就“优化”掉没有开那个编译选项了。
从我的 iPhone 发送，使用 Tapatalk
蟹蟹，女神的回复
我刚刚打完 Deepin 的包了， 目前只有 openSUSE_Tumbleweed 可用（post script 未审查 / 未测试）。 42/43 由于 Qt 版本，以及其他各种各样的问题， 关键的包编译不能， 可能只有部分 Deepin 应用可用， DDE 不可用。
build.opensuse.org/package/show/home:1dot75cm:branches:X11:Deepin
把 X11:Deepin 里面没有的包推过来。
好的， 我整理一下
把 changelog 写好。
早知道不删了
go 的包你也解决了？
没有， 我只是把 Go 源码也打包了
X11:Deepin 有些包不需要了， 我可以编辑吗？
X11:Deepin 只有以下包（14 个）需要保留， 其他的上游已经不维护了：
golang-github-burntsushi-xgb
golang-deepin-go-lib
deepin-dbus-generator
golang-deepin-dbus-factory
deepin-gettext-tools
dtkcore
gsettings-qt
dtkwidget
deepin-qml-widgets
deepin-qt-dbus-factory
deepin-menu
deepin-movie
deepin-music
deepin-terminal
凡是 dde- 开头的包名，都将其改成统一的 deepin-， 上游也接受了 felixonmars 的建议，以后命名估计会统一。
PS: 我先把所有的都提交到 X11:Deepin，它们至少可以正常工作。然后肯定有不符合打包规范的地方， 到时候咱们再改？
可以发 delete request 啊，osc dr X11:Deepin dde-x 这样。你可以把包提交过来啊，然后我们就能看哪里不符合打包规范啦。
从我的 iPhone 发送，使用 Tapatalk
好滴呀， 原来还能发 delete request ～
你发过来的包还是写个变更日志啊？不然我们是不接受的。 初次打包的话 initial package 总要写上一句吧。
