No package for Arch Linux / AUR

[spease]

Currently there isn't a package for Arch Linux or AUR.

[hoehermann]

Would something like this PKGBUILD file suffice?

# Maintainer: Hermann Höhne <[email protected]>
pkgname=purple-presage-git
_pkgnam=${pkgname%-git}
pkgver=0.0.0
pkgrel=1
pkgdesc="Pidgin/libpurple plug-in for Signal messenger using presage"
arch=('x86_64' 'i686')
url="https://github.com/hoehermann/purple-presage"
license=('GPLv3')
groups=()
depends=('libpurple')
makedepends=('git' 'rust' 'cmake' 'make' 'pkg-config')
provides=("${_pkgnam}")
conflicts=("${_pkgnam}")
install=
source=("${_pkgnam}::git+https://github.com/hoehermann/purple-presage.git")
noextract=()
sha256sums=('SKIP')
options=(!lto) # I have no idea why this is needed, but https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/issues/20

prepare() {
  git -C "$srcdir/${_pkgnam}" submodule update --init
  mkdir -p "$srcdir/${_pkgnam}/build"
  export CARGO_HOME="$srcdir/${_pkgnam}/build/cargo_home"
  cd "$srcdir/${_pkgnam}/build"
  cmake -G "Unix Makefiles" ..
}

build() {
  export CARGO_HOME="$srcdir/${_pkgnam}/build/cargo_home"
  cd "$srcdir/${_pkgnam}/build"
  cmake --build .
}

package() {
  export CARGO_HOME="$srcdir/${_pkgnam}/build/cargo_home"
  cd "${srcdir}/${_pkgnam}/build"
  make DESTDIR="$pkgdir/" install/strip
}

[spease]

That almost works on my system. I get some linking errors:

[100%] Linking C shared library libpresage.so
/usr/bin/ld: libpurple_presage_backend.a(ring-a3937bcdd870d785.ring.7753423abb5ab674-cgu.02.rcgu.o): in function `ring::aead::aes::Key::ctr32_encrypt_within':
ring.7753423abb5ab674-cgu.02:(.text._ZN4ring4aead3aes3Key20ctr32_encrypt_within17h0490807eedce7815E+0x3b): undefined reference to `ring_core_0_17_8_OPENSSL_ia32cap_P'
/usr/bin/ld: libpurple_presage_backend.a(ring-a3937bcdd870d785.ring.7753423abb5ab674-cgu.02.rcgu.o): in function `ring::aead::aes::Key::new_mask':
ring.7753423abb5ab674-cgu.02:(.text._ZN4ring4aead3aes3Key8new_mask17hc1bb722e1a1e5cfbE+0x1b): undefined reference to `ring_core_0_17_8_OPENSSL_ia32cap_P'
/usr/bin/ld: ring.7753423abb5ab674-cgu.02:(.text._ZN4ring4aead3aes3Key8new_mask17hc1bb722e1a1e5cfbE+0x79): undefined reference to `ring_core_0_17_8_OPENSSL_ia32cap_P'
/usr/bin/ld: libpurple_presage_backend.a(ring-a3937bcdd870d785.ring.7753423abb5ab674-cgu.02.rcgu.o): in function `ring::aead::aes_gcm::init':
ring.7753423abb5ab674-cgu.02:(.text._ZN4ring4aead7aes_gcm4init17hb7e59fc38ee6358bE+0x9c): undefined reference to `ring_core_0_17_8_OPENSSL_ia32cap_P'
/usr/bin/ld: libpurple_presage_backend.a(ring-a3937bcdd870d785.ring.7753423abb5ab674-cgu.02.rcgu.o): in function `ring::aead::aes_gcm::aes_gcm_seal':
ring.7753423abb5ab674-cgu.02:(.text._ZN4ring4aead7aes_gcm12aes_gcm_seal17hdd3413ad2f324278E+0x1e1): undefined reference to `ring_core_0_17_8_OPENSSL_ia32cap_P'
/usr/bin/ld: libpurple_presage_backend.a(ring-a3937bcdd870d785.ring.7753423abb5ab674-cgu.02.rcgu.o):ring.7753423abb5ab674-cgu.02:(.text._ZN4ring4aead7aes_gcm12aes_gcm_seal17hdd3413ad2f324278E+0x398): more undefined references to `ring_core_0_17_8_OPENSSL_ia32cap_P' follow
/usr/bin/ld: libpurple_presage_backend.a(c322a0bcc369f531-chacha-x86_64-elf.o): relocation R_X86_64_PC32 against undefined hidden symbol `ring_core_0_17_8_OPENSSL_ia32cap_P' can not be used when making a shared object
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/presage.dir/build.make:263: libpresage.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:303: CMakeFiles/presage.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

It builds fine if I go into the build directory and do cmake --build . manually.

I tried building with/without some of the makepkg conf flags and couldn't get it to change / trigger. Not sure what's going on.

[hoehermann]

Strange indeed. Apparently that is due to some "optimization" that is enabled by default when using makepkg. Some details are given at https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/issues/20. I added options=(!lto) to the PKGBUILD above. It seems to be working now.

Icons are missing, though. Nothing critical, but looks a bit ugly and spams the debug log. Tracked in #11.

[spease]

I get a compilation error now. I'm guessing this is just from an API change by a dependency and when I ran it pulled a slightly different version. You might consider checking the Cargo.lock into version control since this is implicitly the end deliverable.

305 |         self.inner.start_send_unpin(item.into()).map_err(Into::into)                                                                                                        10:22:05 [6/1287]
    |                    ^^^^^^^^^^^^^^^^ method cannot be called on `WebSocketStream<Compat<Upgraded>>` due to unsatisfied trait bounds
    |
   ::: /home/spease/projects/purple-presage-aur/src/purple-presage/build/cargo_home/registry/src/index.crates.io-6f17d22bba15001f/async-tungstenite-0.28.1/src/lib.rs:227:1
    |
227 | pub struct WebSocketStream<S> {
    | ----------------------------- doesn't satisfy `_: Sink<_>` or `_: SinkExt<_>`
    |
    = note: the following trait bounds were not satisfied:
            `async_tungstenite::WebSocketStream<Compat<Upgraded>>: futures_util::Sink<_>`
            which is required by `async_tungstenite::WebSocketStream<Compat<Upgraded>>: SinkExt<_>`

error[E0599]: the method `poll_flush_unpin` exists for struct `WebSocketStream<Compat<Upgraded>>`, but its trait bounds were not satisfied
   --> /home/spease/projects/purple-presage-aur/src/purple-presage/build/cargo_home/registry/src/index.crates.io-6f17d22bba15001f/reqwest-websocket-0.4.3/src/lib.rs:309:20
    |
309 |         self.inner.poll_flush_unpin(cx).map_err(Into::into)
    |                    ^^^^^^^^^^^^^^^^
    |
   ::: /home/spease/projects/purple-presage-aur/src/purple-presage/build/cargo_home/registry/src/index.crates.io-6f17d22bba15001f/async-tungstenite-0.28.1/src/lib.rs:227:1
    |
227 | pub struct WebSocketStream<S> {
    | ----------------------------- doesn't satisfy `_: Sink<_>` or `_: SinkExt<_>`
    |
    = note: the following trait bounds were not satisfied:
            `async_tungstenite::WebSocketStream<Compat<Upgraded>>: futures_util::Sink<_>`
            which is required by `async_tungstenite::WebSocketStream<Compat<Upgraded>>: SinkExt<_>`

error[E0599]: the method `poll_close_unpin` exists for struct `WebSocketStream<Compat<Upgraded>>`, but its trait bounds were not satisfied
   --> /home/spease/projects/purple-presage-aur/src/purple-presage/build/cargo_home/registry/src/index.crates.io-6f17d22bba15001f/reqwest-websocket-0.4.3/src/lib.rs:313:20
    |
313 |         self.inner.poll_close_unpin(cx).map_err(Into::into)
    |                    ^^^^^^^^^^^^^^^^
    |
   ::: /home/spease/projects/purple-presage-aur/src/purple-presage/build/cargo_home/registry/src/index.crates.io-6f17d22bba15001f/async-tungstenite-0.28.1/src/lib.rs:227:1
    |
227 | pub struct WebSocketStream<S> {
    | ----------------------------- doesn't satisfy `_: Sink<_>` or `_: SinkExt<_>`
    |
    = note: the following trait bounds were not satisfied:
            `async_tungstenite::WebSocketStream<Compat<Upgraded>>: futures_util::Sink<_>`
            which is required by `async_tungstenite::WebSocketStream<Compat<Upgraded>>: SinkExt<_>`

[hoehermann]

The same error happens on my machine. I assume publishing the Cargo.lock will not solve the issue.

Actually, I do not even understand the problem. This project is not much more than a thin C wrapper around presage-cli. presage pretty much is the only dependency. This is an excerpt of the dependencies as generated by cargo tree:

purple-presage-backend
└── presage v0.7.0-dev (https://github.com/whisperfish/presage?rev=8b9af8e#8b9af8ee)
    └── libsignal-service v0.1.0 (https://github.com/whisperfish/libsignal-service-rs?rev=268e0c4#268e0c47)
        └── reqwest-websocket v0.4.3
            └── async-tungstenite v0.28.1

Provided I read the error message correctly, there is some disagreement between reqwest-websocket and async-tungstenite. I do not have any experience with rust and the cargo environment whatsoever. Do you happen to know if I need to take care about the dependencies manually and recursively?

[spease]

I’m not sure what you’re asking. Generally this kind of compilation error is due to a code issue. It could happen if broken code was merged into git. However usually projects try to prevent this. The most likely reason for it to happen when attempting to build a working git commit from another machine is that the later build ends up using slightly different versions of the dependencies. Cargo is only supposed to fetch n the newest version to a point where the interface will not be broken, however not every project adheres correctly to semver, and most projects are not super careful about specifying dependencies and checking the policies of the dependencies’ versioning.

The error message is complaining that a type does not implement one of the standard async interfaces. The Compat and Upgraded in the names of the types makes it look like this may be some kind of compatibility layer to maintain backwards compatibility. Perhaps either it overlooked implementing the trait, or something about the type prevented a generic impl from taking effect, or it’s pulling in a different version of futures so even though both it and the calling code are specifying a Sink trait, they’re technically two different types in the build due to the divergent versions.

Specifying Cargo.lock will address all of these, because it ensures that exactly the same dependency tree is used for other people building the code as the original CI build that checked it. However it’s only recommended for end products (binaries), because if it’s specified on intermediate libraries it limits the ability of the dependency resolver to find a mutually correct dependency for multiple libraries, which can lead to issues like the divergent versions issue that I mentioned above.

It is possible it’s also because of a genuinely broken commit or some feature flags that aren’t (un)set by default which should be. I’m just saying, generally speaking, for this kind of situation where pulling code will result in l slightly different dependency versions, slightly broken dependencies are not uncommon.

sorry for the long explanation, I wanted to completely explain the issue rather than linking to a few different sources to give the necessary context.

[hoehermann]

Thank you for providing an explanation. I now understand that in the Cargo.toml I can specify https://github.com/whisperfish/presage to be used at commit 8b9af8e. presage depends on other crates and they depend on other crates recursively. It is possible to specify versions in the Cargo.toml. Some projects however do not increment their version numbers reliably. That is why there also is a Cargo.lock. The Cargo.lock not only mentions versions, but also commit hashes. This information is usefull

But where would I get that Cargo.lock file from? If I try to run cargo build --locked, cargo says "Cargo.lock needs to be updated" and refuses to work. If I let cargo update the Cargo.lock, then rustc fails with the Sink trait error. Either way: I did not change anything after 2024-12-04, yet building today still fails. So I guess someone somewhere did indeed mess up, but it is not me. I will not fix problems in the crates I am depending on. That is – unfortunately – way out of scope.

[spease]

Looks like the upstream library fixed this in the last 24 hours.

jgraef/reqwest-websocket#32

I did cargo update and the error disappeared. Basically looks like the dependency tree needs to resolve with reqwest-websocket of at least 0.4.4

[hoehermann]

Nice. 👍 Thank you for investigating this problem!