Arch Linux User Repository

Precompiled pacman-static resources

Since I am a Trusted User, you can verify my packages/binaries against my package signing key in the default keychain.

Prebuilt packages

My custom repository (i686/x86_64).

Direct links to the extracted binary.

If your computer is broken, you can download this, verify the signature with the repo keyring using pacman-key -v, and transfer via USB to your broken system:

• x86_64 uncompressed (GPG) compressed (GPG)

• i686 uncompressed (GPG) compressed (GPG)

... or you could specify --nodeps twice, as the manpage says you should do.

@eschwartz I noted the behavior was as intended with pacman downloading only the specified package, while pacman-static was downloading all the dependencies; but perhaps it was because I already had the dependencies on the other system. I have managed to work around this, in any case, using a chroot to an archlinux rootfs in the target non-archlinux system.

I must say, I love pacman-static. Thank you for contributing and maintaining this.

@moe_narrow,

1) According to the pacman manpage, the behavior you are seeing is correct and intended.

2) Even if it were a bug, do you see the same behavior with core/pacman? If so, then it isn't specific to this static build and you should discuss it somewhere more general than this page... like the pacman bug tracker.

pacman-static -Sw --nodeps still tries to pull the dependancies.

Oops, used the wrong download url in the PKGBUILD vs. the cached source tarball also used in core/zstd. Fixed now, by updating the url.

hashes for zstd does not match

sha512: ef6d95639593fed3cfb9ff4f1527c4ba38658e42f16eb3369b2a4bbe150905751bb71c6e3fe9c8bbdfceee26a540ae3e41bd0f0bc692d36db444b7da65a6e304

b2: d6410eb7cd20640fbebef63d9d78d71ac2dfc42134544412a02faa852c16b61a2939d1bbd4d98d462e0d5c2bc1a23b4991ac353ab896349d13988a191e8ee972

Yes, I discovered that while trying to bump the staticlibs this week. It turns out that GnuPG upstream has started adding pkg-config files and their new gpgrt-config tries to parse that. Apparently the new libassuan checks for that, and prefers it if found... so then it picks that up from the host instead of the custom libs this builds.

Hmm on armv7 libassuan fails to compile with

libtool: compile:  musl-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -D_FORTIFY_SOURCE=2 -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O2 -pipe -fstack-protector-strong -fno-plt -Wall -Wcast-align
-Wshadow -Wstrict-prototypes -Wpointer-arith -fPIC -DPIC -MT libassuan_la-assuan.lo -MD -MP -MF .deps/libassuan_la-assuan.Tpo -c assuan.c -o libassuan_la-assuan.o                          
In file included from assuan-defs.h:42,
                 from assuan.c:29:
assuan.h:38:10: fatal error: gpg-error.h: No such file or directory
 #include <gpg-error.h>
          ^~~~~~~~~~~~~
compilation terminated.

In the configure script above it, it says that it found libgpg-error

checking for gpg-error-config... /home/luca/aur/pacman-static/src/temp/usr/bin/gpg-error-config
checking for gpgrt-config... /usr/bin/gpgrt-config                
configure: Use gpgrt-config with /usr/lib as gpg-error-config

edit: also fails on x86_64 with extra-x86_64-build

There's no such thing as being compatible with "aur installers". This package is written according to the PKGBUILD spec, and if you find an AUR helper which cannot install it, you should report a bug to the AUR helper.

That's assuming you want to compile it yourself rather than using my generously provided precompiled builds. pacman can install from a custom repository just fine, as long as you configure it correctly...

is compatible with any aur installer ??