Package Details: pacaur 4.7.10-1

Git Clone URL: (read-only)
Package Base: pacaur
Description: An AUR helper that minimizes user interaction
Upstream URL:
Keywords: AUR helper wrapper
Licenses: ISC
Submitter: Spyhawk
Maintainer: Spyhawk
Last Packager: Spyhawk
Votes: 1082
Popularity: 37.494540
First Submitted: 2011-05-17 21:16
Last Updated: 2017-07-07 15:22

Required by (16)

Sources (1)

Pinned Comments

Spyhawk commented on 2016-02-17 18:21

[2017-12-15] This project is now unmaintained. Users are encouraged to move to another solution (see wiki for alternatives).

Latest Comments

cl0ne commented on 2018-01-02 18:59

Thanks for great tool, @Spyhawk! Completely agree with @smls precise comment about workflow.

bemeurer commented on 2017-12-31 19:24

@Spyhawk Thanks for having maintained this for all this time, truly an amazing tool. Having used Yaourt and Aura before it I'm a bit sad letting go of pacaur, the only sane project of the bunch. Once again, thank you!

smls commented on 2017-12-30 11:35

Thanks for all the work you put into this over the years, @Spyhawk. It's been a very helpful tool.

When I started using it, it was the only AUR helper that made a serious effort to live up to a "fast/streamlined workflow" design principle.

I still remember the dark ages of Yaourt & friends, which blocked between every package they installed or updated to make me run a gauntlet of questions (with some requiring "Yes" to continue, and some "No"... shudder).

I haven't looked at the state of other AUR helpers in a long time now, though. Hopefully, pacaur has rubbed off on them a bit in the meantime.

And as you say, there's no rush to switch immediately...

badonkadong commented on 2017-12-30 00:51

Dang it, such a nice tool, so sad about it hitting EOL @Spyhawk i guess your motives are rock solid for letting go of this project thank you for such a nice tool and all the work going into it, take care.

Spyhawk commented on 2017-12-25 16:23

@kyak> I haven't made a decision yet. Pacaur will still work as it does currently at least until pacman 5.1 is released, so there is no urgency in switching right now. I'll keep observing what happens in the next few months.

Also, a personal thank you for your work on the Russian translation the past few years.

kyak commented on 2017-12-25 15:59

@Spyhawk, thanks for the great job!

Which AUR helper will you be using yourself from now on? I'm a bit frustrated by the number of AUR helpers and their current state :(

nicman23 commented on 2017-12-21 12:47

it has been a great tool, thanks ! :)

SilverMight commented on 2017-12-19 03:29

Thanks for maintaining, my favorite helper.

JoshuaRLi commented on 2017-12-18 22:34

Thanks for everything, Spyhawk.

ArchNemo commented on 2017-12-17 18:19

Thank you very much for maintaining this awesome package all this time.

francoism90 commented on 2017-12-15 13:24

Ah damn, always like pacaur. :/

Thanks for all the time invested in maintaining the PKG.

Spyhawk commented on 2017-11-03 00:23

The change will be done on the next 4.8 version, which isn't going to be released before a few weeks/months anyway.

haawda commented on 2017-11-02 18:58

What about allowing a co-maintainer do the change?

Spyhawk commented on 2017-11-02 07:12

Can you please read my comment below?

haawda commented on 2017-11-02 07:11

Can you please do what MarcinWieczorek and Alad suggested?

Alad commented on 2017-10-18 07:33

kyak, there's nothing pacaur (or any aur helper) can do about packages that are purely virtual.

kyak commented on 2017-10-18 03:24


Before bringing it to bugtracker, i wanted to quickly check if this is even relevant to pacaur.

When trying to install gplaycli package, I get this error:

:: no results found for python-pyaxmlparser (dependency tree: gplaycli python-pyaxmlparser)

There is python-pyaxmlparser-git package, which provides python-pyaxmlparser. Should it be caught by pacaur, or is this expected behaviour?

Spyhawk commented on 2017-09-30 10:01

Alad> I see, this indeed makes sense. I am however not able to make this change for quite a few weeks, I'll do once I get access to a unix machine again.

Alad commented on 2017-09-29 13:18

Works fine here. Without further detail, we can assume it's something on your end...

Kuchiriel commented on 2017-09-28 21:42

Spyhawk, makepkg -s -i simple doesn't work because of malformed PKGBUILD.

Alad commented on 2017-09-28 20:30

What he means is that right now, the pacaur archive is downloaded as 4.7.10.tar.gz. It's quite possible that a different project has the same pkgver and that the corresponding PKGBUILD also downloads it as 4.7.10.tar.gz.

So, if you have SRCDEST set to some common directory a conflict occurs and things will break. A simple fix is to use:


Spyhawk commented on 2017-09-25 23:43

MarcinWieczorek> No idea what you are talking about.

MarcinWieczorek commented on 2017-09-25 21:40

Please include the name of the package in the name of the tarball for people who use a shared source directory.

e8hffff commented on 2017-07-20 04:57

I found my pacaur wasn't upto date via octopi. Needed to reinstall ca-certificates based packages to fix problem.

chipmunkboogie commented on 2017-07-10 19:33

@Spyhawk thanks. All is good now.

chipmunkboogie commented on 2017-07-10 19:33

@Spyhawk thanks. All is good now.

Spyhawk commented on 2017-07-08 19:26

@chipmunkboogie> As above: check your PATH environment variable.

Spyhawk commented on 2017-07-02 20:40

@bioshacker001> Could? Yes, definitely. But willing to? Hum, no, not really. I have no time to implement and maintain something I don't personally need, though I am 100% in favor of implementing this feature once the planned pacman -B (ABS merge in pacman) is eventually implemented.

ArchangeGabriel commented on 2017-07-02 09:54

@bioshacker001: You should rather ask on GitHub. I think they are already people doing what you do, using pacman hooks.

bioshacker001 commented on 2017-07-02 09:44

