Arch Linux User Repository

i get an error while rusts compile paru, something related to "backtrace" in src/lib.rs. (it happens with paru-git too)

@jmvazquezes Are you using rustup? Try rustup update.

I got this error: error: failed to parse manifest at /tmp/paru-6965007266957474182/paru/src/paru-1.11.0/Cargo.toml

Caused by: feature edition2021 is required

this Cargo does not support nightly features, but if you switch to nightly channel you can add cargo-features = ["edition2021"] to enable this feature

I have run this command on all machines - and then forgot it. I was not in focus that the folder contents can vanish without my action. I have 8 machines running Arch Linux - and the issue was present on all machines... Very strange! Thanks to you for pointing me to the right direction.

@df8oe: It's empty by default on a clean arch install. You have to run the command I mentioned before using paru in chroot mode.

That's why I mentioned: I'm under the impression that this is not mentioned in some obvious place in the docs, but it only happens once when you set up a new system.

@whynothugo: that was the issue. Strange that this folder was empty on all systems I own. I have not deleted any files there...

@df8oe: Is /var/lib/aurbuild/x86_64/root empty? I've seen the same issue you're seeing each time I bootstrap a new system. You need to run mkarchroot /var/lib/aurbuild/aarch64/root base base-devel.

I'm not sure if it's a bug in makechrootpkg, or just a missing steps in the docs somewhere.

@MarsSeed: Misunderstanding. I meant I cannot build any other package using
paru --chroot -S package_name which worked before flawlessly. I cannot provide the exact time the issue popped up: I do not build in chroot very often.

@df8oe, last change was on 2022-02-17.

And it was only a version bump.

Therefore the error you've encountered is unlikely to be coming from paru's PKGBUILD.

paru stops building in a chroot environment on all of my machines:
==> ERROR: This must be run in a directory containing a PKGBUILD. Fehler: Ausführung fehlgeschlagen: makechrootpkg -C /tmp/.tmplqx3u4 -M /etc/makepkg.conf /var/lib/aurbuild/x86_64/root base-devel:
Any ideas what can be the cause?

Oh, and base-devel is not a package, therefore it does not have dependencies.

It is a package group, which is not more than a textual tag given to certain packages.

To install all packages "tagged" with base-devel, users have to run:

sudo pacman -Syu --needed base-devel

@RobinHood2015 pkgconf is part of the group base-devel on Manjaro.

Neither Arch nor Manjaro installs base-devel group as a whole upon fresh install.

Users have to manually install this group of packages before using foreign PKGBUILDs.

Tested on riscv64. Would you be willing to add this as a supported arch?

Trying to install paru on a fresh Manjaro install returns the output in this pastebin URL. https://pastebin.com/2aUgPvkf

Therefore, I would like to consider adding pkgconf as a dependency, because for some reason Manjaro doesn't include this package when doing a fresh install of the OS, even though installing base-devel should automatically pull in pkgconf as one of ITS dependencies.

rustup update stable was insufficient, I also needed to rustup default stable.

After update the version of rust, the build problem resolved. Thanks for @MarsSeed @lesto

@rrenn it seems you were using a Rust version lower than v1.57.0.

Rust v1.57.0 marked the Command::get_program and Command::get_args APIs stable.

Current Rust version in Arch is v1.58.1.

@rrenn, @zjeffer I cannot reproduce either problem. For me, paru builds without any errors.

I am using extra/rust package for rust/cargo, not rustup.

What rust tool and version did you use for the builds?

PSA: before reporting compilation issue, make sure you updated to latest stable rust toolchain with rustup update stable

I can't install the latest update:

==> Starting build()...
error: failed to get `alpm` as a dependency of package `paru v1.9.3 (/home/zjeffer/.cache/paru/clone/paru/src/paru-1.9.3)`

Caused by:
  failed to create directory `/cargo/registry/index/github.com-1ecc6299db9ec823`

Caused by:
  Permission denied (os error 13)
==> ERROR: A failure occurred in build().
    Aborting...
error: failed to build 'paru-1.9.3-1': 
error: packages failed to build: paru-1.9.3-1

Why is it trying to create a directory in /cargo, and not in ~/.cargo? Is this expected behaviour?

Build failed!

