Bug 41044
| Summary: | [done] join liannnix@ | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Team Accounts | Reporter: | Andrey Limachko <liannnix> | ||||||
| Component: | join | Assignee: | Gleb F-Malinovskiy <glebfm> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Andrey Cherepanov <cas> | ||||||
| Severity: | normal | ||||||||
| Priority: | P5 | CC: | andy, glebfm, ldv, liannnix, liannnix, nir, nir, obirvalger, rider, shaba, sin | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86 | ||||||||
| OS: | Linux | ||||||||
| URL: | https://www.altlinux.org/Team/Join | ||||||||
| Attachments: |
|
||||||||
Извиняюсь за ошибку Ментор: Игорь Чудов nir@altliux.org Created attachment 9760 [details]
GPG public key
Created attachment 9761 [details]
SSH public key
Менторство подтверждаю. ПО для затаскивания в дистрибутив выглядит полезным, затащить стоит. Собрал пакет Monitorix и выложил на Github https://github.com/liannnix/monitorix.git (In reply to Andrey Limachko from comment #2) > Created attachment 9760 [details] > GPG public key Ok. (In reply to Andrey Limachko from comment #3) > Created attachment 9761 [details] > SSH public key Ok. Изменения проверил, мне всё нравится, но я бы предложил из файла `rules` убрать комментарий и явно указывать требуемые патчи по принципу "явное лучше неявного". Чтобы в случае потери патча можно было это лего обнаружить. Предлагаю продвинуть кандидата дальше по процедуре Join. Исправил несколько ошибок и внес пару дополнений в пакет cloud-init. Сорцы пакета брал отсюда: http://git.altlinux.org/gears/c/cloud-init.git Мой форк: https://github.com/liannnix/cloud-init Начиная с версии p10 21.3-alt1 в cloud-init поменялся механизм работы с renderers (реализации генерации конфигов для разных сетевых менеджеров, т.е. etcnet, networkd), а так же добавился отдельный механизм применения прописанных настроек к системе. В следствии этого отвалилась поддержка etcnet. На данный момент у нас в облачных образах используется etcnet, потому я сделал ряд исправлений. В частности: * Cloud-init по умолчанию использует netplan, который использует networkd (теперь это явно прописано в cloud.cfg) * Если установить пакет cloud-init-config-etcnet, то будет использоваться etcnet * Соответственно, если поставить cloud-init-config-netplan, то используется netplan и networkd. * Пакеты конфликтуют с друг другом, потому, на мой взгляд, это неплохой вариант переключения между тем или иным способом. Хотелось бы увидеть мои исправления в Сизифе, а желательно и в p10. Подскажите, если я что-то сделал неправильно. Changelog: * Mon Nov 22 2021 Andrey Limachko <liannnix@altlinux.org> 21.4-alt2 - When using sudo add user to the wheel group - Add DHCP interface configuration support for etcnet - Add config-etcnet package for etcnet render - Add Requires and Conflicts for config subpackages - Set netplan network renderer to default - Add etcnet activator and activator cfg variable К текущей версии пакета cloud-init на github у меня нет вопросов, я готов одобрить пакет. Кандидат же уже может отправлять пакеты в сборочницу? ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. Сделал push для репозитория cloud-init git://git.altlinux.org/people/liannnix/packages/cloud-init.git Создал в нем подписанный тэг 21.4-alt2. Жду доступа в gyle Добрый день. Коллеги, дайте, пожалуйста, Андрею доступ к gyle. Он аккуратный и внимательный. Вполне способен пользоваться инструментом. Поправил и залил на gitery репозиторий с Monitorix git://git.altlinux.org/people/liannnix/packages/monitorix.git Тэг 3.13.1-alt1 Реализовал bash completion для control git://git.altlinux.org/people/liannnix/packages/control.git Жду доступ к gyle ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5. Поправленный мною cloud-init приняли в sisyphus и p10 Собрал приложение tayga для NAT64 в userspace #298277 EPERM #1 sisyphus tayga.git=0.9.2-alt2 Исправил ошибки в opennebula-context #297926 EPERM #1 sisyphus opennebula-context.git=5.10.0-alt2 Обновил пакет python3-module-hyperlink #292328 EPERM #2 sisyphus python3-module-hyperlink.git=21.0.0-alt1 Собрал несколько связанных пакетов для ntopng. Не уверен, насколько правильно это сделал. Буду рад дельному совету. #293030 TESTED #1 [test-only] sisyphus kernel-source-pf_ring.git=8.0.0-alt1 kernel-modules-pf_ring.git=sisyphus/kernel-modules-pf_ring-un-def-8.0.0-alt1 libpfring.git=8.0.0-alt3 nDPI.git=4.0-alt1 ntopng.git=5.0-alt1 (Ответ для Andrey Limachko на комментарий #18) > Исправил ошибки в opennebula-context > #297926 EPERM #1 sisyphus opennebula-context.git=5.10.0-alt2 Не совсем понял зачем это править. Я еще понял бы если добавлять префикс "10-" или что-то подобное, но префикс "alterator-" мне совсем не нравится. Это в альтераторе такое придумали? Если не нравится имя файла, лучше альтератор поправить. В systemd-networkd нет ограничений по имени файла, как в других системах(etcnet и др.), с одной стороны хорошо, с другой не очень. (Ответ для Alexey Shabalin на комментарий #19) > (Ответ для Andrey Limachko на комментарий #18) > > Исправил ошибки в opennebula-context > > #297926 EPERM #1 sisyphus opennebula-context.git=5.10.0-alt2 > > Не совсем понял зачем это править. > Я еще понял бы если добавлять префикс "10-" или что-то подобное, но префикс > "alterator-" мне совсем не нравится. Это в альтераторе такое придумали? > Если не нравится имя файла, лучше альтератор поправить. > В systemd-networkd нет ограничений по имени файла, как в других > системах(etcnet и др.), с одной стороны хорошо, с другой не очень. Я исходил из того, что alterator - это системный инструмент, лежащий в основе ОС. Вносить в него правки, значит затрагивать много всего уже работающего и потенциально нарываться на кучу регрессий. one-context же в этом плане не настолько важен. Не спорю, alterator-iface выглядит не очень хорошо, но, мне кажется, это тема для отдельного обсуждения. one-context же можно поправить и на ходу. Согласно https://www.altlinux.org/Team/Join/Secretary , 3.5: Кандидат готов отправлять пакеты в Сизиф. 4.1: Кросс-ревьювером вызвался ранее выступить rider@. Призван ещё один человек (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2. Смотрю наиболее свежий из собираемых пакетов tayga. В этом коммите есть явная ошибка: https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=commitdiff;h=5c207745fa263f30c559577bf0a08a6b00f02ec7 В rules зачем-то указан spec, который расположен по стандартному пути: https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=blob;f=.gear/rules;h=d9b9b8c3ffad5414ec64e85f30c2736a81d02100;hb=sisyphus Такая же ситуация с rules в другом проекте: https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=tree;h=5f8cf63934fc202a7114bea2aac8d808f63aa9a2;hb=5f8cf63934fc202a7114bea2aac8d808f63aa9a2 плюс specfile лежит в корне, что в дальнейшем может создать проблему, если апстрим проекта решит добавить свой спек. лучше всё альтовое держать в одном меcте, например в каталоге .gear в specfile указан Packager - лучше этого не делать, оставляя выбор поля Packager на усмотрение сборочницы (кто последний собирал, тот и указан в Packager) https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=blob;f=ntopng.spec;h=132c07ef30955d67b7b07d2e2e23c974e56ecc0b;hb=5f8cf63934fc202a7114bea2aac8d808f63aa9a2#l11 В зависимостях пакета указаны вручную библиотеки - этого обычно делать не нужно, а если и требуется, то в крайне редких случаях. Хотелось бы понять, на основании чего был сделан вывод о том, что данные зависимости надо указать: https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=blob;f=ntopng.spec;h=132c07ef30955d67b7b07d2e2e23c974e56ecc0b;hb=5f8cf63934fc202a7114bea2aac8d808f63aa9a2#l37 В этом коммите https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=commitdiff;h=45436c0f1ec57bd690243f1eed61a50606d416e4 зачем-то вместо @MAN_DIR@ хардкодится путь Там же в сервисе b/altlinux/ntopng@.service есть ошибка Плюс в патче есть изменения, которые можно не делать. Над пакетом требуется ещё поработать. Пока что ментейнер не готов. (Ответ для Anton Farygin на комментарий #24) > Смотрю наиболее свежий из собираемых пакетов tayga. > В этом коммите есть явная ошибка: > https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=commitdiff; > h=5c207745fa263f30c559577bf0a08a6b00f02ec7 Подскажите, в чём ошибка? Как я понял, вы имеете ввиду mkdir. Добавил из безисходности. Изначально хотел организовать хранение pid'а в отдельной директории /var/run/tayga, но после перезагрузки эта директория удаляется. Не могу понять - почему. Есть множество других пакетов, в которых такой вариант работает. Например nscd или pptp-client. В spec файле прописывается папка /var/run/<app> и вполне спокойно сохраняется после перезагрузки. Подскажите, пожалуйста, возможно я что-то упустил? > В rules зачем-то указан spec, который расположен по стандартному пути: > https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=blob;f=. > gear/rules;h=d9b9b8c3ffad5414ec64e85f30c2736a81d02100;hb=sisyphus > > > Такая же ситуация с rules в другом проекте: > https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=tree; > h=5f8cf63934fc202a7114bea2aac8d808f63aa9a2; > hb=5f8cf63934fc202a7114bea2aac8d808f63aa9a2 > > плюс specfile лежит в корне, что в дальнейшем может создать проблему, если > апстрим проекта решит добавить свой спек. лучше всё альтовое держать в одном > меcте, например в каталоге .gear Подумал, что не имеет значения, где хранить spec. Видел примеры пакетов, где spec лежит в директориии .gear, alt или, как у меня, просто в корне. Исправлю > в specfile указан Packager - лучше этого не делать, оставляя выбор поля > Packager на усмотрение сборочницы (кто последний собирал, тот и указан в > Packager) > https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=blob; > f=ntopng.spec;h=132c07ef30955d67b7b07d2e2e23c974e56ecc0b; > hb=5f8cf63934fc202a7114bea2aac8d808f63aa9a2#l11 Исправлю. > В зависимостях пакета указаны вручную библиотеки - этого обычно делать не > нужно, а если и требуется, то в крайне редких случаях. Хотелось бы понять, > на основании чего был сделан вывод о том, что данные зависимости надо > указать: > https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=blob; > f=ntopng.spec;h=132c07ef30955d67b7b07d2e2e23c974e56ecc0b; > hb=5f8cf63934fc202a7114bea2aac8d808f63aa9a2#l37 Ntopng до конца не доработан. Это мой личный интерес. Когда понял, что доработка требует слишком много времени, то отодвинул на второй план. На сколько помню, большинство зависимостей там действительно лишние, за исключением BuildRequires: libpfring-pcap-devel BuildRequires: libnDPI-devel BuildRequires: libnDPI-static Requires: GeoLite2-ASN Requires: GeoLite2-City Requires: GeoLite2-Country > В этом коммите > https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=commitdiff; > h=45436c0f1ec57bd690243f1eed61a50606d416e4 > > зачем-то вместо @MAN_DIR@ хардкодится путь > > Там же в сервисе b/altlinux/ntopng@.service есть ошибка > > Плюс в патче есть изменения, которые можно не делать. Главная проблема, с которой я столкнулся в ntopng - это возможность использования им библиотеки libpfring, связанного с ней модуля ядра и модифицированной libpcap. Ntopng позволяет мониторить весь проходящий через выбранные интерфейсы трафик. Делает он это с использованием libpcap в стандартном варианте. Разработчики решили, что этого не достаточно и разработали комплекс софта для реализации DPI. В него входит модуль ядра pf_ring для прямой обработки и модификации сетевых пакетов, библиотека libpfring для работы с модулем и модифицированный libpcap для универсального интерфейса взаимодействия. В итоге, получается два варианта сборки ntopng. C модифицированной libpcap и с ванильной. Плюс ntopng ещё использует для анализа пакетов свою собственную библиотеку libnDPI. Как я понял, у неё тоже есть вожможность взаимодействия с модифицированной libpcap. Используется ил она в ntopng - не разобрался. > Над пакетом требуется ещё поработать. Пока что ментейнер не готов. В Сизиф группу пкетов ntopng я и не собирался отправлять в таком виде. (Ответ для Andrey Limachko на комментарий #25) > (Ответ для Anton Farygin на комментарий #24) > > Смотрю наиболее свежий из собираемых пакетов tayga. > > В этом коммите есть явная ошибка: > > https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=commitdiff; > > h=5c207745fa263f30c559577bf0a08a6b00f02ec7 > > Подскажите, в чём ошибка? Как я понял, вы имеете ввиду mkdir. > Добавил из безисходности. > Изначально хотел организовать хранение pid'а в отдельной директории > /var/run/tayga, но после перезагрузки эта директория удаляется. Не могу > понять - почему. Есть множество других пакетов, в которых такой вариант > работает. Например nscd или pptp-client. В spec файле прописывается папка > /var/run/<app> и вполне спокойно сохраняется после перезагрузки. > Подскажите, пожалуйста, возможно я что-то упустил? Посмотрите информацию про /etc/tmpfiles.d и примеры его использования в разных пакетах (например в chrony) > > > В rules зачем-то указан spec, который расположен по стандартному пути: > > https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=blob;f=. > > gear/rules;h=d9b9b8c3ffad5414ec64e85f30c2736a81d02100;hb=sisyphus > > > > > > Такая же ситуация с rules в другом проекте: > > https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=tree; > > h=5f8cf63934fc202a7114bea2aac8d808f63aa9a2; > > hb=5f8cf63934fc202a7114bea2aac8d808f63aa9a2 > > > > плюс specfile лежит в корне, что в дальнейшем может создать проблему, если > > апстрим проекта решит добавить свой спек. лучше всё альтовое держать в одном > > меcте, например в каталоге .gear > > Подумал, что не имеет значения, где хранить spec. Видел примеры пакетов, где > spec лежит в директориии .gear, alt или, как у меня, просто в корне. > Исправлю Действительно место определения хранения spec'а определяет ментейнер, но некоторые нюансы могут выясниться только в процессе длительного жизненного цикла проекта. Спасибо. > > В зависимостях пакета указаны вручную библиотеки - этого обычно делать не > > нужно, а если и требуется, то в крайне редких случаях. Хотелось бы понять, > > на основании чего был сделан вывод о том, что данные зависимости надо > > указать: > > https://git.altlinux.org/people/liannnix/packages/?p=ntopng.git;a=blob; > > f=ntopng.spec;h=132c07ef30955d67b7b07d2e2e23c974e56ecc0b; > > hb=5f8cf63934fc202a7114bea2aac8d808f63aa9a2#l37 > > Ntopng до конца не доработан. Это мой личный интерес. Когда понял, что > доработка требует слишком много времени, то отодвинул на второй план. На > сколько помню, большинство зависимостей там действительно лишние, за > исключением > BuildRequires: libpfring-pcap-devel > BuildRequires: libnDPI-devel > BuildRequires: libnDPI-static > Requires: GeoLite2-ASN > Requires: GeoLite2-City > Requires: GeoLite2-Country Скажите, какие проекты в ваших репозиториях уже на 100% доработаны, я буду смотреть их. > Ntopng позволяет мониторить весь проходящий через выбранные интерфейсы > трафик. Делает он это с использованием libpcap в стандартном варианте. > Разработчики решили, что этого не достаточно и разработали комплекс софта > для реализации DPI. В него входит модуль ядра pf_ring для прямой обработки и > модификации сетевых пакетов, библиотека libpfring для работы с модулем и > модифицированный libpcap для универсального интерфейса взаимодействия. > > В итоге, получается два варианта сборки ntopng. C модифицированной libpcap и > с ванильной. Плюс ntopng ещё использует для анализа пакетов свою собственную > библиотеку libnDPI. Как я понял, у неё тоже есть вожможность взаимодействия > с модифицированной libpcap. Используется ил она в ntopng - не разобрался. > > > Над пакетом требуется ещё поработать. Пока что ментейнер не готов. > > В Сизиф группу пкетов ntopng я и не собирался отправлять в таком виде. предлагаю доработать, проект тяжёлый с точки зрения сборки и можно разобраться с большим количеством разных нюансов упаковки библиотек. (In reply to Anton Farygin from comment #26) > Посмотрите информацию про /etc/tmpfiles.d и примеры его использования в > разных пакетах (например в chrony) На самом деле /lib/tmpfiles.d Спасибо, действительно /lib/tmpfiles.d Исправил пакет tayga: * Перенес spec в .gear * Исправил tayga.service * Добавил конфиг для tpmfiles.d https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=log;h=refs/tags/0.9.2-alt3 #300491 TESTED #1 [test-only] p10 tayga.git=0.9.2-alt3 Подскажите, пожалуйста, есть ли смысл переносить tayga.service в директорию .gear? Изначально в исходниках его не было. Нужно ли добавлять поддержку sysvinit? Поправил пакет monitorix. https://git.altlinux.org/people/liannnix/packages/?p=monitorix.git;a=shortlog;h=refs/tags/3.14.0-alt1 #300510 TESTED #1 [test-only] p10 monitorix.git=3.14.0-alt1 Впринципе monitorix и tayga, на мой взгляд, готовые пакеты. (Ответ для Andrey Limachko на комментарий #29) > Исправил пакет tayga: > * Перенес spec в .gear > * Исправил tayga.service > * Добавил конфиг для tpmfiles.d > https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=log;h=refs/ > tags/0.9.2-alt3 > #300491 TESTED #1 [test-only] p10 tayga.git=0.9.2-alt3 > > Подскажите, пожалуйста, есть ли смысл переносить tayga.service в директорию > .gear? Изначально в исходниках его не было. Это на любителя, но лично я предпочитаю всё, что имеет отношения к альту держать в отдельном каталоге - так потом удобнее с этим работать. > > Нужно ли добавлять поддержку sysvinit? Такого требования нет. По желанию. по monitorix: https://git.altlinux.org/people/liannnix/packages/?p=monitorix.git;a=commitdiff;h=6c705c594843f823d2bacfad7a603d98357d1955 d /run/monitorix 755 root root если 755 для работы не нужен, то лучше сделать 750 У этого коммита плохой commit message: https://git.altlinux.org/people/liannnix/packages/?p=monitorix.git;a=commitdiff;h=e6b76014569f2f6bf193fd3ce671c40b8bf2d267 ну и соответственно ему запись в changelog тоже кривая: https://git.altlinux.org/people/liannnix/packages/?p=monitorix.git;a=commitdiff;h=abca8aa07a4c12c1572e4f372ced0d73758263fd плюс есть пожелания от многих разработчиков в changelog spec писать изменения в past time вот этого изменения в _пакете_ не было: "- Move spec file to .gear directory" и т.к. пакет ещё не попадал в репозиторий, то я рекомендую всю историю изменения его .gear начать с нуля. по taiga: URL у проекта такой: http://www.litech.org/tayga/ проект заброшен в апстриме, какая цель его сборки ? (Ответ для Anton Farygin на комментарий #33) > по taiga: > URL у проекта такой: http://www.litech.org/tayga/ > > проект заброшен в апстриме, какая цель его сборки ? Проект действительно заброшен, но это одно из двух приемлемых решений для NAT64 под linux. Простое, стабильно, работает в userspace. Есть ещё Jool https://www.jool.mx/en/run-nat64.html, он более-менее живой, но там гораздо хуже производительность. (Ответ для Andrey Limachko на комментарий #34) > (Ответ для Anton Farygin на комментарий #33) > > по taiga: > > URL у проекта такой: http://www.litech.org/tayga/ > > > > проект заброшен в апстриме, какая цель его сборки ? > > Проект действительно заброшен, но это одно из двух приемлемых решений для > NAT64 под linux. Простое, стабильно, работает в userspace. Есть ещё Jool > https://www.jool.mx/en/run-nat64.html, он более-менее живой, но там гораздо > хуже производительность. Есть отличная утилита cleanup_spec из пакета rpm-utils выполните её для своих spec-файлов, посмотрите результат. По tayga. Учёл замечания, почистил историю коммитов. Обычно стараюсь делать атамарные коммиты и избегать rebase, но с новыми пакетами действительно другой случай. cleanup_spec только убрал фигурные скобки с переменных https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=commit;h=1ce230c908d265758efaa9d30a7feed55c4083ff а .gitignore точно нужен в этом коммите ? https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=blob;f=.gear/tayga.spec;h=1fd8d9ee51853eda25900479ce592b3a7f14ba14;hb=1ce230c908d265758efaa9d30a7feed55c4083ff#l23 только сейчас заметил %setup -n %name-%version это дефолт, можно не указывать -n (Ответ для Anton Farygin на комментарий #37) > https://git.altlinux.org/people/liannnix/packages/?p=tayga.git;a=commit; > h=1ce230c908d265758efaa9d30a7feed55c4083ff > > а .gitignore точно нужен в этом коммите ? Могу убрать, но обычно всегда его добавляю, чтобы git игнорировал временные файлы vim. Или Вы имеете ввиду, что его стоит перенести в Initial commit? да, я думаю что его лучше оформить отдельным коммитом, а не в общем коммите с добавлением .gear/* По monitorix. Изменённые файлы .logrotate, .service и т.д. не стал переносить в .gear, так как они были в исходном репозитории изначально. Разработчики могут что-то поменять в них, и я могу не заметить это при следующем мерже из upstream. В остальном постарался учесть предыдущие замечания. И это правильно - если файл был, то конечно его проще поправить коммитом. tayga можно отправлять в репозиторий (Ответ для Anton Farygin на комментарий #42) > И это правильно - если файл был, то конечно его проще поправить коммитом. > > tayga можно отправлять в репозиторий Готово #300565 EPERM #1 sisyphus tayga.git=0.9.2-alt1 taiga заапрувил. Давайте соберём ещё какой-то пакет, у меня есть некоторые сомнения что удалось разобраться окончательно во всех нюансах сборки. В рамках боевых задач уже был доработан и собран cloud-init с более полной поддержкой etcnet: https://git.altlinux.org/gears/c/cloud-init.git Предлагаю исправить в нём Url на более актуальный https://cloud-init.io, а также сделать обновление до последней версии 22.2: https://github.com/canonical/cloud-init Женя, я видел работу над cloud-init. Было бы неплохо собрать какой-то пакет с нуля. Если есть сложность с выбором, то я помогу. (Ответ для Anton Farygin на комментарий #46) > Женя, я видел работу над cloud-init. Было бы неплохо собрать какой-то пакет > с нуля. > > Если есть сложность с выбором, то я помогу. У меня в списке интересных мне пакетов пока только три: clatd implements the CLAT component of the 464XLAT network architecture specified in RFC 6877 В пару к tayga. Клиентская часть для прямого доступа к ipv4 адресам в ipv6 only сетях https://github.com/toreanderson/clatd mdless Аналог less для просмотра Markdown файлов в терминале https://github.com/ttscoff/mdless systeroid sysctl на стероидах)) https://github.com/orhun/systeroid Актуальность для текущих задач сомнительная. Возможно стоит собрать что-то более насущное? (Ответ для Evgeny Sinelnikov на комментарий #45) > В рамках боевых задач уже был доработан и собран cloud-init с более полной > поддержкой etcnet: > https://git.altlinux.org/gears/c/cloud-init.git > > Предлагаю исправить в нём Url на более актуальный https://cloud-init.io, а > также сделать обновление до последней версии 22.2: > https://github.com/canonical/cloud-init Обновлю в любом случае. (Ответ для Andrey Limachko на комментарий #47) > mdless > Аналог less для просмотра Markdown файлов в терминале > https://github.com/ttscoff/mdless Неистово голосую за этот пакет! (Ответ для Andrew Vasilyev на комментарий #49) > (Ответ для Andrey Limachko на комментарий #47) > > mdless > > Аналог less для просмотра Markdown файлов в терминале > > https://github.com/ttscoff/mdless > > Неистово голосую за этот пакет! Это ruby, я не смогу его нормально проверить. актуальные задачи на сборку можно посмотреть здесь: https://bugzilla.altlinux.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=26387&product=New%2Fproposed%20packages&query_format=advanced По-моему, часть "актуальных" запросов может быть уже не актуальны. Например, про KDE4. Требуется актуализация полученного в багзилле перечня. Плюс предлагаю рассмотреть ftbfs: http://git.altlinux.org/beehive/stats/Sisyphus-x86_64/ftbfs-joined С актуализацией всё просто - надо смотреть посвежее. ftbfs не нужно, мне очень нужно увидеть сборку ещё одного нового пакета с нуля. Взялся собрать пакет OpenWebStart (https://bugzilla.altlinux.org/43777) по запросу. После разбора вопроса и стало ясно, что собирать его не имеет смысла, а есть необходимость пересобрать и допилить уже существующий пакет mozilla-plugin-java-1.8.0-openjdk, который, по факту, является проектом icedtea-web. В результате: #317655 DONE #2 sisyphus icedtea-web.git=2.0.0-alt3_pre.0.1.alpha26.patched1.3jpp11 (approved by @viy) liannnix проделал большую работу и по результатам тестирования, проведённого коллегами, видно, что человек готов как специалист. Переработал сложный спек сложного проекта и организовал тестирование функционала с разбором проблем.
Давайте продвинем человека дальше по процессу:
> 4.2 Ожидать решения рецензента о готовности кандидата.
https://git.altlinux.org/tasks/archive/done/_310/317655/gears/100/git?p=git;a=commitdiff;h=46050da47144dcfa26ecf193a6fa4102a70defa1 текст этого коммита не соответствует сделанным в нём изменениям. (Ответ для Anton Farygin на комментарий #55) > https://git.altlinux.org/tasks/archive/done/_310/317655/gears/100/git?p=git; > a=commitdiff;h=46050da47144dcfa26ecf193a6fa4102a70defa1 > > текст этого коммита не соответствует сделанным в нём изменениям. Действительно. Пропустил это при очередном rebase. Исправил. #318457 EPERM #3 sisyphus icedtea-web.git=2.0.0-alt4_pre.0.1.alpha26.patched1.3jpp11 Переделал репозиторий пакета icedtea-web. Теперь исходники из upstream хранятся вместе с git-историей. Сделал в стиле @shaba (видел у него собранные так пакеты) и sudo: пустая ветка со спеком, upstream - отдельно, ветка с патч-коммитами - отдельно. #318457 EPERM #7 sisyphus icedtea-web.git=2.0.0.alpha26-alt1_jpp11 Посмотрел наработки Андрея. Инструкции Gear оформлены корректно, на мой взгляд. Работа как таковая имеет ценность. Предыдущие замечания учтены. Мне нравится. Если вы переходите на сборку из git. то отдельное хранение в разных ветках spec'а, патчей и исходников не облегчает работу над проектом, а сильно её усложняет. цель перехода на git - облегчить процесс сборки и доработки, а не сделать его максимально сложным. Никакого смысле держать спек в отдельной пустой ветке нет. https://git.altlinux.org/tasks/318457/gears/300/git?p=git;a=blob;f=.gear/rules;h=5437f5f185ae6f70af405dcc62dd3a49c63ed870;hb=94290060a12130a476990ca9867acf2e520fd1b5 предлагаю ветку с альтовыми патчами и .gear объединить, а в diff добавить exclude для каталога .gear, что бы патч был чистый. пример: https://git.altlinux.org/gears/o/ocaml-ssl.git?p=ocaml-ssl.git;a=blob;f=.gear/rules;h=b72b429331cf567dd59fd10c5a0c2c5447fa5873;hb=e1858b1c426d85e4f0599577cadd33d4c3c5eb03 ну и на самом деле этот icedtea-web абсолютно нерабочий. (Ответ для Anton Farygin на комментарий #60) > https://git.altlinux.org/tasks/318457/gears/300/git?p=git;a=blob;f=.gear/ > rules;h=5437f5f185ae6f70af405dcc62dd3a49c63ed870; > hb=94290060a12130a476990ca9867acf2e520fd1b5 > > предлагаю ветку с альтовыми патчами и .gear объединить, а в diff добавить > exclude для каталога .gear, что бы патч был чистый. > > пример: > https://git.altlinux.org/gears/o/ocaml-ssl.git?p=ocaml-ssl.git;a=blob;f=. > gear/rules;h=b72b429331cf567dd59fd10c5a0c2c5447fa5873; > hb=e1858b1c426d85e4f0599577cadd33d4c3c5eb03 Сделал. #318457 TESTED #9 [test-only] sisyphus icedtea-web.git=2.0.0.alpha26-alt1_jpp11 (Ответ для Anton Farygin на комментарий #61) > ну и на самом деле этот icedtea-web абсолютно нерабочий. Что именно нерабочее? Я проверял, jnlp нормально отрабатывают. Да просто запускается и тут же прекращает свою работу. до iKVM не доходит. вот этот коммит выглядит странно, на мой взгляд он не нужен, по крайней мере целесообразность такого переименования нигде не указана. https://git.altlinux.org/tasks/318457/gears/400/git?p=git;a=commitdiff;h=b9fdb68b2711e5615138bbe36f73d37a5f4c3525 (Ответ для Anton Farygin на комментарий #64) > Да просто запускается и тут же прекращает свою работу. > > до iKVM не доходит. Выяснил, в чём дело. iKVM__V1.69.39.0x0 требуется библиотека libnsl1. Без неё оно не запускается в принципе. Напишу об этом статью на вики. (Ответ для Andrey Limachko на комментарий #66) > (Ответ для Anton Farygin на комментарий #64) > > Да просто запускается и тут же прекращает свою работу. > > > > до iKVM не доходит. > > Выяснил, в чём дело. iKVM__V1.69.39.0x0 требуется библиотека libnsl1. Без > неё оно не запускается в принципе. Напишу об этом статью на вики. Добавил заметку на страничку https://www.altlinux.org/IKVM. может быть проще зависимость добавить ? (Ответ для Anton Farygin на комментарий #68) > может быть проще зависимость добавить ? Можно, но это ведь будет зависимость только для iKVM. Для работы самого icedtea-web она не требуется. Но если Java Web Start, по сути, сейчас ни для чего больше не используется, то, возможно, в этом есть смысл. Добавлять? (Ответ для Anton Farygin на комментарий #65) > вот этот коммит выглядит странно, на мой взгляд он не нужен, по крайней мере > целесообразность такого переименования нигде не указана. > > https://git.altlinux.org/tasks/318457/gears/400/git?p=git;a=commitdiff; > h=b9fdb68b2711e5615138bbe36f73d37a5f4c3525 Убрал. #318457 TESTED #11 [test-only] sisyphus icedtea-web.git=2.0.0.alpha26-alt1_jpp11 (Ответ для Andrey Limachko на комментарий #69) > (Ответ для Anton Farygin на комментарий #68) > > может быть проще зависимость добавить ? > > Можно, но это ведь будет зависимость только для iKVM. Для работы самого > icedtea-web она не требуется. Но если Java Web Start, по сути, сейчас ни для > чего больше не используется, то, возможно, в этом есть смысл. > > Добавлять? конечно, ведь iKVM это основная головная боль админов при настройке серверов, а больше этот icedtea-web вроде как ни для чего и не нужен. (Ответ для Andrey Limachko на комментарий #70) > (Ответ для Anton Farygin на комментарий #65) > > вот этот коммит выглядит странно, на мой взгляд он не нужен, по крайней мере > > целесообразность такого переименования нигде не указана. > > > > https://git.altlinux.org/tasks/318457/gears/400/git?p=git;a=commitdiff; > > h=b9fdb68b2711e5615138bbe36f73d37a5f4c3525 > > Убрал. > #318457 TESTED #11 [test-only] sisyphus > icedtea-web.git=2.0.0.alpha26-alt1_jpp11 Андрей, предлагаю перейти в личку, я вообще не понимаю что и как делается с этим репозиторием. Переход от не-git к git может быть реализован двумя способами: 1) просто взять другой репозиторий, добавить в него всё что нужно (.gear/rules, spec и т.д.) и при сборке на сборочнице порвать наследование через task check-git-inheritance 2) перейти на другое дерево, подшив старую историю: git merge --no-commit --allow-unrelated-histories -s ours <апстримный тэг> git read-tree -u --reset <апстримный тэг> git checkout @ -- .gear <и другие файлы, которые надо забрать из старой ветки> git commit -a и дальше поправить файлы для сборки по другой схеме и сделать второй коммит. Пакет icedtea-web с исправлениями уехал в sisyphus. #318457 DONE #15 sisyphus icedtea-web.git=2.0.0.alpha26-alt1_jpp11 кандидат разобрался со сборкой пакетов и,на мой взгляд, готов уже делать это самостоятельно. Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства! (Ответ для Gleb F-Malinovskiy на комментарий #75) > Адрес подписан на devel@. > Пользователь добавлен в группу мейнтейнеров. > > Желаю удачного мейнтейнерства! Спасибо! |
Description
Andrey Limachko 2021-10-02 22:13:34 MSK