15647 2008-05-14 12:59:18 +0400 rpmbsh не стартует при наличии неизвестных макросов 2009-01-09 03:44:01 +0300 1 1 4 Development Sisyphus etersoft-build-utils unstable all Linux CLOSED FIXED P2 normal --- 1 mutabor lav ktirf lav rlz sin qa-sisyphus oldest_to_newest 69919 0 mutabor 2008-05-14 12:59:18 +0400 Если в spec-файле имеется макрос, определённый в одном из пакетов, от которого зависит сборка, а в окружении, из которого запускается rpmbsh, этот пакет не установлен, то запуск rpmbsh завершается с ошибкой, которой быть не должно, так как в сборочной среде, создаваемой в chroot этот пакет будет установлен по зависимостям и там этот макрос окажется определённым.Вот пример такой ситуации: [mutabor@builder SPECS]$ rpmbsh xmms-in-modplug.spec Target ALT Linux system: SS, use /etc/apt/apt.conf.SS ошибка: Macro %xmms_inputdir not found 2< %xmms_inputdir ошибка: Незакрытая {: {?%xmms_inputdir 2< (пусто) ошибка: xmms-in-modplug.spec:31: parseExpressionBoolean код возврата: -1 ошибка: запрос файла спецификации xmms-in-modplug.spec не удался, невозможно разобрать файл ошибка: Macro %xmms_inputdir not found 2< %xmms_inputdir ошибка: Незакрытая {: {?%xmms_inputdir 2< (пусто) ошибка: xmms-in-modplug.spec:31: parseExpressionBoolean код возврата: -1 ошибка: запрос файла спецификации xmms-in-modplug.spec не удался, невозможно разобрать файл add_changelog: xmms-in-modplug.spec: version "" unchanged, skipping skip changelog editing without EDITOR var Просто упаковывается xmms-in-modplug-2.05-alt1.3.src.rpm Платформы для сборки: i586 Сборка для платформы i586 ошибка: Macro %xmms_inputdir not found 2< %xmms_inputdir ошибка: Незакрытая {: {?%xmms_inputdir 2< (пусто) ошибка: /srv/mutabor/RPM/SPECS/xmms-in-modplug.spec:31: parseExpressionBoolean код возврата: -1 Error: Error with rpmbuild Соответственно выдержки из xmms-in-modplug.spec: %ifndef %xmms_inputdir %define xmms_inputdir %(xmms-config --input-plugin-dir) %endif и далее: %install %make bindir=%buildroot%_bindir \ plugindir=%buildroot%xmms_inputdir install %files %xmms_inputdir/*.so Steps to Reproduce: 1. Скачать их Сизифа пакет с исходниками xmms-in-modplug 2. Установить пакет 3. В каталоге со спеками выполнить rpmbsh xmms-in-modplug.spec Actual Results: Приведённая выше ошибка Expected Results: Нормальная сборка пакета 70618 1 mutabor 2008-05-27 11:51:31 +0400 Из свеженького: [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 70619 2 cas 2008-05-27 12:51:59 +0400 apt-get install rpm-build-licenses 70630 3 mutabor 2008-05-27 13:52:33 +0400 [mutabor@builder meld-1.1.5.1]$ apt-get install rpm-build-licenses E: Запись в /var/cache/apt/ невозможна E: Невозможно прочитать список пакетов или файл статуса. 70632 4 ktirf 2008-05-27 13:54:12 +0400 apt-get вызывать из-под суперпользователя, конечно :) 70633 5 cas 2008-05-27 14:23:09 +0400 Под root: su - перед этой командой 70643 6 mutabor 2008-05-27 14:57:20 +0400 Представьте, я знаю ;) Но, во-первых, в данном случае у меня нет такой возможности, а во-вторых, rpmbsh для того и нужен, чтобы собирать пакет на основании спека без привилегий суперпользователя. Как root я могу просто поставить нужные пакеты в основную систему и не заморачиваться с rpmbsh. 70690 7 lav 2008-05-28 00:12:04 +0400 Да, это такой недостаток rpmbsh (пакет собирается без всяких ухищрений в хост-системе). Я так понимаю особого решения, кроме применённого в gear, нет. 70712 8 mutabor 2008-05-28 10:44:44 +0400 Я слышал, что hasher может собирать пакет не из .src.rpm, а из .pkg.tar, на этапе создания которого зависимости не нужны. Может быть, в etersoft-build-utils имеет смысл реализовать эту функциональность? 70768 9 ktirf 2008-05-28 16:03:23 +0400 Я бы, кстати, с удовольствием увидел в etersoft-build-utils аналог rpmbsh для git-репозиториев. Как вариант, обучить rpmbsh работать с git-репозиториями. 70776 10 vvk 2008-05-28 16:22:56 +0400 Дык сто лет как уже. 70841 11 lav 2008-05-28 23:25:45 +0400 Да, Денис Смирнов давно прикрутил. Замечания принимаются. Особо отмечу, что принципы работы с rpmbb/bsh не меняются, спек указывать надо по-прежнему, несмотря на то, что при работе с git это как бы не нужно. 70899 12 mutabor 2008-05-29 11:51:25 +0400 А в принципе возможно ли следующее: на основании спека создаётся .pkg.tar (не обязательно при работе с git), и он скармливается хэшеру? Это помогло бы (возможно, не в 100%, но уж в 90%-то точно) решить проблему с неопределёнными на этапе сборки исходного пакета макросами. 70946 13 sin 2008-05-29 18:17:22 +0400 Насколько я понял именно так и собирается пакет с помощью $ gear --hasher -- hsh Эта команда как раз и занимается созданием .pkg.tar, который скармливает хешеру Кстати, проблемы с зависимостями могут быть двух видов... Для сборки пакета из src.rpm и для сборки самого src.rpm... И тут есть интересная особенность... Дело в том, что rpm не всегда способен собрать правильный src.rpm без некого минимального набора пакетов... Этот минимальный набор иногда требует расширения... Для этого существует BuildRequires(pre) зависимости... На самом деле gear --hasher удовлетворяет большинству задумок... В этом плане у rpmbsh есть существенный недостаток - он собирает src.rpm-пакет на хостовой системе. А это надо выполнять в чруте, как hasher собственно и делает при передаче ему некого .pkg.tar 70982 14 lav 2008-05-30 09:55:45 +0400 Может быть меня кто-нибудь научит делать .pkg.tar и мы модернизируем rpmbsh? 70988 15 rlz 2008-05-30 11:33:17 +0400 (In reply to comment #14) > Может быть меня кто-нибудь научит делать .pkg.tar > и мы модернизируем rpmbsh? Это такой tar, в котором все исходники и spec. Возможно еще заголовок тома совпадает с именем spec-файла. Только как из spec'а узнать все исходники? gear'e их прямо указывают отдельно, а вот без него я думаю никак. 71059 16 lav 2008-05-31 02:12:32 +0400 Может быть просто делать его из того cpio, который в src.rpm? 71096 17 rlz 2008-05-31 18:33:59 +0400 (In reply to comment #16) > Может быть просто делать его из того cpio, который в src.rpm? Если есть src.rpm, то его можно собрать. Если я правильно понял, то именно в создании его проблема и заключается. Эта задача в общем случае не разрешима в принципе. Собрать rpm можно только при удовлетворении всех зависимостей. gear это делает, ставя все зависимости в hasher, а затем копируя туда все исходники, которые ему явно указаны и spec. А затем уже собирая их там. Рекомендую просто использовать gear. В принципе, задачу можно решить дополнительно указывая список исходников, скажем по одному на строку в файле. Темы связанные с этим обсуждались в devel, так что я практически уверен, что другого решения нет. 71099 18 lav 2008-06-01 00:25:19 +0400 (In reply to comment #17) > Собрать rpm можно только при удовлетворении всех зависимостей. Но собрать src.rpm можно не имея всех зависимостей, и об этом речь. 71100 19 rlz 2008-06-01 09:40:53 +0400 (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. 71228 20 mutabor 2008-06-02 18:14:31 +0400 Можно (поначалу) даже упростить подход. Всё равно при этом класс собираемых с помощью rpmbsh пакетов существенно расширится по сравнению с текущим состоянием. Для этого сначала с помощью rpm -bE получаем спек с (возможно недо)раскрытыми макросами. Если видим, что все Source и Patch раскрылись (что сработает в 99% случав, если не больше), то создаём chroot, копируем туда исходники и спек и запускаем hasher. Если не раскрылись, то интеллигентно ругаемся на то, что "данный пакет невозможно собрать с помощью rpmbsh в текущем сборочном окружении". 71237 21 sin 2008-06-02 23:36:44 +0400 (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% случаев. 83539 22 lav 2008-12-28 01:58:45 +0300 Что в версии 1.5.1? 83706 23 mutabor 2008-12-31 16:41:31 +0300 Да, теперь всё работает :) Спасибо! 84020 24 lav 2009-01-09 03:37:42 +0300 Раз работает, закрываю.