38797 2020-08-11 13:03:38 +0300 [done] join khab@ 2021-09-02 18:54:04 +0300 1 1 4 Development Team Accounts join unspecified x86_64 Linux CLOSED FIXED https://www.altlinux.org/Team/Join/Secretary P5 normal --- 1 anna.khrustova glebfm aen andy cas darktemplar darktemplaralt glebfm grenka klark ldv mike cas oldest_to_newest 191834 0 8903 anna.khrustova 2020-08-11 13:03:38 +0300 Created attachment 8903 ssh pubkey Псевдоним: Khab Email: anna.khrustova@gmail.com Ментор: cas@ , klark@ Цель: Научиться собирать пакеты. 191835 1 8904 anna.khrustova 2020-08-11 13:08:19 +0300 Created attachment 8904 gpg pubkey 191846 2 cas 2020-08-12 11:55:45 +0300 Подтверждаю менторство. 191850 3 klark 2020-08-12 13:15:48 +0300 Подтверждаю. 191854 4 glebfm 2020-08-12 14:34:54 +0300 (Ответ для Anna на комментарий #0) > Создано вложение 8903 [подробности] > ssh pubkey Ok. (Ответ для Anna на комментарий #1) > Создано вложение 8904 [подробности] > gpg pubkey Ok. 191862 5 glebfm 2020-08-12 15:21:18 +0300 ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 3.0. 192358 6 klark 2020-09-10 13:48:23 +0300 Кандидат готов к сборке. Можем переходить на следующий этап. 192468 7 cas 2020-09-14 16:30:31 +0300 Подтверждаю, что кандидат готов к переходу на следующий этап. 192968 8 klark 2020-10-02 14:11:34 +0300 Глеб, ping! Можешь дать Анне права на build.alt? 194069 9 glebfm 2020-11-10 20:58:14 +0300 Пакет alt-gpgkeys обновлён. T/J/S -> 4.0. 194114 10 cas 2020-11-11 22:36:10 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #9) > Пакет alt-gpgkeys обновлён. > > T/J/S -> 4.0. Кандидат показал, что справился со сборкой. Прошу перейти на следующий этап. 194207 11 ldv 2020-11-14 03:19:01 +0300 (In reply to Andrey Cherepanov from comment #10) > (Ответ для Gleb F-Malinovskiy на комментарий #9) > > Пакет alt-gpgkeys обновлён. > > > > T/J/S -> 4.0. > > Кандидат показал, что справился со сборкой. Прошу перейти на следующий этап. Справился со сборкой - это хорошо. Но в пакете нет ни одного патча, хотя напрашивается. Например, в bpytop.spec написано: %py3_requires psutil В то же время в bpytop.py написано: try: import fcntl, termios, tty, pwd except Exception as e: errors.append(f'{e}') try: import psutil # type: ignore except Exception as e: errors.append(f'{e}') Логично же заменить этот try на обычный import и убрать %py3_requires? Заодно можно будет попрактиковаться в упаковывании патчей. 194210 12 klark 2020-11-14 06:08:04 +0300 Дима, к собранному пакету у нас есть и другие замечания, мы никуда не торопимся. Анна постепенно совершенствует технику, а данный пакет никто без одобрения не пропустит. Переход на текущий этап дал нам возможность, наконец, работать с кандидатом удалённо, видеть результаты. Но реакция была больше месяца. Так что, возможно, нынешний запрос сделан чуточку заранее, но с учётом занятости Глеба. 194531 13 glebfm 2020-11-30 13:54:18 +0300 (Ответ для Andrey Cherepanov на комментарий #10) > Кандидат показал, что справился со сборкой. Прошу перейти на следующий этап. Мне кажется, что одного маленького пакета мало чтобы в этом убедиться. (Ответ для Leonid Krivoshein на комментарий #12) > возможно, нынешний запрос сделан чуточку заранее, но Если это верно, то пожалуйста больше не делайте так. 194618 14 anna.khrustova 2020-12-04 16:53:25 +0300 > Справился со сборкой - это хорошо. > Но в пакете нет ни одного патча, хотя напрашивается. > > Например, в bpytop.spec написано: > %py3_requires psutil > > В то же время в bpytop.py написано: > try: import fcntl, termios, tty, pwd > except Exception as e: errors.append(f'{e}') > try: import psutil # type: ignore > except Exception as e: errors.append(f'{e}') > > Логично же заменить этот try на обычный import и убрать %py3_requires? > > Заодно можно будет попрактиковаться в упаковывании патчей. Сделала патч - task #262703 >(Ответ для Gleb F-Malinovskiy на комментарий #13) > Мне кажется, что одного маленького пакета мало чтобы в этом убедиться. Планирую взяться за второй пакет. 194654 15 ldv 2020-12-06 06:09:01 +0300 (In reply to Anna from comment #14) > > Справился со сборкой - это хорошо. > > Но в пакете нет ни одного патча, хотя напрашивается. > > > > Например, в bpytop.spec написано: > > %py3_requires psutil > > > > В то же время в bpytop.py написано: > > try: import fcntl, termios, tty, pwd > > except Exception as e: errors.append(f'{e}') > > try: import psutil # type: ignore > > except Exception as e: errors.append(f'{e}') > > > > Логично же заменить этот try на обычный import и убрать %py3_requires? > > > > Заодно можно будет попрактиковаться в упаковывании патчей. > > Сделала патч - task #262703 Спасибо. Мне кажется, что строчка BuildRequires: python3-devel в этом спек-файле лишняя, как вы думаете? Да и строчку BuildRequires(pre): rpm-build-python3 в этом спек-файле, если я не ошибаюсь, можно было бы упростить до BuildPreReq: pm-build-python3 194701 16 mike 2020-12-07 14:35:26 +0300 (Ответ для Dmitry V. Levin на комментарий #15) > Да и строчку > BuildRequires(pre): rpm-build-python3 > в этом спек-файле, если я не ошибаюсь, можно было бы упростить до > BuildPreReq: pm-build-python3 Интересно, вралась ли бы сюда опечатка без "если я не ошибаюсь"... :) 194702 17 ldv 2020-12-07 14:37:59 +0300 (In reply to Dmitry V. Levin from comment #15) > BuildPreReq: pm-build-python3 Кто-то съел букву, имелось в виду BuildPreReq: rpm-build-python3 194703 18 ldv 2020-12-07 14:39:01 +0300 (In reply to Michael Shigorin from comment #16) > Интересно, вралась ли бы Сложно сказать! :) 194705 19 glebfm 2020-12-07 15:19:14 +0300 (Ответ для Dmitry V. Levin на комментарий #15) > BuildRequires(pre): rpm-build-python3 Вот это моё влияние. Я считаю, что spec должен вычисляться без ошибок сразу после установки пакетов из (pre), но со мной, кажется, не все согласны. :) 194706 20 glebfm 2020-12-07 15:28:23 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #19) > (Ответ для Dmitry V. Levin на комментарий #15) > > BuildRequires(pre): rpm-build-python3 > > Вот это моё влияние. Я считаю, что spec должен вычисляться без ошибок сразу > после установки пакетов из (pre), но со мной, кажется, не все согласны. :) А, но на данный момент макросы для вычисления spec-файла вообще не нужны, т.е. можно зависимость только на python3-devel оставить. 194707 21 ldv 2020-12-07 15:39:47 +0300 (In reply to Gleb F-Malinovskiy from comment #20) > (Ответ для Gleb F-Malinovskiy на комментарий #19) > > (Ответ для Dmitry V. Levin на комментарий #15) > > > BuildRequires(pre): rpm-build-python3 > > > > Вот это моё влияние. Я считаю, что spec должен вычисляться без ошибок сразу > > после установки пакетов из (pre), но со мной, кажется, не все согласны. :) > > А, но на данный момент макросы для вычисления spec-файла вообще не нужны, > т.е. можно зависимость только на python3-devel оставить. А почему python3-devel, а не rpm-build-python3, в пакете же просто скрипт на python3? 194710 22 glebfm 2020-12-07 15:44:44 +0300 (Ответ для Dmitry V. Levin на комментарий #21) > (In reply to Gleb F-Malinovskiy from comment #20) > > т.е. можно зависимость только на python3-devel оставить. > > А почему python3-devel, а не rpm-build-python3, в пакете же просто скрипт на > python3? Да, наверное так понятнее будет, согласен. 194739 23 grenka 2020-12-08 16:41:03 +0300 (Ответ для Dmitry V. Levin на комментарий #15) > Да и строчку > BuildRequires(pre): rpm-build-python3 > в этом спек-файле, если я не ошибаюсь, можно было бы упростить до > BuildPreReq: rpm-build-python3 Разве BuildPreReq у нас не считается "дурным тоном"? Я всегда старался писать BuildRequires(pre) и даже менял в некоторых пакетах BuildPreReq на BuildRequires(pre). 194740 24 ldv 2020-12-08 16:47:30 +0300 (In reply to Grigory Ustinov from comment #23) > (Ответ для Dmitry V. Levin на комментарий #15) > > Да и строчку > > BuildRequires(pre): rpm-build-python3 > > в этом спек-файле, если я не ошибаюсь, можно было бы упростить до > > BuildPreReq: rpm-build-python3 > > Разве BuildPreReq у нас не считается "дурным тоном"? Нет, BuildPreReq - это фактически синоним BuildRequires, некоторые используют BuildPreReq для того, чтобы ещё сильнее отличать зависимости, указанные вручную, от зависимостей, которые вычислил buildreq. > Я всегда старался > писать BuildRequires(pre) и даже менял в некоторых пакетах BuildPreReq на > BuildRequires(pre). У BuildRequires(pre) всё-таки немного другой смысл. 194742 25 grenka 2020-12-08 17:02:26 +0300 (Ответ для Dmitry V. Levin на комментарий #24) > Нет, BuildPreReq - это фактически синоним BuildRequires, некоторые > используют BuildPreReq для того, чтобы ещё сильнее отличать зависимости, > указанные вручную, от зависимостей, которые вычислил buildreq. Перед автоматически вычисленными зависимостями _некоторые_ используют комментарий, который недвусмысленно даёт понять, как они были получены. Так что я не вижу в этом синониме иного смысла, как запутать и без того запутанных мейнтейнеров=) Я скорее согласен с Глебом и если вижу rpm-build-* или rpm-macros-* то ставлю их в BuildRequires(pre): 194749 26 anna.khrustova 2020-12-08 20:12:45 +0300 (Ответ для Dmitry V. Levin на комментарий #15) > BuildRequires(pre): rpm-build-python3 > в этом спек-файле, если я не ошибаюсь, можно было бы упростить до > BuildPreReq: pm-build-python3 Такой хороший вопрос :) Если я правильно поняла, то BuildRequires(pre) следует использовать для тех пакетов, которые будут установлены в cборочную среду до того как hasher начинает сборку пакета с помощью rpm-build. Т.е. если бы у меня был прежний макрос %python3_build, то было бы правильно, но так как патч уже сделан, то дальше rpm-build-python3 можно перенести в BuildRequires. Переделала task #263031 194750 27 klark 2020-12-08 21:00:00 +0300 (In reply to Dmitry V. Levin from comment #11) > Логично же заменить этот try на обычный import и убрать %py3_requires? Как в Дебиане, но не как в Федоре... как дилетант в этом вопросе я бы выбрал второй вариант, чтобы не таскать патч, не проходимый в апстрим. Конечно, можно переложить интелект разруливания зависимостей на нашу сборочницу, но стоит ли так делать для такого небольшого скрипта, если сам питон справляется с задачей успешно? > Заодно можно будет попрактиковаться в упаковывании патчей. Разве что полезно попрактиковаться, это да. :-) 194752 28 ldv 2020-12-08 21:37:53 +0300 (In reply to Leonid Krivoshein from comment #27) > (In reply to Dmitry V. Levin from comment #11) > > Логично же заменить этот try на обычный import и убрать %py3_requires? > Как в Дебиане, но не как в Федоре... как дилетант в этом вопросе я бы выбрал > второй вариант, чтобы не таскать патч, не проходимый в апстрим. Конечно, > можно переложить интелект разруливания зависимостей на нашу сборочницу, но > стоит ли так делать для такого небольшого скрипта, если сам питон > справляется с задачей успешно? Так точно стоит делать, чтобы не отслеживать зависимости вручную. Апстрим имеет право на свою апстримную экстравагантность, конечно, но обычно скрипты на питоне так не делают. > > Заодно можно будет попрактиковаться в упаковывании патчей. > Разве что полезно попрактиковаться, это да. :-) Полезно во всех отношениях, на мой вгляд. :) 195059 29 klark 2020-12-18 15:08:01 +0300 (In reply to Anna from comment #26) > Переделала task #263031 У меня замечаний нет. Если Андрей заапрувит, надо перезапустить таск на сборку и на следующих итерациях ждём самостоятельно собранного пакета "с нуля" и одного исправления в Сизифе. Хотя, на мой взгляд, пользоваться инструментарием Вы уже научились, а опыт сборки приходит с годами. 195081 30 cas 2020-12-21 15:10:17 +0300 (Ответ для Leonid Krivoshein на комментарий #29) > (In reply to Anna from comment #26) > > Переделала task #263031 > > У меня замечаний нет. Если Андрей заапрувит, надо перезапустить таск на > сборку и на следующих итерациях ждём самостоятельно собранного пакета "с > нуля" и одного исправления в Сизифе. Хотя, на мой взгляд, пользоваться > инструментарием Вы уже научились, а опыт сборки приходит с годами. Посмотрел, одобрил. Но из-за test_only=yes запускать надо самой Анне. 195289 31 klark 2021-01-07 01:44:34 +0300 (In reply to Andrey Cherepanov from comment #30) > Посмотрел, одобрил. Анна собрала ещё один пакет в #264340 -- у меня замечаний нет. Он может быть полезен нашим ядерщикам и партнёрам типа Касперского/DrWeb. 195290 32 andy 2021-01-07 03:24:37 +0300 (Ответ для Leonid Krivoshein на комментарий #31) > (In reply to Andrey Cherepanov from comment #30) > > Посмотрел, одобрил. > Анна собрала ещё один пакет в #264340 -- у меня замечаний нет. Он может быть > полезен нашим ядерщикам и партнёрам типа Касперского/DrWeb. А нужен ли BuildRequires: gcc ? gcc разве не всегда устанавливается? 195293 33 anna.khrustova 2021-01-07 12:57:18 +0300 (Ответ для Andrew Vasilyev на комментарий #32) > (Ответ для Leonid Krivoshein на комментарий #31) > > (In reply to Andrey Cherepanov from comment #30) > > > Посмотрел, одобрил. > > Анна собрала ещё один пакет в #264340 -- у меня замечаний нет. Он может быть > > полезен нашим ядерщикам и партнёрам типа Касперского/DrWeb. > > А нужен ли > BuildRequires: gcc > ? > gcc разве не всегда устанавливается? Спасибо, изменила. 195304 34 klark 2021-01-07 15:22:47 +0300 (In reply to Andrew Vasilyev from comment #32) > А нужен ли BuildRequires: gcc? Сборочная зависимость (gcc) у программы есть, так что её прямое указание в спеке полиси не нарушает и ошибкой не является. > gcc разве не всегда устанавливается? Полагаю, вместе с зависимостями rpm-build, т.е. можно это считать текущими особенностями сборочницы. Можно ли полагаться на эту особенность в дальнейшем? 195628 35 klark 2021-01-22 02:23:55 +0300 Есть ли у коллег замечания к task #264340? Есть ли комментарии у основного и добавленного менторов? На мой взгляд Анна показала готовность использовать наш инструментарий. В ближайшее время на сборку должны отправиться ещё несколько пакетов по линии совместимости. 195875 36 anna.khrustova 2021-01-29 19:07:49 +0300 Ещё собрала пакет kesl10-preinstall task #265441 Обновила librtpkcs11ecp task #265108 Планирую дальше собирать пакеты для списка-0 195877 37 klark 2021-01-30 00:56:56 +0300 (In reply to Anna from comment #36) > Ещё собрала пакет kesl10-preinstall task #265441 > Обновила librtpkcs11ecp task #265108 Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9. 196025 38 anna.khrustova 2021-02-04 22:05:24 +0300 > Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9. Отправила. Что от меня ещё требуется для join? 196026 39 ldv 2021-02-04 22:22:28 +0300 (In reply to Anna from comment #38) > > Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9. > > Отправила. > Что от меня ещё требуется для join? Убедить всех менторов в том, что ваши сборки больше не нуждаются в ревью. Я думаю, что спешить не стоит - чем больше вы практикуетесь, тем больше у вас опыта. 196028 40 cas 2021-02-04 23:15:32 +0300 (Ответ для Dmitry V. Levin на комментарий #39) > (In reply to Anna from comment #38) > > > Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9. > > > > Отправила. > > Что от меня ещё требуется для join? > > Убедить всех менторов в том, что ваши сборки больше не нуждаются в ревью. > Я думаю, что спешить не стоит - чем больше вы практикуетесь, тем больше у > вас опыта. Меня лично Анна убедила, что может собирать пакеты. А совершенствоваться можно и параллельно сборке пакетов с одобренной учётной записи. Можно, конечно, и одобрять все задания, но какой в этом будет смысл. Зачем затягивать? 196029 41 ldv 2021-02-04 23:34:06 +0300 (In reply to Andrey Cherepanov from comment #40) > (Ответ для Dmitry V. Levin на комментарий #39) > > (In reply to Anna from comment #38) > > > > Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9. > > > > > > Отправила. > > > Что от меня ещё требуется для join? > > > > Убедить всех менторов в том, что ваши сборки больше не нуждаются в ревью. > > Я думаю, что спешить не стоит - чем больше вы практикуетесь, тем больше у > > вас опыта. > > Меня лично Анна убедила, что может собирать пакеты. Вопрос в том, может ли она это делать полностью самостоятельно. > А совершенствоваться > можно и параллельно сборке пакетов с одобренной учётной записи. Можно, > конечно, и одобрять все задания, но какой в этом будет смысл. Зачем > затягивать? Кто одобряет задания, тот и отвечает за последствия. Несправедливо было бы возлагать ответственность на человека, не убедившись в том, что он может её нести в полном объёме. 196031 42 klark 2021-02-05 02:48:00 +0300 (In reply to Dmitry V. Levin from comment #41) > Вопрос в том, может ли она это делать полностью самостоятельно. Анна убедила, что может и вообще-то должна. Хотя спрашивать совета коллег на хитрых задачках вполне нормально, как мне кажется. Дело в том, что её "рабочая задача" не просто: (In reply to Anna from comment #0) > Цель: Научиться собирать пакеты. а, на самом деле, собирать вполне определённые пакеты, так что здесь нужды проходить все тонкости просвещения нет. То, что требуется для работы, Анна уже знает и умеет, подтвердила это неоднократно. Теперь для работы необходимость апрува ментора при нашей загрузке создаёт лишь дополнительные сложности. Давайте сделаем так: Анна самостоятельно внесёт улучшения в свой последний пакет и полностью с нуля сделает ещё один похожий пакет. Будет ли этого достаточно для джойна? 196032 43 ldv 2021-02-05 03:58:37 +0300 (In reply to Leonid Krivoshein from comment #42) > Давайте сделаем так: Анна самостоятельно внесёт улучшения в свой последний > пакет и полностью с нуля сделает ещё один похожий пакет. Давайте. > Будет ли этого достаточно для джойна? Посмотрим. :) 197223 44 anna.khrustova 2021-03-24 22:53:07 +0300 Доброй ночи! Добавила улучшение в пакет kesl10-preinstall task #268312 197224 45 klark 2021-03-24 23:02:35 +0300 (In reply to Anna from comment #44) > Добавила улучшение в пакет kesl10-preinstall task #268312 Я бы одобрил. Ждём остальных... 197535 46 anna.khrustova 2021-04-05 21:14:33 +0300 Собрала еще пару пакетов: vipnetcsp4-preinstall task #268849 fsprot-control task #268850 drweb11-preinstall task #268850 197540 47 klark 2021-04-06 00:23:36 +0300 (In reply to Anna from comment #46) > vipnetcsp4-preinstall task #268849 > fsprot-control task #268850 > drweb11-preinstall task #268850 К этим сборкам у меня замечаний нет, можно пропускать. Соберите хотя бы ещё парочку таких же полностью без замечаний. 197556 48 andy 2021-04-06 15:15:50 +0300 (Ответ для Anna на комментарий #46) > Собрала еще пару пакетов: > drweb11-preinstall task #268850 К самой процедуре сборки отношения не имеет, но: "This is needded for" -> needed или necessary (аналогично в kesl10-preinstall). "Don't forget remove" -> "to remove" "Don't forget disable" -> "to disable" 197568 49 anna.khrustova 2021-04-06 18:01:19 +0300 (Ответ для Andrew Vasilyev на комментарий #48) > (Ответ для Anna на комментарий #46) > > Собрала еще пару пакетов: > > drweb11-preinstall task #268850 > > К самой процедуре сборки отношения не имеет, но: > > "This is needded for" -> needed или necessary > (аналогично в kesl10-preinstall). > > "Don't forget remove" -> "to remove" > "Don't forget disable" -> "to disable" Андрей, спасибо большое. Обязательно исправлю, если больше замечаний не будет. 197892 50 anna.khrustova 2021-04-13 19:27:35 +0300 Исправила замечания по прошлым пакетам. Обновила пакет librtpkcs11ecp до новой версии 2.1.1.0. librtpkcs11ecp #269872 vipnetcsp4-preinstall #269293 kesl10-preinstall #269256 fsprot-control #268850 drweb11-preinstall #268850 197895 51 klark 2021-04-14 01:28:07 +0300 (In reply to Anna from comment #50) > Исправила замечания по прошлым пакетам. > Обновила пакет librtpkcs11ecp до новой версии 2.1.1.0. > librtpkcs11ecp #269872 > vipnetcsp4-preinstall #269293 > fsprot-control #268850 Вот это безупречно, я бы заапрувил сходу, если нет других возражений. > kesl10-preinstall #269256 > drweb11-preinstall #268850 Здесь тоже всё неплохо, но над тестом %description можно было бы и получше поработать (на мой взгляд). В крайнем случае можно подправить в следующих сборках. 201408 52 klark 2021-08-10 18:22:44 +0300 Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и самостоятельности. 201424 53 ldv 2021-08-11 15:43:22 +0300 (In reply to Leonid Krivoshein from comment #52) > Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и > самостоятельности. Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата". Кто у нас ментор? :) 201425 54 cas 2021-08-11 15:45:57 +0300 (Ответ для Dmitry V. Levin на комментарий #53) > (In reply to Leonid Krivoshein from comment #52) > > Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и > > самостоятельности. > > Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата". > Кто у нас ментор? :) Прошу перечитать https://bugzilla.altlinux.org/show_bug.cgi?id=38797#c7 Или нужно каждое действие повторно подтверждать? Укажите место в регламенте, где это написано. 201426 55 ldv 2021-08-11 15:49:14 +0300 (In reply to Andrey Cherepanov from comment #54) > (Ответ для Dmitry V. Levin на комментарий #53) > > (In reply to Leonid Krivoshein from comment #52) > > > Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и > > > самостоятельности. > > > > Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата". > > Кто у нас ментор? :) > > Прошу перечитать https://bugzilla.altlinux.org/show_bug.cgi?id=38797#c7 > Или нужно каждое действие повторно подтверждать? Укажите место в регламенте, > где это написано. Со времён того подтверждения регламент успел поменяться, так что для перехода на следующую стадию нужно подтвердить. 201428 56 cas 2021-08-11 16:10:07 +0300 (Ответ для Dmitry V. Levin на комментарий #55) > (In reply to Andrey Cherepanov from comment #54) > > (Ответ для Dmitry V. Levin на комментарий #53) > > > (In reply to Leonid Krivoshein from comment #52) > > > > Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и > > > > самостоятельности. > > > > > > Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата". > > > Кто у нас ментор? :) > > > > Прошу перечитать https://bugzilla.altlinux.org/show_bug.cgi?id=38797#c7 > > Или нужно каждое действие повторно подтверждать? Укажите место в регламенте, > > где это написано. > > Со времён того подтверждения регламент успел поменяться, так что для > перехода на следующую стадию нужно подтвердить. Как смотревший эти пакеты подтверждаю, что кандидат готов собирать пакеты. Прошу перейти на следующую стадию. 201437 57 klark 2021-08-11 18:27:47 +0300 (In reply to Dmitry V. Levin from comment #53) > Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата". > Кто у нас ментор? :) Дима, я уже давно в комментарии 42 высказал мнение как бывший ментор. И моя позиция не изменится, сколько бы изменений в регламент не вносилось. Я смотрел каждый последующий пакет и твёрдо убеждён, что Анна научилась собирать пакеты, которые требовалось. Принимающая сторона в комментарии 43 хотела что-то ещё посмотреть. Не знаю, зачем затягивать процесс и почему не дать финальную оценку о готовности либо неготовности кандидата. У нас ещё есть немного времени, чтобы этот баг не ляг очередным пятном на наш джойн. Призываю дать оценку на своё усмотрение, положительную ли, отрицательную, но не динамить с этим. Или сказать, что ещё не сделано или сделано не так. 201480 58 ldv 2021-08-13 11:41:25 +0300 Попробую позвать ещё одного человека (darktemplar@) для независимой оценки готовности кандидата. 201515 59 darktemplaralt 2021-08-13 17:11:59 +0300 Рекомендации: http://git.altlinux.org/people/khab/packages/?p=bpytop.git;a=commitdiff;h=32c1dcf4084eb73fb6c6f85270c2733e04dcb991 1) copy: *.patch Думаю, лучше будет написать "copy?: *.patch" - в таком случае если патчи будут не нужны, их можно будет удалить без изменения файла .gear/rules. 2) Рекомендую при сборке пакетов выставлять: %define _unpackaged_files_terminate_build 1 Обычно это выставляется где-нибудь в начале спека. Полезно тем, что при сборке или обновлении пакета, если появятся новые файлы, их не получится не заметить, что вынудит решить что с ними делать - тоже упаковывать, явно удалять или что-либо ещё. По крайней мере это может быть полезно для пакетов, содержащих файлы. 3) Packager: Anna Khrustova <khab@altlinux.org> Насколько мне известно, данное поле заполняется автоматически при сборке пакета на основе информации о последнем собирающем. Выставлять его явно я необходимости не вижу. 4) %makeinstall_std PREFIX=/usr Вместо /usr скорее всего стоит использовать макрос %_prefix. На следующей странице содержится большое количество макросов с их значениями: https://www.altlinux.org/Spec/Предопределенные_макросы Но данный список не является полным. http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4 5) Не сразу очевидно почему указана данная лицензия, поскольку не взят коммит из апстрима, добавляющий лицензию, а в исходниках она не указана. Хорошо бы взять соответствующий коммит из апстрима. Вопросы: http://git.altlinux.org/people/khab/packages/?p=drweb11-preinstall.git;a=commitdiff;h=8bd720a7d0fdf89b7cc515700611fc77cde92353 1) Где и при каких условиях создаётся или удаляется файл /_NEW_SYSTEM_ ? http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не удалось найти указание версии в апстриме. К имеющимся пакетам претензий нет. Есть только пара вопросов и несколько небольших рекомендаций. К сожалению, все собранные пакеты - простые, либо не содержат сборки, либо эта сборка простая. Вот два самых сложных пакета для сборки: http://git.altlinux.org/people/khab/packages/?p=bpytop.git;a=commitdiff;h=32c1dcf4084eb73fb6c6f85270c2733e04dcb991 http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4 Пакеты *-preinstall по сборке ещё проще двух указанных выше пакетов. Там сборка отсутствует. Только по таким простым пакетам сложно оценить насколько хорошо кандидат умеет собирать пакеты. Возможно было бы лучше, если бы кандидат продемонстрировал свои навыки на сборке с нуля какого-либо более сложного пакета. 201524 60 anna.khrustova 2021-08-13 18:42:21 +0300 Спасибо за комментарии, учту. > Вопросы: > http://git.altlinux.org/people/khab/packages/?p=drweb11-preinstall.git; > a=commitdiff;h=8bd720a7d0fdf89b7cc515700611fc77cde92353 > > 1) Где и при каких условиях создаётся или удаляется файл /_NEW_SYSTEM_ ? > > http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff; > h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4 На этапе инсталляции системы нельзя менять свойств безопасности определенные выпускающим дистрибутива. Наш инсталлятор создаёт флаг /_NEW_SYSTEM_ в начале инсталяции и удаляет его после завершения. Например, когда в каталоге /tmp стоит опция 'noexec' и идет процесс установки системы, то нам это позваляет понять, что в данный момент установка программы в данный каталог будет невозможна, а если пакет устанавливает уже администартор, то данную опцию возможно поменять. http://git.altlinux.org/gears/a/alterator-pkg.git?p=alterator-pkg.git;a=blob;f=alterator-pkg/backend3/pkg-init;h=9e76ca686d4d6744d50027d884f51615c7271ac3;hb=cf4cdff3f3212cdb7c4c671d6df9d0c994022152#l53 > 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не > удалось найти указание версии в апстриме. > Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE > > К имеющимся пакетам претензий нет. Есть только пара вопросов и несколько > небольших рекомендаций. > > К сожалению, все собранные пакеты - простые, либо не содержат сборки, либо > эта сборка простая. > Изначально такая цель ставилась, научиться собирать простые пакеты такие как preinstall. > Вот два самых сложных пакета для сборки: > http://git.altlinux.org/people/khab/packages/?p=bpytop.git;a=commitdiff; > h=32c1dcf4084eb73fb6c6f85270c2733e04dcb991 > http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff; > h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4 > > Пакеты *-preinstall по сборке ещё проще двух указанных выше пакетов. Там > сборка отсутствует. > > Только по таким простым пакетам сложно оценить насколько хорошо кандидат > умеет собирать пакеты. Возможно было бы лучше, если бы кандидат > продемонстрировал свои навыки на сборке с нуля какого-либо более сложного > пакета. Ещё несколько пакетов было собрано: #282420 1c-preinstall.git=8.3-alt13 #279956 sputnik-browser-preinstall.git=5.3.5672.0-alt1 #270114 mate-panel.git=1.22.2-alt2 201526 61 klark 2021-08-13 19:43:28 +0300 Дима, Алексей, большое спасибо! В комментарии 39 говорилось, что осталось сделать для джойна: "Убедить всех менторов в том, что ваши сборки больше не нуждаются в ревью.", после чего мы с Андреем эту готовность подтвердили. Изначально действительно ставилась задача научиться собирать вполне определённые пакеты, обеспечивающие слой совместимости продуктовых решений со сторонним коммерческим ПО. Лично для меня было важно иметь возможность поручать Анне такие задачи, а также простое бэкпортирование. Пропущенных нами с Андреем заданий от Анны очевидно больше, чем упомянуто в баге. Нас она давно убедила в том, что этот навык освоила. Теперь и независимый ментор, как я понял, подтвердил, что такие пакеты Анна может собирать без ошибок и самостоятельно. Достаточно ли этого для закрытия бага или требуется что-то ещё? 201601 62 darktemplaralt 2021-08-16 10:41:55 +0300 (Ответ для Anna на комментарий #60) > Спасибо за комментарии, учту. > > > Вопросы: > > http://git.altlinux.org/people/khab/packages/?p=drweb11-preinstall.git; > > a=commitdiff;h=8bd720a7d0fdf89b7cc515700611fc77cde92353 > > > > 1) Где и при каких условиях создаётся или удаляется файл /_NEW_SYSTEM_ ? > > > > http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff; > > h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4 > > На этапе инсталляции системы нельзя менять свойств безопасности определенные > выпускающим дистрибутива. Наш инсталлятор создаёт флаг /_NEW_SYSTEM_ в > начале инсталяции и удаляет его после завершения. Например, когда в каталоге > /tmp стоит опция 'noexec' и идет процесс установки системы, то нам это > позваляет понять, что в данный момент установка программы в данный каталог > будет невозможна, а если пакет устанавливает уже администартор, то данную > опцию возможно поменять. > > http://git.altlinux.org/gears/a/alterator-pkg.git?p=alterator-pkg.git;a=blob; > f=alterator-pkg/backend3/pkg-init;h=9e76ca686d4d6744d50027d884f51615c7271ac3; > hb=cf4cdff3f3212cdb7c4c671d6df9d0c994022152#l53 > Спасибо за объяснение. > > 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не > > удалось найти указание версии в апстриме. > > > > Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE Извините, если я не точно выразился. Я имел ввиду версию пакета, указанную вот так: Version: 0.0.0.2.507ad > > > > К имеющимся пакетам претензий нет. Есть только пара вопросов и несколько > > небольших рекомендаций. > > > > К сожалению, все собранные пакеты - простые, либо не содержат сборки, либо > > эта сборка простая. > > > Изначально такая цель ставилась, научиться собирать простые пакеты такие > как preinstall. Эта цель была достигнута, я согласен. (Ответ для Leonid Krivoshein на комментарий #61) > Достаточно ли этого для закрытия бага или требуется что-то ещё? С учётом всего вышенаписанного это решать Дмитрию. 201621 63 anna.khrustova 2021-08-16 14:25:49 +0300 > > > http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff; > > > h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4 > > > 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не > > > удалось найти указание версии в апстриме. > > > > > > > Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE > > Извините, если я не точно выразился. Я имел ввиду версию пакета, указанную > вот так: > > Version: 0.0.0.2.507ad Прошу прощения, идея была написать commit id в релиз, где 2 количество комитов от апстрима. 201624 64 ldv 2021-08-16 14:40:21 +0300 (In reply to Anna from comment #63) > > > > http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff; > > > > h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4 > > > > 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не > > > > удалось найти указание версии в апстриме. > > > > > > > > > > Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE > > > > Извините, если я не точно выразился. Я имел ввиду версию пакета, указанную > > вот так: > > > > Version: 0.0.0.2.507ad > > Прошу прощения, идея была написать commit id в релиз, где 2 количество > комитов от апстрима. В качестве апстримного релиза был взят 0.0, поскольку у апстрима не было ни одного релиза? 201636 65 anna.khrustova 2021-08-16 15:06:44 +0300 > > > > Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE > > > > > > Извините, если я не точно выразился. Я имел ввиду версию пакета, указанную > > > вот так: > > > > > > Version: 0.0.0.2.507ad > > > > Прошу прощения, идея была написать commit id в релиз, где 2 количество > > комитов от апстрима. > > В качестве апстримного релиза был взят 0.0, поскольку у апстрима не было ни > одного релиза? Да 201868 66 ldv 2021-08-19 22:47:29 +0300 (In reply to Aleksei Nikiforov from comment #62) > > > К имеющимся пакетам претензий нет. Есть только пара вопросов и несколько > > > небольших рекомендаций. > > > > > > К сожалению, все собранные пакеты - простые, либо не содержат сборки, либо > > > эта сборка простая. > > > > > Изначально такая цель ставилась, научиться собирать простые пакеты такие > > как preinstall. > > Эта цель была достигнута, я согласен. > > (Ответ для Leonid Krivoshein на комментарий #61) > > Достаточно ли этого для закрытия бага или требуется что-то ещё? > > С учётом всего вышенаписанного это решать Дмитрию. С одной стороны, изначально была поставлена очень низкая планка, с другой стороны, эта планка была взята. Кандидат способен самостоятельно собирать простые пакеты, и совершенно не претендует на сборку сложных. Достаточно ли этого для вступления в ALT? Это очень необычный расклад, не припоминаю ничего подобного с тех пор, как была введена формальная процедура вступления. Оставляю этот комментарий здесь, чтобы дать на него ссылку коллегам и спросить их мнение. 201873 67 klark 2021-08-20 03:51:10 +0300 (In reply to Dmitry V. Levin from comment #66) > Кандидат способен самостоятельно собирать > простые пакеты, и совершенно не претендует на сборку сложных. Сложность решаемых задач бывает и за пределами пакетной сборки. То, что оседает в спеке, может быть квинтэссенцией очень непростой работы, но зачастую полезной для ALT. На мой взгляд, тут важный месседж для Анны: быть маинтейнером -- большая ответственность. Не надо самостоятельно делать ничего в репозиториях, пока новыми навыками не овладеете твёрдо. За это и мы, менторы, тоже несём ответственность. > Достаточно ли этого для вступления в ALT? Это очень необычный расклад, > не припоминаю ничего подобного с тех пор, как была введена формальная > процедура вступления. Анна овладела тремя навыками -- сборкой с нуля простых пакетов, простые изменения пакетов, включая прикладывание патчей и простейшее бэкпорирование путём копирования. Кандидат показал способность освоить навык. Он может освоить и другой навык, если это потребуется. Ведь нигде не говорится, какой сборочной сложности должен быть пакет. Говорят, в 2007 все кандидаты собирали один и тот же пакет, он никогда не доезжал до Сизифа. К слову, нынешнюю планку я бы точно не взял, и сложность моих пакетов почти всегда не в хитросплетениях пакетной сборки. > Оставляю этот комментарий здесь, чтобы дать на него ссылку коллегам и > спросить их мнение. Спасибо! Я начал было писать письмо, чтобы помочь систематизировать ряд вопросов, но так и не нашёл подходящих коротких формулировок. Однако вспомнился случай, когда мы (еле собирающие пакеты) быстро и просто помогли маинтейнеру, собирающему такие пакеты, как LibreOffice и Chromium-gost. Просто, у всех в тиме должна быть своя специализация, сборка пакетов -- ещё не вся разработка, другие сильные стороны тоже могут быть полезны ALT. Джойн нужен не только для того, чтобы научились собирать, главная цель -- понимать друг друга, учиться друг у друга и пользоваться единым инструментом, едиными стандартами. Злоупотреблять только полученными возможностями никогда не надо. Т.е. можно это всё отрегулировать по уму, вопрос организационный. 201917 68 mike 2021-08-21 00:59:43 +0300 (Ответ для Dmitry V. Levin на комментарий #66) > С одной стороны, изначально была поставлена очень низкая планка, с другой > стороны, эта планка была взята. Кандидат способен самостоятельно собирать > простые пакеты, и совершенно не претендует на сборку сложных. Достаточно ли > этого для вступления в ALT? Брр, а тебя точно не смущает, что моя первая сборка в альте была по сути чем-то вроде замены /usr/local/apache/log/access_log на /var/log/httpd/access_log в пакетном webalizer.conf? :-) Мне кажется, пора уже RESOLVED FIXED здесь увидеть. 201918 69 ldv 2021-08-21 01:10:39 +0300 (In reply to Michael Shigorin from comment #68) > (Ответ для Dmitry V. Levin на комментарий #66) > > С одной стороны, изначально была поставлена очень низкая планка, с другой > > стороны, эта планка была взята. Кандидат способен самостоятельно собирать > > простые пакеты, и совершенно не претендует на сборку сложных. Достаточно ли > > этого для вступления в ALT? > Брр, а тебя точно не смущает, что моя первая сборка в альте была по сути > чем-то вроде замены /usr/local/apache/log/access_log на > /var/log/httpd/access_log в пакетном webalizer.conf? :-) Нынешний порядкок вступления был принят вследствие снижения уровня готовности кандидатов к самостоятельной сборке пакетов. 202094 70 ldv 2021-08-27 15:29:21 +0300 (In reply to Anna from comment #0) > Created attachment 8903 [details] > ssh pubkey > > Псевдоним: Khab > Email: anna.khrustova@gmail.com > Ментор: cas@ , klark@ > Цель: Научиться собирать пакеты. У меня остался один вопрос: теперь, когда над вами больше не довлеет то, что довлело раньше, вы всё ещё хотите завершить процедуру вступления в ALT? 202130 71 anna.khrustova 2021-08-30 11:22:28 +0300 (Ответ для Dmitry V. Levin на комментарий #70) > (In reply to Anna from comment #0) > > Created attachment 8903 [подробности] [details] > > ssh pubkey > > > > Псевдоним: Khab > > Email: anna.khrustova@gmail.com > > Ментор: cas@ , klark@ > > Цель: Научиться собирать пакеты. > > У меня остался один вопрос: > теперь, когда над вами больше не довлеет то, что довлело раньше, > вы всё ещё хотите завершить процедуру вступления в ALT? Да. 202228 72 glebfm 2021-09-02 14:57:29 +0300 Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства! 202245 73 aen 2021-09-02 17:09:38 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #72) > Адрес подписан на devel@. > Пользователь добавлен в группу мейнтейнеров. > > Желаю удачного мейнтейнерства! Анна, добро пожаловать в тим! :) 202251 74 klark 2021-09-02 18:54:04 +0300 (In reply to Anna from comment #71) > (Ответ для Dmitry V. Levin на комментарий #70) > > вы всё ещё хотите завершить процедуру вступления в ALT? > Да. Анна, мои поздравления! Успешных ALT-build'ов! :-) 8903 2020-08-11 13:03:38 +0300 2020-08-11 13:03:38 +0300 ssh pubkey id_ed25519.pub application/vnd.ms-publisher 117 anna.khrustova c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSURVMWdkOERYcUxxU3lPLzN5SWlL L1FDM1ArVk1VWkQyNno2dmlRTzZMbFkga2hhYkBjb21wLWNvcmUtaTUtODI2NXUubG9jYWxkb21h aW4K 8904 2020-08-11 13:08:19 +0300 2020-08-11 13:08:19 +0300 gpg pubkey file_38797.txt text/plain 3125 anna.khrustova LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQoNCm1RSU5CRjh4UCs4QkVBQzkw aG50QkZRZmlRZGh2cWJ0NmxwUW5CN0tDTXdINHFIbWR6OHRuLzZHNDkrUXJlZnENCmN1SXhBS2lm VGdnZ0V1a292WG9oUDNoT0FvS0JkWGxPd3NvbXdkNmw5cklYT0djamtlTEpTVnl1czFsUS9HM0MN Cjh4ZnJ2RzZicHlHbUIxS0pNQ3p6KzdCNTMxT2RMaWVtY00yanVvdDhJVmVCYzM1b2I1bEtxWjdB WSs0dFpxL3INCk5lcy9XdnduWGJTMjZPZTJhOHJSK29iVGNCNmtUbTJyUTBockw2K3EzQk96UXVR YzBSQ0ZMcDArV2kvdXpUR3UNCnpUUm5iaU0vTjRQaUtsZjdBQXJLVU4vbVN2dGFZdndUZ3QwWE9I Umt1L3VIbXc1TVhTdHBtT214NnkrL1Vpa0QNCkRGdytkZDcvRGVDbVp5VzBrZXVHRmVKUDZDWGVp dzkzODVCZXR0RjcyOTRBYmcvcEJaY1BCeENxZWJNcW1MSk8NClg1VVh3elhCZTM4YkNlSHBmTXli aTNwd2VHbkNLd0FjK1YvcEhQYkNHMEpRWEpCTktMKzg5R2NQcWZpOGdWa0oNCnhaWEdMQkIwa3hR OFkvSXJTNVNpMkVPczFrM1JyRmZ6eHpKbzFSb0l5elNQRkpOaUN2U2t0V3AzTXZvWkdrZy8NCkJh dHJnZnRsMHJVNUw0NGpEL2grQjhseGI0OGtDMkF4V25CMFFoV0ZQKzJvUHFJdUtBdVdWSTI1STdj bCtLVlMNCnJGZ2NWbGZFZzJJNDU4UFhRLy9CRFdlVjJ2M2tlRDdpRXBFNFczZnllRDJkNnVhaGpS NnBZaEJKdlgwMk40cVUNCndUdXAyV0tPM200Q0dZUVU3UUtsNjFGR0M4b0sreUg5K3lhMDR4QUw5 b0FJd1BSZW1VRFdVcWc5VndBUkFRQUINCnRDSkJibTVoSUV0b2NuVnpkRzkyWVNBOGEyaGhZa0Jo YkhSc2FXNTFlQzV2Y21jK2lRSTRCQk1CQWdBaUJRSmYNCk1UL3ZBaHNEQmdzSkNBY0RBZ1lWQ0FJ SkNnc0VGZ0lEQVFJZUFRSVhnQUFLQ1JCZ0ZqSEJBdjRXRVRBRUQvOWgNCmlmVS9jVUJYMVF4bGln K0NpN0p1VzJRbGFnb3VHTE02VmJ1aWRWeUJmTVJCVzBwdURmZ250am5nL0NkeE52RkENCmpwbWty Qm5na1VtVDM3cW1Cdi9CME5mVUFiTFY4NWVjWWlzdFowc2k1VHNRSE9TYlZIeFA2R3Y4eDlLekFJ VHINCmc2VjYwOG8yc25zMnU5MUdqK2xKTUl4RVpuTXZLNXZPekRCWXo0S1QyYU4wSHJPaW5yeUJY TjNCK2RXYjdZVzENCjNaaGJkckNWMVh5dEdDTCtPR1NpTEZmUjZsbE9SZTNuK0lCVDgzTkp1RHNY YVkvVkh2clB4ZTNTWHV0YVZJdWkNCk9iUGtGaWtWNTNoWkZJSkE5RzJIeGFKaHpZV1pvVTN2Y2Vw cWtKYS9acm9heWJ4eFVIdGFYRXpuR3c3YUl2L3MNClZ1YTRYQjlLa3FxN3Q0ejUxZ0R5ZnU3VzR2 UTJnazdVS0IzbmZIaWlPVjQyeEpsa1hCTXkwNjE1eVN6aURVcEsNCjFMYWwzNnMxUmxndTNUTElt Sm93SEdaYngrdmJUMi9wZHdmV0kzT05Va1hBOGN4VXBUSlRaUDRITmxkanFaUnoNCkhSLy9kZ0gy cmJ5Y2VEVVNYWHhkamIycGJ5L3VvYnM4RkQra0NzNW9EWXorTkw0ZXlCQ1BOZnNOUkhtb3EzT28N CmNBUldCOTBDTmVSQ2p0c0pvbFMzSnhWRE44MzVuVEwwZ29WenphU3FKMStoY0ZrVlBWNkJvYzZT ckdoZlp4cjkNClRFVXRLQk5TZmJsUE9FdnNYQVpyRzA2K2lhZkhjMkRXa0NCR1F6RXEyd2lsQkpK Uk1jWlk0OTBqaC9tV2tsWFkNCkNMK0d4M2MwcUtpd21ZOFRlZXVLNnNoM21VVkk3TWc1VWRMTUJa bDFsTGtDRFFSZk1UL3ZBUkFBNWVmaVc4Z1UNCi9ueUEyTHR6NCtNQ2p0WU8xdTVVYkp6OHBJTTJI U3NWcWhFczVveWdrdTRLVmY5SGJUam1pUG04eXV1QVNpeG4NCnFVUmh2QjNCdS9SWjZXOSt5N0Zs QVc1ZkpZK3ZHL2dHY1JKSlpobEc5OU45Ty9VRzdYekVQdE42a0NDalJJWWINCjVrcGpYZy81MENO V1lyU2NoZUdBeVBZWVJ1L0ZmVHdRcUwwL01KZkNkdkcrc2ZxT3hmMU41RGlxckltOExUMmcNCk01 N056bmsrTGlLblhMMW9ia3QwY2FsTjF0eGl3S3U0cGQ3NlZRbWtxR0g0Q0dSalo5VUlNNkZXdFBX TG1QSXoNClJTVGdyeHJCMEIyODJtVSt3Z3gwVFNJZldlOEVCMDZrYjlYQmhkVFAvclRldVlLMTBE TE5sR3hKbE5sUEU2NGcNCnF0QURXS2xDbnhobE9qQW1TNG1IMTRzcjRnRmFGcjloM2dPN3RrK1ZM SlFYM0QvRktud1I0RCttRWJTWWFxR20NCmdTVEJySmNDakpRSXRaZlF1N3ZqZGkyNXJpanllL3FO T2pNbDE2NEk4SEUzVFFpQlJaMmRFRTR1TWVKQ1czbzYNCnJyR2tpZFJVbFBIVXdzbW05TWIwZVlP UG04WXFzZnFyelhkUk5jNC9JYUZOTGk2bmZjbUFxREEzb2I0d0gvdHgNClVIdVdWdnhQczExbTA5 Sk9wbDZXU1NmR1ZBSk11eVZuWXRXL0EwaGtWcUFjVml5VXJETVlRSS9vc0FJV0FURkoNCktmSy84 K1lSUnJmN1NBR1l0SG1TYXZUNFk5RHNPckM0andjVnphTWMxNFVXcmRyZWt3eDNRNXRwNWxIeWRh dGYNCmlsQnJzditVZU8vYkxPc0ZIMjVkRHUrK045M3pzdHJrSXZzQUVRRUFBWWtDSHdRWUFRSUFD UVVDWHpFLzd3SWINCkRBQUtDUkJnRmpIQkF2NFdFVGJqRC85QnlISHlZU0VkVlptdjJnNHdqajZS Rkd6RVQwK0FaK3FSOFBkSjFuOFYNCktvU2kxVi9JSUdQdDBTNDlvdFRGVmJMMlNnMlliTHlBT2R1 YlI3a3oyZHF1QXZYOGE5ajF6c21vaEdpOXJtREwNCmFHZmJuRzJCV0doNXZHK2srWjc5Tzl3bmJs M0hxZGU5UnBlY25rcmVlUjNQQTVUQkhqczlUOTBHQk1IVEYyNnMNCmhGd3VneHI0akR4bXRBajZn OTgyT3BNcGEwRjQ1ZDUySEo5eWIxSGgyNEhoWjJVaHBPUU1WTDJjNEdZMHRlWmQNClRVbnE2L2xV NmVLZEtCNU93Tm1USmpFYzBFTG93elNScTJOajlia3g4Um1VbUVuL3FiMVRqZHRjYkRZaytod04N ClNNMnBKRWgwQXRqc25yTXc5WE1FMXl0eUo0NUdiemR6Y3l0bWxtRzhRWVdhS2dTbHd4U2s3KzVw cExGYks3L2oNCkNDSVJNVmptS2JzdTlrR2w2WXBqcC91a2dMNjVzQm9rM0ZrY2tKbHlqSXF6ckpG dFo5OHFERUpoZWhITlVtRU0NCktMcTVWZ0Y5YUw0ZDlwT1ZSMzE5Zy8wS05QQVVCZWUvc2ZVUnp2 TXg0ZmxPYUtPRjJuZWJMRE9ZWnBmU2xQZFcNCktwN0J0cEM3dGZWNGhPZGVSdjhsQTRTOUgyaEpq SGVmcFJ0dU9rN3dnTndleVpJRHpTZlFkdmw5bThLV1cxTW8NCmVyaHNxZVpXbXllOTl0Yk1lNTRT Mi8vd2JuRGVGOUE1ZWRsRnRoNVdFMFM2SmsyTHpnL2lEcDRLOVROR05HMEkNClZ2S2NBMlM3N3NK QUYrVlNmbGRyUDdxb3B5S2c3Tkt4R3BiQXRnSGR2WlJyUWlIaDJqQldSdCtPcVNVMVdFVzMNCmJR PT0NCj04UkR4DQotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQo=