Arch Linux User Repository

Fails to build for me with a clean chroot:

      /usr/bin/ld: /build/ffsend/src/ffsend-v0.2.76/target/release/deps/ffsend-585952f564175871: hidden symbol `GFp_ia32cap_P' isn't defined
      /usr/bin/ld: final link failed: bad value
      collect2: error: ld returned 1 exit status

      = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
      = note: use the `-l` flag to specify native libraries to link
      = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

    warning: `ffsend` (bin "ffsend") generated 2 warnings
    error: could not compile `ffsend` (bin "ffsend") due to previous error; 2 warnings emitted

I have successfully built this package on aarch64 architecture as well.

@timvisee

Just a big thank you for all the work done with "send" and "ffsend".

Here in the AUR, maintaining the PKGBUILD's and on Gitlab developing the tools.

After hearing about it on Mozilla some years ago, I had forgotten about it.

I only got reminded again about "Send" and "FFsend" when using Libredirect, https://github.com/libredirect/libredirect. (Tip, "Libredirect is also extremely interesting and important for Firefox users)

"Ffsend" is very very usefull and underrated, especially for command line lovers. Pitty it's not better known. Here, and outside Archlinux. Hope this gets more votes. And can make it to Archlinux official packages one day.

"Send" also definetly needs more publicity and mention that can be used with Libredirect, https://reddit.rtrace.io/v50xzf. The decentralized and federation nature of it is a killer feature.

Edit: Disregard this comment. I got confused and mixed up the server and client (send vs ffsend).

Does anyone know which version is the latest one? Or, in other words, which repo is the canonical one for ffsend?

Gitlab has 0.2.74 as the latest (3 months ago) and Github has v3.4.16 (10 days ago). On top of that, the tags on both hosting services don't seem to match (version-wise), and it seems that only Gitlab's CI updates this package.

@alerque Thanks for the comprehensive suggestion on what to change. I've fixed these issues in the ffsend repository, and the PKGBUILDs (for this, and my other Rust projects) will be updated with the next release.

This package should not be specifying the Rust version like it is. The [community] package for rust has a newer version than the minimum and Arch does not support partial upgrades, hence it can be assumed everybody will have at least what is in the official repo.

Actually please review the Arch Rust package guidelines because there are several relevant points this packaging is missing out on. Please just use makedepends=(cargo). The extra export lines will also fix any potential issues for rustup users that have the nightly toolchain set as default. The guidelines also specify how to prefetch dependencies to enable offline and reproducible builds, how to test, and more.

Another point, please don't add the opt-depends for bash-completion. The Shell package guidelines explain why, but this package provides completions, it is not useful to depend of a package which isn't required for the functionality.

if you're using rustup, you can try to patch in a rust-toolchain file[1] which contains your preferred toolchain(e.g. stable-1.40.0) and rustup will make sure to use it. I just don't know if you can make that a range... A workaround here would be to update that patch accordingly with each version to match the current stable branch or else to just pin it to 1.32.

[1] https://doc.rust-lang.org/nightly/edition-guide/rust-2018/rustup-for-managing-rust-versions.html

Yeah, no problem, I suspected it's something like that. As I say it's not too important because I am using the -bin package for now. Thanks for your efforts anyway!

@Flubbadub Good question. The problem with rustup is that you can't properly specify what Rust version must be used (like what is possible when using rust>=1.32). Because of this, the rust>=1.32 dependency is set, which is not compatible with the rustup package.

I did try to detect the installed Rust version when used through rustup when installing the package, to warn the user if they're using an outdated Rust version. But that didn't work so well. I might give it another try soon. If that works, the rust dependency can be removed, allowing you to use either rust or rustup as cargo provider which solves your issue (if that makes sense).