Package Details: paru 1.11.1-1

Git Clone URL: (read-only, click to copy)
Package Base: paru
Description: Feature packed AUR helper
Upstream URL:
Keywords: AUR helper pacman rust wrapper yay
Licenses: GPL3
Submitter: Morganamilo
Maintainer: Morganamilo
Last Packager: Morganamilo
Votes: 582
Popularity: 31.96
First Submitted: 2020-10-19 00:43 (UTC)
Last Updated: 2022-07-07 08:12 (UTC)

Dependencies (6)

Required by (13)

Sources (1)

Latest Comments

SpidFightFR commented on 2022-08-10 13:50 (UTC)

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

whynothugo commented on 2022-06-29 14:59 (UTC)

@jmvazquezes Are you using rustup? Try rustup update.

jmvazquezes commented on 2022-06-29 14:42 (UTC)

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

df8oe commented on 2022-03-22 18:23 (UTC)

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.

whynothugo commented on 2022-03-22 17:38 (UTC)

@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.

df8oe commented on 2022-03-22 17:16 (UTC)

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

whynothugo commented on 2022-03-22 15:48 (UTC)

@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.

df8oe commented on 2022-03-22 15:24 (UTC)

@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.

MarsSeed commented on 2022-03-22 15:06 (UTC)

@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.

df8oe commented on 2022-03-22 13:14 (UTC)

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?

MarsSeed commented on 2022-03-20 10:11 (UTC)

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

MarsSeed commented on 2022-03-20 10:07 (UTC)

@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.

sajattack commented on 2022-03-20 07:04 (UTC)

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

RobinHood2015 commented on 2022-03-08 02:18 (UTC) (edited on 2022-03-08 02:23 (UTC) by RobinHood2015)

Trying to install paru on a fresh Manjaro install returns the output in this pastebin URL.

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.

Ataraxy commented on 2022-02-21 08:33 (UTC) (edited on 2022-02-21 08:47 (UTC) by Ataraxy)

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

rrenn commented on 2022-02-20 15:20 (UTC)

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

MarsSeed commented on 2022-02-18 19:41 (UTC) (edited on 2022-02-18 19:42 (UTC) by MarsSeed)

@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.

MarsSeed commented on 2022-02-18 19:22 (UTC)

@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?

lesto commented on 2022-02-18 12:43 (UTC)

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