paru 1.9.3-1

   Compiling tokio-native-tls v0.3.0
   Compiling tokio-socks v0.5.1
   Compiling async-compression v0.3.12
   Compiling futures v0.3.21
   Compiling aur-fetch v0.10.0
   Compiling h2 v0.3.11
   Compiling string_cache v0.8.3
   Compiling serde_urlencoded v0.7.1
   Compiling kuchiki v0.8.1
   Compiling hyper v0.14.17
   Compiling hyper-tls v0.5.0
   Compiling reqwest v0.11.9
   Compiling raur v5.0.1
   Compiling aur-depends v1.0.3
   Compiling paru v1.9.3 (/home/arch/.cache/paru/clone/paru/src/paru-1.9.3)
error[E0658]: use of unstable library feature 'command_access'
  --> src/exec.rs:83:13
   |
83 |         cmd.get_program().to_string_lossy(),
   |             ^^^^^^^^^^^
   |
   = note: see issue #44434 <https://github.com/rust-lang/rust/issues/44434> for more information

error[E0658]: use of unstable library feature 'command_access'
  --> src/exec.rs:84:13
   |
84 |         cmd.get_args()
   |             ^^^^^^^^
   |
   = note: see issue #44434 <https://github.com/rust-lang/rust/issues/44434> for more information

For more information about this error, try `rustc --explain E0658`.
error: could not compile `paru` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed
==> ERROR: A failure occurred in build().
    Aborting...
error: failed to build 'paru-1.9.3-1':

paru -S paru
:: Resolving dependencies...
:: Calculating conflicts...
:: Calculating inner conflicts...

Aur (1) paru-1.9.2-1

:: Proceed to review? [Y/n]: y

:: Downloading PKGBUILDs...
 (1/1) paru-1.9.2-1                                  [---------------------------------------------------------]
:: Proceed with installation? [Y/n]: y
fetching devel info...
==> Making package: paru 1.9.0-1 (Sun 02 Jan 2022 12:51:11 AM CST)
==> Retrieving sources...
  -> Downloading paru-1.9.0.tar.gz...

pacman thinks its installing paru 1.9.2, but downloads (and ends up installing) paru 1.9.0, leading to paru trying to upgrade itself every time it is run. Trued @th1nhhdk s advice, but files faile to sha validate, for obvious reasons. Im thinking this repository/the current paru version might be slightly broken...

If you want to use v1.9.1 then edit line 3: pkgver=1.9.0 to pkgver=1.9.1 then makepkg it, or for paru-bin: https://cdn.discordapp.com/attachments/915042427927158854/918146456291012689/paru-1.9.1-1-x86_64.pkg.tar.zst

Why is this still at 1.9.0 when 1.9.1 is out? Is there a regression or bug going on? I'm curious.

pkgconf belongs to base-devel, so there's no need for a dependency.

Please add a makedepends to pkgconf, otherwise the build fails:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Could not run `"pkg-config" "--libs" "--cflags" "libalpm" "libalpm >= 13.0.0"`
The pkg-config command could not be found.

Got the same error, your rust toolchain is outdated. rfonseca posted the solution.

I was also getting the same compilation error. The problem was that rustc was not updated.

I've installed rustup instead of the rust package. So I had to run rustup update to update rustc and after that it worked.

This package does not build after the update:

error: doc alias attribute expects a string: #[doc(alias = "0")]
  --> /home/ineu/.cargo/registry/src/github.com-1ecc6299db9ec823/alpm-2.1.3/src/db.rs:13:7
   |
13 | #[doc(alias("repo", "repository"))]
   |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^

   Compiling locale_config v0.3.0
   Compiling env_logger v0.9.0
error: aborting due to previous error

error: could not compile `alpm`

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

Actually yes, I think doas / su / friends should be listed as optdepends here.

Also this should probably depend on base-devel. It is assumed for all package building scenarios, and even though it is part of the instructions to install this, right now you can install it (e.g. directly from my unofficial user repository) on a fresh base system without being forewarned that it really needs base-devel to function as anything beyond a pacman alias.

By that logic pacman should (opt)depend on fakeroot and sudo too, because makepkg uses them at runtime. Anyway I guess the issue at hand is that people specifically remove sudo after installing base-devel, because they want to use doas or su or some such. That's going to lead to issues down the road either way, e.g. when using devtools.

