Bug 37945
| Summary: | [done] join svn17@ | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Team Accounts | Reporter: | Иван Савин <svn17> | ||||||||
| Component: | join | Assignee: | Gleb F-Malinovskiy <glebfm> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | Andrey Cherepanov <cas> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P5 | CC: | darktemplar, darktemplaralt, gkot, glebfm, grenka, iv, ldv, mike, sin | ||||||||
| Version: | unspecified | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| URL: | https://www.altlinux.org/Team/Join/Secretary | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 8546 [details]
Публичный GPG-ключ
Подтверждаю заявку. На текущий момент в минимальном объёме сборка пакетов освоена. Прошу представить примеры пакетов. https://github.com/ichtrnemo/local-policy Исправлен файл default/local.xml Данное исправление запускает gpupdate при старте системы. > Ник : iv17
Не будет ли легко перепутать ник с iv@?
Добавил iv@ в подписчики, чтобы поставить его в известность. Полагаю, что перепутать наши ники будет не просто. (In reply to Савин Иван from comment #5) > Добавил iv@ в подписчики, чтобы поставить его в известность. > Полагаю, что перепутать наши ники будет не просто. Ваня единственный член тим про которого я не волнуюсь, что он перепутает. Все кого я спрашиваю говорят, что это плохая идея. Тут ещё такой прикладной момент, что можно где-нить tab'ить iv17 и не заметить, что дотабил только до iv... у меня такое впопыхах бывало с mik/mike и в каких-то похожих случаях. Но мне кажется, что это пожелание/предупреждение, а не полиси. Ясно. Исправлю. > Все кого я спрашиваю говорят, что это плохая идея. Вы уж извините, но я считаю, что моё мнение должно тут присутствовать, потому что меня не спросили, а я бы ответил, что это не такая уж и плохая идея. Как правильно заметил mike@, у нас нет полиси по созданию ников. >> псевдоним (имя пользователя) участника, выбирается им самим. Имя должно начинаться с буквы, содержать только буквы и цифры и быть не короче трёх символов. Если уж на то пошло, то давайте заставлять iv@ менять свой ник. iv17@ в этом плане прекрасный ник, удовлетворяющий всем требованиям. Просто со стороны это может выглядеть, как "Извини, я не хочу чтобы у тебя был такой ник". Если уж на то пошло, то пусть те члены тим, которые против, напишут тут своё мнение, если им это важно=) Created attachment 8623 [details] новый публичный gpg ключ ник: svn17 почта: svn17@altlinux.org ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 3.0. Готово два пакета. Простой акселератор компилятора, который кэширует и повторно использует результаты сборки: 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 Сборка пакетов воспроизведена. Пакеты buildcache и gcc-common рабочие - подтверждаю. Замечания: - в репозиториях нет ветки по умолчанию (попробуйте склонировать собственные репозитории); - для исправления используйте команду ssh gitery default-branch; - нужно определиться с thirdparty на борту buildcache - можно ли (имеет ли смысл?) от каких-то из них избавиться? В оба репозитория добавил ветку по умолчанию (sisyphus). thirdparty на борту buildcache: я бы оставил, думаю, поддержка пакета будет проще. Они маленькие, 4,6М. Есть ещё пара пакетов. Модуль alterator'a для обновления ядра: http://git.altlinux.org/people/svn17/packages/alterator-update-kernel.git Перевод для данного модуля: http://git.altlinux.org/people/svn17/packages/alterator-l10n.git Думаю нужно на чём-то остановится и собрать в таску buildcache. Предлагаю перейти в следующему шагу. Хорошо, buildcache. Нужен доступ к сборочнице. Мне нужен доступ к сборочнице чтобы продолжить gpg: Can't check signature: public key not found task add: 0.18.0-alt1: tag signature verification failure Пакет alt-gpgkeys обновлён. T/J/S -> 4.0. Пакеты buildcache и gcc-common собрались. http://git.altlinux.org/tasks/261639/ (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. Если нет причины избегать использования системных библиотек, то следует не использовать забандленные. В gcc_wrapper.c исправил комментарий. В строке в %changelog'е добавил точку в конце. (gcc-common) В buildcache.spec исправил лицензию. Забандленные библиотеки (zstd, lz4, lua, hiredis) заменил на системные. Пакеты buildcache и gcc-common собрались. http://git.altlinux.org/tasks/262033/ (In reply to Иван Савин from comment #22) > В gcc_wrapper.c исправил комментарий. > В строке в %changelog'е добавил точку в конце. (gcc-common) По gcc-common у меня больше вопросов нет, готов одобрить это сборку, если нужно. (Ответ для Dmitry V. Levin на комментарий #23) > По gcc-common у меня больше вопросов нет, готов одобрить это сборку, если > нужно. Да, давайте одобрим эту таску. Можно ли считать, что join завёршён? Я со своей стороны считаю, что да. У нас есть ещё одно исправление для alterator-auth. (In reply to Иван Савин from comment #22) > В buildcache.spec исправил лицензию. > Забандленные библиотеки (zstd, lz4, lua, hiredis) заменил на системные. За это время вышло несколько более новых версий buildcache. Я предлагаю попробовать собрать самую свежую, а заодно потренироваться не терять изменения, сделанные в пакете, в результате обновления версии. Собрал самую свежую версию buildcache (0.23.0): http://git.altlinux.org/people/svn17/packages/?p=buildcache.git;a=summary (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? (Ответ для 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'е так пытались повысить производительность. (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 (Ответ для Dmitry V. Levin на комментарий #29) > Интересно, у меня такого в /usr/include/xxhash.h нет: Да, извиняюсь, это я на Р9 собирал. На sisyphus'е всё собралось. http://git.altlinux.org/people/svn17/packages/?p=buildcache.git;a=summary (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. (Ответ для Dmitry V. Levin на комментарий #31) Исправил опечатку в commit message и %changelog. Собирал gcc-common-1.4.27-alt1. (Ответ для Иван Савин на комментарий #32) > (Ответ для Dmitry V. Levin на комментарий #31) > Исправил опечатку в commit message и %changelog. > > Собирал gcc-common-1.4.27-alt1. Собрал) (In reply to Иван Савин from comment #32) > (Ответ для Dmitry V. Levin на комментарий #31) > Исправил опечатку в commit message и %changelog. > > Собрал gcc-common-1.4.27-alt1. Approved. Я думаю, что это задание уже можно отправлять в Сизиф. Задание в Сизифе. У меня вопрос к ментору, есть ли ещё задания для кандидата? (Ответ для Dmitry V. Levin на комментарий #35) > Задание в Сизифе. > У меня вопрос к ментору, есть ли ещё задания для кандидата? В целом, я думаю, что опыт и навыки проявлены. Но задачи накопились: - исправление alterator-auth; - исправление polkit. Оба решения подготовлены, предлагаю их рассмотреть. 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. Всё собралось. merge-request в апстрим polkit https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/71 В 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) (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: если с этим заданием всё в порядке, то почему бы его не заапрувить? (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. Одно предложения разбито на несколько строк, это понятно, но почему все эти строки начинаются со знака минус? (Ответ для Dmitry V. Levin на комментарий #42) > У меня вопросы по оформлению %changelog: > 1. Насколько я понимаю, эта сборка закрывает > https://bugzilla.altlinux.org/show_bug.cgi?id=39420; в таком случае в > %changelog следует внести соответствующую запись, чтобы этот баг > автоматически закрылся при попадании сборки пакета в Сизиф. > 2. Одно предложения разбито на несколько строк, это понятно, но почему все > эти строки начинаются со знака минус? Убрал минусы, добавил (closes: 39420) в changelog. (Ответ для Иван Савин на комментарий #43) > Убрал минусы, добавил (closes: 39420) в changelog. Это было сделано для другой ветки, извиняюсь. Проделал эти же исправления для sisyphus. Готов ещё один пакет, модуль альтератора для обновления ядра: http://git.altlinux.org/people/svn17/packages/?p=alterator-update-kernel.git;a=summary Учитывая, что buildcache уже в сизифе (кстати, вышла новая версия v0.25.2 - думаю обновлением может заняться кто-то другой, заодно gear-remotes добавить для отслеживания), а также alterator-update-kernel, собранный вместе с кодом с нуля (тут ещё есть замечания), можно считать, что сборка освоена. В пакете alterator-update-kernel следует добавить более полное описание в секцию %description, но это скорее детали. Доделал 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 Дополнил описание в секции %description. Считаю, что со сборкой пакетов 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 Призван ещё один человек (darktemplar@) для независимой оценки готовности кандидата. Замечания по 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) Прошу посмотреть это предупреждение, на какие проблемы оно может указывать, и поправить что можно. По другим пакетам замечаний нет. Указанные выше замечания не считаю достаточно критичными, чтобы блокировать завершение вступления, хотя было бы хорошо и их расммотреть. С учётом всего этого считаю, что кандидат готов. Давайте по частям: (Ответ для 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. Хорошо. (Ответ для Evgeny Sinelnikov на комментарий #52) > Поправить тут можно только вот это: > > /usr/lib/alterator/ui/update-kernel > > /usr/lib/alterator/ui/update-kernel/update > > Тут всё ясно. > Всё верно. > А вот "мне говорили, что тэг "Packager:" deprecated и его не стоит > указывать." - это, как требование, выглядит странно. Я давно его не > указываю, но в куче примеров он имеется. Если бы сборка с ним отваливалась > по sisyphus_check, то я бы согласился с тем, что это замечание имеет > серьёзную силу. > Давайте это "пожелание" как-то формализуем. Да, согласен, назвать это "пожеланием" будет точнее. (Ответ для 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. (Ответ для 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, хотя причины там возможно и другие. (In reply to Evgeny Sinelnikov from comment #54) > Про exclude для diff даже я не в курсе - как-то мимо прошло. Какую рассылку > я пропустил? Какая часть документации на этот счёт поправлена? man gear-rules(5) Вики, конечно, неплохо бы пополнить. (Ответ для Ivan A. Melnikov на комментарий #56) > (In reply to Evgeny Sinelnikov from comment #54) > > Про exclude для diff даже я не в курсе - как-то мимо прошло. Какую рассылку > > я пропустил? Какая часть документации на этот счёт поправлена? > > man gear-rules(5) > > Вики, конечно, неплохо бы пополнить. А когда обновление можно ожидать в p9? Или как иначе предлагается разработчику их получить? Лично я пока не рассчитываю, на обновление до сизифа на рабочей машине. Можно собрать весь инструментарий локально. Но как-то не хотелось бы это многократно выполнять на разных машинах множеству разных людей. (In reply to Aleksei Nikiforov from comment #51) > С учётом всего этого считаю, что кандидат готов. Адрес подписан на список рассылки devel@. Пользователь добавлен в группу мантейнеров. Желаю удачного мантейнерства! |
Description
Иван Савин 2020-01-28 13:34:09 MSK