一直出现
在使用 devtools（extra-riscv64-build、mkarchroot 等）进行打包时，即使你在宿主机里是 root，在 chroot 环境里的用户和权限也未必与宿主机同步。因此，就会出现你在宿主系统执行 whoami 显示为 root，但在 chroot 内部却提示 “gyx1 is not in the sudoers file” 的问题。

换句话说：

宿主机和chroot是两个不同的系统环境；
在宿主机里你是 root 并不代表进了 chroot 后也能以同样的身份运行命令；
devtools 默认会在 chroot 内创建/使用一个普通用户（往往与 PKGBUILD 里的 pkgbuild_user 配置有关），而不是让你直接在 chroot 里当 root 操作。
这对工具本身来说应该是个大bug

sudo pacman -Syu devtools
我更新了devtools没有用,在想是不是环境污染了的问题
extra-riscv64-build -- -c
解决了

clang版本有问题,进入配好的riscv环境看看配置.
不过怎么进虚拟机呀.

sudo systemd-nspawn -D ./archriscv/ --machine archriscv -a -U

你的问题是在新分支 ruby-pycall 中，git log 仍然显示 commit 143157fa6c9a9f954ff787102b8ea184b1d3ba01 属于 origin/rbenv 分支的历史，即你的提交历史仍然和 origin/rbenv 共享。

🚀 为什么会这样？
当你创建 ruby-pycall 分支时：

bash
复制
编辑
git checkout -b ruby-pycall origin/ruby-pycall
或

bash
复制
编辑
git switch -c ruby-pycall origin/ruby-pycall
如果 ruby-pycall 和 rbenv 以前是相同的提交历史，你的新分支 ruby-pycall 只是一个指向同一个 commit 的分支，还没有新的提交。

🔍 如何确认 ruby-pycall 分支的提交历史
运行以下命令查看分支关系：

bash
复制
编辑
git branch -av
如果 ruby-pycall 仍然指向 origin/rbenv，会看到类似：

yaml
复制
编辑

  • ruby-pycall 143157f addpatch: rbenv 1.3.2-1
    origin/rbenv 143157f addpatch: rbenv 1.3.2-1
    这说明 ruby-pycall 只是一个分支名，它的 HEAD 仍然指向同一个 commit。

🔧 解决方案
✅ 方法 1：创建新提交
如果你希望 ruby-pycall 分支不再和 rbenv 共享历史，只需要在 ruby-pycall 分支上进行新的提交：

bash
复制
编辑
echo “New changes” > newfile.txt
git add newfile.txt
git commit -m “New commit in ruby-pycall”
然后 git log 会显示 ruby-pycall 分支有新的 commit。

✅ 方法 2：强制重置 ruby-pycall 到新的状态
如果你希望 ruby-pycall 和 rbenv 彻底分开，你可以重置 ruby-pycall：

bash
复制
编辑
git checkout ruby-pycall
git reset –hard HEAD~1 # 让 ruby-pycall 回退 1 个 commit（谨慎使用）
或者完全清空并重新创建：

bash
复制
编辑
git branch -D ruby-pycall
git checkout -b ruby-pycall
然后重新提交你的代码。