October 2024 - Tc - mailweb.openeuler.org

2024 项目之星评选初步结果公示
by 胡欣蔚 30 Oct '24

30 Oct '24

1 1

openeuler 24.03-LTS-SP1 分支初始化公示通知
by yangchaohao 30 Oct '24

30 Oct '24

各位openeuler社区的maintainer、 committer和contributor们好： openEuler-24.03-LTS-SP1版本分支初始化创建pr已提交，链接为init openEuler-24.03-LTS-SP1 branch ・ Pull Request !5967 ・ openEuler/community - Gitee.com<https://gitee.com/openeuler/community/pulls/5967> 请涉及各sig的maintainer检视，如无问题请评论/lgtm 。公示三天，若无反对意见，将于11月1日12点合入。 ________________________________ 杨超豪 Yang Chaohao Email：yangchaohao(a)huawei.com<mailto:yangchaohao@huawei.com>

1 0

Re: [Dev] Re: %cmake引用统计
by wufengguang 29 Oct '24

29 Oct '24

不是试验仓，是独立的构建工程，用于暴露和跟踪构建问题，提供调试log。 350+包的构建工程，对我们资源压力不算大。这一点你可以放宽心，反正有压力也是在我们这边。 From: Funda Wang <fundawang(a)yeah.net> Sent: Tuesday, October 29, 2024 10:54 AM To: wufengguang <wufengguang(a)huawei.com> Cc: dev(a)openeuler.org; tc <tc(a)openeuler.org>; wfg(a)mail.ustc.edu.cn; duanpengjie <duanpengjie(a)huawei.com>; yangchaohao <yangchaohao(a)huawei.com> Subject: Re:[Dev] Re: %cmake引用统计只有100多个报错是不可能的，由于%cmake的定义发生变化，所有这些包在进行到 make 这一步的时候都会报错，因为当前文件夹找不到 Makefile。这里边还牵涉一些自行编写了 build.sh 脚本的自研软件，要说服工程师修改难度很大。我不倾向于建单独的试验仓，原因是spec的这次修改，并不会导致二进制包产生变化。对这个试验仓进行定时重建是非必要的，不但会浪费大量机器时间和资源，这个操作在maintainer的角度还很难复现。在 2024-10-29 10:06:33，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：如果只有100多个spec会报错，那当然更好。写几个脚本不会费多大的事，关键是我们自此建立了一套批量重构和演进的流程。后续全仓使能LTO，也可以照此方法推进。 From: Funda Wang <fundawang(a)yeah.net<mailto:fundawang@yeah.net>> Sent: Monday, October 28, 2024 11:33 AM To: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Cc: dev(a)openeuler.org<mailto:dev@openeuler.org>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; wfg(a)mail.ustc.edu.cn<mailto:wfg@mail.ustc.edu.cn>; duanpengjie <duanpengjie(a)huawei.com<mailto:duanpengjie@huawei.com>>; yangchaohao <yangchaohao(a)huawei.com<mailto:yangchaohao@huawei.com>> Subject: Re:[Dev] Re: %cmake引用统计 OpenEuler 批量工作记录<https://docs.qq.com/sheet/DWkxLU1JiUUNaVU5a?tab=kr08vj> 我觉得你还是没有看我先前发过的在线表格，从而过多担忧下游包的情况。你提的这个方案，eulermaker 团队将会牵涉较多精力，且在构建依赖树的过程中，容易浪费不必要的资源。我这个表是在24.09的发布树里，取得了Buildrequires cmake的所有包，数量比你列出的600+要少。这里边真正采用 in source build 的，只有100多个。这是第一轮要消灭的目标。剩下的，自行定义了 builddir 的包，只需要去掉这个自定义builddir就可以了。另外一个值得关注的问题是，25.03 里还开启了 LTO，有一些包可能由于不支持 LTO 而编译失败，这可能与 binutils 有关，在提交 cmake 切换 PR 的时候需要关注。在 2024-10-26 12:19:39，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：我草拟了一个cmake macros切换计划，大家看是否OK。我仍然建议定义全局%__cmake_in_source_build为1，以保证master分支平滑切换，下游包的fix流程也最简单。同时，通过步骤3-8推动问题暴露和下游包fix。 1. FundaWang/cmake包：在master上合入cmake macros（兼容版本，即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队：创建1个工程，总计600+包url，src-openeuler/$pkg/，定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况，提交PR作为demo url；写cmake宏切换文档url 5. EulerMaker团队：写脚本，批量给600+仓提issue，提供cmake宏切换文档url及log url 6. 600+维护者：fork个人仓，fix，提PR到src-openeuler/$pkg/，合入master分支 7. EulerMaker团队：再次批量构建，对未fix的，写脚本，通过sig-info.yaml查发email催促fix 8. 重复以上2步 Regards, Fengguang From: Funda Wang <fundawang(a)yeah.net<mailto:fundawang@yeah.net>> Sent: Friday, October 25, 2024 7:12 PM To: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Cc: dev(a)openeuler.org<mailto:dev@openeuler.org>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; wfg(a)mail.ustc.edu.cn<mailto:wfg@mail.ustc.edu.cn>; duanpengjie <duanpengjie(a)huawei.com<mailto:duanpengjie@huawei.com>> Subject: Re:%cmake引用统计当前进度：根据TC决议，oEEP 已创建： https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。目前已有下游工程师反馈，希望用同一个SPEC在前置版本中构建，如： https://gitee.com/src-openeuler/openvino/pulls/1 在 2024-10-23 17:02:32，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：受影响的600+ spec清单见附件。受影响的SIG统计： bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t: From: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Sent: Wednesday, October 23, 2024 12:35 PM To: dev(a)openeuler.org<mailto:dev@openeuler.org> Cc: liyang (AG) <liyang342(a)huawei.com<mailto:liyang342@huawei.com>> Subject: [Dev] TC议题：cmake macros改进总结 # cmake macros改进，及其600+包升级 ## issues https://gitee.com/src-openeuler/cmake/issues/I5OATI ## 使用cmake编译安装需要单独定义DESTDIR cmake install ./ ## 打包时会导致安装路径不明确，打包文件不完整，所以建议改为： DESTDIR="%{buildroot}" cmake --install ./ https://gitee.com/src-openeuler/cmake/pulls/31 **%cmake_build, %cmake_install 等相关宏的缺失, 使得从 rpm 生态的其他发行版移植软件包不便。** 部分Fedora中包，如asdcplib，SPEC文件中会使用%cmake3_build, %cmake3_install宏定义。但是在openEuler中没有这几个定义，导致用户自行rpmbuild asdcplib.spec报错。 https://gitee.com/src-openeuler/cmake/pulls/53 由于相关宏的缺失，很多的确需要 out-of-source building 的包都会在 spec 中通过各种方式手动指定编译目录参数 Closed: 不完全兼容已有%cmake，会导致软件包批量构建失败aom等软件包批量失败。 https://gitee.com/src-openeuler/cmake/issues/IAND9Y ## cmake新增支持%cmake_build和%cmake_install的实施方案经过多方讨论，提供如下兼容方案1 ## PRs ### 方案1 <https://gitee.com/src-openeuler/cmake/pulls/81> **Support cmake_build and cmake_install** 【8月合入】 | | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 %**cmake_conf** %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake_conf %cmake_build %cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行： + %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"} + %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir， 需同步修改conf/build/install三阶段 | 【归一化方法】后续版本在条件允许的时候，将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <https://gitee.com/src-openeuler/cmake/pulls/80> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake， 同时定义全局%__cmake_in_source_build为1 定义全新 %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake %cmake_build %cmake_install 同时定义%__cmake_in_source_build=0 | | 后期建议（半年后, 等所有下游包完成改造） | 去掉全局%__cmake_in_source_build=1定义 | 移除%__cmake_in_source_build=0 | ## 决策点 1. 技术方向：方案1 or 方案2 ？直接合入PR80 2. 落地版本：面向未来 25.03 ? 是 3. 回合版本：存量版本 22.03, 24.03 收益 ? 建议：仅回合对cmake包的修改，新增宏，以方便用户rpmbuild三方包。暂不考虑。 4. 兼容性：同一个spec, 可以拿到所有版本上去构建？暂不考虑。 5. 分离目录：是最佳实践，是未来方向。但存量软件包迁移是否迫切，收益是否大，优先级是否高？ 6. 在master上改, 批量暴露问题，推动下游包fix，缩短切换期，25.03分叉点前结束切换 7. release sig确认, 出倒排方案 8. oEEP：fundawang，fengguang ## 组织修改600+下游包 TODOs： 1. 确定上述技术路线（二选一） 2. 确定修改清单：在src-openeuler git上总共grep到634个包含%cmake的spec文件, 按SIG分类，发email出来 3. 提供文档与demo，目前发现有以下三类包，需要各自提供修改示例 1. %make_build、%make_install 2. %ninja_build、%ninja_install 3. %\_\_cmake --build、%\_\_cmake --install 4. 组织修改600+下游包spec，迁移到新的cmake宏，落地25.03版本 **决策点**：如何组织？专人批量修改固定套路的多数包，余下的push各个SIG组去修改？

1 0

Re: [Dev] Re: %cmake引用统计
by wufengguang 29 Oct '24

29 Oct '24

如果只有100多个spec会报错，那当然更好。写几个脚本不会费多大的事，关键是我们自此建立了一套批量重构和演进的流程。后续全仓使能LTO，也可以照此方法推进。 From: Funda Wang <fundawang(a)yeah.net> Sent: Monday, October 28, 2024 11:33 AM To: wufengguang <wufengguang(a)huawei.com> Cc: dev(a)openeuler.org; tc <tc(a)openeuler.org>; wfg(a)mail.ustc.edu.cn; duanpengjie <duanpengjie(a)huawei.com>; yangchaohao <yangchaohao(a)huawei.com> Subject: Re:[Dev] Re: %cmake引用统计 OpenEuler 批量工作记录<https://docs.qq.com/sheet/DWkxLU1JiUUNaVU5a?tab=kr08vj> 我觉得你还是没有看我先前发过的在线表格，从而过多担忧下游包的情况。你提的这个方案，eulermaker 团队将会牵涉较多精力，且在构建依赖树的过程中，容易浪费不必要的资源。我这个表是在24.09的发布树里，取得了Buildrequires cmake的所有包，数量比你列出的600+要少。这里边真正采用 in source build 的，只有100多个。这是第一轮要消灭的目标。剩下的，自行定义了 builddir 的包，只需要去掉这个自定义builddir就可以了。另外一个值得关注的问题是，25.03 里还开启了 LTO，有一些包可能由于不支持 LTO 而编译失败，这可能与 binutils 有关，在提交 cmake 切换 PR 的时候需要关注。在 2024-10-26 12:19:39，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：我草拟了一个cmake macros切换计划，大家看是否OK。我仍然建议定义全局%__cmake_in_source_build为1，以保证master分支平滑切换，下游包的fix流程也最简单。同时，通过步骤3-8推动问题暴露和下游包fix。 1. FundaWang/cmake包：在master上合入cmake macros（兼容版本，即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队：创建1个工程，总计600+包url，src-openeuler/$pkg/，定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况，提交PR作为demo url；写cmake宏切换文档url 5. EulerMaker团队：写脚本，批量给600+仓提issue，提供cmake宏切换文档url及log url 6. 600+维护者：fork个人仓，fix，提PR到src-openeuler/$pkg/，合入master分支 7. EulerMaker团队：再次批量构建，对未fix的，写脚本，通过sig-info.yaml查发email催促fix 8. 重复以上2步 Regards, Fengguang From: Funda Wang <fundawang(a)yeah.net<mailto:fundawang@yeah.net>> Sent: Friday, October 25, 2024 7:12 PM To: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Cc: dev(a)openeuler.org<mailto:dev@openeuler.org>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; wfg(a)mail.ustc.edu.cn<mailto:wfg@mail.ustc.edu.cn>; duanpengjie <duanpengjie(a)huawei.com<mailto:duanpengjie@huawei.com>> Subject: Re:%cmake引用统计当前进度：根据TC决议，oEEP 已创建： https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。目前已有下游工程师反馈，希望用同一个SPEC在前置版本中构建，如： https://gitee.com/src-openeuler/openvino/pulls/1 在 2024-10-23 17:02:32，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：受影响的600+ spec清单见附件。受影响的SIG统计： bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t: From: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Sent: Wednesday, October 23, 2024 12:35 PM To: dev(a)openeuler.org<mailto:dev@openeuler.org> Cc: liyang (AG) <liyang342(a)huawei.com<mailto:liyang342@huawei.com>> Subject: [Dev] TC议题：cmake macros改进总结 # cmake macros改进，及其600+包升级 ## issues https://gitee.com/src-openeuler/cmake/issues/I5OATI ## 使用cmake编译安装需要单独定义DESTDIR cmake install ./ ## 打包时会导致安装路径不明确，打包文件不完整，所以建议改为： DESTDIR="%{buildroot}" cmake --install ./ https://gitee.com/src-openeuler/cmake/pulls/31 **%cmake_build, %cmake_install 等相关宏的缺失, 使得从 rpm 生态的其他发行版移植软件包不便。** 部分Fedora中包，如asdcplib，SPEC文件中会使用%cmake3_build, %cmake3_install宏定义。但是在openEuler中没有这几个定义，导致用户自行rpmbuild asdcplib.spec报错。 https://gitee.com/src-openeuler/cmake/pulls/53 由于相关宏的缺失，很多的确需要 out-of-source building 的包都会在 spec 中通过各种方式手动指定编译目录参数 Closed: 不完全兼容已有%cmake，会导致软件包批量构建失败aom等软件包批量失败。 https://gitee.com/src-openeuler/cmake/issues/IAND9Y ## cmake新增支持%cmake_build和%cmake_install的实施方案经过多方讨论，提供如下兼容方案1 ## PRs ### 方案1 <https://gitee.com/src-openeuler/cmake/pulls/81> **Support cmake_build and cmake_install** 【8月合入】 | | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 %**cmake_conf** %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake_conf %cmake_build %cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行： + %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"} + %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir， 需同步修改conf/build/install三阶段 | 【归一化方法】后续版本在条件允许的时候，将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <https://gitee.com/src-openeuler/cmake/pulls/80> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake， 同时定义全局%__cmake_in_source_build为1 定义全新 %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake %cmake_build %cmake_install 同时定义%__cmake_in_source_build=0 | | 后期建议（半年后, 等所有下游包完成改造） | 去掉全局%__cmake_in_source_build=1定义 | 移除%__cmake_in_source_build=0 | ## 决策点 1. 技术方向：方案1 or 方案2 ？直接合入PR80 2. 落地版本：面向未来 25.03 ? 是 3. 回合版本：存量版本 22.03, 24.03 收益 ? 建议：仅回合对cmake包的修改，新增宏，以方便用户rpmbuild三方包。暂不考虑。 4. 兼容性：同一个spec, 可以拿到所有版本上去构建？暂不考虑。 5. 分离目录：是最佳实践，是未来方向。但存量软件包迁移是否迫切，收益是否大，优先级是否高？ 6. 在master上改, 批量暴露问题，推动下游包fix，缩短切换期，25.03分叉点前结束切换 7. release sig确认, 出倒排方案 8. oEEP：fundawang，fengguang ## 组织修改600+下游包 TODOs： 1. 确定上述技术路线（二选一） 2. 确定修改清单：在src-openeuler git上总共grep到634个包含%cmake的spec文件, 按SIG分类，发email出来 3. 提供文档与demo，目前发现有以下三类包，需要各自提供修改示例 1. %make_build、%make_install 2. %ninja_build、%ninja_install 3. %\_\_cmake --build、%\_\_cmake --install 4. 组织修改600+下游包spec，迁移到新的cmake宏，落地25.03版本 **决策点**：如何组织？专人批量修改固定套路的多数包，余下的push各个SIG组去修改？

