packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

essence-of-foo · 2011-05-07 07:35:49

mhertz wrote:

@essence-of-foo
Packer allready reports out-of-date warnings...

But only if you try to install a package. There is no such warning when looking at the results of packer -Ss

jakob · 2011-05-08 10:11:33

Though packer really impressed me w/ its speed and simplicity (I like the concept of only substituting functions not available by pacman-proper) I have switched back to yaourt, since the possibility to keep once built PKGBUILDS to tinker around w/ them is more important to me.

Wouldn’t it be possible to create a little conf-file to tell packer some settings?

Apart from that, this is a really neat piece

Best, Jakob

neurolysis · 2011-05-08 12:14:59

I switched from yaourt because it doesn't handle file changes/interaction very well (often reports 'file already exists in filesystem' when it should just continue). Has anyone experienced any similar problems using this? Right now I'm using pacget to avoid it.

Also, I noticed a few things that could be improved in the code, will send a pull request soon.

Last edited by neurolysis (2011-05-08 12:16:37)

jakob · 2011-06-19 13:40:53

Since I’ve set “alias p='TMPDIR=~/tmp/pkgs packer'” since my last post, I’m a happy packer user since over a month with saved PKGDIRS in ~/tmp/pkgs/packerbuild-1000.

The only thing I’m experiencing right now is that the installation part during package upgrades doesn’t work since there exist several symlinks to all until then built versions of the given package in ~/tmp/pkgs.

~/tmp/pkgs is also my PKGDEST in makepkg.conf. Today, I saw that the newest git commit is commented with the following

Second, don't use PKGDEST; pkgver globbing returns invalid results for pacman -U if PKGDEST contains more than one version of a package. makepkg creates a symlink in the build directory, so just use that.

(source)

So I wanted to ask how “don’t use PKGDEST” is meant? If I want to have all built packages stored in ~/tmp/pkgs, there is no other possibility than setting PKGDEST, right?

Best,

Jakob

mhertz · 2011-07-02 03:15:29

@bruenig

Could you please consider adding support for customizepkg as an optdepend(like yaourt), since imho this is a really nice feature, which supports auto-patching pkgbuilds during installs/upgrades, so as to e.g. add custom patches or add/remove deps/configure-args etc...

I've made a patch for adding support for customizepkg into packer, but it's just a single line and you can most probably do it better yourselve, but nonetheless...

--- /usr/bin/packer    2011-07-02 04:48:23.000000000 +0200
+++ ./packer    2011-07-02 05:02:32.400075400 +0200
@@ -256,6 +256,7 @@ aurinstall() {
     curl -Lfs "$PKGURL/$1/$1.tar.gz" > "$1.tar.gz"
     tar xf "$1.tar.gz"
     cd "$1"
+    [[ -f "/etc/customizepkg.d/$1" ]] && customizepkg --modify
   fi
 
   # Allow user to edit PKGBUILD

Thanks in advance!

Edit:

Could you also please make --devel not exclude regular aur packages, like yaourt and aurget(recently implemented), which imho makes better sence, as too not need to run packer twise, one for normal and one for devel packages...

Lastly, I would also really appreciate if you would add '-Syuu'. If it was just for downgrading from [testing] to "stable", then it obviously shouldn't be added to packer since that's a pacman job, but that option is also really usefull for [testing] users, to be used allways for upgrading, since packages from time to time gets downgraded there, and currently packer just leaves the buggy versions in place.

Last edited by mhertz (2011-07-02 05:24:46)

anonymous_user · 2011-07-07 15:05:29

I get this output when trying to install yaourt using packer:

~ $ packer -S yaourt
::  is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n]

However I do not have any packages in IgnorePkg/IgnoreGroup.

mhertz · 2011-07-08 00:49:04

Are you absolutelly sure i.e. you have checked /etc/pacman.conf?

Second, are you using latest packer? As it's a git-package you need --devel enabled upon upgrades, or to run packer -S packer...

Why I wrote the above is because it "sorta" works on my end and defenetelly dosen't come up with that error message..

When I run packer -S yaourt, then it first installs yajl, and second starts building and installing package-query, but fails with:

