- Tc - mailweb.openeuler.org

sig-ai-bigdata regular meeting
by openEuler conference 24 Nov '20

24 Nov '20

1 0

release-management sig 例会
by openEuler conference 23 Nov '20

23 Nov '20

1 0

答复: 关于麒麟HA引入SP1-Epol的策略说明
by xiasenlin 23 Nov '20

23 Nov '20

补充说明：为保证工程构建一致性和稳定性， https://117.78.1.88/project/show/Epol_HA 的权限回收，相关修改只能由我们来做。发件人: xiasenlin 发送时间: 2020年11月23日 17:17 收件人: Jiangzhenhua (Ronnie, Kunpeng Computing) <zhenhua.jiang(a)huawei.com>; Hufeng (Solar, Euler) <solar.hu(a)huawei.com>; liyongqiang (H) <liyongqiang10(a)huawei.com>; 'jiangxinyu(a)kylinos.cn' <jiangxinyu(a)kylinos.cn>; 'tc' <tc(a)openeuler.org> 抄送: huanghaitao (A) <huanghaitao8(a)huawei.com>; Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com>; Leiju (kunpeng) <leiju4(a)huawei.com>; yaokai (G) <yaokai13(a)huawei.com>; 'yangzhao1(a)kylinos.cn' <yangzhao1(a)kylinos.cn> 主题: 关于麒麟HA引入SP1-Epol的策略说明 OBS私有工程： https://117.78.1.88/project/show/Epol_HA 引入HA策略： 1．基于私有工程Epol_HA分析、构建HA所有组件（包括编译和安装依赖闭环），确保meta里面只依赖 openEuler:20.03:LTS:SP1<https://117.78.1.88/project/show/openEuler:20.03:LTS:SP1> openEuler:20.03:LTS:SP1:Epol<https://117.78.1.88/project/show/openEuler:20.03:LTS:SP1:Epol> 2．打开Epol_HA的check，暴露出所有组件可能隐含的测试用例的问题，请麒麟的同学一起解决； 3．涉及SP1/Epol已有组件的版本变更，要做好差异分析（特别是接口变更）及升级的影响分析，必须满足前向兼容； 4．涉及新引入Epol的组件，应满足开源友好，可维护，必须通过单包校验，验证安装、卸载、升级； 5．关键功能验证由麒麟同学主导

1 0

openEuler 20.03 LTS SP1转测试通知
by Hufeng (Solar, Euler) 23 Nov '20

23 Nov '20

