40788 2021-08-19 22:24:34 +0300 [done] join kotopesutility@ 2022-05-17 13:06:22 +0300 1 1 4 Development Team Accounts join unspecified x86_64 Linux CLOSED FIXED https://www.altlinux.org/Team/Join/Secretary P5 normal --- 1 kotopesutility glebfm darktemplar darktemplaralt george glebfm grenka ldv neurofreak-alt cas oldest_to_newest 201864 0 9613 kotopesutility 2021-08-19 22:24:34 +0300 Created attachment 9613 ssh and gpg public keys Добрый день! Прошу принять меня в ALT Linux Team. Мой псевдоним kotopesutility, адрес для перессылки почты kotopesutility@yandex.ru. Моим ментором прошу назначить Георгия Владимировича Курячего. Я уже несколько лет пользователь Linux и владею несколькими языками программирования, но я хотел бы научиться собирать пакеты и принять участие в разработке. 201865 1 9614 kotopesutility 2021-08-19 22:28:58 +0300 Created attachment 9614 SSH-key Прошу прощения, почему-то с первого раза прикрепился только GPG-ключ 201907 2 george 2021-08-20 20:46:18 +0300 > Моим ментором прошу назначить Георгия Владимировича Курячего. Подтвержаю 202016 3 glebfm 2021-08-24 22:05:14 +0300 (In reply to kotopesutility from comment #1) > Created attachment 9614 [details] > SSH-key Мы рекомендуем ssh ключи ed25519 или RSA >= 4096. 202023 4 9622 kotopesutility 2021-08-25 01:20:32 +0300 Created attachment 9622 SSH-key Простите, вот ключ нужной длины. 202236 5 glebfm 2021-09-02 15:39:08 +0300 (In reply to kotopesutility from comment #4) > Created attachment 9622 [details] > SSH-key > > Простите, вот ключ нужной длины. Ok. T/J/S -> 1.3. 202247 6 george 2021-09-02 17:21:44 +0300 Пора заводить аккаунты, я считаю. T/J/S 1.3 → T.J.S 2.1 202248 7 glebfm 2021-09-02 17:25:17 +0300 ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.4. 202442 8 george 2021-09-07 19:48:53 +0300 Надо бы пакеты на сборочнице потестить, кандидат готов! → 3.0 202765 9 glebfm 2021-09-14 17:32:48 +0300 Пакет alt-gpgkeys обновлён. T/J/S -> 3.4. 204274 10 george 2021-10-30 22:34:12 +0300 Мне кажется, Кандитат уже вполне кандидат, и пора ему подыскать Рецензента! → 4.0 204943 11 george 2021-11-15 20:42:11 +0300 ping 4.0 204966 12 glebfm 2021-11-16 15:10:49 +0300 Призван ещё один человек (darktemplar@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 205802 13 george 2021-12-07 11:53:33 +0300 ping Может, рецензента поменять? 205816 14 darktemplaralt 2021-12-07 15:05:19 +0300 (Ответ для Fr. Br. George на комментарий #13) > ping > > Может, рецензента поменять? Извиняюсь, пропустил. Если хотите поменять - с моей стороны возражений нет. Или же я посмотрю в ближайшее время. 205838 15 darktemplaralt 2021-12-07 17:51:20 +0300 https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=summary 1) Оформление: почему бы не объединить следующие два коммита в один? https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commit;h=dcc699335a37b835faa83cbca90526e6fae62533 https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commit;h=a69f4e6bdd7445b34ac02ad690d48c4509add21d 2) Оформление: в следующем коммите зачем-то присутствует лишний файл .gear/rules~. Он для сборки пакета не нужен и стоит его удалить. https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commitdiff;h=dcc699335a37b835faa83cbca90526e6fae62533 3) Из spec-файла: %files /usr/bin/slurp Для путей принято по возможности использовать макросы. Т.е. "/usr/bin/slurp" стоит заменить на "%_bindir/slurp". Подробный, но не полный, список макросов и их значений можно найти здесь: https://www.altlinux.org/Spec/Предопределенные_макросы 4) Указана версия пакета 1.3.2, но пакет собирается из апстримных исходников из коммита https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commitdiff;h=ce12cb2be7add82792211113745df0321c3cb115 в то время как тэг v1.3.2 указывает на другой коммит https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commitdiff;h=04945facb2f16ab212bbe7069908b850f654b9fa Вот соответственно лог: https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=shortlog;h=dcc699335a37b835faa83cbca90526e6fae62533 В случаях когда пакет собирается из апстримного коммита, не соответствующего апстримному выпуску, стоит указывать информацию о таком коммите в релизе пакета: https://www.altlinux.org/Spec#Промежуточные_upstream-релизы Другим вариантом решения может быть, если эти коммиты не нужны, делать сборку пакета из релизного коммита. https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=summary 1) Оформление: опять же не вижу смысла не объединять эти два коммита, или же не разбить изменения другим способом: сначала в один коммит изменения в самом пакете, затем в другой коммит spec-файл и .gear/rules. https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=commit;h=a28e37d0040519f1acf39181221da7afb8069624 https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=commit;h=e27e92a26f7a2cb462a4f310529b30d24a9f313c К тому же из тэга 1.3.2-alt1 пакет явно не соберётся, других тэгов пригодных для сборки я тоже не вижу. 2) Опять-таки стоит использовать макросы: /usr/bin/grim -> %_bindir/grim /usr/share/man/man1/grim.1.xz -> %_man1dir/grim.1* /usr/share/zsh/Completion/ALT/_grim -> %_datadir/zsh/Completion/ALT/_grim /usr/share/fish/vendor_completions.d/grim.fish -> %_datadir/fish/vendor_completions.d/grim.fish /usr/share/bash-completion/completions/grim.bash -> %_datadir/bash-completion/completions/grim.bash В данном случае, строка "/usr/share/man/man1/grim.1.xz" особенно может вызвать проблемы. Тип сжатия man-страниц ранее уже менялся, и в будущем может легко поменяться снова. Некоторые пакеты переставали собираться просто потому, что в spec-файле был указан файл %_man1dir/something.1.gz, когда из-за сжатия получался файл %_man1dir/something.1.bz2 или %_man1dir/something.1.xz. 3) Та же проблема со сборкой не из релизного коммита и не указанием этого факта в релизе пакета. https://git.altlinux.org/people/kotopesutility/packages/?p=i3lock.git;a=summary 1) Оформление: работа со spec-файлом разбита на несколько коммитов без видимых причин. Последние два коммита с небольшими доработками вполне можно бы совместить с предыдущим коммитом. 2) Оформление: непонятно зачем все исходники были перенесены в директорию i3lock. Прошу прокомментировать зачем это было сделано. 3) Оформление: #BuildRequires: libxcb-devel, libxkbcommon-devel Закомментированное не нужно оставлять и стоит удалить. 4) %attr(2711, root, shadow) %_bindir/* Такие права явно не стоит выдавать всем приложениям по маске. Сегодня такое приложение одно, в следующем обновлении их станет два, и права такие будут у обоих. Лучше явно указать конкретное приложение: %_bindir/i3lock 5) Оформление: из .gear/rules: "copy: *.patch". Я в таких случаях предпочитаю использовать "copy?: *.patch" - если файлов *.patch больше не будет, то это не станет ошибкой и не потребуется менять .gear/rules. 6) Та же проблема что и в прошлых пакетах со сборкой не из релизного коммита и не указанием этого факта в релизе пакета. Помимо этого: 1) 3 новых пакета c простыми spec-файлами и 1 пакет с обновлением. Но в пакете с обновлением из изменений в спеке - новая версия и запись в changelog. Нередко для сборки новой версии пакета требуется больше действий, и по данным репозиториям не получается понять как с этим справится вступающий. Возможно, стоит дать какой-то нетривиальный пакет на обновление. 2) Все .gear/rules - без использования тэгов и ключевых слов (keywords из man-страницы gear-rules). Непонятно хорошо ли вступающий разобрался с gear-rules. С учётом всего вышенаписанного у меня есть сомнения в готовности кандидата хорошо собирать различные пакеты в репозиторий. 208706 16 kotopesutility 2022-03-21 19:51:50 +0300 Спасибо за ответ! >5) Оформление: из .gear/rules: "copy: *.patch". Я в таких случаях предпочитаю использовать "copy?: *.patch" - если файлов *.patch больше не будет, то это не станет ошибкой и не потребуется менять .gear/rules. Я оставил как есть, контролировать наличие или отсутствие *.patch я готов и, честно говоря, мне так удобнее. Остальные правки я внес, вот задание: https://git.altlinux.org/tasks/292489/ 208715 17 darktemplaralt 2022-03-22 00:09:27 +0300 slurp: 1) К сожалению не помню как было в прошлой версии. Было ли там только 2 указанных коммита? Сейчас там всё смешано в 1 коммит. Я бы предпочёл один коммит под импорт апстримных исходников, один - под спек-файл, gear-rules и прочее содержимое директории .gear. 2) %define commit_num .9.gf4e7559 %define slurp_num 1.3.2 Version: %slurp_num%commit_num Release: alt1 Информацию о коммите сборки помимо версии обычно записывают в релиз, наподобии подобного: Version: %slurp_num Release: alt1%commit_num grim: 1) Тоже самое про перенос информации о коммите в тэг Release. 2) Неправильная запись в changelog: * Wed Feb 09 2022 Daniel Zagaynov <email> - Initial build for Sisyphus. Отсутствует информация о версии. 3) Тэг, из которого собирается, указывает на предыдущий коммит, в котором создаётся спек-файл и всё прочее. В моём представлении такие тэги указывают в ситуации, когда берётся репозиторий из апстрима, на коммит сделанный апстримом. И в такой ситуации не потребуется делать два коммита, их можно будет объединить в один. Либо же сделать без указания на тэг в .gear/rules вообще. 4) В секции %files: %_man1dir/grim.1.xz Та же проблема, о которой я писал в прошлый раз: явно указан тип сжатия man-страниц. В случае очередной смены типа сжатия man-страниц данный пакет перестанет пересобираться. Этого можно избежать и заранее сделать лучше: "%_man1dir/grim.1*": вне зависимости от типа сжатия, такая строка должна работать верно всегда. i3lock: 1) Как и в других пакетах, теперь всё объединено в 1 коммит. Конечно, это не ошибка, но я бы предпочёл разбитие на отдельные части: отдельно то, что сделано/взято из апстрима, отдельно что сделано мэйнтейнером. 2) BuildRequires: gcc BuildRequires: autoconf_2.60 BuildRequires: m4 Насколько мне известно, gcc и m4 можно явно не писать, они устанавливаются во все сборочные окружения. А к autoconf_2.60 у меня есть вопрос: будет ли пакет собираться с версией autoconf по-умолчанию? Или, по другому, зачем здесь явно указана версия autoconf? Если этого можно не делать, лучше этого не делать. Тогда и autoconf явно можно не указывать. spread-sheet-widget: 1) Опять таки, предпочёл бы отдельный коммит с импортом новой версии и отдельный с патчем и изменением спека и т.д. pspp: 1) То же, что и в прошлом пакете. 2) https://git.altlinux.org/gears/p/pspp.git Пакет уже существовал в Сизифе, пусть он и удалён сейчас, и спек, судя по changelog-у, был взят оттуда. Почему не был взят весь репозиторий? Я считаю, что это лучше было бы оформить как обновление пакета, а не сборка с нуля, раз за основу берётся уже ранее существовавший пакет. 209666 18 kotopesutility 2022-04-18 21:50:31 +0300 (Ответ для Aleksei Nikiforov на комментарий #17) > Информацию о коммите сборки помимо версии обычно записывают в релиз, > наподобии подобного: > > Version: %slurp_num > Release: alt1%commit_num Да, я понимаю, что есть риск "странного" версионнирования со стороны upstream и тогда новая версия может стать меньше предыдущей, но, во-первых, не похоже, чтобы этот upstream так себя вел,а во-вторых, и это в самом крайнем случае, есть эпоха, которой, конечно, злоупотреблять нельзя. Остальные требования я вроде все выполнил. 209671 19 grenka 2022-04-19 03:21:39 +0300 (Ответ для kotopesutility на комментарий #18) > (Ответ для Aleksei Nikiforov на комментарий #17) > > Информацию о коммите сборки помимо версии обычно записывают в релиз, > > наподобии подобного: > > > > Version: %slurp_num > > Release: alt1%commit_num > Да, я понимаю, что есть риск "странного" версионнирования со стороны > upstream и тогда новая версия может стать меньше предыдущей, но, во-первых, > не похоже, чтобы этот upstream так себя вел,а во-вторых, и это в самом > крайнем случае, есть эпоха, которой, конечно, злоупотреблять нельзя. > > Остальные требования я вроде все выполнил. Я обычно использовал такой подход: Version: 4.6.3.0.16.git5ecb40bc https://git.altlinux.org/gears/p/python3-module-lxml.git?p=python3-module-lxml.git;a=commit;h=6bb5374190b199e38c30f6ad52962d1134aa1701 Сейчас до меня дошло, что он тоже неправильный, потому что не исключает полностью возможность поломки версионирования. Я теперь буду придерживаться совета darktemplar@ и вам советую того же. Хотя бы из соображений единобразия подходов к оформлению спекфайлов. 209706 20 glebfm 2022-04-19 13:47:12 +0300 (In reply to Grigory Ustinov from comment #19) > полностью возможность поломки версионирования. Никакой подход не исключает, но я всё равно считаю, что версия должна быть в поле Version:, а не в полe Release:. Нет никаких ограничений в том, какое количество нулей вы добавите к предыдущей версии. Напремер, в этом случае я бы сделал версию 1.3.2.0.9.<commit id>. Достаточно только убедить себя в том, что апстрим никогда не выпустит что-то типа 1.3.2.0.1, если неубедительно, то нужно добавить ещё один нолик. 209718 21 grenka 2022-04-19 15:50:54 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #20) > (In reply to Grigory Ustinov from comment #19) > > полностью возможность поломки версионирования. > > Никакой подход не исключает, но я всё равно считаю, что версия должна быть в > поле Version:, а не в полe Release:. Нет никаких ограничений в том, какое > количество нулей вы добавите к предыдущей версии. > Напремер, в этом случае я бы сделал версию 1.3.2.0.9.<commit id>. > Достаточно только убедить себя в том, что апстрим никогда не выпустит что-то > типа 1.3.2.0.1, если неубедительно, то нужно добавить ещё один нолик. Такой подход удобен в автоматизированных сборках из тэга, чтобы временно не ломать её, но зато repology мрачно грустнеет от таких версий. Чем плохо класть <commit id> в поле release? 209730 22 neurofreak-alt 2022-04-19 17:25:27 +0300 А не пора бы уже дать кандидату право коммитить в Сизиф? pspp уже заждался =) 210043 23 kotopesutility 2022-04-25 18:24:45 +0300 >Сейчас до меня дошло, что он тоже неправильный, потому что не исключает полностью возможность поломки версионирования. Я теперь буду придерживаться совета darktemplar@ и вам советую того же. Хотя бы из соображений единобразия подходов к оформлению спекфайлов. Ну, я так и сделал. Посмотрите, пожалуйста! Вот задание: https://git.altlinux.org/tasks/292489/ 210200 24 darktemplaralt 2022-04-27 22:32:09 +0300 (Ответ для kotopesutility на комментарий #18) > Остальные требования я вроде все выполнил. https://git.altlinux.org/people/kotopesutility/packages/?p=pspp.git;a=commitdiff;h=bc30ec7b4521d5e5fabc1e5d1970b6d549d2b4d4 --- a/.gear/rules +++ b/.gear/rules @@ -1 +1 @@ -tar.gz: pspp +tar.zst: pspp 1) Не уверен, может что-то уже и поменялось, но насколько мне известно сжатие исходников всё ещё излишне. Не критичный пункт. -License: GPLv3+ +License: GPLv3 2) Согласно сайту https://www.gnu.org/software/pspp/ лицензия всё ещё GPLv3+ (GPLv3-or-later): Freedom ensured; It is licensed under the GPLv3 or later. -Url: http://www.gnu.org/software/pspp/ +Url: http://gnu.mirror.constant.com/pspp/ 3) Я понимаю что Вы могли взять копию исходников с зеркала, но от этого домашняя страница проекта не меняется. 4) Вот это можно сократить, но это не обязательно: %_datadir/applications/org.fsf.pspp.desktop -> %_desktopdir/org.fsf.pspp.desktop https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=commitdiff;h=3aa1005d4e44d68f64f301f598fd98c206658cd0 1) Мне решительно не ясно зачем в этом merge commit ещё добавлены изменения в файлы .gear/rules и grim.spec, а также добавлены файлы в диретории .gear/tags. Ревьюить такое, мягко говоря, неудобно. Более того, мне непонятно зачем вообще здесь merge commit. Ничего не мешает создать ветку из коммита 1573b10, а затем одним коммитом (простым, не merge commit) добавить .gear/rules, .gear/tags/* и grim.spec. https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=blob;f=grim.spec;h=c60d87a64033c9a0370c16e7626f91a31c4da08e;hb=af5ce9d421dcef703a3a0dbf2065b78c46b83252 1) Я считаю, что лучше будет заменить %_man1dir/grim.1.* на %_man1dir/grim.1*. В случае, если сжатие man-страниц будет по какой-либо причине отключено, вторая запись в отличии от первой всё ещё будет работать. С учётом, что вероятность такого события мала, замечание не критично. Замечаний осталось не много, и я хочу верить что вступающий с ними справится без дополнительных пинков. В связи с этим думаю, что можно пропускать дальше. (Ответ для neurofreak-alt@yandex.ru на комментарий #22) > А не пора бы уже дать кандидату право коммитить в Сизиф? pspp уже заждался =) А для этого кандидату право коммитить не нужно, всегда может выдать approve любой другой член команды, в том числе его ментор. 210244 25 george 2022-04-28 15:55:01 +0300 (Ответ для Aleksei Nikiforov на комментарий #24) > Замечаний осталось не много, и я хочу верить что вступающий с ними справится > без дополнительных пинков. В связи с этим думаю, что можно пропускать дальше. Отлично! Благодарю за серьёзный подход к делу, надеюсь, кандидат принял к сведению). Я, по крайней мере, принял. В следующий раз сам кое-какие аспекты проверять буду, не дожидаясь рецензента. Ждём действий Секретаря. 210776 26 glebfm 2022-05-17 13:06:22 +0300 Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства! 9613 2021-08-19 22:24:34 +0300 2021-08-19 22:24:34 +0300 ssh and gpg public keys gpg.pub application/vnd.ms-publisher 3163 kotopesutility LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdFZWdqWUJFQUNnS1lV SnI4RkMxSXRDcnk1OE5MQkZsS1FHZ2I3MDllVzFOUkJTSi9raGltNXc1SVUyClZLNkJmOEpnK0Fz TUhaL1Q1QVd4TEh2U0QxU1gwN0g5T0RVVDJBNmU2QVhUS2s4OVA3eHkzSnNlWWFjM09XVDQKSi9G Ykd3dnl3VW5qNnYxT0xiNnMyeHNQaXorUURKRGdhd1FDdW5VcDliR2U1V2hiVkJUdS9uSUs4MFVp Q25TdQpkOWRpVVVrK21HcXJ2QUdjS1RuWUcwTkMySEtsajRkcHNqcGkwcWEydVJZYkVWVnJ4Uktt MThuUjYxaDZ5ZDdGCk5IZjFuTGJCekswdzd6cGp2Y2RzM0IydXZsWVdvSjVudGZvbEtQcTBITHF0 Rlo0SDZEd2VFc3VWdmQ1bjFZZmMKZHEzQUw3V2cxU0NKTUgzTitQWGlKakZBZVpkUFNjL3FNVU5i RnFoQXhsODg2RUZrUS9Fc3Brc3lZUHRFTWoxcQpOczhHWDJwZGJjS0c0cCtYLy9tN3lwMURyV1VZ SjE1ZzFNTzhleTNvRFJUcXU3MTlCYjY1RHVPNC9xZUlnUy95CllOK2VMSU8rTk13RW9nL3daeHA5 YzgzbWk3OTZLb01Rck1paVpCRitqVjFOYVFqaWcwQzNUVFcwUjh0eGczeDkKL1c3OGt4V2hxREI5 R0tjQWh0b212cjhvK3JzZjRDeDVPdlo4NUEvRi92S0VzTVl1eWhUcWhuczBZY0pvZ09TdgpTYlht cC9tdm83TGtKV1d2c25rMUxzN09kaWhiWmxvMElWM3ljQ3lkbDMzY29BaE1KUVFEQVNWTnpLSGw5 MUl3ClJxVU9kQm10TG9pbDY1dko4b0t3VFNNemlxS2cxRXNoZy95cHNyYnFlM2EyRnFVTXdxUlNM WUZVdHdBUkFRQUIKdEMxRVlXNXBaV3dnV21GbllYbHViM1lnUEd0dmRHOXdaWE4xZEdsc2FYUjVR R0ZzZEd4cGJuVjRMbTl5Wno2SgpBbFFFRXdFS0FENFdJUVRVRmFMUEdpVDFPYVF1dTEvdStBUkk5 a0Y2WUFVQ1lSNkNOZ0liQXdVSkJhT2FnQVVMCkNRZ0hBZ1lWQ2drSUN3SUVGZ0lEQVFJZUFRSVhn QUFLQ1JEdStBUkk5a0Y2WU1PNEVBQ0VzREZkSWZidHc0SUkKdy9Wb1JNZ0VUVy8zOC9KYnBxenpV SGdTNWlUekJYbmlTZGZpMDVrZlNOaldmZmFCck5rd0J6NnVycmhpdWd5eQpEZmRuOTRobi9CTVc5 RVR1VGxkUzVpMUNUb3YwM29rVWdOUTBnWVZWazFGZnRVZGdpM0R2SXQycVBFVFoyMEpmCnBEVFZ2 M2Z5U2ZzZDZJLytKbzZHK3hWSFpaZ252S3VlbTZqRG40QUdzOFlseWlaT1dSRjhqQkVLdG1qTDhU c2oKK1dJQ1E4MGN4Y1B5OEMzcWVtMWFKSW1PakJRTnBxRjNuSC9nZnU5ODlOOVJJcXpGZEJrV1Z6 ck5KUjBoZDdYUwplbzNtblNuNEE4cFRXK0t5UldtdlpWZ01XQjBzNStpRzJYSE5tQXRGVXdtOUhQ VHdBSTRDcVp1T0gvTU4wTzd3CkRFOUYyQTNtZ0hmeDE1VnhYT0xWYWFhVFl2VmVLdlBEWHBuekhp MStPcDZiKzlkS0REMDBxaE85Z0FZWCtiOXYKRi9tR3BReFJYUnZ6am1uV0EzNFN0Y0gwSFNHRFRp Y05lSVRyc3FaZUZWaG8vWFVHTmpQYlRCb0hOSzJrUkJubQpzWEkvbmxleHNOcDZyNDNzbDAzZ09S bTdvWUd4bEN4RnpoWG96eGJNNXo2ZE44bmF4bXdCQjExVXgxdHNPVmtzCjl3WVBvQm5FWEIrYk1L WU1sdHJBYnFVMjczU1I3MWJNSDBHUnRtcEJ2b2pJQlY4N1B1bGtXa3NBN1krc1B6UWcKam9BYi9F MUZpZjBNdGpsTnI0TnlHZkxvU1lIeGVkQWdlanJUVHd6UFhvTmk4VGRzMWVDVUZWTklRUEtFOTM4 RQp5UHZNL0paZzB2VDlXancraEEwRENMNDdXQUNBZzdrQ0RRUmhIb0kyQVJBQTFwK0VNeW5GQ1R0 TGdDMFFUSkhPClFmSUY2eklOcllsb25ZV3VjaWJ2TlEySDhVYXZVakZvWFRCZGVJc0FQbjErRXlT RGxJK2NTWm9PeGd6c3VvU3IKRk52elRVMTk5MEFqQ3BibExld3NKMUdDZURTdjhzT3hkeVNzOVlH b3Z6TVVLdDNwSFgvc3VYM1Z2WWpNQ0J6MAo4WWc1UzJ2N2RjdjhHdGV2ZzhNM3JnUjlid2h5SEp4 SzNGSElnUkxnNWhHV2ZodTUwbTlvZDVkcDdxRjQ4TDZlCm5ZejVNanVlZ3p5ZTNianRMYVVQanky a05jdUNQNGpHOGJDR1l6QlI4WXVlTDd2YmNvQ2J1M0VLUDJhbkxEaWYKMGVQemdyd2JrN3plNzVM bUdrL3NWQmdiNXVVWG5POHVrQ1FBaWdKSGdZTjZTcitwdFFVeG5pT2lEOVM1bTdXUwpVbHpJNjRT SnNmMnNjR1BFNTBpZjBPUHFVMnprc1lHZVE1Wkk0MVV2ZFYzbG9JL281K3pBQSszTEJqUWxRVS9W ClB4YngyYlB5ZUFFcFRLOWNuMDM4K1c4eE0xNTMrNldZaUtxelpCNHcrazZRcjhwSFg4N2dtYlc2 VmdEUWhjUFEKUFRpNVRkMGlodmd5ckwyYXVhaENaWHVBem4yQkFlTldIUTRxbWlwWmpqamRPN2tO ZUVWeU0rQytNMFcrTjVXRwoxaldwTjlzdEhIWlQ2YVlYL1ZWYmJ5TXVCQzdDSEp2bWUzTWpmR3lz NzQ0WG1VbEdIOEhuMkdyUWs3djhZVGpzCmI3YVgyQ21CWm1XNEUxYzJDQWpoUUdzMzNGM3FwNkhP MDNwTi82QTdoYk51c3l4cmRsbFBWSm54dXhrRTJVRUUKdmFUaXA5aWYwVjRXSXVDY0FvRjlwT0VB RVFFQUFZa0NQQVFZQVFvQUpoWWhCTlFWb3M4YUpQVTVwQzY3WCs3NApCRWoyUVhwZ0JRSmhIb0ky QWhzTUJRa0ZvNXFBQUFvSkVPNzRCRWoyUVhwZ0lGY1FBSXY5aCtvb0VicnQxSUtlCmZoTnFMREV6 S0MyTks4TE1IditwOCt3Y1NvYjlzOG91NHlralR0R09WWkFnd2ZJWU84SGJaZDdVVXFKOTBsNXAK VWVIb0hEOEhYZjFiQ2JPVGRBOUY2K1BRa1NoQlltRzgwU2RWd1d3akZQZHlqL3Bpbm9sbnVPelBD VkNDQzFBaApsYUZsWEs2eHh4TXJiOVlLM0dJRWxXWjZEaVZBN0cwdFdmOXk1RnVqNUp5aklxL0g5 Vy83c05iWXpOcmNUYW9PCnJqQnZhamxlZ2ZtVVlGU2ZPaFp5WWRCNU5mYnB4eGpibWJYcDNsTWQ2 ZENiZzFBbkJiOVVSRy94dGQ4b2NjaGwKWmQ0cDRwU1NnU2NGU1h1c3hrWnR3eTcvbjM0cjFYcXhN YjU5Ni9rc0lvZ3dxTDJDdFArd2xtNmxobjlnSW5JNwp0UXZRYlhOUFk3RDdSbVhRMlVDeHRPTXZl aTNlWVpYaWZWZUtRemJLTlRqTUpEYWUvcEpUNy9FUWFMdzk4M05BCmpBcktxVk92djc3QWZocW5N Zm1zc2NuUm9sSWNmQWMxRE0xRlVUTVF2TzJ3SXNTQm0yTkFQaDJEdStKVkpoTXcKSUxzTWlQbUlZ bnhjOVdYQmJINE1qN1hLbTZ0ZjRFblBxeTEyako3ZWVSSDZWQm5GTXRzelRaNWgxMnRhREluWQpT UitrdFZ1RThJcDhjV0tIdkJhblZVdkkzVmN5K05xbHJJYmFiMVd6eDVzZGpQL2xqVVpHZlhUWkw3 S1pjb3VrCmhjVm1CYVRwYWxsVVh3aGpZcU05N0ltSEVqUUNXSG1DckplaVNzR1lCbVprUVRLVWNv Sm5HNXY5WFlLRVJYNVoKblUxZGU0clpnVXhra2QyN3FKQ1ZJMEdjUHBTcAo9amw1RAotLS0tLUVO RCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCg== 9614 2021-08-19 22:28:58 +0300 2021-08-19 22:28:58 +0300 SSH-key id_rsa.pub application/vnd.ms-publisher 403 kotopesutility c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFDNUxBekx2ek4vTXVqTzBpZ1hD VGxMbFFsRmJFYnB4MGJmNEdKTkFGTXBveFhod0tDdU84SGRMK0hHRHpkaVlVK1JFZWNjVzhqS1ky a3Q5YThHTGJVV09yZ3hiL1FLYjl5RjJENktUWS9WM0VYeVh3d0V5czQ2ZjNFUEEvMmRuN0hMVXY2 VGpjRklpcnBPTWo4VUl5ZG10S3QrTWFiMHVrbDVOb2F6RTBjbFFoVW9kaDdWMS8vWXpLT0l2S0VQ YU1zbjVvZ0QrQU9UY1kyS3hxOHZDK2lXKzBLdFJ5NVRKbFY4VjV6UEpaNWZacm5ZdG9Ed0tPcWla ejFCSUsyMGVCZGVubnJDZWs3dU1ZWldIemdqRmFEdnIvZkVrTE1tekY5Nmp6bWlvRkdZYUowL3pt YmM2VEZHYnhTZ1V5Ymd6SzJaYkJ1MlNXZlJ4T0J5Sy8vZFhTUkogcHNpbmFzdXR1bGF5YUBwaXRi dWxsCg== 9622 2021-08-25 01:20:32 +0300 2021-08-25 01:20:32 +0300 SSH-key alt_rsa.pub text/plain 759 kotopesutility c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFDQVFEYUwwY3NleEtJYUM2UktsQThJ eFBLcit5Unp5aXdQV3B4STg4bmV2cC9UN1U1WFZOVXg3aEdDSko4Y1R1V3hyUzY3WFdydDZvUFQr L0k1VWxXMTZ1MVIrb05xWW1ZVkRMdGZic2NxYXRwQzJsT0t6NFdQQ2JFc3FrRjJYMmRMaUJ2NVVY alFGVUwzMG9uUHBWZm14VTFwYlFHcTZreTNoQ3E4ZWpHdzRTTGVROEhzcEtrcGZtN2lkejhYSTNl bzJHS211LzJqZnVycXZ6cUl2eCszRjQxMTdOVGlsVW9iemtDQmN4Z1FKNDZsV0hiWm5wV2NOaG1I L0ZnMVBMTGlSSnBCZnJQSVVMR3QyTEZFUWRnYnJmRjFrOFJ5SVNRTTZsbXFRQlRPMnhPZmZrWnFw My9UeUZGeEwraUxmUVREb2FCKzdPRlpZQ2U1dVB2UU1tMGpSVFFWbXJ3WUJmeXhhd3A0VGdRaXZs N09PcWtpbFEvQ2lUL1lVL2VZU01OYmxIQWxaUW52dWpLVnBZbm9ySHh5bEVoc3VhU2d1ejIrNmVK Kzc4TWIxbzhoMkxxMzdVN0Q2RFZMN3V2MEtSNE9rUXIxSmxKTXlSRGkwbnJyMVhLbVgrditsWTNY Z1JUUWJqcm1wK2E2Mm1xVTRJM1NMZTkzaUVXZU85MnFHQ3hqdU0rSTBhdFk2RnptNVdNSzYvbTBF aWwyL0tzZ1NGb1pNbDdpL2ZVb3FoWTZvcTNDeEU3Y2EyODFoeUo3aXFBMnN0K0VxRXpuT0tPM21Q NTUxcThON0RmRmVFTmRqeUNYem5QTmdFZXlQVWdNWDZaMXp2Rit5VVk4VGtZWUNFa1dGQ202QXFu VCtWWXNMT0hTbGx1UHdtckorUWgzUTJFWXVESGc5TU04VmV3d3c9PSBrb3RvcGVzdXRpbGl0eUBi b3VsZWRvZ3VlZnJhbmNhaXMK