Package Details: rua 0.19.0-3

Git Clone URL: (read-only, click to copy)
Package Base: rua
Description: AUR helper in Rust providing control, review, patch application and safe build options
Upstream URL:
Keywords: aur rust
Licenses: GPL3
Submitter: vasya
Maintainer: vasya
Last Packager: vasya
Votes: 36
Popularity: 0.57
First Submitted: 2018-10-29 14:26 (UTC)
Last Updated: 2022-04-13 19:47 (UTC)

Dependencies (9)

Required by (0)

Sources (1)

Latest Comments

vasya commented on 2022-04-13 19:48 (UTC)

@yochananmarqos, thanks, you're right, fixed!

yochananmarqos commented on 2022-04-13 19:39 (UTC)

@vasya: That's not what I meant. This package is not architecture independent. The architectures should be specified. See PKGBUILD:arch

vasya commented on 2022-04-13 18:50 (UTC)

@yochananmarqos thanks for testing it! Tricky.. I've added the !lto option to the PKGBUILD.

WRT the architecture: the already built rua package will contain the (ELF) executable, however, if you build it under a different architecture then it'll just have a different ELF. That's pretty much the standard situation for any C package. I know for sure that people use it on arm devices, see some discussions below if curious. (A person actually wrote a PR before to add support for any arch as long as rust, bubblewrap and libseccomp are installable \o/)

yochananmarqos commented on 2022-04-13 17:01 (UTC)

@vasya: With RUSTFLAGS="-C embed-bitcode, it fails to link like I originally reported.

With RUSTFLAGS="-C embed-bitcode -C lto=fat":

   Compiling regex v1.5.5
   Compiling directories v4.0.1
   Compiling libflate v1.2.0
error: cannot prefer dynamic linking when performing LTO

note: only 'staticlib', 'bin', and 'cdylib' outputs are supported with LTO

error: could not compile `proc-macro-error-attr` due to previous error
warning: build failed, waiting for other jobs to finish...

FYI, this is not an 'any' package as it contains an ELF file. The architectures should be specified.

vasya commented on 2022-04-13 16:17 (UTC) (edited on 2022-04-13 16:18 (UTC) by vasya)

@yochananmarqos: could you please try building a Rust package with RUSTFLAGS="-C embed-bitcode" ? 🙏 // I can't reproduce it myself, sorry:(

Or alternatively with lto = "thin" in Cargo.toml in case of rua.

If you don't have time please also just say so. But if you do, a bit of testing would be appreciated

vasya commented on 2022-04-13 16:07 (UTC)

@yochananmarqos (at the moment, rua also uses lto = true, or in other words the lto="fat". But somehow, the setting from PKGBUILD seems to kick in -- for some users.)

yochananmarqos commented on 2022-04-13 15:54 (UTC) (edited on 2022-04-13 15:59 (UTC) by yochananmarqos)

@vasya: Even the Arch packagers are disabling LTO, see the Todo List. It appears it needs to be enabled upstream upstream, see The Cargo Book.

I tried adding RUSTFLAGS="-C lto=fat" to build RUA, but it fails:

error: options `-C embed-bitcode=no` and `-C lto` are incompatible

EDIT: Yes, I'm on x86_64.

vasya commented on 2022-04-13 15:32 (UTC)

@yochananmarqos: by the way, are you on x86_64?

vasya commented on 2022-04-13 15:26 (UTC)

@yochananmarqos: interesting that for me it definitely does build. Do you maybe know what the root cause is / what a general recommendation for fixing it is? I've tried to search through the Rust packages on AUR and some of them indeed just switch off lto, however I couldn't understand why that happens exactly, which issue to link in the comment, what to track even. Do you know? I'll definitely address it somehow, just want to understand how exactly

yochananmarqos commented on 2022-04-13 14:36 (UTC)

@vasya: Like most Rust packages, this fails to build with LTO enabled. Can you add the following?


vasya commented on 2021-10-18 10:13 (UTC)

@kwylder, Thank you!

kwylder commented on 2021-10-16 18:41 (UTC)

I'm really impressed with this software, thank you to all the talented devs that work on this

vasya commented on 2021-09-26 07:32 (UTC)

For anyone's interested: RUA got support for non-x86_64 platforms now, such as i686, arm64, etc. E.g. you can run it on a pinephone, or raspberry Pi, etc. Feel free to raise bugs if something is working suboptimally.

vasya commented on 2021-06-07 18:57 (UTC)

Due to library changes in pacman (5.2.2 -> 6.0.0), rua needs to be re-built from source to work again.

If you see an error message like

rua: error while loading shared libraries: cannot open shared object file: No such file or directory

