Created attachment 5991 [details] ssh public key Имя: Иван Александрович Карпухин Псевдоним: ikar Почта: karpuhini@yandex.ru Ментор: george@ ======================================= Здравствуйте! В моих планах разобраться с созданием и сопровождением пакетов (например, vmpk). В будущем намерен принять участие в разработке Alt Linux.
Created attachment 5992 [details] gpg public key
Есть новости?
По регламенту ожидается ответ от ментора.
Если Гоша перегружен или перестужен, можно попробовать его подстраховать. При наличии готового начального spec-файла давайте его почтой или сюда.
Created attachment 5998 [details] Spec for vmpk package За основу взят spec, распространяемый автором пакета. Однако пришлось изменить зависимости, номер релиза и исправить конфликты man страниц.
Однако пакет не собирается hasher-ом, без такой строчки в конфиге: no_sisyphus_check="packager,buildhost,gpg,changelog" Почему-то sisyphus check ругается на имя сборщика
Совершенно не требуются вот эти фрагменты, их следует удалить: # # spec file for package vmpk (Version 0.5.1) # # norootforbuild BuildRoot: %{_tmppath}/%{name}-%{version}-build Requires: qt4 libalsa libjack libphonon #%debug_package %clean rm -rf $RPM_BUILD_ROOT %defattr(-,root,root) Вероятно, также и этот вызов макроса (он вообще раскрывается?): %suse_update_desktop_file -G "Virtual MIDI Piano Keyboard" %name AudioVideo Midi Можно поправить/улучшить: -make %{?jobs:-j %jobs} VERBOSE=1 +%make_build VERBOSE=1 В %changelog стоит упомянуть, что пакет адаптирован на базе сузешного; их развесистую лицензионную шапку тоже недолюбливаю (и поэтому обычно если пишу на базе suse-спека, то скорее начисто, поглядывая к ним), но считаю уместным оставлять. В целом скрипт стоит обмахнуть cleanup_spec из rpm-utils, нередко полезен и rpmcs из etersoft-build-utils. Ну и на всякий: http://www.altlinux.org/ALT_Packaging_HOWTO
Created attachment 6002 [details] Доработанный спек Поправил. В hsh собирается.
"Совершенно не требуются вот эти фрагменты, их следует удалить: ... Requires: qt4 libalsa libjack libphonon " А почему не требуются зависимости?
(В ответ на комментарий №9) > Requires: qt4 libalsa libjack libphonon > А почему не требуются зависимости? Сгенерирует /usr/lib/rpm/lib.req -- см. rpm -qRp на полученные бинарные пакеты, там будут _и_ вписанные Вами вручную вышеперечисленные, _и_ точно заданные с точностью до soname и снимка ABI: http://ftp.linux.kiev.ua/pub/conference/peers/pereslavl/2010/trubezh2010.pdf (с. 63--66). Кстати, давно пора эту статью на вики оформить отдельной страницей...
Если доработанный спек хорош, предлагаю двинуться дальше. Также собираюсь собрать performous (https://github.com/performous/performous/wiki)
(В ответ на комментарий №11) > Если доработанный спек хорош, предлагаю двинуться дальше. Там есть что подчистить по мелочам, но это уже вкусовщина. :-) Гоша, Дима -- предложенный спек меня лично устраивает, если мнение самозваного псевдоментора что-то значит, то предлагаю переходить к п.3 http://www.altlinux.org/Team/Join/Secretary
Да пожалуйста, пожалуйста. На мне что, свет клином сошёлся?
distclean'ом!
Что можно указать в поле Source для github проекта, если архивов разработчики не дают?
(В ответ на комментарий №15) > Что можно указать в поле Source для github проекта, если архивов разработчики > не дают? Имя файла (обычно упакованного tar), созданного gear из Git-репозитория и прописанного в .gear/rules.
При попытке воспользоваться gear для упаковки исходников из репозитория, получаю: gear: No specfiles found в корне репозитория имеется единственный .spec файл, ./gear/rules с едниственной целью tar также присутствует. Явное указание spec-а в rules к успеху не приводит. Идеи?
(В ответ на комментарий №17) > При попытке воспользоваться gear для упаковки исходников из репозитория, > получаю: > gear: No specfiles found > в корне репозитория имеется единственный .spec файл, ./gear/rules с > едниственной целью tar также присутствует. Явное указание spec-а в rules к > успеху не приводит. Идеи? .gear/rules и он должен быть закоммичен.
Для первого коммита спека, если его хочется выполнить gear-commit, понадобится указание --specfile -- например: $ gear-commit -a --spec=installer-distro-altlinux-desktop.spec
Спасибо, это заработало, но почему-то gear создает архив такой структуры: -архив --архив с исходниками --spec что требует дополнительной распаковки, чтобы извлечь архив с исходниками. Как бы то ни было, во время сборки пакета performous возникает такая ошибка: "CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name." Секция %build следующая: %cmake %make_build VERBOSE=1 -C BUILD
1) покажите .gear/rules; 2) ну так Source: .../%name-%version.tar.bz2 и ожидает tar.bz2 Вообще говоря, для экономии процессорного времени и во избежание двойного сжатия (которое обычно лишь раздувает суммарный архив) рекомендуется использовать tar: и соответственно Source: ... .tar (FIXME: не помню, задокументировано ли это на вики; если нет, надо добавить).
.gear/rules из одной строчки: tar: . Основной вопрос таки про CMAKE_CXX_COMPILER (Комментарий #20)
Всех с прошедшим и с наступающим Старым Новым! (В ответ на комментарий №12) > Гоша, Дима -- предложенный спек меня лично устраивает, если мнение самозваного > псевдоментора что-то значит, то предлагаю переходить к п.3 > http://www.altlinux.org/Team/Join/Secretary Как продвигаются дела с ключами? (насчет email-а мне тоже ничего не приходило). Тем временем практически готовы spec-и для трех новых пакетов: muse, performous, performous-composer
(В ответ на комментарий №20) > "CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found. > Please set CMAKE_CXX_COMPILER to a valid compiler path or name." Тьфу ты, торможу. В отличие от, например, федоры -- альтовская базовая сборочная среда (определяемая зависимостями пакета rpm-build) не включает gcc-c++; в таких случаях его надо затребовать в явном виде, добавив соответствующий BuildRequires:. 2 ldv: предлагаю двигаться к третьему пункту, см. comment 12 и comment 13.
(In reply to comment #24) > 2 ldv: предлагаю двигаться к третьему пункту, см. comment 12 и comment 13. Я свой ход сделал, теперь ваша очередь. :)
Иван, предлагаю залить пакеты на git.alt и оформить их в качестве test-only сборочных заданий.
Процедура приёма прекращена.