1 0

openEuler tc 补充会议
by openEuler conference 29 Oct '24

29 Oct '24

您好！ TC 邀请您参加 2024-10-30 10:00 召开的WeLink会议(自动录制) 会议主题：openEuler tc 补充会议会议链接：https://meeting.huaweicloud.com:36443/#/j/963310592 会议纪要：https://etherpad.openeuler.org/p/TC-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! TC invites you to attend the WeLink conference(auto recording) will be held at 2024-10-30 10:00, The subject of the conference is openEuler tc 补充会议, You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/963310592. Add topics at https://etherpad.openeuler.org/p/TC-meetings. More information: https://www.openeuler.org/en/

1 0

Re: [Dev] Re: %cmake引用统计
by wufengguang 29 Oct '24

29 Oct '24

Issue都在cmake下，容易看到全貌。需要配合写一个close issue的脚本，当构建工程通过后，批量close issue。 Issue需要关联到负责人。目前找到350+ 包含%cmake宏的src-openeuler仓，且在sig-info.yaml里有登记。那下一步就以这350+仓做个构建工程，批量触发问题，批量在cmake下建issue，关联到对应的维护者，推进fix。 From: Xinwei Hu <micromotive(a)qq.com> Sent: Monday, October 28, 2024 7:04 PM To: wufengguang <wufengguang(a)huawei.com> Cc: Funda Wang <fundawang(a)yeah.net>; dev(a)openeuler.org; tc <tc(a)openeuler.org>; wfg(a)mail.ustc.edu.cn; duanpengjie <duanpengjie(a)huawei.com>; yangchaohao <yangchaohao(a)huawei.com> Subject: Re: [Tc] Re: [Dev] Re: %cmake引用统计 issue可以批量建。meta issue没法做实质性关联。我建议直接在cmake下建issue，所有issue都关联到cmake和对应的oeep就好。在 2024年10月28日，15:32，wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：普通issue就可以了，EulerMaker团队不会去跟踪这些issue，仅仅是把它当做提醒开发者的一个途径（还有一个途径是email）。 EulerMaker团队会定期重新构建该工程。还继续有问题的包，继续发email提醒。已经fix的包，就不再做任何事。 From: Funda Wang <fundawang(a)yeah.net<mailto:fundawang@yeah.net>> Sent: Monday, October 28, 2024 3:27 PM To: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Cc: dev(a)openeuler.org<mailto:dev@openeuler.org>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; wfg(a)mail.ustc.edu.cn<mailto:wfg@mail.ustc.edu.cn>; duanpengjie <duanpengjie(a)huawei.com<mailto:duanpengjie@huawei.com>>; yangchaohao <yangchaohao(a)huawei.com<mailto:yangchaohao@huawei.com>> Subject: Re:[Dev] Re: %cmake引用统计创建 meta issue 我是同意的。然而gitee的接口是否允许创建子 issue，这个可能要咨询一下。就是将子issue发配给各仓库之后，把这些子issue设置为 meta issue 的子项，便于跟踪进度。在 2024-10-26 12:19:39，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：我草拟了一个cmake macros切换计划，大家看是否OK。我仍然建议定义全局%__cmake_in_source_build为1，以保证master分支平滑切换，下游包的fix流程也最简单。同时，通过步骤3-8推动问题暴露和下游包fix。 1. FundaWang/cmake包：在master上合入cmake macros（兼容版本，即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队：创建1个工程，总计600+包url，src-openeuler/$pkg/，定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况，提交PR作为demo url；写cmake宏切换文档url 5. EulerMaker团队：写脚本，批量给600+仓提issue，提供cmake宏切换文档url及log url 6. 600+维护者：fork个人仓，fix，提PR到src-openeuler/$pkg/，合入master分支 7. EulerMaker团队：再次批量构建，对未fix的，写脚本，通过sig-info.yaml查发email催促fix 8. 重复以上2步 Regards, Fengguang From: Funda Wang <fundawang(a)yeah.net<mailto:fundawang@yeah.net>> Sent: Friday, October 25, 2024 7:12 PM To: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Cc: dev(a)openeuler.org<mailto:dev@openeuler.org>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; wfg(a)mail.ustc.edu.cn<mailto:wfg@mail.ustc.edu.cn>; duanpengjie <duanpengjie(a)huawei.com<mailto:duanpengjie@huawei.com>> Subject: Re:%cmake引用统计当前进度：根据TC决议，oEEP 已创建： https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。目前已有下游工程师反馈，希望用同一个SPEC在前置版本中构建，如： https://gitee.com/src-openeuler/openvino/pulls/1 在 2024-10-23 17:02:32，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：受影响的600+ spec清单见附件。受影响的SIG统计： bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t: From: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Sent: Wednesday, October 23, 2024 12:35 PM To: dev(a)openeuler.org<mailto:dev@openeuler.org> Cc: liyang (AG) <liyang342(a)huawei.com<mailto:liyang342@huawei.com>> Subject: [Dev] TC议题：cmake macros改进总结 # cmake macros改进，及其600+包升级 ## issues https://gitee.com/src-openeuler/cmake/issues/I5OATI ## 使用cmake编译安装需要单独定义DESTDIR cmake install ./ ## 打包时会导致安装路径不明确，打包文件不完整，所以建议改为： DESTDIR="%{buildroot}" cmake --install ./ https://gitee.com/src-openeuler/cmake/pulls/31 **%cmake_build, %cmake_install 等相关宏的缺失, 使得从 rpm 生态的其他发行版移植软件包不便。** 部分Fedora中包，如asdcplib，SPEC文件中会使用%cmake3_build, %cmake3_install宏定义。但是在openEuler中没有这几个定义，导致用户自行rpmbuild asdcplib.spec报错。 https://gitee.com/src-openeuler/cmake/pulls/53 由于相关宏的缺失，很多的确需要 out-of-source building 的包都会在 spec 中通过各种方式手动指定编译目录参数 Closed: 不完全兼容已有%cmake，会导致软件包批量构建失败aom等软件包批量失败。 https://gitee.com/src-openeuler/cmake/issues/IAND9Y ## cmake新增支持%cmake_build和%cmake_install的实施方案经过多方讨论，提供如下兼容方案1 ## PRs ### 方案1 <https://gitee.com/src-openeuler/cmake/pulls/81> **Support cmake_build and cmake_install** 【8月合入】 | | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 %**cmake_conf** %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake_conf %cmake_build %cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行： + %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"} + %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir， 需同步修改conf/build/install三阶段 | 【归一化方法】后续版本在条件允许的时候，将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <https://gitee.com/src-openeuler/cmake/pulls/80> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake， 同时定义全局%__cmake_in_source_build为1 定义全新 %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake %cmake_build %cmake_install 同时定义%__cmake_in_source_build=0 | | 后期建议（半年后, 等所有下游包完成改造） | 去掉全局%__cmake_in_source_build=1定义 | 移除%__cmake_in_source_build=0 | ## 决策点 1. 技术方向：方案1 or 方案2 ？直接合入PR80 2. 落地版本：面向未来 25.03 ? 是 3. 回合版本：存量版本 22.03, 24.03 收益 ? 建议：仅回合对cmake包的修改，新增宏，以方便用户rpmbuild三方包。暂不考虑。 4. 兼容性：同一个spec, 可以拿到所有版本上去构建？暂不考虑。 5. 分离目录：是最佳实践，是未来方向。但存量软件包迁移是否迫切，收益是否大，优先级是否高？ 6. 在master上改, 批量暴露问题，推动下游包fix，缩短切换期，25.03分叉点前结束切换 7. release sig确认, 出倒排方案 8. oEEP：fundawang，fengguang ## 组织修改600+下游包 TODOs： 1. 确定上述技术路线（二选一） 2. 确定修改清单：在src-openeuler git上总共grep到634个包含%cmake的spec文件, 按SIG分类，发email出来 3. 提供文档与demo，目前发现有以下三类包，需要各自提供修改示例 1. %make_build、%make_install 2. %ninja_build、%ninja_install 3. %\_\_cmake --build、%\_\_cmake --install 4. 组织修改600+下游包spec，迁移到新的cmake宏，落地25.03版本 **决策点**：如何组织？专人批量修改固定套路的多数包，余下的push各个SIG组去修改？ _______________________________________________ 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>