Then please clone the repo and install the new version via makepkg -si (if you use rustup, then also rustup update)

UPD: updated the URL to the correct one

vasya commented on 2021-06-02 06:36 (UTC) (edited on 2021-06-02 07:09 (UTC) by vasya)

I've created a new version of rua, 0.18.1, which does not depend on libalpm (pacman) anymore. This means that the error below will not happen anymore in the future. Even with major pacman updates, or if you compile pacman itself from source using bleeding-edge ("git") version of it.

vanja_z commented on 2021-06-02 03:23 (UTC)

@vasya thank you!

vasya commented on 2021-06-01 09:25 (UTC)

@vanja_z I've added it to the upgrade notice (pinned message here) now. Thanks! (BTW, it's rustup update)

vanja_z commented on 2021-06-01 08:06 (UTC)

Never mind, I figured out how to fix it, run:

rustup upgrade

Actually I don't know anything about Rust programming lannguage, it sounds like there is a Rust package management system that I had no idea I needed to update until now. Is it possible (if that even makes sense) to add rust upgrade as a build step?

vanja_z commented on 2021-06-01 08:00 (UTC)

@vasya thanks for helping, I still cannot get it to build. I'm getting the same error.

error[E0658]: `match` is not allowed in a `const fn`
   --> /home/vanja/.cargo/registry/src/
156 | /         match address {
157 | |             SocketAddr::V4(_) => Domain::IPV4,
158 | |             SocketAddr::V6(_) => Domain::IPV6,
159 | |         }
    | |_________^
    = note: see issue #49146 <> for more information

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `socket2`.

Any ideas?

vasya commented on 2021-06-01 06:39 (UTC) (edited on 2021-06-07 06:04 (UTC) by vasya)

Due to library changes in pacman (5.2.2 -> 6.0.0), rua needs to be re-built from source to work again.

If you see an error message like

rua: error while loading shared libraries: cannot open shared object file: No such file or directory

Then please clone the repo and install the new version via makepkg -si (if you use rustup, then also rustup update)

vasya commented on 2021-06-01 05:46 (UTC)

@vanja_z, thanks for writing. This is due to a major pacman upgrade (5.2.2-4 -> 6.0.0-2) which did not keep binary compatibility and thus changed the file name. rua needs to change its alpm dependency to work with the new libalpm. I'll try to do that now

vanja_z commented on 2021-06-01 04:19 (UTC)

Hi, I can't build rua anymore since recent updates nor can I run my existing build. Runtime errors with existing build,

rua: error while loading shared libraries: cannot open shared object file: No such file or directory

Build errors,

error[E0658]: `match` is not allowed in a `const fn`
   --> /home/vanja/.cargo/registry/src/
156 | /         match address {
157 | |             SocketAddr::V4(_) => Domain::IPV4,
158 | |             SocketAddr::V6(_) => Domain::IPV6,
159 | |         }
    | |_________^
    = note: see issue #49146 <> for more information

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `socket2`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

vasya commented on 2020-10-18 12:28 (UTC)

@Subject-17 I think that's a good question though. I've created an issue to change the behavior of rua and clean build garbage automatically upon a successful build:

vasya commented on 2020-10-17 21:21 (UTC)

Hey @Subject-17, yes, it is safe to remove ~/.cache/rua. It contains the build cache.

There's also ~/.local/share/rua that stores already built artifacts (in case you want to re-install old versions or temporarily deinstalled ones). And the settings live in ~/.config/rua. Nothing else.

Subject-17 commented on 2020-10-17 20:33 (UTC)

Is there a flag to clear out the rua cache? Is it safe to rm from ./.cache/rua ?

vasya commented on 2020-02-07 23:17 (UTC) (edited on 2020-02-07 23:21 (UTC) by vasya)

Hi aconsolelogger, good question(s). Socks is not supported at the moment. To implement it, we need to use socks for "AUR RPC" requests and for "git" commands. Git commands seem to be proxy-able like this:

For the HTTP part, we use raur library: which in turn uses reqwest. Maybe we can configure a reqwest::Client that has socks proxy configured right inside it. Then we can make all the changes in RUA code only. If not, we'll have to make a PR for raur that adds socks proxy support. This library seems to be reasonably alive, so I think it's pretty doable.

Would you be willing to work on that?

For man pages: they are, unfortunately, not generated yet. I didn't find a convenient tool that would generate it re-using some information from the CLI description. There are different approaches to the man pages, but at least that's one of them. If you have any ideas, feel free to share. Otherwise, rua --help should help for now. For a .conf file - indeed there's none at the moment. I didn't want to opt in into any particular configuration format/style for now. If we can live with just a CLI parameter for now, that's fine by me. If you'd like to see proper config support pushed more, please say so, and whether you'd be willing to participate on implementing it / making design choices on that as well.

