Сборка из AUR падает по трём типичным причинам: не склонировались git-сабмодули, устарели контрольные суммы в PKGBUILD и пакет собран под другую версию python. Каждая чинится за пару минут: читаешь вывод makepkg, проверяешь актуальность PKGBUILD, пересчитываешь хэши командой makepkg -g и при необходимости собираешь из исходников. Ниже разбираю все три случая по порядку.
makepkg собирает пакет в несколько этапов: скачивает исходники из source, проверяет контрольные суммы, распаковывает, компилирует, упаковывает. На любом этапе он может остановиться с ошибкой, и тогда сборка прерывается. AUR-хелперы вроде yay и paru просто показывают тебе вывод makepkg, так что диагностировать приходится самому. Про установку пакетов из AUR читай в статье «Установка пакетов из AUR».
Три ошибки встречаются чаще всего: не склонировались git-сабмодули, не совпали контрольные суммы, пакет собран под другую версию python. Разберу каждую отдельно.
Когда в source указан git+https://..., makepkg клонирует репозиторий целиком. Если в проекте есть сабмодули, то есть подключённые сторонние репозитории, клонирование может оборваться: сабмодуль лежит в закрытом репозитории, его URL умер или сеть оборвалась на середине. В выводе ты увидишь что-то вроде fatal: unable to access или Failed to clone submodule, а в каталоге src вместо содержимого сабмодуля окажется пустая папка.
Проверь, что реально склонировалось:
ls src/имя-проекта
ls src/имя-проекта/путь-к-сабмодулю
Если папка сабмодуля пустая, подтяни его вручную:
cd src/имя-проекта
git submodule update --init --recursive
После этого сборку можно запускать заново. Но ручной фикс слетит при следующей попытке, потому что makepkg пересоздаёт каталог src. Правильное решение — прописать сабмодули в PKGBUILD. Рабочих варианта два.
Первый: добавить сабмодуль отдельным элементом в source:
source=("git+https://github.com/автор/проект.git"
"git+https://github.com/автор/сабмодуль.git")
Второй: подтянуть сабмодули в функции prepare():
prepare() {
cd "$srcdir/проект"
git submodule update --init --recursive
}
Второй вариант проще, если сабмодулей несколько. Формат source и функции PKGBUILD подробно разобраны в статье «makepkg: всё, что нужно знать». Про то, как устроены git-пакеты и как они обновляются, читай в статье «Git-пакеты: как обновляются».
Контрольные суммы в PKGBUILD записаны в переменной sha256sums. Они считаются от конкретной версии исходников. Когда апстрим выпускает новый релиз, а PKGBUILD в AUR ещё не обновили, makepkg скачивает свежий архив, считает его хэш и сравнивает со старым. Не совпало — ошибка checksum mismatch и отказ собирать.
Сначала убедись, что апстрим действительно обновился. Сравни версию из PKGBUILD с версией на сайте проекта или в git-репозитории апстрима:
grep -E '^(pkgver|pkgrel)=' PKGBUILD
Если версия устарела, а PKGBUILD не трогали давно, скорее всего, дело именно в этом.
Пересчитать хэши проще всего командой makepkg -g:
makepkg -g
Она скачает исходники и выведет новые контрольные суммы. Скопируй вывод в PKGBUILD в переменную sha256sums. Есть и автоматический вариант — утилита updpkgsums из пакета pacman-contrib:
updpkgsums
Она сама обновит sha256sums в PKGBUILD. После этого запускай makepkg заново.
Важный момент: несовпадение хэша может означать и подмену файла. Если апстрим не обновлялся, а хэш вдруг другой, это повод насторожиться. Контрольные суммы защищают тебя от подмены исходников, поэтому менять их без проверки нельзя.
Третья классическая ошибка выглядит так: пакет собран под python 3.11, а в системе стоит 3.13. Установить такой пакет нельзя, потому что скомпилированные модули привязаны к конкретной версии интерпретатора. Расширения на C собираются под ABI конкретного python, и в новой версии они просто не загрузятся с ошибкой вроде undefined symbol или ModuleNotFoundError.
Проверь версию python в системе:
python --version
Если пакет собран под старую версию, вариантов два. Первый: поискать обновлённый PKGBUILD. Часто кто-то уже пересобрал пакет под новую версию python, и в AUR лежит свежая версия. Проверь комментарии на странице пакета и дату последнего обновления.
Второй вариант: собрать пакет из исходников самому. При сборке makepkg скомпилирует расширения под твой python 3.13, и пакет встанет нормально. Это работает, если исходники поддерживают новую версию. Если нет, придётся ждать обновления апстрима или искать альтернативу.
Вот несколько реальных сообщений об ошибках и их причины.
==> ERROR: Failure while downloading ... означает, что makepkg не смог скачать исходник. Причина: битая ссылка в source, недоступный сервер или обрыв сети. Проверь URL вручную через curl -I и повтори сборку.
==> ERROR: One or more PGP signatures could not be verified! появляется, когда не прошла проверка подписи. Причина: устаревший ключ в validpgpkeys или отсутствие ключа в связке. Обнови ключи через gpg --refresh-keys и добавь нужный в validpgpkeys.
error: failed to commit transaction (conflicting files) появляется, когда пакет собрался, но не ставится. Причина: файлы конфликтуют с уже установленными пакетами. Смотри вывод pacman: он перечисляет конфликтующие файлы и пакеты.
/usr/bin/python: No module named setuptools означает, что сборка падает внутри build() из-за нехватки зависимостей. Причина: в makedepends не указан пакет, нужный для сборки. Добавь его в makedepends и пересобери.
gcc: error: unrecognized command-line option появляется, когда компилятор не понимает флаг из CFLAGS или configure. Причина: слишком новые флаги для старого компилятора или наоборот. Убери проблемный флаг из makepkg.conf или обнови тулчейн.
Когда makepkg падает, действуй по шагам, не прыгая с места в карьер.
Ошибка всегда в конце вывода, но причина может прятаться выше. Пролистай лог от начала: там видно, что именно скачалось, какие суммы посчитались и на каком шаге всё сломалось.
makepkg помечает этапы заголовками вроде ==> Extracting sources и ==> Starting build(). Смотри, на каком заголовке вывод оборвался: после Extracting sources проблема в распаковке, после Starting build() в компиляции. Строка ==> ERROR: в конце указывает на конкретный шаг, но настоящая причина обычно на несколько строк выше.
Если вывод не помещается в терминал, сохрани его в файл:
makepkg 2>&1 | tee build.log
grep -n -E 'error|fatal|ERROR' build.log
Флаг --log пишет подробный лог каждой функции в каталог src. Он пригодится, когда makepkg падает внутри build() и в терминал попадает только хвост вывода.
Сравни версию в PKGBUILD с версией апстрима. Если PKGBUILD старый, обнови его или дождись обновления в AUR. Собирать устаревший PKGBUILD бессмысленно: он упадёт на той же ошибке.
Свежесть PKGBUILD удобно проверить так: склонируй его из AUR и посмотри историю изменений:
git clone https://aur.archlinux.org/имя-пакета.git /tmp/имя-пакета
cd /tmp/имя-пакета
git log --oneline -5
Если последний коммит старый, а апстрим выпустил новый релиз, пакет устарел. Сравни свой PKGBUILD с актуальным из AUR:
diff PKGBUILD /tmp/имя-пакета/PKGBUILD
Разница покажет, что поменялось: версия, хэши, зависимости. Часто достаточно скопировать свежий PKGBUILD и пересобрать. Про то, на что смотреть в PKGBUILD перед сборкой, читай в статье «Проверка PKGBUILD: 10 вопросов».
Если версия актуальна, а хэши не совпадают, выполни makepkg -g или updpkgsums и обнови sha256sums.
makepkg -g выводит суммы в формате, готовом для вставки в PKGBUILD. updpkgsums делает то же самое автоматически: скачивает исходники, считает хэши и переписывает sha256sums сама. После обновления сумм запускай сборку заново.
Проверь, что все зависимости из depends установлены и система обновлена:
pacman -Syu
Иногда сборка падает не из-за PKGBUILD, а из-за устаревшей зависимости. Про сломанные зависимости после обновления читай в статье «Зависимости AUR ломаются после обновления».
Флаг --skipchecksums отключает проверку контрольных сумм:
makepkg --skipchecksums
Пользоваться им стоит только в одном случае: ты сам проверил, что апстрим легитимно обновил архив, а PKGBUILD ещё не обновили. В остальных ситуациях это риск: без проверки сумм ты не узнаешь, что скачал именно то, что задумано. Подмена исходников на зеркале или в цепочке доставки останется незамеченной.
Если makepkg падает на одной и той же ошибке после всех правок, удали каталоги src и pkg в папке пакета:
rm -rf src pkg
makepkg пересоздаст их с нуля при следующем запуске. Иногда в src остаётся мусор от прошлых попыток: старые файлы конфигурации, объектные файлы, частично распакованные исходники. Такой мусор переживает пересборку и ломает её снова.
То же самое делает флаг -C:
makepkg -C
Он удаляет src и pkg перед сборкой, но не трогает скачанные архивы. Если хочешь начать совсем с чистого листа, удали ещё и кэш исходников в ~/.cache/yay или ~/.cache/paru.
Общая методика диагностики таких проблем описана в статье «Методика решения проблем в Arch Linux».
Можно, флагом --skipchecksums, но только когда ты уверен, что эталон изменился легитимно. Если апстрим не обновлялся, а хэш не совпал, пропуск проверки скроет возможную подмену файла. Это осознанный риск, а не рутина.
Скорее всего, PKGBUILD устарел: апстрим выпустил новый релиз, а пакет в AUR ещё не обновили. makepkg скачивает исходники по ссылке из source, и если там указан тег или архив старой версии, соберётся старая версия. Проверь дату обновления пакета и комментарии на его странице.
Собрать такой пакет без доступа не получится: makepkg не сможет клонировать сабмодуль. Если у тебя есть доступ к репозиторию, добавь свои учётные данные в git-конфиг или используй SSH-ключ. Если доступа нет, пакет для тебя недоступен, и это нормально.
Посмотри в PKGBUILD переменную depends: там указано, какой python нужен. Если пакет собран под python 3.11, а в системе 3.13, в depends будет что-то вроде python<3.12. Сравни с выводом python --version.
Сборка из AUR падает по трём типичным причинам: не склонировались git-сабмодули, устарели контрольные суммы и пакет собран под другую версию python. В каждом случае порядок одинаковый: прочитай вывод makepkg, проверь актуальность PKGBUILD, пересчитай хэши, обнови зависимости и только потом думай про --skipchecksums. Большинство проблем решается за пару минут, а rm -rf src pkg даёт чистый старт, если сборка застряла.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии