Псевдоним: armatik Почта: Fomchenkov Semen <armatik@altlinux.org> Адрес пересылки почты: s.fomchenkov@yandex.ru Имя ментора: Юрий Седунов Почта ментора: <aris@altlinux.org> Цель: Научиться собирать пакеты, в частности использующих GTK4 и libadwaita. Интересно будет обновить сборочное окружение GNOME для сборки пакетов.
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.
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-а.
