修复python-mitmproxy-wireguard #269
Comments
调研依赖链路: ring 在 2023 年 10 月 1 日支持了 riscv64：briansmith/ring#1627 ，更新到最新版本即可支持 riscv64 。 尝试升级 解决方案使用 cargo patch 替换一下 boringtun，把其中 ring 的依赖版本修改为 0.17.8，再 cargo vendor 替换一下之前的 cargo-vendor-cache 即可。 本机编译已通过 |
|
牛！讲解的清楚详细，学习了！
…---原始邮件---
发件人: ***@***.***>
发送时间: 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: ***@***.***>
|
|
https://gitee.com/src-openeuler/python-mitmproxy-wireguard/pulls/2 |
|
这个也assign给我吧，已经修复完成了 |
|
修改对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 一下 |
|
PR看起来还有些乱，按上面的“解决方案”： 是否能简洁些 |
尝试将大部分操作放在了一个宏里面，辛苦老师 review 一下 |
|
我不熟悉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: ***@***.***>
|
是可以的，但是我理解这样就不需要 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 就可以了。 但是问题是这样改就让构建的过程中需要从网络上拉取依赖，我想这样改可能不太好（ |
|
了解了
…---原始邮件---
发件人: ***@***.***>
发送时间: 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: ***@***.***>
|
我建议用这样侵入最少的方式修改。因为rv的特殊性而使所有架构遵循的东西显得乱，这应该是maintainer不愿看到的。我们有特殊性，那每次需从网络拉取适配代码是可接受的 当然如果能从包上游直接支持rv，然后推动oe升级也是比较好的做法。（现在已无需跟随2403的代码了） |
|
@hiyasame 还在吗？从maintainer的审核意见看，PR有些乱，理由不是很清晰，， |
依赖的rust包ring不支持riscv，需提升ring版本
The text was updated successfully, but these errors were encountered: