Package Details: aurman 2.20.1-1

Git Clone URL: (read-only, click to copy)
Package Base: aurman
Description: AUR helper with almost pacman syntax
Upstream URL:
Licenses: MIT
Submitter: polygamma
Maintainer: polygamma
Last Packager: polygamma
Votes: 196
Popularity: 0.20
First Submitted: 2018-03-20 21:31
Last Updated: 2020-07-07 19:38

Pinned Comments

polygamma commented on 2018-08-21 18:02

aurman development for public use has been stopped. i suggest migrating to yay, i am not interested in any kind of feedback, bug reports, feature requests etc. anymore.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

eschwartz commented on 2018-07-09 15:43

makepkg itself supports PKGDEST, see the makepkg.conf(5) manpage.

dawcek commented on 2018-07-09 15:28

Hello everyone. May you tell me if there possibility automatically move built package to main packages cache(/var/cache/pacman/pkg) ?? Thanks in advance for your response.

polygamma commented on 2018-06-24 13:07

aurman depends on "expac" again.

eschwartz commented on 2018-06-24 07:21

Heads up -- expac 9 has now been tagged as a stable release.

Morganamilo commented on 2018-06-24 02:25

@Eschwartz thanks for clearing that up, I'd say add the r, epoch or not. Not that big of a deal though obviously, if it's not worth the effort then whatever.

eschwartz commented on 2018-06-24 01:58

I removed a bunch of comments (and the no-longer-needed replies) which were just providing help for GnuPG. Stop doing that. It's inappropriate.

Stop suggesting people break the package by messing with the dependencies. This is advice that moved on from being a waste of space, to being downright dangerous.

Morganamilo: on the topic of expac-git's version format, it uses the standard git describe format, but doesn't insert an "r" into the commit count. 8.2 is not the release tag, 8 is the release tag and 2 is the commit count. Yes, I agree the format is confusing, but it definitely doesn't break vercmp unless dreisner chooses to publish a major.minor release which is is unlikely since he's never done so before (and also knows the dangers of changing the versioning format in non-backwards-compatible ways).

The missing "r" is something that cannot be fixed anyway, without either adding an epoch or waiting until a stable release, since 9.r0.g${sha} is greater than 8.2.g{$sha}, while 8.r2.g${sha} is lesser.

Morganamilo commented on 2018-06-23 16:25

Oh well in that case it doesn't really matter then due to the .2 being more important than the commit.

Although depending on a specific commit doesn't really mean anything when it comes to alpm's vercmp.

I would still talk to falconindy about using the standard pkgver format though.

polygamma commented on 2018-06-23 16:20

@Morganamilo I do not quite see your point, a new commit leads to "8.2.xxxxx"

Morganamilo commented on 2018-06-23 16:16

While I am here though. The dependency on expac-git>=8.1.g5ae006f should probably be changed. vercmp just checks the ascii codes and can not tell which git commit comes after which. This means g5ae006f could change to become something that evaluated as less than the last commit.

Instead expac should be using the more standard 8.1.r100.g5ae006f versioning where you can then dep a specific revision expac-git>=8.1.r100

Foxboron commented on 2018-06-21 20:00


This is expected and any users using the AUR should be aware of how this works. Yelling about outdated VCS packages and claiming that an Arch Dev and an AUR helper developer doesn't understand the basics is just insulting to say the least.

It is even documented in the page we expect you to read.