2512 lts版本编译失败

交流互助区
1

问题描述
拉取最新2512 lts版本的manifest，合入高可用组件后编译报错

image
image1277×499 46.8 KB

task.log报错信息

image
image1289×353 24 KB

环境信息
操作系统：使用2509版本可正常编译的docker

软件版本：

image
image437×121 2.78 KB

尝试过的解决方案
删除adaptive_lm/v100r009c10spc101b200@openubmc/stable组件后再编译显示下载组件失败

image
image1033×412 28.2 KB

重新导入高可用组件后重新编译，报错依旧

image
image1267×159 8.71 KB

2512 release包构建问题
2

答案内容由AI生成，仅供参考：

2512 LTS 版本编译失败问题分析与解决方案

根据您提供的详细信息，当前在拉取最新的 2512 LTS 版本 manifest 并合入高可用组件后触发了编译失败。以下是对该问题的全面分析及建议解决方案。

:magnifying_glass_tilted_left: 问题定位

:pushpin: 核心错误日志

从 task.log 中提取的关键错误信息如下：

ERROR: adaptive_lm/v100r009c10spc101b200@openumbc/stable: Error in source() method, line 30
git.fetch.commit(
TypeError: commit: path should be string, bytes, os.PathLike or integer, not NoneType

此错误发生在 Conan 执行 source() 方法时，调用 git.fetch.commit 抛出异常：

commit 参数类型错误：期望为字符串、字节、路径对象或整数，实际为 NoneType

这表明 adaptive_lm 组件在拉取代码时缺少必要的 commit 或路径信息，导致源码获取失败，进而中断整个构建流程。

:gear: 环境与上下文分析

项目 当前配置
目标版本 openUBMC 2512 LTS
构建命令 bingo build -r openumbc_opensource -b openUBMC
Conan 版本 2.21.0 :white_check_mark:（已知兼容）
Bingo 版本 0.6.122
基础 Docker 环境 基于 2509 可编译环境（:warning:可能存在不兼容）

:magnifying_glass_tilted_right: 注意点：虽然 Conan 使用的是 2.21.0（之前 2509 编译正常所用版本），但 manifest 已切换至 2512，其依赖结构、组件版本、构建脚本均可能发生变更。

:puzzle_piece: 可能原因分析

1. manifest 配置错误或缺失 commit 信息

  • 错误堆栈中 git.fetch.commit(...) 参数为 None，说明在 adaptive_lm 组件的 Conan recipe 或 manifest 配置中未正确指定 Git 提交哈希或分支。
  • 这可能是由于：
    • manifest 文件中对 adaptive_lm 的引用缺少 commit 字段。
    • 使用了未解析的变量或动态表达式（如 ${LATEST_COMMIT}）未被正确展开。
    • manifest 未同步更新至完整状态，某些子模块指针为空。

2. 组件引用方式变更（Conan 2.x 兼容性）

  • 虽然 Conan 版本为 2.21.0（支持 Conan 2.x 语法），但部分组件的 conanfile.py 可能使用了旧版逻辑，在 Conan 2.x 下行为变化导致空值传入。
  • 特别是 git.fetch.commit(None) 表明 Git 操作封装层未做空值防护。

3. Docker 环境残留缓存或配置污染

  • 使用的是 2509 版本能正常编译的 Docker 镜像，可能携带以下风险：
    • .conan2 缓存中存在旧版包元数据，与 2512 新版本冲突。
    • profile 或 remotes 配置残留，影响远程仓库解析。
    • 缺少 2512 所需的新工具链（如新版 git、python 模块等）。

4. 高可用组件引入导致依赖冲突

  • 您提到“合入高可用组件后报错”，说明该操作是触发点。
  • 高可用组件可能显式或隐式依赖 adaptive_lm，但提供的版本或配置不完整，导致其 source() 方法执行异常。

:white_check_mark: 解决方案建议

:white_check_mark: 方案一：检查并修复 manifest 中 adaptive_lm 的 Git 配置

  1. 查看 manifest 中 adaptive_lm 的引用定义：

    grep -r "adaptive_lm" ./.repo/manifests/

  2. 确保其包含明确的 commit 或 revision 字段，例如：

    <project name="adaptive_lm" path="src/adaptive_lm"
         revision="abc123def456..." />

    而非空值或 ${} 变量未展开。

  3. 若使用动态变量，请确认初始化脚本（如 init.py）已正确加载环境变量。

:white_check_mark: 方案二：清除 Conan 缓存并重建依赖图

Conan 缓存可能因跨版本使用导致元数据错乱。

# 清除特定包缓存
conan remove "adaptive_lm*" -c

# 或清除全部缓存（谨慎操作）
conan remove "*" -c

# 重新安装依赖，强制重建
conan install . --build=missing -r openumbc_opensource

:memo: 建议在全新工作区中执行 bingo init 初始化 2512 环境，避免历史残余影响。

:white_check_mark: 方案三：验证并更新 Conan Remote 配置

确保 remote 正确指向 2512 对应的仓库：

conan remote list

应包含类似：

openumbc_opensource: https://conan.openubmc.cn/conan_1

如缺失，请添加：

conan remote add openumbc_opensource https://conan.openubmc.cn/conan_1 --force

:white_check_mark: 方案四：尝试切换到官方推荐的 2512 构建环境

由于您使用的是基于 2509 的 Docker 镜像，强烈建议改用官方为 2512 LTS 定制的基础镜像。

推荐做法：

# 拉取官方 2512 环境文档指引的 base image
docker pull openubmc/studio:2512-lts

# 启动容器并初始化环境
docker run -it openubmc/studio:2512-lts /bin/bash

cd /home/workspace
git clone https://gitcode.com/openUBMC/manifest.git
cd manifest
git checkout br_release_openUBMC2512_LTS_2025xxxx  # 替换为实际 LTS 分支

# 初始化 SDK 与依赖
python3 init.py
bingo build -b openUBMC

:white_check_mark: 方案五：临时规避（调试定位）

若需快速验证是否为 adaptive_lm 组件本身问题，可尝试：

  1. 临时移除高可用组件中对 adaptive_lm 的依赖（如果允许）。
  2. 或在本地 mock 一个 dummy 组件替代，观察是否跳过错误。

用于判断是否为核心组件配置问题。

:hammer_and_wrench: 附加建议

1. 升级 bingo 工具至最新版

当前版本为 0.6.122，建议确认是否存在新版支持 2512：

pip install --upgrade openubmc-bingo

或源码安装最新 release。

2. 检查 .gitconfig 设置（避免 autocrlf 问题）

git config --global core.autocrlf false

3. 查看完整构建日志

深入分析 task.log 中 adaptive_lm 的前序调用链，确认是哪个 recipe 或构建步骤传入了 None。

:books: 相关参考文档

:white_check_mark: 总结

问题 结论
根本原因 adaptive_lm 组件在 source() 阶段因 commit=None 导致 TypeError
触发条件 合入高可用组件 + manifest 2512 配置异常
解决关键 修复 manifest 中 adaptive_lm 的 Git 提交信息或清除缓存重试
预防措施 使用官方推荐的 2512 LTS 构建环境，避免混用旧版 Docker 镜像

:white_check_mark: 推荐操作顺序：

  1. 清理 Conan 缓存 → conan remove "adaptive_lm*" -c
  2. 检查 manifest 中 adaptive_lm 是否有有效 revision
  3. 使用标准 2512 环境重建整个工作区

如仍无法解决，请提供 manifest.xml 中 adaptive_lm 的具体配置片段以便进一步诊断。

相关链接：

  1. 25.03 fructrl源码构建时出文件找不到的错
  2. bingo upgrade问题
  3. 25.12版本编译失败
  4. 【重要！】近期遇到的一些Conan构建相关问题整体解答
  5. maint及conan_index说明 | 文档中心 | openUBMC
3

看起来是这个版本不存在，请检查远程仓是否正确，可以使用conan search adaptive_lm/* -r xxx命令搜索xxx远程仓中的软件包。

4

conan remote list检查下当前远程仓库，是否指向25.09 sdk远程仓？

5

查了一下，存在adaptive_lm,但是版本不对

image
image560×321 8.37 KB

6

conan库中只有b100，manifest报的缺少b200，感觉是你的conan仓上传的内容不对，需要你检查b200来源（检查你的bmc_sdk包）。

可以解压出bmc_sdk再使用conan list adaptive_lm/*检查缓存中的包。

7

配的是conan_1和openubmc_opensource

image

8

conan1中不会有adaptive_lm

9

此组件应存在于你们内部的仓中

10

缓存中有这个包，看日志像是能找到但运行错误了

image

企业微信截图_17685552532824
企业微信截图_176855525328241099×157 91.2 KB

11

发送完整的task.log，当前信息太简单，不具备可定位性

12

经查是二进制导入问题，导入新传递的二进制文件即可正常出包