1 0

Re: [Dev] Re: %cmake引用统计
by wufengguang 28 Oct '24

28 Oct '24

普通issue就可以了，EulerMaker团队不会去跟踪这些issue，仅仅是把它当做提醒开发者的一个途径（还有一个途径是email）。 EulerMaker团队会定期重新构建该工程。还继续有问题的包，继续发email提醒。已经fix的包，就不再做任何事。 From: Funda Wang <fundawang(a)yeah.net> Sent: Monday, October 28, 2024 3:27 PM To: wufengguang <wufengguang(a)huawei.com> Cc: dev(a)openeuler.org; tc <tc(a)openeuler.org>; wfg(a)mail.ustc.edu.cn; duanpengjie <duanpengjie(a)huawei.com>; yangchaohao <yangchaohao(a)huawei.com> Subject: Re:[Dev] Re: %cmake引用统计创建 meta issue 我是同意的。然而gitee的接口是否允许创建子 issue，这个可能要咨询一下。就是将子issue发配给各仓库之后，把这些子issue设置为 meta issue 的子项，便于跟踪进度。在 2024-10-26 12:19:39，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：我草拟了一个cmake macros切换计划，大家看是否OK。我仍然建议定义全局%__cmake_in_source_build为1，以保证master分支平滑切换，下游包的fix流程也最简单。同时，通过步骤3-8推动问题暴露和下游包fix。 1. FundaWang/cmake包：在master上合入cmake macros（兼容版本，即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队：创建1个工程，总计600+包url，src-openeuler/$pkg/，定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况，提交PR作为demo url；写cmake宏切换文档url 5. EulerMaker团队：写脚本，批量给600+仓提issue，提供cmake宏切换文档url及log url 6. 600+维护者：fork个人仓，fix，提PR到src-openeuler/$pkg/，合入master分支 7. EulerMaker团队：再次批量构建，对未fix的，写脚本，通过sig-info.yaml查发email催促fix 8. 重复以上2步 Regards, Fengguang From: Funda Wang <fundawang(a)yeah.net<mailto:fundawang@yeah.net>> Sent: Friday, October 25, 2024 7:12 PM To: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Cc: dev(a)openeuler.org<mailto:dev@openeuler.org>; tc <tc(a)openeuler.org<mailto:tc@openeuler.org>>; wfg(a)mail.ustc.edu.cn<mailto:wfg@mail.ustc.edu.cn>; duanpengjie <duanpengjie(a)huawei.com<mailto:duanpengjie@huawei.com>> Subject: Re:%cmake引用统计当前进度：根据TC决议，oEEP 已创建： https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。目前已有下游工程师反馈，希望用同一个SPEC在前置版本中构建，如： https://gitee.com/src-openeuler/openvino/pulls/1 在 2024-10-23 17:02:32，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：受影响的600+ spec清单见附件。受影响的SIG统计： bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t: From: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Sent: Wednesday, October 23, 2024 12:35 PM To: dev(a)openeuler.org<mailto:dev@openeuler.org> Cc: liyang (AG) <liyang342(a)huawei.com<mailto:liyang342@huawei.com>> Subject: [Dev] TC议题：cmake macros改进总结 # cmake macros改进，及其600+包升级 ## issues https://gitee.com/src-openeuler/cmake/issues/I5OATI ## 使用cmake编译安装需要单独定义DESTDIR cmake install ./ ## 打包时会导致安装路径不明确，打包文件不完整，所以建议改为： DESTDIR="%{buildroot}" cmake --install ./ https://gitee.com/src-openeuler/cmake/pulls/31 **%cmake_build, %cmake_install 等相关宏的缺失, 使得从 rpm 生态的其他发行版移植软件包不便。** 部分Fedora中包，如asdcplib，SPEC文件中会使用%cmake3_build, %cmake3_install宏定义。但是在openEuler中没有这几个定义，导致用户自行rpmbuild asdcplib.spec报错。 https://gitee.com/src-openeuler/cmake/pulls/53 由于相关宏的缺失，很多的确需要 out-of-source building 的包都会在 spec 中通过各种方式手动指定编译目录参数 Closed: 不完全兼容已有%cmake，会导致软件包批量构建失败aom等软件包批量失败。 https://gitee.com/src-openeuler/cmake/issues/IAND9Y ## cmake新增支持%cmake_build和%cmake_install的实施方案经过多方讨论，提供如下兼容方案1 ## PRs ### 方案1 <https://gitee.com/src-openeuler/cmake/pulls/81> **Support cmake_build and cmake_install** 【8月合入】 | | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 %**cmake_conf** %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake_conf %cmake_build %cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行： + %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"} + %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir， 需同步修改conf/build/install三阶段 | 【归一化方法】后续版本在条件允许的时候，将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <https://gitee.com/src-openeuler/cmake/pulls/80> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake， 同时定义全局%__cmake_in_source_build为1 定义全新 %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake %cmake_build %cmake_install 同时定义%__cmake_in_source_build=0 | | 后期建议（半年后, 等所有下游包完成改造） | 去掉全局%__cmake_in_source_build=1定义 | 移除%__cmake_in_source_build=0 | ## 决策点 1. 技术方向：方案1 or 方案2 ？直接合入PR80 2. 落地版本：面向未来 25.03 ? 是 3. 回合版本：存量版本 22.03, 24.03 收益 ? 建议：仅回合对cmake包的修改，新增宏，以方便用户rpmbuild三方包。暂不考虑。 4. 兼容性：同一个spec, 可以拿到所有版本上去构建？暂不考虑。 5. 分离目录：是最佳实践，是未来方向。但存量软件包迁移是否迫切，收益是否大，优先级是否高？ 6. 在master上改, 批量暴露问题，推动下游包fix，缩短切换期，25.03分叉点前结束切换 7. release sig确认, 出倒排方案 8. oEEP：fundawang，fengguang ## 组织修改600+下游包 TODOs： 1. 确定上述技术路线（二选一） 2. 确定修改清单：在src-openeuler git上总共grep到634个包含%cmake的spec文件, 按SIG分类，发email出来 3. 提供文档与demo，目前发现有以下三类包，需要各自提供修改示例 1. %make_build、%make_install 2. %ninja_build、%ninja_install 3. %\_\_cmake --build、%\_\_cmake --install 4. 组织修改600+下游包spec，迁移到新的cmake宏，落地25.03版本 **决策点**：如何组织？专人批量修改固定套路的多数包，余下的push各个SIG组去修改？

