Из свеженького:

[mutabor@builder SPECS]$ rpmbsh meld.spec 
Target ALT Linux system: SS, use /etc/apt/apt.conf.SS
ошибка: Macro %gpl2plus not found
ошибка: строка 9: License: %gpl2plus

ошибка: запрос файла спецификации meld.spec не удался, невозможно разобрать файл
ошибка: Macro %gpl2plus not found
ошибка: строка 9: License: %gpl2plus

ошибка: запрос файла спецификации meld.spec не удался, невозможно разобрать файл
add_changelog: meld.spec: version "" unchanged, skipping
skip changelog editing without EDITOR var
Просто упаковывается meld-1.1.5.1-alt2.qa1.src.rpm
Платформы для сборки: i586
Сборка для платформы i586
ошибка: Macro %gpl2plus not found
ошибка: строка 9: License: %gpl2plus

Error: Error with rpmbuild

apt-get install rpm-build-licenses

[mutabor@builder meld-1.1.5.1]$ apt-get install rpm-build-licenses
E: Запись в /var/cache/apt/ невозможна
E: Невозможно прочитать список пакетов или файл статуса.

apt-get вызывать из-под суперпользователя, конечно :)

Под root: 
su -
перед этой командой

Представьте, я знаю ;) Но, во-первых, в данном случае у меня нет такой
возможности, а во-вторых, rpmbsh для того и нужен, чтобы собирать пакет на
основании спека без привилегий суперпользователя. Как root я могу просто
поставить нужные пакеты в основную систему и не заморачиваться с rpmbsh.

Да, это такой недостаток rpmbsh (пакет собирается без всяких ухищрений в 
хост-системе).
Я так понимаю особого решения, кроме применённого в gear, нет.

Я слышал, что hasher может собирать пакет не из .src.rpm, а из .pkg.tar, на
этапе создания которого зависимости не нужны. Может быть, в etersoft-build-utils
имеет смысл реализовать эту функциональность?

Я бы, кстати, с удовольствием увидел в etersoft-build-utils аналог rpmbsh для
git-репозиториев. Как вариант, обучить rpmbsh работать с git-репозиториями.

Дык сто лет как уже.

Да, Денис Смирнов давно прикрутил. Замечания принимаются.
Особо отмечу, что принципы работы с rpmbb/bsh не меняются, 
спек указывать надо по-прежнему, несмотря на то, что при работе с git
это как бы не нужно.

А в принципе возможно ли следующее: на основании спека создаётся .pkg.tar (не
обязательно при работе с git), и он скармливается хэшеру? Это помогло бы
(возможно, не в 100%, но уж в 90%-то точно) решить проблему с неопределёнными на
этапе сборки исходного пакета макросами.

Насколько я понял именно так и собирается пакет с помощью
 $ gear --hasher -- hsh
Эта команда как раз и занимается созданием .pkg.tar, который скармливает хешеру

Кстати, проблемы с зависимостями могут быть двух видов... Для сборки пакета из
src.rpm и для сборки самого src.rpm...

И тут есть интересная особенность... Дело в том, что rpm не всегда способен
собрать правильный src.rpm без некого минимального набора пакетов... Этот
минимальный набор иногда требует расширения... Для этого существует
BuildRequires(pre) зависимости...

На самом деле gear --hasher удовлетворяет большинству задумок... В этом плане у
rpmbsh есть существенный недостаток - он собирает src.rpm-пакет на хостовой
системе. А это надо выполнять в чруте, как hasher собственно и делает при
передаче ему некого .pkg.tar

Может быть меня кто-нибудь научит делать .pkg.tar
и мы модернизируем rpmbsh?