@alad, sudo is included in the base-devel, however should still be listed as an optdepends=(). I believe listing sudo in optdepends=() makes it clear for PKGBUILD readers.

@Alad That logic applies to makedepends=(), not for depends=(). Anything is base-deve! is presumed and does not need to be listed as a build time dependency. In this case sudo is a optional run time dependency, hence it can (and I believe should) be listed as such. It is not part of base.

sudo is part of base-devel, so no, it should not be listed as a dependency - not a regular one, nor an optional one.

@alergue,I agree, sudo should be listed as an optdepends.

@mimshipio No, there are several things you can do with this without sudo, and there are alternative ways of gaining escalated privileges. It should probably be listed as an optdepends though.

Shouldn't sudo be a dependency? I mean paru needs sudo for privilege elevation to install packages

Thanks @alerque.

@adrianteri It sounds like you cloned the wrong repo. You don't clone the GitHub source repo, you clone this packaging repo (link above in package details). The PKGBUILD is very much there ;-)

QN on first installation(Using instructions in README). The PKGBUILD is missing from the cloned GiHub repo is this by design or was removed by mistake?

The CI makes a draft release. I hate automated releases and it lets me write the changelog in before publishing.

It does make me wonder what happened to this CI run that claims to have been successful. I don't see the expected results...

@Det True this PKGBUILD uses the git archive source link anyway, but for projects that actually use releases as opposed to just tagging, the extra automated stuff can be important. If it goes wrong you make want to fix it and try again, in which case the hash would change. Packaging any platform before all platform builds are finished would be a mistake.

+ but basically the tarball for the non-release tagged one is the same (even when released), it only has some extra testing parts that don't even affect the build.

@Det The difference is pretty obvious in the GitHub interface if you look at the releases page. You can see what are just tags and what tags have been turned into releases with changelogs and attached assets at a glance. Another way to tell is using the latest keyword link.

Idek what that means. :heart:

You can consider the tag as "going gold" in video game terms.

Ah. Slightly confusing.

This doesn't even use the binaries. :shrug:

Tags are just part of version control. Weather it's released or not is separate. Especially since the tag triggers the CI to do stuff to prepare for the release such as binary builds.

You tagged 1.7.3 tho, and it's obtainable from https://github.com/Morganamilo/paru/archive/refs/tags/v1.7.3.tar.gz?

1.7.2 is still the latest: https://github.com/Morganamilo/paru/releases

Why is not this PKGBUILD updated? The out of date flags were removed several times.

Wooow. Written in Rust. My hats off to you, sir.

It's also the highest-ranked pkg by the little aggressive "popularity" (https://aur.archlinux.org/packages/?O=0&SeB=nd&SB=p&SO=d&PP=50&do_Search=Go) (aggressive, because its calculation is 0.98^[day], so e.g. after 35 days, the "vote" is already worth less than 0.5 a vote).

@attila123

Nothing serious, it's just the normal process when a popular library makes changes

• alpm is pacman (a library of)
• paru depends on pacman
• pacman5 library name libalpm.so.12 changed to libalpm.so.13 in pacman6
• an so on, on systems with pacman6, it is necessary to rebuild the products dynamically linked on pacman5.

You must be wondering but why did they change the name of the library. This is to force clients to rebuilt their dependent applications.

If they had not done this, the applications would crash in segmentation fault because of the functions which have changed in the library.

So finally, instead of having a segmentation fault that is difficult to understand, you have a nice message that tells you that libalpm.so.12 is missing.

A common approach to know from where the file is comming is to execute pacman/paru -F libalpm.so.12, you notice that libalpm.so.12 no longer officially exists, so you search by deduction for libalpm.so.13 and you find that it matches pacman.

Hi, not sure what is this alpm thing, but manually rebuilding paru helped.
Symptom: "paru: error while loading shared libraries: libalpm.so.12: cannot open shared object file: No such file or directory"

sudo pacman -S --needed base-devel
git clone https://aur.archlinux.org/paru.git
cd paru
makepkg -si

After this it worked fine. Source of info: https://magyarlinux.hu/paru-yay-gyorsjavitas/ (well, it is in Hungarian)