Hey, anyone think it would be possible to integrate ABS building into Pacaur? (I build almost my entire system from ABS, rather than the repos, to get the benefits of -march=native, so I'm wondering if I could automate the process.) I know the tool doesn't support it right now, but do you think it COULD? I don't want to learn an entire language (Perl) just to find out that what I want is impossible.

Spyhawk commented on 2017-06-17 10:39

vendforce> Do as the error message says.

vendforce commented on 2017-06-17 08:55

I'm getting the is error when installing applications from the aur

Check .SRCINFO for mismatching data with PKGBUILD.

Is there an issue with pacaur ?

Spyhawk commented on 2017-05-10 20:00

@kyak: no, I don't think so. What happened yesterday/today is a very specific issue that concerns only a minor category of users, and that requires a very specific action to be solved.

kyak commented on 2017-05-10 18:44

@Spyhawk Do you think it makes sense to implement a feature that if pacaur sees itself in the list of package updates, it would update itself first, and then proceed with the rest of packages?

Spyhawk commented on 2017-05-10 17:10

Note: if you have *a lot* of AUR packages installed and that you cannot upgrade with 4.7.7, kindly force installation of version 4.7.8 with "pacaur -S pacaur" before proceeding.

Krejzi commented on 2017-04-24 23:00

Thanks to eschwartz on IRC, I found out I could modify makepkg's internal variables from its conf file.

Adding SKIPPGPCHECK=1 to $HOME/.config/pacman/makepkg.conf (or /etc/makepkg.conf) solves my issues. Sorry for the noise.

Spyhawk commented on 2017-04-24 22:19


Krejzi commented on 2017-04-24 22:16

There is no way to disable the "feature" without using the makepkg switch (and guess who's passing the switches). And no, using "auto download GPG keys" GnuPG (not makepkg) conf directive is not an option, I don't want other people's pgp keys being imported. Would you accept a patch that adds the necessary switch to pacaur ... --aur? (And I just remembered why it worked previously - I had edited makepkg by hand to prevent gpg validation, update must've overriden it).

Spyhawk commented on 2017-04-24 22:11

No, learn to configure makepkg. This isn't broken, but present since makepkg included the feature.

Krejzi commented on 2017-04-24 21:59

Is there a way for pacaur not to try to verify signatures when building from AUR? This wasn't needed before IIRC, something recent broke it.

Spyhawk commented on 2017-04-20 10:05

Gettext is in base-devel, so no.

ariflukito commented on 2017-04-20 01:52

Should gettext be added as dependency? I removed yaourt and it also removed gettext and now pacaur complains about missing gettext.

PhotonX commented on 2017-03-02 08:01

@Spyhawk: Could you please check the latest comments in ? I'm out of ideas what is still wrong with my perl lib packages... Thanks!

francoism90 commented on 2017-02-22 12:57

I simple rebooted (after updating with pacman) to fix the pod2man issue.
Don't like editing 'deps', so please try this one first.

Spyhawk commented on 2017-02-06 10:20

"Fixed" in the current version.

kyak commented on 2017-02-05 15:16

Hmm.. During installation of 4.7.2 it tries to run COMMAND=/usr/bin/touch /run/lock/ via sudo.
What's that? I only allow to run /usr/bin/pacman.

Spyhawk commented on 2017-02-05 08:51

@bulletmark: Thx. I've updated the pinned comment.

bulletmark commented on 2017-02-04 23:25

People with that pod2man path error are probably running GNOME with Wayland like me. For a generic system wide fix, see my comment here

Spyhawk commented on 2017-02-04 19:59

@ainola> Thx, will fix in next update.

ainola commented on 2017-02-04 15:55

Thanks for maintaining this, Spyhawk.

$pkgdir and $srcdir should be double quoted to prevent globbing and word splitting.

logancat24 commented on 2017-02-04 01:16

@bulletmark Thanks, I was having that issue. Adding that path fixed the problem for me.

bulletmark commented on 2017-02-03 22:33

OP, it would perhaps be best to avoid that pod2man error for everybody by specifying the path /usr/bin/core_perl/pod2man in the PKGBUILD. That works, is an easy change, and avoids users having to ensure they have particular environment.

olddog commented on 2017-02-03 18:50

Execute in your shell /etc/profile.d/ @Airon90, then makepkg -s the pacaur PKGBUILD.

Remember in your terminal-of-choice, to ensure you its using a 'login shell'.

Airon90 commented on 2017-02-03 16:12

pod2man is needed to install pacaur. Where can I find this program? I can't find it

Spyhawk commented on 2017-02-03 14:10

After a few months and more than a hundred of commits, pacaur 4.7.0 has been released today.

Major changes include:
* support for AURDEST directory cleaning with -Sca
* use of topological sorting for a faster dependency solver
* replacement of -Qur and -Qua by -Qun and -Qum for consistency
* more useful error message in case of dependency tree errors
* lot of minor bug fixes

See the complete changelog for a detailed overview.

Spyhawk commented on 2016-12-28 16:47

@fpqc> No, but you might be able to simply hack it by adding "devel=true" in the config file.

fpqc commented on 2016-12-28 14:01

Heya, spyhawk, is there any way to, or plan for, a setting in the configuration to always run with --devel (three options: true, needed, false, default false)?

This would be convenient, don't know if it would be annoying to implement.

Spyhawk commented on 2016-03-26 20:10

@Utini > I have no idea what you are referring to.

Utini commented on 2016-03-26 19:39

The source has changed to smth else than ""... is this legit?

brittyazel commented on 2016-03-26 18:47

I think I figured out what is up with pod2man, and it has to do with setting your terminal to be a "Login shell" vs a non-login shell. By default, terminals do not source to files in /etc/profiles.d, and thus perl is not added to the bash path. However, if you toggle on the setting "login shell" whenever the shell opens it sources these shell scripts and perl is added as it should be to the path.

Now, I don't know of any downsides to using your terminal as a "login shell" vs the default, but I have yet to have any major issues.

jurf commented on 2016-03-25 20:23

pod2man not found, is it a new makedep? EDIT: my bad, it's in perl, it was a problem on my end.

hiddenhand commented on 2016-03-23 15:33

@Spyhawk It's fixed now, I changed my DNS config by following the wiki. Thanks for your time!

Spyhawk commented on 2016-03-23 15:16

@hiddenhand> Looks like a DNS issue to me. Check if cower behaves correctly (cower -u, cower -s 'string'). If it does, then please open a new issue in the tracker with a complete debug output.

hiddenhand commented on 2016-03-23 14:59

@Spyhawk --my output on pacman -Syu. I'll also look into the man page thanks

Spyhawk commented on 2016-03-23 14:47

@hiddenhand> Any error message? Also see the "Notes" section of the man page. This might be related to a DNS server misconfiguration. If this doesn't apply, please open a bug report on the GH tracker or in the forum thread. See links in the pinned comment above.

hiddenhand commented on 2016-03-23 14:14

I'm new to this so excuse me for this question, pacaur is having trouble connecting to the AUR when I'm trying to -Syu upgrade and when trying to search for a package. I've tried installing through yaourt and manually, but the problem still exists, is there any fix to this? Thanks!

jonlandrum commented on 2016-03-16 19:21

@spyhawk thank you, that update is newer than the last time I checked the comments section on the package.

Spyhawk commented on 2016-03-16 17:31

@jonlandrum> Please read the comments section of the intellij-idea-ce-eap package. The issue occurs because the maintainer changed the versioning system (epoch removal).

jonlandrum commented on 2016-03-16 16:03

For some reason pacaur isn't pulling updates from AUR on my system. It runs the pacman update fine, but when it gets to the AUR upgrade, it always says there is nothing to do. However, the package intellij-idea-ce-eap ( is currently at version 2016. in the AUR, but on my system it's at 2016.

I have tried pacaur -Syu, pacaur -Syyu, pacaur -Sua, and even pacaur -Sykua. I'm not seeing anything in the "NOTES" section of the man page specific to this issue. Any ideas what I may be doing wrong?

brittyazel commented on 2016-02-26 21:32

So some erroneous AUR package can mess with my perl path? Weird...

Spyhawk commented on 2016-02-26 18:02

@brittyazel> You borked your perl path in some way, and it's your job to find out which package you recently installed causes your issue. You're on your own here, good luck.

brittyazel commented on 2016-02-26 17:31

I keep getting the pod2man issue, and yes, I know "PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl" works just fine to fix the problem, but why is this the only package that encounters this issue. Better yet, why does core_perl keep getting dropped from my PATH? shouldn't /usr/bin contain /usr/bin/core_perl?

Spyhawk commented on 2016-02-19 15:38

@jsivak> Thanks for the report. See my comment on hadoop AUR page. Edit: Now fixed in pacaur-git.

jsivak commented on 2016-02-19 13:22

Edit: Just re-read the Changelog.. I think pacaur 4.5.3 fixes/addresses this issue


This may be related to DeMastah's comment: The maintainer of the Hadoop AUR package had this to say about the "Check .SRCINFO for mismatching data with PKGBUILD." message pacaur was displaying when trying to process the hadoop package:

".. pacaur can't handle packages made with PKGEXT."

Here's the comments:

DaMastah commented on 2016-02-19 11:53

Spyhawk> Damn, sorry for my comment then. And thanks for the great work !

Spyhawk commented on 2016-02-19 08:23

DaMastah> Maintainers borked their PKGBUILD update.

DaMastah commented on 2016-02-19 07:00

I get some errors when building some AUR packages since last update/
Example :
:: Installing rinetd package(s)...
:: rinetd package(s) failed to install. Check .SRCINFO for mismatching data with PKGBUILD.

Example packages : wakeonlan, rinetd

Spyhawk commented on 2016-02-17 18:21

[2017-12-15] This project is now unmaintained. Users are encouraged to move to another solution (see wiki for alternatives).

Spyhawk commented on 2016-02-17 18:05

@Mocha_Bean> Read the man page please, especially the notes section.

Mocha_Bean commented on 2016-02-17 04:55

When I -Syu, I get:

:: Starting AUR upgrade...
:: resolving dependencies...
comm: file 2 is not in sorted order
:: no results found for [android-file-transfer]:
:: no results found for [android-sdk]:
:: no results found for [android-sdk-platform-tools]:
:: no results found for [breeze-obsidian-cursor-theme]:
:: no results found for [chromium-pepper-flash]:
:: no results found for [compton-git]:
:: no results found for [cower]:
:: no results found for [depot-tools-git]:
:: no results found for [wimlib]:
:: no results found for [winetricks-git]:
:: no results found for [xavs]:

I've tried pacaur-git and cower-git too; neither fixed the problem.

Spyhawk commented on 2016-02-04 09:40

@vendforce> No. Soname bumps are the user's responsibility (see

If you don't want to be responsible for your own system, then stop using the AUR or stay far away from this helper.

vendforce commented on 2016-02-04 09:16

So if its a cower problem can you please relay this to the cower maintainer for fixing, as pacaur uses cower . Thanks

Spyhawk commented on 2016-02-04 08:54

Yes, a coffin would be great, but it's not mandatory.

Edit: Because it wouldn't solve the issue at all.

vendforce commented on 2016-02-04 08:53

Get back in your box spyhawk

Why dont you add the dependencies

Spyhawk commented on 2016-02-04 08:51

God, kills me now. Shall my death reminds people to read before posting.

vendforce commented on 2016-02-04 08:44

No results found for error

To fix this do the following

sudo pacman -Sq --noconfirm --noedit pyalpm pcurses
sudo pacman -Sq --noconfirm --noedit cower

daniele.belfiore commented on 2016-02-02 13:35

If you have this error:
:: no results found for error

Re-compile cower with the new version of libalpm:
pacaur -S cower

Spyhawk commented on 2016-02-01 09:50

That was faster than I expected. You known the drill, people. When a new major pacman version is released, cower needs to be manually recompiled against the new libalpm.

If you don't know how to do that, stay away from this helper!

Utini commented on 2016-02-01 08:53

pacman 5.0 is now in stable and breaks pacaur. "pacaur -Syu" gives me:

:: Starting AUR upgrade...
:: resolving dependencies...
:: no results found for error

brittyazel commented on 2016-02-01 06:39

Pacman 5.0 just hit stable

Spyhawk commented on 2016-01-31 19:26

@archdaemon> Interesting. By any mean, do you know why that empty directory was created there in the first place? Pacaur wouldn't do that by itself... I guess?
@brittyazel> Please report the issue on GitHub if the error happens again, with debug output attached. On my side, the wsp-office package was correctly created and installed (minus that file conflict issue, which was gone once I removed the conflicting package).

dhscholb commented on 2016-01-31 18:21

@Spyhawk, this is a pacaur issue. I had the same issue but with the desura package. The problem was that I had an empty desura directory in my build directory, but pacaur assumes that if the directory is present that it contains the git repository already, hence the failed git command.

Pacaur should at least error check the git command and print a helpful error message to help users solve the issue.

brittyazel commented on 2016-01-31 18:14

@Spyhawk, no I did not get an error message, and no I do not have that game installed. It goes through the build and says "installing" and gives no error, it just never actually gets installed. However, if I build it manually and install it with pacman -U, it installs fine.

brittyazel commented on 2016-01-31 18:13 I had the same issue, but a reboot solved it. I have no idea what that was about

Spyhawk commented on 2016-01-31 13:51> Not a pacaur issue. This is somehow related to git, as you might have guessed. commented on 2016-01-31 12:57

The `pacaur 4.4.6-1` package is broken, at least on my machine:

$ pacaur -Syu
AUR Packages (1): pacaur-4.4.6-1

:: Proceed with installation? [Y/n]

:: Retrieving package(s)...
fatal: Not a git repository (or any parent up to mount point /tmp)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
:: View pacaur PKGBUILD? [Y/n] y
:: Could not open pacaur PKGBUILD

Spyhawk commented on 2016-01-31 11:45

Please note that users installing pacman 5.0.0 from [testing] also require expac 5 (also in testing) to be installed. Cower also requires to be recompiled against the new libalpm.

Also, from now on, full compatibility with pacman 5.0.0 is being tested out with the pacaur-git package. Users that have installed pacman 5.0.0 are encouraged to switch to the pacaur-git package until the new pacman reaches [core].

If you are using pacman 4.2.1 from the stable [core] repository, simply keep using this stable package and *do not* install the pacaur-git package.

Spyhawk commented on 2016-01-30 17:38

@brittzayel> Do you have an error message? I actually can't install it because wps-office has a conflicting file with enemy-territory. By any chance, do you have that game also installed?

brittyazel commented on 2016-01-30 04:30

Hey guys, I'm having an issue with WPS-Office, I can manually build and install it, but when I try with Pacaur it looks like it built and installed correctly, but it never actually installs. Can someone else try it and let me know what is going on?

kyak commented on 2015-11-13 17:03

@Spyhawk, can you please have a look at last comments in ? Could it be a pacaur bug?

Sorry for the noise. There seemed to be an issue with bbswitch-ck.

Spyhawk commented on 2015-11-08 11:44

Now supports git clone. As some config options are now deprecated, please read the man page and do not forget to merge your config file.

Spyhawk commented on 2015-10-28 13:08

Voice> The issue with the tomb package should be fixed in master branch (pacaur-git). I'm going away of using the --pkg flag, since it will be removed in pacman 5.0.

Spyhawk commented on 2015-09-24 08:22

Voice> As explained in tomb comments, this is a makepkg issue due to arch value overriding in a subpackage (try "makepkg --sfi --pkg tomb").

Apparently, there are a bunch of known issues with --pkg, and pacman developers are going to remove it in the next major pacman release for this very reason.

Voice commented on 2015-09-24 02:01

I'm afraid it's a pacaur bug. One may download either aur/tomb, or aur/tomb-git, and run plain "makepkg" which successfully builds both "tomb" and "tomb-kdf" subpackages. Thus both PKGBUILDs are valid and makepkg works, but pacaur does not. For now I'll install by hand. Hope this test helps and thanks for all your hard work, much appreciated.

Spyhawk commented on 2015-09-23 09:35

Voice> I bet nobody has ever reported the bug... no way it will be magically fixed, he. Install the package manually, there is nothing I can do here.

Voice commented on 2015-09-23 01:04

Yes, I did before posting here, of course. I hoped for advice. I understand from richli his PKGBUILD is good but makepkg has a bug. Apparently it's at least 9 months old, so waiting for a fix does not seem fruitful. What you recommend to do in this situation to get tomb installed.

Spyhawk commented on 2015-09-22 10:18

@Voice> See answer given by richli the very same day.

Spyhawk commented on 2015-09-22 10:18

@Voice> See answer given by richi the very same day.

Voice commented on 2015-09-22 09:33

Thank you for the big update. Does not work on aur/tomb with error as reported by jswagner on 2014-12-31. Using: pacman 4.2.1-2 cower 14-2 pacaur 4.3.1-1

Spyhawk commented on 2015-09-14 09:30

You're damn welcome. And I probably should add an entry in the wiki page for that one..

cgenogo commented on 2015-09-14 09:12

@Spyhawk thanks for explaining me my issue.

Spyhawk commented on 2015-09-14 08:59

Fix your damn perl path.

cgenogo commented on 2015-09-14 07:00

pacaur has a dependency 'pod2man' that not listed. Cannot build the package with makepkg .

Spyhawk commented on 2015-09-01 17:41

Please don't flag this package yet. The stable version of pacaur will be updated once I'm sure the new 4.3.0 doesn't introduce regression. This is quite a big update, with lot of small changes, and it actually requires cower-git which I'm not keen to force on people using the stable version.

slowbro commented on 2015-08-18 21:54

It worked with -si, and still fails with pacaur-git. I put in a new Issue on Github:

Spyhawk commented on 2015-08-17 23:46

slowbro> Try with "makepkg -si" and see if the package succeed. If it fails, the package has to be fixed. If it succeeds, try again with pacaur-git as some recent change might be relevant. Lastly, if the error is still present, please provide a complete debug output on GitHub (or in forum thread). See

slowbro commented on 2015-08-17 22:11

pacaur errored today when trying to install python-botocore:

/usr/bin/makepkg: line 110: GREEN: unbound variable
:: python-botocore cleaning skipped
:: failed to build python-botocore package(s)

..however, installing it with the standard makepkg + pacman -U works fine.

full log:

other info:
[katelyn@sanic ~]$ pacman -Q pacaur
pacaur 4.2.27-1
[katelyn@sanic ~]$ uname -a
Linux sanic 4.1.4-1-ARCH #1 SMP PREEMPT Mon Aug 3 21:30:37 UTC 2015 x86_64 GNU/Linux

slester commented on 2015-08-13 15:11

pacaur "crashed" (froze on a blank screen) when switching to fakeroot when installing neovim-git. Has anyone else seen anything like that?

sdothum commented on 2015-08-10 13:27

Started getting this message today, coincidentally after the weekend migration to aur4:

:: you cannot perform this operation as root

Spyhawk commented on 2015-07-06 12:05

AUR4 can now be used with the pacaur-git package. Ensure to install cower-git, then make use of the new "--domain" command line flag. No config file option, but you can alias it.

Spyhawk commented on 2015-06-18 23:28

This is the same version as AUR3, so AUR3. During the transition period, packages should be maintained in both AUR, as recommended. There is no point in checking AUR4 only, or both AUR during such a short period of time.

ridikulusrat commented on 2015-06-18 17:16

@Spyhawk: Does this pkg (aur4 one) (and/or aur4 pacaur-git) check aur4 or aur for updates?

akurei commented on 2015-05-05 09:16


He was not being rude. You made a very obvious error, Spyhawk told you pacaur is for advanced users. You can shoot yourself in the foot if you don't understand what it does. You obviously don't understand basic error messages, which makes you either a beginner or you overlooked it. Both are a statement without judging you on it.

> " /usr/bin/pacaur: line 654: mvim: command not found

AnbuBlack commented on 2015-04-29 13:38

Well I found the problem, an oh_my_zsh settings.

One general answer: you dont have to be rude with ppl how are trying to learn "the Arch way".

Spyhawk commented on 2015-04-29 13:24

@Minbari> You've configured "mvim" as your EDITOR...

On a more general note: Seriously people, pacaur is for seasoned, advanced Arch users. If you're not able to handle simple issues by yourself, just DO NOT USE this helper.

AnbuBlack commented on 2015-04-29 12:29

When I try to view PKGBUILD of a package it give me same error:
" /usr/bin/pacaur: line 654: mvim: command not found
:: Could not open ttf-font-awesome PKGBUILD. "

If I chose not to view the shell script the instalation works fine. What it's the cause of this trouble? Thanks.

ephaeton commented on 2015-03-25 06:48

Spyhawk> My system isn't broken. I'm not using perl et al (voluntarily). I also use a more restrictive umask than the default 022. Would you consider this broken? Look at makepkg. It explicitly sets the umask back to 022 so that an e.g. 027 of a somewhat paranoid user doesn't prevent building of AUR packages with sane permissions set. It's the sort of operation that build-scripts perform to achieve a level of isolation from the build host. Have a look at *BSD pkgs. They're EXTREME in their setup of a clean environment, and thus achieve building identical packages on different environments. That's a good thing. I'll shut up now though.

Spyhawk commented on 2015-03-24 23:07

ephaeton> I understand your point of view, but as an Arch user, I prefer to know early about my system being broken rather than having some scripts doing some magic and hidding it. I simply don't think this would be a service to the target audience.

Spyhawk commented on 2015-03-24 23:07

Spyhawk> I understand your point of view, but as an Arch user, I prefer to know early about my system being broken rather than having some scripts doing some magic and hidding it. I simply don't think this would be a service to the target audience.

ephaeton commented on 2015-03-24 21:05

Spyhawk> I understand the sentiment. Yes, I broke the build. And I get the Unix philosophy WRT rope, hanging etc. Nonetheless, a clean build environment for building packages is paramount. You rely on arch's perl package as a buildtime dependency. I think it would just be as clean to use the system's hint on where to find pod2man (via to ensure you'll find it, decoupled from the builder's environmental settings. My argument is one for improved robustness of the (build of the) package by decoupling its needs (PATH setup) from the builder's environment.

Spyhawk commented on 2015-03-24 18:26

ephaeton> No. If your system needs to be fixed, then fix it. If someone has a better alternative to generate man pages, let me know.

ephaeton commented on 2015-03-24 18:12

Spyhawk> And there I thought it was mksh's fault. It was mine, all along. Still don't see why I would want these scum executables in my PATH but oh well. Can't the pacaur build script source /etc/profile.d/ itself to make sure PEBKAC won't negatively affect the build?

Spyhawk commented on 2015-03-24 13:15

ephaeton> pod2man can be found without any issue on a standard Arch system.

BertiBoeller commented on 2015-03-24 09:50

@ephaeton: I had messed up my /etc/profile which loads the shell scripts which reside in /etc/profile.d/ and which will set the path to the perl executables.
I was able to solve this by deleting /etc/profile and reinstalling the 'filesystem' package.

ephaeton commented on 2015-03-24 08:31

Spyhawk> "Check your perl path" ? Not "include /usr/bin/core_perl in your PATH"?
I hate this (adding core_perl temporarily to my path w/ env(1) after pacaur failed once again to update itself). Can't the build find pod2man without me having to adjust my environment?

Spyhawk commented on 2015-03-23 04:46

dapolinario> I cannot reproduce. Please report issue on the forum thread or open a new GitHub issue, with a complete debug output (see wiki page).

dapolinario commented on 2015-03-23 02:16

I have a problem when trying to install bbswitch-ck and choose options from 10 when I choose the providers package options.

kyak commented on 2015-03-21 05:09

@Spyhawk, thanks, that's what i'll do :)

Spyhawk commented on 2015-03-20 08:37

kyak> I've a few changes in the pipeline. In the meantime, you can always install pacaur-git to use the latest and greatest Russian translation ever! :)

kyak commented on 2015-03-20 05:10

Hi Spyhawk,
Pardon my impertinence, but can you bump the release to include latest translation? :) That is, of course, if you don't plan to release soon anyway.