目前通过和大家核对，以下特性除HA延期交付外，其他特性均完成合入。版本进入第一轮正式转测试。测试期间发现的问题，请一并提issue，里程碑选择openEuler-20.03-LTS-SP1。方便问题过滤。请相关责任人更新特性进展为Testing。 HA经过和sig组责任人沟通，当前暂不合入SP1版本。相关sig组同步进行测试，12月10日评审测试报告（包含两轮测试结论），评审通过后合入20.03 LTS SP1 EPOL工程。进行最后一轮回归。版本取用路径如下： http://117.78.1.88:82/dailybuilds/openeuler/openEuler-20.03-LTS-SP1/openeul… 该版本为测试周期内版本，仅用于测试，严禁商用，除版本测试必须的人员外，请勿扩散。扩散和商用导致的后果openEuler社区不承担任何责任。 Release计划路径 https://gitee.com/openeuler/release-management/blob/master/openEuler-20.03-… Release plan Stange name Begin time End time Develop 2020-10-12 2020-11-7 Comptibility 2020-11-8 2020-11-18 Buil 2020-11-19 2020-11-21 Test round 1（we are here） 2020-11-23 2020-11-28 Test round 2 2020-11-30 2020-12-5 Test round 3 2020-12-7 2020-12-12 Test round 4 2020-12-14 2020-12-19 release 2020-12-21 2020-12-22 Feture list no fetur status sig owner 1 openEuler 20.03 LTS SP1支持高可用pacemaker<https://gitee.com/openeuler/release-management/issues/I23GH2?from=project-i…> developing sig-HA yangzhao_kl 2 openEuler 20.03 LTS SP1支持openGauss版本<https://gitee.com/openeuler/release-management/issues/I23GGW?from=project-i…> developing 3 openEuler 20.03 LTS SP1支持1822 HBA卡驱动<https://gitee.com/openeuler/release-management/issues/I23GGR?from=project-i…> developing 4 openEuler 20.03 LTS SP1支持华为多路径<https://gitee.com/openeuler/release-management/issues/I23GGO?from=project-i…> developing 5 openEuler 20.03 LTS SP1支持openStack<https://gitee.com/openeuler/release-management/issues/I23GGJ?from=project-i…> developing sig-python-modules @small_leek<https://gitee.com/small_leek> @hht8<https://gitee.com/hht8> 6 openEuler 20.03 LTS SP1支持金融领域软件包<https://gitee.com/openeuler/release-management/issues/I23GG1?from=project-i…> developing DB @small_leek<https://gitee.com/small_leek> @hht8<https://gitee.com/hht8> 7 openEuler 20.03 LTS SP1支持大数据管理组件Ambari的依赖组件<https://gitee.com/openeuler/release-management/issues/I23GFY?from=project-i…> developing sig-release-management @small_leek<https://gitee.com/small_leek> @hht8<https://gitee.com/hht8> 8 openEuler 20.03 LTS SP1新增DDE组件<https://gitee.com/openeuler/release-management/issues/I23GFR?from=project-i…> developing sig-DDE @panchenbo<https://gitee.com/panchenbo> 9 openEuler 20.03-LTS版本新增criu组件<https://gitee.com/openeuler/release-management/issues/I23GFP?from=project-i…> developing 10 openEuler 20.03 LTS SP1支持libxml，hyperscan<https://gitee.com/openeuler/release-management/issues/I23GFL?from=project-i…> developing Desktop @small_leek<https://gitee.com/small_leek> @hht8<https://gitee.com/hht8> 11 openEuler 20.03 LTS SP1同时支持openjdk多个版本<https://gitee.com/openeuler/release-management/issues/I23GFC?from=project-i…> developing 12 openEuler 20.03 SP1 虚拟化支持内存，cpu热添加<https://gitee.com/openeuler/release-management/issues/I23GF7?from=project-i…> developing Virt @alexchen<https://gitee.com/zhendongchen> 13 openEuler 20.03 SP1 “支持vmtop”<https://gitee.com/openeuler/release-management/issues/I23GF2?from=project-i…> developing Virt @alexchen<https://gitee.com/zhendongchen> 14 openEuler 20.03 LTS SP1虚拟化支持安全启动<https://gitee.com/openeuler/release-management/issues/I23GEY?from=project-i…> developing Virt @alexchen<https://gitee.com/zhendongchen> 15 openEuler 20.03 LTS SP1虚拟化支持custom模式<https://gitee.com/openeuler/release-management/issues/I23GEU?from=project-i…> developing Virt @alexchen<https://gitee.com/zhendongchen> 16 openEuler 20.03 LTS SP1回合20.09 Atune<https://gitee.com/openeuler/release-management/issues/I23GEM?from=project-i…> developing 17 openEuler 20.03 LTS SP1补充SONY使用的依赖包<https://gitee.com/openeuler/release-management/issues/I23GEG?from=project-i…> developing 18 openEuler 20.03 LTS SP1补齐pts安装依赖<https://gitee.com/openeuler/release-management/issues/I23GEC?from=project-i…> developing 19 openEuler 20.03 LTS SP1回合20.09 iSular新版本特性<https://gitee.com/openeuler/release-management/issues/I23GE8?from=project-i…> developing 20 openEuler 20.03 LTS SP1开源openEuler-rpm-config宏<https://gitee.com/openeuler/release-management/issues/I23GDZ?from=project-i…> developing Base-service @small_leek<https://gitee.com/small_leek> @hht8<https://gitee.com/hht8> 21 openEuler 20.03 LTS SP1支持abrt组件<https://gitee.com/openeuler/release-management/issues/I23GDU?from=project-i…> developing Application @small_leek<https://gitee.com/small_leek> @hht8<https://gitee.com/hht8> 22 openEuler 20.03 LTS SP1支持osinfo<https://gitee.com/openeuler/release-management/issues/I23GDP?from=project-i…> developing Base-service @small_leek<https://gitee.com/small_leek> @hht8<https://gitee.com/hht8> 23 microcode_ctl需要回合支持x86<https://gitee.com/openeuler/release-management/issues/I1RFVK?from=project-i…> developing 24 openEuler 20.03 LTS SP1新增 raspberrypi 版本<https://gitee.com/openeuler/release-management/issues/I1RMC1?from=project-i…> developing RaspberryPi @woqidaideshi<https://gitee.com/woqidaideshi> 25 openEuler 20.03 LTS SP1新增UKUI组件<https://gitee.com/openeuler/release-management/issues/I1R54N?from=project-i…> developing sig_UKUI @dou33<https://gitee.com/dou33> 26 openEuler 20.03 LTS SP1新增netinstall组件<https://gitee.com/openeuler/release-management/issues/I1Y26A?from=project-i…> developing sig-OS-Builder @t_feng<https://gitee.com/t_feng> 27 openEuler20.03 LTS SP1版本支持飞腾 arm64架构CPU<https://gitee.com/openeuler/release-management/issues/I1RXGT?from=project-i…> developing 28 openEuler 20.03-LTS版本升级新增bcc的软件包<https://gitee.com/openeuler/release-management/issues/I1O7RM?from=project-i…> developing 29 openEuler 20.03 LTS SP1申请新增maildrop和proftpd软件包<https://gitee.com/openeuler/release-management/issues/I1TWXG?from=project-i…> developing 30 openEuler 20.03 LTS SP1内核开启config_acpi_nfit内核选项<https://gitee.com/openeuler/release-management/issues/I26KWQ?from=project-i…> developing 已知问题序号描述关联软件进展/结论 1 package abrt-atomic-2.13.0-9.oe1.aarch64 conflicts with abrt-addon-ccpp provided by abrt-addon-ccpp-2.13.0-9.oe1.aarch64 abrt 已确认：abrt主包spec中对abrt-atomic下加了Conflicts，会与abrt-addon-ccpp冲突 2 package blktrace-1.2.0-14.oe1.aarch64 obsoletes iowatcher < 1.2.0-14.oe1 provided by iowatcher-1.0-7.oe1.aarch64 iowatcher 已确认：blktrace已提供iowatcher，移除 3 package rdma-core-28.1-3.oe1.aarch64 obsoletes infiniband-diags provided by infiniband-diags-2.1.0-2.oe1.aarch64； package rdma-core-devel-28.1-3.oe1.aarch64 obsoletes infiniband-diags-devel < 28.1-3.oe1 provided by infiniband-diags-devel-2.1.0-2.oe1.aarch64 infiniband 已确认：在rdma-core升级到27.1版本时，已经提供了infiniband-diags的功能，移除 4 package fio-3.7-6.oe1.aarch64 requires libibverbs.so.1()(64bit), but none of the providers can be installed； package fio-3.7-6.oe1.aarch64 requires libibverbs.so.1(IBVERBS_1.0)(64bit), but none of the providers can be installed； package fio-3.7-6.oe1.aarch64 requires libibverbs.so.1(IBVERBS_1.1)(64bit), but none of the providers can be installed； package fio-3.7-6.oe1.aarch64 requires librdmacm.so.1()(64bit), but none of the providers can be installed； package fio-3.7-6.oe1.aarch64 requires librdmacm.so.1(RDMACM_1.0)(64bit), but none of the providers can be installed infiniband 已确认：因为缺少rdma-core提供的库文件，库文件没有，是因为rdma-core跟infiniband-diags冲突没安装上，修改方案同问题3 5 package libkcapi-devel-1.2.0-3.oe1.aarch64 obsoletes libkcapi-tests provided by libkcapi-tests-1.2.0-3.oe1.aarch64 libkcapi-devel 已确认：删除多余的provides 6 package mysql5-5.7.21-2.oe1.aarch64 conflicts with mariadb provided by mariadb-3:10.3.9-9.oe1.aarch64 mysql5 已确认：mysql与mariadb不能同时安装 7 package mvapich2-devel-2.3-8.oe1.aarch64 requires rdma-core-devel, but none of the providers can be installed infiniband 已确认：因为缺少rdma-core提供的库文件，库文件没有，是因为rdma-core跟infiniband-diags冲突没安装上，修改方案同问题3 8 package pulseaudio-gdm-hooks-13.0-2.oe1.aarch64 requires gdm >= 1:2.22.0, but none of the providers can be installed package pulseaudio-gdm-hooks-13.0-2.oe1.aarch64 requires gdm, but none of the providers can be installed package gdm-1:3.30.1-8.oe1.aarch64 obsoletes pulseaudio-gdm-hooks < 1:11.1-17 provided by pulseaudio-gdm-hooks-13.0-2.oe1.aarch64 pulseaudio 已确认：gdm包已提供pulseaudio-gdm-hooks这个功能，移除 9 package python3-abrt-container-addon-2.13.0-9.oe1.aarch64 conflicts with python3-abrt-addon provided by python3-abrt-addon-2.13.0-9.oe1.noarch abrt 已确认：abrt主包spec中对abrt-atomic下加了Conflicts，会与abrt-addon-ccpp冲突 10 package python3-pycryptodome-3.9.7-3.oe1.aarch64 conflicts with python3-crypto <= 2.6.1 provided by python3-crypto-2.6.1-26.oe1.aarch64 python-crypto 已确认：python-crypto衰退软件，python-pycryptodome是python-crypto它的替代软件 11 Pxe安装后无法启动，问题正在确认 Selinux

3 2

关于麒麟HA引入SP1-Epol的策略说明
by xiasenlin 23 Nov '20

23 Nov '20

OBS私有工程： https://117.78.1.88/project/show/Epol_HA 引入HA策略： 1．基于私有工程Epol_HA分析、构建HA所有组件（包括编译和安装依赖闭环），确保meta里面只依赖 openEuler:20.03:LTS:SP1<https://117.78.1.88/project/show/openEuler:20.03:LTS:SP1> openEuler:20.03:LTS:SP1:Epol<https://117.78.1.88/project/show/openEuler:20.03:LTS:SP1:Epol> 2．打开Epol_HA的check，暴露出所有组件可能隐含的测试用例的问题，请麒麟的同学一起解决； 3．涉及SP1/Epol已有组件的版本变更，要做好差异分析（特别是接口变更）及升级的影响分析，必须满足前向兼容； 4．涉及新引入Epol的组件，应满足开源友好，可维护，必须通过单包校验，验证安装、卸载、升级； 5．关键功能验证由麒麟同学主导

1 0

Re: 答复: 【议题申报】openEuler引入chromium浏览器替代firefox的策略决策【请注意，邮件由tc-bounces@openeuler.org代发】
by Zhanghaijian (A) 23 Nov '20

23 Nov '20