zjeffer commented on 2022-02-18 12:34 (UTC)

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/`

Caused by:
  Permission denied (os error 13)
==> ERROR: A failure occurred in build().
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?

rrenn commented on 2022-02-18 10:39 (UTC)

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/
83 |         cmd.get_program().to_string_lossy(),
   |             ^^^^^^^^^^^
   = note: see issue #44434 <> for more information

error[E0658]: use of unstable library feature 'command_access'
  --> src/
84 |         cmd.get_args()
   |             ^^^^^^^^
   = note: see issue #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().
error: failed to build 'paru-1.9.3-1':

Toric commented on 2022-01-02 06:53 (UTC)

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...

th1nhhdk commented on 2021-12-08 14:34 (UTC) (edited on 2021-12-08 14:35 (UTC) by th1nhhdk)

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:

epoch32 commented on 2021-12-07 02:22 (UTC)

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.

johnnybash commented on 2021-11-18 16:08 (UTC)

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

egore911 commented on 2021-11-18 15:54 (UTC) (edited on 2021-11-18 15:55 (UTC) by egore911)

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.

huglwutz commented on 2021-11-13 10:04 (UTC)

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

rfonseca commented on 2021-11-12 19:51 (UTC) (edited on 2021-11-12 19:51 (UTC) by rfonseca)

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.

Ineu commented on 2021-11-05 13:00 (UTC)

This package does not build after the update:

error: doc alias attribute expects a string: #[doc(alias = "0")]
  --> /home/ineu/.cargo/registry/src/
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...

alerque commented on 2021-08-12 07:25 (UTC)

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.

Alad commented on 2021-08-11 21:32 (UTC) (edited on 2021-08-11 21:33 (UTC) by Alad)

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.

dominicegginton commented on 2021-08-10 11:23 (UTC)

@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.

alerque commented on 2021-08-10 07:09 (UTC)

@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.

Alad commented on 2021-08-09 07:15 (UTC)

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

dominicegginton commented on 2021-07-27 08:16 (UTC)

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

alerque commented on 2021-07-27 08:10 (UTC)

@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.

mimshipio commented on 2021-07-27 01:06 (UTC)

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

adrianteri commented on 2021-07-19 14:31 (UTC)

Thanks @alerque.

alerque commented on 2021-07-19 13:13 (UTC)

@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 ;-)

adrianteri commented on 2021-07-19 12:50 (UTC)

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?

Morganamilo commented on 2021-06-25 17:59 (UTC)

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

alerque commented on 2021-06-25 17:52 (UTC)

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

alerque commented on 2021-06-25 17:41 (UTC)

@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.

Det commented on 2021-06-25 17:37 (UTC) (edited on 2021-06-25 17:39 (UTC) by Det)

+ 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.

alerque commented on 2021-06-25 17:36 (UTC) (edited on 2021-06-25 17:38 (UTC) by alerque)

@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.

Det commented on 2021-06-25 17:02 (UTC)

Idek what that means. :heart:

Morganamilo commented on 2021-06-25 17:00 (UTC)

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

Det commented on 2021-06-25 16:59 (UTC)

Ah. Slightly confusing.

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

Morganamilo commented on 2021-06-25 16:54 (UTC)

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.

Det commented on 2021-06-25 16:48 (UTC)

You tagged 1.7.3 tho, and it's obtainable from

Morganamilo commented on 2021-06-25 16:38 (UTC)

1.7.2 is still the latest:

Spixmaster commented on 2021-06-25 16:37 (UTC)

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

Det commented on 2021-06-18 08:58 (UTC)

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

It's also the highest-ranked pkg by the little aggressive "popularity" ( (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).

class101 commented on 2021-06-07 09:28 (UTC) (edited on 2021-06-07 09:28 (UTC) by class101)


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 changed to 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 is missing.

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

attila123 commented on 2021-06-07 08:52 (UTC)

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

sudo pacman -S --needed base-devel
git clone
cd paru
makepkg -si

After this it worked fine. Source of info: (well, it is in Hungarian)

alerque commented on 2021-06-02 16:15 (UTC)

Second the explicit dependency note:


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.

johnnybash commented on 2021-06-02 12:23 (UTC)

depending on pacman 6 just gives you another error message.

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

ebo commented on 2021-06-02 11:44 (UTC) (edited on 2021-06-02 11:44 (UTC) by ebo)

this build error for v1.7 is discussed in more detail here:

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')
-depends=('git' 'pacman')
+depends=('git' 'pacman>=6.0.0')
 optdepends=('asp: downloading repo pkgbuilds' 'bat: colored pkgbuild printing' 'devtools: build in chroot')

freecorndogs commented on 2021-06-01 16:05 (UTC)

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

m040601 commented on 2021-06-01 15:15 (UTC)

can confirm that the update from 1.6.2 to 1.70 solves the problem I was having,


... 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

class101 commented on 2021-06-01 13:51 (UTC) (edited on 2021-06-01 13:52 (UTC) by class101)


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

freecorndogs commented on 2021-06-01 13:46 (UTC) (edited on 2021-06-01 13:52 (UTC) by freecorndogs)

I am also getting the error

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

this version of 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?

zerophase commented on 2021-06-01 11:52 (UTC)

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

alerque commented on 2021-06-01 08:57 (UTC) (edited on 2021-06-01 09:00 (UTC) by alerque)

@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.

bartus commented on 2021-06-01 08:32 (UTC)


starquake commented on 2021-06-01 08:13 (UTC)

Shouldn't RUSTFLAGS be used for that?

bartus commented on 2021-06-01 07:42 (UTC)

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

Check out my solution for scons:

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

protolatte commented on 2021-06-01 07:15 (UTC)

v1.7 not building, got this error:

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

TheToblin commented on 2021-06-01 06:37 (UTC)

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.

starquake commented on 2021-06-01 06:14 (UTC) (edited on 2021-06-01 06:15 (UTC) by starquake)

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

m040601 commented on 2021-06-01 03:30 (UTC) (edited on 2021-06-01 03:31 (UTC) by m040601)

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

According to,

sudo pacman -S --needed base-devel
git clone
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 does not support libalpm v13.0.0 only v12.x.0 - v12.x.2 is supported', /home/a1/.cargo/registry/src/
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

class101 commented on 2021-05-15 15:39 (UTC)

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 :)

androide7461 commented on 2021-05-10 21:02 (UTC)

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

totogtr commented on 2021-05-05 07:18 (UTC) (edited on 2021-05-05 07:26 (UTC) by totogtr)

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/
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/
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().
:: 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)

KerfuffleV2 commented on 2021-04-16 01:53 (UTC)

@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.

andrej commented on 2021-04-12 21:54 (UTC)

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/
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/
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/
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/
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

yochananmarqos commented on 2021-04-01 23:37 (UTC)

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

B28302 commented on 2021-04-01 22:47 (UTC) (edited on 2021-04-01 22:52 (UTC) by B28302)

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)?

nainar commented on 2021-03-30 11:48 (UTC)

1.5.0 released

Morganamilo commented on 2021-02-03 23:35 (UTC)

You're using an old rust version.

jstitch commented on 2021-02-03 18:15 (UTC) (edited on 2021-02-03 18:17 (UTC) by jstitch)

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/ | 294 | let remote = remote.as_deref().unwrap_or("devel"); | ^^^^^^^^ | = note: see issue #50264 for more information

error[E0658]: use of unstable library feature 'inner_deref': newly added --> src/ | 341 | let remote = remote.as_deref().unwrap_or("devel"); | ^^^^^^^^ | = note: see issue #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?

akiirui commented on 2021-01-30 20:51 (UTC)

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;


whynothugo commented on 2021-01-27 16:57 (UTC)

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

0100001001000010 commented on 2021-01-27 16:51 (UTC)

@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.

whynothugo commented on 2021-01-27 16:47 (UTC) (edited on 2021-01-27 16:48 (UTC) by whynothugo)

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

Do other completions work for you?

0100001001000010 commented on 2021-01-27 16:24 (UTC)

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.

starquake commented on 2021-01-01 14:24 (UTC)

@nasdack: See this issue:

eh8 commented on 2020-12-21 02:05 (UTC)

   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.

yochananmarqos commented on 2020-11-14 17:51 (UTC)

@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"

tytan652 commented on 2020-11-14 07:03 (UTC)

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

yochananmarqos commented on 2020-10-29 01:05 (UTC) (edited on 2020-10-29 01:05 (UTC) by yochananmarqos)

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


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

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

commented on 2020-10-28 22:25 (UTC)

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

Morganamilo commented on 2020-10-19 11:53 (UTC)

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.

yochananmarqos commented on 2020-10-19 05:06 (UTC)

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: `?`