1 0

Re: %cmake引用统计
by wufengguang 26 Oct '24

26 Oct '24

我草拟了一个cmake macros切换计划，大家看是否OK。我仍然建议定义全局%__cmake_in_source_build为1，以保证master分支平滑切换，下游包的fix流程也最简单。同时，通过步骤3-8推动问题暴露和下游包fix。 1. FundaWang/cmake包：在master上合入cmake macros（兼容版本，即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队：创建1个工程，总计600+包url，src-openeuler/$pkg/，定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况，提交PR作为demo url；写cmake宏切换文档url 5. EulerMaker团队：写脚本，批量给600+仓提issue，提供cmake宏切换文档url及log url 6. 600+维护者：fork个人仓，fix，提PR到src-openeuler/$pkg/，合入master分支 7. EulerMaker团队：再次批量构建，对未fix的，写脚本，通过sig-info.yaml查发email催促fix 8. 重复以上2步 Regards, Fengguang From: Funda Wang <fundawang(a)yeah.net> Sent: Friday, October 25, 2024 7:12 PM To: wufengguang <wufengguang(a)huawei.com> Cc: dev(a)openeuler.org; tc <tc(a)openeuler.org>; wfg(a)mail.ustc.edu.cn; duanpengjie <duanpengjie(a)huawei.com> Subject: Re:%cmake引用统计当前进度：根据TC决议，oEEP 已创建： https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。目前已有下游工程师反馈，希望用同一个SPEC在前置版本中构建，如： https://gitee.com/src-openeuler/openvino/pulls/1 在 2024-10-23 17:02:32，"wufengguang" <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> 写道：受影响的600+ spec清单见附件。受影响的SIG统计： bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t: From: wufengguang <wufengguang(a)huawei.com<mailto:wufengguang@huawei.com>> Sent: Wednesday, October 23, 2024 12:35 PM To: dev(a)openeuler.org<mailto:dev@openeuler.org> Cc: liyang (AG) <liyang342(a)huawei.com<mailto:liyang342@huawei.com>> Subject: [Dev] TC议题：cmake macros改进总结 # cmake macros改进，及其600+包升级 ## issues https://gitee.com/src-openeuler/cmake/issues/I5OATI ## 使用cmake编译安装需要单独定义DESTDIR cmake install ./ ## 打包时会导致安装路径不明确，打包文件不完整，所以建议改为： DESTDIR="%{buildroot}" cmake --install ./ https://gitee.com/src-openeuler/cmake/pulls/31 **%cmake_build, %cmake_install 等相关宏的缺失, 使得从 rpm 生态的其他发行版移植软件包不便。** 部分Fedora中包，如asdcplib，SPEC文件中会使用%cmake3_build, %cmake3_install宏定义。但是在openEuler中没有这几个定义，导致用户自行rpmbuild asdcplib.spec报错。 https://gitee.com/src-openeuler/cmake/pulls/53 由于相关宏的缺失，很多的确需要 out-of-source building 的包都会在 spec 中通过各种方式手动指定编译目录参数 Closed: 不完全兼容已有%cmake，会导致软件包批量构建失败aom等软件包批量失败。 https://gitee.com/src-openeuler/cmake/issues/IAND9Y ## cmake新增支持%cmake_build和%cmake_install的实施方案经过多方讨论，提供如下兼容方案1 ## PRs ### 方案1 <https://gitee.com/src-openeuler/cmake/pulls/81> **Support cmake_build and cmake_install** 【8月合入】 | | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 %**cmake_conf** %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake_conf %cmake_build %cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行： + %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"} + %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir， 需同步修改conf/build/install三阶段 | 【归一化方法】后续版本在条件允许的时候，将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <https://gitee.com/src-openeuler/cmake/pulls/80> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake， 同时定义全局%__cmake_in_source_build为1 定义全新 %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake %cmake_build %cmake_install 同时定义%__cmake_in_source_build=0 | | 后期建议（半年后, 等所有下游包完成改造） | 去掉全局%__cmake_in_source_build=1定义 | 移除%__cmake_in_source_build=0 | ## 决策点 1. 技术方向：方案1 or 方案2 ？直接合入PR80 2. 落地版本：面向未来 25.03 ? 是 3. 回合版本：存量版本 22.03, 24.03 收益 ? 建议：仅回合对cmake包的修改，新增宏，以方便用户rpmbuild三方包。暂不考虑。 4. 兼容性：同一个spec, 可以拿到所有版本上去构建？暂不考虑。 5. 分离目录：是最佳实践，是未来方向。但存量软件包迁移是否迫切，收益是否大，优先级是否高？ 6. 在master上改, 批量暴露问题，推动下游包fix，缩短切换期，25.03分叉点前结束切换 7. release sig确认, 出倒排方案 8. oEEP：fundawang，fengguang ## 组织修改600+下游包 TODOs： 1. 确定上述技术路线（二选一） 2. 确定修改清单：在src-openeuler git上总共grep到634个包含%cmake的spec文件, 按SIG分类，发email出来 3. 提供文档与demo，目前发现有以下三类包，需要各自提供修改示例 1. %make_build、%make_install 2. %ninja_build、%ninja_install 3. %\_\_cmake --build、%\_\_cmake --install 4. 组织修改600+下游包spec，迁移到新的cmake宏，落地25.03版本 **决策点**：如何组织？专人批量修改固定套路的多数包，余下的push各个SIG组去修改？

1 0

%cmake引用统计
by wufengguang 23 Oct '24

23 Oct '24

受影响的600+ spec清单见附件。受影响的SIG统计： bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t: From: wufengguang <wufengguang(a)huawei.com> Sent: Wednesday, October 23, 2024 12:35 PM To: dev(a)openeuler.org Cc: liyang (AG) <liyang342(a)huawei.com> Subject: [Dev] TC议题：cmake macros改进总结 # cmake macros改进，及其600+包升级 ## issues https://gitee.com/src-openeuler/cmake/issues/I5OATI ## 使用cmake编译安装需要单独定义DESTDIR cmake install ./ ## 打包时会导致安装路径不明确，打包文件不完整，所以建议改为： DESTDIR="%{buildroot}" cmake --install ./ https://gitee.com/src-openeuler/cmake/pulls/31 **%cmake_build, %cmake_install 等相关宏的缺失, 使得从 rpm 生态的其他发行版移植软件包不便。** 部分Fedora中包，如asdcplib，SPEC文件中会使用%cmake3_build, %cmake3_install宏定义。但是在openEuler中没有这几个定义，导致用户自行rpmbuild asdcplib.spec报错。 https://gitee.com/src-openeuler/cmake/pulls/53 由于相关宏的缺失，很多的确需要 out-of-source building 的包都会在 spec 中通过各种方式手动指定编译目录参数 Closed: 不完全兼容已有%cmake，会导致软件包批量构建失败aom等软件包批量失败。 https://gitee.com/src-openeuler/cmake/issues/IAND9Y ## cmake新增支持%cmake_build和%cmake_install的实施方案经过多方讨论，提供如下兼容方案1 ## PRs ### 方案1 <https://gitee.com/src-openeuler/cmake/pulls/81> **Support cmake_build and cmake_install** 【8月合入】 | | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 %**cmake_conf** %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake_conf %cmake_build %cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行： + %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"} + %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir， 需同步修改conf/build/install三阶段 | 【归一化方法】后续版本在条件允许的时候，将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <https://gitee.com/src-openeuler/cmake/pulls/80> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake， 同时定义全局%__cmake_in_source_build为1 定义全新 %cmake_build %cmake_install | 逐步修改 %cmake 为 %cmake %cmake_build %cmake_install 同时定义%__cmake_in_source_build=0 | | 后期建议（半年后, 等所有下游包完成改造） | 去掉全局%__cmake_in_source_build=1定义 | 移除%__cmake_in_source_build=0 | ## 决策点 1. 技术方向：方案1 or 方案2 ？直接合入PR80 2. 落地版本：面向未来 25.03 ? 是 3. 回合版本：存量版本 22.03, 24.03 收益 ? 建议：仅回合对cmake包的修改，新增宏，以方便用户rpmbuild三方包。暂不考虑。 4. 兼容性：同一个spec, 可以拿到所有版本上去构建？暂不考虑。 5. 分离目录：是最佳实践，是未来方向。但存量软件包迁移是否迫切，收益是否大，优先级是否高？ 6. 在master上改, 批量暴露问题，推动下游包fix，缩短切换期，25.03分叉点前结束切换 7. release sig确认, 出倒排方案 8. oEEP：fundawang，fengguang ## 组织修改600+下游包 TODOs： 1. 确定上述技术路线（二选一） 2. 确定修改清单：在src-openeuler git上总共grep到634个包含%cmake的spec文件, 按SIG分类，发email出来 3. 提供文档与demo，目前发现有以下三类包，需要各自提供修改示例 1. %make_build、%make_install 2. %ninja_build、%ninja_install 3. %\_\_cmake --build、%\_\_cmake --install 4. 组织修改600+下游包spec，迁移到新的cmake宏，落地25.03版本 **决策点**：如何组织？专人批量修改固定套路的多数包，余下的push各个SIG组去修改？

1 0

温馨提醒 //答复: 【重要】openEuler 24.03 LTS SP1版本需求收集中，请大家提交需要合入的特性到release plan
by Sujinling 22 Oct '24

22 Oct '24

openEuler 24.03 LTS SP1 版本计划在Release Sig例会已同步过，需求收集截止节点 10/31，请大家及时提交需要合入的特性到release plan，感谢~ Thanks & best regards, 苏锦铃 00566192 发件人: Sujinling <sujinling(a)huawei.com> 发送时间: 2024年9月2日 10:23 收件人: release(a)openeuler.org; tc(a)openeuler.org; dev(a)openeuler.org; kernel(a)openeuler.org 主题: 【重要】openEuler 24.03 LTS SP1版本需求收集中，请大家提交需要合入的特性到release plan 大家好， openEuler 24.03 LTS SP1是基于6.6内核的24.03-LTS版本增强扩展版本，按release-plan计划启动需求收集，欢迎各sig maintainer、伙伴和社区开发者们积极反馈和交流。请大家提交需要合入的特性清单到release plan上，感谢！ openEuler 24.03 LTS SP1版本release plan详细版本计划： https://gitee.com/openeuler/release-management/blob/master/openEuler-24.03-… 需求申请流程链接，请按照流程步骤提交，issue 类型选择需求， issue 标题以 [openEuler-24.03 LTS SP1] 开头： https://gitee.com/openeuler/release-management/blob/master/Goverance/openEu… Thanks & best regards, 苏锦铃

1 0

【月报征集】openEuler 2024年10月月报
by 翁巧贞 22 Oct '24

22 Oct '24

Hi，all openEuler 社区2024年10月运作报告征集啦！欢迎大家投稿！！！社区的点滴故事都值得记录。如果您希望在月报增加您的工作内容，请于 10月26日(周六）16:00 前联系翁巧贞（微信号Qzhen303、wengqiaozhen(a)openeuler.sh) 如邮件回复，请在正文内说明稿件内容（标题、文案、配图、相关链接等）以及您的微信联系方式，以便内容的沟通调整。万分感谢！！另，操作系统大会&openEuler Summit 2024 将在 11月15-16日北京中关村国际创新中心举办。报名通道已开启，欢迎大家报名： • P C 报名入口: https://openatomcon.openatom.cn/registration/?code=Amq8&activityNo=HD202410… • 手机端报名入口: https://openatomcon.openatom.cn/registration_mobile/?code=Amq8&activityNo=H… 温馨提醒：如您之前没有平台账号，请进入链接后先注册，再登录账号报名。感谢大会官网：操作系统大会&openEuler Summit 2024<https://www.openeuler.org/zh/interaction/summit-list/summit2024/> 往期回顾：openEuler 社区月报<https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzkyMjYzNjU0Ng==&action=getal…> 感谢大家支持！翁巧贞/openEuler社区运营

1 0

TC双周例会
by openEuler conference 21 Oct '24

21 Oct '24

您好！ TC 邀请您参加 2024-10-23 10:00 召开的WeLink会议(自动录制) 会议主题：TC双周例会会议内容： openEuler技术委员会双周例会会议链接：https://meeting.huaweicloud.com:36443/#/j/960939431 会议纪要：https://etherpad.openeuler.org/p/TC-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! TC invites you to attend the WeLink conference(auto recording) will be held at 2024-10-23 10:00, The subject of the conference is TC双周例会, Summary: openEuler技术委员会双周例会 You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/960939431. Add topics at https://etherpad.openeuler.org/p/TC-meetings. More information: https://www.openeuler.org/en/

1 0

[Cancel] TC双周例会
by openEuler conference 21 Oct '24

21 Oct '24

Sorry! The Zoom meeting will be held at 2024-10-23 10:00 scheduled by TC SIG has been cancelled.

1 0

TC双周例会
by openEuler conference 21 Oct '24

21 Oct '24

您好！ TC 邀请您参加 2024-10-23 10:00 召开的Zoom会议(自动录制) 会议主题：TC双周例会会议内容： openEuler 技术委员会双周例会会议链接：https://us06web.zoom.us/j/85255902732?pwd=a0HvibG3CFUbFSftVHeWdagSoxj8Ku.1 会议纪要：https://etherpad.openeuler.org/p/TC-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! TC invites you to attend the Zoom conference(auto recording) will be held at 2024-10-23 10:00, The subject of the conference is TC双周例会, Summary: openEuler 技术委员会双周例会 You can join the meeting at https://us06web.zoom.us/j/85255902732?pwd=a0HvibG3CFUbFSftVHeWdagSoxj8Ku.1. Add topics at https://etherpad.openeuler.org/p/TC-meetings. More information: https://www.openeuler.org/en/

1 0

openEuler 技术委员会换届申请候选人名单公示
by 胡欣蔚 20 Oct '24

20 Oct '24

