mailweb.openeuler.org
Manage this list
×
Keyboard Shortcuts
Thread View
j
: Next unread message
k
: Previous unread message
j a
: Jump to all threads
j l
: Jump to MailingList overview
2024
November
October
September
August
July
June
May
April
March
February
January
2023
December
November
October
September
August
July
June
May
April
March
February
January
2022
December
November
October
September
August
July
June
May
April
March
February
January
2021
December
November
October
September
August
July
June
May
April
March
February
January
2020
December
November
October
September
August
July
June
May
April
March
February
January
2019
December
List overview
Download
Tc
----- 2024 -----
November 2024
October 2024
September 2024
August 2024
July 2024
June 2024
May 2024
April 2024
March 2024
February 2024
January 2024
----- 2023 -----
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
----- 2022 -----
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
----- 2021 -----
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
----- 2020 -----
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
----- 2019 -----
December 2019
tc@openeuler.org
1 participants
1526 discussions
Start a n
N
ew thread
【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
0
0
2024 项目之星评选初步结果公示
by 胡欣蔚
30 Oct '24
30 Oct '24
各位TC委员和社区伙伴: 经统计,截止30日上午的反馈,我汇总情况如下, ## 行业影响 | yocto-meta-openeuler |
https://gitee.com/openeuler/yocto-meta-openeuler.git
| NA | | mugen |
https://gitee.com/openeuler/mugen.git
| NA | | kernel |
https://gitee.com/openeuler/kernel.git
| NA | | gazelle |
https://gitee.com/openeuler/gazelle.git
| 1 | | zephyr-cn |
https://gitee.com/openeuler/zephyr-cn.git
| 建议不从 openEuler 角度颁奖 | | RISC-V |
https://gitee.com/openeuler/RISC-V.git
| 2 | | PilotGo |
https://gitee.com/openeuler/PilotGo.git
| 3 | | UniProton |
https://gitee.com/openeuler/UniProton.git
| 4 | | syscare |
https://gitee.com/openeuler/syscare.git
| 5 | | ros |
https://gitee.com/openeuler/ros.git
| 6 | ## 技术创新 | libkperf |
https://gitee.com/openeuler/libkperf.git
| 1 | | zvm |
https://gitee.com/openeuler/zvm.git
| 2 | | KubeOS |
https://gitee.com/openeuler/KubeOS.git
| 2021 年建项目,建议今年跳过 | | dde_autotest_euler |
https://gitee.com/openeuler/dde_autotest_euler.git
| 3 | | devkit-pipeline |
https://gitee.com/openeuler/devkit-pipeline.git
| 4 | | sysSentry |
https://gitee.com/openeuler/sysSentry.git
| 5 | | secureguardian |
https://gitee.com/openeuler/secureguardian.git
| 6 | | EulerCopilot |
https://gitee.com/openeuler/EulerCopilot.git
| 7 | | sysmaster |
https://gitee.com/openeuler/sysmaster.git
| 2021 年建项目,建议今年跳过 | | signatrust |
https://gitee.com/openeuler/signatrust.git
| 8 | | security-baseline |
https://gitee.com/openeuler/security-baseline.git
| 9 | ## 金代码仓 | kernel |
https://gitee.com/openeuler/kernel.git
| NA | | openstack |
https://gitee.com/openeuler/openstack.git
| 1 | | mugen |
https://gitee.com/openeuler/mugen.git
| NA | | iSulad |
https://gitee.com/openeuler/iSulad.git
| 2 | | yocto-meta-openeuler |
https://gitee.com/openeuler/yocto-meta-openeuler.git
| NA | | dde |
https://gitee.com/openeuler/dde.git
| 3 | | A-Tune |
https://gitee.com/openeuler/A-Tune.git
| 4 | | secGear |
https://gitee.com/openeuler/secGear.git
| 5 | | qingzhou |
https://gitee.com/openeuler/qingzhou.git
| 6 | | llvm-project |
https://gitee.com/openeuler/llvm-project.git
| 无PR,建议跳过 | | kytuning-server |
https://gitee.com/openeuler/kytuning-server.git
| 7 | | cantian |
https://gitee.com/openeuler/cantian.git
| 8 | ## 社区活跃 | kernel |
https://gitee.com/openeuler/kernel.git
| NA | | yocto-meta-openeuler |
https://gitee.com/openeuler/yocto-meta-openeuler.git
| NA | | mugen |
https://gitee.com/openeuler/mugen.git
| NA | | kytuning-server |
https://gitee.com/openeuler/kytuning-server.git
| Contributor 只有3,建议跳过 | | release-management |
https://gitee.com/openeuler/release-management.git
| 社区管理代码仓 | | openEuler-portal |
https://gitee.com/openeuler/openEuler-portal.git
| 1 | | extuner |
https://gitee.com/openeuler/extuner.git
| 2 | | gazelle |
https://gitee.com/openeuler/gazelle.git
| 3 | | website-v2 |
https://gitee.com/openeuler/website-v2.git
| Contributor 0,建议跳过 | | stratovirt |
https://gitee.com/openeuler/stratovirt.git
| Contributor 2,建议跳过 | | RISC-V |
https://gitee.com/openeuler/RISC-V.git
| Contributor 2,建议跳过 | | TC | [
https://gitee.com/openeuler/TC.git](https://gitee.com/openeuler/TC.git)
| 社区管理代码仓 | | qingzhou |
https://gitee.com/openeuler/qingzhou.git
| 4 | 以上四张表格均为反馈统计的原始数据,排序即为当前反馈结果。 综上建议: openEuler 2024年项目之星: - openEuler Embedded (yocto-meta-openeuler 代码仓作为代表) - mugen - openEuler Kernel 以上三个项目不再颁单项奖。 openEuler 2024 年度新建项目: - libkperf - dde_autotest_euler - devkit-pipeline - sysSentry - secureguardian openEuler 2024 年行业影响力奖: - Gazelle - RISC-V - PilotGo openEuler 2024 年技术创新奖: - zvm - EulerCopilot - signatrust openEuler 2024 年金代码仓奖: - openstack - iSulad - dde openEuler 2024 年社区活跃奖: - openEuler-portal - extuner - gazelle (重复得奖,建议跳过) - qingzhou 请各位审视反馈,也欢迎社区小伙伴对初步结果提出意见建议。
1
1
0
0
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
0
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包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"}<br>+ %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 | 【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <
https://gitee.com/src-openeuler/cmake/pulls/80
> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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
0
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包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"}<br>+ %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 | 【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <
https://gitee.com/src-openeuler/cmake/pulls/80
> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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
0
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
0
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包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"}<br>+ %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 | 【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <
https://gitee.com/src-openeuler/cmake/pulls/80
> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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
0
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包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"}<br>+ %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 | 【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <
https://gitee.com/src-openeuler/cmake/pulls/80
> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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
0
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包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"}<br>+ %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 | 【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <
https://gitee.com/src-openeuler/cmake/pulls/80
> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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
0
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包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?\_\_cmake_in_source_build:-S "%{\_vpath_srcdir}"}<br>+ %{!?\_\_cmake_in_source_build:-B "%{\_\_cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 | 【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏 ### 方案2 <
https://gitee.com/src-openeuler/cmake/pulls/80
> **Update cmake macro** 【讨论中】 | | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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
0
0
← Newer
1
2
3
4
...
153
Older →
Jump to page:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
Results per page:
10
25
50
100
200