Spyhawk commented on 2015-03-19 18:29

BertiBoeller> pod2man is provided by core/perl. Check your perl path.

BertiBoeller commented on 2015-03-19 18:08

does anyone else get this error when trying to upgrade to the newest pacaur version?:
/tmp/pacaurtmp-martin/pacaur/PKGBUILD: line 18: pod2man: command not found.

Spyhawk commented on 2015-02-16 23:07

Sorry guys, I messed up the last md5sum update. Should be fixed now!

gyscos commented on 2015-02-16 22:59

That's a bit odd, since 'ca02cc0085c3018c512cb8deea4478cd' is not the previous version chescksum either.
Maybe github updated their tar/gzip software and the resulting archive is not _exactly_ the same?
In any case, if we trust the github source, the PKGBUILD should be updated with the new md5...

Spyhawk commented on 2015-02-16 22:56

gosella> I had a weird issue as the git tag wasn't correct for some reason. I deleted it and fixed it, before releasing 4.2.19-2.

You might have downloaded the old tarball right before I fixed the tag. Please try again with a new clean directory, or remove it from SRCDEST if you have it defined.

gosella commented on 2015-02-16 22:44

Tried to upgrade to 4.2.19-2 but the integrity check failed.

The PKGBUILD contains md5sums=('ca02cc0085c3018c512cb8deea4478cd') but the downloaded file "4.2.19.tar.gz" reports md5sums=('e593bab9010e342be2da242d8edeeb12').

Is the PKGBUILD wrong?

Spyhawk commented on 2015-01-25 19:53

ArchHK> If you want to help debug that Polish language issue, please refer to GH#302/#267.

ArchHK commented on 2015-01-25 12:42

Why did you remove Polish language? Working here without problems.

DrewFmStateFarm commented on 2015-01-16 00:18

I'm keep getting a "no results found for error" every time I do a pacaur -Syu.
What would cause this?

dmnc commented on 2015-01-05 08:56

@SysGhost> in my case it was broken cower (, probably I did some cleaning after updates and I've cleaned more than is healthy. Rebuilding cower solved problem with `/usr/bin/pacaur: line 667: ... No such file or directory`.

SysGhost commented on 2014-12-29 15:29

@Spyhawk> It all started to work while I was reading the debug output.
I did nothing myself. It just suddenly started to work again... and I did absolutely nothing.
I'm confused.

Perhaps a server error that caused cower and/or pacaur to spit out misleading errors?

For details, see:

Anyway. I works now and I hope it stays that way. :)

SysGhost commented on 2014-12-29 15:28

@Spyhawk> It all started to work while I was reading the debug output.
I did nothing myself. I just suddenly started to work again.
I'm confused.

Perhaps a server error that caused cower and/or pacaur to spit out misleading errors?

For details, see:

Spyhawk commented on 2014-12-29 10:58

@SysGhost> Check that pacman is still working correctly. Also please ensure you really recompiled expac and cower. If the error still occurs, post a debug output in the forum thread or in a new github issue.

SysGhost commented on 2014-12-29 10:54

pacaur doesn't work anymore. I get following errors on these commands:

pacaur -S <any-package>
/usr/bin/pacaur: line 667: cd: /tmp/pacaurtmp-sysghost/<any-package>: No such file or directory
:: Building <any-package> package(s)...
==> ERROR: PKGBUILD does not exist.
:: Could not clean <any-package>

pacaur -Ss <any-package>
failed to initialize alpm: could not create database
error: failed to initialize alpm library

I have updated pacman to version 4.2. I reinstalled alpm and rebuilt cower. I also updated expac.
pacman 4.2 works fine.

I can also run makepkg on whatever package I need just fine.

qmega commented on 2014-12-29 06:34

I had to rebuild expac as well. The rebuilt package of that hasn't been pushed to extra yet.

dhscholb commented on 2014-12-29 04:26

For anyone having this error after the pacman update:

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

just rebuild and reinstall cower manually.

brittyazel commented on 2014-12-29 03:34

With today's pacman update, pacaur no longer works and throws errors.

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

Spyhawk commented on 2014-11-03 22:33

Thanks helq for the suggestion. I did try something similar in the past, but had several issues with msgfmt in a loop. Never understood what was going on, but I'll try again at the next release.

Ideally, I would find some reliable way to read all the .po files in the directory so I wouldn't need to explicitly add them in the PKGBUILD.

helq commented on 2014-11-03 17:35

The language section in the PKGBUILD is getting larger. I suggest a change in the schema for the installation of languages. What you think about:

for lan in {ca,de,es,fr,it,ja,pl,pt,ru,tr}; do
msgfmt ./po/${lan}.po -o $pkgdir/usr/share/locale/${lan}/LC_MESSAGES/

Voice commented on 2014-10-21 20:54

Well, I've installed by hand. FWIW, /tmp had 850MB free of 1.3GB total. Guessing, pacaur hit a weird logic path bypassing mkdir, and/or miscalculated. 1 GB = 1073741824 bytes so it was trying a crazy huge size. Pacaur still hit the mem glitch when I made the missing folder by hand first. Thanks

Spyhawk commented on 2014-10-20 15:47

Voice> Works for me. Please ensure your memory isn't full, as /tmp is by default mounted in ram, or configure pacaur accordingly (see man page). If the issue persists, please report a full debug output (see pacaur wiki page).

Voice commented on 2014-10-18 22:51

Does ttf-lato have a bug? Could not upgrade 2.007-1 to 2.010-1
/usr/bin/pacaur: line 735: cd: /...ttf-lato: No such file or directory
/usr/bin/makepkg: xrealloc: cannot allocate XXXXXXXXXXXXXXXXXXXX bytes (XXXXXXX bytes allocated)
I used makepkg to upgrade by hand.

Spyhawk commented on 2014-10-07 20:49

hakunamenta> Yes. Please read the man page or wiki page for a workaround.

hakunamenta commented on 2014-10-07 19:25

I noticed a improvable behaviour of pacaur:
When there is a dependency switch present in a PKGBUILD like the one for eagle, pacaur ignores the contingency condition for the depends.
Because of this on some $ARCH the dependency resolution might fail in error or even succeed in error.

jsivak commented on 2014-09-26 18:35

I understand... the script I have is just rebuilding/recompiling all of my AUR installed packages (usually due to library updates) and I'd only run it once in a blue moon. Have it "fail" on the first non-installable package is acceptable, since I'd have to resolve the issue manually anyways. (like the case with the 'analog' package no longer being in AUR)

Spyhawk commented on 2014-09-26 14:03

jsivak> I don't think stopping the whole update process because of a single package failure is worth it, instead of skipping it and compiling the next package. I do however understand your issue and better error reporting would be welcome. I'll have a look.

jsivak commented on 2014-09-26 13:40

Is it possible for pacuar to provide an error code or "pass through" an error from curl when a file can't be downloaded?

I'm trying to write a script that updates my AUR packages, and, in this case the "analog" package is no longer in AUR (but still install on my local system), but when I do "pacaur --noconfirm -S analog" the BASH return code is 0, even though I see:

"==> ERROR: Failure while downloading analog-6.0.tar.gz

