修复python-mitmproxy-wireguard

[laokz]

依赖的rust包ring不支持riscv，需提升ring版本

[H1yame]

调研

依赖链路: mitmproxy_wireguard-0.1.23 -> boringtun = "0.5.0" -> ring = "0.15"

ring 在 2023 年 10 月 1 日支持了 riscv64：https://github.com/briansmith/ring/pull/1627 ，更新到最新版本即可支持 riscv64 。

尝试升级 boringtun 到 0.6.0，然而 boringtun 0.6.0 依赖 ring 0.16.x，仍需升级

解决方案

使用 cargo patch 替换一下 boringtun，把其中 ring 的依赖版本修改为 0.17.8，再 cargo vendor 替换一下之前的 cargo-vendor-cache 即可。

本机编译已通过

[laokz]

牛！讲解的清楚详细，学习了！

---原始邮件--- 发件人: @.> 发送时间: 2024年3月26日(周二) 凌晨2:36 收件人: @.>; 抄送: @.**@.>; 主题: Re: [openEuler-RISCV/oerv-team] 修复python-mitmproxy-wireguard (Issue #269)

调研

依赖链路: mitmproxy_wireguard-0.1.23 -> boringtun = "0.5.0" -> ring = "0.15"

ring 在 2023 年 10 月 1 日支持了 riscv64：briansmith/ring#1627 ，更新到最新版本即可支持 riscv64 。

尝试升级 boringtun 到 0.6.0，然而 boringtun 0.6.0 依赖 ring 0.16.x，仍需升级

解决方案

使用 cargo patch 替换一下 boringtun，把其中 ring 的依赖版本修改为 0.17.8，再 cargo vendor 替换一下之前的 cargo-vendor-cache 即可。

本机编译已通过

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[H1yame]

https://gitee.com/src-openeuler/python-mitmproxy-wireguard/pulls/2 提pr了，之前没领这个任务 想着跟 #268 一起修

[H1yame]

这个也assign给我吧，已经修复完成了 https://gitee.com/src-openeuler/python-mitmproxy-wireguard/pulls/2 麻烦老师有空 review 一下

[laokz]

修改对x86和arm影响大，maintainer可能不好接受。看能不能进行下架构隔离（%ifarch riscv64）

---原始邮件--- 发件人: @.> 发送时间: 2024年4月2日(周二) 晚上6:48 收件人: @.>; 抄送: @.**@.>; 主题: Re: [openEuler-RISCV/oerv-team] 修复python-mitmproxy-wireguard (Issue #269)

这个也assign给我吧，已经修复完成了 https://gitee.com/src-openeuler/python-mitmproxy-wireguard/pulls/2 麻烦老师有空 review 一下

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[H1yame]

修改对x86和arm影响大，maintainer可能不好接受。看能不能进行下架构隔离（%ifarch riscv64） … ---原始邮件--- 发件人: @.> 发送时间: 2024年4月2日(周二) 晚上6:48 收件人: @.>; 抄送: @.**@.>; 主题: Re: [openEuler-RISCV/oerv-team] 修复python-mitmproxy-wireguard (Issue #269) 这个也assign给我吧，已经修复完成了 https://gitee.com/src-openeuler/python-mitmproxy-wireguard/pulls/2 麻烦老师有空 review 一下 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

@laokz 已经进行架构隔离，现在在非riscv64架构下的构建不受本次改动的影响，辛苦老师 review 一下

[laokz]

PR看起来还有些乱，按上面的“解决方案”：

%prep部分
%ifarch riscv64
cargo patch ...
cargo vendor ...
%endif

是否能简洁些

[H1yame]

PR看起来还有些乱，按上面的“解决方案”：

%prep部分
%ifarch riscv64
cargo patch ...
cargo vendor ...
%endif

是否能简洁些

尝试将大部分操作放在了一个宏里面，辛苦老师 review 一下

[laokz]

我不熟悉rust，可能出的主意不对，只供参考，最后还是maintainer说了算：）

我的意思是：能通过rust的命令实现打补丁，就不预先制作补丁放到仓库里。比如cargo vendor如果能根据新的cargo.toml，自动从网络下载更新展开后的cargo-vendor-cache

可以和更熟悉rust的老师同学探讨下）

---原始邮件--- 发件人: @.> 发送时间: 2024年4月6日(周六) 中午1:15 收件人: @.>; 抄送: @.**@.>; 主题: Re: [openEuler-RISCV/oerv-team] 修复python-mitmproxy-wireguard (Issue #269)

PR看起来还有些乱，按上面的“解决方案”： %prep部分 %ifarch riscv64 cargo patch ... cargo vendor ... %endif
是否能简洁些

尝试将大部分操作放在了一个宏里面，辛苦老师 review 一下

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[H1yame]

比如cargo vendor如果能根据新的cargo.toml，自动从网络下载更新展开后的cargo-vendor-cache

是可以的，但是我理解这样就不需要 cargo-vendor-cache 了。我感觉原本设计成使用 cargo-vendor-cache 就是为了避免从网络上下载依赖的源码。

这里为了支持 riscv 需要 patch ring 包到 0.17 版本，所以对应的 cargo-vendor-cache 中的一系列依赖也需要更改，所以这里独立分出了一个 cargo-vendor-cache-riscv64

如果把 cargo-vendor-cache 给去掉，每次构建都从网络上下载依赖源码，就不用单独分出一个 cargo-vendor-cache-riscv64 这样麻烦，只需要改一下 Cargo.toml 就可以了。

但是问题是这样改就让构建的过程中需要从网络上拉取依赖，我想这样改可能不太好（

[laokz]

了解了

---原始邮件--- 发件人: @.> 发送时间: 2024年4月6日(周六) 下午5:09 收件人: @.>; 抄送: @.**@.>; 主题: Re: [openEuler-RISCV/oerv-team] 修复python-mitmproxy-wireguard (Issue #269)

比如cargo vendor如果能根据新的cargo.toml，自动从网络下载更新展开后的cargo-vendor-cache

是可以的，但是我理解这样就不需要 cargo-vendor-cache 了。我感觉原本设计成使用 cargo-vendor-cache 就是为了避免从网络上下载依赖的源码。

这里为了支持 riscv 需要 patch ring 包到 0.17 版本，所以对应的 cargo-vendor-cache 中的一系列依赖也需要更改，所以这里独立分出了一个 cargo-vendor-cache-riscv64

如果把 cargo-vendor-cache 给去掉，每次构建都从网络上下载依赖源码，就不用单独分出一个 cargo-vendor-cache-riscv64 这样麻烦，只需要改一下 Cargo.toml 就可以了。

但是问题是这样改就让构建的过程中需要从网络上拉取依赖，我想这样改可能不太好（

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[laokz]

如果把 cargo-vendor-cache 给去掉，每次构建都从网络上下载依赖源码，就不用单独分出一个 cargo-vendor-cache-riscv64 这样麻烦，只需要改一下 Cargo.toml 就可以了。

我建议用这样侵入最少的方式修改。因为rv的特殊性而使所有架构遵循的东西显得乱，这应该是maintainer不愿看到的。我们有特殊性，那每次需从网络拉取适配代码是可接受的

当然如果能从包上游直接支持rv，然后推动oe升级也是比较好的做法。（现在已无需跟随2403的代码了）