Second the explicit dependency note:

depends=('pacman>=6')

As @johnnybash says it's just another error, but at least it is the right one early on so people don't get messed up with cryptic things later, and it gets the blame where it belongs.

depending on pacman 6 just gives you another error message.

there's really no solution but waiting for manjaro to catch up.

this build error for v1.7 is discussed in more detail here: https://github.com/Morganamilo/paru/issues/391

it seems to affect the Manjaro distribution as it still uses pacman 5.2

I would suggest making explicit the dependency on pacman 6, i.e.:

--- PKGBUILD.orig       2021-06-02 12:37:02.564049924 +0100
+++ PKGBUILD    2021-06-02 12:42:05.389066870 +0100
@@ -9,7 +9,7 @@
 arch=('i686' 'pentium4' 'x86_64' 'arm' 'armv7h' 'armv6h' 'aarch64')
 license=('GPL3')
 makedepends=('cargo')
-depends=('git' 'pacman')
+depends=('git' 'pacman>=6.0.0')
 optdepends=('asp: downloading repo pkgbuilds' 'bat: colored pkgbuild printing' 'devtools: build in chroot')
 sha256sums=('68e1761d3e6bcebce18bef6c49a8f0b00ce3469de7a7297e21b95e94407f24af')

@class101 Yeah, I'm on Manjaro Testing Branch so I'll have to wait a few days for the libalpm.so.13 update to roll out to my branch.

can confirm that the update from 1.6.2 to 1.70 solves the problem I was having, https://aur.archlinux.org/cgit/aur.git/commit/?h=paru&id=b4ac587bba5990ede9ea04e42d7d57a24a190271

@caleb:

... your system is out of date... run pacman -Syu

my system was not out of date, when posting this issue.

Everyone posting issues here on AUR with aur helpers like paru or yay,, makes sure that before posting:

• They have the latest pacman version
• Their system is up to date
• They remove any previous versions or leftovers of yay or paru

@freecorndogs

I think yes, one way to verify is /usr/lib/libalpm.so should link to libalpm.so.13, if it is libalpm.so.12 you are on the older version

I am also getting the error

error: failed to run custom build command for alpm v2.0.0

this version of alpm.rs does not support libalpm v12.0.2 only v13.x.0 is supported

My guess is that it's due to I'm running Manjaro and libalpm is a version behind?

With 1.7 I get Failed to find OpenSSL development headers. openssl is installed.

@m040601 Your base system is out of date. Run pacman -Syu (or paru --repo -Syu if you still have a previous version working) to get your base system updated first, then it will build and run fine using the commands you showed.

Rather CARGO_MAKEFLAGS

Shouldn't RUSTFLAGS be used for that?

Could we extract -j N from MAKEFLAGS and pass to cargo ?

Check out my solution for scons:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=boost-python2#n38

local JOBS; JOBS="$(grep -oP -- "-j\s*[0-9]+" <<< "${MAKEFLAGS}")" || JOBS="-j1"
cargo build "${JOBS}" --locked --features "${_features:-}" --release --target-dir target

v1.7 not building, got this error:

error: failed to run custom build command for `alpm v2.0.0`

Confirming that 1.7.0 works for me as well. It builds without a hitch and installs properly. Running and updating works as well. Built from git clone.

@m040601: Version 1.7.0 has been released and works for me

PKGBUILD out of date : does not support libalpm v13.0.0 only v12

According to https://github.com/Morganamilo/paru,

Installation
sudo pacman -S --needed base-devel
git clone https://aur.archlinux.org/paru.git
cd paru
makepkg -si

this gives

error: failed to run custom build command for `alpm v1.1.12`

Caused by:
  process didn't exit successfully: `/dev/shm/paru/src/paru-1.6.1/target/release/build/alpm-f7f9f91cea045c0b/build-script-build` (exit code: 101)
  --- stderr
  thread 'main' panicked at 'this version of alpm.rs does not support libalpm v13.0.0 only v12.x.0 - v12.x.2 is supported', /home/a1/.cargo/registry/src/github.com-1ecc6299db9ec823/alpm-1.1.12/build.rs:18:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

