Created attachment 19092 [details] pub key
Заявка недооформлена. Посмотрите, пожалуйста, сюда: https://www.altlinux.org/Team/Join/Candidate#Сбор_информации
Created attachment 19109 [details] gpg key
Created attachment 19110 [details] gpg exported
nicourced muhamadeevir@basealt.ru Хочу научиться собирать пакеты. Ментор protvin
Подтверждаю.
https://altlinux.space/nicourced/libscalapack пакет libscalapack обновлен до последней версии
kbibtex собран
icecat собран
(In reply to Илья Мухамадеев from comment #3) > Created attachment 19110 [details] > gpg exported А вы "-----BEGIN/END PGP PUBLIC KEY BLOCK-----" сами вручную удалили? Приложите, пожалуйста, полный файл с заголовком.
Created attachment 19273 [details] ключ с шапкой и подвалом
(In reply to Илья Мухамадеев from comment #10) > Created attachment 19273 [details] > ключ с шапкой и подвалом Вы не ответили на вопрос, но я так понимаю, что ответ «да». Этот файл лучше, но в него попал лишний ключ: 4096R/61B7B526D98F0353 2015-07-17 Mozilla Software Releases <release@mozilla.com> Нужен файл с одним вашим ключом.
Created attachment 19276 [details] теперь один ключ
(In reply to Илья Мухамадеев from comment #12) > Created attachment 19276 [details] > теперь один ключ Эти файлы ничем не отличаются: $ curl --no-progress-meter 'https://bugzilla.altlinux.org/attachment.cgi?id=19273' | sha1sum da39a3ee5e6b4b0d3255bfef95601890afd80709 - $ curl --no-progress-meter 'https://bugzilla.altlinux.org/attachment.cgi?id=19276' | sha1sum da39a3ee5e6b4b0d3255bfef95601890afd80709 -
Created attachment 19278 [details] новый Прошу прощения, спутал
Ментор есть, ключи в порядке. T/J/S -> 1.3.
Кандидат освоил инструменты сборки и собрал несколько пакетов. Так что считаю, что кандидат готов собирать пакеты на сборочнице.
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. T/J/S -> 3.6.
Меняю ментора на rauty
(Ответ для Илья Мухамадеев на комментарий #19) > Меняю ментора на rauty Ок
Кандидат готов отправлять пакеты в Сизиф. Прошу призвать рецензента для независимой оценки готовности кандидата. На данный момент кандидат собрал и обновил пакеты: https://beta.packages.altlinux.org/ru/sisyphus/srpms/libscalapack https://beta.packages.altlinux.org/ru/sisyphus/srpms/kbibtex https://beta.packages.altlinux.org/ru/sisyphus/srpms/jacoco https://beta.packages.altlinux.org/ru/sisyphus/srpms/gem-afl-ruby https://beta.packages.altlinux.org/ru/sisyphus/srpms/veyon https://beta.packages.altlinux.org/ru/sisyphus/srpms/qgroundcontrol https://beta.packages.altlinux.org/ru/sisyphus/srpms/geographiclib https://beta.packages.altlinux.org/ru/sisyphus/srpms/libulog_cpp https://beta.packages.altlinux.org/ru/sisyphus/srpms/libevents https://beta.packages.altlinux.org/ru/sisyphus/srpms/libxz-embedded https://beta.packages.altlinux.org/ru/sisyphus/srpms/c_library_v2 https://beta.packages.altlinux.org/ru/sisyphus/srpms/parameterrepository https://beta.packages.altlinux.org/ru/sisyphus/srpms/gpsdrivers https://beta.packages.altlinux.org/ru/sisyphus/srpms/gamecontrollerdb
Created attachment 21334 [details] qgroundcontrol.spec.patch (Ответ для Ajrat Makhmutov на комментарий #21) > Кандидат готов отправлять пакеты в Сизиф. Вы уверены? > Прошу призвать рецензента для независимой оценки готовности кандидата. > На данный момент кандидат собрал и обновил пакеты: > https://beta.packages.altlinux.org/ru/sisyphus/srpms/qgroundcontrol По критериям, предъявленным в bug 45253, я бы ожидал отрицательной оценки, да ещё и с понижением уровня готовности :( По своим -- поблагодарю за сборку в сизиф интересного стека. От ilyakurdyukov@ прилагаю кумулятивный патч на спек (попросил отправить NMU) с таким комментарием: --- Заменил прямые вызовы cmake на макросы. Билд теперь собирается параллельно. Убрал это: patchelf --set-rpath '' build/Release/QGroundControl # Clear wrong paths in rpath. Это потому что install не делается и RPATH от билда. Красиво решается так: -DCMAKE_BUILD_RPATH:STRING='' cmake install не делал, так как файлов всего три и так быстрее. mkdir не нужно при инсталляции одного файла. Нашел решение для вызовов moc в один процесс: -DCMAKE_AUTOGEN_PARALLEL=%__nprocs Было 45 минут (и это еще с общей параллельнйо сборкой через %cmake_build) - стало 17 минут после установки CMAKE_AUTOGEN_PARALLEL. --- Также поправлены группы пробелов на табы в отбивке, что нахожу недокументированным, но общим местом в стиле альтовых спеков. Возможно, -DCMAKE_BUILD_RPATH:STRING='' стоит предложить втащить в cmake-макросы по умолчанию. Ознакомиться с альтовыми макросами одной страницей можно здесь: http://altlinux.org/Spec/Предопределенные_макросы -- а применять их стоит, чтоб не таскать одни и те же рутинные действия по спекам (и не чинить их в тыще мест, когда рекомендуемый способ в кои веки изменится). Ну и install(1) умеет -p для случая установки одного файла. :)
Макросы cmake он использовал в других спеках. Но тут сборка с Qt6 (qt-cmake-qt6), не стал задавать вопросов, кое-как сделал, никто не проверил. Я тоже о таком не знал, потому что 99.9% исправляю, а не добавлю новое. Даже те кто добавляет не факт что добавляли Qt6 приложения. Поискал по спекам qt пакетов и нашел решение в спеке qt-creator. Есть целый репозиторий со спеками (https://github.com/altlinux/specs) где можно подсмотреть решения. Но ведь можно и найти того кто разбирается и спросить. %_cmake__builddir - нужно запомнить или записать, это директория для билда, которую используют %cmake макросы Также в спеке libulog_cpp: BuildRequires(pre): rpm-macros-cmake BuildRequires(pre): cmake gcc-c++ BuildRequires(pre): doctest-devel BuildRequires: /proc (pre) нужно только для rpm-macros-cmake Из той же спеки libulog_cpp, %check %ifarch aarch64 %make -C "aarch64-alt-linux" run-unit-tests %endif %ifarch x86_64 %make -C "x86_64-alt-linux" run-unit-tests %endif %ifarch i586 %make -C "i586-alt-linux" run-unit-tests %endif Должно быть: %check %make -C %_cmake__builddir run-unit-tests Почему спеку не проверили и человека не научили?
А такие называния пакетов, вы считаете нормальными? https://beta.packages.altlinux.org/ru/sisyphus/srpms/parameterrepository/ Которые, между прочим, записаны аж в %_datadir/ParameterRepository/* То есть лежит в системе такая директория каких-то параметров, для чего - никто не знает. Такие названия обычно трояны создают. Даже если оно так называется на гитхабе: https://github.com/ArduPilot/ParameterRepository У них там и репозиторий есть CustomBuild, тоже в Альте создать пакет custombuild под него? Такие вещи, что нужны для сборки одного единственного тематического пакета - засовывают в него же. Я считаю, что большинство созданных пакетов не нужно было создавать, так как все нужны исключительно для qgroundcontrol, и должны быть вместе с исходниками qgroundcontrol. В том числе libevents, которые легко спутать с libevent.
Ещё по именам пакетов вроде parameterrepository соображение: в рамках конкретного ardupilot это может быть достаточно однозначное название, но для целого сизифа -- не факт; при виде прям сильно общего названия стоит обдумать введение пространства имён, в котором оно будет понятно однозначно и без претензий на очередной Word.
По libulog_cpp: > BuildRequires(pre): rpm-macros-cmake > BuildRequires(pre): cmake gcc-c++ > BuildRequires(pre): doctest-devel > BuildRequires: /proc > > (pre) должно быть только в первом. Смысл BR(pre) в том, что соответствующие пакеты должны быть доступны для разбора спека, который может осуществляться ранее, чем ожидается, когда hsh работает в режиме --query-repackage (см. тж. --repackage-source); если части задействованных макросов в окружении, где выполняется анализ спека, ещё нет -- они и не раскроются. Потому подпакеты с макросами и стали выделять из devel-части таким образом, при возможности стараясь сделать их noarch для менее неудобного бутстрапа на новых архитектурах. См. тж. http://altlinux.org/RPM_Macros_Packaging_Policy
(Ответ для ilyakurdyukov на комментарий #24) > https://beta.packages.altlinux.org/ru/sisyphus/srpms/parameterrepository/ Было бы правильнее ardupilot-parameterrepository
(Ответ для Michael Shigorin на комментарий #22) > прилагаю кумулятивный патч на спек Чтоб ничего не понятно было? :-)
Список из этих BR для qgroundcontrol никого не смущает? Чтобы смущало - надо чтобы кто-то спеки читал перед приёмом, а в них явно никто не заглядывал. Зачем SDL2 и SDL3 одновременно? Не слишком ли низкоуровневые библиотеки libffi libselinux libsystemd для Qt приложения? Или потом предполагалось какой-то вредоносный код впихнуть не привлекая внимания? BuildRequires: libpcre2-devel BuildRequires: libffi-devel BuildRequires: libwayland-egl-devel BuildRequires: liborc-devel BuildRequires: libXau-devel BuildRequires: libXdmcp-devel BuildRequires: libgudev-devel BuildRequires: libudev-devel BuildRequires: libcap-devel BuildRequires: libgbm-devel BuildRequires: zlib-devel BuildRequires: libmount-devel BuildRequires: libblkid-devel BuildRequires: libselinux-devel BuildRequires: libunwind-devel BuildRequires: libSDL2-devel BuildRequires: libSDL3-devel BuildRequires: libsystemd-devel BuildRequires: libsoundio-devel BuildRequires: libpulseaudio-devel BuildRequires: libwayland-client-devel BuildRequires: libX11-devel BuildRequires: libXrandr-devel BuildRequires: libvulkan-devel BuildRequires: libgbm-devel BuildRequires: libdrm-devel BuildRequires: libibus-devel BuildRequires: libibus-gir-devel BuildRequires: libsamplerate-devel BuildRequires: libsndio7-devel BuildRequires: libqmdnsengine-devel Оказалось, что из них нужно лишь: BuildRequires: zlib-devel BuildRequires: libSDL2-devel
(Ответ для ilyakurdyukov на комментарий #29) > Не слишком ли низкоуровневые библиотеки libffi libselinux libsystemd для Qt > приложения? Вообще, нет. https://packages.altlinux.org/ru/sisyphus/srpms/systemdgenie/ https://packages.altlinux.org/ru/sisyphus/srpms/seappletsimple/ Другое дело, в конкретном случае.
(Ответ для Michael Shigorin на комментарий #22) > Создано вложение 21334 [details] [подробности] > qgroundcontrol.spec.patch qgroundcontrol с этим патчем для p11/x867_64 собрался и как минимум запустился; заодно может иметь смысл патчить под ALT примечание, грепающееся по словам "If you are using Ubuntu" (перевод дальше не отвалится, т.к. уже отвалился).
Ошибки понял и принял, добавлял эти библиотеки чтоб избежать warning'ов от cmake во время сборки об их отсуствии, а qmake вместо %cmake потому что на официальном сайте раньше так собирать советовали, сейчас посмотрел -- там тоже cmake.
(Ответ для Илья Мухамадеев на комментарий #32) > чтоб избежать warning'ов от cmake во время сборки об их отсуствии Так лучше не делать. Мне, например, пришлось чистить все подобные пакеты, когда тусовал в Qt файлы по пакетам для упрощения сборки с ним.
