- Tc - mailweb.openeuler.org

【RM】openEuler 24.03 LTS SP1 alpha版本release公告
by Xushanshan (Sassa, Intelligent Computing Solution Development Dep) 10 Nov '24

10 Nov '24

Dear all， openEuler 24.03 LTS SP1 alpha 版本每日构建可全量完整构建通过，每日AT验证无阻塞问题验证通过。社区各 sig 组及用户可基于该版本开展功能验证、体验， QA sig组请基于该版本开展软件包验证适配。本次 alpha版本由 EulerMaker构建系统统一编译构建，社区开发者可按需使用。各个 SIG 组可基于该版本开展组件自验证及试用，社区一起协作支撑 openEuler 24.03 LTS SP1 alpha 版本 issue发现和定位修复，您发现和定位修复每一个 issue 不仅可以解决您使用 openEuler版本的问题点，更可以帮助社区一起持续优化用户的体验！ l openEuler 24.03 LTS SP1版本 release plan &特性清单公示链接： https://gitee.com/openeuler/release-management/blob/master/openEuler-24.03-… l openEuler 24.03 LTS SP1 alpha 版本下载链接：http://121.36.84.172/dailybuild/EBS-openEuler-24.03-LTS-SP1/alpha_openeuler-2024-11-09-14-50-56/ | openEuler版本缺陷管理规范链接：https://gitee.com/openeuler/QA/blob/master/%E7%A4%BE%E5…...<https://gitee.com/openeuler/QA/blob/master/%E7%A4%BE%E5%8C%BA%E7%89%88%E6%9…> l openEuler EulerMaker构建系统：https://eulermaker.compass-ci.openeuler.openatom.cn/ l openEuler 24.03 LTS SP1 版本自验证进展与质量结果同步方式：建议各 sig 组及社区用户均可以在 QA-sig 下以 ISSUE方式同步自验证进展和自验证结果，您的自验证结果将是 release 版本质量评估的充分信息依据； tage Name Deadline for PR Begin Time End Time Days Note Collect key features - 2024/9/1 2024/10/31 61 版本需求收集 Change Review 1 - 2024/10/8 2024/10/18 11 Review 软件包变更（升级/退役/淘汰）SP版本尽可能保持版本不变 Herited features - 2024/10/8 2024/11/1 25 继承特性合入（Branch前完成合入） Develop - 2024/10/8 2024/11/28 58 新特性开发，合入24.03 LTS Next Kernel freezing - 2024/11/1 2024/11/8 8 内核冻结 Branch 24.03 LTS SP1 - 2024/11/1 2024/11/7 10 24.03 LTS Next 拉取 24.03 LTS SP1 分支 Build & Alpha（NOW 😊） - 2024/11/8 2024/11/14 7 新开发特性合入，Alpha版本发布 Test round 1 2024/11/13 2024/11/15 2024/11/21 7 24.03 LTS SP1 模块测试 Change Review 2 - 2024/11/22 2024/11/24 3 发起软件包淘汰评审 Test round 2 (Beta Version) 2024/11/20 2024/11/22 2024/11/28 7 24.03 LTS SP1 Beta版本发布 Test round 3 2024/11/27 2024/11/29 2024/12/5 7 全量验证(全量SIT) Change Review 3 - 2024/12/3 2024/12/5 3 分支启动冻结，只允许bug fix Test round 4 2024/12/4 2024/12/6 2024/12/12 7 分支冻结，只允许bug fix Test round 5 2024/12/11 2024/12/13 2024/12/19 7 回归测试 Test round 6 (预留) 2024/12/18 2024/12/20 2024/12/26 7 回归测试 Release Review - 2024/12/19 2024/12/20 2 版本发布决策/ Go or No Go Release preparation - 2024/12/27 2024/12/28 2 发布前准备阶段，发布件系统梳理 Release - 2024/12/30 2024/12/31 2 社区Release评审通过正式发布徐珊珊 BR

1 0

【openEuler Summit 2024】贡献之星名单公示
by yaslynn 09 Nov '24

09 Nov '24

尊敬的openEuler 技术委员会委员， openEuler Summit 2024 贡献之星评选已经结束，现将相关名单公示： openEuler 创新贡献之星/openEuler Innovator：4位-评2位唐葛亮、曹洪涛 openEuler 社区活跃之星/openEuler Active Star：14位-评5位陈强、刘靖蓉、张维瑜、闫志聪、刘忻 openEuler 问题解决之星/openEuler Problem Solver：4位-评2位李超峰、王萌 openEuler基础设施与安全贡献之星 / openEuler Infrastructure & Security Star：13位-评5位裴建康、李新宇、孙毅、江新宇、杨伟 openEuler开发贡献之星/openEuler Code Star：31位-评11位曾怡峰、徐绕青、王清政、郑挺、李亚楠、柳鑫浩、王钧琪、罗君、张兴荣、梁娅、Funda Wang openEuler社区新秀/openEuler Newcomer：9位-评3位王静、张丽敏、温红化感谢各位老师的支持！

1 0

【openEuler Summit 2024】贡献之星评选名单
by yaslynn 08 Nov '24

08 Nov '24