(I realize that 'analog' is no longer hosted in the AUR, so I'd like pacaur to return a non-zero exit code so that my script will stop and I can be alerted.)


Spyhawk commented on 2014-09-14 08:21

drrossum> No, it is not. Read the prerequisites on the AUR wiki page.

Spyhawk commented on 2014-09-13 08:06

drrossum> No, it doesn't. Read the prerequisites on the AUR wiki page.

drrossum commented on 2014-09-13 04:43

gettext dependency is missing

cmellwig commented on 2014-09-02 22:32

zsh completion doesn't work for aur packages.

Spyhawk commented on 2014-09-01 13:56

bezirg> Please provide a complete debug output (see in the pacaur thread in the forum or in the GH tracker.

I mean, seriously guys.

bezirg commented on 2014-09-01 13:32

Problems with 4.2.10 that cannot resolve any the aur dependencies when installing aur packages. Reverted back to 4.2.9 and works fine.

lucacerone commented on 2014-08-24 20:12

Hi, djmattyg007 I had the same issue and thanks to Spyhawk realized it was a problem with curl searching the TLS certificates in the wrong file.

I fixed the issue creating the directory in which curl searches for the certificates:

sudo mkdir -p /etc/pki/tls/certs/

and then
creating the symlink:
sudo ln -s /etc/ssl/certs/ca-certificates.crt /etc/pki/tls/certs/ca-bundle.crt

Hope this helps.

Spyhawk commented on 2014-08-21 12:07

djmattyg007> Please provide a complete debug output (see in the pacaur thread in the forum or in the GH tracker.

djmattyg007 commented on 2014-08-21 11:10

I get this error whenever I try and run 'pacaur -u' or 'pacaur -Su':

$ pacaur -u
:: Starting AUR upgrade...
:: resolving dependencies...
:: no results found for dependencies)

This issue has been happening occasionally for a while. Since the most recent update it has been happening without fail.

Spyhawk commented on 2014-08-07 21:46

vertoe> Please provide a complete debug output (see in the pacaur thread in the forum or in the GH tracker.

5chdn commented on 2014-08-07 21:31

Whenever I try to update packages or install packages from AUR.

Spyhawk commented on 2014-08-06 21:06

vertoe> Please provide details about this error. When does it appear?

5chdn commented on 2014-08-06 20:56

Hi, for some time now I get the following issue:

/usr/bin/pacaur: line 179: 1407309796: syntax error: invalid arithmetic operator (error token is "")

Any idea what the cause is?

I already tried un- and reinstalling pacaur...

Trethon commented on 2014-06-24 19:15

Hi, after upgrade to the newest version (4.2.3-1) "--asroot" option doesn't work anymore. It looks like it is not passed to makepkg

Spyhawk commented on 2014-06-18 09:27

Before complaining about the new release, please read the following:
Since version 4.2, pacaur solves the dependency tree using the full secured extended RPC AUR interface. Packages which are missing AUR metadata may however not provide correct dependencies information and a warning will be displayed.

All packages uploaded to the AUR before 2014-05-27 18:35 UTC (AUR 3.0.0 release) are concerned and should be reuploaded by their respective maintainers. If you encounter such packages, please notify their maintainer about their missing AUR metadata status.

It is however possible to temporarily enable the old parsing dependency solver for such packages with the --insecure option, while the additional --preview option allows to preview PKGBUILDs before sourcing for dependency information.

Both of these options are temporary only and will be removed in the near future.

Spyhawk commented on 2014-06-14 06:24

hobarrera> libindicator-gtk3 is a splitted package, which isn't supported by the stable version of pacaur yet. Please use pacaur-git in the meantime.

WhyNotHugo commented on 2014-06-13 21:37

$ pacaur -S --asdeps libindicator-gtk3
:: Package(s) libindicator-gtk3 not found in repositories, trying AUR...
:: resolving dependencies...
:: Could not read libindicator-gtk3 PKGBUILD: badly packaged tarball

Funny, as manually downloading+installing the package works flawlessly.

Spyhawk commented on 2014-06-07 20:43

kyak> Yes. This is fixed in pacaur 4.2, but I guess I'll backport the fix to the stable 4.1.x if it is possible.

kyak commented on 2014-06-07 19:06

[user@laptop ~]$ LANG=C pacaur -S dvd+rw-tools
:: Package(s) dvd+rw-tools not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for dvd+rw-tools
[user@laptop ~]$ LANG=C sudo pacman -S dvd+rw-tools
resolving dependencies...
looking for inter-conflicts...

Packages (1): dvd+rw-tools-7.1-4

Total Download Size: 0.08 MiB
Total Installed Size: 0.31 MiB

:: Proceed with installation? [Y/n]

Is it a bug?

kyak commented on 2014-05-17 15:22

Thanks, Spyhawk!

Spyhawk commented on 2014-05-17 14:29

Thanks kyak, someone reported a similar issue on the tracker (see GH#230). Should now be fixed in pacaur-git.

kyak commented on 2014-05-17 13:05

Hey Spyhawk, here's what i get:

$ LANG=C pacaur -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
repo-ck is up to date
:: Starting full system upgrade...
there is nothing to do
:: Starting AUR upgrade...
:: virtuoso-base is not present in AUR -- skipping
:: resolving dependencies...
comm: file 2 is not in sorted order
:: looking for inter-conflicts...

AUR Packages (2): energia-0012-5 nepomuk-core-4.13.1-1
Repo Packages (2): automoc4-0.9.88-4 doxygen-1.8.7-1

Repo Download Size: 2.58 MiB
Repo Installed Size: 10.30 MiB

:: Proceed with installation? [Y/n] n

Spyhawk commented on 2014-05-16 17:45

hobarrera> You just happened to have found a very, very old bug (introduced in... October 2011). It is unrelated to the "new orphan" code, which only made that bug more visible. So thx to you, it's now fixed in the master branch (pacaur-git) and I'll release a new stable version soon.

I'm however not sure if I should be happy to have that bug solved, or ashamed that it stayed in the code for more than 2 and a half years...

Spyhawk commented on 2014-05-16 12:50

hobarrera> You just found a bug :)

WhyNotHugo commented on 2014-05-16 11:44

pacaur did something funny:

$ pacaur -Suwy
[... lots of output ...]
==> Finished making: pacaur 4.1.29-1 (Fri May 16 08:42:03 ART 2014)
:: pacaur cleaned
:: pacaur is a new orphan package

Why is it a new orphan? It was explicitly installed, and all I did was tell pacaur to download-but-don't-install new packages.

Spyhawk commented on 2014-05-05 07:14

dustball> pacaur takes into account the pacman and makepkg environment variables, so you might want to have a look at $PACMAN. Enjoy.

dustball commented on 2014-05-04 20:42

Feature request:
Could you please implement a setting to change the backend from pacman to something else? In my case, I'd like to use srcpac. As it stands now, I'd have to run an update via srcpac and then via pacaur.

Or maybe even merge srcpac and pacaur?

Thanks for this great tool :)

Spyhawk commented on 2014-04-22 17:56

Not related to pacaur. Check the forums for similar issues and solutions.

pvinis commented on 2014-04-22 17:46

when i try to install this, i get a Warning: Transient problem: HTTP error.
every other package i installed, worked fine.

avelino commented on 2014-04-19 03:56

Install tibia on thinkpad t430 requirement:
* lib32-glu
* lib32-libxcursor

This is just for me or for any 64x?

If all 64x add on dependencies package!

Spyhawk commented on 2014-03-21 09:27

gettext is in base-devel.

drrossum commented on 2014-03-21 05:09

gettext is missing in makedepends

Spyhawk commented on 2014-03-16 13:32

DaBungalow> I am aware of this "issue", but I don't believe this should be handled by pacaur itself. By design, pacaur doesn't offer cheap workaround for such cases, and should instead encourage people to fix the issue upstream. In any case, cower is here to help apply any temporary workaround manually.

thefirstofthe300 commented on 2014-03-15 22:50

Would it be possible to have pacaur download the pkgbuild and offer to have the user edit the PKGBUILD before it does the search for dependencies? Currently, if one of the dependencies is out of date because of a slightly old PKGBUILD, the install fails without even offering to have the user tweak the PKGBUILD to get it to work.

Spyhawk commented on 2014-02-03 11:04

VDP76> No, this isn't featured in pacaur. I don't think the removal of such packages should be automated, since some might be useful (even though you want them to stay in the -Qdt list). This said, adding a warning about -Qdt package after an installation might be useful. I'll think about it.

VDP76 commented on 2014-02-03 08:48

Hi Spyhawk,
thanks for this great package!
Does the script includes an option that, after installing a given package from the AUR, removes any makedepends packages that night have been installed in the process?
If there is, I have missed it; if there is not, is there any chance you would implement it!?

mouni commented on 2014-02-02 12:48

Thank you. Great tool!

Spyhawk commented on 2014-01-15 08:57

Thx K900, this is now fixed.

K900 commented on 2014-01-15 07:42

The zsh completion file should be 644, not 755. Otherwise zsh doesn't pick it up automatically.

sl1pkn07 commented on 2014-01-05 05:48

lexical error: invalid char in json text.
<html> <head><title>414 Reque
(right here) ------^

i have this error, now listed all packages installed from aur like orphan packages


Spyhawk commented on 2013-12-17 20:30

HenryJia> Please post an output on GitHub or the forum thread, since dependencies are currently installed in reverse order, of course.

HenryJia commented on 2013-12-17 20:27

Found a bug:

when pacaur is run to install a package which depends on other packages, pacaur will try and install the package specified first and before its dependencies which can often result in errors. I think it should be changed so that it installs the dependencies first and then the package itsself

kyak commented on 2013-08-24 07:16

Spyhawk, i see, thanks for the answer!

Spyhawk commented on 2013-08-23 21:13

kyak> That's on the to-do list and also the most wanted feature from my side, but this feature is not trivial to implement (see issue #173 on GH).

The package gnome-shell exists in [extra], but the solver fails because the required version is not available in the main repositories yet.

Spyhawk commented on 2013-08-23 21:01

kyak> That's on the to-do list, but this feature is not trivial to implement (see issue #173 on GH).

The package gnome-shell exists in [extra], but the solver fails because of heavy (and most probably unnecessary) bashism.

kyak commented on 2013-08-23 17:42

can the message be made more clear?
There is no difference if didn't find deps and if didn't find the requested package.

$ LANG=C pacaur -S non-existant-package
:: Package(s) non-existant-package not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for non-existant-package

cgirard commented on 2013-08-23 17:08

@kyak: it looks for dependencies first

kyak commented on 2013-08-23 17:00

$ LANG=C pacaur -S gnome-shell-extensions-git
:: Package(s) gnome-shell-extensions-git not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for gnome-shell

Why is pacaur searching for gnome-shell instead of gnome-shell-extensions-git?

Spyhawk commented on 2013-07-28 15:58

lockheed> Please refer to the other "pod2man" issues in this comments thread.

lockheed commented on 2013-07-28 14:12

I just can't get this to install.

I get "/bin/sh: pod2man: command not found" even after I modified the PATH go PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl"
in /etc/profile

Spyhawk commented on 2013-07-24 21:01

dflt> 1/ Why are you using --asroot in the first place?
2/ See

dflt commented on 2013-07-24 20:41

# pacaur -S smplayer-svn --asroot --noedit
:: Package(s) smplayer-svn not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...
:: smplayer-svn and smplayer are in conflict. Remove smplayer? [y/N] y

AUR Packages (1):

Name Old Version New Version

aur/smplayer-svn 0.8.5-1 latest

:: Proceed with installation? [Y/n]

:: Building smplayer-svn package...
==> ERROR: Running makepkg as root is a BAD idea and can cause permanent,
catastrophic damage to your system. If you wish to run as root, please
use the --asroot option.
==> Making package: smplayer-svn 5377-1 (Wed Jul 24 22:37:28 CEST 2013)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing src/ tree
==> Starting build()...
/tmp/pacaurtmp-xxxx/smplayer-svn/PKGBUILD: line 31: cd: /tmp/pacaurtmp-xxxx/smplayer-svn/src/smplayer: No such file or directory
==> ERROR: A failure occurred in build().
:: smplayer-svn cleaned
[root@yyyyy xxxx]# ls /tmp/pacaurtmp-xxxx/
ignoretmp raw.json

but I can manually download the tarball and build pkg with makepkg.

DaveCode commented on 2013-06-23 00:35

Spyhawk yeah I need to read your bug tracker and thanks for putting one up. Pacman was the last manager on earth to implement signed packages despite clamor for the feature. Security has never been a big focus. Systemd at least has PrivateTmp. Thanks for the conversation.

Spyhawk commented on 2013-06-14 09:38

smls> That was, in fact, the default behavior of the earliest release of pacaur. At that time, you can use the "-e" switch to achieve this (pacaur -Se package), but I'll seriously consider adding an 'always' option in the near future.

Edit: Have a look at GH issue #22.

Spyhawk commented on 2013-06-14 09:27

smls> That was, in fact, the default behavior of the earliest release of pacaur. At that time, you can use the "-e" switch to achieve this (pacaur -Se package), but I'll seriously consider adding an 'always' option in the near future.

smls commented on 2013-06-14 09:12

I have a feature idea: Add an option to automatically open the editor on any PKGBUILD without asking.

Reasoning: When I *don't* want to look at a PKGBUILD, pressing my editor's "quit" keyboard shortcut would not be much different from answering "n" to pacaur's question. But when I *do* want to look at it (which is most of the time), it would save me one keypress.

I think this would fit in nicely with pacaur's "fast workflow" philosophy...
It could be integrated with the existing 'editpkgbuild' option, by also allowing a value of 'always' instead of 'true' or 'false'.

Spyhawk commented on 2013-06-14 08:48

DaveCode> It's not about number of line of code, it's just that is useless code.
The 'bug' you're talking about has been reported very recently (have a look at GH, issue #178). You should also seriously consider learning a bit more about the basis of makepkg security.

DaveCode commented on 2013-06-14 03:23

Well if ~5 lines of easy answer is bloatware, I'll spare pacaur more ideas, just as I have pacman. Think I'll fork a custom pacaur git branch, easy enough.

Anyway here's a pacaur 4.1.10 bug report,

Maybe a package name regex issue. Just after, I installed 'woof' using --asroot, and it worked fine. Thanks!

Spyhawk commented on 2013-06-08 17:16

gfrito> That would indeed be a very useful feature. This has also been requested before, but I haven't looked into it yet. This is tracked on GitHub, issue #134.

Anonymous comment on 2013-06-08 15:29

Is it possible to add an option to clean the build directory only on a successful build/install? The cleaning is really nice to save space/memory in /tmp, but can be irritating if there is one small thing that is noticed later and requires the re-downloading of all source files.

Spyhawk commented on 2013-06-07 23:11

"For me the idea is not defeating hackers, but dumb users and my own stupidity."

Pacaur is explicitly targeted at advanced users. I'm not going to implement some bloated code that serves no useful purpose.

DaveCode commented on 2013-06-07 23:00

Universal solution for pacaur noexec issue:
GREPNOEXEC=`grep -e "^tmpfs /tmp.*noexec" /proc/mounts`
if [ -n "$GREPNOEXEC" ]; then
PRERUN="mount -o remount,exec /tmp"
POSTRUN="mount -o remount /tmp"
The "true" no-op allows set-and-forget. Both vars will Just Work as direct calls no matter what the case.

Arch Wiki lists /tmp noexec as a maybe.

For me the idea is not defeating hackers, but dumb users and my own stupidity. An average Joe will randomly move and double-click files. Noexec also blocks common autoscript attacks. The little sh-run workaround trick is blocked in shell profiles with script location logic.

Please read

Serious hackers who know Linux inside out and want to get you pose a bigger threat. Lesser measures defeat common (automated) attacks. Security is risk management. The universal solution for pacaur is utterly simple.

Spyhawk commented on 2013-05-31 18:31

davef> /etc/profile.d/ should be automatically sourced at login.

davef commented on 2013-05-31 18:04

Perl installer didn't seem to do that.

Guess I'll fix it manually on my machine. Or maybe I'll try to figure out how to contribute changes to core packages.

Spyhawk commented on 2013-05-31 15:49

davef> Works here, with Perl 5.18. Check your binary path with "echo $PATH". Perl should add /usr/bin/core_perl to the binary path.

davef commented on 2013-05-31 15:39

So not sure that this is your issue, but when I build this I get:

/tmp/yaourt-tmp-dfriberg/aur-pacaur/./PKGBUILD: line 18: pod2man: command not found

I do have perl installed, but seems the perl 5.18.0-1 doesn't create symbolic links for pod2man. Maybe you are using a different perl package?

Spyhawk commented on 2013-05-15 12:38

DaveCode> Tracking this issue on GitHub ( Please have a look, because with the little research I've done so far I'm not convinced that running a noexec filesystem solves any security issue.

Spyhawk commented on 2013-05-14 11:43

DaveCode> The more I think about it, the more I believe that checking on an PKGBUILD basis is overkill. The user is entirely responsible for its system, so if the user explicitly change the exec permission it is he that should deal with it. A simple exec check on the build dir with a warning before the install would be sufficient. And even in that case, I'm not sure that it is pacaur's job to warn the user about his personal settings.

Another reason I'd be against any PKGBUILD 'scanning' is that I'd like to completely move to the JSON interface for better efficiency and security in the near future. This is currently not possible without losing accuracy in the dependency solver (the AUR has many difficulties to correctly parse the PKGBUILD), but this will likely be fixed with the pacman/makepkg 4.2 release.

DaveCode commented on 2013-05-14 08:45

> Do you have an example of such PKGBUILD?

The monster wine-mono is too big for testing (except stress-testing).

You can perform 'find' on files with +x perms and .sh suffix (say). I vaguely recall Auto*.sh cases.

Won't any source tarball with any files having +x perms need /tmp mounted exec? I would think so. The 'find' command will easily provide a list of them.


Spyhawk commented on 2013-05-05 11:52

Rasi> Weird. A debug output might help (bash -x pacaur -Syu, or whatever command you used).

Rasi commented on 2013-05-05 09:51

Not working for me anymore.

:: resolving dependencies...

and then nothing...

Spyhawk commented on 2013-05-02 05:00

DaveCode> Do you have an example of such PKGBUILD? Pacaur error handling might be improved here.

But I don't think it is possible to know in advance if a PKGBUILD needs exec easily ('exec' is easy to detect, but './' has tons of false positive). Anyway, you should always have a look at the PKGBUILD before compiling, so you'll know if it needs it :)

DaveCode commented on 2013-05-01 23:40

I love pacaur. Thank you for it.

For security I disable exec permissions on /tmp. Some AUR packages need it. Once in a while pacaur snags on that permission issue.

It's easy to fix with /tmp remount if you can remember the problem. That's always my snag - remembering! Many times now, I've stared at a screen wondering why pacaur stopped. I would like pacaur to emit messages on the subject and/or check in advance if it can know a package needs exec (if possible). Thanks!

Spyhawk commented on 2013-04-06 08:41

hexid> Thanks for notifying me.
There is also a last minute bug when the color support is disabled in pacman.conf (it is half enabled in pacaur), this will be fixed soon.

hexid commented on 2013-04-06 00:59

pacman-color can be removed from being an optional dependency.
Instead, you must uncomment `Color` from /etc/pacman.conf

Spyhawk commented on 2013-04-05 09:34

gyurman> Should be fixed now. Ensure that you have the newest expac dependency. It has now reached [community].

Spyhawk commented on 2013-04-05 09:26

gyurman> Should be fixed now. The new dependency of expac has now reached [core].

gyurman commented on 2013-04-05 08:20

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

Spyhawk commented on 2013-04-02 08:09

For those that want to use pacaur with pacman 4.1 from [testing], please install pacaur-git. You'll need cower-git and the newest expac available in [community-testing].
Major change is that pacman-color is now unneeded, as color support has been implemented in pacman.

Spyhawk commented on 2013-04-01 12:38

For those that want to use pacaur with pacman 4.1 from [testing], please install pacaur-git. You'll need the last version of expac-git (the newest version of expac might also land in [testing] soon too).

Major change is that pacman-color is now unneeded, as color support has been implemented in pacman.

Spyhawk commented on 2013-03-18 13:47

BertiBoeller> Not sure what the problem is. The original URL works fine here.

BertiBoeller commented on 2013-03-18 12:40

I had to change the source link from:
so that I could build the package (4.0.3-1).

Spyhawk commented on 2013-03-08 15:27

Pacaur v4.0.0 is now live. Enable the detailed interface with the VerbosePkgLists option in pacman.conf. As always, regression/bug reports are warmly welcome :]

Spyhawk commented on 2013-02-25 14:56

The next release (v4.0.0) will provide multilingual support. For those interested in providing translation, see

Spyhawk commented on 2012-11-16 15:49

dflt> Seems this is a vercmp issue. Please send a bug report to the pacman developers.
cgirard> Thx :)

