49644 2024-03-10 19:47:21 +0300 [3.6] join boria138@ 2024-12-24 10:22:27 +0300 1 1 4 Development Team Accounts join unspecified x86_64 Linux ASSIGNED P5 normal --- 1 boriabloger glebfm glebfm lav ldv mr.shad rider tergoev-m vt cas oldest_to_newest 242785 0 15668 boriabloger 2024-03-10 19:47:21 +0300 Created attachment 15668 ssh ключ Псевдоним: boria138 Адрес пересылки почты: boriabloger@protonmail.com Цель: научиться собирать пакеты Ментор: Виталий Липатов <lav@altlinux.org> 242786 1 15669 boriabloger 2024-03-10 19:47:44 +0300 Created attachment 15669 gpg ключ 242787 2 lav 2024-03-10 22:15:53 +0300 (Ответ для Boris Yumankulov на комментарий #0) ... > Ментор: Виталий Липатов <lav@altlinux.org> Подтверждаю менторство. 243549 3 glebfm 2024-03-26 22:34:18 +0300 Ментор есть, ключи в порядке. T/J/S -> 1.3. 244352 4 lav 2024-04-08 11:36:47 +0300 2.0 Кандидат готов начать вступление. 246340 5 glebfm 2024-05-16 18:45:01 +0300 ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. 246437 6 boriabloger 2024-05-19 21:41:05 +0300 Собран пакет: Distrobox Github: https://github.com/89luca89/distrobox Репо: https://git.altlinux.org/people/boria138/packages/?p=distrobox.git;a=summary 246441 7 lav 2024-05-19 22:45:53 +0300 3.0. Кандидат готов собирать пакеты. 246916 8 glebfm 2024-05-28 19:54:44 +0300 ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. T/J/S -> 3.6. 247035 9 boriabloger 2024-05-30 17:12:58 +0300 Собран пакет: NoteBook FanControl github: https://github.com/nbfc-linux/nbfc-linux Репо: https://git.altlinux.org/people/boria138/packages/?p=nbfc-linux.git;a=summary Таска: https://packages.altlinux.org/en/tasks/349948/ Собран пакет: ProtonPlus github: https://github.com/Vysp3r/ProtonPlus Репо: https://git.altlinux.org/people/boria138/packages/?p=protonplus.git;a=summary Таска: https://packages.altlinux.org/en/tasks/349934/ Собран Distrobox Таска: https://packages.altlinux.org/en/tasks/349896/ 247159 10 boriabloger 2024-06-03 13:12:22 +0300 Собран пакет: Aurea github: https://github.com/CleoMenezesJr/Aurea/ Репо: https://git.altlinux.org/people/boria138/packages/?p=aurea.git;a=summary Таска: https://packages.altlinux.org/ru/tasks/350254/ 247467 11 boriabloger 2024-06-10 14:21:42 +0300 Собран пакет: Ptyxis gitlab: https://gitlab.gnome.org/chergert/ptyxis Репо: https://git.altlinux.org/people/boria138/packages/?p=ptyxis.git;a=summary Таска: https://packages.altlinux.org/ru/tasks/350730/ Пришолось собрать патченный vte и приложить библиотеки от него в пакет иначе пакет не собирается и не запускается 247690 12 boriabloger 2024-06-17 09:56:33 +0300 Собран пакет: onnx github: https://github.com/onnx/onnx Репо: https://git.altlinux.org/people/boria138/packages/?p=onnx.git;a=summary Таска: https://packages.altlinux.org/ru/tasks/351066/ 247742 13 boriabloger 2024-06-18 09:58:39 +0300 Собран пакет: zram-generator github: https://github.com/systemd/zram-generator Репо: https://git.altlinux.org/people/boria138/packages/?p=zram-generator.git;a=summary Таска: https://packages.altlinux.org/ru/tasks/351104/ 247834 14 vt 2024-06-20 01:03:21 +0300 Предлагаю в devel пакетах с Си хедерами указывать Group: Development/C 247837 15 boriabloger 2024-06-20 07:40:51 +0300 (In reply to Vitaly Chikunov from comment #14) > Предлагаю в devel пакетах с Си хедерами указывать Group: Development/C Поменял группу 247838 16 boriabloger 2024-06-20 09:25:46 +0300 Обновил пакет ptyxis до 46.3 Таска: https://packages.altlinux.org/en/tasks/351201/ Выделил всё что касается vte в отдельный подпакет libvte-ptyxis 248020 17 boriabloger 2024-06-22 21:16:37 +0300 Исправил ошибку пересборки nbfc-linux из-за смены макросов Таска: https://packages.altlinux.org/ru/tasks/351359 248021 18 boriabloger 2024-06-22 21:18:07 +0300 Сделал NMU на lowdown для добавления devel пакета Таска: https://packages.altlinux.org/ru/tasks/351162 248364 19 boriabloger 2024-07-01 12:12:28 +0300 Собран пакет: libeditline github: https://github.com/troglobit/editline Репо: https://git.altlinux.org/people/boria138/packages/?p=libeditline.git;a=summary Таска: https://packages.altlinux.org/en/tasks/351887 248365 20 boriabloger 2024-07-01 12:15:04 +0300 Обновил пакет ptyxis до 46.4 Таска: https://packages.altlinux.org/en/tasks/351859/ 248540 21 lav 2024-07-04 18:11:27 +0300 4.0 Собранные выше пакеты отправлены в Сизиф. Считаю, что Борис готов отправлять пакеты в Сизиф самостоятельно. 248599 22 boriabloger 2024-07-06 15:27:20 +0300 Собран пакет: nix github: https://github.com/NixOS/nix Репо: https://git.altlinux.org/people/boria138/packages/?p=nix.git;a=summary Таска: https://packages.altlinux.org/en/tasks/351975 248613 23 boriabloger 2024-07-07 19:16:16 +0300 Собран пакет firmware-nouveau Репо: https://git.altlinux.org/people/boria138/packages/?p=firmware-nouveau.git;a=summary Бага: https://bugzilla.altlinux.org/50851 Таска: https://packages.altlinux.org/en/tasks/352326/ Пакет по сути набор прошивок nvidia которые нужны для поддержки аппартного ускорения видео на nouveau 248923 24 boriabloger 2024-07-16 15:28:17 +0300 Обновил nix до версии 2.23.3 Таска: https://packages.altlinux.org/en/tasks/352622/ Обновил ptyxis до версии 46.5 Таска: https://packages.altlinux.org/en/tasks/352621/ 249055 25 boriabloger 2024-07-19 15:56:39 +0300 Обновил ProtonPlus до версии 0.4.11 Таска: https://packages.altlinux.org/en/tasks/353116/ 249587 26 boriabloger 2024-08-02 11:12:25 +0300 Собран пакет: liboneapi-level-zero1 github: https://github.com/oneapi-src/level-zero Репо: https://git.altlinux.org/people/boria138/packages/?p=liboneapi-level-zero1.git;a=summary Таска: https://packages.altlinux.org/ru/tasks/354108/ Собран пакет: libintel-opencl-clang github: https://github.com/intel/opencl-clang Репо: https://git.altlinux.org/people/boria138/packages/?p=libintel-opencl-clang.git;a=summary Таска: https://packages.altlinux.org/ru/tasks/354118/ Собран пакет: libvc-intrinsics github: https://github.com/intel/vc-intrinsics Репо: https://git.altlinux.org/people/boria138/packages/?p=libvc-intrinsics.git;a=summary Таска: https://packages.altlinux.org/ru/tasks/354107/ 250158 27 boriabloger 2024-08-17 11:31:21 +0300 Обновил ptyxis до версии 46.6 Таска: https://packages.altlinux.org/en/tasks/354930/ 250159 28 boriabloger 2024-08-17 11:33:45 +0300 Собран пакет: libtoml11 github: https://github.com/ToruNiina/toml11 Репо: https://git.altlinux.org/people/boria138/packages/?p=libtoml11.git;a=summary Таска: https://packages.altlinux.org/en/tasks/355318/ 250160 29 boriabloger 2024-08-17 11:36:24 +0300 Обновил liboneapi-level-zero1 до версии 1.17.28 Таска: https://packages.altlinux.org/en/tasks/355316/ 250171 30 boriabloger 2024-08-18 11:32:30 +0300 Обновил nix до версии 2.24.2 Таска: https://packages.altlinux.org/en/tasks/355457/ 252096 31 glebfm 2024-09-24 19:29:38 +0300 Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 256008 32 rider 2024-12-13 12:05:30 +0300 Из свежего: https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/3148729581672545815 1) При наличии апстримного гита схема сборки выбрана без его использования. Этот вопрос ко всем собранным пакетам. 2) в секции files используется путь к файлу без макросов - зачем ? 49 /usr/lib/systemd/system-generators/zram-generator 256009 33 rider 2024-12-13 12:06:45 +0300 Пакет nix собран без учёта SharedLibsPolicy: https://packages.altlinux.org/ru/tasks/361634/ 256010 34 rider 2024-12-13 12:08:15 +0300 %configure --localstatedir=/nix/var --disable-tests --disable-unit-tests --disable-doc-gen --enable-gc 1) Надо включить тесты (во всех пакетах, в которых тесты есть) 2) почему localstatedir=/nix/var ? 256011 35 rider 2024-12-13 12:12:38 +0300 Все пакеты отдавайте на review только мне, не надо их аппрувить ментором. 256012 36 rider 2024-12-13 12:12:52 +0300 Как исправите - напишите. 256018 37 rider 2024-12-13 13:52:09 +0300 https://packages.altlinux.org/ru/sisyphus/srpms/liboneapi-level-zero1/ Вот этот пакет собран вообще неправильно (не в соответствии с SharedLibsPolicy), мы его сейчас переделаем, а этот придётся удалить. 256056 38 boriabloger 2024-12-14 10:06:21 +0300 (Ответ для Anton Farygin на комментарий #32) > Из свежего: > https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/ > 3148729581672545815 > > 1) При наличии апстримного гита схема сборки выбрана без его использования. > Этот вопрос ко всем собранным пакетам. То что я собираю из тарболла разве влияет на работу пакета ? Кроме аппстримной истории которая по моему мнению только мешает я ничего не теряю. полиси на этот счёт так же отсутствует, так что переделывать пакета с тарболла на гит не вижу смысла > 2) в секции files используется путь к файлу без макросов - зачем ? > 49 /usr/lib/systemd/system-generators/zram-generator По моему когда я собирал zram-generator макроса %_systemdgeneratordir не было, или я невнимательно смотрел, переделаю на макрос 256057 39 boriabloger 2024-12-14 10:26:34 +0300 365032 TESTED #1 [test-only] sisyphus zram-generator.git=1.2.1-alt2 256060 40 boriabloger 2024-12-14 13:45:45 +0300 (Ответ для Anton Farygin на комментарий #34) > %configure --localstatedir=/nix/var --disable-tests --disable-unit-tests > --disable-doc-gen --enable-gc > > 1) Надо включить тесты (во всех пакетах, в которых тесты есть) > 2) почему localstatedir=/nix/var ? 1) Тесты зависят от rapidcheck которого нет в репозиториях 2) Везде где nix есть нативным пакетом (Fedora, Arch и NiOS) localstatedir указывается как /nix/var решил последовать их примеру 256061 41 boriabloger 2024-12-14 14:04:40 +0300 (Ответ для Anton Farygin на комментарий #33) > Пакет nix собран без учёта SharedLibsPolicy: > https://packages.altlinux.org/ru/tasks/361634/ Вроде единственное нарушение policy это сборка %_libdir/*.so не в devel пакет, но только потому что эти библиотеки нужны самому nix и тогда получается что у него зависимость от devel пакета, что бы этого избежать положил библиотеки в него, могу положить их в пакет libnix это вроде policy не нарушает 256118 42 rider 2024-12-16 08:29:09 +0300 (In reply to Boris Yumankulov from comment #41) > (Ответ для Anton Farygin на комментарий #33) > > Пакет nix собран без учёта SharedLibsPolicy: > > https://packages.altlinux.org/ru/tasks/361634/ > > Вроде единственное нарушение policy это сборка %_libdir/*.so не в devel > пакет, но только потому что эти библиотеки нужны самому nix и тогда > получается что у него зависимость от devel пакета, что бы этого избежать > положил библиотеки в него, могу положить их в пакет libnix это вроде policy > не нарушает Просьба попросить вашего ментора помочь разобраться с shared libs policy. Если вы не поняли, в чём проблема. 256119 43 rider 2024-12-16 08:31:11 +0300 (In reply to Boris Yumankulov from comment #38) > (Ответ для Anton Farygin на комментарий #32) > > Из свежего: > > https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/ > > 3148729581672545815 > > > > 1) При наличии апстримного гита схема сборки выбрана без его использования. > > Этот вопрос ко всем собранным пакетам. > > То что я собираю из тарболла разве влияет на работу пакета ? Кроме > аппстримной истории которая по моему мнению только мешает я ничего не теряю. > полиси на этот счёт так же отсутствует, так что переделывать пакета с > тарболла на гит не вижу смысла Апстримная история очень помогает качественно сопровождать пакет. Поэтому большая просьба при наличии апстримного гита - собирать с сохранением апстримной истории в пакете. > > > 2) в секции files используется путь к файлу без макросов - зачем ? > > 49 /usr/lib/systemd/system-generators/zram-generator > > > По моему когда я собирал zram-generator макроса %_systemdgeneratordir не > было, или я невнимательно смотрел, переделаю на макрос Даже если нет макроса с полным путём, макрос для каталогов более верхнего уровня есть всегда. Непонятно, почему ваш ментор заапрувил такой пакет. 256120 44 rider 2024-12-16 08:32:07 +0300 (In reply to Boris Yumankulov from comment #40) > (Ответ для Anton Farygin на комментарий #34) > > %configure --localstatedir=/nix/var --disable-tests --disable-unit-tests > > --disable-doc-gen --enable-gc > > > > 1) Надо включить тесты (во всех пакетах, в которых тесты есть) > > 2) почему localstatedir=/nix/var ? > > 1) Тесты зависят от rapidcheck которого нет в репозиториях Его можно упакетить ? > 2) Везде где nix есть нативным пакетом (Fedora, Arch и NiOS) localstatedir > указывается как /nix/var решил последовать их примеру а в пакете каталога /nix/var нет. 256188 45 lav 2024-12-17 01:50:42 +0300 (Ответ для Anton Farygin на комментарий #43) > (In reply to Boris Yumankulov from comment #38) > > (Ответ для Anton Farygin на комментарий #32) > > > Из свежего: > > > https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/ > > > 3148729581672545815 > > > > > > 1) При наличии апстримного гита схема сборки выбрана без его использования. > > > Этот вопрос ко всем собранным пакетам. > > > > То что я собираю из тарболла разве влияет на работу пакета ? Кроме > > аппстримной истории которая по моему мнению только мешает я ничего не теряю. > > полиси на этот счёт так же отсутствует, так что переделывать пакета с > > тарболла на гит не вижу смысла > > Апстримная история очень помогает качественно сопровождать пакет. Поэтому Есть другая точка зрения — что апстримная история мешает сопровождать пакет, в частности, потому что апстримная история — о разработке, а в git пакета должна быть история пакета, а не разработки. Если же хочется сохранять историю апстрима для каких-то целей, это стоит делать отдельно, а не в пакете. Также добавлю, что существует не так мало проектов, которые релизы выпускают в виде тарболов, а содержимое git не подходит для прямой сборки без особых ухищрений. Поэтому, при всём уважении к другому мнению — оно остаётся другим мнением, и не ясно, почему нужно всех с ним продавливать. > большая просьба при наличии апстримного гита - собирать с сохранением > апстримной истории в пакете. > ... > Даже если нет макроса с полным путём, макрос для каталогов более верхнего > уровня есть всегда. > > Непонятно, почему ваш ментор заапрувил такой пакет. Я могу объяснить. 1. Потому что у нас нет ресурса, где написано, какие макросы стоит использовать и для чего. Есть безнадёжно устаревшая страница https://www.altlinux.org/Spec/Предопределенные_макросы 2. Потому что чрезмерное увлечение макросами к хорошему не приводит, нужно знать и понимать границы. А с ними проблема — см. пункт 1. 256194 46 ldv 2024-12-17 09:04:04 +0300 (In reply to Vitaly Lipatov from comment #45) > (Ответ для Anton Farygin на комментарий #43) > > (In reply to Boris Yumankulov from comment #38) > > > (Ответ для Anton Farygin на комментарий #32) > > > > Из свежего: > > > > https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/ > > > > 3148729581672545815 > > > > > > > > 1) При наличии апстримного гита схема сборки выбрана без его использования. > > > > Этот вопрос ко всем собранным пакетам. > > > > > > То что я собираю из тарболла разве влияет на работу пакета ? Кроме > > > аппстримной истории которая по моему мнению только мешает я ничего не теряю. > > > полиси на этот счёт так же отсутствует, так что переделывать пакета с > > > тарболла на гит не вижу смысла > > > > Апстримная история очень помогает качественно сопровождать пакет. Поэтому > Есть другая точка зрения — что апстримная история мешает сопровождать пакет, > в частности, потому что апстримная история — о разработке, а в git пакета > должна быть история пакета, а не разработки. Если же хочется сохранять > историю апстрима для каких-то целей, это стоит делать отдельно, а не в > пакете. > Также добавлю, что существует не так мало проектов, которые релизы выпускают > в виде тарболов, а содержимое git не подходит для прямой сборки без особых > ухищрений. > Поэтому, при всём уважении к другому мнению — оно остаётся другим мнением, и > не ясно, почему нужно всех с ним продавливать. Один из самых главных навыков самостоятельного мантейнера - уметь аргументированно отстаивать свою точку зрения. У меня нет сомнений в том, что этот навык есть у ментора, но мы же готовим нового самостоятельного мантейнера. 256214 47 rider 2024-12-17 12:05:58 +0300 Поддерживаю Диму. Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор убедил о единственно-правильном решении. Что касается макросов - вопрос был именно к ментору. Выглядит так, что ментор вообще не понимает смысла использования макросов. Очень жаль. 256241 48 boriabloger 2024-12-17 16:59:46 +0300 (In reply to Anton Farygin from comment #47) > Поддерживаю Диму. > Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор > убедил о единственно-правильном решении. > > Что касается макросов - вопрос был именно к ментору. Выглядит так, что > ментор вообще не понимает смысла использования макросов. > > Очень жаль. Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и историю пакета не стоит, подобное наоборот усложняет сопровождение, когда я захожу в свой репозиторий я хочу видеть только свои коммиты, если мне нужен будет аппстрим я пойду в аппстрим, и в тои что это единственно верный способ сопровождения пакетов меня никто не убеждал, я просто сопровождаю так как удобно для меня 256243 49 boriabloger 2024-12-17 17:40:58 +0300 (Ответ для Anton Farygin на комментарий #44) > (In reply to Boris Yumankulov from comment #40) > > (Ответ для Anton Farygin на комментарий #34) > > > %configure --localstatedir=/nix/var --disable-tests --disable-unit-tests > > > --disable-doc-gen --enable-gc > > > > > > 1) Надо включить тесты (во всех пакетах, в которых тесты есть) > > > 2) почему localstatedir=/nix/var ? > > > > 1) Тесты зависят от rapidcheck которого нет в репозиториях > > Его можно упакетить ? Из гита да, так как у пакета отсутствуют релизы > > 2) Везде где nix есть нативным пакетом (Fedora, Arch и NiOS) localstatedir > > указывается как /nix/var решил последовать их примеру > > а в пакете каталога /nix/var нет. Потому что он появляется после добавления репозитория nix-channel --add https://nixos.org/channels/nixpkgs-unstable nix-channel --update Можно упаковать в пакет пустые папки и файлы как это делается здесь https://download.copr.fedorainfracloud.org/results/petersen/nix/fedora-41-ppc64le/08039673-nix/nix.spec 256248 50 rider 2024-12-17 19:20:11 +0300 (In reply to Boris Yumankulov from comment #49) > > Можно упаковать в пакет пустые папки и файлы как это делается здесь > > https://download.copr.fedorainfracloud.org/results/petersen/nix/fedora-41- > ppc64le/08039673-nix/nix.spec Да, так и надо делать - после удаления пакета не должно оставаться мусора. 256249 51 rider 2024-12-17 19:22:12 +0300 (In reply to Boris Yumankulov from comment #48) > (In reply to Anton Farygin from comment #47) > > Поддерживаю Диму. > > Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор > > убедил о единственно-правильном решении. > > > > Что касается макросов - вопрос был именно к ментору. Выглядит так, что > > ментор вообще не понимает смысла использования макросов. > > > > Очень жаль. > > Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и > историю пакета не стоит, подобное наоборот усложняет сопровождение, когда я > захожу в свой репозиторий я хочу видеть только свои коммиты, если мне нужен > будет аппстрим я пойду в аппстрим, и в тои что это единственно верный способ > сопровождения пакетов меня никто не убеждал, я просто сопровождаю так как > удобно для меня Но вы не один ментейнер в репозитории и наличие апстримной истории сильно облегчает процесс поиска ошибок между релизами. Если вы принципиально планируете использовать эту схему для упаковки, то секретарю придётся поискать другого ревьювера - я не готов аппрувить задания, у которых есть апстримный гит и он не используется в полной мере для сопровождения пакетов. 256255 52 lav 2024-12-18 00:08:33 +0300 (Ответ для Anton Farygin на комментарий #47) ... > Что касается макросов - вопрос был именно к ментору. Выглядит так, что > ментор вообще не понимает смысла использования макросов. > > Очень жаль. Если что, это я 19 лет назад сделал пакет rpm-build-altlinux-compat, который делал возможным бэкпортирование пакетов, затруднённое неторопливым или отсутствующим переносом новых макросов на стабильные бранчи. И это я сделал rpm-build-compat, который обеспечивает базовые rpm/альтовые макросы на всех существующих системах, не обязательно основанных на rpm, включая FreeBSD. И я отлично понимаю, насколько макросы нужны, а где ими начали чрезмерно увлекаться, затрудняя вхождение новых мантейнеров (они должны строить у себя в голове таблицу соответствий путь<->макрос), не предоставляя актуального инструмента для перевода путей в макросы. Если сборочные скрипты думают одно, а в макросах другое, ничем тут макросы не помогут, всё равно сборка развалится. Это было красиво только для configure. Ну и для нормальных cmake-файлов (которые — редкость). Представление некоторых разработчиках о макросах достаточно устарело, вот и всё. 256256 53 lav 2024-12-18 00:10:56 +0300 (Ответ для Anton Farygin на комментарий #51) > (In reply to Boris Yumankulov from comment #48) > > (In reply to Anton Farygin from comment #47) > > > Поддерживаю Диму. > > > Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор > > > убедил о единственно-правильном решении. > > > > > > Что касается макросов - вопрос был именно к ментору. Выглядит так, что > > > ментор вообще не понимает смысла использования макросов. > > > > > > Очень жаль. > > > > Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и > > историю пакета не стоит, подобное наоборот усложняет сопровождение, когда я > > захожу в свой репозиторий я хочу видеть только свои коммиты, если мне нужен > > будет аппстрим я пойду в аппстрим, и в тои что это единственно верный способ > > сопровождения пакетов меня никто не убеждал, я просто сопровождаю так как > > удобно для меня > > Но вы не один ментейнер в репозитории и наличие апстримной истории сильно > облегчает процесс поиска ошибок между релизами. > > Если вы принципиально планируете использовать эту схему для упаковки, то > секретарю придётся поискать другого ревьювера - я не готов аппрувить > задания, у которых есть апстримный гит и он не используется в полной мере > для сопровождения пакетов. Прошу также отметить, что этот ревьювер всем навязывает свою схему сборки, вынуждая прогибаться под его требования, чтобы хоть как-то за пару лет пройти джойн. Сейчас появилась гибкость — единственный ревьювер вообще отказывается. Но добавлю, что ревьювера никто и не просит аппрувить задания. У него другая задача, как мне казалось. 256258 54 rider 2024-12-18 09:25:03 +0300 (In reply to Vitaly Lipatov from comment #53) > (Ответ для Anton Farygin на комментарий #51) > > (In reply to Boris Yumankulov from comment #48) > > > (In reply to Anton Farygin from comment #47) > > > > Поддерживаю Диму. > > > > Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор > > > > убедил о единственно-правильном решении. > > > > > > > > Что касается макросов - вопрос был именно к ментору. Выглядит так, что > > > > ментор вообще не понимает смысла использования макросов. > > > > > > > > Очень жаль. > > > > > > Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и > > > историю пакета не стоит, подобное наоборот усложняет сопровождение, когда я > > > захожу в свой репозиторий я хочу видеть только свои коммиты, если мне нужен > > > будет аппстрим я пойду в аппстрим, и в тои что это единственно верный способ > > > сопровождения пакетов меня никто не убеждал, я просто сопровождаю так как > > > удобно для меня > > > > Но вы не один ментейнер в репозитории и наличие апстримной истории сильно > > облегчает процесс поиска ошибок между релизами. > > > > Если вы принципиально планируете использовать эту схему для упаковки, то > > секретарю придётся поискать другого ревьювера - я не готов аппрувить > > задания, у которых есть апстримный гит и он не используется в полной мере > > для сопровождения пакетов. > Прошу также отметить, что этот ревьювер всем навязывает свою схему сборки, > вынуждая прогибаться под его требования, чтобы хоть как-то за пару лет > пройти джойн. Сейчас появилась гибкость — единственный ревьювер вообще > отказывается. Ревью дело добровольное. Я ещё хочу предложить дать право тому, кто ревьювил - отзывать ревью. Потому что уже неоднократно было мной замечено, как нормально обученный кандидат начинает опять скатываться в сборку пакетов "как Виталий советует". > > Но добавлю, что ревьювера никто и не просит аппрувить задания. У него другая > задача, как мне казалось. Старых не исправить, новых надо учить сразу делать хорошо. Всё просто. У нас ещё осталась возможность собирать из src.rpm и мы даже иногда ей пользуемся, но собирать все пакеты таким образом новому кандидату точно не стоит. Ровно такая же история с отказом от импорта гита. Я добавлю, что импорт апстримной истории помимо всех основных преимуществ создаёт ещё одно зеркало апстримной истории. Мне кажется что этот тикет не очень удачное место для данной дискуссии. 256262 55 lav 2024-12-18 11:39:24 +0300 (Ответ для Anton Farygin на комментарий #54) ... > Ревью дело добровольное. Я ещё хочу предложить дать право тому, кто ревьювил > - отзывать ревью. Потому что уже неоднократно было мной замечено, как > нормально обученный кандидат начинает опять скатываться в сборку пакетов > "как Виталий советует". Это фантазии, я никому не советую. И рассказываю, что есть два варианта. И что надо уметь собирать обоими способами. Просто я не навязываю своё мнение и не заставляю под страхом не пройти джойн делать как мне хочется. Нормально обученный кандидат — это тоже фантазии. Когда возникают нелепые формальные требования, возникают и способы приспособится к этому и сделать как требует преподаватель, потому что зачёт надо получить, а не тараканов ловить. Я ещё хочу предложить выбирать ревьюверов, а то ревью такое добровольное, что его кто-то тайный назначает, как судью в РФ. > > > > Но добавлю, что ревьювера никто и не просит аппрувить задания. У него другая > > задача, как мне казалось. > > Старых не исправить, новых надо учить сразу делать хорошо. Всё просто. > > У нас ещё осталась возможность собирать из src.rpm и мы даже иногда ей > пользуемся, но собирать все пакеты таким образом новому кандидату точно не > стоит. Это уход в крайность. > Ровно такая же история с отказом от импорта гита. Я добавлю, что импорт Да не с отказом от импорта гита. А с принуждением импортировать гит. > апстримной истории помимо всех основных преимуществ создаёт ещё одно зеркало > апстримной истории. А точно создание зеркала апстримной истории это задача мантейнера? У нас тут не разработка софта, а сопровождение. > Мне кажется что этот тикет не очень удачное место для данной дискуссии. Ну не я начал вопросы и упрёки к ментору. 256264 56 ldv 2024-12-18 11:49:48 +0300 (In reply to Boris Yumankulov from comment #48) > Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и > историю пакета не стоит, подобное наоборот усложняет сопровождение, Расскажите, пожалуйста, в чём именно для вас проявляется усложнение сопровождения. > когда я захожу в свой репозиторий я хочу видеть только свои коммиты, Расскажите, пожалуйста, каким образом апстримные коммиты мешают именно вам? > если мне нужен будет аппстрим я пойду в аппстрим, Окей, допустим. А если вам понадобятся и те, и другие коммиты, вы будете переключаться между двумя репозиториями? 256272 57 rider 2024-12-18 13:52:07 +0300 (In reply to Vitaly Lipatov from comment #55) > (Ответ для Anton Farygin на комментарий #54) > > апстримной истории помимо всех основных преимуществ создаёт ещё одно зеркало > > апстримной истории. > А точно создание зеркала апстримной истории это задача мантейнера? У нас тут > не разработка софта, а сопровождение. Да, действительно - когда ты убеждаешь окружающих в том, что сборка через импорт тарболлов это хорошая практика, ты используешь посыл что разработка и сопровождение это разные понятия и сопровождающий не должен принимать участия в разработке. Я очень надеюсь что к нам будут приходить в команду люди, не разделяющие это мнение. Качественно сопровождать софт можно только принимая участия в разработке, чем мы с тобой к сожалению не занимаемся (просто потому что упакечивать приходится слишком много пакетов и это точно не позволяет нам принимать участие в разработке). Не занимаясь (не принимая участия) апстримной разработкой невозможно разгребать то множество ошибок, которое сыпется на ментейнера по функционированию собираемого софта. Ну и кстати, уж коль ты всё-таки решил продолжить в этом тикете: что делать с менторами, которые сами нарушают Policy ? Я сейчас про вот это Policy: https://www.altlinux.org/Vulnerability_Policy И ещё почему-то так сложилось что только кандидаты, ментором которых является lav@ сопротивляются схеме ведения пакетов с апстримной историей гита, все остальные после объяснения переходят на неё и спокойно без проблем сопровождают пакеты с использованием этой схемы ? 256456 58 boriabloger 2024-12-23 09:50:32 +0300 (In reply to Dmitry V. Levin from comment #56) > (In reply to Boris Yumankulov from comment #48) > > Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и > > историю пакета не стоит, подобное наоборот усложняет сопровождение, > > Расскажите, пожалуйста, в чём именно для вас проявляется усложнение > сопровождения. > > > когда я захожу в свой репозиторий я хочу видеть только свои коммиты, > > Расскажите, пожалуйста, каким образом апстримные коммиты мешают именно вам? > > > если мне нужен будет аппстрим я пойду в аппстрим, > > Окей, допустим. А если вам понадобятся и те, и другие коммиты, вы будете > переключаться между двумя репозиториями? Да, я так и делаю и всегда делал при сопровождение пакетов для Arch Linux и Fedora Linux, полагаю отсюда привычка собирать из тарбола, я просто собираю так как привык собирать в других дистрибутивах, потому что лично для себя я не вижу преимуществ сборки с гита, что касается аргумента на счёт того что я не один и должен собирать так как удобно другим, я так не считаю, пока я мейнтейнер пакета я имею полное право собирать как удобно и привычно мне, а если мейнтейнер сменится пусть сам и переделывает как ему будет удобно 256461 59 rider 2024-12-23 10:22:23 +0300 Нести в Альт Линукс практику сборки из других дистрибутивов - очень плохая идея. Тут свои сложившиеся традиции и в рамках JOIN лучше перенять их. 256506 60 boriabloger 2024-12-24 09:41:32 +0300 (Ответ для Anton Farygin на комментарий #59) > Нести в Альт Линукс практику сборки из других дистрибутивов - очень плохая > идея. Тут свои сложившиеся традиции и в рамках JOIN лучше перенять их. В который раз спрашиваю разве сборка с тарбола вместо гита является ошибкой ? Пакет из тарбола хуже работает, у него проблемы с зависимостями, или ещё что ? Я не несу практику сборки из других дистрибутивов в Альт и стараюсь соблюдать policy, но собирать с гита не собираюсь принципиально, если вы настаиваете на сборке с гита то думаю стоит найти нового ревьювера 256510 61 rider 2024-12-24 10:22:27 +0300 Я с этого и начал. @glebfm - у меня освободился ещё один слот 15668 2024-03-10 19:47:21 +0300 2024-03-10 19:47:21 +0300 ssh ключ alt.pub application/vnd.exstream-package 94 boriabloger c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUduMFl3K0hQNFlzMTU2dm5mWjBi RDk1TG0rUGl2NHo4OVlyN21tOWJjaGUgYmFycnlAbHVuYW9zCg== 15669 2024-03-10 19:47:44 +0300 2024-03-10 19:47:44 +0300 gpg ключ alt.pub.gpg application/pgp-keys 3147 boriabloger LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdYdDRIVUJFQUM5bmN0 OU1hYVhYZkVxeUV6dldnN2R6TE0vZExLRTNsOEFxM05yaEpOL1JLa25vRm91Cjh5SmQ4c1JCRENG bVN3UGFuSGJtUUt3UWNCNFpxR0pOZVkzY0VpVGhvYnkxM3pJM3hXejZZa2NSbnloRmN4NnUKcmFD eVhGK3l2cVdwRGExaGdEVlBLZzI5WE9jRnoremh4Y0NSbnRaY0pEZHozSUJCRzE1SXpjdkZYMFVm bWlPZQpLbWZueklLZVcwYUxJZ1hKVDIyMk1GQk4vUUpsMStNUFcxTnFvV213bTFTdGpBeGkxdkpN bTNjVDRzc1cySnRUCmE1UFJwcDAvMml0Snk0bFZpY3NQbitpRW1KbUdGcVBwbzZYcDI0OVdEcEx1 SHpyYUVMWm1TbTBJOGJvUWtXa1MKczlHZGh3aENHQndzR01LMFhqYzFybDJwN3prK2FhelYxcm9m TjRwM3VJRkI5YU5kNGxmT1RoTi9IN1YvQTVaSQpJSTFFU3BWVEpqZ2M0dUNaQlFaRW5QMmNsYjVN eTRKQm9SZXlvUWZYWlprVTQvY3gxbnFlbngwSTRsbUJXZW9OCjQzd3Q0RXdvSHlWc1d1cG9TUVF3 WVpxT1E4d1FYeE5PSExaaHJwTTJaNjRPYUJNcndFa1gvMldXRVppMlByeHgKVi9XYVEvYjZTN3oz WitMU0pJZFhxc05mQ1F4dktvc2FGcUgxK3lNN1pld1VUOFpvODVTM2crOWJRYmJGRVE4Vgo4NHZH TGlQd3kydFczczVmY0lDQmlvaUp6QzltdnYvWEJockpyVkF1MU0vWDhMbWhnU1orVWtRU3FNSFRr V3NtCldDcVI3K3lzdzRqSEo5aS9BalJPS0VDeitPNHhoV28rdmI0RUFrWG94K0dWTjZvcVQyRlBq MkJDWndBUkFRQUIKdENoQ2IzSnBjeUJaZFcxaGJtdDFiRzkySUR4aWIzSnBZVEV6T0VCaGJIUnNh VzUxZUM1dmNtYytpUUpSQkJNQgpDQUE3RmlFRVUxcEhvT2tQY2dIcEpNenhGTFNsWnovVG5IWUZB bVh0NEhVQ0d3TUZDd2tJQndJQ0lnSUdGUW9KCkNBc0NCQllDQXdFQ0hnY0NGNEFBQ2drUUZMU2xa ei9UbkhhU2lRLytMc1BwL2RSNEdyd2FoUlRlR0ljUndZQU4KZk4rVkVndkhnTHVRLzZSZm5MSEVj Wi91SnRMUnF6WTNObC9CcCtGSlpCZGZNWUVQQ01rWUN3c0pjRThUSmI3NwpNM1hmK2lpMDhhVUdR d0xqUklPM1dJSjNPKzRUQlN1VXZ4a0tMdnVDMzV3SnE2SGFXbVlGYk9VNUZJWWE0NldFCmZQVEFu bWpOY3I3TE85ZDB2RUJ1Y0h4Q0Z5bG40Mkd4VW1hQ0d4dDFZaHdhQXZGWVZkQTUzK0J5TGZkMWVK WUoKQjdtZWU5UndtOG9JVCs3MkVJWk1kbDB0VEU4SGNqeFc4OWFUaFFXNUZNUEErOERhUGgrU291 WUpxK1NRdDBOQgpBREV4cXBIeUUvUUU3Q3d4Tlh1ZC9lc1llbFdDejJIQUtKMkpiZnZMQ09FTEJn K3lueGpkRjRqd1EzbVo1VzErCmVjL0p2aXBaeXp6SWZhaUZkQmc4WEgzcGZjckVPVUpDVlZOK0JF UkF1MmNheit2RjBqZ0FTQ29mcG5FR0lkUkMKN3RkWDA5SnJGdFJXM0t2aEZuMHVRKy94aSt0SFRo NStKNkMxaHlDZEdub3ZqS1NnM2Nkc0hhYVI3Wm5FZ0txYgp0ZDFRazd0S1BoVzlmUUdPejl5QVBs TUZFaXFzRUZlTllSajYrTTNvNDIxMmZmSFVWclRMQlZRWkdZcGZsU3A2Cmp1bE41RDlyN1pHOGJO U01iWGJ6U1ZuKzJwbDN0WnhHN0YraDg4LzhJZU94a0I4czllZjdPak8wbHpQUDF4Z2kKQllPNFcr WkZ3ZFY2N3o2OHV5ODJGdzRteGpWakExRDJ3NldLeVVkNnJ4aHRNV0lMN1J2enM1akVRYWpLdENR RQo5NVp5MUlkZzRadTA4QXRTRTY2NUFnMEVaZTNnZFFFUUFQTUNhUEFPK2s3N2N0ZU1YOWE2SWxM ZUdJcU9rcUlBCmV1UDR2K2JvU0x6aTBmT1FiOUF4anJuRHJhQ1hheDVsczhpTVVMYnRzMGlET0cv b3VRSU11L0hJV2Uvc0ZBVEsKdlJrMmJlZ2lQUVh6WFljYUlVK2d3RnUrSDlveWEzVU9KQUdUbXJq WEROQ1FsSjVIcXpyL28xTWJDSWhoZ003bgpoZ3cra2lqODhJQ1pvSURkVXBuTXNrelQvS2YzYVFM L1JDZWw5MERDSkRsdEl6YkNUNE9SYlB6TURFTFVxZFNXCjNGemUwNFJqMnJPMzNuTTByQjNhTXN3 VDJZMnV4aU1xb1llbFhIV29WOWpqV2E2RTVORzJ4RTVqbFIrZngrZGwKNjRMYnlLaTFoMVdFNjUr ZndzL3BNOFV3SGR5WVdHNUtoM2ZxcG9PSEcvMmNPTDRWMVloSGpCUlpnSVBlQ3JtTQo5TlRlYXRw cExRQ2UxS1hUZUJmWkh5TGxMSVlJcDBYRC9pTXVWM1psVHlWcjFsQXJ2cDFkS01ldXFDbUhlRmxK ClU5V1F0elJNOXIwSW1FSlEvTndhR3llakEydmxvWnR6Vk52NHJ3VWU2QnRWTFVLeEF1emFWQVZR NEEvdFlqTksKRVhtNWd4UDBwdW0wczl4d0dOTFVtdjV0TXI4bm1TeDNvK013OFg0clBXNDZWR2dP UEMxNDE1K1lvSmFySDhycAp1eDFsS1lEd2M5cDV0ZW15eGJtODZBeEFadE9GQ3hZUnFyTTE1aXR3 SmNVY2dYZDg3ODd3NUsvUmUvc29KVXEzCkJIMHJKNWdUQ09MaGRkMDl6Qis5WU5OSE1WbEdScWlt NkpwcFdCRmZ3ckgwRkQyallRSzlURkI5cFVyN2x2NGwKN2lndHczM2VTbzlYQUJFQkFBR0pBallF R0FFSUFDQVdJUVJUV2tlZzZROXlBZWtrelBFVXRLVm5QOU9jZGdVQwpaZTNnZFFJYkRBQUtDUkFV dEtWblA5T2NkclZhRUFDTTV2RERRV1U2SjJFRzdobVNEYmY2RGhSVldGQi85S2VqCnowckNOS3dk K2x0L0VvazVxbVRGTVNiclREV1pGMXZ2dkVJS3dpdGxWV1o4MGFhUExTSjFQWlJ0bVNrbE5jd0IK eC80TUtnaHZrT29FTHUxRTNQa1lKbXd1S0c2SXBsdTlqdHRZWFVyU2g3aVhZRHpqNG5KVmd4NENX Z3A5UVlOcAovc0pGYktyZWlOWWY3NW5icmNFRmliRHJ3cWJDeFArTmpDQjIrT0g2ZzlRaUE2WmJx RlNTUXVkQnRUd09COVB4CkpTeHVrbUN2ejJ2Y1RXU2ppK2J6VFZhS01yTlBFZ3RXRHdZbU41UkZw OFF0akFPK1NjQWM0U1RORURVNmljYWsKaUttWjRjaU01bzB4UU5MRm10TFY0czdXUzhMVzdFSTV3 V1R6bEx0N3ZZVm5DcmxxbWhocGI2Ylh2MEc5NUZSdwpoVm9qdVNCakpwdnI2K0d6cFptWkthNlp6 OENIRU5tandCNElzR0htK01obDJCbjF3UTB2TCs5U2JneWhlYWl5Cjh6cFowS2VTS2xzUHdjMExl cmxrUHFPMUkvcXAxQUZxT0tWME9sOG1neDh0U2FqQjJqVVE1OHhXM0lMRHREWm8KUzQwZkc5Vkdw alh1NDl6L2t0VXVIS0daZFBOYzUycEpkQjVyM1JuckdsM1VCRkx2RThaM3AycXgwVkIxWVVFSQpk SGtoem9wbWx4cjZTeWtMRFdFb2JmVU1UWlJ6VmY5Z3dUcnAxeVY4bFNmZkhFOHpEL2UyelVvMHZt T2lXbWN2CkVKN1d4YXJxOGRTMG8yb0FuWEpyc3JoMExSQlk2ZFdnOWRHd3lCZXo0eUZiRGdXcEd3 ZDJOTDAza0RUbUdBek8KTmJ6bDJxRGZLdz09Cj16SktDCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZ IEJMT0NLLS0tLS0K