Created attachment 15276 [details]
GPG-ключ

(Ответ для alxvmr на комментарий #0)

> Псевдоним: alekseevamo
> Адрес пересылки почты: alekseevamo@basealt.ru

Хотелось бы изменить псевдоним и адрес пересылки почты:
Новый псевдоним: alxvmr
Новый адрес пересылки почты: alexeevamro@gmail.com

(In reply to alxvmr from comment #2)
> Хотелось бы изменить псевдоним и адрес пересылки почты:
> Новый псевдоним: alxvmr
> Новый адрес пересылки почты: alexeevamro@gmail.com
Без проблем, но с другим ником нужен и другой id в gpg-ключе.

Created attachment 15393 [details]
GPG-ключ для нового ника

Created attachment 15394 [details]
Новый публичный SSH-ключ

(In reply to alxvmr from comment #4)
> Created attachment 15393 [details]

Прошу прощения, я не заметил в предыдущем варианте, а тут проблема осталась: мы просим идентификатор ключа делать в формате <First name> <Last name>, а не в обратном порядке, как у вас.

ssh ключ не обязательно было перегенерировать, и первый бы подошёл, но и новый ничем не хуже.

Created attachment 15395 [details]
Новый GPG-ключ

Спасибо, теперь с ключами всё хорошо.

Теперь требуется подтверждение от ментора, а он, кажется, даже на баг не подписан.  Вижу, он был assignee, а в Cc не попал, исправляю тогда сам. :)

Подтверждаю, поехали.

Обновила пакет python3-module-smbc до версии 1.0.25.1; убрала патч Игоря Чудова, который был принят в upstream.
https://github.com/alxvmr/smbc

Ментор есть, ключи в порядке.
T/J/S -> 1.3.

Обновила пакет python3-module-prettytable
2.1.0 -> 2.2.0

github: https://github.com/alxvmr/prettytable_alt_linux

Сделала Python-обвязку для библиотеки GVDB (язык C), собрала в пакет - https://github.com/alxvmr/gvdb-binding

(Ответ для alxvmr на комментарий #13)
> Сделала Python-обвязку для библиотеки GVDB (язык C), собрала в пакет -
> https://github.com/alxvmr/gvdb-binding

В дополнение к предыдущему собщению.

В рамках рабочих задач возникла необходимость обвязать C библиотеку GVDB для предоставления возможности чтения данных из бинарников (Python).

В процессе работы также потребовалось изменить исходники GVDB. В результате, во время сборки пакета формируется патч, который применяется к upstream.

Обвязала, результат обвязки упаковала. 

Применять пакет планируется в задачах, связанных с разработкой в области инфраструктурных решений.

Пакеты собираются, пора переходить на этап регистрации ключей.

Внесла изменения в исходники ALT Media Writer - решена проблема, из-за которой вместо выбранного пользователем устройства записи образ записывался на последнее смонтированное устройство (https://github.com/altlinux/ALTMediaWriter/issues/37).

Обновила пакет (1.0.4-alt1 -> 1.0.4-alt2).

Также собрала новый инсталлятор для Windows.

Обновленный .spec лежит в репозитории ALT Media Writer (https://github.com/altlinux/ALTMediaWriter).

Внесла изменения в accountsservicies - теперь просматривается /etc/tcb, а не /etc/shadow/, что бьется с внутренним устройством ALT Linux. В соответствии с этим изменила и тесты.

Теперь в Gnome локальные пользователи определяются accountsservicie-ом как локальные и доступен автоматический вход (https://bugzilla.altlinux.org/47499)

Ссылка на репозиторий - https://github.com/alxvmr/accountsservice

Нам уже пора переходить к стадии 3.0, давайте продвинемся.

А то передавать наработки приходится через github:
https://bugzilla.altlinux.org/48922#c17

Добрый день!

Написала консольную утилиту gpresult (python) - предоставляет сведения о результирующем наборе групповых политик для текущего пользователя и/или компьютера.

Для проекта был написан конфигурационный файл pyproject.toml, в качестве системы сборки используется hatchling. 

В итоге, получившиеся приложение упаковала в rpm-пакет. Ссылка на репозиторий - https://github.com/alxvmr/gpresult

Также во время работы над документацией понадобился плагин mkdocs-static-i18n (исходники: https://github.com/ultrabug/mkdocs-static-i18n).

Плагин предоставляет возможность поддержки нескольких языков документации через добавление файлов статического перевода.

В итоге, собрала данный проект в rpm-пакет: https://github.com/alxvmr/mkdocs-static-i18n

ssh ключ на gitery.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.3.

Репы нужно переложить сюда:
https://git.altlinux.org/people/alxvmr/packages/

Сборка пакетов освоена в достаточной степени, чтобы отправлять тестовые задания на сборочницу.

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.
Адрес подписан на devel@.

T/J/S -> 3.6.

Обновила пакет libgvdb - добавила генерацию .pc файла в meson.build (https://git.altlinux.org/people/alxvmr/packages/?p=libgvdb.git;a=summary)

Создала task #357343

Пакет libgvdb попал в Sisyphus.

Ссылка: https://packages.altlinux.org/en/sisyphus/srpms/libgvdb/3118378682792640562

Обновила пакет gpresult (0.0.1-alt1 -> 0.0.2-alt1):
- добавлен вывод информации о Preference;
- добавлена обработка информации о политиках, не имеющих ключей;
- из сборки исключены .po файлы переводов.

Ссылка на пакет: https://packages.altlinux.org/en/sisyphus/srpms/gpresult/

Обновила altmediawriter для Sisyphus:
- исправлена ошибка с выбором накопителя (#44462);
- исправлено отображение прогресса записи (#49205);
- исправлено форматирование диска (#47202).

Номер таски #358188.

Вместе с @iv собрали пакет alloy (https://github.com/grafana/alloy)
Task (sisyphus): 361292

Вместе с @iv починили утечку памяти в mate-menu.
Обновила пакет: #361543 (Sisyphus, 22.04.2-alt7 -> 22.04.2-alt8)

(Ответ для alxvmr на комментарий #29)
> Вместе с @iv починили утечку памяти в mate-menu.
> Обновила пакет: #361543 (Sisyphus, 22.04.2-alt7 -> 22.04.2-alt8)

* #361554

Обновила пакет userpasswd (применила патч Ивана Волченко)
0.3.4-alt1 -> 0.3.5-alt1

Обновила пакет alloy (Sisyphus):
1.4.3-alt3 -> 1.5.0-alt1 -> 1.5.1-alt1
Версия 1.5.1-alt1 сейчас находится в таске 364081

Обновила userpasswd: 0.3.5-alt1 -> 0.3.6-alt1
Исправили регрессию

Обновила gpresult
0.0.2-alt1 -> 0.0.3-alt1

В частности, добавлены bash completion
Помимо этого внесен новый функционал в утилиту: добавлены новые ключи для форматирования вывода и включения предыдущих значений, включена новая информация в вывод, обновлены переводы, ...

Обновила mate-menu: 22.04.2-alt9 -> 22.04.2-alt10

Приложен патч, исправляющий отображение подсказок + добавлена кнопка включения/выключения отображения подсказок.

Номер таски (Sisyphus): 374511

Обновила altmediawriter: 1.0.5-alt2.1 -> 1.0.6-alt1

Исправила проблему с кодировкой при выводе ошибки в gui (Windows)

Номер таски (Sisyphus): 374370

Обновила gpresult: 0.0.3-alt1 -> 0.0.4-alt1

* Добавлены переводы для стандартного вывода argparse
* Внесены изменения в работу gpresult

Номер таски (Sisyphus): 372224

Базовый каркас сборочных инструментов освоен, давайте подыщем диментора.

Обновила пакет alloy (обновление версии): 1.5.1-alt1 -> 1.6.1-alt1
Номер таски (Sisyphus): 371997

Собрала новые пакеты из своих исходников (С, cmake):
userpasswd-gnome
gnome-shell-extension-userpasswd

+ обновила .spec для userpasswd (добавила альтернативы) и вынесла .desktop файл в отдельный пакет: userpasswd-common

Пакет userpasswd-gnome предоставляет обновленный userpasswd для GNOME. Манипуляции со старым userpasswd нужны для разрешения конфликтов (новая версия 0.3.6-alt2).

Номер таски с пакетами (userpasswd, userpasswd-common, userpasswd-gnome, gnome-shell-extension-userpasswd): 
Sisyphus 374317

Призван рецензент (arseny@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.

(In reply to Gleb F-Malinovskiy from comment #41)
> Призван рецензент (arseny@) для независимой оценки готовности кандидата.
> 
> T/J/S -> 4.2.

ACK.

По словосочетанию "номер таски" я автоматически выгрепал из этой баги следующие
сборочные задания:
https://packages.altlinux.org/tasks/358188
https://packages.altlinux.org/tasks/374511
https://packages.altlinux.org/tasks/374370
https://packages.altlinux.org/tasks/372224
https://packages.altlinux.org/tasks/371997
https://packages.altlinux.org/tasks/374317
и так понял, что смотреть нужно на них.

Мария, Женя, если в списке выше что-то лишнее или нужно рассматривать что-то ещё, сообщите. :)

Начнём, благословясь. :)

https://packages.altlinux.org/tasks/374317

userpasswd.git:

Глядя на 0.3.6-alt2, вижу не очень внятные записи в changelog пакета.
Я не стал бы подробно на этом останавливаться, будь дело только в стиле.
Мейнтейнеру нужно чётко понимать, что уместно в истории gear-репозитория, а что
в changelog.

Тексты в аннотациях коммитов (commit messages) и в журнале изменений пакета,
вообще говоря, предназначены разным кругам адресатов и сообщают своим адресатам
о разном.
Первое читают участники ALT Linux Team или любой желающий, изучая
исходный пакет (например, чтобы вспомнить, зачем была сделана некая правка),
и сопоставляют с построчным диффом; второе читают пользователи, которые ставят
пакеты и могут не разбираться в их сопровождении, но хотели бы узнать о
заметных для них изменениях в новом пакете — вдруг к обновлению нужно сначала
подготовиться?
Отсюда следует и разница между одним и другим: разный охват (каждый коммит vs
от релиза к релизу), уровень детализации (в changelog короче), changelog
копируется в каждый "бинарный" пакет и возникает иллюзия, что его содержимое
присуще этому бинарному пакету, проч.
[Надо бы где-то это подробно письменно объяснить и положить в базу знаний, а то
про заглавные буквы и точки у нас есть, а про взгляд сисадмина — нет.]

> 63 * Thu Feb 20 2025 Maria Alexeeva <alxvmr@altlinux.org> 0.3.6-alt2
> 64 - Add alternatives
> 65 - Add common subpackage
> 66 - Add conflict with userpasswd < 0.3.6-alt2
* "Add common subpackage" ни о чём читателю changelog entry не скажет, особенно
если он читает changelog не от userpasswd-common.
Чтобы прочесть его summary и description, нужно дать команду, а это не факт,
что удобно — читатель не всегда находится перед интерактивным шеллом, чтобы
туда сказать `apt-cache show userpasswd-common`. Если написать что-то вроде
"Moved .desktop file to userpasswd-common to be shared with ...", это уже
объяснит пользователю суть произошедшего. Или не shared with, а used by, по смыслу.
* "Add conflict" тоже может быть непонятно куда. Если открыть спек, то станет
понятно, что в -common, но это мы с вами на git-историю и исходники смотрим.
Раз уж у нас есть в тексте параграф о появлении -common, там же можно упомянуть
и об этом.

Ну и, раз уж мы на этом остановились, у записей к 0.3.6-alt1 и к -alt2
почему-то разное оформление: там в прошедшем времени, тут в настоящем. Лучше бы
выбрать что-то одно. Так как это сообщения о уже проведённых в репозитории
действиях, а не заголовки ещё не принятых патчей (как в git), я бы предложил
писать в прошедшем; это совпадает с традиционной практикой для RPM-пакетов как
минимум.

Это всё уже уехало в сизиф, но у нас changelog-записи упаковываются в составе
исходников, так что можно исправить задним числом. :)

Кроме этого — теперь в спеке у пакета указано значение Packager, не соответствующее действительности.

userpasswd-gnome:

в сборочной среде указан пакет ccmake. Вопрос _кандидату_: зачем?
Ещё один вопрос _кандидату_: можно ли упаковать программу с правами setgid
shadow при помощи директив для RPM? если нет, почему?

(In reply to Arseny Maslennikov from comment #44)
> userpasswd-gnome:
Вопрос на грани апстрима и пакета, на ревью скорее не влияет.
А зачем было городить alternatives, если можно выбирать наилучший фронт в
зависимости от, например, переменной окружения XDG_CURRENT_DESKTOP?
Программа-обёртка, работающая по принципу: если в этом массиве упомянут GNOME,
то взять *-gnome, если KDE (и при этом установлен фронт на Qt, если кто-нибудь
таковой сделает), то *-qt, ..., fallback на что-нибудь безобидное. На неё же смотрит .desktop-файл.

Или от прежней программы userpasswd планируется тоже отказаться?

(In reply to Arseny Maslennikov from comment #44)
> userpasswd-gnome:
Небольшое замечание отн. апстрима userpasswd-gnome.
Хорошо, что я проходил по commitdiff и заметил.
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
> @@ -58,6 +61,8 @@ target_compile_options(
>  )
>  
>  install (TARGETS ${PROJECT_NAME} DESTINATION bin)
> +install (FILES ${DESKTOP_FILE} DESTINATION
> +         /usr/share/applications)
>  
>  set(CMAKE_CLEAN_FILES ${PROJECT_NAME})
>  include(GNUInstallDirs)
В процитированном фрагменте уместен путь `${CMAKE_INSTALL_DATADIR}/applications`.

https://cmake.org/cmake/help/v3.31/command/install.html#files
> To make packages compliant with distribution filesystem layout policies, if projects must specify a DESTINATION, it is strongly recommended that they use a path that begins with the appropriate relative GNUInstallDirs variable. This allows package maintainers to control the install destination by setting the appropriate cache variables. The following example shows how to follow this advice while installing an image to a project-specific documentation subdirectory:
>
> include(GNUInstallDirs)
> install(FILES logo.png
>         DESTINATION ${CMAKE_INSTALL_DOCDIR}/myproj
> )
Не надо начинать новые проекты на CMake. Из этого не выходит ничего хорошего.
Возможно, рациональным исключением из этого правила был бы Qt-dependent проект
(потому что иначе придётся соображать, как правильно интегрироваться с Qt без
CMake), но это же не наш случай...

Неподготовленному человеку, не эксперту по CMake, очень легко по неосторожности
сломать механизмы CMake, которые, по идее, должны упрощать ему и тем, кто
собирает исходники в разных окружениях, жизнь, а в реальности усложняют.

> --- a/src/pam_helper/CMakeLists.txt
> +++ b/src/pam_helper/CMakeLists.txt
> @@ -20,7 +20,7 @@ target_include_directories(helper PRIVATE ${HEADER_DIR} ${GOBJECT_INCLUDE_DIRS}
>  target_link_libraries(helper PRIVATE ${GOBJECT_LIBRARIES} ${GIO_LIBRARIES} ${PAM_LIBRARIES} ${JSON_GLIB_LIBRARIES})
>  target_compile_options(helper PRIVATE ${GOBJECT_CFLAGS} ${GIO_CFLAGS} ${PAM_CFLAGS} ${JSON_GLIB_CFLAGS})
>  
> -install (TARGETS helper DESTINATION ${CMAKE_INSTALL_LIBDIR}/userpasswd/)
> +install (TARGETS helper DESTINATION /usr/lib/userpasswd/)
>  
>  set(CMAKE_CLEAN_FILES ${PROJECT_NAME})
>  include(GNUInstallDirs)
Здесь тоже `${CMAKE_INSTALL_PREFIX}/lib/userpasswd`, если нет отдельной переменной для такого контента.

То же касается `${CMAKE_INSTALL_DATADIR}/gnome-shell` в гноморасширении.

В наше время вообще можно брать meson и горя не знать, особенно для проектов на gnome-стеке.

(Ответ для Arseny Maslennikov на комментарий #44)
> userpasswd-gnome:
>
> Ещё один вопрос _кандидату_: можно ли упаковать программу с правами setgid
> shadow при помощи директив для RPM? если нет, почему?

Добрый день!
По поводу setgid shadow: у Вас сейчас старая таска, в ней был неправильный подход к назначению прав. В итоге сделали так:

%attr(2711, root, shadow) %_libexecdir/userpasswd/helper

Простите за путаницу, корректная таска: 375891 (https://git.altlinux.org/tasks/archive/done/_367/375891/)

> в сборочной среде указан пакет ccmake. Вопрос _кандидату_: зачем?
По поводу ccmake: да, зависимость от ccmake тут не нужна, уберу.

Добрый день!

Обновила пакеты userpasswd-common, userpasswd и userpasswd-gnome. Учла свои ошибки при прошлых обновлениях и внесла дополнительные изменения.
userpasswd:
- сделала записи в changelog пакета более содержательными
- изменила свои записи на прошедшее время
- удалила поле Packager
userpasswd-gnome:
- заменила ccmake на cmake
- исправила пути в CMakeLists.txt на использование переменных
- установка прав была исправлена в прошлой версии

Номер задания в Sisyphus: #381971

Также собрала новый пакет в Sisyphus - Cambalache.
Для его работы также собрала проект Casilda.

Cambalache - это конструктор графического интерфейса для GTK4/GTK3. Casilda - виджет-композитор Wayland для Gtk4, который можно использовать для встраивания окон других процессов в приложение Gtk4.

Пакеты уже попали в Sisyphus:
Cambalache - https://packages.altlinux.org/ru/sisyphus/srpms/cambalache/
Casilda - https://packages.altlinux.org/ru/sisyphus/srpms/casilda/

Обновила пакет alloy: 1.7.4-alt1 -> 1.8.1-alt1

Уже попал в Sisyphus: https://packages.altlinux.org/ru/sisyphus/srpms/alloy/

(In reply to alxvmr from comment #48)
> Добрый день!
> 
> Обновила пакеты userpasswd-common, userpasswd и userpasswd-gnome. Учла свои
> ошибки при прошлых обновлениях и внесла дополнительные изменения.
> userpasswd:
> - сделала записи в changelog пакета более содержательными
> - изменила свои записи на прошедшее время
> - удалила поле Packager
> userpasswd-gnome:
> - заменила ccmake на cmake
> - исправила пути в CMakeLists.txt на использование переменных
> - установка прав была исправлена в прошлой версии
> 
> Номер задания в Sisyphus: #381971

Здорово. Я надеюсь, что смогу посмотреть внимательно на этой неделе (фактически уже на майских). Извините, что торможу :/

У меня было окно, в которое я довольно сильно залип в код gpresult, хотел к нему немного придраться, но потом оказалось, что без изменения cli там сильно лучше не сделаешь. Так что проехали, да и это не касалось напрямую нашего с вами review.

(In reply to alxvmr from comment #50)
> Обновила пакет alloy: 1.7.4-alt1 -> 1.8.1-alt1
> 
> Уже попал в Sisyphus: https://packages.altlinux.org/ru/sisyphus/srpms/alloy/

Пока вот о чём задам вопрос.
>  25 ExcludeArch: %ix86
По какой причине пришлось выкинуть intel-32?

(Ответ для Arseny Maslennikov на комментарий #52)
> (In reply to alxvmr from comment #50)
> > Обновила пакет alloy: 1.7.4-alt1 -> 1.8.1-alt1
> > 
> > Уже попал в Sisyphus: https://packages.altlinux.org/ru/sisyphus/srpms/alloy/
> 
> Пока вот о чём задам вопрос.
> >  25 ExcludeArch: %ix86
> По какой причине пришлось выкинуть intel-32?

Добрый день!
Насколько помню, не хватает места на сборочнице (cannot allocate memory). В пакете содержится большой объем завендоренных зависимостей.

(Ответ для Arseny Maslennikov на комментарий #51)
> Здорово. Я надеюсь, что смогу посмотреть внимательно на этой неделе
> (фактически уже на майских). Извините, что торможу :/

Ничего страшного, у всех бывают занятые моменты. Спасибо, что уделяете время.

> У меня было окно, в которое я довольно сильно залип в код gpresult, хотел к
> нему немного придраться, но потом оказалось, что без изменения cli там
> сильно лучше не сделаешь. Так что проехали, да и это не касалось напрямую
> нашего с вами review.

Да, логика у gpresult своеобразная :) Если есть предложения по изменению cli - пишите, пожалуйста (можно прям на github).

(In reply to alxvmr from comment #53)
> > >  25 ExcludeArch: %ix86
> > По какой причине пришлось выкинуть intel-32?
> 
> Добрый день!
> Насколько помню, не хватает места на сборочнице (cannot allocate memory). В
> пакете содержится большой объем завендоренных зависимостей.
Это объяснение лучше всего добавить в виде комментария перед строчкой с ExcludeArch:, с цитатой из лога сборки с ошибкой.  Коммуникация с другими разработчиками (на моей практике главный разработчик, с которым приходится коммуницировать это я сам через n лет) не менее важна, чем коммуникация с rpm-build.

(In reply to Gleb F-Malinovskiy from comment #55)
> (In reply to alxvmr from comment #53)
> > > >  25 ExcludeArch: %ix86
> > > По какой причине пришлось выкинуть intel-32?
> > 
> > Добрый день!
> > Насколько помню, не хватает места на сборочнице (cannot allocate memory). В
> > пакете содержится большой объем завендоренных зависимостей.
> Это объяснение лучше всего добавить в виде комментария перед строчкой с
> ExcludeArch:, с цитатой из лога сборки с ошибкой.  Коммуникация с другими
> разработчиками (на моей практике главный разработчик, с которым приходится
> коммуницировать это я сам через n лет) не менее важна, чем коммуникация с
> rpm-build.

+1.

То же самое относится к нетривиальным операциям, которые мейнтейнеру нужно проделывать с исходниками вручную, чтобы можно было их собрать — например, у вас в этом пакете таким образом описано, как правильно завендорить вебфронт (и оч. хорошо!).

alloy:

* В спеке есть BR: libsystemd-devel. Нужен ли там этот пакет? Если да, то для чего?

gpresult:

Я всё ныл про changelog в ранее рассмотренных пакетах; так вот здесь он лучше. Видимо, потому, что содержит записи о развитии самого gpresult. :)

В спеке есть явная зависимость на libgvdb-gir. Неужели автопоиск не справился?

(In reply to Arseny Maslennikov from comment #58)
> gpresult:

Я не то чтобы эксперт по переводу, но бросилось в глаза, что переводы установлены под python3 sitepackages.
Предназначен ли gpresult быть импортированным в качестве питоньего модуля?
Если нет, то почему бы не положить под /usr/share/locale?

Нижеследующий вопрос касается сразу нескольких разных пакетов. Я заметил, что директива define _unpackaged_files_terminate_build 1 начала из спеков пропадать. С чем это связано?

casilda:

Для размещения GObject intro у нас есть %_girdir и %_typelibdir. Об этом, насколько я помню, никто ни в каких базах знаний не пишет, так что это на будущее. :)

Ну, и библиотеку, согласно Shared Libs Policy[1], лучше класть в пакет с версией. Вон, у wireplumber тоже номерок вписан в имя библиотеки, soversion не меняется, а поломок интерфейса не было, но в некоторый момент мне пришлось собирать в репозиторий обе версии сразу.

Ещё, бывает, файлы gir и typelib выделяют в подпакеты *-gir и *-gir-devel, но тут на вкус и цвет товарища нет, делайте как вам удобно.

[1] https://altlinux.org/Shared_Libs_Policy

Теперь вопрос:
> 41 %package devel
> 42 Group: Development/GNOME and GTK+
> 43 Summary: Wayland compositor for GTK4
> 44 Requires: %{name}%{?_isa} = %{version}-%{release}
Интересно, зачем здесь зависимость на %{name}%{?_isa}? Да и просто явно прописанная зависимость.

(Ответ для Gleb F-Malinovskiy на комментарий #55)
> (In reply to alxvmr from comment #53)
> > > >  25 ExcludeArch: %ix86
> > > По какой причине пришлось выкинуть intel-32?
> > 
> > Добрый день!
> > Насколько помню, не хватает места на сборочнице (cannot allocate memory). В
> > пакете содержится большой объем завендоренных зависимостей.
> Это объяснение лучше всего добавить в виде комментария перед строчкой с
> ExcludeArch:, с цитатой из лога сборки с ошибкой.  Коммуникация с другими
> разработчиками (на моей практике главный разработчик, с которым приходится
> коммуницировать это я сам через n лет) не менее важна, чем коммуникация с
> rpm-build.

Добавлю с обновлением вместе с обновлением до новой версии.

(Ответ для alxvmr на комментарий #62)
> (Ответ для Gleb F-Malinovskiy на комментарий #55)
> > (In reply to alxvmr from comment #53)
> > > > >  25 ExcludeArch: %ix86
> > > > По какой причине пришлось выкинуть intel-32?
> > > 
> > > Добрый день!
> > > Насколько помню, не хватает места на сборочнице (cannot allocate memory). В
> > > пакете содержится большой объем завендоренных зависимостей.
> > Это объяснение лучше всего добавить в виде комментария перед строчкой с
> > ExcludeArch:, с цитатой из лога сборки с ошибкой.  Коммуникация с другими
> > разработчиками (на моей практике главный разработчик, с которым приходится
> > коммуницировать это я сам через n лет) не менее важна, чем коммуникация с
> > rpm-build.
> 
> Добавлю с обновлением вместе с обновлением до новой версии.

*Добавлю вместе с обновлением до новой версии.

(Ответ для Arseny Maslennikov на комментарий #57)
> alloy:
> 
> * В спеке есть BR: libsystemd-devel. Нужен ли там этот пакет? Если да, то
> для чего?

В апстриме указано, что пакет нужен для сборки:

### Compile on Linux

Compiling Alloy on Linux requires extra dependencies:

* [systemd headers](https://packages.debian.org/sid/libsystemd-dev) for
  Loki components.

   * Can be installed on Debian-based distributions with:

     ```bash
     sudo apt-get install libsystemd-dev
     ```

(Ответ для Arseny Maslennikov на комментарий #58)
> gpresult:
> 
> Я всё ныл про changelog в ранее рассмотренных пакетах; так вот здесь он
> лучше. Видимо, потому, что содержит записи о развитии самого gpresult. :)
> 
> В спеке есть явная зависимость на libgvdb-gir. Неужели автопоиск не
> справился?

Автопоиск справился, в зависимостях указывает typelib(Gvdb).

libgvdb-gir собирала специально для gpresult, поэтому и указала...

Поправлю.

(Ответ для Arseny Maslennikov на комментарий #59)
> (In reply to Arseny Maslennikov from comment #58)
> > gpresult:
> 
> Я не то чтобы эксперт по переводу, но бросилось в глаза, что переводы
> установлены под python3 sitepackages.
> Предназначен ли gpresult быть импортированным в качестве питоньего модуля?
> Если нет, то почему бы не положить под /usr/share/locale?

Пересобрала с нормальной установкой переводов в /usr/share/locale + перенесла упаковку bash-completions в pyproject.toml

Задание в Sisyphus: 383381

(Ответ для Arseny Maslennikov на комментарий #60)
> Нижеследующий вопрос касается сразу нескольких разных пакетов. Я заметил,
> что директива define _unpackaged_files_terminate_build 1 начала из спеков
> пропадать. С чем это связано?

Брала за основу разные spec-файлы...

(Ответ для Arseny Maslennikov на комментарий #61)
> casilda:
> 
> Для размещения GObject intro у нас есть %_girdir и %_typelibdir. Об этом,
> насколько я помню, никто ни в каких базах знаний не пишет, так что это на
> будущее. :)
> 
> Ну, и библиотеку, согласно Shared Libs Policy[1], лучше класть в пакет с
> версией. Вон, у wireplumber тоже номерок вписан в имя библиотеки, soversion
> не меняется, а поломок интерфейса не было, но в некоторый момент мне
> пришлось собирать в репозиторий обе версии сразу.
> 
> Ещё, бывает, файлы gir и typelib выделяют в подпакеты *-gir и *-gir-devel,
> но тут на вкус и цвет товарища нет, делайте как вам удобно.
> 
> [1] https://altlinux.org/Shared_Libs_Policy
> 
> Теперь вопрос:
> > 41 %package devel
> > 42 Group: Development/GNOME and GTK+
> > 43 Summary: Wayland compositor for GTK4
> > 44 Requires: %{name}%{?_isa} = %{version}-%{release}
> Интересно, зачем здесь зависимость на %{name}%{?_isa}? Да и просто явно
> прописанная зависимость.

Чтобы привязать архитектуру.
https://rpm-software-management.github.io/rpm/manual/arch_dependencies.html

Добавила комментарий к исключению архитектуры в alloy-1.8.3-alt1. Номер задания: 384971

(In reply to alxvmr from comment #68)
> (Ответ для Arseny Maslennikov на комментарий #61)
> > casilda:
> > 
> > > 44 Requires: %{name}%{?_isa} = %{version}-%{release}
> > Интересно, зачем здесь зависимость на %{name}%{?_isa}? Да и просто явно
> > прописанная зависимость.
> 
> Чтобы привязать архитектуру.
> https://rpm-software-management.github.io/rpm/manual/arch_dependencies.html
[Надо же, я написал это две недели назад и не отправил. ﷐[U+1F926]﷑‍♂️]

Короче, %_isa — это такой редхатизм; у нас этот макрос не определён, а задача обеспечить мультиарч на x86 решается по-другому: подсистема "arepo" кладёт содержимое i586-пакетов в x86-64-пакеты с другим именем и расставленными достаточным образом зависимостями.
Зависимости вида `Requires: %{name}%{?_isa}` у нас на сегодняшний день не имеют смысла, хоть в каких-то спеках (цельнотянутых из Fedora?) и присутствуют. Лучше  будет убрать.

(In reply to alxvmr from comment #64)
> (Ответ для Arseny Maslennikov на комментарий #57)
> > alloy:
> > 
> > * В спеке есть BR: libsystemd-devel. Нужен ли там этот пакет? Если да, то
> > для чего?
> 
> В апстриме указано, что пакет нужен для сборки:
> 
> ### Compile on Linux
> 
> Compiling Alloy on Linux requires extra dependencies:
> 
> * [systemd headers](https://packages.debian.org/sid/libsystemd-dev) for
>   Loki components.
> 
А, я понял:

https://github.com/grafana/loki/blob/v3.5.1/README.md?plain=1#L129
 129  On Linux, Promtail requires the systemd headers to be installed if
 130  Journal support is enabled.
 131  To enable Journal support the go build tag flag `promtail_journal_enabled` should be passed

Т. е. это не совсем фиктивная зависимость, они хотят sd_journal(3), и, судя по
всему, не напрямую (через модуль coreos/go-systemd), т. е. отпилить это не
так-то просто. Ну ладно.

(In reply to alxvmr from comment #69)
> Добавила комментарий к исключению архитектуры в alloy-1.8.3-alt1. Номер
> задания: 384971

Так пойдёт. Спасибо!

cambalache:

* Как и в некоторых ранее рассмотренных пакетах, тут зачем-то расставлены явные зависимости на *-gir. Может, не надо?
* В этот пакет упакован сам каталог %_girdir, т. е. он присутствует в filelist пакета. Вот так точно не надо делать, такие каталоги, в которые много кто раскладывает свои данные — это filesystem-* или *-filesystem, и если у нас %_girdir unowned, то это бага всего репозитория. Таких недочётов у нас много: `%_datadir/metainfo` не упакованы, `%_datadir/icons/$size` всякие не упакованы. Это потому, что либо не договорились, либо при очередном изменении пакета filesystem руки не дошли предложить какой-то порядок и убедить сообщество (если есть сомнения), что надо именно так.

Поправила cambalache:
- убраны -gir зависимости
- убрана упаковка каталога %_girdir

Номер задания: 391012

(In reply to alxvmr from comment #74)
> Поправила cambalache:
> - убраны -gir зависимости
> - убрана упаковка каталога %_girdir
> 
> Номер задания: 391012
OK, спасибо!

Жду ещё исправление упаковки gettext-сообщений в gpresult (задание надо довести до конца :).

Если я ничего не упустил, всё остальное, что нужно было поправить в ваших пакетах, вы поправили, и ещё чему-то провели NMU, и вообще много в чём поучаствовали, что в альтотиме _всегда приветствуется_.

(In reply to Arseny Maslennikov from comment #75)
> Жду ещё исправление упаковки gettext-сообщений в gpresult (задание надо
> довести до конца :).
Вообще, видно, что Мария научилась собирать пакеты и ясно понимает, что и зачем нужно делать в этом процессе, самостоятельно находит решения проблем, в т. ч. растёт как разработчик (что позволяет самостоятельно вносить в пакеты нетривиальные патчи), и давно пора уже переходить к 5.x.

Но в процессе ревью иногда выяснялось, что Мария повторяет ошибки, которые допускала ранее, которые обнаруживались на ревью и которые потом исправляет. :)
Я думаю, что ув. кандидату надо что-то новое собрать с нуля, предъявить на ревью и при этом не ошибиться, и тогда можно смело завершать процедуру join.

Подскажите, пожалуйста, проект для пакетирования кто-то должен дать или я сама могу выбрать?

(In reply to alxvmr from comment #77)
> Подскажите, пожалуйста, проект для пакетирования кто-то должен дать или я
> сама могу выбрать?
Кандидат вместе с ментором, как и раньше. Рецензент имеет право предложить что-то конкретное, если есть затруднения в подборе, но кандидат и ментор не обязаны прислушиваться.

Может подобрать ментор, можете вы (тогда за ментором на всякий случай остаётся право вето). Если бы среди уже собранных вами пакетов был перекос в сторону какой-то конкретной категории (такое бывает; некоторые вон собирают исключительно gnome apps), то я бы предложил собрать что-нибудь другое, но в вашем случае такого перекоса нет.

(In reply to Arseny Maslennikov from comment #78)
> Рецензент имеет право предложить
> что-то конкретное, если есть затруднения в подборе, но кандидат и ментор не
> обязаны прислушиваться. :)
Я пока что воздерживаюсь от того, чтобы предложить что-то конкретное. Я пошарился как-то по разделу "New/proposed packages" в bugzilla, чтобы предложить проект другому почти готовому кандидату в похожей ситуации, и вбросил с виду безобидный проект. А потом вчитался подробнее и выяснилось, что он не работает без ONNX Runtime, который ещё поди собери в Сизиф с соблюдением наших политик. Т. е. предлагать такое начинающему мейнтейнеру в качестве барьера — издевательство. До сих пор стыдно :/

Добрый день!

Собрала header-only библиотеку recycle - реализация простого пула ресурсов на C++.
Данная библиотека нужна для старта сборки форка проекта eclipse 4diac-forte (https://gitverse.ru/IT_Severstal/4diac-forte).

Номер сборочного задания 402397

(In reply to alxvmr from comment #80)
> Добрый день!
> 
> Собрала header-only библиотеку recycle - реализация простого пула ресурсов
> на C++.
> Данная библиотека нужна для старта сборки форка проекта eclipse 4diac-forte
> (https://gitverse.ru/IT_Severstal/4diac-forte).
> 
> https://git.altlinux.org/tasks/402397
Посмотрел; претензий у меня нет.
Идём дальше по процедуре.

Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!

Спасибо!