cgirard commented on 2012-11-16 00:24

[$]>vercmp "0.86u1-1" "0.9-1"

dflt commented on 2012-11-15 20:18

I think that I found a bug:

[root@localhost u]# pacaur -Ss freerapid
aur/freerapid 0.9-1 (125) [installed]
A Java-based download manager for Rapidshare and other file sharing archives
[root@localhost u]# pacaur -S freerapid
:: Package(s) freerapid not found in repositories, trying AUR...
:: freerapid-0.86u1-1 is up to date -- reinstalling

AUR Targets (1): freerapid

Proceed with installation? [Y/n]

Spyhawk commented on 2012-10-28 13:41

exterm> As I told you, not sure if that is easily doable without adding lot of complexity to the code. -Qu is for "checking for update", and -Su for "doing the upgrade" after all.
But you can still show me your wrapper later, and I'll see if some code is worth implementing in pacaur :)

exterm commented on 2012-10-28 13:33

Spyhawk> It's your decision of course, but how about an additional parameter that displays the output of -Qu instead of standard pacman output when doing -Syu. Everything after and including the prompt ("do you want to update Y/n") could be left as it is now.

Maybe I'll just write a wrapper script that does this.

Spyhawk commented on 2012-10-28 13:26

exterm> I am not sure if this is easily doable, as pacaur is relaying entirely on pacman/pacman-color and only extend for AUR features, unlike more complex AUR helper like yaourt.
Unnecessary complexity is something I'm trying to stay away from. My typical workflow is to always check version with pacaur -Qu (that is what it is made for), then doing the upgrade with -Syu or delaying it, depending if you have time right now.
I don't think tracking minor/major version upgrades is very relevant, as many major upgrade don't need more effort than minor upgrade. I believe this is more a bloated feature than a clean and neat addition.

exterm commented on 2012-10-28 13:15

Spyhawk> OK, that's what I was looking for, but I'd like this displayed when doing pacaur -Syu.
That way I can see what is a major version upgrade and what is minor and that way estimate how much work I need to put into upgrading (especially important with databases like postgres).

Is there a way to combine this, so I can just do pacaur -Syu and see old and new versions side by side?

exterm commented on 2012-10-28 13:14

Spyhawk> OK, that's what I was looking for, but I'd like this displayed when doing pacaur -Syu.
That way I can see what is a major version upgrade and what is minor and that way estimate how much work I need to put into upgrading (especially important with databases like postgres).

Is there a way to combine this, so I can just do pacaur -Syu and see old and new versions side by side?

exterm commented on 2012-10-28 13:10

Also it would be very nice if you could display local packages that are newer than their AUR entry (by version number). Those are usually the *-git or *-hg, *-svn packages that need to be updated manually to stay up to date.

Yaourt displays those packages and it is a nice reminder to update them regurarly.

Spyhawk commented on 2012-10-28 13:04

exterm> I'm not sure what you are talking about here. Have you looked at "pacaur -Qu" output? Does this meet your needs?

exterm commented on 2012-10-28 13:03

I have a feature request.

Please "display current *and* available version" not only for AUR packages, but for repo packages too. Yaourt does this in some way.

Thanks for your work on this though, looks very promising!

Spyhawk commented on 2012-08-20 11:23

Archetyp> I see what you're on here. I need to check if the clean and cleandevel options are set to cover this user case. Thx for reporting, as always.

Archetyp commented on 2012-08-20 08:36

Spyhawk, thanks for fix, now it does not wipe out my whole builddir directory... But still, it's maybe a question of what is an expected behavior. I personally assume, that if I don't want to continue with installation, the program simply returns to console without touching anything... I don't see any reason why it should wipe out my older build (the fact that there is new version, is not sufficient, as I did not want to install it) :D I do understand that this is a matter of personal preferences, but for example, if you were trying some your own configuration with a package, and that package gets a new version, I would expect that if I say that I don't want to continue with installation, all my files stay untouched as they are and not that they get silently wiped out:D For me, this is unexpected :D

Spyhawk commented on 2012-08-11 07:43

Archetyp> Fixed in 3.2.2. I also fixed a similar bug when ignoring a dependency of a package. Thx for reporting.

Spyhawk commented on 2012-08-11 07:41

Archetyp> Fixed in 3.2.2.

Spyhawk commented on 2012-08-08 08:42

Archetyp> You're right, a regression has been introduced here a few weeks ago. Working on a fix, thanks for reporting.

Archetyp commented on 2012-08-07 08:25