(In reply to comment #14)
> Может быть меня кто-нибудь научит делать .pkg.tar
> и мы модернизируем rpmbsh?

Это такой tar, в котором все исходники и spec. Возможно еще заголовок тома 
совпадает с именем spec-файла. Только как из spec'а узнать все исходники? 
gear'e их прямо указывают отдельно, а вот без него я думаю никак.

Может быть просто делать его из того cpio, который в src.rpm?

(In reply to comment #16)
> Может быть просто делать его из того cpio, который в src.rpm?

Если есть src.rpm, то его можно собрать. Если я правильно понял, то именно в 
создании его проблема и заключается.
Эта задача в общем случае не разрешима в принципе. Собрать rpm можно только при 
удовлетворении всех зависимостей. gear это делает, ставя все зависимости в 
hasher, а затем копируя туда все исходники, которые ему явно указаны и spec. А 
затем уже собирая их там. Рекомендую просто использовать gear. В принципе, 
задачу можно решить дополнительно указывая список исходников, скажем по одному 
на строку в файле. Темы связанные с этим обсуждались в devel, так что я 
практически уверен, что другого решения нет.

(In reply to comment #17)
> Собрать rpm можно только при удовлетворении всех зависимостей.
Но собрать src.rpm можно не имея всех зависимостей, и об этом речь.

(In reply to comment #18)
> (In reply to comment #17)
> > Собрать rpm можно только при удовлетворении всех зависимостей.
> Но собрать src.rpm можно не имея всех зависимостей, и об этом речь.

Хорошо. Описываю проблему, как я ее вижу подробнее.
Необходимо собрать пакет по спеку и исходникам в системе, в которой не стоят 
все зависимости, используя hasher.
Для этого hasher'у надо передать спек и все исходники, больше ему ничего не 
надо. Спек мы знаем, остаются исходники. Чаще всего их можно взять из спека, но 
в некоторых пакетах при указании исходников используются макросы (например в 
kdebase). Чаще всего это %version. Такое можно решить выполнив часть работы с 
помощью утилит hasher'а. Но некоторые используют и более хитрые макросы, для 
раскрытия которых, необходимы некоторые пакеты предоставляющие макросы. При 
этом эти пакеты могут даже стоять в системе, но быть не тех версий, которые 
вытянет hasher потом. В частности мы наблюдали такие проблемы в системе, где 
установлен python-2.4, тогда как в сизифе -- python-2.5.
Таким образом работать со спеком возможно только в том стиле, которыйя описал в 
своем сообщении http://lists.altlinux.org/pipermail/devel/2008-May/074855.html. 
То есть, надо изначально создавать окружение для пакета, потом копировать туда 
спек и анализировать зависимости уже внутри hasher. Затем надо опять-таки 
внутри hasher выяснять все исходники для пакета и только затем собирать pkg.tar 
по полученной информации (при этом, чтобы не собирать окружение заново, 
пользоваться надо утилитой hsh-rebuild). Правда его можно не собирать, а просто 
скопировать исходники в .in и выполнить команды для сборки с помощью hsh-run.

Можно (поначалу) даже упростить подход. Всё равно при этом класс собираемых с
помощью rpmbsh пакетов существенно расширится по сравнению с текущим состоянием.
Для этого сначала с помощью rpm -bE получаем спек с (возможно недо)раскрытыми
макросами. Если видим, что все Source и Patch раскрылись (что сработает в 99%
случав, если не больше), то создаём chroot, копируем туда исходники и спек и
запускаем hasher. Если не раскрылись, то интеллигентно ругаемся на то, что
"данный пакет невозможно собрать с помощью rpmbsh в текущем сборочном окружении".

(In reply to comment #20)
> Можно (поначалу) даже упростить подход. Всё равно при этом класс собираемых с
> помощью rpmbsh пакетов существенно расширится по сравнению с текущим 
> состоянием.
> Для этого сначала с помощью rpm -bE получаем спек с (возможно недо)раскрытыми
> макросами.

Ну, вот в этом-то вся и проблема... сборочные зависимости таким образом ставятся
в сам сборочный сервер, причём какие они потребуются для раскрытия макросов
заранее неизвестно... При первоначальном разворачивании процесс начинается с
того, что в систему, по мере необходимости, ставят кучу пакетов... Далее это
может привести к конфликтам, когда всё что нужно для сборки разных пакетов в
систему не устанавливается...

> Если видим, что все Source и Patch раскрылись (что сработает в 99%
> случав, если не больше), то создаём chroot, копируем туда исходники и спек и
> запускаем hasher. Если не раскрылись, то интеллигентно ругаемся на то, что
> "данный пакет невозможно собрать с помощью rpmbsh в текущем сборочном
> окружении".

Я так понимаю, что rpmbsh, в данном случае, расматривается, как средство работы
из стандартной сборочной среды RPM (~/RPM/{BUILD,RPMS,SOURCES,SPECS,SRPMS}). И
вышеописанное поведение в таком случае оправдано...

Просто получается, что rpmbsh выступает, как более универсальное средство, чем
gear. Менее надёжное в плане организации универсальной сборочной среды, но более
удобное...

Хотелось бы это подчеркнуть, поскольку rpmbsh можно использовать как для
обычного SPEC-файла в сборочном каталоге RPM, так и для gear-репозитория. В этом
плане, раз уж внутренние механизмы по этому поводу раличаются, я думаю стоит
сохранить для gear стандартную схему (без разворачивания SPEC-файла) - это
позволит, не задумываясь о последствиях, использовать rpmbsh вместо gear
--hasher. Для обычной сборки, из сборочного каталога RPM, вышеописанная схема
действительно является достаточной в 95% случаев. 

Что в версии 1.5.1?

Да, теперь всё работает :) Спасибо!

Раз работает, закрываю.