Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't compile due to conflicting copies of curve25519-dalek #77

Open
ioistired opened this issue Jul 11, 2024 · 3 comments
Open

Can't compile due to conflicting copies of curve25519-dalek #77

ioistired opened this issue Jul 11, 2024 · 3 comments

Comments

@ioistired
Copy link

auxin-build-log.txt

running cargo tree confirms the source of these errors

➤ cargo tree -i curve25519-dalek
warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2021 which implies `resolver = "2"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions
warning: Patch `curve25519-dalek v3.2.1 (https://github.com/signalapp/curve25519-dalek.git?branch=lizard2#829f52e7)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
error: There are multiple `curve25519-dalek` packages in your project, and the specification `curve25519-dalek` is ambiguous.
Please re-run this command with one of the following specifications:
  registry+https://github.com/rust-lang/crates.io-index#[email protected]
  git+https://github.com/signalapp/curve25519-dalek?tag=signal-curve25519-4.1.3#4.1.3
@rugk
Copy link

rugk commented Sep 9, 2024

For everyone reading this: Note this issue is apparently a mission critical one for a Telegram sticker bot, see https://github.com/signalstickers/Adhesive?tab=readme-ov-file

It was quite popular and is archived now since "Aug 31, 2024".

signalstickers/Adhesive#32 as I see you are the maintainer, thanks a lot for creating this issue!

I hope you can maybe bring some other people into the boat that may help to bring it up again and fix the technical issues? Do you maybe know some?
Like maybe pinging people who contributed before or so?

I am sure there are many people who would like to use the bot (including myself) and miss it very much!

@rugk
Copy link

rugk commented Sep 9, 2024

Also maybe could you explain the status/progress on signalstickers/Adhesive#32? So am I right to assume, Adhesive was/is rewritten in Rust? And this failed due to this issue here?

https://github.com/signalstickers/Adhesive is Python code currently only, where may I find the new Rust code?

Concrete questions I'd have are:

  • What has been done? How has progress been?
  • What still needs to be done? Are there "road blockers"?
  • Generally, I see you seem to (need to) use MTProto, is not that Telegram's (e2e) encryption protocol? Why do you need to do so at all? Does the bot really need to accept secret e2e encrypted messages (aka "secret chats"?) or would it be fine not to accept them?
  • How much do you estimate the missing workload?
  • Also in general, what is this library here – apparently for Signal?. And more important why do you need it? Technically why does the bot need Signal access? Cannot it convert the Telegram stickers with Telegram access only? (Just asking stupid questions?) As a user, I did not see that before, i.e. the Signal stickers were not provided via Signal, but just via a link in Telegram, which I can open in Signal, which was totally fine for me, personally.

These are some things that maybe can also be put into (technical) documentation or so…

@ioistired
Copy link
Author

ioistired commented Sep 12, 2024

Also maybe could you explain the status/progress on signalstickers/Adhesive#32? So am I right to assume, Adhesive was/is rewritten in Rust? And this failed due to this issue here?

It's planned to be rewritten in Rust, yes.

https://github.com/signalstickers/Adhesive is Python code currently only, where may I find the new Rust code?

There is none as I haven't started on the Rust rewrite.

  • Generally, I see you seem to (need to) use MTProto, is not that Telegram's (e2e) encryption protocol? Why do you need to do so at all? Does the bot really need to accept secret e2e encrypted messages (aka "secret chats"?) or would it be fine not to accept them?

MTProto is not just for e2e, it's for all communication with the Telegram servers. But the rewrite is planned to use the "bot API" instead which is an official HTTP API that wraps the mtproto one.

  • Also in general, what is this library here – apparently for Signal?. And more important why do you need it? Technically why does the bot need Signal access? Cannot it convert the Telegram stickers with Telegram access only? (Just asking stupid questions?) As a user, I did not see that before, i.e. the Signal stickers were not provided via Signal, but just via a link in Telegram, which I can open in Signal, which was totally fine for me, personally.

I guess I could start work on the bot without a Signal side of it, yeah.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants