- Tc - mailweb.openeuler.org

openEuler kernel sig meeting
by openEuler conference 13 Nov '20

13 Nov '20

2 3

答复: chrome 浏览器，在openEuler-20.03 系列分支编译进展情况
by guoge (A) 13 Nov '20

13 Nov '20

openEuler 20.03 LTS在尝试引入chrome浏览器，目前遇到编译问题目前怀疑需要gcc 8特性，需要具体看下是否可以简单补丁方式解决，否则可能会需要引入gcc 8及以上版本，需要麻烦@章海剑 @谢志恒看下发件人: qiaopeixin 发送时间: 2020年11月13日 10:25 收件人: gaojianxing <gaojianxing(a)huawei.com>; Hufeng (Solar, Euler) <solar.hu(a)huawei.com>; sunguoshuai <sunguoshuai(a)huawei.com>; xiasenlin <xiasenlin1(a)huawei.com> 抄送: guoge (A) <guoge1(a)huawei.com>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com>; tc <tc(a)openeuler.org>; Zhanghaijian (A) <z.zhanghaijian(a)huawei.com> 主题: RE: chrome 浏览器，在openEuler-20.03 系列分支编译进展情况修正2.3: 代码是C++用了C语言结构体的格式。GCC trunk进入8.0.0之前的时候拉出来一个分支gcc-7，后面继续演进直到7.3，都没有修掉这个问题，7.5也没有修掉；trunk 同时继续演进，在8.0.0和9.0.0之间某一个节点修掉了这个问题。所以GCC release的版本中8.1之后的都修掉了这个问题。我找到修掉这个问题的节点后我们分析了一下，该节点依赖不少trunk之前合入的patch， gcc-7没有合入，初步尝试往前追溯了几个patch，都无法打到GCC 7.3.0上。预计需要合入多个patch，短时间无法适配好。祝好，乔沛鑫 From: gaojianxing Sent: Friday, November 13, 2020 9:14 AM To: Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>>; sunguoshuai <sunguoshuai(a)huawei.com<mailto:sunguoshuai@huawei.com>>; xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>>; qiaopeixin <qiaopeixin(a)huawei.com<mailto:qiaopeixin@huawei.com>> Cc: guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>> Subject: chrome 浏览器，在openEuler-20.03 系列分支编译进展情况 Chrome 试引入进展情况： 1、openEuler-20.09 、主线基于gcc 9.3.0 可以正常编译，功能待测试； 2、基于openEuler-20.03-LTS-Next，编译器gcc 7.3.0 版本，已进展如下 2．1、在编译第三方库 libjpeg_turbo 时，vld1_s16_x3 错误，已找到gcc的patch AARCH64-Neon-vld1_-_x3-vst1_-_x2-and-vst1_-_x3-intrinsics.patch 2．2、编译第三方库blink时， “requested alignment is not an integer constant”错误，已找到patch Bogus error with alignof [PR90736] 2．3、编译gpu/vulkan相关文件出错是因为gcc-7 不支持GNU C 方式的c++结构体对象赋值，已通过补丁形式修改chromium vulkan相关代码解决。 ---已解决因gcc相关特性是在gcc-8及以上版本支持的，gcc-7社区没有相关补丁，需要修改的地方比较多，且需要自个做补丁修改，困难较大。 2．4、编译net/dns/dns_query.cc 时出现如下错误，问题还在定位、修复中―已解决合入乔沛鑫提供的patch，PR c++/80452， optional-bug-fix.patch 此部分已编译通过 2．5、当前编译 gpu/command_buffer/service/external_vk_image_backing.cc出现错误，正在修改chromium相应文件。预期上午今天上午解决发件人: gaojianxing 发送时间: 2020年11月11日 18:11 收件人: Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>>; sunguoshuai <sunguoshuai(a)huawei.com<mailto:sunguoshuai@huawei.com>>; xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>> 抄送: guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>>; 'tc' <tc(a)openeuler.org<mailto:tc@openeuler.org>>; '；qiaopeixin(a)huawei.com<mailto:qiaopeixin@huawei.com>' <；qiaopeixin(a)huawei.com<mailto:qiaopeixin@huawei.com>> 主题: 答复: 关于firefox后续版本(firefox82) 因专利问题存在引入风险 Chrome 试引入进展情况： 1、openEuler-20.09 、主线基于gcc 9.3.0 可以正常编译，功能待测试； 2、基于openEuler-20.03-LTS-Next，编译器gcc 7.3.0 版本，已进展如下 2．1、在编译第三方库 libjpeg_turbo 时，vld1_s16_x3 错误，已找到gcc的patch AARCH64-Neon-vld1_-_x3-vst1_-_x2-and-vst1_-_x3-intrinsics.patch 2．2、编译第三方库blink时， “requested alignment is not an integer constant”错误，已找到patch Bogus error with alignof [PR90736] 2．3、当前编译错误如下图，已找到patch，patch commit ID为：d68ddd2b35078ab61f164b268bac63767b2a8e6a，但此patch不能直接合入，需要多个patch解决，正在回溯gcc解决此问题的历史patch。发件人: gaojianxing 发送时间: 2020年11月9日 20:45 收件人: Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>>; sunguoshuai <sunguoshuai(a)huawei.com<mailto:sunguoshuai@huawei.com>>; xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>> 抄送: guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>> 主题: 答复: 关于firefox后续版本(firefox82) 因专利问题存在引入风险 Chrome 试引入进展情况： 1、openEuler-20.09 、主线基于gcc 9.3.0 可以正常编译，功能待测试； 2、基于openEuler-20.03-LTS-Next，编译器gcc 7.3.0 版本，已进展如下 2．1、在编译第三方库 libjpeg_turbo 时，vld1_s16_x3 错误，已找到gcc的patch AARCH64-Neon-vld1_-_x3-vst1_-_x2-and-vst1_-_x3-intrinsics.patch 2．2、编译第三方库blink时， “requested alignment is not an integer constant”错误，已找到patch Bogus error with alignof [PR90736] 2．3、编译gpu/vulkan相关文件出错是因为gcc-7 不支持GNU C 方式的c++结构体对象赋值，已通过补丁形式修改chromium vulkan相关代码解决。 ---已解决因gcc相关特性是在gcc-8及以上版本支持的，gcc-7社区没有相关补丁，需要修改的地方比较多，且需要自个做补丁修改，困难较大。 2．4、编译net/dns/dns_query.cc 时出现如下错误，问题还在定位、修复中 [cid:image001.png@01D6B9AD.4C816EC0] 发件人: Hufeng (Solar, Euler) 发送时间: 2020年11月7日 14:51 收件人: gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>>; sunguoshuai <sunguoshuai(a)huawei.com<mailto:sunguoshuai@huawei.com>>; xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>> 抄送: guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>> 主题: RE: 关于firefox后续版本(firefox82) 因专利问题存在引入风险 20.09ukui有桌面，挂epol的源，可以试试 From: gaojianxing Sent: Friday, November 6, 2020 6:16 PM To: sunguoshuai <sunguoshuai(a)huawei.com<mailto:sunguoshuai@huawei.com>>; xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>> Cc: guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>> Subject: 答复: 关于firefox后续版本(firefox82) 因专利问题存在引入风险 Chrome 试引入进展情况： 1、 openEuler-20.09 、主线基于gcc 9.3.0 可以正常编译，功能未测试（需要GUI界面才能进行测试）; 2、基于openEuler-20.03-LTS-Next，编译器gcc 7.3.0 版本，已发现问题如下 2．1 在编译第三方库 libjpeg_turbo 时，vld1_s16_x3 错误，已找到gcc的patch AARCH64-Neon-vld1_-_x3-vst1_-_x2-and-vst1_-_x3-intrinsics.patch 此patch已合入到私有工程中，并编译通过，相应问题已解决； 2．2 当前错误 blink/renderer/platform/wtf/vector.h:268:58: error: requested alignment is not an integer constant 对应的漏洞原因正在定位中，尝试通过gcc补丁解决。发件人: sunguoshuai 发送时间: 2020年11月4日 17:48 收件人: xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>>; gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>> 抄送: guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>> 主题: 答复: 关于firefox后续版本(firefox82) 因专利问题存在引入风险 Chrome编译时间过长的问题需要提前考虑… Obs上次自己的分支编译了9个多小时发件人: xiasenlin 发送时间: 2020年11月4日 15:45 收件人: gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>> 抄送: guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>>; sunguoshuai <sunguoshuai(a)huawei.com<mailto:sunguoshuai@huawei.com>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>> 主题: 答复: 关于firefox后续版本(firefox82) 因专利问题存在引入风险引入chrome是很好的尝试，意义不止在于替换调更新版本的存在专利问题的firefox，更多的是为了提供更安全的浏览器。接下来需要做的： 1．“在openEuler-20.03及衍生版本中当前gcc是编译不过的（可以尝试gcc打补丁解决）”，具体打什么补丁尽快与编译器同事确认 2．本地编译打包完成之后，要给出进一步的安装和功能验证的自验文档发件人: gaojianxing 发送时间: 2020年11月4日 14:56 收件人: xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>> 抄送: Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>>; sunguoshuai <sunguoshuai(a)huawei.com<mailto:sunguoshuai@huawei.com>>; platform.zhang(a)huawei.com<mailto:platform.zhang@huawei.com>；; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; dev(a)openeuler.org<mailto:dev@openeuler.org> 主题: 关于firefox后续版本(firefox82) 因专利问题存在引入风险 1、当前firefox 在主线已经升级到79版本，openEuler-20.03-LTS 经过适配已经可以升级到79版本，但因下游需求及CVE解决需要，及firefox本身在不断的演进，后续存在升级的需求，注：（当前firefox最新版本已是firefox82） Firefox后续版本流媒编解码依赖于包fdk-acc，fdk-acc包托管于github.com, license经与公司法务张伟咨询发现存在专利权问题：具体见附件的license，有风险部分如下： [cid:image002.png@01D6B9AD.4C816EC0] [cid:image003.png@01D6B9AD.4C816EC0] 2．可采取的解决方案： 2.1．后续采用chromium 浏览器，当前调查不存在专利和license等相关法务风险，但是在openEuler-20.03及衍生版本中当前gcc是编译不过的（可以尝试gcc打补丁解决），当前在主线和09版本引入没有问题； 2.2．继续使用firefox，尝试寻找其它包替代fdk-aac相关包功能（有风险，可能引入的包也有法务问题，且需要解决依赖问题）； 2.3．继续使用firefox，但是firefox后续升级存在法务风险（firefox不升级，但漏洞无法修复）。

