Package Details: packer 20150808-1

Git Clone URL: https://aur.archlinux.org/packer.git (read-only)
Package Base: packer
Description: Bash wrapper for pacman and aur
Upstream URL: http://github.com/keenerd/packer
Licenses: GPL3
Submitter: None
Maintainer: keenerd
Last Packager: keenerd
Votes: 750
Popularity: 5.332298
First Submitted: 2010-01-06 06:33
Last Updated: 2015-08-08 14:16

Dependencies (10)

Required by (3)

Sources (1)

Latest Comments

replabrobin commented on 2016-03-02 08:13

I had to make these changes in packer from packer-combined; not sure if that's all that's required

diff -r c903c022786d packer
--- a/packer Wed Jan 20 10:29:32 2016 +0000
+++ b/packer Wed Mar 02 08:13:02 2016 +0000
@@ -25,7 +25,7 @@
pacmanconf='/etc/pacman.conf'

AUR_DOMAIN="aur.archlinux.org"
-RPCURL="https://${AUR_DOMAIN}/rpc.php?type"
+RPCURL="https://${AUR_DOMAIN}/rpc.php?v=5&type"
PKGURL="https://${AUR_DOMAIN}"

if [[ -t 1 && ! $COLOR = "NO" ]]; then
@@ -265,7 +265,7 @@

pkglink() {
rpcinfo $1
- echo "${PKGURL}$(jshon -Q -e results -e URLPath -u < "$tmpdir/$1.info")"
+ echo "${PKGURL}$(jshon -Q -e results -e 0 -e URLPath -u < "$tmpdir/$1.info")"
}

# downloads pkgbuild ($1), edits if $2 is set
@@ -296,7 +296,8 @@

isoutofdate() {
rpcinfo "$1"
- [[ "$(jshon -Q -e results -e OutOfDate -u < "$tmpdir/$1.info")" != "0" ]]
+ local ood="$(jshon -Q -e results -e 0 -e OutOfDate -u < "$tmpdir/$1.info")"
+ [[ "${ood}" != "0" && "${ood}" != null ]]
}

# $1 is prompt, $2 is file
@@ -543,7 +544,7 @@
}