1， chrome官方编译文档是否有说明，一定依赖gcc 9+。 Chrome 86 版本有说明依赖gcc 8： addons: apt: sources: - llvm-toolchain-xenial-7 - ubuntu-toolchain-r-test packages: - clang-7 - cmake - gcc-8 - g++-8 - ninja-build 2，需要确认下chrome编译不过是依赖高版本C++的哪些特性，这些特性是何时添加进来的？还是第一个版本就已经有了目前已经发现有依赖C++新特性，是gcc8引入的，目前是通过回合gcc patch和chrome patch解决了7 8个问题，还未完全解决，有些新特性依赖较大，无法直接回合，也无法确认还有多少问题。 From: gaojianxing Sent: Thursday, November 19, 2020 4:50 PM To: 潘晨博 <panchenbo(a)uniontech.com>; Huxinwei <huxinwei(a)huawei.com>; Zhanghaijian (A) <z.zhanghaijian(a)huawei.com>; xiasenlin <xiasenlin1(a)huawei.com>; Jianmin Wang <jianmin(a)iscas.ac.cn>; tc <tc(a)openeuler.org>; Xiexiuqi <xiexiuqi(a)huawei.com> Cc: Hufeng (Solar, Euler) <solar.hu(a)huawei.com>; guoge (A) <guoge1(a)huawei.com> Subject: 答复: Re:[Tc] 答复: 【议题申报】openEuler引入chromium浏览器替代firefox的策略决策【请注意，邮件由tc-bounces(a)openeuler.xn--org-003br75nmgg > 3，如果2问题确认是在某个版本以上chrome才依赖高版本C++，那么是否可以通过降低chrome版本或者spec中去掉部分功能来规避编译问题。当前常用的各浏览器，chrome、firefox、edge、safari 都会不断因解决CVE、适应新的功能需求不断升级，以firefox和chrome为例版本发布周期为4~6周一个稳定版本。要解决CVE漏洞或支持新的功能都会不断推动浏览器升级，无论firefox、chrome或其它浏览器都有这种要求。更换为chrome 是因为firefox升级解决CVE的过程中发现firefox高版本引入存在法务风险，引入低版本的chrome同样面临CVE问题推动需要升级。发件人: 潘晨博 [mailto:panchenbo@uniontech.com] 发送时间: 2020年11月19日 16:18 收件人: Huxinwei <huxinwei(a)huawei.com<mailto:huxinwei@huawei.com>>; Zhanghaijian (A) <z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com>>; xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>>; Jianmin Wang <jianmin(a)iscas.ac.cn<mailto:jianmin@iscas.ac.cn>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; Xiexiuqi <xiexiuqi(a)huawei.com<mailto:xiexiuqi@huawei.com>> 抄送: Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>>; guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>> 主题: Re:[Tc] 答复: 【议题申报】openEuler引入chromium浏览器替代firefox的策略决策【请注意，邮件由tc-bounces(a)openeuler.xn--org-003br75nmgg<mailto:邮件由tc-bounces@openeuler.org代发】> 你好，看到各位讨论chrome浏览器无法通过gcc7.3.0编译，想通过兼容2个版本gcc来实现，方案2确实对于osv厂商来说不太现实，关于这个问题，我有几个疑问，： 1，chrome官方编译文档是否有说明，一定依赖gcc 9+。 2，需要确认下chrome编译不过是依赖高版本C++的哪些特性，这些特性是何时添加进来的？还是第一个版本就已经有了。 3，如果2问题确认是在某个版本以上chrome才依赖高版本C++，那么是否可以通过降低chrome版本或者spec中去掉部分功能来规避编译问题。 From: "Huxinwei <huxinwei(a)huawei.com<mailto:huxinwei@huawei.com>>" To: "Zhanghaijian (A) <z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com>>","xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>>","Jianmin Wang <jianmin(a)iscas.ac.cn<mailto:jianmin@iscas.ac.cn>>","tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>","Xiexiuqi <xiexiuqi(a)huawei.com<mailto:xiexiuqi@huawei.com>>" CC: "Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>>","guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>","gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>>" Sent: 2020-11-19 15:27 Subject: [Tc] 答复: 【议题申报】openEuler引入chromium浏览器替代firefox的策略决策【请注意，邮件由tc-bounces(a)openeuler.xn--org-003br75nmgg<mailto:邮件由tc-bounces@openeuler.org代发】> 这个例子听起来不合理。 so 文件本身是有版本的，也就是so后面的版本后缀。我手边的 Ubuntu 系统里， libstdc++.so.6 是指向 libstdc++.so.6.0.21 的符号链接。所以我问的是为什么不能只依赖带版本号的 libstdc++ 和 libgcc -----邮件原件----- 发件人: Zhanghaijian (A) 发送时间: 2020年11月19日 13:46 收件人: Huxinwei <huxinwei(a)huawei.com<mailto:huxinwei@huawei.com>>; xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>>; Jianmin Wang <jianmin(a)iscas.ac.cn<mailto:jianmin@iscas.ac.cn>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; Xiexiuqi <xiexiuqi(a)huawei.com<mailto:xiexiuqi@huawei.com>> 抄送: Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>>; guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>> 主题: RE: 【议题申报】openEuler引入chromium浏览器替代firefox的策略决策 2. 方案2我不理解为什么安装 Chromium 会引入 gcc 9.3，不应该只在 > 构建的时候引入吗？安装只依赖带版本号的 libstdc++和libgcc？ > 所以这里 chromium 和gcc 7.3不能共存的技术原因是什么？@郭 > 歌 libstdc++.so是运行库，是gcc的一个组件，用gcc9.3编译的Chromium，Chromium会调用gcc9.3的libstdc+ libstdc+++.so的接口，有些接口是高版本引入的，gcc7.3的libstdc++.so并没有提供这些接口，如果OS的gcc还是gcc7.3版本，会导致Chromium加载时找不到这些接口，导致无法运行。昨天刚有个例子：用户用gcc9编了一个工具thin-provisioning-tools，在openEuler20.03上运行报错：nothing provides libstdc++.so.6(GLIBCXX_3.4.26)(64bit) needed by thin-provisioning-tools，就是因为openEuler20.03上的libstdc++.so库是gcc7.3版本，没有GLIBCXX_3.4.26，7.3最高只支持到GLIBCXX_3.4.24 > -----Original Message----- > From: Huxinwei > Sent: Thursday, November 19, 2020 11:40 AM > To: xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>>; Jianmin Wang > <jianmin(a)iscas.ac.cn<mailto:jianmin@iscas.ac.cn>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; Xiexiuqi > <xiexiuqi(a)huawei.com<mailto:xiexiuqi@huawei.com>> > Cc: Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>>; guoge (A) > <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>>; > Zhanghaijian (A) <z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com>> > Subject: RE: 【议题申报】openEuler引入chromium浏览器替代firefox的策 > 略决策 > > 1. 张伟的角色是openEuler社区法务，不是公司法务 > 2. 对三个方案的建议： > 1. 方案1需要安全委员会的意见，其他OSV社区的情况不适合作为我 > 们的参考。 > 2. 方案2我不理解为什么安装 Chromium 会引入 gcc 9.3，不应该只在 > 构建的时候引入吗？安装只依赖带版本号的 libstdc++和libgcc？ > 所以这里 chromium 和gcc 7.3不能共存的技术原因是什么？@郭 > 歌 > 3. 方案3不是独立存在的，先确认方案2的问题吧。 > > 另外，社区讨论，建议不要使用 word 文档 > > > -----Original Message----- > > From: xiasenlin [mailto:xiasenlin1@huawei.com] > > Sent: Thursday, November 19, 2020 10:25 AM > > To: Jianmin Wang <jianmin(a)iscas.ac.cn<mailto:jianmin@iscas.ac.cn>>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; > > Xiexiuqi <xiexiuqi(a)huawei.com<mailto:xiexiuqi@huawei.com>> > > Cc: Hufeng (Solar, Euler) <solar.hu(a)huawei.com<mailto:solar.hu@huawei.com>>; guoge (A) > > <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>>; > > Zhanghaijian (A) <z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com>> > > Subject: [Tc] 【议题申报】openEuler引入chromium浏览器替代firefox的 > 策 > > 略决策 > > > > Hi，各位 TC 委员， > > > > 在上一次申请“升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本 > 一 > > 致以解决firefox升级失败问题”之后，我们尝试引入chromium浏览器替 > 代 > > firefox，目前遇到阻塞问题并提供了可选方案（见附件），因为依然涉及 > 高 > > 版本的gcc，特申请与 TC 委员们和社区成员讨论。 > > 谢谢。 > > > > ——夏森林、章海剑 _______________________________________________ Tc mailing list -- tc(a)openeuler.org<mailto:tc@openeuler.org> To unsubscribe send an email to tc-leave(a)openeuler.org<mailto:tc-leave@openeuler.org>