尊敬的openEuler 技术委员会委员， openEuler Summit 2024召开在即，社区展开openEuler 2024年度贡献之星的评选活动，该奖项旨在鼓励对2024年度在openEuler社区的技术创新、技术生态发展、工程能力提升等工作中成果突出的工程师，更感谢每一位贡献者在社区的专业和辛勤付出。评选范围：在2024年度对社区有代码贡献的社区开发者；排他条件：近两年（2023-2024）在社区中出现过违反社区行为准则（https://www.openeuler.org/zh/community/c… 评选贡献时间： 2024年 1 月 1 日-2024年 11 月 1 日我们今年设有以下奖项： openEuler社区新秀/openEuler Rising Star 在 2024 年度积极参与社区问题讨论、帮助其他新成员、主动提出改进建议、从加入社区变成为一个成熟的贡献者。 openEuler开发贡献之星/openEuler Code Star 核心代码贡献：专注于项目关键功能开发、模块化实现等方面的贡献。代码评审：评审和优化其他开发者的代码，保持项目代码质量。创新贡献：提出新的功能、算法或重大改进。 openEuler基础设施与安全贡献之星 /openEuler Infra & Security Star 基础设施贡献：维护 CI/CD（持续集成与持续交付）管道、自动化测试工具和服务器等基础设施，确保项目的顺利运行。改进或扩展社区基础设施工具，提升开发和发布流程的效率。 CVE 和安全维护：积极参与安全漏洞的发现、修复和报告，确保项目的安全性和健壮性。参与并推动安全补丁的更新，协助发布安全公告，确保社区和用户及时获得安全信息。软件包维护：维护社区关键软件包和依赖项，保证其版本更新及时，处理兼容性问题。对长期维护的软件包提供技术支持，并解决用户反馈的问题。 openEuler 问题解决之星/openEuler Problem Solver 表彰给在项目中发现、分析和修复复杂问题的关键贡献者。 openEuler 创新贡献之星/openEuler Innovator 表彰为项目带来创新特性、新功能、新解决方案或方法上有突出贡献的关键贡献者。引入新的工具、工作流程或自动化高影响力功能开发 openEuler 社区活跃之星/openEuler Star Advocate 1. 社区活动组织者：主导或协助社区meetup、黑客松、线上研讨会、开发者聚会等。成功吸引更多成员加入或增强现有成员的活跃度。每次活动的组织质量及参与反馈，尤其是技术深度、互动性和社区影响。 2. 教育与推广：创建或推动教育资源，如教程、工作坊、教学视频等，有助于新成员快速上手并参与项目。通过公开讲座、博客、社交媒体等方式，提升项目在全球范围内的知名度和参与度。 3. 社群管理与互动：在论坛、聊天室、社交平台上持续活跃，帮助解决问题并促进成员之间的合作与互动。推动社区讨论，提出有价值的建议和反馈，积极参与核心问题的解决和项目路线图的讨论。 4. 新成员引导：帮助新加入社区的成员找到合适的贡献路径，指导他们参与项目和活动，确保新成员能尽快融入社区。对新手友好的文档、教程等内容的贡献和维护。评选方式：提名方式：通过社区成员公开提名，可以自荐/他荐，或由 maintainer 举荐。提名附带贡献者的具体贡献证明（例如 Pull Request 链接、活动记录等）。经这阶段的材料收集，以上附件为所有入选名单，需TC委员老师们进行评选。评选标准：按照3:1的比例选取中选名额，如遇无法被整除则视为+1个名额，最终名额拟定为： openEuler 创新贡献之星/openEuler Innovator：4位；-评2位 openEuler 社区活跃之星/openEuler Active Star；14位-评5位 openEuler 问题解决之星/openEuler Problem Solver；4位-评2位 openEuler基础设施与安全贡献之星 / openEuler Infrastructure & Security Star；13位-评5位 openEuler开发贡献之星/openEuler Code Star：26位；-评9位 openEuler社区新秀/openEuler Newcomer：7位-评3位共计中选名单26位。感谢各位老师！

1 0

openEuler TC 临时会议
by openEuler conference 07 Nov '24

07 Nov '24

您好！ TC 邀请您参加 2024-11-09 10:00 召开的WeLink会议(自动录制) 会议主题：openEuler TC 临时会议会议链接：https://meeting.huaweicloud.com:36443/#/j/984308042 会议纪要：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-11-09 10:00, The subject of the conference is openEuler TC 临时会议, You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/984308042. Add topics at https://etherpad.openeuler.org/p/TC-meetings. More information: https://www.openeuler.org/en/

1 0

memsafety SIG例会
by openEuler conference 07 Nov '24

07 Nov '24

您好！ sig-memsafety 邀请您参加 2024-11-07 15:00 召开的Tencent会议(自动录制) 会议主题：memsafety SIG例会会议内容： 1、项目进展同步。会议链接：https://meeting.tencent.com/dm/EezVGlJdG6HY 会议纪要：https://etherpad.openeuler.org/p/sig-memsafety-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! sig-memsafety invites you to attend the Tencent conference(auto recording) will be held at 2024-11-07 15:00, The subject of the conference is memsafety SIG例会, Summary: 1、项目进展同步。 You can join the meeting at https://meeting.tencent.com/dm/EezVGlJdG6HY. Add topics at https://etherpad.openeuler.org/p/sig-memsafety-meetings. More information: https://www.openeuler.org/en/

1 0

【ops sig】openEuler 2024 summit线下sig组例会议题收集
by Hufeng (Solar, Euler) 01 Nov '24

01 Nov '24

各位ops sig maintainer大家好： Ops sig计划在openEuler Summit期间2024年11月16日下午16:15~17:45召开线下会议，现向大家收集本次会议与会人和议题请大家在11月13日前完成议题反馈，反馈地址如下 https://etherpad.openeuler.org/p/sig-ops-meetings 本次议题主题按照特性总结和未来规划来汇报比如： 1. A-ops年终总结和未来规划 -- 胡峰 2. 3. 4.开放讨论

1 0

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

2025

2024

2023

2022

2021

2020

2019

Tc