Running "$pacaur -Syu" asked me a question "Proceed with installation? [Y/n]" on which I answered "n". This instead of expected immediate return to console caused the console to hang up (which I ended with ctrl+c). Brief look at the code showed that pacaur is calling CleanUp() function that seems to be silently trying to delete my *whole* $builddir directory... I really don't think that this is intended behaviour :D
(I'm using latest pacaur 3.2.1)

dauerbaustelle commented on 2012-08-03 19:53

Please add 'arm' to the supported architectures. Works perfectly fine.

Spyhawk commented on 2012-07-15 14:02

smls> The config option to modify builddir has been readded in the git branch.

Spyhawk commented on 2012-07-06 12:53

smls> I'll have a look at it, thx for the report.

smls commented on 2012-07-05 14:16

@Spyhawk: But the BUILDDIR in makepkg.conf works differently from the one that used to be in pacaur.conf...

Previously, the src/ and pkg/ folders ended up in ${BUILDDIR}/${PACKAGENAME}/. Now with the BUILDDIR in makepkg.conf, they always end up directly in ${BUILDDIR}/ (overwriting what was previously there).

This defeats the purpose of specifying a BUILDDIR outside of /tmp so as to archive the build files of all packages that were built with pacaur.

Spyhawk commented on 2012-06-08 08:01

Before someone asks: The new ignore-ood option (new in v3.1.0) is available when using cower-git only at the moment.
Also, changelog is always available at

cgirard commented on 2012-05-24 11:31

@neuromancer85: I defined BUILDDIR in /etc/xdg/pacaur/pacaur.conf (didn't know the var in makepkg.conf was used) and it works. I guess it would allow to have separate build dirs for makepkg and pacaur.

Spyhawk commented on 2012-05-24 10:10

neuromancer85> One design principle I try to apply to pacaur is not reinventing the wheel. The only reason pacaur didn't use the makepkg.conf BUILDDIR var in the past is that I wasn't aware it existed (or it might have been added in pacman 4, but I wouldn't bet on it).

neuromancer85 commented on 2012-05-24 10:00

So this way I don't have separated build dirs for makepkg & pacaur anymore, but at least it works. Thanks :)

Spyhawk commented on 2012-05-24 09:49

neuromancer85> pacaur now uses makepkg.conf BUILDDIR variable instead of the old buildDir in the config file.

neuromancer85 commented on 2012-05-24 09:46

How can I specify the directory where to download/build the pkgs from AUR? There used to be a "buildDir" option in the config file, but it does not seem to work anymore... My problem is that my /tmp is mounted in ram, and for big packages it could be a problem...

Spyhawk commented on 2012-04-26 07:27

doits> makepkg -sfi fails in building netatalk, so the PKGBUILD must be corrected here. Pacaur relies exclusively on makepkg to build and install package, so if makepkg can't install it, pacaur can't too.

Spyhawk commented on 2012-04-25 17:27

doits> Could you try to build the package manually with "makepkg -sfi"? Pacaur is strictly based on makepkg to build and install package, so if makepkg can't install it, pacaur can't too. If makepkg -sfi succeed, please post the output of "bash -x pacaur -S netatalk" in the forum thread ( or send it to me by email.

doits commented on 2012-04-25 17:21

having problems installing netatalk, (see my comment there)

it tries to install something that isn't built and fails. Others (probably not using pacaur) do not have the problem. Could you look into this and tell me if you need more info?

Spyhawk commented on 2012-04-24 03:58

cupentae> I don't think clean option should be disabled by default. Most people don't want/don't need it, and if there is an error, that's gcc pkg fault and thus not related to pacaur itself.

cupantae commented on 2012-04-24 03:50

You have to change this default behaviour: the build directory is "cleaned" even in the case of an error.
My machine spent an hour compiling gcc45. Then a small error meant that I lost all progress. The whole point of make is to do only the minimum of recompilation, so this is a bug.

Spyhawk commented on 2012-04-20 11:37

Pacaur v3 is now live. Few visible changes, but lot of changes in the internal code that will help in further coding/maintenance. As always, regression/bug reports are warmly welcome :]

philomath commented on 2012-04-05 08:11

Thanks, answered on the forum.

Spyhawk commented on 2012-04-04 05:19

philomath> For the second issue, please check that your tmpdir is user readable. Delete it (as root) and try again (as user). For the first issue, it's possible that I introduced a bug with 2.5.4/2.5.5 although I'm trying to be very conservative with the changes I do in the 2.5.x series. Could you post the result of the "bash -x pacaur -Ql <pkg>" (or any other faulty command) in the forum post ( or by email? Thanks for reporting.

Spyhawk commented on 2012-04-04 05:17

philomath> For the second issue, please check that your tmpdir is not user readable. Delete it (as root) and try again (as user). For the first issue, it's possible that I introduced a bug with 2.5.4/2.5.5 although I'm trying to be very conservative with the changes I do in the 2.5.x series. Could you post the result of the "bash -x pacaur -Ql <pkg>" (or any other faulty command) in the forum post ( or by email? Thanks for reporting.

philomath commented on 2012-04-04 04:46

Recently (since 2.5.5-1?) I'm sometimes prompted for a password even when doing simple queries such as pacaur -Ql <package>. what gives?
Also, I have never succeed in editing PKGBUILDs, I'm always getting something like '/usr/bin/pacaur: line 215: /tmp/pacaurtmp-sm/thetime/PKGBUILD: Permission denied :: Could not open thetime PKGBUILD'. what am I missing?

keep up the good work!

asampson commented on 2012-03-20 17:16

@Spyhawk: Thanks for filling me in. I must have broken my $PATH somehow if the build works on a default installation; sorry for the noise.

Spyhawk commented on 2012-03-20 05:59

asampson> Pacaur compile just fine on a default installation (assuming base/base-devel pkgs are installed from Arch media). Perl is already in makedepends array of cower PKGBUILD (which is a direct dependency) ard thus not needed here.

Spyhawk commented on 2012-03-20 05:57

asampson> Pacaur compile just fine on a default installation (assuming base/base-devel pkgs are installed from Arch media). I'll add Perl to makedepends array on the next update.

asampson commented on 2012-03-16 22:45

This PKGBUILD uses pod2man, which (at least on my system) is located at /usr/bin/core_perl/pod2man and not on the default $PATH. Perhaps the full path should be used? (And perl should be added to makedepends?)

Spyhawk commented on 2012-03-10 12:53

KerrickStaley> Please report the PKGBUILD error to the maintainer as "local" PKGBUILD build is not directly supported by pacaur (by design). Of course, you can use makepkg -sfi directly to install the package semi-automatically.

KerrickStaley commented on 2012-03-09 18:50

Could you add a feature to allow building a package from a local PKGBUILD? I ran across a PKGBUILD with incorrect dependencies, so I downloaded it and corrected the dependencies, but I couldn't figure out how to get pacaur to build the new PKGBUILD and automatically install the corrected dependencies.


Spyhawk commented on 2012-02-07 06:27

Sorry guys, I commented on the wrong PKGBUILD :)
This package is still maintained, of course.

cgirard commented on 2012-02-03 16:33

What do you mean "obsolete" ?

Spyhawk commented on 2012-01-26 13:16

This PKGBUILD is now obsolete.

Spyhawk commented on 2012-01-26 12:37

@cgirard> Thx, fixed in master branch now.

cgirard commented on 2012-01-20 18:11

@Spyhawk error messages still lead to the old config file location.

Spyhawk commented on 2012-01-18 14:48

cgirard> you're right, my mistake. @all> Message says "Config file has moved from /etc/pacaur.conf to /etc/xdg/pacaur/pacaur.conf". Please ensure you're using this new conf file if your are upgrading from 2.4.3.
sburnett> my mistake again :) Try downloading and untarring pacaur tarball (see link above, next to "PKGBUILD" link) before running makepkg. I also advise you to learn about the basics of makepkg/abs before everything else, as pacaur has never targeted people that never learned about it.

Anonymous comment on 2012-01-17 18:40

When I follow the installation instructions on

$ curl -o PKGBUILD && makepkg -si
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1031 100 1031 0 0 5972 0 --:--:-- --:--:-- --:--:-- 35551
==> ERROR: install file (pacaur25.install) does not exist.

Am I doing something wrong or is there an error in the PKGBUILD?

cgirard commented on 2012-01-17 16:28

The message is only displayed when updating not installing. I just went into the process of pacaur-legacy removal, pacman 4 installation, pacaur installation and thus never seen the message (but I was aware of the change).

Spyhawk commented on 2012-01-17 15:32

Yes. Please read console output when installing/updating package.

GutenYe commented on 2012-01-17 10:31

config file changes to /etc/xdg/pacaur/pacaur.conf ?

Spyhawk commented on 2011-12-16 15:46

Changed requirement to "depends=('cower>3.0.5' 'expac>0.05' 'sudo')" in order to prevent pacman 3/cower-legacy users to install this package.
Once again, if you're using pacman 3.5.4, please install "pacaur-legacy" [here] (

Spyhawk commented on 2011-12-16 15:05

ZekeSulastin> conflicts=('cower-legacy') won't work as the "provides" field (if existing) is what is checked while solving dependencies, but I've added "conflicts=('cower<=3.0.5')" to the pkgbuild.

And yes, I choose "pacaur-legacy" to match the "cower-legacy" requirement :]

Spyhawk commented on 2011-12-16 15:05

ZekeSulastin> conflicts=('cower-legacy') won't work as the "provides" field (if existing) is what is checked while solving dependencies, but I've added "conflicts=('cower<=3.0.5')" to the pkgbuild.

And yes, I choose "pacaur-legacy" to match the "cower-legacy" requirement :]

ZekeSulastin commented on 2011-12-16 14:44

cgirard: to be fair, pacaur-legacy matches the AUR backend requirement cower-legacy pretty well ;)

What the PKGBUILD *does* need is a method of failing if cower-legacy is installed (I guess a conflict with cower-legacy would work?): since cower-legacy currently provides cower, it's not replaced if you update pacaur thereby leading to possible hilarity. As pacaur is the only thing dependent on any version of cower, I imagine it'd be easiest to add the conflict here :p

cgirard commented on 2011-12-16 12:58


Spyhawk commented on 2011-12-16 11:45

cgirard > Unfortunately, I wasn't aware that the changes I did weren't backward compatible with pacman 3 before someone points it out. I checked that pactree was included in the pacman 3 package, but didn't realize the "-s" option I needed was available in pacman 4 only (and I've one unique machine running pacman 4 only). What should have been a minor release resulted in a mess. Meh.

cgirard commented on 2011-12-16 11:16

I'm really disappointed the way you handled this. It would have been way better if you had advertised this change before releasing 2.4.4. And I don't understand why this package require a version in testing. pacaur-legacy is not legacy, it is current. pacaur should be pacaur-testing.

This was my rant of the day ;)

Spyhawk commented on 2011-12-15 22:36

pacaur 2.4.4 introduce some code optimization that needs the pactree version released with pacman 4.x. Thus, this PKGBUILD is now fully compatible with Pacman 4.x *only*. Is you're still using Pacman 3.x, please install pacaur-legacy available here:

Spyhawk commented on 2011-12-15 22:00

pacaur-legacy, for pacman<4.
Needs pacman 3.5.4, cower-legacy (3.0.5) and expac 0.0.5

Spyhawk commented on 2011-12-15 21:57

pacaur 2.4.4 introduce some code optimization that needs the pactree version released with pacman 4.x. If the carchmagic option is enabled, you'll encounter some issue.
Thus, this PKGBUILD is now *only* fully compatible with Pacman 4.x. Is you're still using Pacman 3.x, please install pacaur-legacy here:

dflt commented on 2011-11-21 10:19

yeeaah, thanks :) Now I can do pacaur -Syyu without f*cking around with pacaur ;-)

Spyhawk commented on 2011-11-16 19:27

People using pacman 4 in [testing] can now use "pacaur-git" instead of that one, without needing to change anything. Although both packages are actually similar, I do not guarantee stability in the future as I'll do prior testing for the "stable" package only.

Spyhawk commented on 2011-11-10 11:51

Sara> Unfortunately, that is the maintainer that decides the new (manually set) pkgver, and there is no kind of server side check in any way. Hopefully, this seldomly happens and occurs only for a limited time. The only fix I can think of is that you move to Japan or New Zealand :]

Sara commented on 2011-11-10 04:29

I am not sure if this can be considered a bug, but pacaur updated the
git version of a package, dated in the AUR as 2011-11-10, but in my
timezone (EST), it's 2011-11-09, so after I run the upgrade, pacaur
still prompts me to update because it doesn't take into account the
timezone difference. (The package is clipodder, by the way.) Can this
be fixed, or is this something that can't be helped?