5 4

[sig-openresty] 寻找 OpenResty SIG 的 maintainer/committer
by Joey Ma 21 Nov '20

21 Nov '20

Hi All, 大家好，我是马俊杰，正在与小伙伴计划将 OpenResty 生态引入至 openEuler 社区。前期经过与 TC 的沟通 [1]，我们将成立 OpenResty SIG 小组负责此项工作，SIG 小组名称暂定为 sig-openresty。本着开源社区“透明、公开”的精神，现面向社区寻找有能力的开发者担任 sig-openresty 的 maintainer/committer，期望您在 OpenResty 生态有所建树，并乐意为 SIG 组贡献自己的智慧。 sig-openresty 的工作内容有： 1. 引入+维护 OpenResty 的依赖包，与其他 SIG 组确定依赖包归属； 2. 引入+维护 OpenResty 核心包，放入 sig-openresty； 3. 引入+维护以 OpenResty 为基础的其他开源项目，如：Kong、Apache APISIX等； 4. ARM64 架构下 OpenResty 生态的调优；另外，目前 sig-openresty 的重要成员已包括： 1. 温铭（maintainer）：OpenResty 软件基金会创始人、OpenResty 软件基金会第一任主席、Apache APISIX 项目 VP； 2. 罗泽轩（maintainer）：OpenResty 核心开发者、Apache APISIX 项目 PMC 成员 3. 刘曦冉（committer）：Apache APISIX 项目 Committer 愿意参与的开发者请直接回复此邮件，时间截至：2020-11-20T20:00:00.00+08:00 。期待与您一起做好 sig-openresty，谢谢。祝好，马俊杰 [1]: https://gitee.com/openeuler/community/pulls/1240

