37945 2020-01-28 13:34:09 +0300 [done] join svn17@ 2021-03-25 03:41: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 svn17 glebfm darktemplar darktemplaralt gkot glebfm grenka iv ldv mike sin cas oldest_to_newest 187288 0 8545 svn17 2020-01-28 13:34:09 +0300 Created attachment 8545 Публичный SSH-ключ Ник : iv17 Почта : altbug@yandex.ru Ментор: sin@altlinux.org Моя цель: Научиться собирать пакеты. 187289 1 8546 svn17 2020-01-28 13:36:05 +0300 Created attachment 8546 Публичный GPG-ключ 187630 2 sin 2020-02-07 14:24:26 +0300 Подтверждаю заявку. На текущий момент в минимальном объёме сборка пакетов освоена. Прошу представить примеры пакетов. 187648 3 svn17 2020-02-07 16:19:58 +0300 https://github.com/ichtrnemo/local-policy Исправлен файл default/local.xml Данное исправление запускает gpupdate при старте системы. 188020 4 glebfm 2020-02-19 13:13:11 +0300 > Ник : iv17 Не будет ли легко перепутать ник с iv@? 188041 5 svn17 2020-02-19 14:33:20 +0300 Добавил iv@ в подписчики, чтобы поставить его в известность. Полагаю, что перепутать наши ники будет не просто. 188061 6 glebfm 2020-02-20 10:16:53 +0300 (In reply to Савин Иван from comment #5) > Добавил iv@ в подписчики, чтобы поставить его в известность. > Полагаю, что перепутать наши ники будет не просто. Ваня единственный член тим про которого я не волнуюсь, что он перепутает. Все кого я спрашиваю говорят, что это плохая идея. 188062 7 mike 2020-02-20 10:29:25 +0300 Тут ещё такой прикладной момент, что можно где-нить tab'ить iv17 и не заметить, что дотабил только до iv... у меня такое впопыхах бывало с mik/mike и в каких-то похожих случаях. Но мне кажется, что это пожелание/предупреждение, а не полиси. 188065 8 svn17 2020-02-20 11:12:54 +0300 Ясно. Исправлю. 188067 9 grenka 2020-02-20 11:31:11 +0300 > Все кого я спрашиваю говорят, что это плохая идея. Вы уж извините, но я считаю, что моё мнение должно тут присутствовать, потому что меня не спросили, а я бы ответил, что это не такая уж и плохая идея. Как правильно заметил mike@, у нас нет полиси по созданию ников. >> псевдоним (имя пользователя) участника, выбирается им самим. Имя должно начинаться с буквы, содержать только буквы и цифры и быть не короче трёх символов. Если уж на то пошло, то давайте заставлять iv@ менять свой ник. iv17@ в этом плане прекрасный ник, удовлетворяющий всем требованиям. Просто со стороны это может выглядеть, как "Извини, я не хочу чтобы у тебя был такой ник". Если уж на то пошло, то пусть те члены тим, которые против, напишут тут своё мнение, если им это важно=) 188072 10 8623 svn17 2020-02-20 12:56:48 +0300 Created attachment 8623 новый публичный gpg ключ ник: svn17 почта: svn17@altlinux.org 188289 11 glebfm 2020-03-03 14:47:09 +0300 ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 3.0. 190825 12 svn17 2020-06-29 14:46:12 +0300 Готово два пакета. Простой акселератор компилятора, который кэширует и повторно использует результаты сборки: http://git.altlinux.org/people/svn17/packages/?p=buildcache.git;a=summary Добавлена возможность использовать boildcache через переменную окружения GCC_USE_BUILDCACHE: http://git.altlinux.org/people/svn17/packages/?p=gcc-common.git;a=summary 190856 13 sin 2020-07-01 03:16:28 +0300 Сборка пакетов воспроизведена. Пакеты buildcache и gcc-common рабочие - подтверждаю. Замечания: - в репозиториях нет ветки по умолчанию (попробуйте склонировать собственные репозитории); - для исправления используйте команду ssh gitery default-branch; - нужно определиться с thirdparty на борту buildcache - можно ли (имеет ли смысл?) от каких-то из них избавиться? 191664 14 svn17 2020-08-02 21:05:09 +0300 В оба репозитория добавил ветку по умолчанию (sisyphus). thirdparty на борту buildcache: я бы оставил, думаю, поддержка пакета будет проще. Они маленькие, 4,6М. 191992 15 svn17 2020-08-24 10:47:17 +0300 Есть ещё пара пакетов. Модуль alterator'a для обновления ядра: http://git.altlinux.org/people/svn17/packages/alterator-update-kernel.git Перевод для данного модуля: http://git.altlinux.org/people/svn17/packages/alterator-l10n.git 193601 16 sin 2020-10-29 11:38:19 +0300 Думаю нужно на чём-то остановится и собрать в таску buildcache. Предлагаю перейти в следующему шагу. 193610 17 svn17 2020-10-29 13:32:55 +0300 Хорошо, buildcache. Нужен доступ к сборочнице. 193968 18 svn17 2020-11-09 16:44:22 +0300 Мне нужен доступ к сборочнице чтобы продолжить gpg: Can't check signature: public key not found task add: 0.18.0-alt1: tag signature verification failure 194067 19 glebfm 2020-11-10 20:58:01 +0300 Пакет alt-gpgkeys обновлён. T/J/S -> 4.0. 194121 20 svn17 2020-11-12 14:45:43 +0300 Пакеты buildcache и gcc-common собрались. http://git.altlinux.org/tasks/261639/ 194209 21 ldv 2020-11-14 04:12:57 +0300 (In reply to Савин Иван from comment #20) > Пакеты buildcache и gcc-common собрались. > http://git.altlinux.org/tasks/261639/ В gcc_wrapper.c был добавлен комментарий: /*if the user tries to use ccache and buildcache simultaneously, ccache is used.*/ Пожалуйста, начинайте предложения в комментариях с заглавной буквы. После * в начале комментария и перед * в конце комментария нужен пробел. В %changelog была добавлена строка: - Add support buildcache via GCC_USE_BUILDCACHE environment variable Пожалуйста, ставьте точку в конце предложения. В buildcache.spec написано: License: zlib На это ругается sisyphus_check: buildcache-0.18.0-alt1.x86_64.rpm: license not found in '/usr/share/license' directory: zlib Традиционное название этой лицензии - Zlib. В пакет buildcache забандлены такие системные библиотеки, как zstd. Если нет причины избегать использования системных библиотек, то следует не использовать забандленные. 194322 22 svn17 2020-11-18 17:32:27 +0300 В gcc_wrapper.c исправил комментарий. В строке в %changelog'е добавил точку в конце. (gcc-common) В buildcache.spec исправил лицензию. Забандленные библиотеки (zstd, lz4, lua, hiredis) заменил на системные. Пакеты buildcache и gcc-common собрались. http://git.altlinux.org/tasks/262033/ 194519 23 ldv 2020-11-29 15:50:03 +0300 (In reply to Иван Савин from comment #22) > В gcc_wrapper.c исправил комментарий. > В строке в %changelog'е добавил точку в конце. (gcc-common) По gcc-common у меня больше вопросов нет, готов одобрить это сборку, если нужно. 194528 24 sin 2020-11-30 13:25:08 +0300 (Ответ для Dmitry V. Levin на комментарий #23) > По gcc-common у меня больше вопросов нет, готов одобрить это сборку, если > нужно. Да, давайте одобрим эту таску. Можно ли считать, что join завёршён? Я со своей стороны считаю, что да. У нас есть ещё одно исправление для alterator-auth. 194529 25 ldv 2020-11-30 13:32:07 +0300 (In reply to Иван Савин from comment #22) > В buildcache.spec исправил лицензию. > Забандленные библиотеки (zstd, lz4, lua, hiredis) заменил на системные. За это время вышло несколько более новых версий buildcache. Я предлагаю попробовать собрать самую свежую, а заодно потренироваться не терять изменения, сделанные в пакете, в результате обновления версии. 194610 26 svn17 2020-12-04 13:54:39 +0300 Собрал самую свежую версию buildcache (0.23.0): http://git.altlinux.org/people/svn17/packages/?p=buildcache.git;a=summary 194611 27 ldv 2020-12-04 14:21:20 +0300 (In reply to Иван Савин from comment #26) > Собрал самую свежую версию buildcache (0.23.0): > http://git.altlinux.org/people/svn17/packages/?p=buildcache.git;a=summary В новой версии забандлили xxhash, не хотите попробовать собрать с libxxhash-devel? 194619 28 svn17 2020-12-04 18:13:25 +0300 (Ответ для Dmitry V. Levin на комментарий #27) > В новой версии забандлили xxhash, не хотите попробовать собрать с > libxxhash-devel? Да, я пропустил этот момент. Но собрать с libxxhash-devel не получилось: [ 10%] Building CXX object base/CMakeFiles/base.dir/hasher.cpp.o In file included from /usr/src/RPM/BUILD/buildcache-0.23.0/src/base/hasher.cpp:30: /usr/include/xxhash.h:433:12: fatal error: xxhash.c: No such file or directory # include "xxhash.c" /* include xxhash function bodies as `static`, for inlining */ ^~~~~~~~~~ Затем я обнаружил следующее в ихнем заголовочном файле: /*-********************************************************************** * xxHash implementation *-********************************************************************** * xxHash's implementation used to be hosted inside xxhash.c. * * However, inlining requires implementation to be visible to the compiler, * hence be included alongside the header. * Previously, implementation was hosted inside xxhash.c, * which was then #included when inlining was activated. * This construction created issues with a few build and install systems, * as it required xxhash.c to be stored in /include directory. * * xxHash implementation is now directly integrated within xxhash.h. * As a consequence, xxhash.c is no longer needed in /include. * * xxhash.c is still available and is still useful. * In a "normal" setup, when xxhash is not inlined, * xxhash.h only exposes the prototypes and public symbols, * while xxhash.c can be built into an object file xxhash.o * which can then be linked into the final binary. ************************************************************************/ Значит ли это что нужно оставить всё как есть, или нужно отключать inlining? Второе мне кажется не очень хорошим решением, я думаю в upstream'е так пытались повысить производительность. 194620 29 ldv 2020-12-04 18:21:50 +0300 (In reply to Иван Савин from comment #28) > (Ответ для Dmitry V. Levin на комментарий #27) > > В новой версии забандлили xxhash, не хотите попробовать собрать с > > libxxhash-devel? > > Да, я пропустил этот момент. > Но собрать с libxxhash-devel не получилось: > > [ 10%] Building CXX object base/CMakeFiles/base.dir/hasher.cpp.o > In file included from > /usr/src/RPM/BUILD/buildcache-0.23.0/src/base/hasher.cpp:30: > /usr/include/xxhash.h:433:12: fatal error: xxhash.c: No such file or > directory > # include "xxhash.c" /* include xxhash function bodies as `static`, for > inlining */ > ^~~~~~~~~~ Интересно, у меня такого в /usr/include/xxhash.h нет: $ grep xxhash.c /usr/include/xxhash.h * - xxHash homepage: https://www.xxhash.com * xxHash's implementation used to be hosted inside xxhash.c. * Previously, implementation was hosted inside xxhash.c, * as it required xxhash.c to be stored in /include directory. * As a consequence, xxhash.c is no longer needed in /include. * xxhash.c is still available and is still useful. * while xxhash.c can be built into an object file xxhash.o 194622 30 svn17 2020-12-04 19:09:41 +0300 (Ответ для Dmitry V. Levin на комментарий #29) > Интересно, у меня такого в /usr/include/xxhash.h нет: Да, извиняюсь, это я на Р9 собирал. На sisyphus'е всё собралось. http://git.altlinux.org/people/svn17/packages/?p=buildcache.git;a=summary 194653 31 ldv 2020-12-05 23:09:24 +0300 (In reply to Иван Савин from comment #30) > (Ответ для Dmitry V. Levin на комментарий #29) > > Интересно, у меня такого в /usr/include/xxhash.h нет: > > Да, извиняюсь, это я на Р9 собирал. На sisyphus'е всё собралось. > > http://git.altlinux.org/people/svn17/packages/?p=buildcache.git;a=summary Спасибо. Только в два последних commit message и в %changelog вкралась опечатка (вместо xxhash написано xxhach), исправьте её, пожалуйста. Кроме того, у Глеба в его репозитории /people/glebfm/packages/gcc-common.git тоже есть коммит gcc-common-1.4.26-alt1 с изменением на совсем другую тему, поэтому у меня к вам просьба перебазировать своё изменение поверх этого коммита и, соответственно, собирать gcc-common-1.4.27-alt1. 194691 32 svn17 2020-12-07 13:04:20 +0300 (Ответ для Dmitry V. Levin на комментарий #31) Исправил опечатку в commit message и %changelog. Собирал gcc-common-1.4.27-alt1. 194692 33 svn17 2020-12-07 13:05:49 +0300 (Ответ для Иван Савин на комментарий #32) > (Ответ для Dmitry V. Levin на комментарий #31) > Исправил опечатку в commit message и %changelog. > > Собирал gcc-common-1.4.27-alt1. Собрал) 194699 34 ldv 2020-12-07 13:51:45 +0300 (In reply to Иван Савин from comment #32) > (Ответ для Dmitry V. Levin на комментарий #31) > Исправил опечатку в commit message и %changelog. > > Собрал gcc-common-1.4.27-alt1. Approved. Я думаю, что это задание уже можно отправлять в Сизиф. 194709 35 ldv 2020-12-07 15:44:31 +0300 Задание в Сизифе. У меня вопрос к ментору, есть ли ещё задания для кандидата? 194741 36 sin 2020-12-08 16:53:49 +0300 (Ответ для Dmitry V. Levin на комментарий #35) > Задание в Сизифе. > У меня вопрос к ментору, есть ли ещё задания для кандидата? В целом, я думаю, что опыт и навыки проявлены. Но задачи накопились: - исправление alterator-auth; - исправление polkit. Оба решения подготовлены, предлагаю их рассмотреть. 194743 37 svn17 2020-12-08 17:08:26 +0300 alterator-auth: http://git.altlinux.org/people/svn17/packages/?p=alterator-auth.git;a=summary http://git.altlinux.org/people/svn17/packages/?p=alterator-l10n.git;a=summary Таска 261722. polkit: http://git.altlinux.org/people/svn17/packages/?p=polkit.git;a=summary Таска 263041. Всё собралось. 194748 38 svn17 2020-12-08 19:09:20 +0300 merge-request в апстрим polkit https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/71 194804 39 svn17 2020-12-10 14:54:30 +0300 https://bugzilla.altlinux.org/show_bug.cgi?id=39420 195033 40 svn17 2020-12-17 17:05:45 +0300 В sisyphus собран polkit 0.118-alt2. (Таска 263041) В p9 отсутствует libmozjs78 (нужен для >=0.117.alt1) и libmozjs68 (нужен для 0.116.alt3), но есть libmozjs60, поэтому сделал сборку polkit 0.116-alt2.M90P.1 поверх polkit 0.116-alt2. (Таска 263588) 195121 41 ldv 2020-12-24 02:07:55 +0300 (In reply to Иван Савин from comment #37) > alterator-auth: > http://git.altlinux.org/people/svn17/packages/?p=alterator-auth.git;a=summary > http://git.altlinux.org/people/svn17/packages/?p=alterator-l10n.git;a=summary > Таска 261722. 2sin: если с этим заданием всё в порядке, то почему бы его не заапрувить? 195122 42 ldv 2020-12-24 02:14:00 +0300 (In reply to Иван Савин from comment #37) > polkit: > http://git.altlinux.org/people/svn17/packages/?p=polkit.git;a=summary > Таска 263041. У меня вопросы по оформлению %changelog: 1. Насколько я понимаю, эта сборка закрывает https://bugzilla.altlinux.org/show_bug.cgi?id=39420; в таком случае в %changelog следует внести соответствующую запись, чтобы этот баг автоматически закрылся при попадании сборки пакета в Сизиф. 2. Одно предложения разбито на несколько строк, это понятно, но почему все эти строки начинаются со знака минус? 195146 43 svn17 2020-12-24 18:53:57 +0300 (Ответ для Dmitry V. Levin на комментарий #42) > У меня вопросы по оформлению %changelog: > 1. Насколько я понимаю, эта сборка закрывает > https://bugzilla.altlinux.org/show_bug.cgi?id=39420; в таком случае в > %changelog следует внести соответствующую запись, чтобы этот баг > автоматически закрылся при попадании сборки пакета в Сизиф. > 2. Одно предложения разбито на несколько строк, это понятно, но почему все > эти строки начинаются со знака минус? Убрал минусы, добавил (closes: 39420) в changelog. 195194 44 svn17 2020-12-30 13:59:15 +0300 (Ответ для Иван Савин на комментарий #43) > Убрал минусы, добавил (closes: 39420) в changelog. Это было сделано для другой ветки, извиняюсь. Проделал эти же исправления для sisyphus. 196229 45 svn17 2021-02-12 17:03:33 +0300 Готов ещё один пакет, модуль альтератора для обновления ядра: http://git.altlinux.org/people/svn17/packages/?p=alterator-update-kernel.git;a=summary 196235 46 sin 2021-02-13 06:09:33 +0300 Учитывая, что buildcache уже в сизифе (кстати, вышла новая версия v0.25.2 - думаю обновлением может заняться кто-то другой, заодно gear-remotes добавить для отслеживания), а также alterator-update-kernel, собранный вместе с кодом с нуля (тут ещё есть замечания), можно считать, что сборка освоена. В пакете alterator-update-kernel следует добавить более полное описание в секцию %description, но это скорее детали. 196354 47 svn17 2021-02-19 22:57:22 +0300 Доделал alterator-update-kernel вместе с переводом (кроме более полного описания в секции %description, пока не придумал). http://git.altlinux.org/people/svn17/packages/?p=alterator-update-kernel.git;a=summary http://git.altlinux.org/people/svn17/packages/?p=alterator-l10n.git;a=summary Таска 266636 196379 48 svn17 2021-02-20 14:38:38 +0300 Дополнил описание в секции %description. 196914 49 sin 2021-03-11 18:52:39 +0300 Считаю, что со сборкой пакетов svn17@ ознакомлен в достаточном объёме, чтобы успешно завершить Join. Несколько пакетов, в том числе и собранных с нуля, уже в сизифе: - http://git.altlinux.org/gears/b/buildcache.git - http://git.altlinux.org/gears/a/alterator-update-kernel.git - http://git.altlinux.org/gears/p/polkit.git 197186 50 ldv 2021-03-23 19:28:04 +0300 Призван ещё один человек (darktemplar@) для независимой оценки готовности кандидата. 197209 51 darktemplaralt 2021-03-24 14:02:27 +0300 Замечания по buildcache: 1) Мне говорили, что тэг "Packager:" deprecated и его не стоит указывать. Если он не указан, он автоматически заполняется при сборке пакета. 2) В .gear/rules: "tar.gz: v@version@:." Сжатие исходников также не рекомендуется. src.rpm уже сжимается сжатием лучше, чем указано здесь. Сжимать перед этим исходники дополнительно может только мешать. Лучше использовать "tar" вместо "tar.gz". 3) Из https://www.altlinux.org/Руководство_по_написанию_changelog#Содержимое : "При сборке новой upstream-версии это указывается первым пунктом." * Fri Dec 04 2020 Ivan Savin <svn17@altlinux.org> 0.23.0-alt1 - Merge remote-tracking branch 'upstream/master' into sisyphus. Считаю, что данная запись в %changelog не следует указанному руководству. Прошу ещё раз ознакомиться с указанным руководством и следовать ему. 4) Взял src.rpm buildcache-0.23.0-alt2.src.rpm. В нём находится файл buildcache-0.23.0-alt.patch размером 4382727 байт (4,2 МБ). Это очень большой патч. И в нём много лишнего. Патч создаётся следующей директивой из .gear/rules: diff: v@version@:. . name=@name@-@version@-alt.patch 4.1) Первое лишнее: файлы .gear/buildcache.spec, .gear/rules, .gear/tags/list. С учётом того, что недавно ввели возможность исключать файлы и директории из таких патчей (см. https://bugzilla.altlinux.org/31851 ), хорошо бы их убрать. Но это лишь мелкая проблема в этом патче, одну её можно было бы и пропустить. 4.2) Большей проблемой является разбандливание библиотек. Само разбандливание - это хорошо. Плохо то, что для того, чтобы избежать использования локальной копии исходников библиотек, эти копии исходников удаляются прямо в репозитории и эти мегабайты изменений попадают в генерируемый патч. Насколько мне известно, обычно в таких случаях излишние исходники удаляют не из репозитория или архива с исходниками, а при сборке пакета в секции %prep. Таким образом, в патч это не попадает, апстримные исходники упаковываются в оригинальном виде, а при сборке исходники bundled библиотек всё же отсутствуют и гарантированно не используются. Я считаю что лучше было бы исключить следующие директории из патча, вернув их в репозиторий, с последующим их удалением в секции %prep: src/third_party/hiredis src/third_party/lua-5.3.4 src/third_party/lz4 src/third_party/xxHash src/third_party/zstd Исключением этих директорий из патча, без исключения из патча директории .gear, мне удалось получить патч размером 8739 байт (8.6 КБ). Такой объём изменений просмотреть значительно легче по сравнению с 4-мегабайтным патчем, с учётом того что большей частью объёма патча сейчас является просто удаление файлов. Замечания по alterator-update-kernel: 1) Тоже самое про тэг "Packager:". 2) https://lists.altlinux.org/pipermail/sisyphus-incominger/2021-March/602517.html В логе есть вот такое предупреждение: x86_64: alterator-update-kernel=1.3-alt1 post-install unowned files: /usr/lib/alterator /usr/lib/alterator/backend3 /usr/lib/alterator/ui /usr/lib/alterator/ui/update-kernel /usr/lib/alterator/ui/update-kernel/update /usr/share/alterator/applications /usr/share/alterator/ui 2021-Mar-07 08:47:27 :: [x86_64] #100 alterator-update-kernel: install check OK (cached) Прошу посмотреть это предупреждение, на какие проблемы оно может указывать, и поправить что можно. По другим пакетам замечаний нет. Указанные выше замечания не считаю достаточно критичными, чтобы блокировать завершение вступления, хотя было бы хорошо и их расммотреть. С учётом всего этого считаю, что кандидат готов. 197210 52 sin 2021-03-24 14:55:33 +0300 Давайте по частям: (Ответ для Aleksei Nikiforov на комментарий #51) ... > Замечания по alterator-update-kernel: > > 1) Тоже самое про тэг "Packager:". > > 2) > https://lists.altlinux.org/pipermail/sisyphus-incominger/2021-March/602517. > html > > В логе есть вот такое предупреждение: > > x86_64: alterator-update-kernel=1.3-alt1 post-install unowned files: > /usr/lib/alterator > /usr/lib/alterator/backend3 > /usr/lib/alterator/ui > /usr/lib/alterator/ui/update-kernel > /usr/lib/alterator/ui/update-kernel/update > /usr/share/alterator/applications > /usr/share/alterator/ui > 2021-Mar-07 08:47:27 :: [x86_64] #100 alterator-update-kernel: install check > OK (cached) > > Прошу посмотреть это предупреждение, на какие проблемы оно может указывать, > и поправить что можно. Поправить тут можно только вот это: > /usr/lib/alterator/ui/update-kernel > /usr/lib/alterator/ui/update-kernel/update Тут всё ясно. А вот "мне говорили, что тэг "Packager:" deprecated и его не стоит указывать." - это, как требование, выглядит странно. Я давно его не указываю, но в куче примеров он имеется. Если бы сборка с ним отваливалась по sisyphus_check, то я бы согласился с тем, что это замечание имеет серьёзную силу. Давайте это "пожелание" как-то формализуем. В общем, два исправления в alterator-update-kernel. Хорошо. 197211 53 darktemplaralt 2021-03-24 15:00:34 +0300 (Ответ для Evgeny Sinelnikov на комментарий #52) > Поправить тут можно только вот это: > > /usr/lib/alterator/ui/update-kernel > > /usr/lib/alterator/ui/update-kernel/update > > Тут всё ясно. > Всё верно. > А вот "мне говорили, что тэг "Packager:" deprecated и его не стоит > указывать." - это, как требование, выглядит странно. Я давно его не > указываю, но в куче примеров он имеется. Если бы сборка с ним отваливалась > по sisyphus_check, то я бы согласился с тем, что это замечание имеет > серьёзную силу. > Давайте это "пожелание" как-то формализуем. Да, согласен, назвать это "пожеланием" будет точнее. 197212 54 sin 2021-03-24 15:10:48 +0300 (Ответ для Aleksei Nikiforov на комментарий #51) > Замечания по buildcache: > > 1) Мне говорили, что тэг "Packager:" deprecated и его не стоит указывать. > Если он не указан, он автоматически заполняется при сборке пакета. > > 2) В .gear/rules: "tar.gz: v@version@:." > > Сжатие исходников также не рекомендуется. src.rpm уже сжимается сжатием > лучше, чем указано здесь. Сжимать перед этим исходники дополнительно может > только мешать. Лучше использовать "tar" вместо "tar.gz". > > 3) Из https://www.altlinux.org/Руководство_по_написанию_changelog#Содержимое > : "При сборке новой upstream-версии это указывается первым пунктом." > > * Fri Dec 04 2020 Ivan Savin <svn17@altlinux.org> 0.23.0-alt1 > - Merge remote-tracking branch 'upstream/master' into sisyphus. > > Считаю, что данная запись в %changelog не следует указанному руководству. > Прошу ещё раз ознакомиться с указанным руководством и следовать ему. > > 4) Взял src.rpm buildcache-0.23.0-alt2.src.rpm. В нём находится файл > buildcache-0.23.0-alt.patch размером 4382727 байт (4,2 МБ). Это очень > большой патч. И в нём много лишнего. > > Патч создаётся следующей директивой из .gear/rules: > > diff: v@version@:. . name=@name@-@version@-alt.patch > > 4.1) Первое лишнее: файлы .gear/buildcache.spec, .gear/rules, > .gear/tags/list. > > С учётом того, что недавно ввели возможность исключать файлы и директории из > таких патчей (см. https://bugzilla.altlinux.org/31851 ), хорошо бы их > убрать. Но это лишь мелкая проблема в этом патче, одну её можно было бы и > пропустить. > > 4.2) Большей проблемой является разбандливание библиотек. Само > разбандливание - это хорошо. Плохо то, что для того, чтобы избежать > использования локальной копии исходников библиотек, эти копии исходников > удаляются прямо в репозитории и эти мегабайты изменений попадают в > генерируемый патч. > > Насколько мне известно, обычно в таких случаях излишние исходники удаляют не > из репозитория или архива с исходниками, а при сборке пакета в секции %prep. > Таким образом, в патч это не попадает, апстримные исходники упаковываются в > оригинальном виде, а при сборке исходники bundled библиотек всё же > отсутствуют и гарантированно не используются. > > Я считаю что лучше было бы исключить следующие директории из патча, вернув > их в репозиторий, с последующим их удалением в секции %prep: > src/third_party/hiredis > src/third_party/lua-5.3.4 > src/third_party/lz4 > src/third_party/xxHash > src/third_party/zstd > > Исключением этих директорий из патча, без исключения из патча директории > .gear, мне удалось получить патч размером 8739 байт (8.6 КБ). Такой объём > изменений просмотреть значительно легче по сравнению с 4-мегабайтным патчем, > с учётом того что большей частью объёма патча сейчас является просто > удаление файлов. Все аргументы разумны. Про Packager то же замечание. Ну, давайте это либо зафиксируем, либо как ошибку, либо, хотя бы, как предупреждение. Про exclude для diff даже я не в курсе - как-то мимо прошло. Какую рассылку я пропустил? Какая часть документации на этот счёт поправлена? В общем четыре исправления в buildcache. Хорошо. Иван, возьми тогда обновлённый вариант: https://github.com/alenka26/buildcache из ветки sisyphus. 197214 55 darktemplaralt 2021-03-24 15:23:13 +0300 (Ответ для Evgeny Sinelnikov на комментарий #54) > Про exclude для diff даже я не в курсе - как-то мимо прошло. Какую рассылку > я пропустил? Какая часть документации на этот счёт поправлена? > Лучше это спросить в указанном баге при необходимости. Убрать .gear/* из патча - это тоже просто пожелание. Там не так много строк. Тут немного важнее пункт 4.2. Решил я посмотреть какие изменения сделаны по сравнению с апстримом: $ cat .gear/rules $ gear-restore-tags $ git diff v0.23.0 И тут мне открывается diff на 117080 строк, и подавляющее большинство этого diff-а - это удаление файлов bundled библиотек. Если проделать только изменения, предложенные в пункте 4.2, то этот diff будет всего 284 строки, и это при наличии в нём директории .gear/. Хоть проревьюить можно изменения и в текущем виде, но лично мне кажется, что в предложенном варианте это сделать может быть проще. Обычно такой подход используется при удалении bundled библиотек, например, в Fedora, хотя причины там возможно и другие. 197216 56 iv 2021-03-24 15:29:16 +0300 (In reply to Evgeny Sinelnikov from comment #54) > Про exclude для diff даже я не в курсе - как-то мимо прошло. Какую рассылку > я пропустил? Какая часть документации на этот счёт поправлена? man gear-rules(5) Вики, конечно, неплохо бы пополнить. 197217 57 sin 2021-03-24 15:38:27 +0300 (Ответ для Ivan A. Melnikov на комментарий #56) > (In reply to Evgeny Sinelnikov from comment #54) > > Про exclude для diff даже я не в курсе - как-то мимо прошло. Какую рассылку > > я пропустил? Какая часть документации на этот счёт поправлена? > > man gear-rules(5) > > Вики, конечно, неплохо бы пополнить. А когда обновление можно ожидать в p9? Или как иначе предлагается разработчику их получить? Лично я пока не рассчитываю, на обновление до сизифа на рабочей машине. Можно собрать весь инструментарий локально. Но как-то не хотелось бы это многократно выполнять на разных машинах множеству разных людей. 197227 58 ldv 2021-03-25 02:39:54 +0300 (In reply to Aleksei Nikiforov from comment #51) > С учётом всего этого считаю, что кандидат готов. 197233 59 ldv 2021-03-25 03:41:22 +0300 Адрес подписан на список рассылки devel@. Пользователь добавлен в группу мантейнеров. Желаю удачного мантейнерства! 8545 2020-01-28 13:34:09 +0300 2020-01-28 13:34:09 +0300 Публичный SSH-ключ id_ed25519.pub application/vnd.ms-publisher 101 svn17 c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSU9GaDUwNThzL3JjbXpLcGU0WVNq QzE4VU9CVTBzQUY0a2x5Z01hKzdIYmsgaXZhbkB0MDEuZG9tYWluLmFsdAo= 8546 2020-01-28 13:36:05 +0300 2020-02-20 12:56:48 +0300 Публичный GPG-ключ iv17_public_gpg.key application/x-iwork-keynote-sffkey 3086 svn17 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkY0djkyRUJFQURENVVu dDROTlJKcVlyejZsVUFDeEwzbHkwUjBTd2VYTmZ6UzUzbHJnYTA4U3RnT0ZCCkhJTnhaOEZsNnN6 RWRrMUc1YUc1U0tpY0dRL2ZFL3hGR0VLd2diaWRjSFFKYm56cnBoanZ0RE1zSk1NelZvZEgKd2l4 OTczV3JhZC9rL0tQbEVOdVpCRDJDNGM0aERGYW03L2lJNWNMSExLMkZlaG80bk5sRWtjL1JTaE9N TG9hZwpZZ3hFYjJpWWRkNkljZ3c5Q1FjUDhBOE1MajFMd0RxWFN3UElYRW4wVFk5cVN3S0VUS28r NVAydmNaQVI5L0cyCmF3TVljdDZnMFZMM1lnYTVnUVNDUTVpMzdiRTNuaGhCUmczYWNCWGJXNXFp VlFycndGM05QdVFHdTQwWXVJeDAKNW5XTjlvenFKdXd3d0tsWE1wODdDdlVGU2pKNjlkN3MrdEpN OWdIRkluN3MydnBQQmNPV3g3cE5qSkQwSU83VApKbVNIMXFpeUphbzJKc3pCTFpIVHdxOGtkSHA5 Zk9nV3dUQS82SHV0MHZjWnNCRXdvWVNkc1hleVF2TGxwNHJ6ClpxbjFUajBCVFNTY2ZybWVRZWVU NitRNlhZQ3h1dFI4bGZucWVaRk91NjB3Nm4rSm1HNWNFLzU5MWVWcFpqQzAKMkR5Uk81SmZBeHRO OC9NYXNTZEZydlBrYXpTVnEzRzI5THhtSGxLamgxY0wxeUV5RElJTTBpOGduVTNsSU5tRQp5Mjdw UEpqU0ZIQ2pYY0ZhVGFEdU9JaXYrWUJqb3VQbUU5KzBZOWFSdVpPS1ZFSGlhanZQL0lWMHFwRXJP b242CmV2bi9COTRNbjltckJsVkFQMmRERlZNY3QxZTlWVk9ta0U3L29sWERkUENBcTBUS25CalZY b3FqOFFBUkFRQUIKdEN4SmRtRnVJRk5oZG1sdUlDaHVieUJqYjIxdFpXNTBjeWtnUEdsMk1UZEFZ V3gwYkdsdWRYZ3ViM0puUG9rQwpPQVFUQVFJQUlnVUNYaS8zWVFJYkF3WUxDUWdIQXdJR0ZRZ0ND UW9MQkJZQ0F3RUNIZ0VDRjRBQUNna1FMT2hXCmJWS1N1K3VPSUJBQWptaDl4QmNudlJWWE1BN3dD bE84bDM4UUhKY0RVRXplTE9CUWJmU0R2bWxjS0RHZy9uZ3kKd3RqYlFnV1JZa0hwczhtQi9SN292 UlBjRHpURldiV3VZN0U3KzFKTjFWSmJxN2RiNEwrMmtndURSRTduWkJTeApSWXdINE9yRVpJVnBn TGE4VkdBNnVFYkJJRlBWL2ZReXd6NXhtSVFMRnF1aG93eExVemorZ1VCSVZjYmw1VzJTCk0xV2FR YXJRSDU5SlkvcExkUjhOK21pY2FHN1BwRGdHcTV0Q1FsSU93TXErcjh0dTlDeVdPNDFGeE1tbE9x cmMKcy91ZWl5VnNlV2J5TCtKT0s1MmFFU1F5S2p6N2o1RXZSeFZpMU8vMHJTUEJaaDhZM0pPbklL UitKL2lkR1o0Qwp5OUZGbjQvMFNhSlJEZitJSFNWQlVWWDEwZlRLMGlwaEFMNGNheXFjRkRxb3d1 eWphaGhRWjhzUWlxMmxrRlpXCjNndEdEd21JaFJVWGpzYXZtRnlLYlF0U0lCR05UZkt0RVBjQmhI M2dWTjF5RU9JbnJwL2Q4OGhRSU9lUkdKR3oKWk9uTnVrK291WldETnlYRFBqQjZacXpuSnZMeUhM VnZzbjM4a1RpQ0ZBVG1BS2VUOE5SNnF5a1oxazMzZW15aAp1SXdIRDVkSzZ6Tm1OWXFBZFpINW5Q M1RnSk9pT2R1RHF0aEM0VWhZcVZSSjZ2UkxDUUNxaS9tSUlLM2hPZzFYCkord0VIM3JHeXZLY25T bnM4WTIzZnBMRWZaWHJCMEI1Q0lZZkpvcTFWK1c3ekpTbjViRHpielFjbmJUZW5JbmsKWFd3dmpB WndNQ2l0aGp0Z3AyeWF5d0ZSd25qVlJZdGR1dGw3ZUc0QjFaZVR4Ujl1NzMxcmRmYTVBZzBFWGkv MwpZUUVRQU1zZWlWOVdPaWRMZVZBeXYrVHhFWlVidExjVFFuRnkzenJoMlNFYm9PdUNlbVBrRyth MzFhKzVEa2VCClQ1Q2hzWGRuRTIyWnVFV3NFQ0oxV3FsRGloSnZpRXdKYXI0aU9Hck0wUHdjS3Vq TVpGbzBKaEQ3SmZySmlUeEsKYmxkQ3c4MDVPNVoybllDbk1Tb3JGdnlxVTR5NlZMOHhocE1USDJO cWtiTlhQUHphc3JKZTMwaDREYXhLZEt0WgpxZ1VZQmxEOU5xSEt1WkhCVWFMQXlWdk5YRWE1dkpl QUpPeDFwU09sWEFBemV3Y2dqQXA0UDd5NlBHV2N5SW5sCi8vY0pOcDE1Q0RSQmFVelBSM1k1ZVVu LytHczl6R1lya28ydGlvZEVWNEJHZXdzbVRZVmxMMzYyM3RZbWRsSFgKZjNPRWZTaHYzUXN3S2tC UlZmd1dydlF6eis0dVo4N1prZHdMMlRmS0tFVzBVN0w1ZXk0ZEJncnVCMzEyV2plbQoyLzNQSGZ0 UUU3eWJ3T2ZZUUhkOVVYdmNkVllCQVd0NjBuL2J5K2NsZU5YbFM3WXNLMkM5QkF2Yk50Q05pMmVJ Cm1iNE82Tkp4MDFpMFUzOVM2RXpac002d3lsYUFud0k4SGdrNXZpR1UvZktXcGFmR3pmMDE1U3Ez dlBpY3pVV1gKditXV0xBOHJ1VDFKSnFia0JCMU5OY252VzVuTjNSQzVCOUtLOCtXTWJ2aDg2VUky TzVGWE9NYzlnd1YxRlQ0cgpPRU15SGhCWEJsdzBaT29GYlVFdlF4Z0NRaXNZbkQyQnZCZHhaRDRs ZUk0NWdLRzg2ekJRUE53NFhpS2pGaStLCnlhUXg2Y25RQnFNUW1oUFFOdVF5dWR4ek9SZnRzOVZC Zmp6WnhESnExYWJPMEYvbkFCRUJBQUdKQWg4RUdBRUMKQUFrRkFsNHY5MkVDR3d3QUNna1FMT2hX YlZLU3UrdENUZy8vVmoyQ1BhY0FrelhRN1VGRnBQZnBQVjd2cGYrYwpIc3lHUHdKaTlGU1VLMW5r N1A5Y0t6a3BkUDY0SitiakJYVEJjY1phNHFueXkzaEhmb1pFdG9taXpEYkpVbVlJCm1mQUdHWEZD bjZJRStzamcyL1RYZVhEd201eHIycm5zemZ6WlpINjZMY1Y4cjZFUVdBSDMxbWM3cERkd2hFajMK MjVzd25VdzFVMWhjVU5icjFjZ1QyTDhZT2lUTElRY1hLRkhFWklnalZkL0M5ZVl5Qmxad3dPY3ds QUozb29vdApES0I2bW85cHVGNkJncm5TV0U0dm5LY2F0T2o4QzkvWjNNUTJFb20wU3VHb0c2T1pW RHJWSzJXY256WUNsUkNrCkZzTFhOdlF2dUNycjhTYnh6REN2TTl4dG5zdXpRbUFoWkcrdnFWa0FF RGVmUjZ5WU5MZVNoOG9RMWxsQjNramcKNHU0UVN4SEh6bThqbFY4Y25rcTluWjRXajNNWng5djl6 NlZqaU0zRnZTcjdrWGYrbDRUUzhuc1VvYlRFZlpPawpTRk1qMTlaTHFZYlc1OUlBSjNyWGlZa0xS MGFNUDFXNTVabEMwS3V1Z00zeDlXV2MrQ2lrNDNSckxMQVJUVWtaClFvVXVsVFlSUVZmM2MrRG4y NEtHWmpJUG1DUVE1bTRaUGtLb0tFUGtUMVRGNUpWd3c0N0w5NVZSOGM2R1g3eVUKZDh5M2NuZUJp dzdEaDRXWHlic2cxRmJseEROY3JURlQvRWI3UnVubGRHZ09vZUtmSDFMREU5WkRQaUtIc2MyRQpu bDNlUWJTODJ0Q3dEV0ZTT01hSm9uMmtPV0JlQWVNRHJnRnM0ZCtwamo2OW1icmNUUk9FZnBGU1lH SkwvcWVjCk11eFhDTHFlSm9Qckx6bz0KPXAxYnkKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= 8623 2020-02-20 12:56:48 +0300 2020-02-20 12:56:48 +0300 новый публичный gpg ключ gpg_public.key application/x-iwork-keynote-sffkey 3086 svn17 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkY1T1Rwa0JFQURGcndS NDZUdWNDRGVKaUJVelNMVFRxemRNT3JLaWlzT2FvODFRV1NkNEJ6d3hmb25lCjJKNGdpY0tiZjVX OVhaOHJrL1NTRUdMYXdBMmxwaUlBSW8yTnZIUTd5c3VETG1vZ3Y1VXdHaXhham0wTW5hNi8KbFpy b3ZacXZpcnJzZVhhOG1UOHJGMWxRWTNjYXZxS0paZHFSdGx6MTd4ZDRtVUZHWTdkM1FVMGRMdEhC a0RqZwpRRlowSlVjdWpicktGQnQ0cUZOMjYxU2xpa3hpMEh6UGhkTGpEZTFDejkrb1lwU3pFNTVS aUtDVTBxUUc2NXRyCnpjMlFmUmhtT0NwblJVVkRYSFpMTnVubXZLTDFhQi9zQmREaW1VVUFJZkdl amZTKzlHMFBDaUpzcVRmSnh0Rk0KSFMxYTIxcG1CcUtacTJwbkdCTS96clBWaHE3ZHNMSCtkc1Zy NzhvYWRLN0Y5S0VaZFpNNTBrcCs1Y09pSVJMVQpkN0M5RHFTb3RkbnI5Nm1IbTdJdVI4ZXU0Q3Ny ZjBVMkplTmdEdWUrOFRyaTFLcWxXQ3ZUUFFVVjZoME91aExDCndmYnVqUVRRVzc1S3RGd01NbWhL aGhDci9rV2tCOFFXZ2hRTk9lcHpZUGFiMWVXQUJxWnJ1ZUZTUlY0d3k0c1QKYWxTUnZWQ1lNNWZy YnlPSkZFTWlpK1lyeW9Dd1prVjkzM2Y3NG1RRXJKNmcxcmlWRkw3bGtxdmczaEt4K0lpQQpQLzlV bS9lZXJpRVMxKzlLcjhGUU9pUkFvZDh1MkxhQkhnOFg1MXNRN0U2Z0ZyRDRBSlA0bDNIZ3NsSi9a cEhpCloyQXcxUzhacEpPOXVKM0kxU2xXOWNMY1RQdEV4U1JLR05OUFNZWEJXM1J4OXcvQWpVVmtK QmdCSndBUkFRQUIKdEMxSmRtRnVJRk5oZG1sdUlDaHVieUJqYjIxdFpXNTBjeWtnUEhOMmJqRTNR R0ZzZEd4cGJuVjRMbTl5Wno2SgpBamdFRXdFQ0FDSUZBbDVPVHBrQ0d3TUdDd2tJQndNQ0JoVUlB Z2tLQ3dRV0FnTUJBaDRCQWhlQUFBb0pFSG1UCjdtYVdqMFBkTStJUC9SRGZPcTdMcEhyV1VQUndH OGRGWGREamlNN2l0dFd5aUFITFBSdnFCdU0vN3BORTZxUVoKc1ZEUnFBYXFoSzJwSTNud3lGWjJ2 RTBENWpnSGI0WWxhcXg0aW5UWFNNZHZsWkQxN0s3aThZamZHMStZNHErQQpBaG5RdHMzbjlKKzVh cm5FcWcvdXpMazF1cWxuc0h6M1lBME9MZWxoWnRqV1FhR0JRU2lyYkpEVFRMYXhZWDVxCjhKbFlC U3ZUVUxhY0pxZVpWMndubm5LSE5PSVJLTDZCZXNGSXp5a2QxMjJGT0NveVBGSnp4WW9XTjJmVW1Z a1MKb0svNHFwQkt0UWl0azdxVU5HSFUwWGlmL1p2Y0tJQzQzeDR2WU8wTXJ0N1BwSEp3Z3RPSEZu bFczVjJSODBQcwpsZHdCTWhzL01ZODZFczEyQm9VMlQzdmRFdUkwZ0tkaG1ISzFqYmwvK01hV0hK c0dyai8wYkJvZ3hMMkV0bnozCmk2b3o3YW1pOXJDS1BBdXdUeHVWVk82dy8yNWg2Q2tOajJtSld4 TjdQbStwNzZVMmhEOUVjYUU4T0t0aXZMTnEKSVNheVB6amF3eXZKam54TGt5ZUpYOFY3K2xFUG0x T3JqRmFwYjZMT2VYay9RUkZuNzR2VktqOTBoOTJSN0xKZwp4UnBHak1nbnIrOEo0Z0FBQWVmMU5M T3RZSnhiWlNvVmZ0WmdpQU82WitaUlQrcDg2MlNTRUtzRXZvTGl0MnVVCit1c0JtYVFFeEo4UVVu ZmRmUkVMdllRMUpkR2V5Z0tuVmczY3oxUTR0SGtHYUFyK2M3eUtzeXI0SXd5Q0o1WEwKRmFsWURC WlI2cTl5WkVySXUxUnVGVXlwVEV1cXB6TGFOeUNyTE82MzY3K2pjbTBvMUpZRkVVZXV1UUlOQkY1 TwpUcGtCRUFEQnBxdGc1VzhQR1piY0JWZmtaYXY3WnF6QWZ5V3BSZUl3SzNOVjdUd09UWEMwRmpJ WDR6SXBpcmdXCmI5a1dFMHNZR0dqMkJJZVhubVY5MEQvTGcxQ2wvQ0xUWGdMbWgvbVV3MjBzbGF4 bkFKVXIzeUJPT1BrQVY5TkYKZW14UXJhcHFycXZLckdaaGJpeFM0M0NsOHZnaUlabDR3c1dPSTlm aXN1Sjh1K0h2d1JoU0tHcDJsaVpuTW4weApwWHczN1BYMFQxOVE0K2dpckhpbTJBVDd1ZlZvcTd5 ZlVHelhZalFlU1FmL09lMUhJbnV2cmxUWU1ZV2hlc2pnCk9oRGtLWE5QNEZJTHBwaHhHQkVNbDdW QS9HOHAyQy9PeEZLNDREeFF4a2UxZWVpUnAwdGV3blBrT2poaTlPVjIKRDB5WkVkeUhZd2RPcWY5 Zkw4QVl5VW5BTFl6ZldvUzhYQzMySWEzdXVHL1Y1ZW93WkI1YWhCTzV5MUN1N3NSZApJOG9EVzBW cVRxWkdqWW5vVmphaU1LMTh6Vi9DUGZaZFRFWFpVTThSd2dnbDNUd3d1dTdVajB6OFA4MHc4eVlZ Cm9Zc21wdEtQeTBSdGFubUQwbFk2L1dXRmdIT3I5SEpFUHREc3hUVXdRSCsxQ1hPSGxpYWJDTWsx c0wxWU9aNnkKYXZiUy8xWGRjTS9OSTNSZHAzTm9OU1JYZE1sSkwzRFFwRmg5Yy9iOHlZYmhWK3Fr L2xXL2FIZ1BBZHBaKytnagpwSUN5T2g5UUYzQUp2Unk1OFppY3liMUNobU5SbS81VTBKRkRVR2hH TXplNEhPNmtObjdmQm9mcEhnaDZUUWZYCmI5RUN0STU2dU9ubVdmOUtmRkV6ZzVSTGd4dnp4NDVJ UE9HUzluWXhVYlh0VWtFejlRQVJBUUFCaVFJZkJCZ0IKQWdBSkJRSmVUazZaQWhzTUFBb0pFSG1U N21hV2owUGQ2cXdQL2l4L1RQaHJYaFdpcG5OUGVzZVNieVNveTcxTgp6NCtISjI0NFR6MTlMVkJy WERRZzRSOUhyd1lvckU2aFU2dU1pUkd2N202RFpZUytWOCtUN1FyQXBIYlJZTW1iCjdrSi9IZXBU SUFlVDRuNlVUdEN1WE15bUk5OFlWdXhCMDBXU1lwOEtDRkdmRzg5c0FOWkpTMk5XNzk3ZXlFZTgK RUp3MURUSWJVYkIvcWo2cy8xaHBpUUJRL1FkSThzMTZxUHhMRU9QUnYrYUhtS1ZuZHBJeFhCTEdJ djFqajFDTwpXNXltbzc1dTBxcnkxTG55RmlRTThRbG82bW90S29GUjhyY3VaeWI3RU44TWxObTRH T2RSV3ZzZ1VnSDA3RFA5CjNQWGZMSXhxNE5tVmJzSThuS0YyQktLakx6TDBqMVRYdjFkZ2lmYXUv T3FDMjVoS2QyWW9aVU40UVVZM1lPWWUKZkZINmpZd3pmYStvdzB5aVNLMjBwNEMzQTdwaUdocjJE bjZaYzRJSjlkTHRBc1RhVW8xZ3hpaWhqR3RQWHFMRgpzcTE3MXdnL3NGdVN4Z2VjQVNBQ0lrY281 RFdjRGpBTytJVDZlVERud0RkRi9wSFhDZzNKMGQ5aVY3YUk5ajk2CkpzZ29ZNWdaRmVqUDNlMExl a1lJbkE1WFNIUnhUOThuS1dhQzdkeklWb2M4Wk1OK0dYUHdJbE9iSStxOE5BamwKVEhEa3ZOWTVv M0xaUTVMZjFPbWZKZEZjQyt6ekNNdElMT01RMlBpM3NuRUtXZWJFRHJzU2tlVkR3dHlBQmhHdAp3 dGV4RGhVbFBOU2sxM01hZ2FVWkU0T2pac29uVE82NUs5d3p1SkxsZytYWVZQVjE3K0xGSkc2ZUdB OUN1bHUrCm1majRrTlY2Tk1DejRwNTAKPTlWaHcKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo=