Bug 43827

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.

https://www.altlinux.org/Работа_с_ключами_разработчика#Обновление_существующего_GPG-ключа_в_пакете_alt-gpgkeys

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 и на сборочнице заменён.