1 0

回复：[Dev] Re: 申请修改仓库配置文件格式
by George 12 Nov '20

12 Nov '20

0.      从评审角度，以举例的方式来评审格式是不严谨的。希望有一个规范的格式文件，比如字段的属性，可选项等等。 -- 输出了仓库配置管理格式说明.md 文件，看是否满足要求（ https://github.com/GeorgeCao-hw/georgedoc/blob/master/yaml… 1.      这个yaml文件格式看起来将来还有可能变化，那这次修改应该把格式版本字段加上。 -- 赞同该建议, 在yaml文件开头增加version字段 2.      Branch的type normal 有什么意义吗？ -- branch的type是按照码云分支的类型设置，包括protected，normal，readyonly三个选项,normal分支通常就是非保护分支       3.      Created_from 应该叫fork_from --create_from字段是按照gitee页面新建分支操作上的提示取的，希望和码云一致        4.      这样的branch 会一直增加下去，怎么表示已经衰退或者停止的分支？什么时候删除分支？ --我们考虑删除分支和删除仓库类似，属于高危操作，当前建议是不通过配置文件执行自动删除，    如果确实需要删除可以将该分支从配置文件中删除，然后再到码云仓库中手动删除 5.  你们这个应该只考虑 src-openeuler.yaml 就可以了吧？我没想到需要改 openEuler.yaml 的场景。 -- 如果src-openeuler.yaml改了格式，openeuler.yaml格式不调整， CI-bot需要两套处理逻辑，增加了复杂度。附格式样例： ------------------ 原始邮件 ------------------ 发件人: "Huxinwei" <huxinwei(a)huawei.com>; 发送时间: 2020年11月12日(星期四) 中午1:01 收件人: "George"<caozhi1214(a)qq.com>;"tc(a)openeuler.org"<tc(a)openeuler.org>; 抄送: "dev"<dev(a)openeuler.org>; 主题: [Dev] Re: [Tc] 申请修改仓库配置文件格式你们这个应该只考虑 src-openeuler.yaml 就可以了吧？我没想到需要改 openEuler.yaml 的场景。   以下是我的建议： 0.      从评审角度，以举例的方式来评审格式是不严谨的。希望有一个规范的格式文件，比如字段的属性，可选项等等。 1.      这个yaml文件格式看起来将来还有可能变化，那这次修改应该把格式版本字段加上。 2.      Branch的type normal 有什么意义吗？ 3.      Created_from 应该叫fork_from 4.      这样的branch 会一直增加下去，怎么表示已经衰退或者停止的分支？什么时候删除分支？   From: George [mailto:caozhi1214@qq.com] Sent: Thursday, November 12, 2020 12:05 PM To: tc(a)openeuler.org Cc: dev <dev(a)openeuler.org> Subject: [Tc] 申请修改仓库配置文件格式   Hi，各位TC委员：我是openEuler基础设施SIG的同事。我们在落地【根据仓库配置文件自动创建仓库分支】的需求，需要指定新建分支是基于哪个分支来创建；当前community仓库下配置管理文件 src-openeuler.yaml和openeuler.yaml 的配置项没有包含这个信息，需要新增。现申请修改两个仓库配置文件（src-openeuler.yaml和openeuler.yaml）格式如下，烦请评审一下，谢谢。   老格式：   新格式：注：create_from若为空，默认create_from到master，       type若为空，默认protected  

