paru
paru copied to clipboard
Arch AUR paru-bin package fails to build on ARM armv7
I reported this in the comments on the Arch paru-bin AUR page.
The paru-bin AUR package fails to build on Arch 32 bit ARM because for pacman 6.1 it was changed to depend on libalpm.so>=14-64 but armv7 pacman 6.1.0 provides libalpm.so=14-32. Possibly paru-bin should just depend on libalpm.so>=14?
$ aur-get paru-bin
Cloning into 'paru-bin'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (4/4), done.
==> Making package: paru-bin 2.0.3-3 (Tue 19 Mar 2024 08:00:34 AM AEST)
==> Checking runtime dependencies...
==> Installing missing dependencies...
error: target not found: libalpm.so>=14-64
==> ERROR: 'pacman' failed to install missing dependencies.
==> Missing dependencies:
-> libalpm.so>=14-64
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.
$ uname -a
Linux pi2 6.6.21-2-rpi #1 SMP Wed Mar 13 13:59:47 MDT 2024 armv7l GNU/Linux
$ pacman -Qi pacman
Name : pacman
Version : 6.1.0-3
Description : A library-based package manager with dependency support
Architecture : armv7h
URL : https://www.archlinux.org/pacman/
Licenses : GPL-2.0-or-later
Groups : None
Provides : libalpm.so=14-32
Depends On : bash glibc libarchive curl gpgme pacman-mirrorlist gettext gawk coreutils gnupg grep
Optional Deps : perl-locale-gettext: translation support in makepkg-template
Required By : arch-install-scripts archlinux-keyring base pacman-contrib pacutils pkgfile pyalpm yay-bin
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 4.78 MiB
Packager : Arch Linux ARM Build System <[email protected]>
Build Date : Sat 16 Mar 2024 10:41:58 AM AEST
Install Date : Mon 18 Mar 2024 07:15:02 AM AEST
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
I have confirmed that this couldn't have worked anyway, even it attempting to use it, and it has likely been generating filesystem related errors in the application log, since the code specifying the texture path was bugged.