UPD: this text suggests that HTTP part can be fixed with just configuring a reqwest client: so we probably won't need to patch raur, only to configure the proper client for it (everything can be fixed just in RUA).

aconsolelogger commented on 2020-02-07 21:46 (UTC)

Is it possible to configure rua to connect using a socks proxy? There doesn't seem to be a manpage and I couldn't find a .conf file either.

Oscar commented on 2019-11-04 16:20 (UTC) (edited on 2019-11-04 16:20 (UTC) by Oscar)

@vasya: I didn't have untracked directories either, but i now uninstalled it (pacman -Rs rua), cloning it into a new folder and executing makepkg -si from there. That solved it, though I'm not sure which one of those steps did ^^

Anyways, thank (both of) you for your help

vasya commented on 2019-11-04 15:25 (UTC) (edited on 2019-11-04 15:26 (UTC) by vasya)

@Oscar: (with the latest edit). I think the directory is still not clean. Otherwise, why would it, for example, write Removing existing $pkgdir/ directory... ? Also, I see no logs of actual compilation. Guessing by the timestamps, it didn't happen. Can you try cleaning with git clean -fd instead of git clean -xfq? The -d option forces to remove untracked files, too.

Oscar commented on 2019-11-04 13:37 (UTC) (edited on 2019-11-04 13:47 (UTC) by Oscar)

@vasya: of course, are there better places than here to post this than here or is this the correct place?

git clean -xfq && makepkg -si (edited to change command and output to clean first & prettified output)

==> Making package: rua 0.14.19-1 (Mon 04 Nov 2019 14:38:25 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading rua-0.14.19.tar.gz...
==> Validating source files with sha256sums...
==> Extracting sources...
  -> Extracting rua-0.14.19.tar.gz with bsdtar
==> Removing existing $pkgdir/ directory...
==> Starting build()...
    Finished release [optimized] target(s) in 0.11s
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "rua"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: rua 0.14.19-1 (Mon 04 Nov 2019 14:39:09 CET)
==> Installing package rua with pacman -U...
loading packages...
warning: rua-0.14.19-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) rua-0.14.19-1

Total Installed Size:  6.10 MiB
Net Upgrade Size:      0.00 MiB

checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
checking available disk space...
:: Processing package changes...
reinstalling rua...
ldconfig: File /usr/lib/ is empty, not checked.
ldconfig: File /usr/lib/ is empty, not checked.
ldconfig: File /usr/lib/ is empty, not checked.
ldconfig: File /usr/lib/ is empty, not checked.
ldconfig: File /usr/lib/ is empty, not checked.
ldconfig: File /usr/lib/ is empty, not checked.
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...

pacman -Q rua

rua 0.14.19-1

which rua or which -a rua


vasya commented on 2019-11-04 12:44 (UTC)

@Oscar: can you please give the full output of makepkg -si and pacman -Q rua?

Oscar commented on 2019-11-04 12:35 (UTC) (edited on 2019-11-04 12:36 (UTC) by Oscar)

@vasya: which -a rua returns the same as which rua

The full error is:

rua upgrade
rua: error while loading shared libraries: cannot open shared object file: No such file or directory

vasya commented on 2019-11-04 12:31 (UTC)

@Morganamilo, ah indeed you're right, an older version would simply fail to build. It's probably an issue with PATH indeed. It can be checked with which -a rua.

Oscar commented on 2019-11-04 12:24 (UTC) (edited on 2019-11-04 12:29 (UTC) by Oscar)

@vasya: It is 0.14.19 and it's the same as the given PKGBUILD. Likewise I'm on the same commit as (3f1206) and on the master branch

@Morganamilo: The only time I ever used cargo install (manually) was to try to update rua as it didn't work through makepkg; it failed telling me that I do not have a default toolchain configured. which rua gives me /usr/bin/rua

Morganamilo commented on 2019-11-04 12:23 (UTC)

Linking is done at compile time. Even if you were trying to build an older version of rua you'd never get the error that does not exist. Instead linking will just fail outright.

My guess is you've used cargo install and now have an old version in PATH, and even though you've installed the new version via makepkg, the old version is still taking priority.

which rua

vasya commented on 2019-11-04 12:18 (UTC)

@Oscar: that's very weird. What version is actually written in the PKGBUILD? It should be 0.14.19, as seen here: Is it also in your local PKGBUILD?

Oscar commented on 2019-11-04 11:54 (UTC)

I've updated the repository and re-installed it using git clean -xfq && git pull && makepkg -si, but it still tells me that does not exist. Is there something I'm missing? (I am on the newest commit of rua and have just upgraded all pacman packages)