2 1

【议题申报】openEuler引入chromium浏览器替代firefox的策略决策
by xiasenlin 20 Nov '20

20 Nov '20

Hi，各位 TC 委员，在上一次申请“升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致以解决firefox升级失败问题”之后，我们尝试引入chromium浏览器替代firefox，目前遇到阻塞问题并提供了可选方案（见附件），因为依然涉及高版本的gcc，特申请与 TC 委员们和社区成员讨论。谢谢。 ——夏森林、章海剑

6 11

[summit]Last Call: 不要错过在首届线下openEuler Summit 登台演讲的机会
by Liyongle (Fred) 20 Nov '20

20 Nov '20

openEuler Summit 已经得到了大家的很多支持演讲议题、支持单位、SIG、Demo 还在增加但是，申报议题和Demo今天就是 Deadline 了 11月20日23：59截至，不要错过你发展最迅速、最具活力的首届openEuler Summit 展示自己的技术实力赶快点击下方的链接报名申请链接 Call for Speaker<https://shimo.im/forms/XtCTP9jcrXKgjytD/fill> Call for Sponsor<https://shimo.im/forms/VWWtgLsVHzovmbeH/fill> Call for SIG<https://shimo.im/forms/KSMKHGPHIAsjoNHP/fill> Call for Demo<https://shimo.im/forms/lMTsArbYcy4hd2dY/fill> [cid:image001.png@01D6BF24.25DA26F0]<https://openeuler.org/zh/interaction/summit-list/> 在 openEuler Summit 人人都是主办方人人都是参与者这和开源精神的内核是一致的大会议程日益丰满并且干货满满、富有趣味 Hello openEuler 开发者体验区非常的酷因为我们想到了一个从树莓派到数据中心的全场景展示还有其他一些 “别有用心” 的 Demo 绝对的好玩 TC、SIG、Maintainer 已经准备好了 “网友见面” 现场召开 TC 工作会议现场召开 SIG 组工作会议现场接受新 SIG 申请现场的 Maintainer 共同分享学习不断增加的支持单位、友好基金会和社区媒体 [cid:image001.jpg@01D6BF21.1ADA52F0]