2 1

关于openEuler 选择 5.10 作为下一个长期维护的内核版本 (公示)
by xiasenlin 12 Nov '20

12 Nov '20

邮件背景：当前海思在维护的KAEdriver（Github主页：https://github.com/kunpengcompute/KAEdriver）基于4.… kernel及openeuler的版本计划： Linux 5.10 预计是 Linux 社区今年的 LTS (long-term support) 版本。openEuler 社区经过多轮沟通，选择 5.10 作为 openEuler 内核的下一个长期维护版本（openEuler Long-term support Kernel, OLK）。openEuler 社区提供不少于4年的维护时间和不少于2年的扩展维护时间。按照规划 openEuler 21.03、21.09 以及 openEuler 22.03 LTS 都将选择该内核版本。（具体时间以openEuler社区官网公布为准）转自：https://gitee.com/openeuler/community/blob/master/sig/Kernel/kernel-upgr…

1 0

申请修改仓库配置文件格式
by George 12 Nov '20

12 Nov '20

Hi，各位TC委员：我是openEuler基础设施SIG的同事。我们在落地【根据仓库配置文件自动创建仓库分支】的需求，需要指定新建分支是基于哪个分支来创建；当前community仓库下配置管理文件 src-openeuler.yaml和openeuler.yaml 的配置项没有包含这个信息，需要新增。现申请修改两个仓库配置文件（src-openeuler.yaml和openeuler.yaml）格式如下，烦请评审一下，谢谢。老格式：新格式：注：create_from若为空，默认create_from到master，       type若为空，默认protected

