Все об Arch Linux

Arch Linux будет тем, что вы из него сделаете!

Сборка из AUR падает: submodules, checksum, python

Сборка из AUR падает по трём типичным причинам: не склонировались git-сабмодули, устарели контрольные суммы в PKGBUILD и пакет собран под другую версию python. Каждая чинится за пару минут: читаешь вывод makepkg, проверяешь актуальность PKGBUILD, пересчитываешь хэши командой makepkg -g и при необходимости собираешь из исходников. Ниже разбираю все три случая по порядку.

Почему makepkg падает при сборке из AUR

makepkg собирает пакет в несколько этапов: скачивает исходники из source, проверяет контрольные суммы, распаковывает, компилирует, упаковывает. На любом этапе он может остановиться с ошибкой, и тогда сборка прерывается. AUR-хелперы вроде yay и paru просто показывают тебе вывод makepkg, так что диагностировать приходится самому. Про установку пакетов из AUR читай в статье «Установка пакетов из AUR».

Три ошибки встречаются чаще всего: не склонировались git-сабмодули, не совпали контрольные суммы, пакет собран под другую версию python. Разберу каждую отдельно.

Что делать, если не склонировались git submodules

Когда в 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-пакеты: как обновляются».

Как починить checksum mismatch

Контрольные суммы в 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

Третья классическая ошибка выглядит так: пакет собран под python 3.11, а в системе стоит 3.13. Установить такой пакет нельзя, потому что скомпилированные модули привязаны к конкретной версии интерпретатора. Расширения на C собираются под ABI конкретного python, и в новой версии они просто не загрузятся с ошибкой вроде undefined symbol или ModuleNotFoundError.

Проверь версию python в системе:

python --version

Если пакет собран под старую версию, вариантов два. Первый: поискать обновлённый PKGBUILD. Часто кто-то уже пересобрал пакет под новую версию python, и в AUR лежит свежая версия. Проверь комментарии на странице пакета и дату последнего обновления.

Второй вариант: собрать пакет из исходников самому. При сборке makepkg скомпилирует расширения под твой python 3.13, и пакет встанет нормально. Это работает, если исходники поддерживают новую версию. Если нет, придётся ждать обновления апстрима или искать альтернативу.

Какие ошибки makepkg показывает чаще всего

Вот несколько реальных сообщений об ошибках и их причины.

==> 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 с версией апстрима. Если 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 только осознанно

Флаг --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, но только когда ты уверен, что эталон изменился легитимно. Если апстрим не обновлялся, а хэш не совпал, пропуск проверки скроет возможную подмену файла. Это осознанный риск, а не рутина.

Почему makepkg собирает не ту версию, что указана в AUR?

Скорее всего, PKGBUILD устарел: апстрим выпустил новый релиз, а пакет в AUR ещё не обновили. makepkg скачивает исходники по ссылке из source, и если там указан тег или архив старой версии, соберётся старая версия. Проверь дату обновления пакета и комментарии на его странице.

Что делать, если сабмодуль лежит в закрытом репозитории?

Собрать такой пакет без доступа не получится: makepkg не сможет клонировать сабмодуль. Если у тебя есть доступ к репозиторию, добавь свои учётные данные в git-конфиг или используй SSH-ключ. Если доступа нет, пакет для тебя недоступен, и это нормально.

Как узнать, под какую версию python собран пакет?

Посмотри в PKGBUILD переменную depends: там указано, какой python нужен. Если пакет собран под python 3.11, а в системе 3.13, в depends будет что-то вроде python<3.12. Сравни с выводом python --version.

Полезные ресурсы

Заключение

Сборка из AUR падает по трём типичным причинам: не склонировались git-сабмодули, устарели контрольные суммы и пакет собран под другую версию python. В каждом случае порядок одинаковый: прочитай вывод makepkg, проверь актуальность PKGBUILD, пересчитай хэши, обнови зависимости и только потом думай про --skipchecksums. Большинство проблем решается за пару минут, а rm -rf src pkg даёт чистый старт, если сборка застряла.



Не получилось? Поможем настроить

Задай вопрос в чате — отвечаем быстро, по делу и без воды.

Читайте также

Комментарии

Загрузка…

Откроется GitHub: создайте новый issue с вашим комментарием (кнопка «Submit new issue»). После отправки обновите эту страницу — комментарий появится ниже.

Telegram Max