(1/1) installing package-query [#####################################################] 100%
tar: This does not look like a tar archive
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now

When then running packer -S yaourt again, then it installs yaourt fine...

Last edited by mhertz (2011-07-08 00:51:32)

anonymous_user · 2011-07-08 01:18:29

I am very sure:

~ $ cat /etc/pacman.conf 
#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives

#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir     = /
#DBPath      = /var/lib/pacman/
#CacheDir    = /var/cache/pacman/pkg/
#LogFile     = /var/log/pacman.log
HoldPkg     = pacman glibc
# If upgrades are available for these packages they will be asked for first
SyncFirst   = pacman
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#XferCommand = /usr/bin/curl -C - -f %u > %o
#CleanMethod = KeepInstalled
Architecture = auto

# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg   =
#IgnoreGroup =

#NoUpgrade   =
#NoExtract   =

# Misc options (all disabled by default)
#UseSyslog
ShowSize
#UseDelta
#TotalDownload
#CheckSpace

#
# REPOSITORIES
#   - can be defined here or included from another file
#   - pacman will search repositories in the order defined here
#   - local/custom mirrors can be added here or in separate files
#   - repositories listed first will take precedence when packages
#     have identical names, regardless of version number
#   - URLs will have $repo replaced by the name of the current repo
#   - URLs will have $arch replaced by the name of the architecture
#
# Repository entries are of the format:
#       [repo-name]
#       Server = ServerName
#       Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#

# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.

#[testing]
#Include = /etc/pacman.d/mirrorlist

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

#[community-testing]
#Include = /etc/pacman.d/mirrorlist

[community]
Include = /etc/pacman.d/mirrorlist

# An example of a custom package repository.  See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#Server = file:///home/custompkgs

Yes I am using the latest packer. I also observed this behavior when installing btnx-config however I do not get that question when trying to install checkgmail-svn.

mhertz · 2011-07-08 01:52:13

Hmm, OK thanks for replying!

I did a debug-run i.e. 'bash -x packer -S yaourt', and it fails after having installed package-query and then when it should install yaourt, it still thinks there is another aur dep, which it tries to download and build, but that dep is empty: "", which obviously dosen't work.

(1/1) installing package-query                                                             [#####################################################] 100%
+ for dep in '"${aurdepends[@]}"'
+ aurinstall '' dependency
+ dir=/tmp/packerbuild-1000/
+ . /tmp/packerbuild-1000///PKGBUILD
+ [[ -d /tmp/packerbuild-1000/ ]]
+ rm -rf /tmp/packerbuild-1000/
+ mkdir -p /tmp/packerbuild-1000/
+ cd /tmp/packerbuild-1000/
+ curl -Lfs https://aur.archlinux.org/packages//.tar.gz
+ tar xf .tar.gz
tar: This does not look like a tar archive

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
+ cd ''
+ [[ -f PKGBUILD ]]
+ err 'No PKGBUILD found in directory.'
+ echo -e 'No PKGBUILD found in directory.'
No PKGBUILD found in directory.
+ exit 1

Also, it states: 'Aur Targets (3): package-query' ' yaourt':

+ for pkg in '"${aurtargets[@]}"'
+ existsinlocal yaourt
+ /usr/bin/pacman -Qq -- yaourt
+ for pkg in '"${aurtargets[@]}"' '"${aurdepends[@]}"'
+ isoutofdate yaourt
+ rpcinfo yaourt
+ [[ -f /tmp/packertmp-1000/yaourt.info ]]
+ grep -qF '"OutOfDate":"1"}}' /tmp/packertmp-1000/yaourt.info
+ for pkg in '"${aurtargets[@]}"' '"${aurdepends[@]}"'
+ isoutofdate package-query
+ rpcinfo package-query
+ [[ -f /tmp/packertmp-1000/package-query.info ]]
+ grep -qF '"OutOfDate":"1"}}' /tmp/packertmp-1000/package-query.info
+ for pkg in '"${aurtargets[@]}"' '"${aurdepends[@]}"'
+ isoutofdate ''
+ rpcinfo ''
+ [[ -f /tmp/packertmp-1000/.info ]]
+ curl -LfGs --data-urlencode arg= 'https://aur.archlinux.org/rpc.php?type=info'
+ grep -qF '"OutOfDate":"1"}}' /tmp/packertmp-1000/.info
+ echo

+ [[ -n package-query ]]
+ num=3
+ echo -e 'Aur Targets    (3): package-query' ' yaourt'
Aur Targets    (3): package-query  yaourt

But it seems it detects the deps fine? :

+ dependencies=($(echo -e "${depends[*]}\n${makedepends[*]}" | sed -e 's/=.*//' -e 's/>.*//' -e 's/<.*//'| sort -u))
++ sort -u
++ sed -e 's/=.*//' -e 's/>.*//' -e 's/<.*//'
++ echo -e 'pacman>=3.5
pacman<3.6
curl
yajl>=2.0\n'

+ dependencies=($(echo -e "${depends[*]}\n${makedepends[*]}" | sed -e 's/=.*//' -e 's/>.*//' -e 's/<.*//'| sort -u))
++ sort -u
++ sed -e 's/=.*//' -e 's/>.*//' -e 's/<.*//'
++ echo -e 'diffutils
pacman>=3.5
package-query>=0.7
gettext\n'

Last edited by mhertz (2011-07-08 02:18:02)

bruenig · 2011-07-10 20:17:31

I put out a new version of it (should update automatically since I uppped the PKGBUILD number on aur). It has the following 3 changes.

1. Implemented customizepkg modifications, thanks mhertz.
2. Fixed the bug of the phantom empty dependency (I introduced that bug a couple of weeks ago when I changed the order that I filled up the aurdepends array)
3. Now allow for any sort of -Su command to go through, e.g. -Suuyy or whatever else.

So hopefully that covers all of the built up concerns.

b9anders · 2011-07-16 21:59:58

I like packer for its speed and simplicity, but I do have one feature request for a behaviour that is bugging me:

Is it possible that to change the sequence of pkgbuild editing and dependency checking? Or at least add an option to edit it at the "Proceed with installation?" point before proceeding? There are packages where I need to edit the dependencies in the PKGBUILD and packer pulling in all the dependencies ahead of that sort of defeats a major point of being able to edit the PKGBUILD for me.

mhertz · 2011-07-16 22:12:33

With the newly introduced customizepkg optdepends, then you can make "edit-files" for your aur packages, which then afterwards upon installs or upgrades will automatically follow the customizations you've defined in the "edit-files", like e.g. removing deps, changing build options or adding patches etc etc.

That's imho a brilliant addition, so as we do not need to make the same changes to the pkgbuilds install after install, upgrade after upgrade! And then just can run automatic from then on with e.g. the --noconfirm switch and still have all your changes fully applied!

Last edited by mhertz (2011-07-16 22:18:59)

Zucca · 2011-07-18 19:07:21

Quick quetion: Does packer save source files for git, svn and so on packages, so that when you do "packer -S foo-git" it only syncs the sources rather than download all the sources again?

jakob · 2011-07-18 19:20:56

Zucca wrote:

Quick quetion: Does packer save source files for git, svn and so on packages, so that when you do "packer -S foo-git" it only syncs the sources rather than download all the sources again?

Depends on whether you leave the tefault tmp dir or change it.

I start packer by invoing it via the following alias:
'alias p="TMPDIR=/home/jakob/tmp/pkgs/ packer"'

thus, all build dirs are stored in ~/tmp/pkgs/packerbuild-1000/$pkgname/$pkgname → if I do a fresh build of a git/svn/hg/whatever package, only the new commits are loaded.

However, this encompasses the problem I described in #529 that the installation process fails in most cases since there are more symlinks to every version that was once built…

Last edited by jakob (2011-07-18 19:21:51)

Zucca · 2011-07-18 20:17:43

jakob wrote:

Zucca wrote:
Quick quetion: Does packer save source files for git, svn and so on packages, so that when you do "packer -S foo-git" it only syncs the sources rather than download all the sources again?
Depends on whether you leave the tefault tmp dir or change it.
I start packer by invoing it via the following alias:
'alias p="TMPDIR=/home/jakob/tmp/pkgs/ packer"'
thus, all build dirs are stored in ~/tmp/pkgs/packerbuild-1000/$pkgname/$pkgname → if I do a fresh build of a git/svn/hg/whatever package, only the new commits are loaded.
However, this encompasses the problem I described in #529 that the installation process fails in most cases since there are more symlinks to every version that was once built…

I think packer needs this kind of feature. Also skipping the update if sources are up-to-date (optionally forcing compiling and installion anyways).

karabaja4 · 2011-07-18 20:47:03

Something seems very wrong here (trying to install compiz from AUR):

~ >>> packer -S ccsm-git compiz-plugins-extra-git compiz-plugins-main-git compizconfig-python-git fusion-icon-git libcompizconfig-git
warning: fusion-icon-git is flagged out of date

Aur Targets    (18): compiz-core-git libcompizconfig-git compiz-core-git compizconfig-python-git libcompizconfig-git compiz-core-git compiz-core-git compiz-plugins-main-git compiz-core-git libcompizconfig-git compiz-core-git compizconfig-python-git ccsm-git compiz-plugins-extra-git compiz-plugins-main-git compizconfig-python-git fusion-icon-git libcompizconfig-git
Pacman Targets (2): boost libstdc++5

notice the repeating packages in Targets? I'm afraid to build them like this.

Spyhawk · 2011-07-22 09:17:06

mhertz wrote:

With the newly introduced customizepkg optdepends, then you can make "edit-files" for your aur packages, which then afterwards upon installs or upgrades will automatically follow the customizations you've defined in the "edit-files", like e.g. removing deps, changing build options or adding patches etc etc.
That's imho a brilliant addition, so as we do not need to make the same changes to the pkgbuilds install after install, upgrade after upgrade! And then just can run automatic from then on with e.g. the --noconfirm switch and still have all your changes fully applied!

Just out of curiosity, is there any valid user case when it is required to add/remove a dependency instead of fixing the upstream PKGBUILD? Also, packer doesn't seem to take into account changes of dependencies after editing the file (manually of with customizepkg), but I'm not sure if that is required *in practice* (yaourt does it).

Last edited by Spyhawk (2011-07-22 09:20:41)

b9anders · 2011-07-22 11:07:52

Spyhawk wrote:

Just out of curiosity, is there any valid user case when it is required to add/remove a dependency instead of fixing the upstream PKGBUILD? Also, packer doesn't seem to take into account changes of dependencies after editing the file (manually of with customizepkg), but I'm not sure if that is required *in practice* (yaourt does it).

I have vala-git. I know I don't need to install vala whenever I want to install a package that requires regular vala. Packer won't let me do this and so I have to go to the AUR website and download the tarball and change the PKGBUILD manually before makepkg hauls in the dependencies. It sort of defeats the purpose of having packer installed in the first place.

You should always be able to edit the package build before doing anything else. That Packer doesn't allow for this is a serious design flaw, imo.

Spyhawk · 2011-07-22 11:23:14

b9anders wrote:

I have vala-git. I know I don't need to install vala whenever I want to install a package that requires regular vala. Packer won't let me do this and so I have to go to the AUR website and download the tarball and change the PKGBUILD manually before makepkg hauls in the dependencies. It sort of defeats the purpose of having packer installed in the first place.

Shouldn't the "provides" field be sufficient for this?

b9anders · 2011-07-22 12:53:21

Spyhawk wrote:

b9anders wrote:
I have vala-git. I know I don't need to install vala whenever I want to install a package that requires regular vala. Packer won't let me do this and so I have to go to the AUR website and download the tarball and change the PKGBUILD manually before makepkg hauls in the dependencies. It sort of defeats the purpose of having packer installed in the first place.
Shouldn't the "provides" field be sufficient for this?

This is just one example. Vala-git already proves 'vala' but it doesn't play well with PKGBUILDs that specify version numbers for Vala. Bottomline is that with the packages on my system I often need to edit dependencies for pkgbuilds when I want to install something new. Can't do that with Packer.

Last edited by b9anders (2011-07-22 12:54:37)

mhertz · 2011-07-23 00:51:43

@Spyhawk

The packages from the official repositories are in general very clean and only includes whats needed to run and everything else is e.g. optdepends, but however it's a different story with the aur, which often contains deps which pleases the pkgbuild author, but maybe not you...

Now, the customizepkg optdepends, will let you automatically do whatever mods you like to the pkgbuilds, exactly as if you yourself had selected yes to edit the pkgbuild and done the edits manually!

However, due to a design-fault in packer, then changed deps either be manual edits or with customizepkg, isn't respected by packer, since it installs them first, before letting you edit the pkgbuild/run customizepkg edits.

I actually didn't knew this before you and b9anders mentioned this, and I have just tested it and came to the same conclusion...

I haden't noticed it before, because I personally only use very few aur packages, and of them, then i'm content with the authors choise of deps, and only use customizepkg to auto-edit the build-options for me upon installs/upgrades...

I don't really have time for this currently, but bruenig is very active and helpfull if you make an "Issues" report on the packer github page, if, provided, that he feels that your issue is valid! (but im sure that he will feel such about this specific issue here!)

Spyhawk · 2011-07-23 16:42:50

b9anders, mhertz > Thx, but I'm afraid that both of you haven't answered my question. I do understand that it is sometimes necessary to modify deps because of low quality pkgbuild, or because it is faster to do it yourself than requesting the original author to improve the upstream pkgbuild. What I don't know is if there is any existing user case that require to add/remove a dependency even though the upstream pkgbuild is of good quality. In other words, does the fact that packer doesn't allow it means it has a technical flaw, or does customizepkg itself encourage bad practice (convenience over code-correctness, see the Arch way)? And if such a use case exists, could you give me an example?

The other reason I'm asking is because the aur helper I'm currently working on (pacaur) has (more or less) a similar "flaw", but I'm still not convinced that it is really one and that I (or bruenig) should "fix" it (ie, find an ugly workaround instead of fixing the upstream pkgbuild).

Last edited by Spyhawk (2011-07-23 16:55:23)

keenerd · 2011-07-23 19:56:49

I've been fooling around with patches for Packer again.

New stuff includes color for people without pacman-color, proper line wrapping, parallel AUR searches, and moving parts of the backend to expac/jshon for increased speed and reliability.

Code is here: https://github.com/keenerd/packer

If these are anything like my last set of patches (parallel AUR update) then there are probably weird bugs I've missed. Any guinea pigs brave volunteers want to try it?

mhertz · 2011-07-24 03:23:52

@Spyhawk

I believe that I did actually answer your question, though... As stated, then strict package standards are followed for official apps, but that dosen't always count for aur packages, which you e.g. can see be the sheer amount of packages with patches for added fuctionality i.e. against the arch way!

If some pkgbuild author wants to add extra deps, because he likes that specific extra functionality, then who am I too say that he shouldn't do that? It is afterall the unofficial _user_ repo... On the other hand, for official repos, I fully agree with you...

That's just like if I was to report a bug to an aur author because he uses non-essential patches, and which a load of packages does...

That's one of the uses of the aur afterall... To get e.g. patched packages, or packages with extra functionality, since the official repos are so strict...

As I said, I do not use many aur packages, and so cannot give you some examples from the top of my head, but im absolutelly sure that there are packages with deps that would have been optdepends if the package where in the official repo...

Another case in point, is that sometimes people will want to remove deps + add --disable-xxx build-options for avoiding unwanted functionality, e.g. one of the example configs in customizepkg disables dbus-glib for a package etc. Or, to add deps and extra build-options for added functionality...

Anyway, since packer does let you edit the pkgbuild before install(or use customizepkg for that automatically), then I would defenetelly say that it is a design-fault if changed deps aren't respected, but that's just me...

@keenered

Thanks alot for your contribution! I had actually allready seen your commits at the packer git repo, and was e.g. intrigued by gaining peformance with the use of jshon in packer, and also expac, but to be honest, then i'm pretty undecided about these changes, since on the one hand you indeed use the right tools for the job to gain speed, but also you introduce extra deps into the equation, and so I don't really know how I feel about it, though.. But nonetheless, kudos for taking the initiative and implementing it!

Last edited by mhertz (2011-07-24 03:33:01)

keenerd · 2011-07-24 04:15:04

Both of those deps are in community. And the way Packer handles these things now is scary. It works, but is very fragile. I am still not entirely happy with everything, like packer adhoc parses the AUR's html.

Expac and Jshon were made for shell scripts, to replace messy and fragile code. Expac links against alpm (as does package-query, causing no end of pain for yaourt users) but Expac is in the repos and should be updated more or less along with pacman. Falconindy also hacks on Pacman, so it does not seem likely Expac will be blindsided by future developments.

Jshon mainly suffers from being very young. While hacking on Packer, I had to add several features to Jshon. Usually this is a sign the lead dev did not think things through. And it is an odd way of handling json, but the most sane way in a script.

Bruenig, if they really bother you I can try to write them out of the patches. Most of the gains would be lost, but some of the refactorings would still apply.

Last edited by keenerd (2011-07-24 04:26:26)

Arch Linux

#526 2011-05-07 07:35:49

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#527 2011-05-08 10:11:33

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#528 2011-05-08 12:14:59

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#529 2011-06-19 13:40:53

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#530 2011-07-02 03:15:29

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#531 2011-07-07 15:05:29

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#532 2011-07-08 00:49:04

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#533 2011-07-08 01:18:29

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#534 2011-07-08 01:52:13

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#535 2011-07-10 20:17:31

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#536 2011-07-16 21:59:58

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#537 2011-07-16 22:12:33

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#538 2011-07-18 19:07:21

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#539 2011-07-18 19:20:56

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#540 2011-07-18 20:17:43

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#541 2011-07-18 20:47:03

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#542 2011-07-22 09:17:06

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#543 2011-07-22 11:07:52

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#544 2011-07-22 11:23:14

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#545 2011-07-22 12:53:21

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#546 2011-07-23 00:51:43

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#547 2011-07-23 16:42:50

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#548 2011-07-23 19:56:49

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#549 2011-07-24 03:23:52

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

#550 2011-07-24 04:15:04

Re: packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

Board footer