run_quick_check() {
- bigurl="https://${AUR_DOMAIN}/rpc.php?type=multiinfo"
+ bigurl="https://${AUR_DOMAIN}/rpc.php?v=5&type=multiinfo"
for p in $(pacman -Qqm); do
bigurl="$bigurl&arg\[\]=$p"
done

tom.swartz07 commented on 2016-03-01 13:54

Just confirming as well:

packer -S packer
Package `packer' does not exist.

binhex commented on 2016-02-29 15:55

yep packer looks broken for me too, attempted compile of rutorrent returns this:-

[root]# packer -S rutorrent
Package `rutorrent' does not exist.

seen the same for rtorrent-color

trizen commented on 2016-02-29 08:07

"v=5" is required to be added to the "RPCURL" constant, like this:

RPCURL="https://aur.archlinux.org/rpc.php?v=5&type"

Although, I'm afraid more changes are required to make it work correctly in all cases. However, until packer is fixed, a lightweight alternative, written in Perl and easy to use, would be trizen (https://aur.archlinux.org/packages/trizen/) which provides, basically, all the functionality found in packer.

antony commented on 2016-02-29 07:20

Seems to not be able to find any AUR packages anymore, even after switching to package-query-git as suggested in the comments for yaourt.

rpodgorny commented on 2016-02-02 22:09

i suspect this should be renamed to packer-git according to https://wiki.archlinux.org/index.php/VCS_package_guidelines

Roken commented on 2015-08-09 15:48

It did update itself - everything did. It just spammed me first, until packer had updated, then the spamming stopped. That's why I suggest that packer should prioritise itself. It's not for broken functionality, it's for panicking humans.

keenerd commented on 2015-08-09 12:42

Packer wouldn't have been able to update itself anyway, in your case.

Roken commented on 2015-08-09 08:05

I've just had a hell of a time trying to debug AUR updates using packer spamming the console with error messages suggesting that an HTML document had been downloaded instead of the PKGBUILD. After a while, along came an update to packer which fixed it.

Is there a way you can force packer to update first when it's being updated at the same time as other packages?

Xavion commented on 2015-06-22 20:34

Use my "packer-color" package instead. It's been modified to work with AUR v4.

Zeth commented on 2015-06-22 09:55

This packer version still uses old aur.archlinux.org . Please update it to aur4.

AsavarTzeth commented on 2015-01-13 11:18

Is python-packagekit/python2-package kit a dependency for packer now? I don't know why, but while upgrading AUR packages it aborted every single one, complaining that it could not find the mentioned packages.

I installed them and now things work again. Any idea why?

neonkowy commented on 2014-12-29 11:03

oh, nevermind, it's already open upstream - https://github.com/keenerd/packer/issues/131

neonkowy commented on 2014-12-29 11:01

Hi,

after today update i cannot make any packages using packer:

makepkg complains about unknown option --asroot - probably something changed in latest pacman.

# packer -Syu

Aur Targets (3): perl-unicode-string customizepkg imapsync

Proceed with installation? [Y/n] y
Edit perl-unicode-string PKGBUILD with $EDITOR? [Y/n] n
makepkg: nieprawidłowa opcja '--asroot'
The build failed.
Edit customizepkg PKGBUILD with $EDITOR? [Y/n] n
makepkg: nieprawidłowa opcja '--asroot'
The build failed.
Dependencies for `imapsync' are not met, not building...
local database is up to date

anubis2591 commented on 2014-12-17 02:47

Sorry, I marked this as out of date since I didn't get any notification within packer that it was updated (maybe git AUR package versions are a little bit broken in packman/packer). And packer/pacman said that the version I had was the same as the current version (which is curious since the version numbers are clearly not the same).

If anyone is seeing the "could not find or read package" error, just update packer though its self or manually.

anubis2591 commented on 2014-12-17 02:34

@shutdown-hnow: Yeah I've had the same issue, but updating packer fixed it.

I flagged this as out of date because there must be other users like myself who expected packer to update its self to reflect the change in package format. I realize maintaining an AUR package and especially a git package is hard (I've maintained a package in the past) but this major change needed a version bump so users like myself could expect continued functionality. I just got "could not find or read package" and was perplexed by the fact that this package was marked up to date.

Thanks in advance, and I apologize on the lateness of this comment, I know the package format change happened a while ago, I just looked into it now.

shutdown-hnow commented on 2014-12-15 02:05

These "could not find or read package" errors are really getting to me. Try installing this little gem without softly weeping: "packer -S --noedit --noconfirm steam-native".

adirat commented on 2014-11-14 18:58

After the ca-certificates-utils package update, packer fails with error: "SSL certificate problem: unable to get local issuer certificate".

From the update info:

4. In programs that have settings like "ca_dir = /etc/ssl/certs",
change them to "ca_file = /etc/ssl/certs/ca-certificates.crt"

tom.swartz07 commented on 2014-11-04 00:09

I took a peek at the source code.

It seems that packer is doing a lot of error checking that might not be necessary.

I agree with ultrviolet's comment- just pass any unknown flag directly to the wrapped pacman instance, and let pacman's error handling sort it out.

This will not only keep usability between the two applications (practically no learning curve), but will save keenerd (or whomever the package maintainer might be in the future) from having to update code for new/removed features.

Are you up for some pull requests on GH?

ultraviolet commented on 2014-11-03 23:58

seconded. i'd actually really appreciate the ability to pass packer any pacman option... i often type things like "packer -Qo /usr/bin/fileicareabout" and packer just laughs at me and exits. it's really annoying to have to then retype my command as "sudo pacman ..." every single time i make this mistake. it certainly wouldn't be hard to have packer pass any unrecognised option to pacman, though the auto-su(do) might need some tweaking so as to not do it as root unless needed.

gummiflummi commented on 2014-11-03 13:17

The flag --needed from pacman and yaourt would be really nice and helpful (especially for scripts).

gummiflummi commented on 2014-11-03 10:51

The flag --needed from pacman and yaourt would be really nice and helpfull (especially for scripts).

keenerd commented on 2014-08-17 16:56

Fixed.

qmega commented on 2014-08-17 16:19

It's not only epochs that break it. Anything with a pkgver() also has the opportunity to break, such as git packages.

I think chasing the name of the package is a losing battle. IMO it'd be better to use makepkg -i. Is passing options to pacman the only reason for doing it manually? If so, maybe we could use a simple wrapper for pacman that adds options from an environment variable and pass that to makepkg as $PACMAN. Feels a little dirty, but idk what else to do.

As a side note, why is it never appropriate for an AUR package to have an epoch? What if the versioning scheme changes? Sure, it's rarely necessary for any package to have an epoch, but why would AUR packages be any less qualified?

keenerd commented on 2014-08-17 15:39

dvk: It is not the colon, it is the epoch. Which is really dumb, there is no reason to ever use an epoch for an AUR package.

bluerider commented on 2014-08-17 15:30

@qmega: I think we should just set up key pairs of pkgname and pkgver and install based on that.

brittyazel commented on 2014-08-16 21:37

Since the update to packer a week or so ago, I am getting a lot of "could not find or read package" on ever second or third package I try to install. Trying to install the package a second time usually fixes this issue. It is just annoying that I have to install everything 2 times to get it to stick.

dvk commented on 2014-08-13 01:13

error: 'chromium-pepper-flash-36.0.1985.143-1*.pkg.tar.xz': could not find or read package

Actual name of the package is chromium-pepper-flash-1:14.0.0.177-1-x86_64.pkg.tar.xz
So, packer does not accept a colon in the package name.
# pacman -U chromium-pepper-flash-1\:14.0.0.177-1-x86_64.pkg.tar.xz worked ok.

qmega commented on 2014-08-11 21:16

The issue is that the package_whatever functions for the chromium plugins change pkgver and pkgrel. I can't think of a clean solution for this. The only things I can think of so far would be to duplicate a bunch of makepkg functionality and run the package functions itself, or else try to parse them somehow. Both of those sound pretty nasty. Alternatively, it could just use makepkg -i instead of its custom logic, but then it'd lose the ability to pass options to pacman, which I assume is why the custom logic is there in the first place.

replabrobin commented on 2014-08-11 15:10

I suspect this might be a version number issue. When I look in the packerbuild folder I see this

# ls /tmp/packerbuild-1000/chromium-pepper-flash/chromium-pepper-flash
chromium-libpdf-1:36.0.1985.125-1-i686.pkg.tar.xz license.html
chromium-libpdf.install pkg
chromium-pepper-flash-1:14.0.0.145-1-i686.pkg.tar.xz PKGBUILD
chromium-pepper-flash.install src
google-chrome-stable-36.0.1985.125-1.i386.rpm

ie the versions are ...-125-1-... not ...125-2-.... as in my error message.

replabrobin commented on 2014-08-11 15:06

I'm seeing this error with the chromium-pepper-flash package
[code]
$ /bin/packer -S chromium-pepper-flash

Aur Targets (1): chromium-pepper-flash

Proceed with installation? [Y/n]

Edit chromium-pepper-flash PKGBUILD with $EDITOR? [Y/n] n
==> Making package: chromium-plugins 36.0.1985.125-2 (Mon 11 Aug 15:58:19 BST 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Downloading license.html...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 265 100 265 0 0 4769 0 --:--:-- --:--:-- --:--:-- 4818
0 0 0 52500 0 0 176k 0 --:--:-- --:--:-- --:--:-- 176k
-> Downloading google-chrome-stable-36.0.1985.125-1.i386.rpm...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 58.0M 100 58.0M 0 0 458k 0 0:02:09 0:02:09 --:--:-- 460k
==> Validating source files with sha1sums...
license.html ... Skipped
google-chrome-stable-36.0.1985.125-1.i386.rpm ... Passed
==> Extracting sources...
-> Extracting google-chrome-stable-36.0.1985.125-1.i386.rpm with bsdtar
==> Entering fakeroot environment...
==> Starting package_chromium-libpdf()...
==> Tidying install...
-> Purging unwanted files...
-> Removing libtool files...
-> Removing static library files...
-> Compressing man and info pages...
-> Stripping unneeded symbols from binaries and libraries...
==> Creating package "chromium-libpdf"...
........
==> Starting package_chromium-pepper-flash()...
==> Tidying install...
-> Purging unwanted files...
.........
==> Creating package "chromium-pepper-flash"...
-> Generating .PKGINFO file...
-> Adding install file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: chromium-plugins 36.0.1985.125-2 (Mon 11 Aug 16:01:32 BST 2014)
loading packages...
error: 'chromium-libpdf-36.0.1985.125-2*.pkg.tar.xz': could not find or read package
error: 'chromium-pepper-flash-36.0.1985.125-2*.pkg.tar.xz': could not find or read package
[/code]

keenerd commented on 2014-08-10 19:00

Fixed.

keenerd commented on 2014-08-09 21:18

Actual issue. First I had heard of it, will try to fix it this weekend.

allevil669 commented on 2014-08-09 19:45

packer seems to be having trouble with AUR split packages, like https://aur.archlinux.org/packages/chromium-pepper-flash/ it will only install/upgrade one of the packages (chromium-libpdf in this case), and not build/install the other (chromium-pepper-flash in this case).

Am I passing an incorrect flag to packer? Or is this an actual issue?

kazufukurou commented on 2014-08-08 14:32

Oh, I was going to comment to eclim-git package but though maybe I use packer wrong and mixed it up. Thanks for pointing this out.

keenerd commented on 2014-08-08 14:00

kazufukurou: That really sounds like a problem with the eclim-git package.

And never run packer (or even makepkg) with root privileges! I can't revoke your linux license but I am going to glare at you really hard. Please read
https://wiki.archlinux.org/index.php/AUR
https://wiki.archlinux.org/index.php/Makepkg
https://wiki.archlinux.org/index.php/Pkgbuild

kazufukurou commented on 2014-08-08 13:39

I'm getting build errors. Eclipse 4.3.2-2
sudo packer -S eclim-git
BUILD FAILED
/tmp/packerbuild-0/eclim-git/eclim-git/src/eclim-build/build.xml:26: The following error occurred while executing this line:
/tmp/packerbuild-0/eclim-git/eclim-git/src/eclim-build/build.xml:151: : /home/root/.eclipse does not exist.

packer -S eclim-git
[javac] /tmp/packerbuild-1000/eclim-git/eclim-git/src/eclim-build/org.eclim.cdt/java/org/eclim/plugin/cdt/command/search/SearchCommand.java:257: error: cannot find symbol
[javac] IIndexManager.ADD_EXTENSION_FRAGMENTS_NAVIGATION);
[javac] ^
[javac] symbol: variable ADD_EXTENSION_FRAGMENTS_NAVIGATION
[javac] location: interface IIndexManager
[javac] /tmp/packerbuild-1000/eclim-git/eclim-git/src/eclim-build/org.eclim.cdt/java/org/eclim/plugin/cdt/command/search/SearchCommand.java:560: error: method does not override or implement a method from a supertype
[javac] @Override
[javac] ^
[javac] Note: /tmp/packerbuild-1000/eclim-git/eclim-git/src/eclim-build/org.eclim.cdt/java/org/eclim/plugin/cdt/command/search/SearchCommand.java uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 2 errors

BUILD FAILED
/tmp/packerbuild-1000/eclim-git/eclim-git/src/eclim-build/build.xml:26: The following error occurred while executing this line:
/tmp/packerbuild-1000/eclim-git/eclim-git/src/eclim-build/build.xml:151: : Compile failed; see the compiler error output for details.

tom.swartz07 commented on 2013-12-02 13:17

I can confirm that p91paul's fix works.

I was unable to download the update until making this change to the PKGBUILD.

p91paul commented on 2013-12-01 22:34

I don't know if it's related to my firewall or whatever, but I'm not able to download packer sources with the current PKGBUILD. Changing source from
git://github.com/keenerd/packer.git
to
git+https://github.com/keenerd/packer.git
fixes the issue, and should work for anybody. Thanks!

spsf64 commented on 2013-11-01 18:32

@keenerd: Thanks for the latest update!

keenerd commented on 2013-10-03 00:29

No. Please actually update packer.

bluerider commented on 2013-10-02 16:31

Running packer --quickcheck requires expac. Please add it to the depends array.

Anonymous comment on 2013-09-04 00:55

Please use a dynamic pkgver() function to properly resolve version: https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines#Git

falmp commented on 2013-08-23 10:30

It's sad keenerd doesn't accept users pull requests, there are a lot of improvements people contributed on Github.

falmp commented on 2013-08-23 10:30

It's bad keenerd doesn't accept users pull requests, there are a lot of improvements people contributed on Github.

leodag commented on 2013-07-16 22:42

lspci: use 'makepkg -s' for auto dependency resolving.

arielp commented on 2013-06-15 09:10

Here is an updated PKGBUILD.

-pacman 4.1 VCS features
-added package() function

http://ix.io/6aV

hav3lock commented on 2013-05-05 02:10

==> WARNING: Using a PKGBUILD without a package() function is deprecated.

hav3lock commented on 2013-05-05 00:18

I keep getting:

Dependencies for `automake-1.11' are not met, not building...
Dependencies for `crimson' are not met, not building...
Dependencies for `downgrader' are not met, not building...
Dependencies for `lib32-libsoup' are not met, not building...
Dependencies for `lib32-libxp' are not met, not building...

and I know that at least the first two build and install just fine with pacman--I maintain them.

hav3lock commented on 2013-05-05 00:18

I keep getting:

Dependencies for `automake-1.11' are not met, not building...
Dependencies for `crimson' are not met, not building...
Dependencies for `downgrader' are not met, not building...
Dependencies for `lib32-libsoup' are not met, not building...
Dependencies for `lib32-libxp' are not met, not building...

x33a commented on 2013-05-03 06:09

Is packer detecting updates for the updated devel packages (using pkgver()) for you guys?

For example, I have a package:

https://aur.archlinux.org/packages.php?O=0&K=dex%2Deditor&do_Search=Go

And packer is not showing any update for it with either -Syu or -Syu --devel

Mr Green commented on 2013-05-02 06:15

@pnorcks I simply went by guide in wiki, yes an increasing version number or possibly date reference would be better....

pnorcks commented on 2013-05-02 03:28

Mr Green: I would prefer the no-annotated-tag example for pkgver() so that there is always an increasing version number:

pkgver() {
cd $_gitname
echo $(git rev-list --count master).$(git rev-parse --short master)
}

Mr Green commented on 2013-05-01 14:57

This is my attempt at creating new pkgbuild

# Maintainer: Kyle Keen <keenerd@gmail.com>
# Contributor: Mr Green <mrgreen@archbang.org>

pkgname=packer
_gitname=packer
pkgver=cfc8648
pkgrel=1
pkgdesc="Bash wrapper for pacman and aur"
arch=('any')
url="http://github.com/keenerd/packer"
license=('GPL')
depends=('grep' 'sed' 'bash' 'curl' 'pacman' 'jshon')
optdepends=('sudo: install and update packages as non-root' 'customizepkg: apply customizepkg modifications')
_gitroot='https://github.com/keenerd/packer.git'
_gitname='packer'
makedepends=('git')
source=('git://github.com/keenerd/packer.git')
md5sums=('SKIP')

pkgver() {
cd $_gitname
git describe --always | sed 's|-|.|g'
}


package() {
cd $_gitname
mkdir -p "$pkgdir/usr/bin/"
mkdir -p "$pkgdir/usr/share/man/man8/"
install -m 755 packer "$pkgdir/usr/bin/packer"
install -m 644 packer.8 "$pkgdir/usr/share/man/man8/packer.8"
}

innn commented on 2013-04-23 04:41

@bluerider
i get two passowrd requests right after build is done and wants to install the package

mloskot commented on 2013-04-19 22:58

Since this commit [1], packer has got expac as new dependency

[1] https://github.com/keenerd/packer/commit/cfc864878f485feeaf58c0c873d4e1ce8934fa12

workdowg commented on 2013-04-14 13:28

I don't know if this should make this "out of date": warning:
config file /etc/pacman.conf, line 19: directive 'SyncFirst' in section 'options' not recognized.

pezz commented on 2013-04-13 08:17

FYI - you don't need pacman-color any more.

Pacman 4.1.0 supports it out of the box, just un-comment "Color" in /etc/pacman.conf

jeancf commented on 2013-04-13 07:31

I found a solution to the problem below. I had a stray "export PACMAN=pacman-color" in my /etc/bash.bashrc. Removing it made the error disappear.

jeancf commented on 2013-04-12 08:09

Since my last update a few days ago I notice that pacman-color has been removed from my system (I read that it has been integrated into pacman). The problem is that when I run packer I now get an error:

jeancf@server ~ $ packer -Syu
root Password:
bash: pacman-color: command not found
:: Synchronizing aur database...
aur 14 14 [#######################################################################################################]100%
:: Starting full aur upgrade...

Aur Targets (3): aurvote cloog-ppl dar
Pacman Targets (1): doxygen

Proceed with installation? [Y/n]

root Password:
bash: pacman-color: command not found
Installation failed.

How can I fix this?

Gilrain commented on 2013-04-08 09:22

Here's a leaner PKGBUILD to use the new functionalities introduced by pacman 4.1: http://pastebin.com/4hGnusX7
I also took the liberty of merging the mkdir and install lines, as well as changing the license to 'GPL3' to better reflect the statement in packer header ('GPL' referring to v2 of the license).

Xavion commented on 2013-04-06 22:21

Have you thought about merging my "packer-color" package into this one? The previous maintainer wasn't interested, but maybe you can see the benefits. It's probably a good idea now that "pacman-color" has been merged into "pacman".

keenerd commented on 2013-03-12 12:01

Bluerider: Hardcoding '/var/cache/pacman/pkg/' is a bigger problem than making a tireless computer do extra work.

Let me play with the whole thing a bit.

bluerider commented on 2013-03-11 20:11

@innn : When do you get two password requests?

bluerider commented on 2013-03-11 20:11

@grawity : while that method works, it requires a pipe (it's two operations vs. one). I've kept the "cp" method.

innn commented on 2013-03-11 15:01

please how to reduce number of password request from 2 to just 1?

grawity commented on 2013-03-10 11:59

The file:// method can work. (It's still silly.)

printf 'file://%s\n' /full/path/to/$pkgname-*$PKGEXT | runasroot $PACMAN -U -

bluerider commented on 2013-02-04 01:23

Scratch that, the file:// method doesn't seem to work, since the wild card character "*" doesn't get resolved

Adding above lines 317 and 318 should work:
runasroot cp $pkgname-*$PKGEXT /var/cache/pacman/pkg/

Arch developer with head up his ass refuses to change "-U" behavior, says it's "silly", so storing packer packages in pacman cache will require the above code.

bluerider commented on 2013-02-04 00:02

Scratch that, the file:// method doesn't seem to work, since the wild card character "*" doesn't get resolved

Adding above lines 317 and 318 should work:
runasroot cp $pkgname-*$PKGEXT /var/cache/pacman/pkg/

bluerider commented on 2013-02-04 00:02

Scratch that, the file:// method doesn't seem to work, since the wild card character "*" doesn't get resolved

Adding above lines 317 and 318 shoudl work:
runasroot cp $pkgname-*$PKGEXT /var/cache/pacman/pkg/

bluerider commented on 2013-02-03 23:51

Scratch that, the file:// method doesn't seem to work, since the wild card character "*" doesn't get resolved

bluerider commented on 2013-02-03 23:51

Scratch that, the file:// method doesn't seem to work, since the wild card character "*" doesn't get sorted out

bluerider commented on 2013-02-03 23:06

I noticed that packages installed with packer don't appear in /var/cache/pacman/pkg. This is due to the "-U" feature in pacman not storing the package in its cache. Having a copy of the compiled package would be useful for downgrading custom packages. I filed a feature request to accomplish this : https://bugs.archlinux.org/task/33693

As listed on the bug report, an alternative is to modify the following lines in packer:
Line 317 :: runasroot $PACMAN ${PACOPTS[@]} --asdeps -U file://$pkgname-*$PKGEXT
Line 318 :: runasroot $PACMAN ${PACOPTS[@]} --asdeps -U file://$pkgname-*$PKGEXT

bluerider commented on 2013-02-03 23:01

I noticed that packages installed with packer don't appear in /var/cache/pacman/pkg. Having the custom built packages copied to this directory would assist in downgrading user-built AUR package. To accomplish this feature : one just needs to add "runasroot cp $pkgname-*$PKGEXT /var/cache/pacman/pkg/" above lines 317 and 319.

I've already filed a feature request for "-U" in pacman to accomplish this : https://bugs.archlinux.org/task/33693.

As listed on the bug report, an alternative is to modify the following lines in packer:
Line 317 :: runasroot $PACMAN ${PACOPTS[@]} --asdeps -U file://$pkgname-*$PKGEXT
Line 318 :: runasroot $PACMAN ${PACOPTS[@]} --asdeps -U file://$pkgname-*$PKGEXT

bluerider commented on 2013-02-03 21:46

An alternative would to just edit $PKGDEST of /etc/makepkg.conf to include that path.

bluerider commented on 2013-02-03 21:07

I noticed that packages installed with packer don't appear in /var/cache/pacman/pkg. Having the custom built packages copied to this directory would assist in downgrading user-built AUR package. To accomplish this feature : one just needs to add "runasroot cp $pkgname-*$PKGEXT /var/cache/pacman/pkg/" above lines 317 and 319.

bluerider commented on 2013-02-03 20:33

I noticed that packages installed with packer don't appear in /var/cache/pacman/pkg. I was wondering if you could include a feature to have packages placed there as well, so a record of AUR packages can also be kept (in case an upgrade breaks something).

keenerd commented on 2012-12-16 12:25

klim8d, oddstr13: Fixed.

klim8d commented on 2012-12-16 12:01

keenerd:
Yes, that tweak fixed it.

klim8d commented on 2012-12-16 11:54

@keenerd:
At line 333 at http://pastebin.com/RdGitPav, it seems like the package jdk are changing the PKGEXT. Could this be the issue?

keenerd commented on 2012-12-16 11:52

klim8d:
Does the sourcemakepkgconf tweak fix this for you?

klim8d commented on 2012-12-16 11:47

@keenerd:
At line 333 at http://pastebin.com/RdGitPav, it seems like the package jdk are changing the PKGEXT. Could this be the issue?

klim8d commented on 2012-12-16 11:43

@keenerd:
I have not made anychanges to the makepkg.conf (http://pastebin.com/t7SeJSEy), and I don't have anything that changes the PKGEXT.

oddstr13 commented on 2012-12-16 03:28

This seems to be the error message you get when you try to install a package with packer, that does not exist.
Is allso the case for dependencies. (the "depends" line in PKGBUILD).

This is a bug in packer, it should check if packages exist instead of assuming it does. Should also report missing/unknown dependencies.

-----------

┌(oddstr13@oddlaptop-Arch)─(✗)─(05:16 AM Sun Dec 16)
└─(~)─(14 files, 92Kb)─> sudo pacman -S yes-there-really-is-no-such-package
error: target not found: yes-there-really-is-no-such-package

┌(oddstr13@oddlaptop-Arch)─(✗)─(05:16 AM Sun Dec 16)
└─(~)─(14 files, 92Kb)─> sudo packer -S yes-there-really-is-no-such-package

Aur Targets (1): yes-there-really-is-no-such-package

Proceed with installation? [Y/n] y

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
No PKGBUILD found in directory.

keenerd commented on 2012-12-16 00:19

Other thing to look for would be either a ~/.makepkg.conf or a /root/.makepkg.conf.

Since this happened during a -Syu, the PKGEXT could have been changed by an earlier pkgbuild. Packer loads makepkg.conf once at the beginning, so any bad pkgbuild could break it.

On line 284 of packer, in the aurinstall() function, try inserting
sourcemakepkgconf
on its own line.

keenerd commented on 2012-12-16 00:10

Other thing to look for would be either a ~/.makepkg.conf or a /root/.makepkg.conf

keenerd commented on 2012-12-16 00:01

Looks like that comes from line 329,
runasroot $PACMAN ${PACOPTS[@]} -U $pkgname-*$PKGEXT

So, somewhere $PKGEXT is changed to ".pkg.tar". Normally this is set in /etc/makepkg.conf, and normally it is ".pkg.tar.xz". Makepkg built a pkg.tar.xz, so I am not sure what is going on there.

It kind of looks like a broken config somewhere on your end. Do you have anything silly like a .bashrc that changes PKGEXT?

klim8d commented on 2012-12-15 17:01

@keenerd:

I've made a pastebin:
command: bash -x /usr/bin/packer -Syu --auronly --noedit --noconfirm
output: http://pastebin.com/RdGitPav

It seems like it's trying to look for dropbox-*.pkg.tar, but nothing is named like that.
Here is the output of the dropbox build folder:
┌─( klim ) - ( ~ )
└─> ls -l /tmp/packerbuild-1000/dropbox/dropbox
total 49372
drwxr-xr-x 4 klim users 100 Dec 15 17:53 pkg
drwxr-xr-x 3 klim users 160 Dec 15 17:53 src
-rw-r--r-- 1 klim users 1866 Dec 12 15:31 PKGBUILD
-rw-r--r-- 1 klim users 30910724 Dec 15 17:54 dropbox-1.6.4-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 klim users 19604277 Dec 15 17:53 dropbox-lnx.x86_64-1.6.4.tar.gz
-rw-r--r-- 1 klim users 271 Aug 17 11:27 dropbox.desktop
-rw-r--r-- 1 klim users 9896 May 29 2011 dropbox.png
-rw-r--r-- 1 klim users 229 Nov 21 09:19 dropbox.service
-rw-r--r-- 1 klim users 12278 Sep 5 2011 terms.txt

keenerd commented on 2012-12-14 23:30

jarav, klim8d:

I can't reproduce the problem, so I can't fit it. I'll gladly merge any patches you come up with. Some debugging traces would be helpful though.

bash -x /usr/bin/packer -S ...

And put all the output up on a paste site somewhere.

Anonymous comment on 2012-12-14 21:55

Any fix for the error reported by klim8d yet? I am having to go to the packerbuild directory and manually install the package.

Anonymous comment on 2012-12-08 17:55

I get the same error. It seems to be happening most when trying to do
packer -Syu

and not

packer -S <package>

klim8d commented on 2012-12-01 17:30

This error happens for all packages, every time, I'm trying to upgrade from AUR. I'm using the latest version of packer.

==> Finished making: spideroak 4.8.1-1 (Sat Dec 1 18:28:41 CET 2012)
loading packages...
error: 'spideroak-*.pkg.tar': could not find or read package
local database is up to date

x33a commented on 2012-11-27 05:17

Since keenerd has taken over the maintainership of packer, this change is needed:

_gitroot='https://github.com/keenerd/packer.git'

bruenig's repo is asking for a password anyway.

mueslo commented on 2012-11-20 20:32

I too have the same problem as hydn.

@arthurdent: I already have multilib enabled, so that's no help.

packer -S *anything* doesn't work. Not even packer -S packer. It doesn't even realize that some packages don't exist:

[user@hostname ~]$ sudo packer -S ifartinyourgeneraldirection

Aur Targets (1): ifartinyourgeneraldirection

Proceed with installation? [Y/n]

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
/usr/bin/packer: line 271: cd: ifartinyourgeneraldirection: No such file or directory
No PKGBUILD found in directory.

Manually reinstalling packer fixed it.

mueslo commented on 2012-11-20 20:20

I too have the same problem as hydn.

@arthurdent: I already have multilib enabled, so that's no help.

packer -S *anything* doesn't work. Not even packer -S packer. It doesn't even realize that some packages don't exist:

[user@hostname ~]$ sudo packer -S ifartinyourgeneraldirection

Aur Targets (1): ifartinyourgeneraldirection

Proceed with installation? [Y/n]

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
/usr/bin/packer: line 271: cd: ifartinyourgeneraldirection: No such file or directory
No PKGBUILD found in directory.

Anonymous comment on 2012-11-14 20:19

I was having the same problem as hadyn and it turned out I needed to enable multilib in my pacman.conf

Mr Green commented on 2012-11-10 11:58

It might be a problem with curl not finding the url correctly..

Mr Green commented on 2012-11-10 11:56

Been having similar problems, started happening soon after AUR returned back online about a week ago. It might be that wget is not finding tarball url correctly. Not able to check script at the moment as I am away. Have a feeling it will be a simple fix.

tom.swartz07 commented on 2012-11-09 21:50

@Haydn - are you behind a proxy or firewall?

I had this issue at work, and the content filter was blocking the download location.

Can you try it on an open network?

Anonymous comment on 2012-11-09 21:20

I was told to report this here.

Problem:
I've been getting this for random packages. So I've been manually installing stuff. But I noticed this again when trying to add skype to pidgin.
Output:
sudo packer -S skype4pidgin

Aur Targets (2): skype skype4pidgin

Proceed with installation? [Y/n] y

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
No PKGBUILD found in directory.

Threads I've tried via Google:
http://forum.manjaro.org/index.php?topic=750.0
http://www.linuxforums.org/forum/instal … ormat.html
https://bbs.archlinux.org/viewtopic.php?id=98278

Current Arch forums support thread:
https://bbs.archlinux.org/viewtopic.php?id=152605

dcelasun commented on 2012-11-05 09:26

@sknd: Same problem here.

@bruenig: Any ideas?

sknd commented on 2012-11-04 14:40

i'm unable to upgrade anything from aur, when doing packer -Syu

it says (for example): error: 'dropbox-*.pkg.tar': could not find or read package

looks like it's looking for pkg.tar, instead of pkg.tar.xz
i checked makepkg.conf, looks ok: PKGEXT='.pkg.tar.xz'

any ideas?

Anonymous comment on 2012-10-29 14:54

AUR only supports https from now, will packer get an update for this?

Anonymous comment on 2012-10-29 14:53

AUR

tom.swartz07 commented on 2012-10-19 22:56

For some reason, when I run packer now, it's asking for my root password 3 times.

Is this happening with anyone else?

cippaciong commented on 2012-10-15 14:12

Dunno why but if I run "packer -Syu --devel" on my laptop the process hangs at:
":: Synchronizing aur database...
aur 34 34 [########################################################################################################################################]100%"
If I run the program on my netbook or desktop everything works.

cippaciong commented on 2012-10-15 14:03

Dunno why but if I run "packer -Syu --devel" on my laptop the process hangs at:
":: Synchronizing aur database...
aur 34 34 [########################################################################################################################################]100%"
If I run the program on my netbook or desktop everything works.

Shark commented on 2012-08-29 16:27

I have the same problem as @hyness. I don't think that the issue was before (i don't know exactly when appeared if at all) but it is really annoying that you cannot edit PKGBUILD before downloading. Any suggestions/solutions?
Thank you very much!

Jristz commented on 2012-06-25 15:23

+1 to hyness
MANY packages spacialy -devel or non-versioning packages can have issues or can build for stables
other example a re btrfs-progs and btrfs-progs-unstable change or libusb and libusbx
if the pkgbuild arennot updated but you know how and the "2-weeks-wait· are runing for disound this can help for theses issues too

and finaly, can by nmore clean if you install only yours-needed and not aurp-pkgbuild neede

hyness commented on 2012-04-26 13:54

Is it possible to ask about editing the PKGBUILD before downloading any dependencies? I never noticed it before, but after upgrading xscreensaver-arch-logo, it was trying to force me to install gdm because its listed as a makedepends. I know I can uninstall the deps afterward, but it seems much cleaner just to ask about editing before downloading anything. I had to use yaourt to install that package...TIA!

qqqqqqqqq9 commented on 2012-04-17 22:34

Hi, can you implement support for --color=always aka disabling the tty check so that it's possible to page and grep the output without loosing the colour?

sputnick commented on 2012-03-07 18:19

Ok, problem is gone, I had some non AUR/pacman git binaries.

karol_007 commented on 2012-03-07 18:07

[karol@black ~]$ pacman -Q git
git 1.7.9.3-1

This only tells us what version you're using, but doesn't say a thing about where did you get the package from. 'pacman -S extra/git' is the only sure way.

jpate commented on 2012-03-07 18:01

how about pacman -Q curl ?

sputnick commented on 2012-03-07 17:43

$ pacman -Q | grep git
git 1.7.9.2-1

karol_007 commented on 2012-03-07 17:08

Google says it's a git error. Are you using git from the repos?

sputnick commented on 2012-03-07 16:41

@Karol_007 see http://pastie.org/3542251

karol_007 commented on 2012-03-07 09:21

@sputnick
Seems to work for me. How exactly are you using this PKGBUILD?

sputnick commented on 2012-03-07 02:46

PKGBUILD is broken, you should replace https:// by git://

Anonymous comment on 2012-03-06 13:34

Problem solved I changed my DNS to google's DNS.

Anonymous comment on 2012-03-05 08:57

Any one ?

jpate commented on 2012-03-04 14:03

vSvylatoslav: how are you trying to install? basic makepkg? or are you using some other helper?

Anonymous comment on 2012-03-04 13:57

Basic makepkg I use makepkg -csi

jpate commented on 2012-03-04 13:56

vSvylatoslav: how are you trying to install? basic makepkg? or are you using some other helper?

Anonymous comment on 2012-03-04 13:42

I also got that kind of problems trying to install package-query.
I have been try installing these packages so many times and the result is still the same!
I'm really desperate right now.

jpate commented on 2012-03-04 12:57

@scjet AUR helpers are not (and never will be) officially supported (see https://wiki.archlinux.org/index.php/AUR_helper)

scjet commented on 2012-03-04 12:46

Suggestion:
Why can't we just do a "pacman -S packer" ?
(... wouldn't that just be soooo much easier in the ling run ?)
thx.

Anonymous comment on 2012-03-04 10:14

Cloning into 'packer'...
error: Could not resolve host: (nil); No address associated with hostname while accessing https://github.com/bruenig/packer.git/info/refs
fatal: HTTP request failed
==> ERROR: A failure occurred in build().
Aborting...

I got this error whenever I try to install packer
How can I fix it am I doing anything wrong ?

Xavion commented on 2012-03-02 22:21

If someone in authority ignores my suggestions in favour of his own inferior ones, I'm not just going to sit back and attempt to be 'cool' about it. If you are the sort of wuss who wouldn't keep hammering the guy until he corrects his mistakes, maybe you should think about moving to Switzerland.

mitch_feaster commented on 2012-03-02 17:44

I think gitroot should be https, not http...

@Xavion let's be cool, all right?

Xavion commented on 2012-02-23 21:21

Yes, I was aware that the maintainer of this package is also the developer of 'packer'. This is why I was especially surprised that he wasn't initially interested in fixing his PKGBUILD. I can't understand how someone who creates such a good script can be cursed with such a stubbornly dismissive attitude.

Mayeu commented on 2012-02-23 19:04

@Xavion
Thanks for your input.
I was suspecting something like that, but unaware of the "good maner" in package creationg:)

Mayeu commented on 2012-02-23 19:03

@Xavion
Thanks for your input.
I was suspecting something like that, but unaware of the "good maner" in creating package :)

karol_007 commented on 2012-02-23 07:56

grep & sed are in 'base' group, curl is a dependency for many packages from 'base' - you don't have to put them in the 'dependencies' array, everyone should have them installed.

x33a commented on 2012-02-23 07:18

@ Xavion

Thanks for your input.

PS: In case you don't know, bruenig is the maintainer as well as the developer of packer ;)

Xavion commented on 2012-02-23 00:21

That's good to know; thanks for the info.

Anonymous comment on 2012-02-23 00:13

Linux is srs business.

Xavion commented on 2012-02-23 00:10

It's important to remember that the maintainer probably wouldn't have fixed the problem until someone made him look foolish. I state this because I had posted a comment about this problem here a long time ago and nothing was done about it!

I can only hope that this maintainer will choose to adopt my suggestions more willingly in the future. If he continues to put up more resistances instead, it may be necessary that I react in a similar way for the benefit of 'packer' users.

tom.swartz07 commented on 2012-02-22 23:36

I jest in good fun. Seriously though, at least the maintainer is aware of it and is actively working to sort the issue.

For the right reasons, no ones sure, but at least its getting done.

Xavion commented on 2012-02-22 23:33

I don't know why he'd be issuing a secret 'UNIX' command on a 'Linux' installation. My understanding is that Linux was built on the premise that secrets are to be avoided. The other problem with having something like that as a command is that all of it is in uppercase. Seriously though, were you trying your hand at a bit of comedy there Tommy? :-)

It looks like the infamous "FIX YO PKGBUILDS" response has just made a comeback! I guess that rules out the suggestion that it was intended to be typed in a terminal window. This comeback might just be an attempt by the maintainer to divert our attention away from the fact that he has promptly fixed-up his PKGBUILD, just like I predicted he would.

Anonymous comment on 2012-02-22 23:10

FIX YO PKGBUILDS

tom.swartz07 commented on 2012-02-22 22:52

you're mistaken. "FIX YO PKGBUILDS" is actually a secret Unix command. He must have mistyped it, in the comment window rather than a terminal.

Xavion commented on 2012-02-22 22:39

It has come to my attention that the maintainer of this package has withdrawn his most recent "FIX YO PKGBUILDS" response. This could be a victory for all, as it seems like an indication that he has finally managed to understand the meaning of my below message! It will now be interesting to see whether he promptly proceeds to fix his PKGBUILD in stealth to avert any further embarrassment.

Xavion commented on 2012-02-22 22:06

It's pretty obvious to me that the maintainer of this package has FAILED to understand the meaning of my previous message. Anyone with half a brain would have realised that I was informing said maintainer that his own PKGBUILD is one of the faulty ones in need of fixing.

Xavion commented on 2012-02-22 21:48

I was receiving the same error and I discovered that it's not actually caused by 'packer'. The problem is that some PKGBUILDs incorrectly use "${startdir}/src" and "${startdir}/pkg" instead of "${srcdir}" and "${pkgdir}".

Whenever you encounter cases like this, you should instruct the maintainer of the offending PKGBUILD to use "${srcdir}" and "${pkgdir}" instead. For example, the maintainer of this 'packer' package should be the very first person to take my advice :-).

Since he seems to have a policy of ignoring my suggestions, I'm not so sure that this will happen anytime soon. I suppose someone else could just copy and paste what I've written above and then he might pay some attention to the idea ...

Mayeu commented on 2012-02-22 09:56

I got a strange bug, when using packer -Suy or makepkg to create the packer package I got :
==> Determining latest git revision...
-> Version found: 20120222
==> Making package: packer 20120222-1 (Wed Feb 22 10:12:36 CET 2012)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving Sources...
==> Extracting Sources...
==> Removing existing pkg/ directory...
==> Entering fakeroot environment...
==> Starting build()...
/tmp/packerbuild-1000/packer/packer/PKGBUILD: line 16: cd: /tmp/packerbuild-1000/packer/packer/src: No such file or directory
==> ERROR: A failure occurred in build().
Aborting...

I found that it was due to my makepkg config: /etc/makepkg.conf:

#-- Specify a directory for package building.
BUILDDIR=/tmp/makepkg

If I comment my BUILDDIR directory there is no problem.
It is the first time I got a problem in a package due to this config. (I set up this 1 or 2 month ago)

Anonymous comment on 2012-02-19 16:05

Fixed. Retsam was right.

Anonymous comment on 2012-02-19 12:22

I found this like a possible fix:

on line 282 (or something above) changing code to this:

curl -Lfs "$PKGURL/${1:0:2}/$1/$1.tar.gz" > "$1.tar.gz"


and on line

583(or something above :D) to thi

curl -Lfs "$PKGURL/${package:0:2}/$package/$package.tar.gz" > "$package.tar.gz"

fixes missing redirects problem.

Anonymous comment on 2012-02-19 06:33

@dewert, I'm glad I'm not the only one that just spent time chasing a ghost. ;)

Anonymous comment on 2012-02-19 06:19

@chimeracoder
Thanks, at least I can stop pulling my hair out over this now.

Anonymous comment on 2012-02-19 06:17

@karol_007 @CaptainHaddock
I'm getting the same error, when using packer to sync ANYTHING, for example, trying to fix cairo-ubuntu from my latest upgrade:

packer -S cairo-ubuntu

All the packages I've tried do this. Have upgraded packer and package-query manually.

chimeracoder commented on 2012-02-19 06:16

@karol_007 @CaptainHaddock

It's because the compact URL redirects were removed today/yesterday:

https://bbs.archlinux.org/viewtopic.php?pid=1059991#p1059991

karol_007 commented on 2012-02-19 06:04

@CaptainHaddock
Please post the exact command you run.

Anonymous comment on 2012-02-19 05:56

I'm getting this error when I try to use packer. Any way to solve this problem?

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
/usr/bin/packer: line 283: cd: b43-firmware-lts: No such file or directory
No PKGBUILD found in directory.

Anonymous comment on 2012-02-17 16:54

It's a git package folks. It is never out of date.

I guess I can bump the version at the top so that those not doing --devel will get an update.

Maybe later.

karol_007 commented on 2012-02-17 16:50

Maybe he meant your changes: https://github.com/bruenig/packer/commit/137cbc02ed587f3e5c32709861b731e52a452445

Anonymous comment on 2012-02-17 16:39

What makes this out of date?

ItachiSan commented on 2012-02-17 16:28

Please update the 'makepkg' if the online repo is updated, so anyone can receive updates. :)

cippaciong commented on 2012-02-13 12:17

Got the same error
I just tried to install it again and everything went fine.

Anonymous comment on 2012-02-13 10:18

Fail to build :
==> Connecting to github GIT server....
Cloning into 'packer'...
fatal: http://github.com/bruenig/packer.git/info/refs not valid: is this a git repository?

Any idea to fix this ?

Xavion commented on 2012-02-10 21:14

Using the "BUILDDIR=/tmp/makepkg" setting in "/etc/makepkg.conf" causes 'packer' to fail here. When I then tried to build 'jdiskreport' manually, I had to issue "cd /tmp/packerbuild-1000/jdiskreport/jdiskreport/" and "ln -s /tmp/makepkg/src" first. After doing so, I was then able to build the package via 'makepkg'. Can you please modify the 'packer' code so that it works properly when this 'BUILDDIR' variable is enabled?

Anonymous comment on 2012-02-08 02:00

@rlipman

Some kind soul wrote a patch that allows you to set the client you want to use instead of pacman.

Just do: export PACMAN_CLIENT='pacmatic'

Then you should be set (it reads that environment variable)

Anonymous comment on 2012-02-07 21:59

@rlipman

You could go through the code and change some calls to pacman to pacmatic to get your intended effect.

Anonymous comment on 2012-02-07 21:49

Is there a way to use packer with pacmatic?

scjet commented on 2012-01-25 10:38

It looks like this actually may be a "makepkg" error that is causing packer to spew out those error, according to this -> https://bbs.archlinux.org/viewtopic.php?id=133902

scjet commented on 2012-01-22 13:58

It appears ever since arch upgrade to pacman (ver 4), "packer" installs packages ok, howver it constantly spews out:
"==> ERROR: An unknown error has occurred. Exiting..." right after the " -> Compressing man and info pages..." ???

t3ddy commented on 2012-01-21 13:02

Referring to: https://aur.archlinux.org/packages.php?ID=27031
Packer doesn't extract man page, while makepkg and yaourt do it.

t3ddy commented on 2012-01-21 13:00

For some strange reason it doesn't extract man page, like makepkg and yaourt do.

CPUnltd commented on 2012-01-17 15:15

@ mezcal: What I've done in the past, when necessary, is symlink my build folder (packerbuild-XXXX, IIRC) to a place with more space... if all else failed, I'd plug in a USB flash drive and symlink to the root or whatever folder I could create in a temp space for that quick purpose. Then return to normal after I was done. Hope that's a good quick-fix option for you...

karol_007 commented on 2012-01-17 14:45

@Jristz
I've been tricked by this a couple times too. BTW, archlinuxfr has rar 4.0.1-1 now.
You can run 'packer -Syu --auronly'.

karol_007 commented on 2012-01-17 14:44

@Jristz
I've been tricked with this a couple times too. BTW, archlinuxfr is rar is now 4.0.1-1, but archstuff is 4.0.0-1.
You can run 'packer -Syu --auronly'.

karol_007 commented on 2012-01-17 14:40

IIRC packer uses makepkg.conf's settings, so just move BUILDDIR from /tmp/makepkg to e.g. BUILDDIR=/home/karol/test/makepkg

mezcal commented on 2012-01-17 09:49

Some packages ends with error: No space left on device.
/tmp is too small.

Does exist any setting to use another directory?

Jristz commented on 2012-01-17 06:32

If for example a package in normal reppo have the same name tha one in aur, packer only download and install from the offcial
and not exist ani form for use the aur version (aur/package give an error in many lines referent to the download path)

a clear example is rar from archlinuxfr and from aur
the archlinuxfr is rar 4.0.0 and the aur is 4.0.1 but packer fetch for the archlinuxfr indifferent if aur is more datted than the archlinuxfr

Anonymous comment on 2011-12-31 23:10

Thanks bruenig! Looks great now.

Anonymous comment on 2011-12-31 21:30

I modified packer to use sudo -E internally now. Somehow for the 2 years or so that this has been running, nobody ever mentioned that sudo -E was necessary to preserve the environmental variables.

Anonymous comment on 2011-12-31 21:26

For those of you experiencing EDITOR issues, there is discussion about it below but here are two easy options:
When you run packer pass -E to sudo; sudo -E packer, this preserves the editor set by your environment.
Or put an EDITOR=youreditor variable in packer near the top. For example:
PKGURL="https://aur.archlinux.org/packages"
EDITOR="nano"

Anonymous comment on 2011-12-12 08:46

thx man.you rock;)

carlwgeorge commented on 2011-12-12 08:43

I encountered an issue on a fresh arch net install. I installed packer, but when I would use it it would always return "Package FOO does not exist". After much digging, I discovered that the file /etc/ssl/certs/ca-certificates.crt did not exist for some reason. I was able to fix this by running update-ca-certificates.

Anonymous comment on 2011-12-01 20:30

i have this packer issue, ex when i call 'packer pdi' it shows me only 3 packages, but none of them is pdi http://imgur.com/aNavY.
i just made a fresh install of arch 64.

Anonymous comment on 2011-11-28 13:31

binutils and binutils-multilib clash, packer can't handle deps but pacman can. Any idea why? For more info here the thread: https://bbs.archlinux.org/viewtopic.php?pid=1022203#p1022203 (on a 64bit up-to-date system)

magus commented on 2011-11-03 09:15

@breunig: it's actually rather simple, 'packer' doesn't handle 'provides' properly. In the case rich_o is referring to, 'haskell-pandoc' requires 'haskell-bytestring', 'haskell-bytestring' isn't a separate package but is provided by 'ghc'. 'packer' isn't able to figure this out, while 'yaourt' is.

rich_o commented on 2011-11-02 16:42

@bruening: you seem confused? well, i was. all i know is, that it works with yaourt and packer fails. i don't really know where the bug is anymore. i mean, why define haskell-bytestring as a dependency, if ghc provides it? on the other hand, it's the first time i encountered that error and i use packer for quite some time now.

Anonymous comment on 2011-11-02 12:14

It is true that packer can not find dependencies that do not exist...............................................................................................................I will work on a fix?

rich_o commented on 2011-11-02 10:25

packer doesn't build haskell-pandoc. problem is, that a dependency (here: ghc) provides another dependency (here: haskell-bytestring), which is not in aur. packer seems not aware of this and complains about not finding the dep (haskell-bytestring).

Anonymous comment on 2011-10-09 02:44

anyway else have packer consistently fail to build firefox-kde-opensuse?

karol_007 commented on 2011-09-23 21:41

With regard to pacman 4.0 - I'm using pacman 4.0.0rc2-1 and packer is OK with it :-)

karol_007 commented on 2011-09-23 18:25

Turns out I had an outdated packer installed from [archstuff] repo and it seems that's why packer wasn't treating itself as an AUR package and kept telling me my packages are up to date.

PKGEXT indeed works fine with the current packer, thanks :-)

Anonymous comment on 2011-09-23 18:11

302 runasroot pacman ${PACOPTS[@]} -U $pkgname-*$PKGEXT

Have no idea what your error is being caused by. It already uses PKGEXT as a variable so whatever you specify should be fine. Need more info if want to diagnose this.

karol_007 commented on 2011-09-23 18:02

Do you plan supporting PKGEXT='.pkg.tar'? Right now I get an error: 'error: '<packagename>-*.pkg.tar.*': cannot open package file'.
It's not a big deal, I can switch to gz compression or install packages build with packer manually.

Anonymous comment on 2011-09-20 01:43

What is incompatible about it?

Anonymous comment on 2011-09-20 01:30

any plans to make this compatible with pacman 4.0 any time soon?

karol_007 commented on 2011-09-11 18:21

@x33a
Yes, this is the problem.
[karol@black ~]$ packer -S kcm_ufw

Aur Targets (1): kcm_ufw

Proceed with installation? [Y/n]

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
/usr/bin/packer: line 271: cd: kcm_ufw: No such file or directory
No PKGBUILD found in directory.


Now let's use the correct name:
[karol@black ~]$ packer -S kcm-ufw

Aur Targets (1): kcm-ufw
Pacman Targets (6): automoc4 docbook-xml docbook-xsl kdebase-workspace polkit-kde ufw

Proceed with installation? [Y/n]

Password:
resolving dependencies...
:: There are 2 providers available for phonon-backend:
:: Repository extra
1) phonon-gstreamer 2) phonon-vlc

Enter a number (default=1):
looking for inter-conflicts...

Targets (87): qt-4.7.4-2 [24,75 MB] automoc4-0.9.88-2 [0,02 MB] docbook-xml-4.5-4 [0,07 MB]
libxslt-1.1.26-2 [0,41 MB] docbook-xsl-1.76.1-1 [0,56 MB]
...
(I haven't installed it but hopefully it all goes well :-) )

x33a commented on 2011-09-11 18:17

@ xntrzcc, i don't know if it has any relevance to your problem or not, but the package name you are listing in the command is wrong. It should be kcm-ufw instead.

https://aur.archlinux.org/packages.php?ID=46880

Anonymous comment on 2011-09-11 01:39

abs support is bloat

Anonymous comment on 2011-09-11 01:38

svinto, that package is incorrectly packaged. Needs to be fixed.

svinto commented on 2011-09-11 01:05

BUG: function aurinstall(), row 258
DESCRIPTION: If tar.gz file downloaded to $dir/$1 is extracted to a folder name other than $1 then a crash will occur at row 271 "cd $1".
REPRODUCE: Try to install linux-aufs_friendly 3.0.4-1 from AUR.
SOLUTION: Add he following line between row 270 and 271: mv "$(find . -maxdepth 1 -type d | sed -r '/^[.]$/d;/^[.]\//s///;q')" "$1"

Anonymous comment on 2011-09-10 11:51

HI,
I just wanted to make a suggestion could we possibly add abs support to packer, so that we have pacman, aur and abs all in on place.

ponsfoot commented on 2011-09-10 06:56

Hi,
Could you support split packages?
For example, call pacman with '-U *$PKGEXT' instead.
Thx

Anonymous comment on 2011-09-02 14:48

Hi,

Why not change the _gitroot/_gitname variables in the pkgbuild to _gitbase/_gitrepo (for example). Using other variable names will avoid that odd behavior that makes the package version different from the version explicited in the pkgbuild.

I'm using this _solution_ in one of my pkgbuilds and everything looks ok. Thanks.

Xavion commented on 2011-08-21 11:11

To get around the problem you've raised, I've been issuing "pacman -Sd pacman" instead. This skips dependency version checks, which prevents the need to uninstall "pacman-color" first.

Anonymous comment on 2011-08-21 01:00

The loss of color on install is not a big deal. We removed pacman-color because it is a huge pain in the ass every time pacman updates. You have to uninstall pacman-color, install pacman, then reinstall pacman-color every. single. time. I don't know if people liked doing that or not, but I thought it was pretty shitty.

So the upshot of the new coloring scheme is that you don't have to mess with an unsupported pacman-color package that requires manual uninstalls and reinstalls for every pacman update. The downside -- I guess -- is that you don't get color on the install prompts, something that I don't really take to be that important (the coloring is really only needed to work through search output, not anything else in my opinion).

Xavion commented on 2011-08-20 22:49

My "packer-color" package brings back "pacman-color" support. It can be downloaded here: http://aur.archlinux.org/packages.php?ID=51263

The two advantages are that it: includes better support for colourised output; forwards unrecognised arguments straight to "pacman-color".

The latter improvement means that you won't need to mess around using separate commands for repository (pacman) and AUR (packer) operations.

tjwoosta commented on 2011-08-20 10:15

Bruenig: Its not calling on pacman-color anymore for some reason. So packers output (search results and aur stuff) is colored fine, but the actual pacman output (installing stuff from standard repos and such) is now all uncolored because its not using pacman-color. Is this going to be fixed?

svanheulen commented on 2011-08-09 21:13

It doesn't seems to use pacman-color any more.

Xavion commented on 2011-08-06 01:24

I have just added a "packer-color" package to the AUR, which is available for viewing here: http://aur.archlinux.org/packages.php?ID=51263

The two advantages are that it: includes better support for colourised output; forwards unrecognised arguments straight to "pacman-color".

The latter improvement means that you won't need to mess around using separate commands for repository (pacman) and AUR (packer) operations.

Xavion commented on 2011-08-05 23:43

Some colours are missing using your new colourisation method. For example, in the output from "packer -Ss pacman": the "(base)" text should be dark-blue and the "[installed]" text should be light-blue.

Xavion commented on 2011-08-05 21:38

Why on Earth have you dropped "pacman-color" support in the latest release? Is this just a regression bug or are you deliberately trying to kill 'pacwrap'?

Anonymous comment on 2011-07-30 03:04

Big changes were made. Look out for bugs.

Xavion commented on 2011-07-29 05:15

I recommended "sudo -E" because Bruenig wrote this below: "No one has ever been able to satisfactorily figure out why it doesn't respect the environment variables except that perhaps sudo or something is causing it to fail?" I was already aware of SUdo's 'env_keep' configuration option; other users probably aren't, so I suggested "sudo -E" for their sake.

pezz commented on 2011-07-29 00:51

Ah right. Why is "sudo -E" being asked for then? o_O

Anonymous comment on 2011-07-28 23:28

Yeah actually I recall now that the "configure your sudo" correctly arguments were made last time this came up, and so I kept with that. Although, to be honest, this is not a sudo thing as far as I can tell since of course you aren't editing with sudo.

pezz commented on 2011-07-28 23:03

Why don't you configure sudo properly to always preserve your EDITOR variable?

e.g.

Defaults env_keep += "ACKRC EDITOR LANG"

Xavion commented on 2011-07-28 21:25

To preserve the value of the 'EDITOR' environment variable, you need to pass the '-E' flag to 'SUdo'. It's not exactly rocket science, Bruenig.

`--> sudo env | grep EDITOR

`--> sudo -E env | grep EDITOR
EDITOR=diakonos

x33a commented on 2011-07-28 17:15

@ bruenig, as you said that a number of people have problem with the $EDITOR variable, maybe you could implement a switch to use a user specified editor.

Anyway, since i have always used vim, so i haven't noticed this problem :P

Xavion commented on 2011-07-28 06:22

Bruenig, you've stated below that 'pacwrap' is useless. I'm quite surprised at this comment, since you were its original author.

Given your feelings toward 'pacwrap', I still can't see why you don't just forward unrecognised flags straight to "pacman(-color)".

Anonymous comment on 2011-07-28 01:59

Ok, I'm sorry. Packer is great. I wasn't trying to force the issue, just giving some friendly suggestions :P. Thanks for all your hard work.

Anonymous comment on 2011-07-28 01:39

Not really. I mean, it makes more sense to just use vi for the once in a year time that you actually need to edit some package. Seems like you will live. Prompts are obnoxious.

Anonymous comment on 2011-07-28 01:32

Ok, it's fine. Just asking :P.
If it isn't possible to get the "EDITOR" variable to work, wouldn't it make more sense to (temporally at least) prompt for the name of the editor to use instead of just using vi every time?

Anonymous comment on 2011-07-28 01:25

resource intensive meaning -- slows it down a bunch

Anonymous comment on 2011-07-28 01:24

This is like the greatest hits in packer complaints. I have no idea why EDITOR does that. No one has ever been able to satisfactorily figure out why it doesn't respect the environment variables except that perhaps sudo or something is causing it to fail? Adding support for [installed] is way too resource intensive and not worth it. I do not intend to expand packer functionality to cover all things. If you are doing something that just needs pacman, then use pacman.

Anonymous comment on 2011-07-28 01:20

Not sure if the database structure allows it. But is it possible to get an "[installed]" tag next to the AUR packages installed when querying the database with "-Ss" as normal packages have?

Anonymous comment on 2011-07-28 01:02

I have the EDITOR enviornment variable set to "nano" in my .bashrc (and I checked the value manually with echo "$EDITOR"). However, when I edit a package via-packer the vi editor is used instead.

Anonymous comment on 2011-07-28 00:23

Also packer "$@" 2>/dev/null would be a stupid thing to do since now you would hide all the error messages. You just want to hide that one error message, the parsing one.

Anonymous comment on 2011-07-28 00:10

Too much work to change it all to stderr. I don't have any particular interest in pacwrap in that it adds absolutely no functionality and is therefore useless. That small little parsing error message that you have to fight through to use pacwrap is not a big deal in my opinion.

Xavion commented on 2011-07-28 00:05

Please respond to the question I asked in the second paragraph of my July 22 comment. Another user of my 'pacwrap' script has requested the same thing, but I can't do so at my end without causing an unwanted side-effect.

lymphatik commented on 2011-07-25 14:41

Sorry bruenig you were right it was another package that made zsh completion possible.

Anonymous comment on 2011-07-25 03:27

Oh, I get it now. So if they're not in the database it's impossible. Thanks for the explanation.

CPUnltd commented on 2011-07-24 16:19

lymphatik: remove -S and packer will offer all packages (standard and AUR) that have the letters in sequence that you typed... choose the number that corresponds to the package you want, then hit the enter key...

"packer net-t" should get you what you're looking for...

Anonymous comment on 2011-07-24 15:20

Never used zsh or autocompletion (there is no autocompletion files in packer). So that is something you are pulling in from somewhere else.

lymphatik commented on 2011-07-24 15:16

I have a small glitch with packer autocompletion and zsh. For example if I try packer -S net-t I get testing and extra as suggestion instead of net-tools. Is that the normal behaviour ?

Anonymous comment on 2011-07-24 14:12

There is no such thing as synchronizing the AUR database. It does not have a database. All you can do is check every single aur package that you have installed against the present version of that package on AUR. So -Sy would literally do nothing. If you just want to synchronize the pacman database, then do pacman -Sy. If you just want to update aur, then do pacman --auronly -Su (or -Syu which is no different for aur).

Anonymous comment on 2011-07-24 09:36

Sorry again, I think I'm abusing already but Yapan also needs the "-Qu" flag to list all the updates if it's not too much trouble :P.

Anonymous comment on 2011-07-24 09:31

Hey, great work :D. I like it more than yaourt.
Is it possible to get the "-Sy" flag? I use Yapan (another AUR package) to synchronize the database periodically and prompt me when there's and update (so I choose if I update then or later). However, if I use "sudo yaourt -Sy" it doesn't check the AUR database for updates. The only way of synchronizing the supported database + AUR is using "packer -Syu" but that upgrades the system too without prompting me first so adding the "-Sy" flag would solve the problem.
Thanks a lot in advance :D.

Xavion commented on 2011-07-22 09:00

I've modified your 'pacwrap' script to use "pacman-color" if present and fall-back on 'pacman' if not. I've just uploaded a 'pacwrap' package to the AUR, noting you as one of the authors.

Can you please modify 'packer' to send its error messages to 'stderr' instead of to 'stdout'? I want to use 'packer "$@" 2>/dev/null' in our script, but doing so currently has no effect.

Xavion commented on 2011-07-21 22:50

Thanks for pointing that out. Can you please modify it to use "pacman-color" if present and fall-back on 'pacman' if not? Once that's done, can you create a PKGBUILD and upload a 'pacwrap' package to the AUR?

Anonymous comment on 2011-07-21 22:30

Use pacwrap: https://github.com/bruenig/pacwrap

Xavion commented on 2011-07-21 22:26

I'm actually hoping to use 'packer' instead of "pacman(-color)" all the time, even for cases like '-Qi' and '-Rd'. You wouldn't need to care what these unrecognised flags represent if you just forward them straight to "pacman(-color)". Doing so would mean that we'd be able to use 'packer' for all of our packaging needs.

Anonymous comment on 2011-07-21 22:13

-Sy would only synchronize pacman's db since there is no aur database to synchronize in an -Sy fashion. So just use pacman -Sy.

Xavion commented on 2011-07-21 22:10

Sometimes I like to synchronise the repositories simply to check on the current version of a package. When I just submitted the '-Sy' flags to 'packer', it reported that these are invalid (when alone).

`--> packer -Sy
packer: Option `-Sy' is not valid.

`--> packer -Suy
:: Synchronizing package databases...

Please just pass '-Sy' to "pacman(-color)" instead and it will know what to do. In fact, perhaps just pass all unrecognised flags to "pacman(-color)" and it will report errors if they are truly invalid.

Xavion commented on 2011-07-16 11:01

Another way of knowing what's popular is to use the "Popular Packages" script, which is located here: http://aur.archlinux.org/packages.php?ID=47257

CPUnltd commented on 2011-07-16 05:03

Well, I'd at least like to see acknowledgement of the number of votes a package has similar to what clyde used to do (or still does, I never use it anymore now that I have packer)... I liked seeing the number of votes next to the package name... it let me know what was popular or "worked best". It's about the only feature from clyde that I truly miss...

Anonymous comment on 2011-07-16 01:06

I am not in favor of adding a call to aurvote in the script. One can aurvote on their own if they would like to do so externally.

Xavion commented on 2011-07-15 22:57

I got really worried when I found out that 'bauerbill' has been deprecated. It's pleasing to know that 'packer' is right in line to take its place.

I like how you haven't tried to reinvent the wheel by duplicating a whole bunch of 'pacman' features. Have you considered adding 'aurvote' support?

Anonymous comment on 2011-06-25 08:52

Thank you!

Anonymous comment on 2011-06-24 22:11

Ok I changed the PKGBUILD.

The other problem appears to be because I use sleep 0.1 (I guess other userlands don't like stuff like "0.1"). So let me know how to make that work in those userlands.

Anonymous comment on 2011-06-24 21:52

@bruening Those userlands:
Busybox: https://wiki.archlinux.org/index.php/Base2busybox
UCB, Posix2001, Heirloom: https://wiki.archlinux.org/index.php/Base2heirloom
plan 9: https://wiki.archlinux.org/index.php/Base2plan9
sbase: https://aur.archlinux.org/packages.php?ID=50027
goblin: https://aur.archlinux.org/packages.php?ID=48413
ppt: https://aur.archlinux.org/packages.php?ID=48392

To install packages from ABS or AUR, we download the PKGBUILDs (+ files) via pak -G <packagename> and compile them via unipkg instead of makepkg.

Anonymous comment on 2011-06-24 21:09

Fixed grine's complain. What userland's can't handle install -D?

Anonymous comment on 2011-06-24 20:19

Removed the for most userlands incompatible -D option from install and inserted two real mkdir -p commands: https://gist.github.com/1045580
Cloning into packer...
remote: Counting objects: 580, done.
remote: Compressing objects: 100% (251/251), done.
remote: Total 580 (delta 189), reused 556 (delta 179)
Receiving objects: 100% (580/580), 78.22 KiB, done.
Resolving deltas: 100% (189/189), done.
install: illegal option -- D

packer has one remaining optical bug in most userlands:
sleep: bad character in argument
sleep: bad character in argument 65 65 [################################################################] 100%
sleep: bad character in argument

grine commented on 2011-06-24 08:34

Hey, are there any plans to make packer understand the ordering of dependencies? As it is now they often install in the wrong order making some fail and forcing the user to rerun the command.

Otherwise I might be persuaded to try and fix it sometime during summer.

CPUnltd commented on 2011-06-15 03:24

thanks for the comment crimsonredmk... I don't think anyone ads 'arm' to their arch lines yet... it hasn't gotten popular enough (YET)... but with more and more devices moving to ARM and even desktops/laptops making the move, it will happen soon enough... especially with advocates like us speaking up on the matter (even in the most insignificant ways)...

Anonymous comment on 2011-06-15 02:15

Yep, works fine on Arch Linux ARM for me too on a Pandaboard. Does _anyone_ else in AUR add "arm" or "armv7" to their arch lines? I don't think so...

CPUnltd commented on 2011-06-05 22:42

works on ARM architecture... please add to archs in next update

jyaworski commented on 2011-04-30 00:29

Is anyone else have an issue where trying to edit a PKGBUILD when it prompts you causes the terminal to lock up and not be able to edit? This is specifically with nano, it appears. I tried emacs-gtk and it works fine.

jyaworski commented on 2011-04-30 00:21

Is anyone else have an issue where trying to edit a PKGBUILD when it prompts you causes the terminal to lock up and not be able to edit?

Anonymous comment on 2011-04-28 05:40

You can specify tmp with TMPDIR environmental variable.

silvik commented on 2011-04-23 12:30

Is there a way to specify where to build the package? My /tmp is nosuid,nodev,noexec and sometimes I get some build errors. Thanks

Det commented on 2011-04-16 11:56

The PKGBUILD could be simplified a bit like this (commented): http://pastebin.com/qekbubUU - here's a version without the comments: http://pastebin.com/QFC2AUme

E: correction with the cd.
E2: *grubmle* links were the other way around..

Det commented on 2011-04-13 11:19

The PKGBUILD could be simplified a bit like this (commented): http://pastebin.com/QFC2AUme - here's a version without the comments: http://pastebin.com/qekbubUU

E: correction with the cd.

Det commented on 2011-04-12 19:20

The PKGBUILD could be simplified a bit like this (commented): http://pastebin.com/HBCJZUqh - here's a version without the comments: http://pastebin.com/bBnVqYmj

CPUnltd commented on 2011-03-26 20:39

point taken... was not able to duplicate the error... seems to be working fine now. My mistake for jumping to concluions. I did update the database once, but not twice...

Anonymous comment on 2011-03-26 14:14

packer does not directly access the pacman db. It only uses pacman commands. What that probably means is that you didn't update your database structure when you updated to pacman, and pacman itself is not recognizing the db (therefore making packer's calling of pacman not work). This of course is not packer's fault.

CPUnltd commented on 2011-03-26 07:39

will get output and report back... gave me an error that basically told me it couldn't recognize the db structure after I updated to pacman 3.5 right before I made that post... was doing a bunch of stuff at once and didn't think to copy/paste the output. Will see if I can get it in the morning or during the day/evening tomorrow.

Anonymous comment on 2011-03-26 06:35

If you flag it out of date, better tell me what broke, because I haven't seen any problems.

CPUnltd commented on 2011-03-26 03:36

needs to be updated to handle pacman 3.5

stqn commented on 2011-03-25 12:38

Small bug; only i2p requires java-environment, not retroshare or unetbootin:

$ sudo packer --auronly -Syu
Password:
:: Synchronizing aur database...
aur 30 30 [######################] 100%
:: Starting full aur upgrade...
Dependency `java-environment' of `i2p' does not exist.
Dependency `java-environment' of `retroshare' does not exist.
Dependency `java-environment' of `unetbootin' does not exist.
local database is up to date

And it would be great if packer could find the packages that provide java-environment and install one of them (the user would have to choose which one, of course.)

mezcal commented on 2011-03-22 20:22

Hi,

here is a little patch for packer

http://pastebin.com/v6AsE5FL


It shows packages which are not in aur.

mezcal commented on 2011-03-22 19:29

Hi,

here is a little patch for packer

http://pastebin.com/v6AsE5FL


It shows packages which are not in aur.

Anonymous comment on 2011-03-08 08:58

Yes, it's a sudo issue, and it's been fixed with an upstream patch in sudo-1.8-3 from [testing], but if you're using [core], then you'll have to live with the issue untill sudo-1.8-3 comes out of testing.

The issue is that sudo-1.8-1 and 1.8-2(curently in [core]) returns wrong return value when using it's -v parameter, and so sudo is never used in packer even if installed, and instead su is used, which prompts for your root password upon each and every package install!

CPUnltd commented on 2011-03-06 17:47

I'd have to go with the error being with sudo... I just did 'packer -Syu', it asked for the password and I hit [ENTER] without using a password... it went through without issue. (note: I had already done a sudo command prior to this as I'm reading PKGBUILDs within AUR via the commandline comparing pkgs... but everytime I use packer or sudo, it asks for the password, whereas the usual expectation is about a 10 or 20 second timeout before I actually need to put a password in again...

CPUnltd commented on 2011-03-06 17:41

I see I'm not the only one running into this problem... thing is, it ALWAYS asks for the root password, even when it doesn't need it... and after the first time I do it, I can input the first letter to the root password and it will say "incorrect password" and run the command anyway, while making the rest of the letters in my password visible on the commandline (like it errors out after the first letter and I'm returned to an empty commandline).

Anonymous comment on 2011-03-06 15:44

Always run packer -S packer before noting some problem. Since this is a git package, I often just update the repo, instead of bothering with changing the PKGBUILD and re-uploading it. I believe it is fixed there.

Anonymous comment on 2011-03-06 15:33

I'm having the same troubles with packer asking for root password. My current workaround is to run packer like this: 'sudo packer'

Anonymous comment on 2011-03-06 15:32

I'm having the same troubles with packer asking for root password.

fackamato commented on 2011-03-06 13:41

$ if sudo -v &>/dev/null && sudo -l "$@" &>/dev/null; then
> echo yes; fi
yes

pezz commented on 2011-03-06 13:38

May be a bug in the updated sudo?

The test on line 67:

elif sudo -v &>/dev/null && sudo -l "$@" &>/dev/null; then

Is failing as sudo -v is always returning 1 for me, hence the test falls through to su regardless if you have sudo permission or not.

Is my thinking right here?

Anonymous comment on 2011-03-05 13:08

I just updated sudo and now packer always requires the root password.

Anonymous comment on 2011-03-02 01:49

Manual update required folks. Aur changed the url scheme.

Overand commented on 2011-03-01 19:25

I 'sort of' fixed the PKGBUILD - there are some changes in filenames (v0.5.0 in the old one, 0.5.1 in the new one), hyphens in the URL where there used to be a -. Additionally, some of the patches seem to no longer work, but the string.h patch needed for compilation of the UPnP stuff is still in use. Also had to add a compile block for libbitdht. My PKGBUILD used some hardcoded versions, but I'll stick it up somewhere. The 'patch' file needs to have bunches of stuff taken out that I think no longer apply. http://pastebin.com/iP2CbW1w

trizen commented on 2011-02-19 14:34

% packer -S gxneur-svn
Aur Targets (3): xneur-svn libmatheval gxneur-svn

The correct order should be:
Aur Targets (3): libmatheval xneur-svn gxneur-svn

scio commented on 2011-01-26 22:06

@ibendiben: Those are part of base-devel and are thus required to use AUR. The packages themselves don't need to include them.

Anonymous comment on 2011-01-26 21:37

packer needs both fakeroot and patch

scippio commented on 2011-01-17 11:22

It would be good to add to the packer -f (force) parameter for Pacman

Anonymous comment on 2010-12-30 11:30

the EDITOR variable in my .zshrc is set to vim, but packer uses vi...

Anonymous comment on 2010-12-11 18:56

For the lazy:

wget "https://aur.archlinux.org/packages/packer/packer/PKGBUILD" ; makepkg -fic

Anonymous comment on 2010-12-11 18:55

Everything is fixed. I assume you are going to have to old school makepkg install this newest version.

Howitzer commented on 2010-12-11 17:20

Ditto on AUR breakage.

Proceed with installation? [Y/n] y
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
/usr/bin/packer: line 283: cd: air-video-server: No such file or directory
No PKGBUILD found in directory.

Line 283 is the aurinstall function:
# Installs packages from aur ($1 is package, $2 is dependency or explicit)
aurinstall() {
dir="${TMPDIR:-/tmp}/packerbuild-$UID/$1"

# Prepare the installation directory
# If there is an old directory and aurversion is not newer, use old directory
if . "$dir/$1/PKGBUILD" &>/dev/null && ! aurversionisnewer "$1" "$pkgver-$pkgrel"; then
cd "$dir/$1"
else
[[ -d $dir ]] && rm -rf $dir
mkdir -p "$dir"
cd "$dir"
curl -fs "$PKGURL/$1/$1.tar.gz" > "$1.tar.gz"
tar xf "$1.tar.gz"
cd "$1"
fi


ed0c commented on 2010-12-11 17:13

@fackamato
Same issue for me.
Also, the search/install with aur doesn't seems to work.

But It still work with yaourt, so i don't know but it seems to be a problem with packer

fackamato commented on 2010-12-11 15:52

Is it just me or did AUR just break?

fackamato@ion /raid5volume/aur $ packer -G mpd-git
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

packer -Ss only shows repos, not AUR.

Anonymous comment on 2010-11-29 22:45

You should probably change '$startdir/src' and '$startdir/pkg' to '$srcdir' and '$pkgdir', respectively.

Anonymous comment on 2010-11-26 20:10

Ay chance you could pass wget the --no-check-certificate option as default, so it is possible to use this with pkgbuilds with files hosten on github?

Anonymous comment on 2010-11-24 22:16

A quick look at the code makes it look like I can accomplish the same thing as number 2 with an environment variable, but it's not documented. It should probably at least be mentioned in the manfile. Also, would it be possible to get it to automatically delete its build directories? Maybe a packer -Sc(c) or something.

Anonymous comment on 2010-11-24 22:12

A couple of things:
1) Would it be possible to add an option to make it check vote status the way yaourt does? It probably shouldn't do it by default, but the option would be nice.
2) I'm not sure what else you'd put in it, but a config file would be nice just so I could change the tmp dir.

scippio commented on 2010-11-24 17:25

It would be nice if it could packer have -f flag like --force for pacman...

Anonymous comment on 2010-11-02 05:45

evanlec is such a hater

install pacman-color for color

There is no need for a config file, what do you even want to config.

Indicating whether something is installed is too resource-heavy to do in bash and was not pacman's behavior until well after packer was going anyhow.

evanlec commented on 2010-10-27 18:22

And stop asking me for my password!!!$##@ I can't believe you wrote this whole thing in bash either...

evanlec commented on 2010-10-27 18:16

Some color would be nice...
Also a config file would be handy too.
Also indication in search results of whether the package is already installed or not would be lovely

Anonymous comment on 2010-10-16 16:15

Changed to http:// and added a patch to fix some issues with the aur percentage bar

linuxSEAT commented on 2010-10-16 12:58

To allow "git" access behind a proxy, I had to change

git://github.com/bruenig/packer.git

into

http://github.com/bruenig/packer.git

I tried setting env variables without avail. Unless there is a good reason, why not use "http://" instead of "git://" ?

Anonymous comment on 2010-10-08 02:10

Auguste, changed it. packer -S packer to get the latest git revision

Auguste commented on 2010-10-08 02:07

on line 266, the "dir" variable is hardcoded to /tmp directory, thus makes setting $TMPDIR to compile aur in different directory useless here.

is this a intentional feature or just a typo?

mezcal commented on 2010-10-05 13:43

Hi, thanks for this nice tool.

pacman has option -Qm it shows foreign packages.
Could you add option that show foreign packages which are not in aur.

Anonymous comment on 2010-09-19 21:35

export EDITOR=nano works fine in ~/.bashrc for packer.

Det commented on 2010-09-17 15:07

Also is it really necessary to have 'pacman' as a dependency? It wouldn't really help to know that, if you happened to remove it... unless you hit archiso.

Det commented on 2010-09-08 17:16

No.

Anonymous comment on 2010-08-30 10:06

Does the EDITOR variable actually do anything?

If I run:

$ eval ${EDITOR}

Then emacs will start since I have said EDITOR="emacs -nw" in my .bashrc

But no matter what I do packer only uses vi to edit the files.

Any suggestions?

Det commented on 2010-08-15 00:33

Just some suggestions: http://aur.pastebin.com/WPMFGBZ7

Stebalien commented on 2010-08-11 20:03

@Auguste: Set the $TMPDIR variable (add `export TMPDIR=/dev/shm/` to your login script).

Auguste commented on 2010-08-11 05:47

can i have packer use /dev/shm instead of /tmp to compile aur packages?

there must be a config file somewhere that i didn't find.

Stebalien commented on 2010-08-11 03:29

I added support for all -Q, -R, -D, and -U options and added support for the rest of the -S options. My code does not check anything, it simply calls pacman when needed.
http://github.com/Stebalien/packer

ecraven commented on 2010-07-21 17:04

great tool! do you think you could add -R(d) and -U to the accepted options? (just runasroot $@)

herve commented on 2010-05-19 14:45

Hi, please use "srcdir" and "pkgdir" instead of the deprecated "startdir". Thanks.

chancho commented on 2010-05-16 06:59

i need to input 4 times of the password, is it normal ?

Anonymous comment on 2010-04-29 05:59

Line 84 needs the cut field expression changed from "-f 2" to "-f 2-". This is necessary to accomodate IgnorePkg entries that have a >= or <= like "xorg-server>=1.7.0" (commonly used for ATI drivers).

xenoterracide commented on 2010-04-08 20:33

This is just a bash script right shouldn't it use the arch=('any') ? since it will run wherever bash does...