https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/
Feel free to update.
Решил, что некуда дальше откладывать: https://packages.altlinux.org/en/tasks/334324/ Прошу посмотреть и одобрить.
1. Думаю кандидат готов обновлять пакеты самостоятельно. 2. С другой стороны, если те коммиты делались для review, то вот пригоршня вопросов: - https://git.altlinux.org/tasks/334324/gears/300/git?p=git;a=commitdiff;h=2abcd87a884b00febebabf8944ccebeb019df26c откуда это "looks"? - зачем 1 убирание libnetlink сделано в виде трех коммитов - 1 до (еще и revert) merge + 2 после. Думаю, не обязательно при удалении ревертить все коммиты затрагивавшие libnetlink за все 11 лет, ведь это не была какая-то ошибка и теперь её откат. - зачем оставлены пустые пакеты libnetlink и libnetlink-devel (с 1 man страницей)? - https://git.altlinux.org/tasks/334324/gears/300/git?p=git;a=commitdiff;h=c1bb677dad05a2cdb1e6a574272c0372a256f1b4 зачем дополнительные аргументы make, если это "upstream decision"? - как насчет добавить %define _stripped_files_terminate_build 1 %set_verify_elf_method strict,unresolved=relaxed
(In reply to Vitaly Chikunov from comment #3) > 1. Думаю кандидат готов обновлять пакеты самостоятельно. > > 2. С другой стороны, если те коммиты делались для review, то вот пригоршня > вопросов: Ну раз уж требуется ревью, почему бы его и не провести, да. Благодарю за заданные вопросы! ^^ > - > https://git.altlinux.org/tasks/334324/gears/300/git?p=git;a=commitdiff; > h=2abcd87a884b00febebabf8944ccebeb019df26c > > откуда это "looks"? Я об это споткнулся, потому что возникал merge-конфликт при попытке смёржить v6.6.0. Выяснилось, что в апстриме из q_prio.c получается просто q_prio.o, который далее входит в программу tc, и зачем плагин — непонятно. Это я и обозвал "looks like". > - зачем 1 убирание libnetlink сделано в виде трех коммитов - 1 до (еще и > revert) merge + 2 после. Думаю, не обязательно при удалении ревертить все > коммиты затрагивавшие libnetlink за все 11 лет, ведь это не была какая-то > ошибка и теперь её откат. 2 коммита после меняют спек, а не исходники iproute2. Для кого как, конечно, но для меня разница важна. Их можно было и склеить, просто разные коммиты проще читать впервые. Если не ревёртить наши чудесные изобретения, а затмевать их новыми явными коммитами, которые вдобавок ещё что-нибудь меняют, то в такой истории проще потеряться и сложнее отделить наши оставшиеся чудесные изобретения от кода iproute2. git diff v6.6.0 "$@" покажет отличия, но не покажет их контекста, + спек так расположен, что его трудно выбросить из вывода git diff. Будь моя воля, я бы предпочёл tcpdump-подобную схему упаковки: коммит апстрима, unrolled patches поверх (в пакете iproute2 их пока 0), merge в ветку с релизными коммитами каким-нибудь способом, имеющим смысл. Но ради одного обновления iproute2, первого из сделанных моими руками, менять gear-схему — это уже перебор. > - зачем оставлены пустые пакеты libnetlink и libnetlink-devel (с 1 man > страницей)? Ман-страницу, наверное, надо куда-то положить. libnetlink-devel нужен как раз ради этой ман-страницы. Существование пакета libnetlink-devel без пакета libnetlink мне показалось странным. Если ман-страницу не стоит упаковывать вообще или стоит засунуть в iproute2-devel, то и эти два пакета ни к чему. А ты как думаешь, нужна ли она вообще? Это же устаревший интерфейс, с которым ничего не собрано и с которым нет никакой нужды собираться чему-либо внешнему. > - > https://git.altlinux.org/tasks/334324/gears/300/git?p=git;a=commitdiff; > h=c1bb677dad05a2cdb1e6a574272c0372a256f1b4 > > зачем дополнительные аргументы make, если это "upstream decision"? Чтобы на 64-битных архитектурах файлы не попадали в %_libdir. Иными словами, апстрим решил отделить CONF_USR_DIR от CONF_ETC_DIR и устанавливать эти файлы в CONF_USR_DIR, по умолчанию лежащий под %_libdir; а я вмешался, чтобы они попадали в /usr/lib, по моде[1] проекта systemd. (Мне эта мода не то чтобы очень нравится[•], но %_libdir хуже) [1] https://www.freedesktop.org/software/systemd/man/254/file-hierarchy.html > - как насчет добавить > %define _stripped_files_terminate_build 1 > %set_verify_elf_method strict,unresolved=relaxed Об этом вообще не думал. А зачем unresolved=relaxed? Неужели затем, чтобы простить пакету вот это: [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: show_stats [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: print_nl [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: matches [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: addattr_nest_end [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: addattr_l [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: get_u32 [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: print_tm [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: parse_rtattr_flags [00:00:38] verify-elf: WARNING: ./usr/lib64/tc/m_xt.so: undefined symbol: addattr_nest Полагаю, лучше это видеть; я именно из-за сообщений verify-elf про undefined symbols на псевдо-libnetlink внимание обратил; этот объект получил зависимости прямо на символы из ip(8). ____ [•] Будь у нас %_libdir по-дебиановски, с арч-триплетом, каталог /usr/lib как место для комплектной вендорской конфигурации выглядел бы лучше, но слишком много на это нужно сил. Системдоиды приняли неудачное решение.
(In reply to Arseny Maslennikov from comment #2) > Решил, что некуда дальше откладывать: > https://packages.altlinux.org/en/tasks/334324/ > > Прошу посмотреть и одобрить. Обновил это задание: - %define _stripped_files_terminate_build 1; - dropped libnetlink* package altogether.
(In reply to Arseny Maslennikov from comment #5) > (In reply to Arseny Maslennikov from comment #2) > > Решил, что некуда дальше откладывать: > > https://packages.altlinux.org/en/tasks/334324/ > > > > Прошу посмотреть и одобрить. > > Обновил это задание: > - добавил %define _stripped_files_terminate_build 1; > - окончательно выбросил пакеты libnetlink*. Всё ещё прошу посмотреть и одобрить.
(In reply to Arseny Maslennikov from comment #4) > Иными словами, апстрим решил отделить CONF_USR_DIR от CONF_ETC_DIR и устанавливать эти файлы в CONF_USR_DIR, по умолчанию лежащий под %_libdir; а я вмешался, чтобы они попадали в /usr/lib, по моде[1] проекта systemd. (Мне эта мода не то чтобы очень нравится[•], но %_libdir хуже) > Системдоиды приняли неудачное решение. Пришёл небезызвестный bluca и сделал CONF_USR_DIR по умолчанию под datadir: https://lore.kernel.org/netdev/20231106001410.183542-1-luca.boccassi@gmail.com/ Вот и хорошо, сделаем так же.
(In reply to Arseny Maslennikov from comment #6) > (In reply to Arseny Maslennikov from comment #5) > > (In reply to Arseny Maslennikov from comment #2) > > > Решил, что некуда дальше откладывать: > > > https://packages.altlinux.org/en/tasks/334324/ > > > > > > Прошу посмотреть и одобрить. > > > > Обновил это задание: > > - добавил %define _stripped_files_terminate_build 1; > > - окончательно выбросил пакеты libnetlink*. > > Всё ещё прошу посмотреть и одобрить. Обновил это задание: - поместил значения для файлов из /etc/iproute2 по умолчанию под /usr/share. Всё ещё прошу посмотреть и одобрить. Задание отложено из-за https://packages.altlinux.org/tasks/333513, но пакеты собрались, а исходники доступны; обсуждать можно уже сейчас. Более того, с тех пор успела выйти ещё и 6.7.0: https://packages.altlinux.org/tasks/338134 Но её имеет смысл готовить после одобрения 6.6.0.
2024-Jan-19 04:47:03 :: task #334324 for sisyphus EPERM Судя по всему, задание всех устраивает, и его можно пропускать в репозиторий. :)
> Dear Arseny Maslennikov! > > Gleb Fotengauer-Malinovskiy has added an approval of subtask #1000 of task #334324: > 1000:iproute2.git=6.6.0-alt1 > > The text of approval follows: > > lgtm Благодарю! :) Новое задание c iproute2 6.7.0-alt1 на очереди: > 2024-Jan-24 19:31:29 :: task #338134 for sisyphus EPERM
Закоммитилось же? Этот баг закрываю. FYI https://lore.altlinux.org/sisyphus-cybertalk/ZbHuQQRoyD%2Ff6aG6@beehive.mskdc.altlinux.org/ > ch341prog-20170517ba1a8306-alt1 > Building Dependency Tree... > E: Couldn't find package libnetlink-devel > hsh-install: Failed to calculate package file list.
(In reply to Gleb F-Malinovskiy from comment #11) > FYI > https://lore.altlinux.org/sisyphus-cybertalk/ZbHuQQRoyD%2Ff6aG6@beehive. > mskdc.altlinux.org/ > > ch341prog-20170517ba1a8306-alt1 > > Building Dependency Tree... > > E: Couldn't find package libnetlink-devel > > hsh-install: Failed to calculate package file list. Ух ты, спасибо. Но если бы там действительно была зависимость на эту псевдобиблиотеку, возник бы анмет. Судя по исходникам, там BR: libnetlink-devel* и передача -lnetlink — паразитные. Сейчас локально смог пересобрать пакет без них.
Блок снимать не надо. В соотв. ошибке будет видно, что эту исправили.
(In reply to Sergey V Turchin from comment #13) > Блок снимать не надо. В соотв. ошибке будет видно, что эту исправили. Письма о закрытии пришли тем, кому интересно и кто был подписан на bug 46625. Но я снял блок не поэтому; считаю, что наличие этой закрытой баги в зависимостях у bug 46625 сейчас вводит читателя в заблуждение, потому что причина открытия баги не устранена: пока мы одобряли одну версию, вышла другая.
(Ответ для Arseny Maslennikov на комментарий #14) > пока мы одобряли одну версию, вышла другая. Т.е. баг не исправлен?
(In reply to Sergey V Turchin from comment #15) > (Ответ для Arseny Maslennikov на комментарий #14) > > пока мы одобряли одну версию, вышла другая. > Т.е. баг не исправлен? Именно так.
Ааа, ну тогда и в #46625 всё отобразится.
* Sat Jan 13 2024 Arseny Maslennikov <arseny@altlinux.org> 6.7.0-alt1 - 6.6.0 -> 6.7.0.
