Bug 43827
| Summary: | [4.2] join morozovaes@ | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Team Accounts | Reporter: | morozovaes | ||||||||||||||||||||||||||
| Component: | join | Assignee: | Gleb F-Malinovskiy <glebfm> | ||||||||||||||||||||||||||
| Status: | ASSIGNED --- | QA Contact: | Andrey Cherepanov <cas> | ||||||||||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||||||||||
| Priority: | P5 | CC: | bircoph, dshein, glebfm, grenka, ldv, mike, morozovaes, morozovaes, rider, zerg | ||||||||||||||||||||||||||
| Version: | unspecified | ||||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||||||||||
| URL: | https://altlinux.org/Team/Join | ||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||
Created attachment 11543 [details]
gpg pub key
(In reply to morozovaes from comment #1) > Created attachment 11543 [details] > gpg pub key У gpg-ключа должен быть uid в домене @altlinux.org, это не мешает оставить другие uid-ы, но один с @altlinux.org должен быть. Created attachment 11544 [details]
gpg pub key adduid
Created attachment 11557 [details]
gpg pub key adduid alt
Извиняюсь, добавлено.
(In reply to morozovaes from comment #4) > Created attachment 11557 [details] > gpg pub key adduid alt Ok. Ментор пока что не отозвался. > Ментор пока что не отозвался.
Ещё болеет.
(Ответ для morozovaes на комментарий #0) > Ментор: mcpain Ментор: dshein принято Created attachment 11735 [details]
alt-morozovaes-gpg
Прилагаю обновленные ключи, прошу заменить.
Created attachment 11736 [details]
alt-morozovaes-ssh
Прошу обновить SSH и GPG ключи кандидата (In reply to morozovaes from comment #9) > Created attachment 11735 [details] > alt-morozovaes-gpg Здесь целых два ключа -- тот, который был раньше и новый ключ. (In reply to dshein@altlinux.org from comment #11) > Прошу обновить SSH и GPG ключи кандидата Ключи кандидата на данный момент нигде не зарегистрированы. Created attachment 11737 [details]
alt-morozovaes-gpg
Исправлено.
(In reply to morozovaes from comment #14) > Created attachment 11737 [details] > alt-morozovaes-gpg Ok. Кандидат готов собирать пакеты. Прошу перевести процедуру на стадию 3. ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. Кандидат готов собирать пакеты. ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5. Кандидат готов собирать пакеты в Сизиф T/J/S -> 4.0 Призываю самого себя в качестве рецензента для независимой оценки готовности кандидата. Пока только по поводу задания #322141 EPERM #70 sisyphus qrestapi.git=0-alt2.git.ea5e85a CTK.git=0.1.0-alt4.git.95dac75b slicer.git=5.2.2-alt1 остальное посмотрю чуть позже. Проблемы: * В логе сборки задания есть вот такие сообщения: x86_64: CTK-devel=0.1.0-alt4.git.95dac75b post-install unowned files: /usr/lib64/cmake /usr/lib64/cmake/CTK x86_64: libqrestapi-devel=0-alt2.git.ea5e85a post-install unowned files: /usr/lib64/cmake /usr/lib64/cmake/qRestAPI Эта проверка в сборочнице реализована как warning потому что она не может понять, забыли вы запаковать файл (в данном случае, каталог) или сделали это намеренно. В данном случае, каталоги /usr/lib64/cmake/CTK и /usr/lib64/cmake/qRestAPI стоит запаковать в соответствующие пакеты, а /usr/lib64/cmake запаковывать не следует потому что он общий для очень многих пакетов. Таким образом, в qrestapi стоило либо поменять %_libdir/cmake/* в qrestapi на %_libdir/cmake/qRestAPI, а в CTK на %_libdir/cmake/%name, либо не менять это место вовсе. * У slicer-upstream-wc-last-change-date-fix.patch [1] потерян апстримный commit message и, видимо, добавлено изменение, которого не было в апстриме. Первое просто неаккуратно потому что если у изменения есть описание, от которого есть польза. А вот смешивать изменения вместе совсем неправильно особенно, если у них разные источники. Замечания: * В slicer непонятно, что вот это за изменение и как он влияет на пакет - Remove custom ITK Namespaces for compatibitily with official ITK Расскажите, пожалуйста, об этом чтобы можно было посоветовать как с ними поступить и как лучше описать. Проблемы в пакетах, которые были и раньше, но нет повода не исправить: * В пакетах CTK и slicer вместо %ifarch %e2k ppc64le лучше использовать %ifarch %qt5_qtwebengine_arches. Этот макрос реализован в пакете rpm-macros-qt5-webengine, т.е. чтобы его использовать нужно добавить в specfile BuildRequires(pre): rpm-macros-qt5-webengine. * В libqrestapi, CTK и slicer перед ExcludeArch стоит написать комментарий о том, чем такое ограничение вызвано. Понятно, что в CTK и slicer можно просто написать, что на этой архитектуре нет libqrestapi, но причина отсутствия самой libqrestapi нигде, кажется, не указана. Скорее мысли вслух: * Многие (включая меня) считают, что пункты в %changelog должны быть записаны как полноценные предложения в прошедшем времени, т.е. с большой буквы и с точкой в конце, но, увы, так считают не все. Комментарий к #322141 try 85 * Добавлены описания к новым патчам в slicer. * Использованы rpm-macros-qt5-webengine. * При более пристальном рассмотрении проблемы с незадокументированными ExcludeArch выяснилось, что для qrestapi ограничение на сборку на armh на данный момент не обосновано, но в CTK и slicer ограничение остается из-за другого пакета (pythonqt). Обновлен с актуального для Slicer-project хеша, пояснения добавлены; qrestapi собран на armh. * CTK обновлен до хеша a203172b для закрытия бага #46364. Предыдущая точка обновления была избрана как стабильная для сборки slicer-5.2.2 - изменения в CTK не версионируются с оглядкой на совместимость, некоторые обновления могут ломать сборку slicer, с данным коммитом проблем при сборке не наблюдается. * Строки в спеках qrestapi, CTK заменены, соответственно, на %_libdir/cmake/qRestAPI и %_libdir/cmake/%name, тем не менее, warning "unowned files: /usr/lib64/cmake" появляется при сборке. Елизавета, поясните, пожалуйста, в чём был сакральный смысл обновления pythonqt на два коммита вперёд? Это несерьёзно. Не думали ли вы о полноценном обновлении пакета до свежей версии? (Ответ для Grigory Ustinov на комментарий #23) > Елизавета, поясните, пожалуйста, в чём был сакральный смысл обновления > pythonqt на два коммита вперёд? Это несерьёзно. Не думали ли вы о > полноценном обновлении пакета до свежей версии? Вы имеете в виду, что вместо форка pythonqt с проекта commontk, сейчас находящегося в Сизифе, следует запаковать pythonqt-3.4.1 с Repology? (https://github.com/MeVisLab/pythonqt/releases/tag/v3.4.1) Или что вместо последнего коммита с ветки patched-9 commontk/pythonqt следует обновить до более недавнего коммита из patched-10? (https://github.com/commontk/PythonQt/commit/14fa99a66aa6d1fcc95d084515834dcdb3c6ab46) Конкретно на это коммит с ветки patched-9 указывает в зависимостях CTK имеющейся и обновляемой версии (https://github.com/commontk/CTK/blob/aa4a717152052812627a020c7f4110ccb8f7bfc8/CMakeExternals/PythonQt.cmake#L85). Версионирования в форке как такого нет, нигде не указано, что patched-10 является стабильной веткой. Следует обновить до хронологически последнего 14fa99a, тем не менее? Я предлагаю первый вариант, поскольку patched-10 тоже уже безнадёжно устарела. В частности последний патч про адаптацию сборки с новым питоном был взят отсюда: https://github.com/MeVisLab/pythonqt/commit/f52ff964f2468eb82928c81bab5bdebdb7e53ac9 Кроме того, насколько я понимаю остальные дистрибутивы тоже собирают отсюда. Вместо того, чтобы привязываться к конкретному хэшу коммита в одном проекте, лучше двигаться вперёд и при необходимости запатчить именно CTK. Хотя федора вроде собирает так. Раз уж вы взялись за это дело, было бы хорошо сделать его хорошо. Мой корыстный интерес заключается в том, что если заметили, последние пару лет я патчу этот пакет и поддерживать его в таком протухшем состоянии становится всё сложнее и сложнее. Мне бы хотелось чтобы он обновился. Но как бы то ни было, двигать на два коммита вперёд - это точно бессмысленное изменение, которым вероятно не стоит обременять сборочницу. Хорошо, с остальными пакетами такого рода в зависимостях тоже посмотрю, что можно сделать. Обеспечить совместимость CTK с upstream-версией pythonqt на данный момент затруднительно. Помимо того, что upstream не поддерживает cmake, многие из патчей commontk, функционал которых требует CTK, не были приняты в upstream. Обновление pythonqt исключено из таска. К таску #322141 добавлено обновление ITK (v5.1.2 -> v.5.3.0), новые зависимости ITK (Cleaver, VkFFT, rang). rang: - надо поправить тэг лицензии. - description ограничить 80-ю знаками в одной строке (добавить переводов строки) - включить тесты - убрать тэг VCS, т.к. он совпадает с URL - убрать пакет doc - это два файла перенести в devel и в библиотеку. (какой куда должно быть и так понятно) VkFFT: в секции install ставить файлы в docdir не нужно, это можно сделать прямо в %files doc через %doc + исправить все замечания, применимые из комментария про rang cleaver: имя пакета привести к нижнему регистру непонятно зачем нужен define pkgver - его нужно убрать. +%if_with qt_gui +%files +%endif Это мусор, нужно убрать всё что имеет отношение к qt, если сейчас собирать нет необходимости (или починить сборку с qt). тут похоже на ошибку: +# remove useless bundled Teem files +%exclude %_includedir/* +%exclude %_bindir/* +%exclude %_libexecdir/* Это по аналогии с замечаниями к пакету rang. +%files doc +%doc LICENSE +%doc README.md Попробовать включить в пакете тесты. qrestapi: - -DBUILD_TESTING:BOOL=ON - тогда уж и тесты попробовать выполнить в секции check, а иначе непонятно зачем включать TESTING. slicer: + -DSlicer_WITH_LIBRARY_VERSION:BOOL=OFF \ непонятно зачем было делать это изменение, требуются или пояснения или обратно включить версионирование у библиотеки. rang, VkFFT, cleaver - Изменения внесены. qrestapi - offline-тесты в пакете отсутствуют; build_testing выключено. slicer - Восстановлено версионирование библиотек. Итого, мы в телеграм вместе с Лизой довели до ума два тяжёлых сборочных задания: https://packages.altlinux.org/ru/tasks/322141/ https://packages.altlinux.org/ru/tasks/323564/ Но пока что однозначно сказать что можно начинать самостоятельную работу я не могу. review пакетов требуется. А так прогресс отличный, продолжаем работать. Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6. Елизавета, если не передумали вступать в team -- попросите наставника (mcpain@) сообщить о том, что Вы готовы отправлять пакеты в сизиф; см. тж. http://altlinux.org/Team/Join/Secretary (In reply to Michael Shigorin from comment #36) > Елизавета, если не передумали вступать в team -- попросите наставника > (mcpain@) сообщить о том, что Вы готовы отправлять пакеты в сизиф; см. тж. > http://altlinux.org/Team/Join/Secretary https://bugzilla.altlinux.org/show_bug.cgi?id=43827#c18 и ментор давным давно сменился. Created attachment 17079 [details]
gpg pub key
Прилагаю обновленные ключи, прошу заменить.
Created attachment 17080 [details]
ssh pub key
А что случилось со старыми ключами? Если они доступны, то новые ключи следует выложить на git.alt. Created attachment 17133 [details]
gpg pub key
(Ответ для Gleb F-Malinovskiy на комментарий #41) > https://www.altlinux.org/ > Работа_с_ключами_разработчика#Обновление_существующего_GPG- > ключа_в_пакете_alt-gpgkeys Не имею на данный момент старых ключей. Created attachment 17231 [details]
keys.tar.xz.gpg
В связи с одновременной утерей обоих ключей (ssh и gpg) была проведена личная встреча в офисе с целью идентификации кандидата и передачи новых ключей. В приложенном архиве, заверенном моей GPG-подписью, находятся новые ключи.
Содержательно, ssh ключ тот же, что и выше; gpg ключ был по моей просьбе усилен: добавлены S и E подключи, с основного ключа сняты S и E флаги, поэтому он отличается от ранее загруженных.
ssh ключ обновлён на gitery и gyle. Елизавета, поскольку gpg-ключ поменялся, приложите его тоже к багу. Created attachment 17232 [details]
gpg pub key
gpg-ключ в alt-gpgkeys и на сборочнице заменён. |
Description
morozovaes 2022-09-20 12:21:16 MSK