59461 2026-06-05 11:54:30 +0300 Кривой конфликт c polkit 2026-06-08 17:31:25 +0300 1 1 1 Unclassified Branch p11 NetworkManager unspecified x86_64 Linux CLOSED FIXED P5 normal --- 1 zerg sem sem shaba qa-p11 oldest_to_newest 289019 0 zerg 2026-06-05 11:54:30 +0300 Есть же опция сборки polkit_agent_helper_1. Если хочется привязаться к этому пути, положите в укромное место пакета симлинк на её значение. Теперь ни polkit обновить, ни NM пересобрать... 289020 1 zerg 2026-06-05 11:54:52 +0300 В p11 такая же ерунда. 289051 2 sem 2026-06-05 17:20:12 +0300 Я не понимаю в чем проблема. В polkit-126-alt1 изменился путь к файлу, в спеке NM, соответственно, он изменился тоже. Естественно добавлен конфликт со старой версией polkit. В p11 путь не менялся, поэтому стоит конфликт на версию polkit из Сизифа. 289052 3 zerg 2026-06-05 17:24:41 +0300 (Ответ для Mikhail Efremov на комментарий #2) > Я не понимаю в чем проблема. Обновите polkit в p11 до 126 и в сизифе до 127. 289054 4 sem 2026-06-05 17:41:34 +0300 (Ответ для Sergey V Turchin на комментарий #3) > (Ответ для Mikhail Efremov на комментарий #2) > > Я не понимаю в чем проблема. > Обновите polkit в p11 до 126 Расшарь таск, добавлю NM с убранным кофликтом. Ведь путь в сборке polkit для p11 не меняется как в Сизифе, правда? Или как всегда, наши бранчи самые "стабильные"? > и в сизифе до 127. А в Сизифе NM чем мешает обновлению? 289055 5 zerg 2026-06-05 17:44:58 +0300 (Ответ для Mikhail Efremov на комментарий #4) > Расшарь таск, добавлю NM с убранным кофликтом. build#420009 [...] > А в Сизифе NM чем мешает обновлению? Там же самым. Но это уже к мантейнеру. 289058 6 sem 2026-06-05 18:16:47 +0300 (Ответ для Sergey V Turchin на комментарий #5) > (Ответ для Mikhail Efremov на комментарий #4) > > Расшарь таск, добавлю NM с убранным кофликтом. > build#420009 Я вижу там просто копирование пакета из Сизифа с измененным путем. Ок, на то, что потенциально у пользователей могут существовать сторонние приложения, написанные для p11 и рассчитывающие найти агента по старому пути, мы забиваем. Но точно только NM требует пересборки, другие, особенно gnome-приложения, пересобирать для изменения пути не надо? В любом случае прошу явно подтвердить, что отправка polkit с измененным путем к агенту в стабильный бранч - это осознанное и взвешенное решение. > > А в Сизифе NM чем мешает обновлению? > Там же самым. Но это уже к мантейнеру. Чем Conflicts: polkit < 126-alt1 мешает обновлению polkit до 127? 289059 7 sem 2026-06-05 18:26:18 +0300 Добавил shaba@ 289100 8 zerg 2026-06-08 10:31:20 +0300 (Ответ для Mikhail Efremov на комментарий #6) > Чем Conflicts: polkit < 126-alt1 мешает обновлению polkit до 127? Слепой я. Прочёл, как Conflicts: polkit > 126-alt1 289101 9 zerg 2026-06-08 10:33:12 +0300 (Ответ для Mikhail Efremov на комментарий #6) > NM требует пересборки Нет. Я о том, что он требовал бы пересборки, если бы сделано было правильно. А теперь он требует отдельной _правки_ для p11. 289102 10 zerg 2026-06-08 10:33:57 +0300 (Ответ для Sergey V Turchin на комментарий #9) > он требовал бы пересборки, если бы сделано было правильно. Я бы просто добавил в задание пересборку и никого не отвлекал. 289104 11 zerg 2026-06-08 10:36:43 +0300 (Ответ для Mikhail Efremov на комментарий #6) > другие, особенно gnome-приложения, Судя по тому, что .pc от polkit не содержит этого пути, то в NM это уже изврат. > пересобирать для изменения пути не надо? Я вообще первый раз вижу, что это кому-то нужно. Но, для NM допускаю, что может быть хоть как-то оправдано(не вникал). 289115 12 sem 2026-06-08 12:33:00 +0300 (Ответ для Sergey V Turchin на комментарий #10) > > он требовал бы пересборки, если бы сделано было правильно. > Я бы просто добавил в задание пересборку и никого не отвлекал. Без этого конфликта необходимость пересборки была бы неизвестна и после изменения пути в polkit аутентификация в nmcli просто сломалась бы. (Ответ для Sergey V Turchin на комментарий #11) > Судя по тому, что .pc от polkit не содержит этого пути, то в NM это уже > изврат. > > > пересобирать для изменения пути не надо? > Я вообще первый раз вижу, что это кому-то нужно. Но, для NM допускаю, что > может быть хоть как-то оправдано(не вникал). Там в nmcli напрямую запускается polkit-agent. Я не знаю насколько это распространенная практика, но у меня нет уверенности, что в репозитории больше нет таких приложений, в которых путь к агенту определяется во время сборки. Я лично не готов проводить анализ репозитория на предмет выяснения этого вопроса (даже если не брать в расчет возможное существование сторонних приложений), поэтому не стал бы менять путь в стабильном бранче. Возможно shaba@ знает, не всплывали ли еще проблемы при смене пути в Сизифе. 289119 13 zerg 2026-06-08 13:39:06 +0300 (Ответ для Mikhail Efremov на комментарий #12) > Без этого конфликта необходимость пересборки была бы неизвестна Я в изначальном сообщении написал, как это сделать. 289121 14 zerg 2026-06-08 13:45:19 +0300 (Ответ для Mikhail Efremov на комментарий #12) > в nmcli напрямую запускается polkit-agent. Полагаю, это баг. 289135 15 sem 2026-06-08 17:01:57 +0300 В общем, я добавил в таск NM с измененным путем к агенту. Дальше действия на твоей совести, но лично я бы собрал в p11 polkit без изменения пути. 289138 16 zerg 2026-06-08 17:14:29 +0300 (Ответ для Mikhail Efremov на комментарий #15) > я бы собрал в p11 polkit без изменения пути. Месяц, как в Сизифе никто не жаловался. Смысла мало. 289139 17 zerg 2026-06-08 17:15:25 +0300 (Ответ для Mikhail Efremov на комментарий #15) > я бы собрал в p11 polkit без изменения пути. Так и придётся каждый раз пересобирать NM. 289140 18 zerg 2026-06-08 17:29:32 +0300 https://packages.altlinux.org/ru/tasks/420009/ 289141 19 zerg 2026-06-08 17:31:25 +0300 (Ответ для Mikhail Efremov на комментарий #15) > я бы собрал в p11 polkit без изменения пути. Лучше баг на него повесить про изменение пути.