Sara commented on 2011-11-10 04:26

I am not sure if this can be considered a bug, but I have an AUR
package that wants me to update to the git version of a package, dated
for 2011-11-10, but in my timezone (EST), it's still 2011-11-09. I ran
`pacaur -Syu`, and after upgrading the package, pacaur still wants me
to upgrade, because the aur package (it's for clipodder) lists
clipodder-20111110 as the current version, whereas my machine doesn't
have it because it isn't tomorrow yet. Is there any way to properly
deal with this issue, or is it something that can't be fixed? (By
"fixed", I mean that the timezone differences should be taken to
account when running upgrades, so that I won't be prompted to
re-upgrade when I do in fact have the latest version of the software.)

dflt commented on 2011-11-07 16:47

Pacman4 is stable but it is not tested, so it is in testing, duh.

Spyhawk commented on 2011-11-05 17:27

This PKGBUILD will follow what is commonly considered as stable ([core], [community]). I don't feel like maintain another PKGBUILD that will become obsolete as soon as pacman 4 is released to [core]. Anyway, if removing ~7 characters is too a hassle and that you don't want to "bother" with minor details, you probably shouldn't be using [testing] in the first place :]

dflt commented on 2011-11-05 16:45

or even pacaur-testing?

dflt commented on 2011-11-05 16:44

can we have like pacaur-legacy? why bother with changing anything by hand?

Spyhawk commented on 2011-10-30 16:22

gobonja > I'll certainly not make "No" the default answer. However, I'm planning to add a global option to disable it for those that prefer not to edit anything.

gobonja commented on 2011-10-30 15:25

I have suggestion. Could you make N default answer when I press ENTER when pacaur ask me should I edit pkgbuild?
I know that there is --noedit option but I think this would be useful.

gulafaran commented on 2011-10-28 02:03

SanskritFritz it does now, sorry missed to add that in the PKGBUILD

gulafaran commented on 2011-10-28 02:03

SanskritFritz it does now, sorry missed to add that in the PKGBUILD

SanskritFritz commented on 2011-10-27 13:35

Pity that that cower-legacy PKGBUILD doesnt provides=cower

Spyhawk commented on 2011-10-27 12:53

Updated to 2.3.9.
If you are using pacman 4 from [testing] and expac 0.0.7 from [community-testing], please change "cower-legacy" dependency to "cower".

Spyhawk commented on 2011-10-22 15:44

No, that has been done on purpose to prevent an easy install/upgrade to cower 3.0.8 that is only compatible with pacman 4 from [testing]. Again:
- if you use pacman 3.5.4, install (or stick with) cower 3.0.5.
- if you use pacman 4.0.0 from [testing], install cower 3.0.8 manually and expac 0.0.7 from [community-testing], then install pacaur by removing the dependencies version restriction.
This is a temporary measure that will be lifted once pacman 4 reaches [core] and expac 0.0.7 reaches [community]. Pacaur itself is both compatible with cower 3.0.5 and cower 3.0.8.

Anonymous comment on 2011-10-22 14:21

I think dependences should be with <=:
depends=('cower<=3.0.8' 'expac<=0.07')

Spyhawk commented on 2011-10-14 20:22

No, dependency checks are done by cower itself before download. However, upgrade checks version number (through cower) and you'll need to ignore cower to avoid it being detected (try "cower -u", then "cower -u --ignore cower"), which is the correct behavior. The problem here is simply that the newest cower is only compatible with a package that is available in testing. That's quite an unusual way to update an aur package - usually, maintainers use two different pkgbuild (ie, pacman-color and pacman-color-testing) to avoid this kind of situation :]

Sara commented on 2011-10-14 19:42

Why does pacaur still prompt me to upgrade cower, though the upgrade conflicts? (I've upgraded pacaur.) Do the dependency checks occur after makepkg?

Spyhawk commented on 2011-10-14 15:20

Done. If you are using pacman 4 that is now in testing, you'll need to upgrade pacman and expac (community-testing) first, then install cower 3.0.8 the old way with makepkg (or with any other aur helper). Also, pacman-color-testing is actually out of date.

Spyhawk commented on 2011-10-14 15:17

Done. If you are using pacman 4 that is now in testing, you'll need to upgrade pacman and expac (community-testing) first, then install cower 3.0.8 the old way with makepkg (or with any other aur helper). Also, pacman-color-testing is actually out of date.

Sara commented on 2011-10-14 13:55

At the moment, cower is broken, so can the pkgver of the cower dependency be restricted to less than 3.0.8, so we don't upgrade and brake pacaur as well in
the process? Hopefully cower will be fixed soon, but I think this would be helpful in the interim (I already broke pacaur on another machine because of the

Spyhawk commented on 2011-10-10 08:35

You might have temporary problems with your internet line. Try with cower and see how it behaves (cower -dd package).

Anonymous comment on 2011-10-09 21:44

I'm getting the message:

WARNING: no socket to connect to

Any idea why?

Spyhawk commented on 2011-09-25 18:32

That bug should now be fixed in the git tree. However, there are still some other related bugs (using --noconfirm with ignored packages) that I want to get rid off before releasing the next version, but you can try it out.

Spyhawk commented on 2011-09-17 09:38

Yes, that's a bug I am aware of. I opened a github issue 2 weeks ago here:

Sara commented on 2011-09-16 22:01

Another bug I just noticed: If I run `pacaur -u --devel --ignore surf-hg` pacaur still tries to install the dependencies of surf-hg. I know this because if I run `pacaur -y` with the other developmental packages manually inserted as arguments, pacaur (correctly) does not prompt me to install the dependcies of surf-hg.

Sara commented on 2011-09-16 21:59

Another bug I just noticed: If I run `pacaur -u --devel --ignore surf-hg` pacaur still tries to install the dependencies of surf-hg. I know this because if I run `pacaur -y` with the other developmental packages manually inserted as arguments, pacaur does not prompt me to install those dependencies.

Sara commented on 2011-09-15 03:47

The update to pacaur fixed my issue, so I presume it's the bug you identified.

Spyhawk commented on 2011-09-14 21:20

2.3.6 is released, fixing a conflict bug that might occur in upgrade or upgrade --devel only. Hope that is the bug you came across, and not another one I haven't identified yet.

Sara commented on 2011-09-14 20:00

When I try to upgrade developmental packages with the --devel switch, pacaur
is giving me strange output:

pdfgrep-git and vim-latexsuite-git are in conflict. Remove vim-latexsuite-git?

It also told me that fbff-git and cope-git are in conflict, which is entirely
impossible, as one is a framebuffer video player, and the other colors text on
the console. It also appears unlikely that vim and pdfgrep would conflict,
since pdfgrep searches PDFs, and vim is a text editor.

Do you have any idea why this is happening?

Spyhawk commented on 2011-09-09 08:10

I'll make it possible in the next version.

Sara commented on 2011-09-08 05:17

The default value for "white" in pacman-color is intensive foreground (which in my case, with a white background, is black), but AUR operations use white (and not my foreground color) for things like "Starting AUR upgrade". Replacing "31" with "30" in the definition for white in the script itself fixes the issue, but could this color be made configurable in the conf file? Thanks.

Spyhawk commented on 2011-09-04 22:36

You're right. I'll set color option to false by default in the next release.

MisterAnderson commented on 2011-09-04 14:47

Since pacman-color is not a dependency it should not be enabled by default. Either make it a dependency or colour should be defaulted to false not true.

Spyhawk commented on 2011-08-10 12:07

The default value is the one that is used by the main script if you comment all the values in pacaur.conf. The conf file values only override the default ones. However, I agree with you that it looks inconsistent and will change it in the next release.

dikei commented on 2011-08-10 02:07

The default value used in pacaur.conf is different from the one in the comment. IMHO, this is a bug.

Spyhawk commented on 2011-07-30 18:31

2.2.1 released. I'll add your request about editing option on my todo list.

Spyhawk commented on 2011-07-30 11:14

Thanks for this new report. Most of the issues are fixed in github, but the --asdeps switch needs more work. I'm out of town today, but I'll try to release 2.2.1 when I come back tonight.

Anonymous comment on 2011-07-30 03:11

Thanks for reacting so quickly :)

I am using cower 3.0.4-1 package, and expac 0.05-1.
Installing a single package from aur works fine with -S switch, with -y and -ye its the same as with -u, but they give this message on end too:

/usr/bin/pacaur: line 207: /etc/abs.conf: No such file or directory.

Spyhawk commented on 2011-07-29 23:15

"grep: /home/user/.config/cower/config: No such file or directory" error is related to the ignorecheck part of pacaur and is now fixed on my system (not related to cower directly - my bad). The others bugs are on the track. Stay tuned for a 2.2.1 release! :]

Spyhawk commented on 2011-07-29 23:01

Also, you can use the non-pacman like command set to install without edit prompt (-y to install, -ye to edit and install) or use the --noedit option.
"--asdeps" not working is definitely a pacaur bug. Any unknown option is passed to pacman, but --asdeps is a special case that need to be handled separately. Thanks for reporting :]

Spyhawk commented on 2011-07-29 22:40

The grep message is related to cower backend, but pacaur/cower seems to run without problem here. Which version of cower are you using? Cower or cower-git?
The last line (error: no target specified) is indeed related to pacaur. Thanks for reporting, I'll fix it as soon as possible.

Anonymous comment on 2011-07-29 21:44

I am getting this error on "pacaur -u" command:

grep: /home/attila589/.config/cower/config: No such file or directory
error: no targets specified (use -h for help)

It lists packages that needs upgrades but it stops after printing that message.

Besides this, two options that might improve pacaur further: --asdeps support, and option in config file to turn out prompting to edit PKGBUILDS

Thanks for the best aur helper available, keep up the good work!

Spyhawk commented on 2011-06-23 12:47

Better way of handling dev packages + fixed a few bugs in 1.1.1 . Let me know if you encounter any problem :)

Anonymous comment on 2011-06-23 11:04

Thanks for the new option to upgrade the dev packages!

Spyhawk commented on 2011-06-23 00:45

Added --devel flag for -Sua operation.
attila589 > The development packages detection is handled differently from packer for performance reason. Please test and compare with packer -Syu --auronly --devel. There are no difference on my machine but I don't use that many dev packages. Detection seems also better than yaourt.

Spyhawk commented on 2011-06-20 12:06

I'll see what I can do in the following days. In the meantime, any patch is warmly welcome :)

Spyhawk commented on 2011-06-20 11:35

I'll see what I can in the following days. In the meantime, any patch is warmly welcome :)

Anonymous comment on 2011-06-20 01:37

Thanks for this great script, im missing only one feature: a switch to upgrade all dev packages (like packer -Syu --auronly --devel)