vasya commented on 2019-10-25 08:21 (UTC) (edited on 2019-11-04 16:33 (UTC) by vasya)

Those who upgraded pacman in the last days will notice that RUA becomes broken. This is caused by a change in pacman-s underlying library, "libalpm".

You need to install RUA version 0.14.16 or newer to make it work with newest pacman. You can use makepkg -si or cargo install --force rua to re-build RUA, as per instructions here:

vasya commented on 2018-10-31 00:11 (UTC)

I've removed all rustup invocations from the PKGBUILD. Something worth considering though is that ~/.cargo (and possibly ~/.rustup) are shared with normal $HOME anyway. I guess that's a common property of all AUR packages using cargo though.

vasya commented on 2018-10-30 23:23 (UTC)

@eschwartz, to address a very specific comment:

only if you're using your own unsupported helper

Said problem appears whenever rustup is used. If you haven't used it before (for this unix user), this is what you'll get.

Regarding $HOME. Would using cargo itself be safe? It does fetch dependencies and store them in ~/.cargo too... I'd really want a way around this myself...

vasya commented on 2018-10-30 23:17 (UTC) (edited on 2018-10-30 23:17 (UTC) by vasya)

@Morganamilo > Why not just depend on rust? -- That would be ideal. Unfortunately, however, the "rustup" and "rust" packages are in conflict. If the user already uses "rustup", they will have to uninstall it.

coderobe commented on 2018-10-30 23:17 (UTC)

Eli already echoed what i told you on IRC earlier, but for some reason you've only removed parts of it. Could you please get rid of the rest as well? Your package is not special, and this dance is not required - not to mention that your implementation of said hack isn't particularly good either. Seeing your complete lack of understanding on irc regarding this, consider this a warning...

eschwartz commented on 2018-10-30 23:11 (UTC)

puts on Trusted User hat

Suddenly using rustup and installing a toolchain to the user's $HOME is not okay, moreso when the need for doing so is only if you're using your own unsupported helper which breaks this.

If users use rustup, that's their problem, and I guess they shouldn't use toolchains that install themselves to $HOME in order to build packages. This very program was supposedly supposed to prevent issues like this -- it's ironic that the only way to build this PKGBUILD in a sane manner, is to use the program you haven't built yet to do it!

vasya commented on 2018-10-30 19:18 (UTC)

Morganamilo: I guess it's kinda controversal then. From my point of view, requiring anything at all from $HOME when building packages is not nice. Had this story with some PKGBUILDs before, was never happy when such constraint breaks. Especially because I build packages from a separate user. Let's leave it as-is then, for now.

Morganamilo commented on 2018-10-30 18:54 (UTC)

I'll say that AUR helpers are not supported.

If this package fails to build because of a specific helper then it should be on the helper to make it work, not the pkgbuild. (even if this pkgbuild is for that helper).

But that's just what I think. If you do care about having a good pkgbuild you should probably ask on the forums/mailing list/irc to see what they come up with.

vasya commented on 2018-10-30 18:10 (UTC) (edited on 2018-10-30 18:11 (UTC) by vasya)

Morganamilo: another thing about rustup and RUA. The latter currently isolates your $HOME directory, unless you whitelist some paths in ~/.config/rua/ So if you e.g. build RUA inside stock RUA, the PKGBUILD script will have empty $HOME and will not be able to work without a rustup command. I understand that it soulds like unneeded complexity, but naturally, I do want this PKGBUILD to be buildable in a clean environment.

Put it another way. If the environment is shared and properly configured, then these configuration lines will never be "hit". Thoughts?

Morganamilo commented on 2018-10-30 16:39 (UTC)

If a user decides to use rustup it should be their responsibility to manage it. I think it's a bad idea for a pkgbuild to start installing something.

To rephrase what I said. Why not just depend on there already being a valid rust environment already set up like other packages do?

vasya commented on 2018-10-30 16:19 (UTC) (edited on 2018-10-30 16:21 (UTC) by vasya)

Morganamilo: the package does in fact depend on cargo, which is provided by both rust and rustup. So if you have rust installed, everything will work just fine for you.

If, however, you decide to go with rustup, you NEED to also download&install the stable version using rustup itself. This is a rustup limitation, not mine.

EDIT: in other words, users that decide to use rustup cannot just install it via pacman and be ready to build.:( The missing steps are ensured by this PKGBUILD.

Morganamilo commented on 2018-10-30 15:41 (UTC)

Whats up with the rustup calls? Why not just depend on rust? I don't see any reason a pkgbuild should trigger an update/install of something. Especially something not managed by pacman.