Arch Linux User Repository

There's now a custom repo and binaries again. Though only for x86_64 currently.

Custom Repo

[pacman-static]
SigLevel = Required
Server = https://pkgbuild.com/~morganamilo/$repo/$arch

Pre compiled binaries

https://pkgbuild.com/~morganamilo/pacman-static/x86_64/bin/

For maintainance of the keys:

for i in $( . PKGBUILD; echo "${validpgpkeys[@]}" ); do gpg --receive "$i"; gpg -a --export "$i" > "keys/pgp/$i.asc" ; done

Ideal would be if we could have a 'keys/pgp' directory as for the "normal" packages, where we could deposit all PGP keys necessary to build the package:

So we could keep the keys of for instance 'openssl' there:

ls keys/pgp/
7953AC1FBC3DC8B3B292393ED5E9E43F7DF9EE8C.asc  A21FAB74B0088AA361152586B8EF1A6BA9DA2D5C.asc
8657ABB260F056B1E5190839D9C4D26D0E604491.asc  EFC0A467D613CB83C7ED6D30D894E2CE8B3D79F5.asc

It seems there should probably be a list of GPG keys you need to import to build this somewhere. I ended up extracting all the IDs from the PKGBUILD, but it would be nice to have it collected in a single list given how many there are. As of writing this I ended up with the following list

gpg --recv-keys \
6645B0A8C7005E78DB1D7864F99FFE0FEAE999BD B8151B117037781095514CA7BBDFFC92306B1121 \
27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2 \
8657ABB260F056B1E5190839D9C4D26D0E604491 7953AC1FBC3DC8B3B292393ED5E9E43F7DF9EE8C \
A21FAB74B0088AA361152586B8EF1A6BA9DA2D5C EFC0A467D613CB83C7ED6D30D894E2CE8B3D79F5 \
8657ABB260F056B1E5190839D9C4D26D0E604491 7953AC1FBC3DC8B3B292393ED5E9E43F7DF9EE8C \
A21FAB74B0088AA361152586B8EF1A6BA9DA2D5C EFC0A467D613CB83C7ED6D30D894E2CE8B3D79F5 \
5ED46A6721D365587791E2AA783FCD8E58BCAFBA 3690C240CE51B4670D30AD1C38EE757D69184620 \
22D465F2B4C173803B20C6DE59FCF207FEA7F445 EC3CFE88F6CA0788774F5C1D1AA44BE649DE760A \
4EF4AC63455FC9F4545D9B7DEF8FE99528B52FFD D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 \
031EC2536E580D8EA286A9F22071B08A33BD3F06 6DAA6E64A76D2840571B4902528897B826403ADA \
AC8E115BF73E2D8D47FA9908E98E9B2D19C6C8BD A5A45B12AD92D964B89EEE2DEC560C81CEC2276E \
DB2C7CF1B4C265FAEF56E3FC5848A18B8F14184B

In fact I believe that it is recommended to bundle the required keys in the package repo these days? I'm pretty sure I saw something about that in some packaging guidelines (probably on the wiki).

The key EFC0A467D613CB83C7ED6D30D894E2CE8B3D79F5 for openssl has been expired.

updated nghttp2 to 1.59.0 and zlib to 1.3.1

Thanks for all of the hints! I did not realize that pacman-key was a shell script. The short conclusion to my problem is that I was able to fix it by running: sudo sed -i s'/pacman-conf/pacman-conf-static/'g /usr/bin/pacman-key.

Good to know that I can also easily look at the code to manually replicate the GPG actions. Also good to know about makepkg being able to use pacman-static! I try to use pre-compiled packages as much as possible (either my own or from the Chaotic repository).

I am the creator of winesapOS and we have an automated upgrade script. One thing I am working on is to refactor it out of the winesapOS project and for it to to work for any generic Arch Linux distribution. I will apply these teachings there!

https://github.com/LukeShortCloud/winesapOS/blob/3.4.0/scripts/winesapos-upgrade.sh

No changes need to be made to the pacman-static package. It was just a lack of knowledge on my side for how some of this worked. Thanks again! :-)

Actually:

    for exe in "${pkgdir}"/usr/bin/*; do
        if [[ -f ${exe} && $(head -c4 "${exe}") = $'\x7fELF' ]]; then
            mv "${exe}" "${exe}"-static
        else
            rm "${exe}"
        fi
    done

makes static versions of things which are recognized as ELF binaries. pacman-key and all the other "binaries" you mentioned are shell scripts.

The shell scripts might contain calls to pacman instead of pacman-static, that might be something one could patch, on the other hand the pacman to use can be set via environment:

# set pacman command if not already defined
PACMAN=${PACMAN:-pacman}

So, something like PACMAN=pacman-static makepkg -s should actually work. pacman-key should actually just manipulate the keys in /etc/pacman.d/gnupg without the help of pacman or pacman-static (as far as I can tell). Besides, those can also be manipulated directly with gpg.

Building packages while your standard pacman is broken, is maybe not a smart idea to begin with and you should fix your standard pacman first.

Well, "repo-elaphants" are actually absolutely crucial to run statically.. ;-)

Opinions?

Would it be possible to add pacman-key-static to this build? For situations where (1) Pacman is broken and (2) the GPG keyrings used by Pacman are also broken this would be really helpful. I know I can set SigLevel = Never in the Pacman configuration to workaround those issues but it would be ideal to have trusted packages.

I compared the binaries from pacman and pacman-static packages. These are the missing ones: makepkg, makepkg-template, pacman-db-upgrade, pacman-key, repo-add, repo-elephant, and repo-move. I am not sure how useful most of those are to have as statically built but I do have a lot of old systems (last update was from 1.5+ years ago) where at least having pacman-key-static would be beneficial. On those systems, the GPG keys are so old that they need to be recreated from scratch. This required workaround below cannot be done when GLIBC was upgraded but pacman and pacman-key are broken:

rm -r -f /etc/pacman.d/gnupg
pacman-key --init
pacman-static -S archlinux-keyring

updated c-ares to 1.25.0

The downgrading issue didn't appear again with pkgver=12.