41734 2022-01-18 17:07:27 +0300 [done] join homura@ 2022-12-15 09:06:37 +0300 1 1 4 Development Team Accounts join unspecified x86 Linux CLOSED FIXED http://altlinux.org/Team/Join/Secretary P5 normal --- 1 Igor.A.Molchanov glebfm arbars bircoph glebfm grenka ldv mike cas oldest_to_newest 206829 0 10136 Igor.A.Molchanov 2022-01-18 17:07:27 +0300 Created attachment 10136 ssh public key for homura@altlinux.org Имя ментора: mike Псевдоним: homura Адрес почты: akemi_homura@kurisa.ch (если можно несколько, то тогда ещё Igor.A.Molchanov@mcst.ru) SSH- и GPG-ключи: в приложениях к багрепорту Цель: собрать для начала Taisei Project (https://taisei-project.org/), потом, возможно, что-то ещё (xnp2, dosbox-x, ...). 206830 1 10137 Igor.A.Molchanov 2022-01-18 17:12:07 +0300 Created attachment 10137 gpg public key for homura@altlinux.org 206831 2 mike 2022-01-18 17:14:33 +0300 (Ответ для makise-homura на комментарий #0) > Имя ментора: mike ack 207332 3 glebfm 2022-01-31 21:14:30 +0300 (In reply to makise-homura from comment #0) > Created attachment 10136 [details] С одной стороны, ключ в смысле типа и размера в порядке, а с другой стороны у него в конце CRLF, которые вызвали совершенно неожиданные проблемы в утилитах. Не могли бы вы приложить ключ без CR? (In reply to makise-homura from comment #1) > Created attachment 10137 [details] > gpg public key for homura@altlinux.org Ok. 207367 4 10238 Igor.A.Molchanov 2022-02-01 16:58:52 +0300 Created attachment 10238 ssh public key for homura@altlinux.org with LF EOLs (Ответ для Gleb F-Malinovskiy на комментарий #3) > Не могли бы вы приложить ключ без CR? Приложил. 207554 5 glebfm 2022-02-08 16:05:38 +0300 (In reply to makise-homura from comment #4) > Created attachment 10238 [details] > ssh public key for homura@altlinux.org with LF EOLs Ok. > (Ответ для Gleb F-Malinovskiy на комментарий #3) > > Не могли бы вы приложить ключ без CR? > Приложил. Спасибо! 207578 6 mike 2022-02-08 18:57:08 +0300 Собственно, Игорь ещё до размещения этой заявки освоил альтовый инструментарий в достаточной степени, чтобы собрать пару пакетов, один из которых уже в сизифе -- libcglm.spec Игорь написал сам и прислал, я лишь добавил .gear/rules и чуть причесал полученный спек: http://git.altlinux.org/gears/l/libcglm.git?p=libcglm.git;a=commitdiff;h=a6efb3de1584e574c7dc8840cdc9f2bd8a93fda9 -- а taisei.spec предлагаю привесить к данной баге в качестве первого пакета. Иными словами, считаю, что Игорь вполне готов начать вступление (что касается ключей, тут видней Глебу). 207582 7 10263 Igor.A.Molchanov 2022-02-08 19:58:57 +0300 Created attachment 10263 spec for Taisei Project v.1.3.2 Прикладываю spec-файл того проекта, который я планирую добавить в Sisyphus (Touhou-подобная игра (даммаку-шутер), Taisei Project, https://taisei-project.org/). 207584 8 mike 2022-02-08 20:11:45 +0300 Можем двигаться к 3.0 -- с моей стороны "добро". 207748 9 glebfm 2022-02-14 17:46:19 +0300 ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. 207787 10 mike 2022-02-15 16:54:16 +0300 Игорь, прошу выложить taisei.git на git.alt и провести пробную сборку; с вопросами пиши лично (или в devel-newbies@). 208365 11 Igor.A.Molchanov 2022-03-10 00:10:48 +0300 (Ответ для Michael Shigorin на комментарий #10) > Игорь, прошу выложить taisei.git на git.alt и провести пробную сборку; > с вопросами пиши лично (или в devel-newbies@). Готово: http://git.altlinux.org/people/homura/packages/?p=taisei.git;a=summary Проверил сборку с gear, собранный пакет установил и попробовал - работает. 208366 12 mike 2022-03-10 00:26:38 +0300 (Ответ для makise-homura на комментарий #11) > http://git.altlinux.org/people/homura/packages/?p=taisei.git;a=summary Собирать решил в итоге из тарбола, а не апстримного гита с добавлением альтовых файликов? В .gear/rules и spec-файле лучше заменить tar.xz на tar: содержимое srpm и так будет сжато xz по умолчанию, дважды жать -- лишь увеличивать объём и время. В спеке сам бы сделал (поскольку нет технической необходимости в обрамлении): -%setup -n %{name}-v%{version} +%setup -n %name-v%version Но это всё вопросы/предложения по оформлению, в целом пакет должен быть уже рабочим (отличия от того спека на основе твоего, что собирал я -- дополнение сборочных зависимостей). 2 glebfm: предлагаю переходить к шагу 3. 208395 13 Igor.A.Molchanov 2022-03-11 07:58:54 +0300 (Ответ для Michael Shigorin на комментарий #12) > Собирать решил в итоге из тарбола, а не апстримного гита с добавлением > альтовых файликов? Да, потому что у них иногда ломается мастер, вдобавок в релизном тарболе у них сразу все субмодули есть, а если собирать из гита - то их придётся ручками вытаскивать и подкладывать, мне кажется, это лишняя работа, когда её уже за тебя мэйнтейнер апстрима сделал. > В .gear/rules и spec-файле лучше заменить tar.xz на tar Как выяснилось, в таком случае получится, что ради экономии пары минут при сборке мы ломаем осмысленность строки Source в RPM: поскольку .spec попадает в SRPM, и пользователь, получивший этот SRPM из репы, может захотеть узнать точную ссылку на ванильные исходники, а тут нам придётся сломать её, тоже заменив на .tar, которого на гитхабе нет. Выглядит это как-то очень неудачно, как по мне. > -%setup -n %{name}-v%{version} > +%setup -n %name-v%version Сделал. Собрал, проверил, что работает, закоммитил, добавил тег 1.3.2-alt2, пушнул в репу (также параллельно сделал пару улучшений в сборке, относящихся к OpenGL ES - теперь можно гамать даже на видюхах, которые поддерживают только GLES, но не GL). 211156 14 Igor.A.Molchanov 2022-05-26 17:08:33 +0300 На всякий случай: собрал вчера из gear на e2k с помощью gear-hsh, сборка успешна (если не считать тонны warning-ов о депрекации разных вещей - но это норма даже для ванильной сборки taisei на e2k). Правда, у меня нет машины с альтом, на которую можно поставить видюху, так что проверить работоспособность с рендерером, отличным от null, не смог: VNC+LLVMPIPE из-за недоработанности LCCRT крашатся даже на glxgears, не говоря уже о чём-то более сложном. Но с другой стороны, при --renderer null музыка играет, звуки издаются, на ввод программа реагирует корректно, так что считаю, что всё ок. 211202 15 mike 2022-05-27 17:03:39 +0300 (Ответ для Michael Shigorin на комментарий #12) > 2 glebfm: предлагаю переходить к шагу 3. ping :) Так-то тут уже можно и на отсмотр другим участником команды приглашать: http://git.altlinux.org/people/homura/packages/?p=taisei.git 211206 16 grenka 2022-05-27 17:35:56 +0300 (Ответ для Michael Shigorin на комментарий #15) > Так-то тут уже можно и на отсмотр другим участником команды приглашать: Джойн по одному пакету? Или я что-то неправильно понял? 211218 17 Igor.A.Molchanov 2022-05-27 20:56:37 +0300 (Ответ для Grigory Ustinov на комментарий #16) > Джойн по одному пакету? Или я что-то неправильно понял? А есть лимит по минимальному количеству пакетов, которые я должен собрать, чтобы их начали принимать в сизиф, а меня - в команду? Просто про это ничего не было написано на вики. 211220 18 grenka 2022-05-27 21:22:56 +0300 (Ответ для makise-homura на комментарий #17) > (Ответ для Grigory Ustinov на комментарий #16) > > Джойн по одному пакету? Или я что-то неправильно понял? > А есть лимит по минимальному количеству пакетов, которые я должен собрать, > чтобы их начали принимать в сизиф, а меня - в команду? > Просто про это ничего не было написано на вики. Там было написано, что вы должны убедить ментора в том, что умеете собирать пакеты. Но поскольку ментор в силу человеческого фактора может отнестись попустительски к доверенной ему роли, ввели роль независимого рецензента. И в общем-то его тоже надо убедить в том, что вы достойны быть в команде. По одному пакету это сделать довольно сложно, хотя я бы на месте рецензента точно бы отправил вас на продолжение обучения. В спеке фигурируют два питоновских модуля для второго питона, которых нет в сизифе. Этот пакет вообще не должен собраться. 211225 19 Igor.A.Molchanov 2022-05-27 22:33:33 +0300 (Ответ для Grigory Ustinov на комментарий #18) > По одному пакету это сделать довольно сложно Хорошо, какие тогда требования по минимальному количеству пакетов? > В спеке фигурируют два > питоновских модуля для второго питона, которых нет в сизифе. Этот пакет > вообще не должен собраться. Не является ли это багом hasher тогда? Как он подсасывает пакеты, которых нет в сизифе? P.S. Пофиксил в спеке модули на соответствующие третьему питону, всё собирается (x86_64, e2k), повысил ревизию до -alt3, но как проверить, что подобных ошибок больше нет - не знаю. В вики это тоже не описано; там создаётся впечатление, что у hasher/gear-hsh нет проблем с изоляцией своего чрута от основной системы, но получается, они есть. Был бы хорош чеклист того, что стоит проверить начинающему сборщику в спеке из того, что не может проверить hasher/gear-hsh. 211240 20 mike 2022-05-29 16:56:46 +0300 (Ответ для Grigory Ustinov на комментарий #16) > > Так-то тут уже можно и на отсмотр другим участником команды приглашать: > Джойн по одному пакету? Или я что-то неправильно понял? Ну я с одним пакетом когда-то и пришёл (правда, за ним оперативно нарисовался второй, а дальше вообще понеслось и опомнился только сотнях на четырёх). Точнее, вообще с однострочной правкой к коробочному конфигу webalizer. (Ответ для makise-homura на комментарий #19) > Хорошо, какие тогда требования по минимальному количеству пакетов? Я таких не видел, но порой и впрямь просят представить более одного примера (того, чем собираешься заняться, или того, что готов пособирать в качестве пробного задания -- своего, как в данном разе, или существующего). > > В спеке фигурируют два питоновских модуля для второго питона, > > которых нет в сизифе. Этот пакет вообще не должен собраться. > Не является ли это багом hasher тогда? Как он подсасывает пакеты, > которых нет в сизифе? Это скорее особенность join -- надеюсь, мы не дождёмся ни четвёртого питона, ни третьего halflife с этим запросом в состоянии "всё ещё открыто" ;-] (скажем, bug 39887 удалось в итоге пройти весьма оперативно) Второпитоновые модули из сизифа по большей части выпилили, в частности, и эти (ещё в августе прошлого года): http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/p/python-module-docutils/ http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/p/python-module-Pygments/ А вот в p10 ещё есть и python-module-docutils, и python-module-Pygments -- если ты собирался на дистрибутиве, то неудивительно (если на сизифе, то такого же эффекта можно достичь, например, передав hsh --apt-config=/путь/к/apt.conf.p10 со ссылкой на sources.list.p10 в нём). > P.S. Пофиксил в спеке модули на соответствующие третьему питону, всё > собирается (x86_64, e2k), повысил ревизию до -alt3, но как проверить, > что подобных ошибок больше нет - не знаю. Проверил на sisyphus_e2k (v4) и sisyphus (x86_64), подтверждаю, собирается. > Был бы хорош чеклист того, что стоит проверить начинающему сборщику в спеке > из того, что не может проверить hasher/gear-hsh. Что-то ещё проверит сборочница (гругря, репозиторные проверки, которые сложно организовать вдали от соответствующих метаданных) -- но всё равно не всё, поэтому "вредный" отсматривающий, когда докопы по существу, тут не менее полезен, чем "вредный" профессор или военпред. 211242 21 grenka 2022-05-29 19:44:33 +0300 (Ответ для Michael Shigorin на комментарий #20) > (Ответ для Grigory Ustinov на комментарий #16) > > > Так-то тут уже можно и на отсмотр другим участником команды приглашать: > > Джойн по одному пакету? Или я что-то неправильно понял? > Ну я с одним пакетом когда-то и пришёл (правда, за ним оперативно > нарисовался второй, а дальше вообще понеслось и опомнился только сотнях на > четырёх). Точнее, вообще с однострочной правкой к коробочному конфигу > webalizer. Миш, если у тебя нет времени на помощь с обучением человека, передай менторство кому-нибудь, кому это интересно. Человек в BuildRequires пишет про python3-module-Pygments, хотя им там даже не пахнет. Ну и в ченджлоге творится полнейший бардак: https://git.altlinux.org/people/homura/packages/?p=taisei.git;a=commitdiff;h=9e801bdf3f5c27af7f1a00cd3c79bbfe7faa93fc Так дело не пойдёт. Только не в мою смену. 211272 22 Igor.A.Molchanov 2022-05-30 17:51:15 +0300 (Ответ для Michael Shigorin на комментарий #20) > если ты собирался на дистрибутиве, то неудивительно (если на сизифе, то > такого же эффекта можно достичь, например, передав hsh > --apt-config=/путь/к/apt.conf.p10 со ссылкой на sources.list.p10 в нём). Ну у меня p10, обновлённый до сизифа. Способа поставить сизиф с нуля я не смог нигде найти. Разумеется, никаких --apt-config я хэшеру не передавал. Как вообще можно проверить, что в сборку пошли только пакеты, изолированные от тех, что стоят на основной системе? (Ответ для Grigory Ustinov на комментарий #21) > Человек в BuildRequires пишет > про python3-module-Pygments, хотя им там даже не пахнет. Без него не генерится документация (сейчас специально проверил это): [6/190] Generating 'doc/ENVIRON.html.p/ENVIRON.html'. ../doc/ENVIRON.rst:267: (WARNING/2) Cannot analyze code. Pygments package not found. ../doc/ENVIRON.rst:273: (WARNING/2) Cannot analyze code. Pygments package not found. ../doc/ENVIRON.rst:279: (WARNING/2) Cannot analyze code. Pygments package not found. ../doc/ENVIRON.rst:285: (WARNING/2) Cannot analyze code. Pygments package not found. ../doc/ENVIRON.rst:291: (WARNING/2) Cannot analyze code. Pygments package not found. ../doc/ENVIRON.rst:297: (WARNING/2) Cannot analyze code. Pygments package not found. ../doc/ENVIRON.rst:303: (WARNING/2) Cannot analyze code. Pygments package not found. > Ну и в ченджлоге > творится полнейший бардак: > https://git.altlinux.org/people/homura/packages/?p=taisei.git;a=commitdiff; > h=9e801bdf3f5c27af7f1a00cd3c79bbfe7faa93fc Можно определение бардака (и опционально, полнейшего бардака) относительно чейнджлога? Хотя бы чтобы понять, к чему именно претензия. В идеале - какой-нибудь мануал на альтвики по чейнджлогам - ибо я не нашёл; такое чувство, что там с руководствами по сборке пакетов в сизиф творится тоже относительно заметный "бардак" - например, когда там аж три руководства (просто, "с нуля" и "с полного нуля"), ни одно из которых из коробки неприменимо и приходится в уме из всех трёх компоновать свой собственный путь. P.S. Если речь о том, что в спеке один из комментов к чейнджлогу улетел в репу только со следующим коммитом, а не с тем, к которому он должен был быть - сорян, не заметил, поправил, отребейсил и форспушнул сейчас. Теперь должно быть всё нормально. (Непривычно, конечно, копипастить чейнджлог из гита руками, да ещё и "до" того, как сделан соответствующий коммит (а на самом деле "коммит - правка чейнджлога в спеке - аменд коммита - пуш"; здесь я как раз забыл отамендить последний коммит); из-за этого там могут возникать такие косяки, да). 211409 23 mike 2022-06-03 14:01:27 +0300 (Ответ для makise-homura на комментарий #22) > Как вообще можно проверить, что в сборку пошли только пакеты, > изолированные от тех, что стоят на основной системе? hasher в любом разе строит чрут с нуля из репозитория -- т.е. можно, конечно, извратиться для получения в чруте в т.ч. пакетов, стоящих на основной системе, но это надо очень конкретно постараться. > В идеале - какой-нибудь мануал на альтвики по чейнджлогам - ибо я не нашёл Думаю, Гриша про вот этот фрагмент: %changelog -* Thu Mar 10 2022 Igor Molchanov <homura@altlinux.org> 1.3.2-alt2 +* Fri May 27 2022 Igor Molchanov <homura@altlinux.org> 1.3.2-alt3 +- Change python2 modules to python3 ones + +* Fri Mar 11 2022 Igor Molchanov <homura@altlinux.org> 1.3.2-alt2 +- Enable gles20 and gles30 renderers + +* Thu Mar 10 2022 Igor Molchanov <homura@altlinux.org> - Minor beautifying of spec and gear rules Ченжлог задним числом лучше вовсе не переписывать, а только дополнять -- недостатка циферок для Release: на складе пока не наблюдается :) А так, что самое смешное, есть даже отдельное http://altlinux.org/руководство_по_написанию_changelog -- немножко расширил секцию примеров, спасибо за вопрос. > такое чувство, что там с руководствами по сборке пакетов в сизиф творится > тоже относительно заметный "бардак" - например, когда там аж три руководства > (просто, "с нуля" и "с полного нуля"), ни одно из которых из коробки > неприменимо и приходится в уме из всех трёх компоновать свой собственный > путь. Вообще-то с полдюжины. И это в смену и Гриши, и нас с Черепановым, и Димы с Гошей, ага. > P.S. Если речь о том, что в спеке один из комментов к чейнджлогу улетел в > репу только со следующим коммитом, а не с тем, к которому он должен был быть > - сорян, не заметил, поправил, отребейсил и форспушнул сейчас. Обычно стараюсь отсматривать на всякий git diff перед коммитом :) > (а на самом деле "коммит - правка чейнджлога в спеке - аменд коммита - пуш"; > здесь я как раз забыл отамендить последний коммит); из-за этого там могут > возникать такие косяки, да). Выработал привычку для сколь-нибудь нетривиальных изменений разделять работу над содержимым пакета, спеком и (отдельно!) описанием сделанного. Бишь обновил-похакал-покоммитил по существу; затем потрогал спек и тоже закоммитил с хотя бы однострочным описанием (в идеале -- почему/зачем); затем поправил версию/релиз в спеке и уже к этому изменению написал %changelog (кстати, есть утилитка add_changelog и к ней пакетик для редактора -- vim-plugin-spec_alt-ftplugin; по \ac позволяет создать/добавить ченжлог минимальными телодвижениями) -- и вот для коммита таких изменений удобно применять gear-commit -a (сразу и commit message сформирует по записи в %changelog). И да, всё это должно быть удобно и кратко расписано на вики :-/ 211410 24 Igor.A.Molchanov 2022-06-03 14:10:51 +0300 (Ответ для Michael Shigorin на комментарий #23) > т.е. можно, > конечно, извратиться для получения в чруте в т.ч. пакетов, стоящих на > основной системе, но это надо очень конкретно постараться. Интересно тогда, как у меня такое получается, даже когда я этого не хочу... > Думаю, Гриша про вот этот фрагмент: Да, это я уже поправил. > А так, что самое смешное, есть даже отдельное > http://altlinux.org/руководство_по_написанию_changelog -- немножко расширил > секцию примеров, спасибо за вопрос. О, отлично, спасибо. Интересно, почему на него нигде ссылок нет из этих руководств (или я не нашёл...) > Вообще-то с полдюжины. И это в смену и Гриши, и нас с Черепановым, и Димы с > Гошей, ага. Лол, отличная ситуация. Пора ещё одно руководство писать (в полном соответствии с xkcd_14_standards.jpg) - о том, как новичку разобраться во всех этих руководствах. =) > кстати, есть утилитка add_changelog > удобно применять gear-commit -a Хм, надо будет изучить. > И да, всё это должно быть удобно и кратко расписано на вики :-/ Да уж, вопрос только - когда... 212397 25 Igor.A.Molchanov 2022-07-06 22:36:15 +0300 На всякий случай по просьбе @mike бампнул версию libcglm: https://git.altlinux.org/people/homura/packages/libcglm.git Собирается на e2kv4 и x86_64, также собирается зависящий от неё taisei (и на x86_64 проверено, что запускается). Можно ли это считать за второй пакет? 212400 26 mike 2022-07-06 23:56:52 +0300 2 glebfm: я всё так же считаю, что homura@ готов собирать пакеты в сизиф, и прошу перейти к шагу 3. 212568 27 glebfm 2022-07-11 15:43:39 +0300 ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5. 213631 28 mike 2022-08-11 21:44:36 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #27) > T/J/S -> 3.5. Благодарю; всё так же считаю (comment 26), что Игорь готов собирать пакеты в сизиф -- по крайней мере уже им собранные (libcglm уже требует обновления -- ftbfs, емнип, исправленный в текущей версии). 214972 29 glebfm 2022-09-16 13:26:20 +0300 Миша, ты забыл поменять статус. 214973 30 glebfm 2022-09-16 13:38:12 +0300 Призван рецензент (bircoph@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 214989 31 bircoph 2022-09-16 15:34:31 +0300 Добрый день! 1) libcglm: 1.1) Рекомендую использовать %define _unpackaged_files_terminate_build 1 в хедере spec. Не использование _не_ является ошибкой, но данный макрос поможет избегать неупакованных файлов при обновлении пакета. Значение по-умолчанию 0 позволяет легко исключать из установки ненужные файлы, но по моему опыту в целом даёт больше проблем, чем пользы (т.е. есть пакеты, где разумен 0, но большинству лучше будет от 1). 1.2) Апстрим предоставляет тесты (CGLM_USE_TEST), но пакет их не использует. Рекомендуется включать тесты в пакетах, если нет веской причины для обратного. Для этого в spec есть секция %check. 2) taisei: 2.1) аналогично 1.1) 2.2) некорректный формат %changelog, проблемы с этим заголовком: * Fri Mar 11 2022 Igor Molchanov <homura@altlinux.org> Не указана версия. \ac в vim ругается, да и сборочница сругнётся. Исправить легко, объединив содержимое со следующей записью для alt3. 2.3) Source в tar.xz — это неправильно, особенно для достаточно упитанного пакета. Следует использовать tar. А для сохранения точного апстримного URL можно использовать комментарий выше. 2.4) 056-debuginfo.brp: WARNING: You have 1 stripped ELF objects. Please compile with debugging information! 056-debuginfo.brp: WARNING: An excerpt from the list of affected files follows: ./usr/bin/taisei Нужно отключить strip для taisei, это легко делается. Дальше rpm-build сам выделит debuginfo в отдельный пакет. 2.5) Лицензия указана некорректно: там кроме MIT есть медиафайлы под CC-BY 4.0. 2.6) Документация ставится в неверсионированную директорию: /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо важная проблема, но лучше исправить. Итого: в целом работа кандидатом проделана аккуратно, но есть ряд досадных ошибок. Считаю, что прямо сейчас кандидат не готов к самостоятельной работе в Сизифе. Рекомендую исправить обнаруженные проблемы. 214990 32 glebfm 2022-09-16 15:37:57 +0300 (In reply to Andrew Savchenko from comment #31) > 056-debuginfo.brp: WARNING: You have 1 stripped ELF objects. Please compile > with debugging information! > 056-debuginfo.brp: WARNING: An excerpt from the list of affected files > follows: > ./usr/bin/taisei > > Нужно отключить strip для taisei, это легко делается. Дальше rpm-build сам > выделит debuginfo в отдельный пакет. Ещё можно добавлять в spec-и %define _stripped_files_terminate_build 1 тогда rpm в этом месте не только пожалуется. 217745 33 arbars 2022-11-21 22:34:49 +0300 (Ответ для Michael Shigorin на комментарий #28) > (Ответ для Gleb F-Malinovskiy на комментарий #27) > > T/J/S -> 3.5. > Благодарю; всё так же считаю (comment 26), что Игорь готов собирать пакеты в > сизиф -- по крайней мере уже им собранные (libcglm уже требует обновления -- > ftbfs, емнип, исправленный в текущей версии). Пакет возвращён в Сизиф и обновлён до текущей версии: git.altlinux.org/gears/l/libcglm.git 218070 34 Igor.A.Molchanov 2022-11-28 23:35:13 +0300 Ухх, прошу прощения за длительное отсутствие реакции, люто завалили работой, некогда было разбирать пакеты, только в последние пару недель-таки вернулся к этому. Итак: > 1) libcglm: Я правильно понимаю по comment 33, что это уже сделали и более неактуально? > 2.1) аналогично 1.1) Commit e0ab34a > 2.2) некорректный формат %changelog, проблемы с этим заголовком: > * Fri Mar 11 2022 Igor Molchanov <homura@altlinux.org> Commit 814dbd1 > 2.3) Source в tar.xz — это неправильно, особенно для достаточно упитанного > пакета. Commit a33e7f4 > 2.4) > Нужно отключить strip для taisei Commit c2cfec9 > 2.5) Лицензия указана некорректно: там кроме MIT есть медиафайлы под CC-BY > 4.0. Commit e2cf4e4 > 2.6) Документация ставится в неверсионированную директорию: > /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо > важная проблема, но лучше исправить. А вот тут вопрос неоднозначный. По-хорошему, тут надо тогда версионировать всё, что лежит в share, но с другой стороны, оно может меняться между релизами (то есть, бинарник тоже надо версионировать, получается?). Или это такая полиси (если да, то где она описана в вики? Я не видел) у альта - всё, что кладётся в /usr/share/doc, версионировать вне зависимости от целесообразности (а версионирование остального при этом не обязательно)? На самом деле, когда я заглянул туда, я увидел реально необычную картину - почти все каталоги с версией, в отличие от всех остальных операционных систем - проверил на Ubuntu 20.04.4 LTS (Focal Fossa), Debian GNU/Linux 11 (bullseye), Elbrus Linux 7.1, Astra Linux (Smolensk 1.5). Не, ну если это реально фишка альта, то я, конечно, сделаю. > Ещё можно добавлять в spec-и > %define _stripped_files_terminate_build 1 Commit 18b84bb 218796 35 bircoph 2022-12-12 21:19:37 +0300 (In reply to makise-homura from comment #34) > Ухх, прошу прощения за длительное отсутствие реакции, люто завалили работой, > некогда было разбирать пакеты, только в последние пару недель-таки вернулся > к этому. Все мы волонтеры в этом деле, так что ничего страшного. > Итак: > > > 1) libcglm: > Я правильно понимаю по comment 33, что это уже сделали и более неактуально? Там вернули пакет в Сизиф, но указанные замечания никто не исправлял. 1.1. — дело вкуса и хорошей, по моему мнению, практики А вот 1.2. никто не исправлял. > > 2.1) аналогично 1.1) > Commit e0ab34a > > > 2.2) некорректный формат %changelog, проблемы с этим заголовком: > > * Fri Mar 11 2022 Igor Molchanov <homura@altlinux.org> > Commit 814dbd1 > > > 2.3) Source в tar.xz — это неправильно, особенно для достаточно упитанного > > пакета. > Commit a33e7f4 > > > 2.4) > > Нужно отключить strip для taisei > Commit c2cfec9 > > > 2.5) Лицензия указана некорректно: там кроме MIT есть медиафайлы под CC-BY > > 4.0. > Commit e2cf4e4 Вс > > 2.6) Документация ставится в неверсионированную директорию: > > /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо > > важная проблема, но лучше исправить. > А вот тут вопрос неоднозначный. По-хорошему, тут надо тогда версионировать > всё, что лежит в share, но с другой стороны, оно может меняться между > релизами (то есть, бинарник тоже надо версионировать, получается?). Или это > такая полиси (если да, то где она описана в вики? Я не видел) у альта - всё, > что кладётся в /usr/share/doc, версионировать вне зависимости от > целесообразности (а версионирование остального при этом не обязательно)? На > самом деле, когда я заглянул туда, я увидел реально необычную картину - > почти все каталоги с версией, в отличие от всех остальных операционных > систем - проверил на Ubuntu 20.04.4 LTS (Focal Fossa), Debian GNU/Linux 11 > (bullseye), Elbrus Linux 7.1, Astra Linux (Smolensk 1.5). Не, ну если это > реально фишка альта, то я, конечно, сделаю. > > > Ещё можно добавлять в spec-и > > %define _stripped_files_terminate_build 1 > Commit 18b84bb 218797 36 bircoph 2022-12-12 21:21:10 +0300 Случайно отправил раньше, продолжаем. [Как же раздражает в багзилле, что tab+space = отправить] 2.1-2.5 = Всё хорошо. 218802 37 bircoph 2022-12-12 21:52:23 +0300 (In reply to makise-homura from comment #34) > > 2.6) Документация ставится в неверсионированную директорию: > > /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо > > важная проблема, но лучше исправить. > А вот тут вопрос неоднозначный. По-хорошему, тут надо тогда версионировать > всё, что лежит в share, но с другой стороны, оно может меняться между > релизами (то есть, бинарник тоже надо версионировать, получается?). Или это > такая полиси (если да, то где она описана в вики? Я не видел) у альта - всё, > что кладётся в /usr/share/doc, версионировать вне зависимости от > целесообразности (а версионирование остального при этом не обязательно)? На > самом деле, когда я заглянул туда, я увидел реально необычную картину - > почти все каталоги с версией, в отличие от всех остальных операционных > систем - проверил на Ubuntu 20.04.4 LTS (Focal Fossa), Debian GNU/Linux 11 > (bullseye), Elbrus Linux 7.1, Astra Linux (Smolensk 1.5). Не, ну если это > реально фишка альта, то я, конечно, сделаю. В Gentoo тоже всё с версиями в doc. Как по мне, это просто удобно — сразу видно на какую версию документация. Ну и в Gentoo в ряде случаев можно ставить две версии одного пакета. В Альте так нельзя, но может быть libfoo и libfoo2. В общем, прошу переделать, чтоб было как у (почти) всех в Альте. 218803 38 bircoph 2022-12-12 22:05:11 +0300 По совокупности проделанной работы считаю что homura@ (Игорь) готов к самостоятельной работе в Team. Мелочи можно доводить до блеска уже в ходе работы. 218804 39 ldv 2022-12-12 22:15:50 +0300 JFYI, (In reply to makise-homura from comment #34) > > 2.6) Документация ставится в неверсионированную директорию: > > /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо > > важная проблема, но лучше исправить. > А вот тут вопрос неоднозначный. По-хорошему, тут надо тогда версионировать > всё, что лежит в share, но с другой стороны, оно может меняться между > релизами (то есть, бинарник тоже надо версионировать, получается?). Или это > такая полиси (если да, то где она описана в вики? Я не видел) у альта - всё, > что кладётся в /usr/share/doc, версионировать вне зависимости от > целесообразности (а версионирование остального при этом не обязательно)? На > самом деле, когда я заглянул туда, я увидел реально необычную картину - > почти все каталоги с версией, в отличие от всех остальных операционных > систем - проверил на Ubuntu 20.04.4 LTS (Focal Fossa), Debian GNU/Linux 11 > (bullseye), Elbrus Linux 7.1, Astra Linux (Smolensk 1.5). Не, ну если это > реально фишка альта, то я, конечно, сделаю. Неверсионированные каталоги в /usr/share/doc - это традиция из Debian, версионированные каталоги в /usr/share/doc - это традиция из Red Hat, обе традиции из прошлого тысячелетия, у каждой есть свои преимущества. В ALT в /usr/share/doc преимущественно используются версионированные каталоги. 218913 40 glebfm 2022-12-15 09:06:37 +0300 Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства! 10136 2022-01-18 17:07:27 +0300 2022-02-01 16:58:52 +0300 ssh public key for homura@altlinux.org file_41734.txt text/plain 746 Igor.A.Molchanov c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFDQVFDK1FBTWVBUE4zcnlCTnZRK3Zs aFcyOU16K2RBOUpmN0NMWjJpQjZGQnZycy9KSEMxMmxUWjRIb0h3dFQ0aU51VVFNYmZxVWpSRGh2 M21nV3lkUncyUFhjWGNYTjZiMzVkSGNCcmRsTm5CMFgwQzl2NmZlQ0xIanlqWk4xWjE3TkkrZDlS VUhGRXhVdS94eGhCdnZlWWkweDIwRk5zZm5UODY2aURNUkJhRTB2bW5vNUN2elBpYmhKOGQ0RDdh N3czc0xnYUxWSG41eEZKTXZSQUoxaENreklTS2F6dWtnMEswSnY1SDVISDJZa2F6WDFHZlNOMzRU YmxSdUZTQlRZV251VWQ5L1lkR3dEZ3djcWFNS0pEVERLd3lnemxmRUE4aFE3VFBiT0w3QitUemx2 UzJvUU9RbUZmUVoyUXpLYnlFQkpLRzRUSU85S2U5VWxkNFl6eVJoZnUwblFaYmFwd21DZUJXN3FE dFBpbldUZnNKaFBsV2MrVzV4b3IwSDZKN3RVcWR6WVpud24vbW5vNE1zTFFJdXpIbWFZT0tVc3NF dklaaE4ySk9ROE9wN2JpU2t2bGorMERiYXZJazljRWhPMkREZ2NDbHFJQnhvNUxieVFGRzErRnpo S3dseXVPMnluZy9Sd09XcldHS2s0UWl5a01QU1dBTmJ1RmFUOTc3L2QwaTJLS01XbythQTZqQmpU QUlGVzR0NGZEWkNkQzZpRTBJa0RtNi9jcW4waHhubS9VN0pnZjdjeUVrTVcreENpZ0dqQ2hjM05I Z0hGbzZLRVBCckRiVDl0Tm95N2VKajlrbE1aTFh5M1luUklvc0tLVitldXZnMVd3ckJBUHdMT09z K0RuL3pBY3orTktrR1BQVzRiMUJ1bnVLblRZTkUrb2ZLcE5ac1E9PSBob211cmFAYWx0bGludXgu b3JnDQo= 10137 2022-01-18 17:12:07 +0300 2022-01-18 17:12:07 +0300 gpg public key for homura@altlinux.org file_41734.txt text/plain 3125 Igor.A.Molchanov LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQoNCm1RSU5CR0hscDZzQkVBRGE3 L3IwcVNsaUE5WUZWYnBWeVM0aHJhN2NhOGxsNzg5WFZIQkx0WlErN3JSaVZFcHcNCjNhMklLd0h6 Y2FVcWJOWVlZZ1o4RUI0Zy80Z0xDRFZkczlxUXV3N0d2S0FVQ0dJaVB6a2xzN2VDdjJlZnJYeWkN CnNMTTNWSDhjZWxCSGk4cnEyRW9xOEhRKzI2VC9teEgwZWZuTVlOcnhrb29UZStvMGlnbTZXK3Zv SWZiWkc0Vk8NCmtHeG4rU1kzYlZKQ3plNzg1VWpxQVdLRE05eC80ekhLUWtFaUpod1N5WnNtc1pn dDIzMG1oL1VxRnJ2ZWdqZXINCkV5dEloY0pIdGxycUgxSGJVSVZRYkxFeThNendraHV2OEphYUZa VlNIa3AxUXE4OVFRVnl1ay9PWVpsbDExMzUNCmNVWEtzbTZINjRhbWNvbUxpUzU0ZDF0U2puVFFx NGJEZnBzbWo3TlFWbHZTTTdaSWJJZ0Z6NXhTR1JCcklYUDQNCmlOemxIT1ViMFAxZ0NtWEVxTHpw cExKMURCdlJxWXVuN3RSaFFreWZzNWMzcStXZzVnVmFiVlF0ai9TVythaVcNCnRKQmJzNTJ5bUtW RU8yTmlrM3RJYlo0L2RtYjI5SE5FUUtNb2ViNDFkekNrTERWS093NEQ3Vm5sNURmVkRMTzYNCkln c3hKcjNiNG9JRHNWZHJaM1ZzeGtpK2htSWk2QW5nYmkrdGdkUDBxWU1ySjBxZC83UUtqWmN4OUUy R3hBWU8NCnl0OTV3cytJQTlLL3ZMaFJDekhSMkZ6RDV5OU5ibFVFMnMvU3kzdVNwYlJhOFo5V2V4 NlZWZVE4THlBUW96dlENCjlpV2E4TWNGWGhJakV0QUw2dW9PMDVLMVFyU0s2ZmJ0VFFwZW1NU3R4 UzRkK0NQOVpreFFxbWE0UlFBUkFRQUINCnRDUkpaMjl5SUUxdmJHTm9ZVzV2ZGlBOGFHOXRkWEpo UUdGc2RHeHBiblY0TG05eVp6NkpBamdFRXdFQ0FDSUYNCkFtSGxwNnNDR3dNR0N3a0lCd01DQmhV SUFna0tDd1FXQWdNQkFoNEJBaGVBQUFvSkVCVURETUE0QkJnd2RlMFENCkFMQ1Q2SGF5UnVPd1hN VGt0dll2NW1jUDRZdHZGMmZEWlBHTEZ2cmhObFpoQk1mSGUwRVZqaG9IeCtqZHE0U1UNCmFaM0Rw b25nMzJ1eXVoQXVWemx0Um5zdGRuWDhRMjlWWGl3UTdXbkQwcG9EakhmRmQ4ZTROcERnMlFELzll SzUNCnVlTVBYR2k3Yk81TDREeXBQeUwvekFGTyt5clBVekh3dFRUTmhIeERSQTJtYTFJNGV4aGZm QUFzYjFYbWRDZlUNCitvelliVmJHOGpMU2d3YUd6QnpyTllwR0QzcFBUVklCbEpvaGpVSnlFL3VK UXozOU5hUXF1cFBIY0JuRGdUcVMNCnFVZjM5UVVDUk9SU1I4OUNiVzB0KytkMk5oZHorUjFHRHJv QVE5TkFBNHJHdTVMV1Uva3QwOU84eG5hYTY1NUwNCjRMajZMNUJZbjdZbGFLcXRQYkNzZUxobEFl THlhL3hOSlJOdS9rUWtyaUdYWTlaM3ZzLzBPVVRQV3NyZ1ExYi8NClRZUnNhVUtEeXQzb20rVEhi WDlseHJjZWg1U2ZQZTg1VWRLektpWDNwTUdkWU9JS1Bxd1RWUHBDdFBRQVBrRlINCm5mRkNCMUdh T2lzK3dMemVOYU1RcmZqckswcmpveWJ5TmRUZ2ZUam1KR0tQalVSYWZCSGlYYXh3NE1Rc2dDMysN CjJQMDlZT0xOa29OYmtLd3VVcmZGUW1TeEdiU0ZjTE9DZng0MzcrZ2w1ZXBlSXdxZjFKdmdNdVhp V1RUQmVMeWsNCkk3bXlrQ0pHcUQ4WUIraGF6SzBEeHB4ZTZwWXBQbG53cEQydmFqTGhaUmY3Q2kr ZjlXRE1Dc3FYS3BWWkZvYS8NCnY2MGlqRWo0NUhsOVFqUDJBRUhJbndqQXBSSVZSaDJCenU4YWhM OXZDakJCdVFJTkJHSGxwNnNCRUFDd255SFoNCjZINXhjZ0t3L1d6djFBVVo1T0ZBcmFwSnc3c2Fj K041SFVINldxK3MrNFMwbHQzS1Qya1QvZWd0eG5qeStudXMNCnRRaW1qK2svM3Myb2VLVEtHUUFp Tm95NlQ1K0s3ZXlhOVZPRDNFTmVacUlDbHpJU3BtV2dvb3J4WUNnTE5ua2sNCjdVekxPdHlieTF6 dm51VkxKRE1EQ3d2OUwrdmxrMUNRS2MzT2p1Yjk1RnBLUHdDWmZZUDMyTGhMUXVCZHR3Z2YNCk9B VHkyeE9Cemk4UTl2emROM3VNNWllQWh0L3hoaHUvbkRUMm9mSjlzbC9YalNhb0FCejRJdzF2aGlx eERXUWENCjFTSzVDRUNVekpqV2VVVCtjNmtFODFOaWgrWmo1c2JEaEFQTkNWYlVBbCt3L1A4clcw Rm1HUU9hazBxTWlrTXANClA1VFBkY1Y3VkFNdENWTElHMUJta0NML1RDWmJPVGZnbEZuZDVMdHFZ SUh5ZEViQ0Y2Zjh6dFQ0VXMrVm5ZajkNCkxSNzRLN09Xb2ltT1lVNWR2akgzazN4NXN4Q0FQK3Q4 ZTQzQmIrd0Q1WlZTRGw4YS9nc3pSMkJxakFseGtPcXcNCnhwQWw3UnphOHZML0VPd3dQNFVZaC9j TXM4eWkyaERUcCtja1RpV1NmcG5SYkhhbFFram5LZ3lWWW9jZXhJdnYNCjVObW5jMWhpdmd0bDdR M0F4K0JldmhvR09NREN6ZW5YZWloeEdNOG11SFN2c1dlKzJma2tuQkJIQnZuNFlaNHMNCnlhR0c0 dW00cUoyT2hOY0JSTGpYTnlEUktWRlB2MkxTeGtTUW9IaDZZNmQ4S0ROVzJ3dzcrejVya2YzaEhj c1ANCnlEMFNWQjRLR2k2c3VETmhIZUsyNXlmNjZrQWZsK3pVdVhwWW93QVJBUUFCaVFJZkJCZ0JB Z0FKQlFKaDVhZXINCkFoc01BQW9KRUJVRERNQTRCQmd3WjNZUUFJcnRsQlFicHQxejFmeGtrWFFC NndEMTljOG9iem9QOWpRU0VzbVUNCmJyOUQ2RXdlSGtoSCtQOUdqT1JZRXNxd05xdXRXSGt1RE5G bHV2WjdqM3ROUnl5WElwdTdLaStHZ01VcW4ya1oNCnVaNVFtWXRFMDcvak0vVkI3SThBY09XcE80 YjRhLzZNSzczcUptbzcybmtaV3BKL255VkRNdHk0a1o1Ri9PbVINCnhRTHJNbGs2REk1NTcvMml3 Y2NrL0ZSZ2RqbXRHOUhoWE9hNkxxYmhTZytKa1MvblUyWGcxVGlscUwwQXptUlQNClRGWFlTemVK VW5ETDUwYmlFSTYvdWVaRXJ4U2ttNE12UFcvU1FMZ0ttdSs5WGRBQ09UY2pUekhyalNURG41am0N ClFMZkxIVzdlK0hYenY5S3hyd3FNdTFVWUtnaDRkeUtYZk9xSVlKZTFHM3NMeGVWaTVWYXk2alFq QWcvMVNma3ENCmM0VmlOMGUwNUNEWGtEZlViNEdLWjgwbzYvQlFIMm5EbEdDVnZGVlRHaS83cVp3 M29heWxFSWdOOHMvWTV1Q28NCkU5a0tkT2NvYWJNZEphV3VOWjlBcHRtVzBxdTZIWlJjOEg0a1p2 UllRQkFrQS9VSDhxY0tpcVBFaXBjMVFHRzgNCnlDMUtFekNId2o3bTkyRnhKdWdZWW0xaHlFMWVq RlFPUWtLaWUwQXlOWnB4eVBXdW10R2xZeXAyVzVzbXo1WVYNCkdmN3dHWm1wTGppZWFmVzI5QVpq YjgwZS9qSW9uRnI2Nzk0eWdVRzI3emVITmF3cU1sM0dBTXVEMkY1SFFqS0MNClFRSnVUbXcrYVUx NUtZL1FEU1BISWpDN0krdzh1eE5JLytqSWtVSytZWHNiYXl1bEpiL21wZ1oxMDNudzRMMXUNCmpx YkINCj1CMVQxDQotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQo= 10238 2022-02-01 16:58:52 +0300 2022-02-01 16:58:52 +0300 ssh public key for homura@altlinux.org with LF EOLs file_41734.txt text/plain 745 Igor.A.Molchanov c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFDQVFDK1FBTWVBUE4zcnlCTnZRK3Zs aFcyOU16K2RBOUpmN0NMWjJpQjZGQnZycy9KSEMxMmxUWjRIb0h3dFQ0aU51VVFNYmZxVWpSRGh2 M21nV3lkUncyUFhjWGNYTjZiMzVkSGNCcmRsTm5CMFgwQzl2NmZlQ0xIanlqWk4xWjE3TkkrZDlS VUhGRXhVdS94eGhCdnZlWWkweDIwRk5zZm5UODY2aURNUkJhRTB2bW5vNUN2elBpYmhKOGQ0RDdh N3czc0xnYUxWSG41eEZKTXZSQUoxaENreklTS2F6dWtnMEswSnY1SDVISDJZa2F6WDFHZlNOMzRU YmxSdUZTQlRZV251VWQ5L1lkR3dEZ3djcWFNS0pEVERLd3lnemxmRUE4aFE3VFBiT0w3QitUemx2 UzJvUU9RbUZmUVoyUXpLYnlFQkpLRzRUSU85S2U5VWxkNFl6eVJoZnUwblFaYmFwd21DZUJXN3FE dFBpbldUZnNKaFBsV2MrVzV4b3IwSDZKN3RVcWR6WVpud24vbW5vNE1zTFFJdXpIbWFZT0tVc3NF dklaaE4ySk9ROE9wN2JpU2t2bGorMERiYXZJazljRWhPMkREZ2NDbHFJQnhvNUxieVFGRzErRnpo S3dseXVPMnluZy9Sd09XcldHS2s0UWl5a01QU1dBTmJ1RmFUOTc3L2QwaTJLS01XbythQTZqQmpU QUlGVzR0NGZEWkNkQzZpRTBJa0RtNi9jcW4waHhubS9VN0pnZjdjeUVrTVcreENpZ0dqQ2hjM05I Z0hGbzZLRVBCckRiVDl0Tm95N2VKajlrbE1aTFh5M1luUklvc0tLVitldXZnMVd3ckJBUHdMT09z K0RuL3pBY3orTktrR1BQVzRiMUJ1bnVLblRZTkUrb2ZLcE5ac1E9PSBob211cmFAYWx0bGludXgu b3JnCg== 10263 2022-02-08 19:58:57 +0300 2022-02-08 19:58:57 +0300 spec for Taisei Project v.1.3.2 taisei.spec text/plain 1433 Igor.A.Molchanov TmFtZTogdGFpc2VpClZlcnNpb246IDEuMy4yClJlbGVhc2U6IGFsdDEKClN1bW1hcnk6IFRhaXNl aSBQcm9qZWN0IGlzIGZyZWUgYW5kIG9wZW4tc291cmNlIFRvdWhvdSBQcm9qZWN0IGZhbmdhbWUK TGljZW5zZTogTUlUCkdyb3VwOiBHYW1lcy9BcmNhZGUKClVybDogaHR0cHM6Ly90YWlzZWktcHJv amVjdC5vcmcvClNvdXJjZTogaHR0cHM6Ly9naXRodWIuY29tL3RhaXNlaS1wcm9qZWN0L3RhaXNl aS9yZWxlYXNlcy9kb3dubG9hZC92JXZlcnNpb24vJW5hbWUtdiV2ZXJzaW9uLnRhci54egoKQnVp bGRSZXF1aXJlczogbWVzb24KQnVpbGRSZXF1aXJlczogbGliY2dsbS1kZXZlbApCdWlsZFJlcXVp cmVzOiBsaWJvcHVzZmlsZS1kZXZlbApCdWlsZFJlcXVpcmVzOiBsaWJzc2wtZGV2ZWwKQnVpbGRS ZXF1aXJlczogbGliZnJlZXR5cGUtZGV2ZWwKQnVpbGRSZXF1aXJlczogbGlicG5nLWRldmVsCkJ1 aWxkUmVxdWlyZXM6IGxpYlNETDJfbWl4ZXItZGV2ZWwKQnVpbGRSZXF1aXJlczogbGlid2VicC1k ZXZlbApCdWlsZFJlcXVpcmVzOiBsaWJ6aXAtZGV2ZWwKQnVpbGRSZXF1aXJlczogbGliZ2FtZW1v ZGUtZGV2ZWwKQnVpbGRSZXF1aXJlczogcHl0aG9uLW1vZHVsZS1kb2N1dGlscwoKUmVxdWlyZXM6 IGxpYmdhbWVtb2RlMAoKJWRlc2NyaXB0aW9uClRhaXNlaSBQcm9qZWN0IGlzIGFuIG9wZW4gc291 cmNlIGZhbi1nYW1lIHNldCBpbiB0aGUgd29ybGQgb2YgVG91aG91IFByb2plY3QuCkl0IGlzIGEg dG9wLWRvd24gdmVydGljYWwtc2Nyb2xsaW5nIGN1cnRhaW4gZmlyZSBzaG9vdGluZyBnYW1lIChT VEcpLAphbHNvIGtub3duIGFzIGEgImJ1bGxldCBoZWxsIiBvciAiZGFubWFrdS4iIFNUR3MgYXJl IGZhc3QtcGFjZWQgZ2FtZXMKZm9jdXNlZCBhcm91bmQgcGF0dGVybiByZWNvZ25pdGlvbiBhbmQg bWFzdGVyeSB0aHJvdWdoIHByYWN0aWNlLgoKJXByZXAKJXNldHVwIC1uICV7bmFtZX0tdiV7dmVy c2lvbn0KCiVidWlsZAolbWVzb24gLUR2YWxpZGF0ZV9nbHNsPWZhbHNlIC1EdmVyc2lvbl9mYWxs YmFjaz12JXZlcnNpb24KJW1lc29uX2J1aWxkCgolaW5zdGFsbAolbWVzb25faW5zdGFsbAoKJWZp bGVzCiVfYmluZGlyLyVuYW1lCiVfZGF0YWRpci8lbmFtZS8qCiVfZG9jZGlyLyVuYW1lLyoKJV9k ZXNrdG9wZGlyLyVuYW1lLmRlc2t0b3AKJV9pY29uc2Rpci9oaWNvbG9yLzEyOHgxMjgvYXBwcy8l bmFtZS5wbmcKJV9kZXNrdG9wZGlyLyVuYW1lLXJlcGxheS12aWV3ZXIuZGVza3RvcAolX2ljb25z ZGlyL2hpY29sb3IvMjU2eDI1Ni9taW1ldHlwZXMvJW5hbWUtcmVwbGF5LnBuZwolX2RhdGFkaXIv bWltZS9wYWNrYWdlcy8lbmFtZS54bWwKCiVjaGFuZ2Vsb2cKKiBGcmkgSmFuIDE0IDIwMjIgSWdv ciBNb2xjaGFub3YgPGFrZW1pX2hvbXVyYUBrdXJpc2EuY2g+IDEuMy4yLWFsdDEKLSBJbml0aWFs IGJ1aWxkLgo=