pacaur - an AUR helper that minimizes user interaction

Spyhawk · 2011-08-09 16:10:59

plippity> Check your sudo configuration (timestamp to zero?)
lucak3 > Glad you found a solution :]

splippity · 2011-08-09 19:29:25

Spyhawk wrote:

plippity> Check your sudo configuration (timestamp to zero?)
lucak3 > Glad you found a solution :]

Yes the timestamp is zero
Is that why if I dont type sudo before it I have to type twice but if I put sudo it works on first password input???

Spyhawk · 2011-08-09 20:42:26

splippity wrote:

Yes the timestamp is zero
Is that why if I dont type sudo before it I have to type twice but if I put sudo it works on first password input???

Settings timestamp to zero means that you'll have to type your password each and every time an internal function requiring root privilege is called. Although I'm pretty sure that is the reason of your problem, could you show me your sudo configuration here so I could test it on my machine?

splippity · 2011-08-09 22:37:36

Defaults insults
Defaults timestamp_timeout=0

##
## Runas alias specification
##

##
## User privilege specification
##
root ALL=(ALL) ALL

## Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL
%wheel ALL = NOPASSWD: /usr/bin/pacaur -Sy
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

## Uncomment to allow members of group sudo to execute any command
# %sudo ALL=(ALL) ALL

## Uncomment to allow any user to run sudo if they know the password
## of the user they are running the command as (root by default).
# Defaults targetpw  # Ask for the password of the target user
# ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'

## Read drop-in files from /etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /etc/sudoers.d

and if I try a command like: pacaur -Su
I end up with:

└─┤06:54 PM|$├─> pacaur -Su
Password: 
Password: 
:: Starting full system upgrade...

and if I were to do sudo pacaur -Su
everything works perfectly:

─┤06:35 PM|$├─> sudo pacaur -Su                                                                  
Password: 
:: Starting full system upgrade...
resolving dependencies...

Spyhawk · 2011-08-10 17:24:10

Yes, it seems that using sudo with a timestamp value of zero calls sudo 3 times. You can bypass it by aliasing "alias pacaur='sudo pacaur'" in your .bashrc, so you'll have to type your password only once.

Edit: That's not a real solution... see a better way to bypass the extra password below

Last edited by Spyhawk (2011-08-11 12:40:44)

anonymous_user · 2011-08-10 17:32:33

Just a question, if you run "sudo pacaur" would that build the package with root privileges, or does pacaur bring down permissions when building?

splippity · 2011-08-10 17:39:00

anonymous_user wrote:

Just a question, if you run "sudo pacaur" would that build the package with root privileges, or does pacaur bring down permissions when building?

from my limited experience you would want to run it without sudo so that it will ask to elevate privileges to root when done building.
If not it spits out some error about needing to add some --(whatever) to override and let it run as root, but its not recommended.

Spyhawk · 2011-08-10 17:41:24

"fakeroot" is used in any case. Moreover, makepkg will warn you if you run it with the root account (not sudo) and you'll have to pass the additional option "--asroot" to make it works. But you would't try to use pacaur with the root account, do you? :]

Last edited by Spyhawk (2011-08-10 17:41:39)

splippity · 2011-08-10 18:01:00

Spyhawk wrote:

"fakeroot" is used in any case. Moreover, makepkg will warn you if you run it with the root account (not sudo) and you'll have to pass the additional option "--asroot" to make it works. But you would't try to use pacaur with the root account, do you? :]

In my experience when I have an aur package if I run something like sudo pacaur -Su (since I have yapan syncing all the time) it will spit the error but if I run just as pacaur -Su it will prompt for password when its done in fakeroot.

splippity · 2011-08-10 18:02:05

oh btw AWESOME program. dont stop working on it as bauerbill and clyde have with theirs.

Spyhawk · 2011-08-10 18:13:41

splippity wrote:

In my experience when I have an aur package if I run something like sudo pacaur -Su (since I have yapan syncing all the time) it will spit the error but if I run just as pacaur -Su it will prompt for password when its done in fakeroot.

Ah yeah, you're right. In any case, it works the same way as packer does (code handling sudo is the very same).

decibelmute · 2011-08-11 02:28:00

I'm a user of "timestamp_timeout=0" in sudoers, and I have it set up so that "sudo pacman" doesn't require a password for my user. I've noticed that pacaur (and packer as well, since they share code) call "sudo -v" to reset the timeout. If you're using a zero timestamp, however, this'll cause you to be prompted for a password every time, since the timestamp is always timed out.

I made a little workaround "sudo" script and put it in my path before the actual sudo binary:

#!/bin/sh
[ "x$*" = "x-v" ] && exit 0
/usr/bin/sudo "$@"

This makes all calls to "sudo -v" exit silently without prompting for the password. May be useful for other zero timestamppers out there

anonymous_user · 2011-08-11 03:53:00

I tried installing a package from the AUR and although it built, pacaur failed to install the package. Using 2.2.8 btw.

~ $ pacaur -y screenfetch-git
warning: xorg-xdpyinfo is available in extra

:: AUR package(s) to build: screenfetch-git

Proceed with installation? [Y/n] y
:: Building screenfetch-git package...
==> Determining latest git revision...
  -> Version found: 20110810
==> Making package: screenfetch-git 20110810-1 (Wed Aug 10 20:50:22 PDT 2011)
==> Checking runtime dependencies...
==> Installing missing dependencies...
resolving dependencies...
looking for inter-conflicts...

Targets (3): dmxproto-2.3.1-1 [0.00 MB]  libdmx-1.1.1-1 [0.03 MB]  xorg-xdpyinfo-1.2.0-2 [0.01 MB]

Total Download Size:    0.00 MB
Total Installed Size:   0.27 MB

Proceed with installation? [Y/n] 
(3/3) checking package integrity                                                                                               [############################################################################] 100%
(3/3) checking for file conflicts                                                                                              [############################################################################] 100%
(1/3) installing dmxproto                                                                                                      [############################################################################] 100%
(2/3) installing libdmx                                                                                                        [############################################################################] 100%
(3/3) installing xorg-xdpyinfo                                                                                                 [############################################################################] 100%
==> Checking buildtime dependencies...
==> Retrieving Sources...
==> Extracting Sources...
==> Starting build()...
==> Connecting to GIT server....
Cloning into screenfetch-dev...
remote: Counting objects: 598, done.
remote: Compressing objects: 100% (397/397), done.
remote: Total 598 (delta 296), reused 402 (delta 187)
Receiving objects: 100% (598/598), 1.47 MiB | 71 KiB/s, done.
Resolving deltas: 100% (296/296), done.
==> GIT checkout done or server timeout
==> Entering fakeroot environment...
==> Starting package_screenfetch-git()...
==> Starting make...
Cloning into /tmp/pacaurtmp-kevin/screenfetch-git/src/screenfetch-dev-build...
done.
==> Tidying install...
  -> Purging other files...
  -> Compressing man and info pages...
  -> Stripping unneeded symbols from binaries and libraries...
==> Creating package...
  -> Generating .PKGINFO file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: screenfetch-git 20110810-1 (Wed Aug 10 20:50:44 PDT 2011)
==> Installing screenfetch-git package group with pacman -U...
error: '/tmp/pacaurtmp-kevin/screenfetch-git/screenfetch-git-20110810-1-any.pkg.tar.xz': cannot open package file
==> WARNING: Failed to install built package(s).
:: Build directory cleaned

Spyhawk · 2011-08-11 07:12:19

decibelmute > Great workaround I'll see if there is a way to include it in pacaur script.
anonymous_user > The screenfetch-git package use an (ugly) workaround to "force" the package version (see line 33) in order to bypass the git version number, resulting in the failure of makepkg -sfi to install the package. I'd say that the pkgbuild needs to be corrected here. However, packer/clyde succeed to install the package due to their different design.

Last edited by Spyhawk (2011-08-11 07:16:08)

lucak3 · 2011-08-11 10:14:19

Spyhawk wrote:

anonymous_user > The screenfetch-git package use an (ugly) workaround to "force" the package version (see line 33) in order to bypass the git version number, resulting in the failure of makepkg -sfi to install the package. I'd say that the pkgbuild needs to be corrected here. However, packer/clyde succeed to install the package due to their different design.

Going from what i know, if makepkg can't build and install it, it's not supported.

decibelmute · 2011-08-17 22:06:46

@Spyhawk,

I think you could safely remove the call to "sudo -v" (on line 408), which would solve the problem for people with zero timeout. I don't really see why its necessary in this case (perhaps I'm overlooking something?), since calling sudo on the next line should refresh the timestamp anyway.

Spyhawk · 2011-08-18 07:42:46

decibelmute wrote:

@Spyhawk,
I think you could safely remove the call to "sudo -v" (on line 408), which would solve the problem for people with zero timeout. I don't really see why its necessary in this case (perhaps I'm overlooking something?), since calling sudo on the next line should refresh the timestamp anyway.

That makes sense. However, the user will still have to type his password twice (instead of three times), right?

decibelmute · 2011-08-19 06:23:31

Spyhawk wrote:

That makes sense. However, the user will still have to type his password twice (instead of three times), right?

The call to "sudo -l" doesn't ask for a password (it just checks if the user is allowed to run the command), so if "sudo -v" is removed it should only ask once per call to runasroot.
I've never had it ask me three times for a password, not sure why that would happen unless runasroot is being called more than once per package installed. My setup is a little unconventional though

Spyhawk · 2011-08-19 10:05:43

Dunno. When using timestamp=zero, it asks me the password 3 times (sudo -v, sudo - then sudo command), and twice with your modification (sudo -l and sudo command).

My test sudo config:

Defaults timestamp_timeout=0
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL

But I've to concede that I'm a sudo newbie, and never really cared about its config as I'm running a single user machine.

GSF1200S · 2011-08-21 06:57:03

Ive been happily using packer (as well as paktahn and cower on the side), but I have a few situations where I need to be able to manage pkgbuilds before the AUR wrapper passes commands to build them; pacaur does this. Pacaur does not check the IgnorePkg line in pacman.conf (for AUR packages- it DOES for repo packages.. well, pacman does), but ive since figured out that editing cower's config file takes care of this. Diffpac takes care of config merging. Brilliant

I have only one gripe with pacaur- sometimes I go to install a package to see how many dependencies it needs. In the case of packer, it right up front lists how many repo targets I have and how many AUR targets I have. Yaourt (which I only used to see its behavior- I stay away from it otherwise) at least passes on to pacman without a --noconfirm option, so if Im going to install 45 dependencies (or whatever), I can abort by hitting 'n.' pacaur does not allow this.

Example: I want to install package A, which has dependencies X, Y, and Z. I have dependencies X and Y installed, but need Z. Simple enough- pacaur tells me that dep Z is not found in the repos but does exist in the AUR, and has package A also listed to install. However, unbeknownst to me, dep Z has 45 dependencies (binary: part of Arch's repos) of its own- pacaur does not tell me this. I hit 'y' and bam- 45 dependencies are installed to satisfy the requirements for package Z, which in turn is necessary for package A (all of them I was unaware were going to be installed). There is no way for me to avoid this as the install command is passed with --noconfirm.

Im wondering if its possible to either list the dependencies of dependencies (and their dependencies, etc) straight away, OR if its possible maybe in the config file to have an option to have pacman prompt me before installing its packages (instead of passing the --noconfirm option, that way I can at least see there whether I want to follow through with all dependencies). With that, the fact this uses cower/expac, and the fantastic searching, I think I could replace packer with pacaur.

Spyhawk · 2011-08-21 08:59:38

GSF1200S wrote:

Ive been happily using packer (as well as paktahn and cower on the side), but I have a few situations where I need to be able to manage pkgbuilds before the AUR wrapper passes commands to build them; pacaur does this. Pacaur does not check the IgnorePkg line in pacman.conf (for AUR packages- it DOES for repo packages.. well, pacman does), but ive since figured out that editing cower's config file takes care of this. Diffpac takes care of config merging. Brilliant

AUR packages should also be taken into account when listed in pacman's IgnorePkg - otherwise you've found a bug. Could you provide me with a real life example?

GSF1200S wrote:

I have only one gripe with pacaur- sometimes I go to install a package to see how many dependencies it needs. In the case of packer, it right up front lists how many repo targets I have and how many AUR targets I have. Yaourt (which I only used to see its behavior- I stay away from it otherwise) at least passes on to pacman without a --noconfirm option, so if Im going to install 45 dependencies (or whatever), I can abort by hitting 'n.' pacaur does not allow this.
Example: I want to install package A, which has dependencies X, Y, and Z. I have dependencies X and Y installed, but need Z. Simple enough- pacaur tells me that dep Z is not found in the repos but does exist in the AUR, and has package A also listed to install. However, unbeknownst to me, dep Z has 45 dependencies (binary: part of Arch's repos) of its own- pacaur does not tell me this. I hit 'y' and bam- 45 dependencies are installed to satisfy the requirements for package Z, which in turn is necessary for package A (all of them I was unaware were going to be installed). There is no way for me to avoid this as the install command is passed with --noconfirm.
Im wondering if its possible to either list the dependencies of dependencies (and their dependencies, etc) straight away, OR if its possible maybe in the config file to have an option to have pacman prompt me before installing its packages (instead of passing the --noconfirm option, that way I can at least see there whether I want to follow through with all dependencies). With that, the fact this uses cower/expac, and the fantastic searching, I think I could replace packer with pacaur.

Dependencies are checked recursively, and all binary+aur deps are listed. If a binary deps (in repo) is already installed, it will not be shown at the install prompt. Again, could you provide me with a real life example, so I can debug it?

GSF1200S · 2011-08-21 12:11:19

Spyhawk wrote:

GSF1200S wrote:
Ive been happily using packer (as well as paktahn and cower on the side), but I have a few situations where I need to be able to manage pkgbuilds before the AUR wrapper passes commands to build them; pacaur does this. Pacaur does not check the IgnorePkg line in pacman.conf (for AUR packages- it DOES for repo packages.. well, pacman does), but ive since figured out that editing cower's config file takes care of this. Diffpac takes care of config merging. Brilliant
AUR packages should also be taken into account when listed in pacman's IgnorePkg - otherwise you've found a bug. Could you provide me with a real life example?

Indeed Ive found a bug- im an idiot. I went ahead and tried to replicate but it worked every time- I must have finger-f'd the package name or something. Sorry if you invested any time here

Spyhawk wrote:

GSF1200S wrote:
I have only one gripe with pacaur- sometimes I go to install a package to see how many dependencies it needs. In the case of packer, it right up front lists how many repo targets I have and how many AUR targets I have. Yaourt (which I only used to see its behavior- I stay away from it otherwise) at least passes on to pacman without a --noconfirm option, so if Im going to install 45 dependencies (or whatever), I can abort by hitting 'n.' pacaur does not allow this.
Example: I want to install package A, which has dependencies X, Y, and Z. I have dependencies X and Y installed, but need Z. Simple enough- pacaur tells me that dep Z is not found in the repos but does exist in the AUR, and has package A also listed to install. However, unbeknownst to me, dep Z has 45 dependencies (binary: part of Arch's repos) of its own- pacaur does not tell me this. I hit 'y' and bam- 45 dependencies are installed to satisfy the requirements for package Z, which in turn is necessary for package A (all of them I was unaware were going to be installed). There is no way for me to avoid this as the install command is passed with --noconfirm.
Im wondering if its possible to either list the dependencies of dependencies (and their dependencies, etc) straight away, OR if its possible maybe in the config file to have an option to have pacman prompt me before installing its packages (instead of passing the --noconfirm option, that way I can at least see there whether I want to follow through with all dependencies). With that, the fact this uses cower/expac, and the fantastic searching, I think I could replace packer with pacaur.
Dependencies are checked recursively, and all binary+aur deps are listed. If a binary deps (in repo) is already installed, it will not be shown at the install prompt. Again, could you provide me with a real life example, so I can debug it?

Heres a simple example where the package I wish to install is in the AUR, and both of its dependencies are in the arch repos:

[poeticrpm@geekdom ~]$ pacaur -S packer
:: Package(s) packer not found in repositories, trying aur...
warning: jshon is available in community

AUR Targets (1): packer

Proceed with installation? [Y/n] y
:: Edit packer PKGBUILD? [Y/n] n
:: Building packer package...
==> Determining latest git revision...
  -> Version found: 20110821
==> Making package: packer 20110821-1 (Sun Aug 21 06:58:22 CDT 2011)
==> Checking runtime dependencies...
==> Installing missing dependencies...
resolving dependencies...
looking for inter-conflicts...

Targets (2): jansson-2.1-1  jshon-20110803-1

Total Download Size:    0.00 MB
Total Installed Size:   0.15 MB

Proceed with installation? [Y/n] 
(2/2) checking package integrity                   [######################] 100%
(2/2) checking for file conflicts                  [######################] 100%
(1/2) installing jansson                           [######################] 100%
(2/2) installing jshon                             [######################] 100%
==> Checking buildtime dependencies...
==> Retrieving Sources...
==> Extracting Sources...
==> Entering fakeroot environment...
==> Starting build()...
==> Connecting to github GIT server....
Cloning into packer...
remote: Counting objects: 624, done.
remote: Compressing objects: 100% (290/290), done.
remote: Total 624 (delta 205), reused 589 (delta 184)
Receiving objects: 100% (624/624), 84.40 KiB, done.
Resolving deltas: 100% (205/205), done.
==> Tidying install...
  -> Purging other files...
  -> Compressing man and info pages...
  -> Stripping unneeded symbols from binaries and libraries...
==> Creating package...
  -> Generating .PKGINFO file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: packer 20110821-1 (Sun Aug 21 06:58:24 CDT 2011)
==> Installing package packer with pacman -U...
resolving dependencies...
looking for inter-conflicts...

Targets (1): packer-20110821-1

Total Download Size:    0.00 MB
Total Installed Size:   0.05 MB

Proceed with installation? [Y/n] 
(1/1) checking package integrity                   [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
(1/1) installing packer                            [######################] 100%
Optional dependencies for packer
    sudo: install and update packages as non-root
    customizepkg: apply customizepkg modifications
:: Build directory cleaned

As you can see, im trying to install packer here (as an example). The last time I intervene on the process is reviewing packer's pkgbuild, and due to:

warning: jshon is available in community

AUR Targets (1): packer

im aware of these two packages. However, jansson is also installed as a dependency, yet never listed by pacaur during the install process. Not a big deal here for sure, but it can be with bigger dependency lists.

Last edited by GSF1200S (2011-08-21 12:11:49)

Spyhawk · 2011-08-21 13:33:42

GSF1200S wrote:

Indeed Ive found a bug- im an idiot. I went ahead and tried to replicate but it worked every time- I must have finger-f'd the package name or something. Sorry if you invested any time here

No problem :]

GSF1200S wrote:

Heres a simple example where the package I wish to install is in the AUR, and both of its dependencies are in the arch repos:
[...]
As you can see, im trying to install packer here (as an example). The last time I intervene on the process is reviewing packer's pkgbuild, and due to:
warning: jshon is available in community

AUR Targets (1): packer
im aware of these two packages. However, jansson is also installed as a dependency, yet never listed by pacaur during the install process. Not a big deal here for sure, but it can be with bigger dependency lists.

Right, that is something that needs to be fixed. Somehow, I never encountered a similar situation (or never took close attention to it) and wrongly assumed that cower recursively checked binaries deps too.

GSF1200S · 2011-08-21 20:17:22

Spyhawk wrote:

GSF1200S wrote:
Indeed Ive found a bug- im an idiot. I went ahead and tried to replicate but it worked every time- I must have finger-f'd the package name or something. Sorry if you invested any time here
No problem :]
GSF1200S wrote:
Heres a simple example where the package I wish to install is in the AUR, and both of its dependencies are in the arch repos:
[...]
As you can see, im trying to install packer here (as an example). The last time I intervene on the process is reviewing packer's pkgbuild, and due to:
warning: jshon is available in community

AUR Targets (1): packer
im aware of these two packages. However, jansson is also installed as a dependency, yet never listed by pacaur during the install process. Not a big deal here for sure, but it can be with bigger dependency lists.
Right, that is something that needs to be fixed. Somehow, I never encountered a similar situation (or never took close attention to it) and wrongly assumed that cower recursively checked binaries deps too.

Actually, unless I misunderstand myself, wouldnt you be right about cower recursively finding dependencies? It seems the only issue is that pacaur isnt reporting what dependencies are going to be installed- cower retrieves all necessary deps and pacaur installs all the deps cower retrieves. I could be wrong here, but since the program builds and works as well as all dependencies being satisfied, I would think cower is doing its job.

As a work around, could pacaur simply parse the pkgbuild of each aur package (dependencies line) and then parse the dependencies of those packages etc? Really, the easiest solution to me seems to be just to allow a config option to bypass --noconfirm, as I at least then am still prompted before all the dependencies are installed. I understand that you care alot about workflow (makes sense), but thats why it would be an option. It certainly would perform better than yaourt in terms of workflow, and probably more on par with packer only WITH the ability to edit PKGBUILDs before installing. Thoughts?

Love how it works though. This seems to be a minor flaw..

Spyhawk · 2011-08-21 21:16:37

GSF1200S wrote:

Actually, unless I misunderstand myself, wouldnt you be right about cower recursively finding dependencies? It seems the only issue is that pacaur isnt reporting what dependencies are going to be installed- cower retrieves all necessary deps and pacaur installs all the deps cower retrieves. I could be wrong here, but since the program builds and works as well as all dependencies being satisfied, I would think cower is doing its job.

Cower does compute aur dependencies recursively, but it doesn't do it for binary deps of an aur package (try "cower -dd packer"). Of course that is not cower job, as it is strictly a minimal aur helper. Binary dependencies are solved using makepkg when installing compiled package. Unlike other aur helper, pacaur does not compute dependencies by itself but use cower/makepkg. The reason pacaur is slightly faster than other tools out there when parsing PKGBUILD in order to compute deps is that it (almost) doesn't do it :]

GSF1200S wrote:

As a work around, could pacaur simply parse the pkgbuild of each aur package (dependencies line) and then parse the dependencies of those packages etc? Really, the easiest solution to me seems to be just to allow a config option to bypass --noconfirm, as I at least then am still prompted before all the dependencies are installed. I understand that you care alot about workflow (makes sense), but thats why it would be an option. It certainly would perform better than yaourt in terms of workflow, and probably more on par with packer only WITH the ability to edit PKGBUILDs before installing. Thoughts?
Love how it works though. This seems to be a minor flaw..

Pacaur doesn't know what are the binary deps before installation, so it actually can't show any information about them. Parsing all pkgbuilds of binary deps is overkill, but I can use expac to retrieve this information. That would also be simpler that implementing another extra switch, and should work in any case with very minimal performance footprint. I'm working on that feature, but I need to find some free time to complete and test it (expect a few days as this is a minor flaw )

Arch Linux

#51 2011-08-09 16:10:59

Re: pacaur - an AUR helper that minimizes user interaction

#52 2011-08-09 19:29:25

Re: pacaur - an AUR helper that minimizes user interaction

#53 2011-08-09 20:42:26

Re: pacaur - an AUR helper that minimizes user interaction

#54 2011-08-09 22:37:36

Re: pacaur - an AUR helper that minimizes user interaction

#55 2011-08-10 17:24:10

Re: pacaur - an AUR helper that minimizes user interaction

#56 2011-08-10 17:32:33

Re: pacaur - an AUR helper that minimizes user interaction

#57 2011-08-10 17:39:00

Re: pacaur - an AUR helper that minimizes user interaction

#58 2011-08-10 17:41:24

Re: pacaur - an AUR helper that minimizes user interaction

#59 2011-08-10 18:01:00

Re: pacaur - an AUR helper that minimizes user interaction

#60 2011-08-10 18:02:05

Re: pacaur - an AUR helper that minimizes user interaction

#61 2011-08-10 18:13:41

Re: pacaur - an AUR helper that minimizes user interaction

#62 2011-08-11 02:28:00

Re: pacaur - an AUR helper that minimizes user interaction

#63 2011-08-11 03:53:00

Re: pacaur - an AUR helper that minimizes user interaction

#64 2011-08-11 07:12:19

Re: pacaur - an AUR helper that minimizes user interaction

#65 2011-08-11 10:14:19

Re: pacaur - an AUR helper that minimizes user interaction

#66 2011-08-17 22:06:46

Re: pacaur - an AUR helper that minimizes user interaction

#67 2011-08-18 07:42:46

Re: pacaur - an AUR helper that minimizes user interaction

#68 2011-08-19 06:23:31

Re: pacaur - an AUR helper that minimizes user interaction

#69 2011-08-19 10:05:43

Re: pacaur - an AUR helper that minimizes user interaction

#70 2011-08-21 06:57:03

Re: pacaur - an AUR helper that minimizes user interaction

#71 2011-08-21 08:59:38

Re: pacaur - an AUR helper that minimizes user interaction

#72 2011-08-21 12:11:19

Re: pacaur - an AUR helper that minimizes user interaction

#73 2011-08-21 13:33:42

Re: pacaur - an AUR helper that minimizes user interaction

#74 2011-08-21 20:17:22

Re: pacaur - an AUR helper that minimizes user interaction

#75 2011-08-21 21:16:37

Re: pacaur - an AUR helper that minimizes user interaction

Board footer