February 2021 - Dev - mailweb.openeuler.org

关于go 的归属
by Erik Yuan 05 Feb '21

05 Feb '21

Hi, 请教一下各位，Go目前在openEuler是归属哪个 SIG的领地？是 Golang SIG(目前可能归并到了CloudNative SIG了）？ Programming-language？还是专有的 SIG组来统领诸多的Go相关组件... 谢谢！

5 5

安全委员会例会
by openEuler conference 04 Feb '21

04 Feb '21

2 1

Re: 关于go 的归属
by jingrui 03 Feb '21

03 Feb '21

Hi, Golang已经广泛在云原生项目使用，目前还是独立SIG，后续云原生仍是top支持场景。 BR.

1 0

RISC-V SIG例会
by openEuler conference 03 Feb '21

03 Feb '21

1 0

【openEuler工程系统维护通知】2021-02-03 17:30~2021-02-03 24:00 openEuler构建系统进行IO升级，维护期间门禁会受影响。
by Hufeng (Solar, Euler) 03 Feb '21

03 Feb '21

openEuler社区广大贡献者：大家好，先给大家拜个早年。 openEuler社区在大家1年多的努力下，社区仓库数已经达到7676个。后台编译系统支撑2036个项目，45650个软件包编译，与大家一年来的贡献密切相关，很感谢大家的辛苦付出。高兴的同时，构建系统也迎来了巨大的挑战， IO拥塞是影响编译效率的关键问题，本次计划于2020/2/3 17:30~24:00对IO进行升级，提升系统编译效率。同时openEuler 21.03发布期限临近，今天会同时对所有仓库建立21.03的分支，版本测试期间内分支会处于冻结状态，冻结后除了maintainer还需要release manage的委员同时审批才能合入。此举是为了保证21.03尽快稳定，并发布给大家，希望大家理解。对大家工作造成的影响，深表歉意。 ------- release management sig

1 0

【合规工作组例会纪要】 SIG-complaince meeting note
by Gaokun (King) 02 Feb '21

02 Feb '21

时间：2021年2月2日早上10：00- 11：00（北京时间）感谢各位小伙伴的支持和关注，今天的例会共有30+人参加，最高峰有28人同时在线，可以看到合规的问题大家还是很重视的。会议纪要： 1、针对openEuler当前社区提供的70+ license清单，高琨、李自和张伟律师制定了表格，内容包括了权力、义务和限制条件并在会上进行了解读。待再次校验之后，会在合规SIG的网页上展示。 2、会上有小伙伴问到了自由软件和商用的关系，两者是没有直接关系的。 3、会上讨论可以在合规的repo提交issue来讨论问题，很感谢三位贡献者 @ weidongkl<https://gitee.com/weidongkl> @ jzm369<https://gitee.com/jinzhimin369> @ haochen<https://gitee.com/haochenstar> 今天提的issue： https://gitee.com/openeuler/compliance/issues/I34W2J?from=project-issue https://gitee.com/openeuler/compliance/issues/I34LMI?from=project-issue https://gitee.com/openeuler/compliance/issues/I34K14?from=project-issue 我们已经全部进行了答复，有问题欢迎继续讨论。高琨 The English version is below the dividing line. Time: February 2, 2021, 10:00 - 11:00 AM Beijing time Thank you for your support and attention. Today's regular meeting was attended by more than 30 people, and 28 people were online at the peak. We can feel that compliance are very important to you. Meeting Minutes: 1. According to the 70+ license list provided by the OpenEuler community, Gao Kun, Li Zi, and lawer Zhang Wei developed a table, including rights, obligations, and restrictions, and interpreted the form at the meeting. After the verification is table again, the information will display on the compliance SIG web page. 2. Some attender asked about the relationship between free software and commercial software.Answer is there is no directly relationship between them. 3. For discussion at the meeting, you can submit issues in the compliance repo to discuss issues. We are grateful to the three contributors @ weidongkl @ jzm369 @ haochen for all open issues today： https://gitee.com/openeuler/compliance/issues/I34W2J?from=project-issue https://gitee.com/openeuler/compliance/issues/I34LMI?from=project-issue https://gitee.com/openeuler/compliance/issues/I34K14?from=project-issue We have responded to all the issues. You are welcome to continue the discussion. King

1 0

sig openstack 例会
by openEuler conference 02 Feb '21

02 Feb '21

1 0

openEuler 社区 2021 年 1 月运作报告
by Huxinwei 02 Feb '21

02 Feb '21

[cid:image001.jpg@01D6F990.A8CA5ED0] 技术委员会的改变在过去的 2020 年年尾，技术委员会经历了第一次增改选，团队的规模从7人增加到17人。这次变动的根本原因是社区快速发展，需要一个更大的领域间合作讨论平台。这次新增的技术委员会委员中，既有各家厂商的资深从业者，也有社区里广受尊敬的“老神仙”，还有华为公司在各个领域的专家。如果说共同点的话，这些伙伴们在 2020 都深度参与了 openEuler 社区的运作，也对openEuler的发展贡献良多。 1. 卞乃猛 bian_naimeng(a)hoperun.com<mailto:bian_naimeng@hoperun.com> [@biannm<https://gitee.com/biannm>] 2. 陈祺德 dillon.chen(a)turbolinux.com.cn<mailto:dillon.chen@turbolinux.com.cn> [@dillon_chen<https://gitee.com/dillon_chen>] 3. 冯健 jian.feng(a)i-soft.com.cn<mailto:jian.feng@i-soft.com.cn> [@hostfj<https://gitee.com/hostfj>] 4. 郭寒军 guohanjun(a)huawei.com<mailto:guohanjun@huawei.com> [@hanjun-guo<https://gitee.com/hanjun-guo>] 5. 侯健 houjian(a)kylinos.cn<mailto:houjian@kylinos.cn> [@hjimmy<https://gitee.com/hjimmy>] 6. 胡欣蔚 huxinwei(a)huawei.com<mailto:huxinwei@huawei.com> [@shinwell_hu<https://gitee.com/shinwell_hu>] 7. 姜振华 zhenhua.jiang(a)huawei.com<mailto:zhenhua.jiang@huawei.com> [@Ronnie_Jiang<https://gitee.com/Ronnie_Jiang>] 8. 刘金刚 liujingang09(a)huawei.com<mailto:liujingang09@huawei.com> [@liujingang09<https://gitee.com/liujingang09>] 9. 李永强 liyongqiang10(a)huawei.com<mailto:liyongqiang10@huawei.com> [@charlie_li<https://gitee.com/charlie_li>] 10. 马全一 eli(a)patch.sh<mailto:eli@patch.sh> [@genedna<https://gitee.com/genedna>] 11. 石勇 shiyong(a)kylinos.com.cn<mailto:shiyong@kylinos.com.cn> [@stonefly<https://gitee.com/stonefly>] 12. 王建民 jianmin(a)iscas.ac.cn<mailto:jianmin@iscas.ac.cn> [@jianminw<https://gitee.com/jianminw>] 13. 王志钢 wangzhigang17(a)huawei.com<mailto:wangzhigang17@huawei.com> [@cellfaint<https://gitee.com/cellfaint>] 14. 魏伟 weiwei64(a)huawei.com<mailto:weiwei64@huawei.com> [@wweiandrew<https://gitee.com/wweiandrew>] 15. 吴峰光 wufengguang(a)huawei.com<mailto:wufengguang@huawei.com> [@wu_fengguang<https://gitee.com/wu_fengguang>] 16. 熊伟 xiongwei888(a)huawei.com<mailto:xiongwei888@huawei.com> [@myeuler<https://gitee.com/myeuler>] 17. 叶青龙 yeqinglong(a)uniontech.com<mailto:yeqinglong@uniontech.com> [@yeqinglong01<https://gitee.com/yeqinglong01>] 大家基于不同的背景和出发点，分享共同的愿景。希望在2021年里，通过各位小伙伴的共同努力，把 openEuler 社区运作的更好。 1月新成立的 SIG 到1月底，openEuler 社区已经有了 77 个 SIG，我们借助一张图来更直观的展示下。新增的SIG用红色的星号做了标记。 [cid:image002.png@01D6F990.A8CA5ED0] 其中，Container SIG 改名为 Cloud Native SIG。经过多方协调，新的SIG负责的范围扩大了。包括 OKD SIG 中维护的基础软件包也已经并入了 Cloud Native SIG。相应的，Kubernetes SIG更名为 KuberSphere SIG，后续会更加聚焦。openEuler 的公众号近期也会有专文阐释,欢迎大家关注。 [cid:image003.jpg@01D6F990.A8CA5ED0] Cloud Native SIG是一个非常重要的SIG，它承载了openEuler云原生的重要工作，也是未来openEuler 21.09的核心特性之一。希望该SIG能将openEuler带入到激动人心的云原生时代。新成立的Compliance SIG是由开源软件专家高琨 (@king-gao<https://gitee.com/king-gao>)所发起，也得到了麒麟信安和润和的积极响应。这个SIG的目标是帮助快速发展的 openEuler 社区满足合规要求，包括社区中片段引用代码带来的版权风险，不同开源软件组件的License自动化识别，以及对License之前潜在冲突的提前分析。我们也希望Compliance SIG能够为国内的软件合规做出样板，同时能够积累出一系列软件工具，为行业提供公共的能力服务。朱家法(@wl1587<https://gitee.com/wl1587>)和吕修任(@lllxxxrrr<https://gitee.com/lllxxxrrr>)在 openEuler 中发起了面向嵌入式场景的 Embedded SIG。这个SIG主要关注将 openEuler 中的开源组件，通过裁剪定制，形成更加适合嵌入式环境中使用的版本。这也是社区走向多样化的必经之路。我们也希望通过Embedded SIG将openEuler社区打造成端、边、云一体化的基础设施平台，同时真正实现整个架构设计的“榫卯”化。 OPS SIG则是社区已经酝酿了很久的SIG，内核热替换等关键技术，将通过这个SIG的工作，进入 openEuler 社区和版本。在21.03这个即将发布的版本中，大家将会见到这个期待已久的新特性的正式亮相。除了这些之外，1月最意外的，还要算袁德俊老师(@yuandj<https://gitee.com/yuandj>)申请的 minzuchess （民族棋）这个SIG。袁老师一直致力于推广人工智能与中国非遗文化传承的结合。这次在社区申请成立的SIG，也是希望通过共性技术沉淀，让青少年可以参与到多民族多游戏样本的开发中来。之前没有想到过 openEuler 社区还会和青少年教育，民族文化传承等建立联系。要感谢袁老师和这个SIG的导师王建民(@jianminw<https://gitee.com/jianminw>)，让我们看到了 openEuler 跨界的可能。随着开源文化在国内的逐步推广和深入人心，我们相信这样的跨界还会发生。 20.03 LTS SP1 发布 2020 年 12 月的最后一周，openEuler 20.03 LTS 的第一个 SP 版本发布了<https://openeuler.org/zh/news/20201228.html>。这个版本中对操作系统内核、虚拟化，JDK 等领域都做了一定的增强，修复了306个已知的安全漏洞，更重要的是集成了社区伙伴们贡献的 UKUI 桌面，DDE 桌面，Pacemaker + Corosync 高可靠集群软件等解决方案。围绕第一个SP版本的发布，Release Management SIG和社区合作伙伴对于 openEuler LTS 的维护策略有非常多的讨论，技术委员会也看到不少下游的用户希望能够就维护策略做进一步的讨论。对于 openEuler 的维护策略的讨论，本质上是社区需要给合作伙伴和用户对未来的一个明确预期。而从技术委员会的角度，我觉得更重要的是先对 “LTS” 有个统一的认识。忒休斯之船古希腊作家普鲁塔克讲过这样一个传说，忒休斯回雅典时乘坐的30桨船被雅典人作为纪念碑保留下来，随着时间流逝，木材腐朽，而雅典人会用新的木头来替代。最后，船上每一根木头都被换过了。那这艘船，还是原来的忒休斯之船吗？我们看两个例子：从用户态软件的角度，CentOS 在 7 系列生命周期中，用户态软件的变化：版本软件总数新增删除版本更新同版本二进制不兼容完全未变化 7.0 2481 NA NA NA NA NA 7.1 2523 43 1 167 228 2085 7.2 2587 68 4 323 303 1893 7.3 2640 54 1 219 334 2033 7.4 2682 60 18 413 242 1967 7.5 2743 61 0 214 283 2185 基本上来说，每个小版本升级，大约有 20%~30% 的用户态软件会发生变化。这里有一些是因为版本的更新，有一些版本未变但是因为二进制不兼容而做了重新构建。而对于系统最基本的内核来说，虽然版本号未变化，但内核的接口也是在不断演进的，还是用CentOS 作为例子：内核接口总数 8.0 -> 8.1 KABI变化 8.1 -> 8.2 KABI变化 8.0 -> 8.2 KABI变化数量 18903 6324 5755 7963 比例 100% 33.4% 30.4% 42.1% 从CentOS 8发布到现在，已经有超过 40% 的内核接口二进制不再兼容。这是不是和传统中“长期稳定版本”一成不变的印象不太一样呢？像 openEuler 这样集成了大量的开源软件，每个软件自己的演进节奏，兼容性保持和版本维护策略，都是不一样的。我们的挑战，就是把零散不同的演进节奏，兼容性保持和版本维护策略，整合而形成一个统一的策略。像一条忒休斯之船，无时无刻不在变化，但又不让人觉得有变化。 openEuler 维护策略发展方向 openEuler 社区在2020年就软件包的管理策略有过长时间的讨论，最新版本归档在这里： https://gitee.com/openeuler/community/blob/master/zh/technical-committee/go… 其中明确提到，对LTS软件版本生命周期内的软件选型要求，以及软件升级时要关注的差异分析要求。与之相对应的，openEuler 也在 CI 中设立了兼容性检查的门禁，每一次提交，都会触发系统自动对ABI的变化进行检查。比如：https://gitee.com/src-openeuler/p… 中，我们看到 check_abi 被自动执行，并且结果也能直观看到。当一个软件本身的兼容性变化被检查到时，相应所有依赖这个软件的组件，都会被触发做相应的修改。但从社区到用户场景，还有很大的鸿沟需要越过。在当前的用户场景中，软件兼容性大部分情况下都只是一个抽象的概念，这使得软件变更的影响像个混沌系统。太平洋西岸的蝴蝶扇动翅膀，可能会造成太平洋东岸的飓风。我们就遇到过这样的情况，因为一个内核接口的变更，造成 NVIDIA 驱动必须随之升级，而驱动的升级又要求上层的 CUDA 版本升级，新的 CUDA 必须使用新的 TensorRT。最终，新版本的 TensorRT 上线，因为新旧版本之间的计算精度差异，造成用户场景下当前使用的 AI 算法和模型统统失效。从操作系统角度，通过内核，驱动，函数库，中间件的联动升级，实现了内部兼容性问题解决的闭环。但当场景延伸到用户场景时，兼容性还是出现了失控。所以从长期来看，我认为维护策略的核心是识别用户场景中真正的兼容性要求。建议 Release Management SIG在沟通讨论时重点关注这一点，技术委员会也会从工具和方法论角度给出支持。小结为了openEuler 21.03 创新版本，最近社区多了很多新的贡献者。也有很多贡献者，因为 openEuler 在建仓提交管理上的要求，感觉深受折磨。我想借这个机会稍微说明下。 1月18日的一个新闻曾经引起了很多人的注意，Flash停更造成大连铁路系统瘫痪<https://www.163.com/dy/article/G0KC2HQA0545AUFL.html> 。乍看起来，个别单位对软件生命周期管理不重视而造成事故，这种情况只是个例；开源开放的操作系统，关注的人多，高灯下亮，应该没有个问题。但从2020年的实际分析来看，不仅不是高灯下亮，反而是灯下黑。在广泛使用的开源操作系统里，类似的问题并不鲜见。比如 libdb 数据库，早在2012年就已经从开源转闭源，而有些重要的基础工具依然在坚持引用闭源之前的最后一个版本；而开发人员弃坑，软件本身却依然被广泛依赖的场景更是随处可见。为什么这个问题没有得到社区的关注？一个间接的佐证来自对最近的 sudo 高危安全漏洞 CVE-2021-3156的分析。在 Y Combinator的讨论贴<https://news.ycombinator.com/item?id=25921811> 中，有从业者表示： “All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested…As long as this type of thing continues, our tools will remain at a very low level of safety, reliability, and correctness.” 换言之，Linux用户态的大多数软件不是没有安全问题，而是测试不足没有发现。一方面是软件上游社区停止维护，另一方面是测试不足没有发现问题，后者掩盖了前者的存在。而对一些操作系统发行版的盲目信赖，让很多人选择性地忽视了后者。 openEuler 认为必须通过透明有效的开发管理和测试来提升社区整体的安全，可靠和正确性。这条路当然是要艰难得多，但想到 openEuler 会越来越多被用在国计民生等关键场景中，社区中的伙伴们也都有了一份责任感和使命感。艾尔帕西诺在"闻香识女人"里有段著名的台词，我常常拿来勉励自己。 “Now l have come to the crossroads in my life. l always knew what the right path was. Without exception, l knew, but l never took it. You know why? lt was too damn hard.” 在此感谢大家和 openEuler 一起选择 “对” 的道路。 from openEuler TC

1 0

Compiler SIG双周例会
by openEuler conference 02 Feb '21

02 Feb '21

2 1

【月度例行update】openEuler 20.03 LTS SP1 Update 20210130 release评审通知
by Hufeng (Solar, Euler) 02 Feb '21

02 Feb '21

openEuler 20.03 LTS Update 20210130已经测试完成。请TC委员，Release委员，QA委员在issue内答复评审意见，欢迎广大开发者对本次发布发表意见，您的每条意见我们都会认真对待，并加以改进。如果您发现了版本的致命问题请及时在issue内回复或者邮件通知我们，2021年2月5日关闭该发布电子流。 https://gitee.com/openeuler/release-management/issues/I34VSC?from=project-i… 版本测试意见：测试策略：本次LTS版本月度update版本的测试策略如下： 1、发布软件包对应的日构建版本冒烟验证 2、发布软件包的安装升级管理操作验证 1)验证本次发布软件包的升级正确性符合用户实际使用场景从3月份版本直接升级选取中间版本进行升级 2)发布软件包管理验证升级后的卸载与回退 3、本次发布软件包提供服务的管理操作验证(启动/停止/重启等) 4、软件包升级后操作系统的基本功能和集成验证； 5、升级后的系统重启/长稳 5、内核LTP和OS的基本benchmark性能验证 6、本次发布范围中重点软件包基本功能验证整体测试结论如下： 1、软件包的升级、降级、卸载正常 2、软件包升级后基本功能、命令、服务测试无问题 3、升级后系统的重启操作正常 4、升级后系统的基本性能指标和LTS基本持平 5、版本测试过程中发现问题均已修复并回归通过版本目标：CVE和Bugfix修复版本计划：例行CVE冻结（20号之后发现的9分以下CVE纳入2021年2月版本）：20210120 代码冻结：20210120 转测试时间：20211225 版本发布：20210202 本次更新涉及，涉及kernel/qemu更新，需要补充性能测试，python包功能测试。修复cve：76个发布源码包34个 arm二进制包311个 x86二进制包309个 CVE清单： CVE score status CVE-2020-8231 7.5 完成 CVE-2020-8286 7.5 完成 CVE-2020-8285 7.5 完成 CVE-2020-8284 3.7 完成 CVE-2020-14351 7.8 完成 CVE-2020-27675 4.7 完成 CVE-2020-25656 4.1 完成 CVE-2020-12352 6.5 完成 CVE-2020-29661 7.8 完成 CVE-2020-27777 6.7 完成 CVE-2020-29660 4.4 完成 CVE-2020-29569 8.8 完成 CVE-2019-13377 5.9 完成 CVE-2019-12519 9.8 完成 CVE-2020-26570 5.5 完成 CVE-2019-20352 7.1 完成 CVE-2020-24241 5.5 完成 CVE-2020-28896 7.5 完成 CVE-2019-15026 7.5 完成 CVE-2020-27762 5.5 完成 CVE-2020-27766 7.8 完成 CVE-2020-27761 3.3 完成 CVE-2020-27767 3.3 完成 CVE-2020-27764 3.3 完成 CVE-2020-27770 5.5 完成 CVE-2020-27759 3.3 完成 CVE-2020-27760 5.5 完成 CVE-2020-27765 3.3 完成 CVE-2020-29599 7.8 完成 CVE-2019-16707 6.5 完成 CVE-2020-11526 2.2 完成 CVE-2020-11522 6.5 完成 CVE-2020-11524 6.6 完成 CVE-2020-11521 6.6 完成 CVE-2020-11525 2.2 完成 CVE-2020-11523 6.6 完成 CVE-2019-17177 7.5 完成 CVE-2020-11044 2.2 完成 CVE-2020-11042 5.9 完成 CVE-2020-11095 5.4 完成 CVE-2020-11045 3.3 完成 CVE-2019-18804 7.5 完成 CVE-2019-15144 6.5 完成 CVE-2019-15143 6.5 完成 CVE-2019-15142 6.5 完成 CVE-2019-15145 6.5 完成 CVE-2020-12059 7.5 完成 CVE-2020-14339 8.8 完成 CVE-2020-29509 5.6 完成 CVE-2020-29363 9.8 完成 CVE-2020-29361 7.5 完成 CVE-2020-29362 9.1 完成 CVE-2020-15890 7.5 完成 CVE-2020-28196 7.5 完成 CVE-2020-1971 5.9 完成 CVE-2020-27821 6 完成 CVE-2019-25013 7.5 完成 CVE-2014-9640 5 完成 CVE-2019-17362 9.1 完成 CVE-2019-16319 7.5 完成 CVE-2020-7059 9.1 完成 CVE-2020-7062 7.5 完成 CVE-2020-7071 7.5 完成 CVE-2019-13456 6.5 完成 CVE-2019-17185 7.5 完成 CVE-2020-24455 4.1 完成 CVE-2019-15892 7.5 完成 CVE-2020-12867 5.5 完成 CVE-2020-14019 9.8 完成 CVE-2020-35490 8.1 完成 CVE-2020-35728 8.1 完成 CVE-2020-35491 8.1 完成 CVE-2020-26259 6.8 完成 CVE-2020-26258 7.7 完成 CVE-2019-0210 7.5 完成 CVE-2019-0205 7.5 完成涉及软件仓清单 src-openEuler/curl src-openEuler/kernel src-openEuler/wpa_supplicant src-openEuler/squid src-openEuler/opensc src-openEuler/nasm src-openEuler/mutt src-openEuler/memcached src-openEuler/ImageMagick src-openEuler/hunspell src-openEuler/freerdp src-openEuler/djvulibre src-openEuler/ceph src-openEuler/libvirt src-openEuler/golang src-openEuler/p11-kit src-openEuler/luajit src-openEuler/krb5 src-openEuler/openssl src-openEuler/qemu src-openEuler/glibc src-openEuler/vorbis-tools src-openEuler/libtomcrypt src-openEuler/wireshark src-openEuler/php src-openEuler/freeradius src-openEuler/tpm2-tss src-openEuler/varnish src-openEuler/sane-backends src-openEuler/libguestfs src-openEuler/python-rtslib src-openEuler/jackson-databind src-openEuler/xstream src-openEuler/thrift

1 0

2024

2023

2022

2021

2020

2019

Dev February 2021