3 3

【Meeting Notice】openEuler Community TC Regular Meeting Time: 2020-11-04 10:00-12:00
by Meeting Book 11 Nov '20

11 Nov '20

4 4

【例会纪要】openEuler Release-Management SIG meeting
by chenyaqiang 11 Nov '20

11 Nov '20

议题一： pkgship工具Roadmap及纳入openEuler 21.03版本需求讨论；议题主讲人：汪奕如遗留问题： 1、软件包兼容性分级信息是否可以在pkgship网站呈现 A: 当前pkgship 数据库及web页面均已经预留软件包兼容性分级接口，待openEuler社区软件包分级数据收集完成后，对接预留接口，可以直接支持信息查询； 2、如何访问pkgship依赖关系数据库网站？ A：当前pkgship已经提供独立页面支持访问：https://pkgmanage.openeuler.org/ 。后续会在openEuler.org社区主页界面增加pkgship子入口，引导用户访问pkgship；议题二： openEuler 21.03 需求收集---引入python 3.9；议题主讲人：陈亚强遗留问题： 1、openEuler 21.03版本是否集成python 3.9，需要结合python 3.9稳定版本发布计划与openEuler 21.03版本节奏匹配；议题三： openEuler 20.03-LTS SP2计划移除python2及其相关子包；议题主讲人：陈亚强遗留问题： 1、pythpn2.7从标准ISO发布件中移除后，对于其他依赖python2的软件包的影响范围和差异需求梳理清楚，并在社区发起影响分析讨论； 2、openEuler线下交流会议中，同步收集openEuler 20.03-LTS用户对于python2.7移除的意见和建议议题四： openEuler 20.03-LTS SP1版本需求进展及版本计划同步：议题主讲人：胡峰议题五： openEuler 20.03-LTS 10月份补丁版本（update）发布评审；议题主讲人：胡峰 1、版本发布件及发布信息已公示openEuler社区release sig，本周持续收集社区意见及确认完成发布评审go_nogo签署；议题六： openEuler 20.03-LTS SP版本生命周期讨论议题主讲人：刘博 1、openEuler 20.03-LTS 330版本和后续LTS SP版本的生命周期、版本收编方式和收编计划需要在社区、线下交流沟通会议中持续收集建议，SP1发布时明确规范结论，支撑LTS版本在社区维护策略； Topic [WeLink Meeting] openEuler Release-Management SIG meeting Time 2020-11-11 09:30-11:30 ((UTC+08:00)Beijing) Join Conference Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=8c8b822b759dc0a40175afc5be6…> Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=508447837&app=welink> Join (External) >><https://welink-meeting.zoom.us/j/508447837> Meeting ID 508 447 837 Convener 陈亚强 (c00390579) Internal (10) 陈亚强 (c00390579), 朱延朋 (z00482129), 姜振华 (j00509688), 胡峰 (h00275609), 江裕民 (j00285779), 李永强 (l00384083), 明沛 (m00256926), 张伟 (z00444582), 刘博 (l00392858), Ying Wu (y00565703) External (9) fangyafengqidai(a)163.com<mailto:fangyafengqidai@163.com>, jianmin(a)iscas.ac.cn<mailto:jianmin@iscas.ac.cn>, Erik.Yuan(a)arm.com<mailto:Erik.Yuan@arm.com>, panchenbo(a)uniontech.com<mailto:panchenbo@uniontech.com>, pengfeizhou(a)yunify.com<mailto:pengfeizhou@yunify.com>, majunjiev(a)gmail.con<mailto:majunjiev@gmail.con>, release(a)openeuler.org<mailto:release@openeuler.org>, dev(a)openeuler.org<mailto:dev@openeuler.org>, tc(a)openeuler.org<mailto:tc@openeuler.org> Agenda 本次例会议题持续收集中，新增议题直接邮件回复申报即可。已收集议题如下： 1、pkgship工具Roadmap及纳入openEuler 21.03版本需求讨论；议题主讲人：汪奕如 2、openEuler 21.03 需求收集---引入python 3.9；议题主讲人：陈亚强 3、openEuler 20.03 SP版本生命周期审视；议题主讲人：刘博注: 会议最大支持200人同时与会。(A conference supports a maximum of 200 participants.) 外部用户加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。 If external users fail to join a meeting, advise them to download the latest meeting client and try again. 下载链接( DownloadURL ):https://zoom.us/download

1 0

[会议纪要] DDE sig组11月例会
by 潘晨博 11 Nov '20

11 Nov '20

2 1

【请大家在评论区发表意见】openEuler 20.03 LTS Update 20201030 release 评审
by Hufeng (Solar, Euler) 10 Nov '20

10 Nov '20

https://gitee.com/openeuler/release-management/issues/I24KF3?from=project-i… 请大家发表该版本的评审意见。关键角色 QA（补充测试结论），TC委员会、包管理委员会、工程团队、release managment团队暂行评审规范（欢迎提意见） https://gitee.com/openeuler/release-management/blob/master/openEuler%E7%89%…

1 0

【Meeting Notice】openEuler Release-Management SIG meeting Time: 2020-11-11 09:30-11:30
by Meeting Book 10 Nov '20

10 Nov '20

1 0