Created attachment 15346 [details]
ssh_key

Добавлен ключ ssh.

Created attachment 15347 [details]
gpg_key

Добавлен ключ gpg.

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

> Имя ментора: Юрий Седунов
> Почта ментора: <aris@altlinux.org>

Подтверждаю, Семен готов начать процесс вступления.
Прошу зарегистрировать его на gitery.alt.

Добрый день, @aris
Прошу рассмотреть возможность изменения статуса join'a (T/J/S) с учётом моего вклада в создание пакетов:
- https://packages.altlinux.org/ru/sisyphus/srpms/iplookup-gtk/
- https://packages.altlinux.org/ru/sisyphus/srpms/wike/
- https://packages.altlinux.org/ru/sisyphus/srpms/ascii-draw/
- https://packages.altlinux.org/ru/sisyphus/srpms/textpieces/
Кроме того, я отправил вам по электронной почте файлы spec для сборки, но они не были собраны. Эти файлы я прилагаю во вложении.

Created attachment 16167 [details]
spec-файл speedtest

Created attachment 16168 [details]
spec-файл notejot

Created attachment 16169 [details]
patch-файл notejot

Created attachment 16170 [details]
patch-файл notepad

Твои претензии не обоснованы, Сёма. Остынь, работай по плану, разбирайся в проблемах по-существу. Пока ты только в начале пути.

То что ты здесь навыкладывал, тоже надо исправлять.

(Ответ для Yuri N. Sedunov на комментарий #9)
> Твои претензии не обоснованы, Сёма. Остынь, работай по плану, разбирайся в
> проблемах по-существу. Пока ты только в начале пути.
> 
> То что ты здесь навыкладывал, тоже надо исправлять.

Подскажите пожалуйста, о каких претензиях идёт речь. Я попросил пересмотреть статуса join'a согласно информации на странице https://www.altlinux.org/Team/Join/Secretary. На каком этапе я нахожусь сейчас.

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

Добрый день, кажется ошибка не решена, подскажите тогда в чем задача ментора?

Ожидаю получить ответ на предыдущий свой комментарий :)

Юрий, здравствуйте!

Прошу прощения за вопрос Павла. Мы обсудили, что этот отчёт не предполагает вопросов от широкой аудитории. Вопрос снимается.

Прошу заменить ментора в процессе join на shaba@

(In reply to Cемен Фомченков from comment #2)
> Created attachment 15347 [details]
> gpg_key
В этом файле два ключа, нужен только один.

Принимаю желающего на вступление.
Посмотрим как у меня получится/не получится 8)

Семён парень вдумчивый, желаю ему удачи, 
Если что готов консультировать его помимо ментора.
Специалист по Python, так что советую использовать в этом направлении. 

Если что, я на связи в телеграмме и могу проконсультировать.

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

Опять-же новички могли-бы и AltWiki отредактировать, так-как то что понятно знающему человеку, может не очень понятно начинающему. 

PS Еще раз мои извинения. за то что "встрял" в разговор

> Принимаю желающего на вступление.
> Посмотрим как у меня получится/не получится 8)

Я думаю получится, Семену только сессию надо сдать ;-)

(Ответ для Gleb F-Malinovskiy на комментарий #16)
> (In reply to Cемен Фомченков from comment #2)
> > Created attachment 15347 [details] [подробности] [details]
> > gpg_key
> В этом файле два ключа, нужен только один.
Прикладываю новый ключ gpg.

Created attachment 16193 [details]
gpg_key

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

Кандидат готов начать вступление.
Прошу выдать доступ к gitery.alt

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

T/J/S -> 2.3.

Кандидат готов собирать пакеты.
Прошу предоставить доступ к  gyle.alt.

Кандидат готов собирать пакеты.
Прошу предоставить доступ к  gyle.alt.

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

T/J/S -> 3.6.

Подопечный готов отправлять пакеты в Сизиф. Прошу призвать рецензента.

Призову самого себя в качестве рецензента.
T/J/S -> 4.2.

1. Настоятельно рекомендую подумать о том, чтобы включить хук pre-commit в git,
потому что в некоторых коммитах встречаются «красные» пробелы, например в конце
строк.
2. Тут просто на подумать: некоторые макросы кажутся излишними, например:
* в libhelium/libbismuth макрос %namespace кажется совсем бесполезным, но
%libhelium/%libbismuth тоже усложняет картину (а не упрощает её);
* klaro, read-it-later, alt-gnome-experimental-settings: макрос %app_id,
например, тоже не очень нужен по сути на случай, что поменяется идентификатор
программы (т.е. с очень большой вероятностью никогда).
Я имею в виду: зачем нужен макрос, если он не предполагает того, чтобы его
изменять, но усложняет чтение spec-файла.
3. Вопрос про libhelium: какова вероятность, что версия пакета не будет
совпадать с %tau_helium_ver?
4. codium: вместо %filter_from_requires /^\/usr\/lib\/ld-linux-aarch64.*/d лучше
использовать patchelf --set-interpreter /lib64/ld-linux-aarch64.so.1 как это
делается в других пакетах.
5. В некоторых пакетах, например gnome-legacy-theme-switcher, libhelium и
libbismuth, пакет libgio устанавливается для тестов? Почему он не попадает в
сборочную среду, если это библиотека?
6. gnome-console-keybind: 00-console-keybind устанавливается в /etc, но зачастую
в /etc кладутся файлы локальной (админской) конфигурации. Может быть у dconf
тоже возможность положить пакетные части в /usr/lib или какое-то такое место?
7. tailscale: зачем в BuildRequires: /proc?
8. ignition-adw, ohmysvg: в пакетах пачка Requires: typelib(..., что выглядит
как потенциальная проблема, например когда список зависимостей меняется. Может
быть существуют какие-то возможности для автоматической генерации таких
зависимостей?

9. Ещё одна вещь, про которую я забыл сказать: подход с использованием каталога
.gear для spec-файла, патчей и прочих дополнительных файлов я считаю
неправильным. Этот подход достаточно распространён, поэтому сложно засунуть
этого джина обратно в бутылку, когда половина команды так делает, но обратить
внимание всё равно хочется. .gear это каталог для служебных файлов,
используемых gear, туда *можно* положить файлы, но это нецелевое его
использование. Для spec-а и прочих дополнительных файлов я обычно использую
каталог alt, но он может называться как угодно.

Спасибо за рецензирование, постараюсь ответить на все пункты:

1. Спасибо, обязательно воспользуюсь этим, наблюдал у себя такое и к сожалению не всегда получалось уследить за этим;

2. Тут скорее я пришёл к тому, что достаточно шаблонные вещи стараюсь описать в самом начале спека, особенно те которые могут фигурировать в путях и в названиях файлов далее по спеку. Но по %libhelium/%libbismuth согласен, палку с шаблонностью тут я перегнул, учту на будущее и исправлю при обновлении. %namespace показался достаточно шаблонным при взгляде на libadwaita;

3. Да, как например сейчас (и раньше такое тоже было). От shaba@ было предложение вытягивать пакет tau-helium по файлам так как он собирается как subproject в libhelium, но там бы пришлось патчить сильно meson.build что бы собирать его со всеми нужными опциями. И по итогу учитывая это и различие в версионировании в прошлом, решил собирать отдельными пакетами;

4. Беря codium после долгой задержки в его сопровождении первый раз столкнулся с тем что нужно было отфильтровать зависимости, узнал про %filter_from_requires и видимо решил всё под одну гребёнку отправить. Возьму patchelf --set-interpreter на вооружение для таких ситуаций и исправлю. Задание с исправлением: https://packages.altlinux.org/ru/tasks/391740/ ;

5. От libgio нужен бинарный файл /usr/bin/glib-compile-schemas который нужен для выполнения одного из базовых тестов meson для большинства GNOME-пакетов "Validate schema file" в котором проверяется файл схемы dconf. Для сборки пакета это не нужно, так как схемы там не компилируются, а остаются в исходном виде, компиляция уже происходит после установки у пользователя;

6. Тут столкнулся с тем что нужно было не только переопределять значения схем (с чем я обычно и сталкивался при работе с dconf), а ещё и создать новую, в рамках уже заданного шаблона. Кроме /etc не смог найти такое место, где в данном случае корректно обработал бы dconf. А override схем обычно как раз лежат в /usr/share/glib-2.0/schemas/;

7. При сборке без /proc столкнулся с ошибкой: failed to start telemetry sidecar: os.Executable: readlink /proc/self/exe: no such file or directory посмотрев другие пакеты на golang, например forgejo, заметил аналогичное действие, поэтому не придал этому сильного внимания (как я понимаю зря);

8. Да, есть rpm-build-gir, но с TS он к сожалению не сработал (https://bugzilla.altlinux.org/52815). Я сейчас столкнулся с проблемой при обновлении ignition-adw, так как там теперь используется TS for GIR (https://github.com/gjsify/ts-for-gir), возможно получиться раскрыть эту шкатулку;

9. Да согласен, тут скорее пошёл по накатанной как видел в большинстве пакетов, но патчи сейчас уже начал оформлять в виде коммитов в ветке гита. Думаю, теперь постепенно с обновлениями пакетов буду выносить всё не относиться к gear в alt.

(In reply to Semen Fomchenkov from comment #30)
> 5. От libgio нужен бинарный файл /usr/bin/glib-compile-schemas который нужен
> для выполнения одного из базовых тестов meson для большинства GNOME-пакетов
> "Validate schema file" в котором проверяется файл схемы dconf. Для сборки
> пакета это не нужно, так как схемы там не компилируются, а остаются в
> исходном виде, компиляция уже происходит после установки у пользователя;
Т.е. на самом деле ошибка в libgio, где утилиты запакованы в тот же пакет,
что и библиотека. К сожалению, из-за обратной совместимости такие ошибки очень
сложно исправлять после того, как они были сделаны.

6. Ну если нет такого места, то ничего не поделаешь.
 
> 7. При сборке без /proc столкнулся с ошибкой: failed to start telemetry
> sidecar: os.Executable: readlink /proc/self/exe: no such file or directory
> посмотрев другие пакеты на golang, например forgejo, заметил аналогичное
> действие, поэтому не придал этому сильного внимания (как я понимаю зря);
Если пакету всегда нужен /proc для работы и пакет используется для сборки,
то зависимость нужна в самом пакете (например, для java всегда нужен /proc, поэтому в пакете есть зависимость).
Если же /proc нужен для чего-то, что делает сам пакет, то это нормальная зависимость.
hasher учитывает и BuildRequires: и Requires: (в установленных в сборочную среду пакетах), см. 4.2.1 в hasher FAQ.
 
> 8. Да, есть rpm-build-gir, но с TS он к сожалению не сработал
> (https://bugzilla.altlinux.org/52815). Я сейчас столкнулся с проблемой при
> обновлении ignition-adw, так как там теперь используется TS for GIR
> (https://github.com/gjsify/ts-for-gir), возможно получиться раскрыть эту
> шкатулку;
Получается, это важная тема на самом деле.

Ещё одна вещь:

10. В коммит, в котором импортируются исходники лучше писать либо url, либо команды, которые были выполнены, чтобы получить исходники. Например, если используется gear-import, ей можно передать -c "Import <url>" программе gear-import.

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

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

Семён, мои поздравления с прохождением join ^.^

﷐[U+1F32D]﷑

(In reply to Gleb F-Malinovskiy from comment #32)
> Ещё одна вещь:
> 
> 10. В коммит, в котором импортируются исходники лучше писать либо url, либо
> команды, которые были выполнены, чтобы получить исходники. Например, если
> используется gear-import, ей можно передать -c "Import <url>" программе
> gear-import.

Если import в пакете повторяется, имеет смысл настроить commit message в .git/config, например:

[gear "import"]
        commit-message = Import https://ftp.gnu.org/gnu/@name@/@archive_file@

(In reply to Dmitry V. Levin from comment #36)
>         commit-message = Import https://ftp.gnu.org/gnu/@name@/@archive_file@
Я тоже так делал, но если это не проект GNU, то нет гарантии, что не поменяется фиксированная часть URL-а.