Summary: | Не обновляется | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Олег Соловьев <mcpain> |
Component: | firmware-linux | Assignee: | Vitaly Chikunov <vt> |
Status: | CLOSED WONTFIX | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | Sergei.Naumov, aen, antohami, boyarsh, ildar, ldv, nrbrtx, rider, viy, vt |
Version: | unstable | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
See Also: | https://bugzilla.altlinux.org/show_bug.cgi?id=36628 | ||
Bug Depends on: | 34619 | ||
Bug Blocks: |
Description
Олег Соловьев
2022-09-16 11:20:40 MSK
Пакет роботом собирается. Превратился в апстриме каталог в симлинк: https://git.altlinux.org/gears/f/firmware-linux.git?p=firmware-linux.git;a=commitdiff;h=edf9a2b4e1fb70ca7d6f04a0a0a3d95ebb64a3d7 У нас такие баги периодически появляются. Решать надо на уровне починки rpm, как я понимаю. Проблема в том, что починки в rpm не ожидается, а этот пакет установлен на всех машинах и обязателен к обновлению. Дима, я всё правильно написал про rpm ? Или есть шанс что эта ошибка будет исправлена в ближайшее время в sisyphus и, хотя-бы, в p10 ? (Ответ для 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 до Сизифа не ломает (проверил). Предлагаю улучшить робота, собирающего firmware-linux, чтобы он проверял обновление пакета с предыдущей версии на новую. И коммитил только тогда, когда обновление проходит успешно. Правда я не в курсе, где и как этот робот работает. Вроде viy@ им заведовал. Но может я ошибаюсь. (Ответ для Антон Мидюков на комментарий #5) > Предлагаю улучшить робота, собирающего firmware-linux, чтобы он проверял > обновление пакета с предыдущей версии на новую. И коммитил только тогда, > когда обновление проходит успешно. > Правда я не в курсе, где и как этот робот работает. Вроде viy@ им заведовал. > Но может я ошибаюсь. а как это проверить? какой у такой проверки алгоритм? (Ответ для viy на комментарий #6) > (Ответ для Антон Мидюков на комментарий #5) > > Предлагаю улучшить робота, собирающего firmware-linux, чтобы он проверял > > обновление пакета с предыдущей версии на новую. И коммитил только тогда, > > когда обновление проходит успешно. > > Правда я не в курсе, где и как этот робот работает. Вроде viy@ им заведовал. > > Но может я ошибаюсь. > > а как это проверить? какой у такой проверки алгоритм? Установить firmware-linux из репозитория. Обновить из задания. Если успешно, то закоммитить. (Ответ для Антон Мидюков на комментарий #7) > (Ответ для viy на комментарий #6) > > (Ответ для Антон Мидюков на комментарий #5) > > > Предлагаю улучшить робота, собирающего firmware-linux, чтобы он проверял > > > обновление пакета с предыдущей версии на новую. И коммитил только тогда, > > > когда обновление проходит успешно. > > > Правда я не в курсе, где и как этот робот работает. Вроде viy@ им заведовал. > > > Но может я ошибаюсь. > > > > а как это проверить? какой у такой проверки алгоритм? > > Установить firmware-linux из репозитория. Обновить из задания. Если успешно, > то закоммитить. такое вряд ли получится засунуть в скрипт обновления gear-cronbuild. Надо что-то на уровне git. К примеру, есть листинг прошлого собранного коммита и есть листинг текущего. проверяем, содержат ли эти листинги конфликт. Так как-то можно? *** Bug 43814 has been marked as a duplicate of this bug. *** Я добавил проверку, чтобы такого больше не случилось при обновлении cronbuild'ом. Но сразу возникает вопрос: вот случится, сборка кроном обломится, и чего с этим делать дальше? правильно было бы задать этот вопрос в #34619 (Ответ для Антон Мидюков на комментарий #10) > Я добавил проверку, чтобы такого больше не случилось при обновлении > cronbuild'ом. Но сразу возникает вопрос: вот случится, сборка кроном > обломится, и чего с этим делать дальше? Поправить проблему руками и руками починку отправить на сборку. cronbuild продолжает работу с последней сборки, неважно, ручной или авто. (Ответ для viy на комментарий #12) > (Ответ для Антон Мидюков на комментарий #10) > > Я добавил проверку, чтобы такого больше не случилось при обновлении > > cronbuild'ом. Но сразу возникает вопрос: вот случится, сборка кроном > > обломится, и чего с этим делать дальше? > > Поправить проблему руками и руками починку отправить на сборку. > cronbuild продолжает работу с последней сборки, неважно, ручной или авто. Да, это понятно. Я мысль свою не развил. Править исходники? Суть правки будет состоять в том, чтобы вместо ссылки на каталог был каталог с ссылками на файлы. Но тогда это в форк со временем вырастет, который перестанет автоматически собираться всё чаще и чаще из-за конфликтов, как мне кажется. проблему надо чинить в #34619 - известного способа объезда этой ошибки не существует. Я думаю, что все, кто мог, эту граблю уже поймали, а те, кто будет обновляться с p10, её не поймают (там более новая версия), поэтому можно не чинить. |