For me Paru works a lot better than Yay. The problem that bothered me the most with this last one, it was always missing updates of git packages. I see you reworked this part, thank you for that.

Now I can fully trust my AUR helper because it does things the right way :)

@totogtr thank you! Had that issue for a while now. Thx for the fix :)

I'm having an issue with release 1.6.1-1, seems related to anyhow dependency. If anyone is having the same issue a rustup default stable (never did that before) seems to correct the issue.

 Compiling pacmanconf v1.0.0
 Compiling tracing v0.1.26
 Compiling tendril v0.4.2
error[E0433]: failed to resolve: could not find `addr_of` in `ptr`
 --> /home/tom/.cargo/registry/src/github.com-1ecc6299db9ec823/anyhow-1.0.40/src/error.rs:606:14
    |
606 |         ptr::addr_of!((*unerased.as_ptr())._object) as *mut E,
     |              ^^^^^^^ could not find `addr_of` in `ptr`

error[E0433]: failed to resolve: could not find `addr_of` in `ptr`
   --> /home/tom/.cargo/registry/src/github.com-1ecc6299db9ec823/anyhow-1.0.40/src/error.rs:647:22
    |
647 |                 ptr::addr_of!((*unerased.as_ptr())._object) as *mut E,
    |                      ^^^^^^^ could not find `addr_of` in `ptr`

   Compiling unicode-normalization v0.1.17
error: aborting due to 2 previous errors

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

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
==> ERROR: A failure occurred in build().
Aborting...
:: Packages failed to build: paru-1.6.1-1
 ✘  ~  paru --version 
paru v1.5.1 +backtrace - libalpm v12.0.2
 ~  rustc --version 
rustc 1.51.0-nightly (a4cbb44ae 2021-01-20)

@andrej It would be helpful to include more information like the version of rustc you're using. Latest stable (1.51.0) doesn't seem to have any issues with alpm 1.1.8. Another thing to try is possibly running "cargo update" - maybe something in the dependency tree is outdated.

I’m running into E0367 when trying to build this (caused by alpm).

   Compiling alpm v1.1.8
error[E0367]: The requirement `for<'b> T: list::IntoAlpmListItem<'a, 'b>` is added only by the Drop impl.
   --> /home/andrej/.cargo/registry/src/github.com-1ecc6299db9ec823/alpm-1.1.8/src/list.rs:193:1
    |
193 | / impl<'a, T> Drop for AlpmListMut<'a, T>
194 | | where
195 | |     for<'b> T: IntoAlpmListItem<'a, 'b>,
196 | | {
...   |
208 | |     }
209 | | }
    | |_^
    |
note: The same requirement must be part of the struct/enum definition
   --> /home/andrej/.cargo/registry/src/github.com-1ecc6299db9ec823/alpm-1.1.8/src/list.rs:175:1
    |
175 | / pub struct AlpmListMut<'a, T>
176 | | where
177 | |     for<'b> T: IntoAlpmListItem<'a, 'b>,
178 | | {
179 | |     list: AlpmList<'a, T>,
180 | | }
    | |_^

error[E0367]: The requirement `for<'b> T: list::IntoAlpmListItem<'a, 'b>` is added only by the Drop impl.
   --> /home/andrej/.cargo/registry/src/github.com-1ecc6299db9ec823/alpm-1.1.8/src/list.rs:447:1
    |
447 | / impl<'a, T> Drop for IntoIterMut<'a, T>
448 | | where
449 | |     for<'b> T: IntoAlpmListItem<'a, 'b>,
450 | | {
...   |
453 | |     }
454 | | }
    | |_^
    |
note: The same requirement must be part of the struct/enum definition
   --> /home/andrej/.cargo/registry/src/github.com-1ecc6299db9ec823/alpm-1.1.8/src/list.rs:439:1
    |