各位 openEuler 社区的小伙伴：如前沟通，openEuler 技术委员会换届的流程已经启动。结合 openEuler 社区章程 [openEuler项目群开源治理制度](https://www.openeuler.org/zh/community/charter/) 与 [openEuler项目群选举管理条例](https://www.openeuler.org/zh/community/vote/) 的要求，以及已经明确沟通表达个人意愿的情况，现公示参加下一届社区技术委员会委员推选的候选人名单。 > 以下名单以姓名首字母排序： | 姓名 | gitee账号 | 推举来源 | | --- | ---------------------- | -------- | | 陈棋德 | @dillon_chen | 上届TC委员推荐 | | 陈茂冬 | @chenmaodong | 自荐 | | 高贵锦 | @blue0613 | 自荐 | | 胡欣蔚 | @shinwell_hu | 上届TC委员推荐 | | 蒋彪 | @happyseeker | 上届TC委员推荐 | | 李永强 | @charlie_li | 上届TC委员推荐 | | 刘恺 | @kailiu42 | 自荐 | | 吕从庆 | @HelloWorld_lvcongqing | 上届TC委员推荐 | | 马全一 | @genedna | 自荐 | | 任慰 | @vonhust | 上届TC委员推荐 | | 石勇 | @stonefly128 | 上届TC委员推荐 | | 田俊 | @juntianlinux | 上届TC委员推荐 | | 王建民 | @jianminw | 上届TC委员推荐 | | 王志钢 | @cellfaint | 上届TC委员推荐 | | 魏建刚 | @bugflyfly | 上届TC委员推荐 | | 王麟 | @wonleing | 自荐 | | 岳龙广 | @bigclouds99 | 自荐 | 此外，社区公共技术组 Maintainer 担任的委员无任期限制，将继续从以下四个 SIG 的 Maintainer 中推举并自动成为技术委员会委员。 | 公共技术组 | | ---------------------- | | Infrastructure | | Kernel | | sig-release-management | | security-committee | 下周三（10月23日）技术委员会例会将审视候选人名单，并完成TC委员会正式提名；同时讨论确定下届技术委员会规模。欢迎社区伙伴围观、审视、反馈意见，候选人名单在22日前，还会结合反馈进一步刷新。谢谢。 Regards 胡欣蔚 openEuler 技术委员会主席

1 0

2024 年社区项目之星评选启动
by Huxinwei 14 Oct '24

14 Oct '24

各位技术委员，大家好：参考 oEEP-0007，技术委员会当前启动 2004年社区项目之星的评选。大家可以参考一下链接，回顾下我们的评选要求。 https://www.openeuler.org/zh/oEEP/?name=oEEP-0007%20openEuler%E4%BC%98%E7%A… 经过曹志的帮助，当前对社区创新代码仓做了统计，我把各个维度的前十几个代码仓提出来，供各位参考： 1. 2024 年贡献者最多的代码仓： Repo_name URL Create_at forks watches PR_ALL PR_2024 SIG Contributors_ALL Contributor_2024 community https://gitee.com/openeuler/community.git 2019 1298 155 3855 354 TC 870 202 mugen https://gitee.com/openeuler/mugen.git 2021 640 33 2496 962 sig-QA 228 134 kernel https://gitee.com/openeuler/kernel.git 2019 1450 410 3495 2536 kernel 175 104 release-management https://gitee.com/openeuler/release-management.git 2020 392 53 1537 292 sig-release-management 322 95 git-basics https://gitee.com/openeuler/git-basics.git 2022 339 8 245 85 sig-OSCourse 214 69 QA https://gitee.com/openeuler/QA.git 2020 241 46 571 90 sig-QA 168 47 docs https://gitee.com/openeuler/docs.git 2019 548 70 1231 96 Doc 259 45 yocto-meta-openeuler https://gitee.com/openeuler/yocto-meta-openeuler.git 2021 198 25 1310 524 sig-Yocto 65 32 openeuler-jenkins https://gitee.com/openeuler/openeuler-jenkins.git 2019 120 41 427 55 sig-Gatekeeper 86 32 openEuler-portal https://gitee.com/openeuler/openEuler-portal.git 2022 97 10 1842 354 sig-OpenDesign 71 30 cantian https://gitee.com/openeuler/cantian.git 2023 143 34 195 190 db 27 26 gazelle https://gitee.com/openeuler/gazelle.git 2022 93 23 652 229 sig-high-performance-network 35 20 UniProton https://gitee.com/openeuler/UniProton.git 2022 98 22 228 86 sig-embedded 37 19 qingzhou https://gitee.com/openeuler/qingzhou.git 2023 37 40 241 236 dev-utils 18 18 gala-gopher https://gitee.com/openeuler/gala-gopher.git 2022 96 16 363 154 sig-ebpf 30 18 2. 2024 年贡献 PR 最多的代码仓： Repo_name URL Create_at forks watches PR_ALL PR_2024 SIG Contributors_ALL Contributor_2024 kernel https://gitee.com/openeuler/kernel.git 2019 1450 410 3495 2536 kernel 175 104 mugen https://gitee.com/openeuler/mugen.git 2021 640 33 2496 962 sig-QA 228 134 ccps https://gitee.com/openeuler/ccps.git 2023 7 5 777 564 sig-K8sDistro 5 5 yocto-meta-openeuler https://gitee.com/openeuler/yocto-meta-openeuler.git 2021 198 25 1310 524 sig-Yocto 65 32 community https://gitee.com/openeuler/community.git 2019 1298 155 3855 354 TC 870 202 openEuler-portal https://gitee.com/openeuler/openEuler-portal.git 2022 97 10 1842 354 sig-OpenDesign 71 30 kytuning-server https://gitee.com/openeuler/kytuning-server.git 2023 7 16 326 323 sig-ops 3 3 extuner https://gitee.com/openeuler/extuner.git 2023 18 18 340 298 sig-ops 15 14 release-management https://gitee.com/openeuler/release-management.git 2020 392 53 1537 292 sig-release-management 322 95 env_check https://gitee.com/openeuler/env_check.git 2023 30 9 463 257 sig-Compatibility-Infra 11 8 qingzhou https://gitee.com/openeuler/qingzhou.git 2023 37 40 241 236 dev-utils 18 18 gazelle https://gitee.com/openeuler/gazelle.git 2022 93 23 652 229 sig-high-performance-network 35 20 openstack https://gitee.com/openeuler/openstack.git 2021 51 15 989 191 sig-openstack 39 9 cantian https://gitee.com/openeuler/cantian.git 2023 143 34 195 190 db 27 26 devkit-pipeline https://gitee.com/openeuler/devkit-pipeline.git 2024 26 7 186 186 sig-CICD 15 15 3. 2023与2024年创建的新代码仓，以开发活跃排序 Repo_name URL Create_at forks watches PR_ALL PR_2024 SIG Contributors_ALL Contributor_2024 ccps https://gitee.com/openeuler/ccps.git 2023 7 5 777 564 sig-K8sDistro 5 5 kytuning-server https://gitee.com/openeuler/kytuning-server.git 2023 7 16 326 323 sig-ops 3 3 extuner https://gitee.com/openeuler/extuner.git 2023 18 18 340 298 sig-ops 15 14 env_check https://gitee.com/openeuler/env_check.git 2023 30 9 463 257 sig-Compatibility-Infra 11 8 qingzhou https://gitee.com/openeuler/qingzhou.git 2023 37 40 241 236 dev-utils 18 18 cantian https://gitee.com/openeuler/cantian.git 2023 143 34 195 190 db 27 26 devkit-pipeline https://gitee.com/openeuler/devkit-pipeline.git 2024 26 7 186 186 sig-CICD 15 15 PilotGo-plugin-topology https://gitee.com/openeuler/PilotGo-plugin-topology.git 2023 10 17 346 177 sig-ops 4 3 utsudo https://gitee.com/openeuler/utsudo.git 2023 10 8 1123 147 sig-memsafety 7 3 fastblock https://gitee.com/openeuler/fastblock.git 2023 36 18 122 120 sig-SDS 17 16 utshell https://gitee.com/openeuler/utshell.git 2023 9 8 1101 120 sig-memsafety 6 2 kytuning-client https://gitee.com/openeuler/kytuning-client.git 2023 14 16 125 103 sig-ops 8 7 cantian-connector-mysql https://gitee.com/openeuler/cantian-connector-mysql.git 2023 80 12 97 95 db 14 14 oebuild https://gitee.com/openeuler/oebuild.git 2023 37 5 117 83 sig-Yocto 10 6 libkperf https://gitee.com/openeuler/libkperf.git 2024 12 11 82 82 A-Tune 10 10 4． 2024年创建的代码仓，以开发活跃排序 Repo_name URL Create_at forks watches PR_ALL PR_2024 SIG Contributors_ALL Contributor_2024 devkit-pipeline https://gitee.com/openeuler/devkit-pipeline.git 2024 26 7 186 186 sig-CICD 15 15 libkperf https://gitee.com/openeuler/libkperf.git 2024 12 11 82 82 A-Tune 10 10 sysSentry https://gitee.com/openeuler/sysSentry.git 2024 19 13 72 72 Base-service 12 12 dde_autotest_euler https://gitee.com/openeuler/dde_autotest_euler.git 2024 10 22 56 56 sig-QA 9 9 security-baseline https://gitee.com/openeuler/security-baseline.git 2024 1 8 52 52 sig-security-facility 1 1 secureguardian https://gitee.com/openeuler/secureguardian.git 2024 6 8 46 46 sig-security-facility 2 2 PilotGo-plugin-syscare https://gitee.com/openeuler/PilotGo-plugin-syscare.git 2024 4 16 46 46 sig-ops 2 2 PilotGo-plugin-ELK https://gitee.com/openeuler/PilotGo-plugin-ELK.git 2024 4 16 45 45 sig-ops 3 3 oeAware-collector https://gitee.com/openeuler/oeAware-collector.git 2024 18 10 35 35 A-Tune 11 11 virtCCA_sdk https://gitee.com/openeuler/virtCCA_sdk.git 2024 13 9 32 32 sig-confidential-computing 8 8 oeAware-manager https://gitee.com/openeuler/oeAware-manager.git 2024 11 9 30 30 A-Tune 4 4 PilotGo-plugin-a-tune https://gitee.com/openeuler/PilotGo-plugin-a-tune.git 2024 4 17 24 24 sig-ops 4 4 kyclassifier https://gitee.com/openeuler/kyclassifier.git 2024 2 7 22 22 sig-Compatibility-Infra 2 2 kail_dnn_adapter https://gitee.com/openeuler/kail_dnn_adapter.git 2024 3 5 17 17 sig-AccLib 2 2 PilotGo-plugin-MFD https://gitee.com/openeuler/PilotGo-plugin-MFD.git 2024 1 13 14 14 sig-ops 1 1 oeAware-scenario https://gitee.com/openeuler/oeAware-scenario.git 2024 7 9 13 13 A-Tune 3 3 authHub https://gitee.com/openeuler/authHub.git 2024 7 13 12 12 sig-ops 5 5 easy-software https://gitee.com/openeuler/easy-software.git 2024 14 8 12 12 sig-OpenDesign 4 4 请各位委员参考并评估，并且欢迎大家推荐在这些项目之外的其他代码仓。我们下次TC会议正式启动评选。谢谢

1 0

[Cancel] TC例会
by openEuler conference 08 Oct '24

08 Oct '24

Sorry! The Zoom meeting will be held at 2024-10-09 10:00 scheduled by TC SIG has been cancelled.

1 0

TC例会
by openEuler conference 08 Oct '24

08 Oct '24

您好！ TC 邀请您参加 2024-10-09 10:00 召开的WeLink会议(自动录制) 会议主题：TC例会会议链接：https://meeting.huaweicloud.com:36443/#/j/983168410 会议纪要：https://etherpad.openeuler.org/p/TC-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! TC invites you to attend the WeLink conference(auto recording) will be held at 2024-10-09 10:00, The subject of the conference is TC例会, You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/983168410. Add topics at https://etherpad.openeuler.org/p/TC-meetings. More information: https://www.openeuler.org/en/

1 0

2025

2024

2023

2022

2021

2020

2019

Tc October 2024