1 0

关于openEuler 20.03-LTS-SP1版本中删除python2-virtualenv组件的讨论
by chenyaqiang 19 Nov '20

19 Nov '20

Hi，all 议题：本邮件收集openEuler社区及openEuler相关联使用者对于openEuler 20.03-LTS-SP1版本中删除python2-virtualenv组件，仅保留python3-virtualenv组件的相关建议和意见，如果你对下面的删包方式和兼容性解决方案由其他建议，烦请邮件或者openEuler社区回复讨论。社区issue讨论链接： https://gitee.com/src-openeuler/python-virtualenv/issues/I266XK Python- virtualenv组件功能简介： Python- virtualenv组件主要是用来在同一套开发环境下为每个应用创建一套“隔离”的Python运行环境，用户可以使用Python- virtualenv组件创建多个不同的python运行环境，例如然后在创建的环境中开发项目，隔离项目之间的第三方包依赖，不同项目之间相互不干扰。同时Python<https://wiki.archlinux.org/index.php/Python>从3.3开始包含了venv程序，无需单独安装。如果用户必须使用老版本的Python，例如openEuler 20.03-LTS提供的python 2.7，则需要额外安装<https://wiki.archlinux.org/index.php/%E5%AE%89%E8%A3%85>virtualenv。 Python- virtualenv具体使用方式如下： Python 3 使用 python-virtualenv 提供的 virtualenv。 $ virtualenv venv Python 2 使用 python2-virtualenv 提供的 virtualenv2。 $ virtualenv2 venv Python- virtualenv组件中删除python2-virtualenv子包原因： 1、 openEuler 20.03-LT-Next开发分支定期分析所有组件包upstream社区各个版本状态和质量过程中，同步发现当前python-virtualenv版本是16.0.0，社区于2018.5.17发布该版本，该版本比较老旧，社区当前stable版本已更新到V16.7.10，3年多时间版本更新了21次，新版本中修复了大量bug和CVE，同步引入新的特性支持python 3.x，根据openEuler社区软件包选型规范和策略，python sig考虑跟随upstream社区版本演进路线，同步选型升级到V16.7.10，次新版本变化带来不可避免的ABI变更。具体升级到V16.7.10之后,python2-virtualenv新增大量python2相关子包依赖，详细如下：（1）python2-appdirs ——>SP1分支仅有python3版本（2）python2-distlib ——>SP1分支仅有python3版本（3）python2-contextlib2 ——>版本较低，需要升级才能依赖关系（4）python2-filelock ——>SP1分支仅有python3版本（5）python2-importlib-metadata ——>SP1分支仅有python3版本（6）python2-importlib-resources ——>由python-importlib-resources提供，需要引入python-importlib-resources包 ——> python2-importlib-resources依赖python2-zipp python2-zipp ——>SP1分支仅有python3版本（7）python2-pathlib2 ——>由python-pathlib2提供，需要引入python-pathlib2 ——>python-pathlib2依赖python2-scandir python2-scandir ——> SP1分支仅有python3版本详细变更可以参考： a) https://virtualenv.pypa.io/en/legacy/changes.html#v16-0-0-2018-05-16 b) https://virtualenv.pypa.io/en/latest/changelog.html 2、 openEuler 20.03-LTS及其后续SP版本已明确将于2020.12.30号停止维护python2及其相关子包基于上面2点原因考虑，python sig考虑从openEuler 20.03-LTS-SP1版本开始，删除python2-virtualenv组件，建议对python-virtualenv组件有依赖和使用场景的使用者，推荐使用python3及对应的python-virtualenv组件； Python2-virtuallenv前向兼容性解决方案： Python sig同时考虑到社区部分使用者前期可能存在已使用openEuler 20.03-LTS版本中python2和python2-virtualenv相关组件，为了尽最大可能减少用户使用习惯的改变，本着把“困难留给maintainer自己 ☺ ”，openEuler 20.03-LTS-SP1版本中考虑在该版本的EPOL仓库中继续提供openEuler 20.03-LTS版本中的python2-virtualenv相关组件（仅提供二进制文件，不再承诺该组件的后续CVE和bugfix维护支持），您只需要在安装了openEuler 20.03-LTS-SP1后，配置EPOL软件仓库，使用dnf install python2-virtualenv –y方式（当然rpm –ivh方式也可以），即可安装和继续正常使用python2-virtualenv组件；该兼容性方案已由openEuler python sig验证通过； --------------------------- Best Regards 陈亚强

1 0