43806 2022-09-16 11:20:40 +0300 Не обновляется 2023-08-30 15:31:20 +0300 1 1 4 Development Sisyphus firmware-linux unstable x86_64 Linux CLOSED WONTFIX https://bugzilla.altlinux.org/show_bug.cgi?id=36628 P5 normal --- 34619 1 mcpain vt Sergei.Naumov aen antohami boyarsh ildar ldv n.strelkov rider viy vt qa-sisyphus oldest_to_newest 214952 0 mcpain 2022-09-16 11:20:40 +0300 Продолжить? [Y/n] Совершаем изменения... Подготовка... #################################################################################################### [100%] файл /lib/firmware/qcom/LENOVO/21BX из устанавливаемого пакета firmware-linux-20220912-alt1.noarch конфликтует с файлом из пакета firmware-linux-20220902-alt1.noarch E: Ошибка во время исполнения транзакции 214958 1 antohami 2022-09-16 12:22:31 +0300 Пакет роботом собирается. Превратился в апстриме каталог в симлинк: https://git.altlinux.org/gears/f/firmware-linux.git?p=firmware-linux.git;a=commitdiff;h=edf9a2b4e1fb70ca7d6f04a0a0a3d95ebb64a3d7 У нас такие баги периодически появляются. Решать надо на уровне починки rpm, как я понимаю. 214960 2 rider 2022-09-16 12:25:26 +0300 Проблема в том, что починки в rpm не ожидается, а этот пакет установлен на всех машинах и обязателен к обновлению. 214961 3 rider 2022-09-16 12:26:08 +0300 Дима, я всё правильно написал про rpm ? Или есть шанс что эта ошибка будет исправлена в ближайшее время в sisyphus и, хотя-бы, в p10 ? 215010 4 antohami 2022-09-17 14:31:50 +0300 (Ответ для Anton Farygin на комментарий #2) > Проблема в том, что починки в rpm не ожидается, а этот пакет установлен на > всех машинах и обязателен к обновлению. И тем не менее всё не так плохо, как могло быть. Каталог /lib/firmware/qcom/LENOVO/21BX был добавлен 3 августа 2022 года: https://git.altlinux.org/gears/f/firmware-linux.git?p=firmware-linux.git;a=commitdiff;h=4ae4ae88918928e15006eb129ad981aa58216b59 А в p10 firmware-linux 20220309. Так что обновление из p10 до Сизифа не ломает (проверил). 215011 5 antohami 2022-09-17 14:38:04 +0300 Предлагаю улучшить робота, собирающего firmware-linux, чтобы он проверял обновление пакета с предыдущей версии на новую. И коммитил только тогда, когда обновление проходит успешно. Правда я не в курсе, где и как этот робот работает. Вроде viy@ им заведовал. Но может я ошибаюсь. 215013 6 viy 2022-09-17 16:53:56 +0300 (Ответ для Антон Мидюков на комментарий #5) > Предлагаю улучшить робота, собирающего firmware-linux, чтобы он проверял > обновление пакета с предыдущей версии на новую. И коммитил только тогда, > когда обновление проходит успешно. > Правда я не в курсе, где и как этот робот работает. Вроде viy@ им заведовал. > Но может я ошибаюсь. а как это проверить? какой у такой проверки алгоритм? 215015 7 antohami 2022-09-17 17:58:20 +0300 (Ответ для viy на комментарий #6) > (Ответ для Антон Мидюков на комментарий #5) > > Предлагаю улучшить робота, собирающего firmware-linux, чтобы он проверял > > обновление пакета с предыдущей версии на новую. И коммитил только тогда, > > когда обновление проходит успешно. > > Правда я не в курсе, где и как этот робот работает. Вроде viy@ им заведовал. > > Но может я ошибаюсь. > > а как это проверить? какой у такой проверки алгоритм? Установить firmware-linux из репозитория. Обновить из задания. Если успешно, то закоммитить. 215016 8 viy 2022-09-17 18:20:35 +0300 (Ответ для Антон Мидюков на комментарий #7) > (Ответ для viy на комментарий #6) > > (Ответ для Антон Мидюков на комментарий #5) > > > Предлагаю улучшить робота, собирающего firmware-linux, чтобы он проверял > > > обновление пакета с предыдущей версии на новую. И коммитил только тогда, > > > когда обновление проходит успешно. > > > Правда я не в курсе, где и как этот робот работает. Вроде viy@ им заведовал. > > > Но может я ошибаюсь. > > > > а как это проверить? какой у такой проверки алгоритм? > > Установить firmware-linux из репозитория. Обновить из задания. Если успешно, > то закоммитить. такое вряд ли получится засунуть в скрипт обновления gear-cronbuild. Надо что-то на уровне git. К примеру, есть листинг прошлого собранного коммита и есть листинг текущего. проверяем, содержат ли эти листинги конфликт. Так как-то можно? 215023 9 antohami 2022-09-18 06:46:24 +0300 *** Bug 43814 has been marked as a duplicate of this bug. *** 215228 10 antohami 2022-09-23 14:21:25 +0300 Я добавил проверку, чтобы такого больше не случилось при обновлении cronbuild'ом. Но сразу возникает вопрос: вот случится, сборка кроном обломится, и чего с этим делать дальше? 215236 11 rider 2022-09-23 15:18:02 +0300 правильно было бы задать этот вопрос в #34619 215263 12 viy 2022-09-24 19:09:45 +0300 (Ответ для Антон Мидюков на комментарий #10) > Я добавил проверку, чтобы такого больше не случилось при обновлении > cronbuild'ом. Но сразу возникает вопрос: вот случится, сборка кроном > обломится, и чего с этим делать дальше? Поправить проблему руками и руками починку отправить на сборку. cronbuild продолжает работу с последней сборки, неважно, ручной или авто. 215266 13 antohami 2022-09-24 19:25:29 +0300 (Ответ для viy на комментарий #12) > (Ответ для Антон Мидюков на комментарий #10) > > Я добавил проверку, чтобы такого больше не случилось при обновлении > > cronbuild'ом. Но сразу возникает вопрос: вот случится, сборка кроном > > обломится, и чего с этим делать дальше? > > Поправить проблему руками и руками починку отправить на сборку. > cronbuild продолжает работу с последней сборки, неважно, ручной или авто. Да, это понятно. Я мысль свою не развил. Править исходники? Суть правки будет состоять в том, чтобы вместо ссылки на каталог был каталог с ссылками на файлы. Но тогда это в форк со временем вырастет, который перестанет автоматически собираться всё чаще и чаще из-за конфликтов, как мне кажется. 215273 14 rider 2022-09-25 10:33:31 +0300 проблему надо чинить в #34619 - известного способа объезда этой ошибки не существует. 232164 15 antohami 2023-08-30 15:31:20 +0300 Я думаю, что все, кто мог, эту граблю уже поймали, а те, кто будет обновляться с p10, её не поймают (там более новая версия), поэтому можно не чинить.