439 | / pub struct IntoIterMut<'a, T>
440 | | where
441 | |     for<'b> T: IntoAlpmListItem<'a, 'b>,
442 | | {
443 | |     list: ManuallyDrop<AlpmListMut<'a, T>>,
444 | |     current: *mut alpm_list_t,
445 | | }
    | |_^

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0367`.
error: could not compile `alpm`.
warning: build failed, waiting for other jobs to finish...
error: build failed

@B28302: It means those packages neither exist in the Arch repos nor AUR. It appears you're using Manjaro and those packages were removed.

What does this mean...

$ paru -Syu

:: Synchronizing package databases...

core is up to date

extra is up to date

community is up to date

multilib is up to date

:: Starting full system upgrade...

there is nothing to do

:: Looking for AUR upgrades

:: Looking for devel upgrades

:: Packages not in the AUR: linux-latest linux-latest-headers

there is nothing to do

Should the packages "linux-latest linux-latest-headers" be in AUR?

Why does it also say "Starting full system upgrade" (implying an action), yet "there is nothing to do" (no action)?

1.5.0 released https://github.com/Morganamilo/paru/commit/8835524f1d4c736e6e755563ac9798440212a1d0

You're using an old rust version.

When trying to update to paru v1.2.1-1 I'm getting the following messages during compilation:

error[E0658]: use of unstable library feature 'inner_deref': newly added --> src/upgrade.rs:294:29 | 294 | let remote = remote.as_deref().unwrap_or("devel"); | ^^^^^^^^ | = note: see issue #50264 https://github.com/rust-lang/rust/issues/50264 for more information

error[E0658]: use of unstable library feature 'inner_deref': newly added --> src/upgrade.rs:341:29 | 341 | let remote = remote.as_deref().unwrap_or("devel"); | ^^^^^^^^ | = note: see issue #50264 https://github.com/rust-lang/rust/issues/50264 for more information

error: aborting due to 2 previous errors

Seems a problem with Rust (?) I have two machines.

One has the rust package installed, paru updated succesfully.

The other one has rustup, so... perhaps there's some incompatibility here?

Hello, I found a little problem. fish completion is installed to wrong place.

Should install to /usr/share/fish/vendor_completions.d/

Directories for third-party software vendors to ship their own completions for their software. Fish searches the directories in the XDG_DATA_DIRS environment variable for a fish/vendor_completions.d directory; if this variable is not defined, the default is usually to search /usr/share/fish/vendor_completions.d and /usr/local/share/fish/vendor_completions.d;

Ref: https://fishshell.com/docs/current/#where-to-put-completions

Odd. I can't really explain it. But it seems that zsh-completions should be added as an optional dependency.

@WhyNotHugo I did not have the zsh-completions package installed, although all other completions did work for me. Now that I installed zsh-completions by your suggestion, the completions for this package work too.

@0100001001000010 autocompletions work fine for me. Do you have the zsh-completions package installed?

Do other completions work for you?

On my machine, the zsh completions don't work even if copied into /usr/share/zsh/site-functions/_paru as suggested by @yochananmarqos and @tytan652.

@nasdack: See this issue: https://github.com/Morganamilo/paru/issues/117

   Compiling reqwest v0.10.8
   Compiling raur v4.0.0
   Compiling kuchiki v0.8.1
   Compiling aur-depends v0.10.0
   Compiling paru v1.1.4 (/home/eh8/.cache/paru/clone/paru/src/paru-1.1.4)
error: could not compile `paru`

on armv7h, I used to be able to compile previous versions.

@Morganamilo: As @tytan652 mentioned, the zsh completions should be in /usr/share/zsh/site-functions/ as completion does not work where there are now.

install -Dm644 completions/zsh "${pkgdir}/usr/share/zsh/site-functions/_paru"

The zsh completion would be better in /usr/share/zsh/site-functions/ like yay or trizen

The source file has no file extension, it should be:

source=("$pkgname-$pkgver.tar.gz::https://github.com/Morganamilo/paru/archive/v$pkgver.tar.gz")

Please add a backup() array for the conf file, see PKGBUILD:backup:

``` backup=('etc/paru.conf')

Paru compiles and seems to run fine on aarch64. Would you mind adding it to the PKGBUILD arches?

Whoops, Just typo'd a single ?.

However the other checks are indeed useful. pacman-git has a different api/abi so it needs to be accounted for. And rust nightly is indeed in the repos via rustup.

This already depends on git, no need to check for it. There is no rust nightly package, no use checking for it, either. It fails, anyway:

error: Package `paru v0.99.0 (/home/yochanan/Documents/pkgbuilds/paru/src/paru-0.99.0)` does not have these features: `?`