35529 2018-10-19 12:13:59 +0300 сломано обновление с p10 до sisyphus 2024-06-28 17:57:43 +0300 1 1 4 Development Sisyphus rpm unstable all Linux CLOSED FIXED P3 blocker --- 35737 36872 34231 1 rider vseleznv Sergei.Naumov aas aas aen antohami asy at avm berkut_174 boyarsh glebfm ildar imz inger iv lav ldv m mike placeholder rider shrek sin sotor stalker vseleznv vt zerg qa-sisyphus oldest_to_newest 175146 0 rider 2018-10-19 12:13:59 +0300 Новый конфиг /etc/apt/preferences не приезжает ни с каким пакетом, обновляться пакеты с одинаковыми версиями естественно не хотят. apt-conf-sisyphus установлен. 175147 1 rider 2018-10-19 12:21:50 +0300 Более того - мои попытки придумать /etc/apt/preferences ни к чему не привели - обновления по прежнему не работают. Ну или нужен какой-то пример. Что писать в Pin: release l= ??? 175150 2 rider 2018-10-19 13:43:04 +0300 Кому не блокер, а мне так срочно прямо сейчас нужно обновиться. 175152 3 rider 2018-10-19 13:50:28 +0300 $ cat /etc/apt/preferences Package: * Pin: release l=Sisyphus Pin-Priority: 700 так не работает. Да собственно никак не работает, что я уже только в /etc/apt/preferences не писал. Кто-то мне говорил что у него это работает и он этим пользуется. Не мог бы этот кто-то описать рецепт для обновления workstation K с p8 до Sisyphus ? Спасибо заранее. 175153 4 rider 2018-10-19 14:05:36 +0300 поднятие Pin-priority до значения больше 1000 помогает запустить процесс обновления. нужно конфиг по умолчанию. 175154 5 rider 2018-10-19 14:09:16 +0300 Заработало оно правда тоже весьма странно: Следующие пакеты будут ЗАМЕНЕНЫ БОЛЕЕ СТАРЫМИ ВЕРСИЯМИ: gtk-theme-breeze kde5-mini kde5-runtime kde5-small libcolorcorrect5 libkdecorations25 libkdecorations2private5 libkf5screen libkwin4_effect_builtins1 libkwin5 libkwineffects11 libkwinglutils11 libkwinxrenderutils11 libkworkspace55 libplasma-geolocation-interface5 libpowerdevilconfigcommonprivate5 libpowerdevilcore2 libpowerdevilui5 libsystemsettingsview3 libtaskmanager6 libweather_ion7 pciids plasma5-breeze plasma5-drkonqi plasma5-integration plasma5-kactivitymanagerd plasma5-kde-cli-tools plasma5-kdecoration-common plasma5-ksysguard plasma5-kwayland-integration plasma5-kwin plasma5-kwin-common plasma5-libkscreen-common plasma5-nm plasma5-nm-connect-fortisslvpn plasma5-nm-connect-iodine plasma5-nm-connect-l2tp plasma5-nm-connect-mobile plasma5-nm-connect-openconnect plasma5-nm-connect-openswan plasma5-nm-connect-openvpn plasma5-nm-connect-pptp plasma5-nm-connect-ssh plasma5-nm-connect-sstp plasma5-nm-connect-strongswan plasma5-nm-connect-vpnc plasma5-nm-maxi plasma5-pa plasma5-polkit-kde-agent plasma5-powerdevil plasma5-powerdevil-common plasma5-sddm-kcm plasma5-systemsettings plasma5-systemsettings-common plasma5-workspace plasma5-workspace-common 175155 6 ldv 2018-10-19 14:32:59 +0300 (In reply to comment #5) > Заработало оно правда тоже весьма странно: > > Следующие пакеты будут ЗАМЕНЕНЫ БОЛЕЕ СТАРЫМИ ВЕРСИЯМИ: Да, это сообщение на первый взгляд выглядит странно. Но посколько пакеты в Сизиф были собраны раньше, чем в бранч, с точки зрения apt они действительно старее. Пожалуйста, предлагайте более удачные формулировки и/или идеи. 175156 7 rider 2018-10-19 14:38:23 +0300 Я понимаю почему это происходит. Технически, наверняка можно вычислить пакеты в которых версия/релиз при обновлении не меняется, а уменьшается только дата сборки. Если дату сборки убрать из алгоритма вычисления возраста пакетов, то dist-upgrade заработает и с более низким pin-priority и не возникнет случайной ситуации, когда действительно будет понижение версии, а не сборка точно такой же версии в другом окружении. Вообще, Дима, что я тебе советую - у тебя же своя голова на плечах есть. Сделай как-нибуть что бы было хорошо, пожалуйста. 175158 8 zerg 2018-10-19 14:48:56 +0300 (В ответ на комментарий №7) > Если дату сборки убрать из алгоритма вычисления возраста пакетов Не-не! Убирать не надо. Я постоянно пользуюсь. Надо инфу про бранч сделать более приоритетной. 175159 9 rider 2018-10-19 14:51:53 +0300 Нет, ты не понял. Убрать надо только из алгоритма сравнения при pin-priority < 1000 (если такое возможно) Впрочем, я уже сказал. пусть ldv голову ломает, он себя умнее всех окружающсчитает. 175834 10 vseleznv 2018-11-15 22:55:14 +0300 Я хочу отметить, что сообщение с тем, что пакеты будут DOWNGRADED будет отображаться для большого количества пакетов только при обновления с последнего бранча платформ на Сизиф. При обновлении с бранча на следующий бранч количество таких пакетов будет незначительно, если вообще таковые будут. О такое поведении можно задокументировать в вики, оповестить в списке рассылки и описать в особенностях в QA на wiki. 175845 11 rider 2018-11-16 07:41:55 +0300 Можно, и нужно, но врятли это поможет - большое количество людей просто не пойдут искать информацию, почему у них массово доунгрейдятся пакеты при обновлении дистрибутива. И почему это не будет происходить при любом обновлении на новый бранч, вышедший на новом Sisyphus? Чем он хуже Sisyphus ? 175847 12 zerg 2018-11-16 10:01:33 +0300 Еще попробуйте поиграться c dist-upgrade c p8 до sisyphus, а потом обратно, а потом опять. 175880 13 vseleznv 2018-11-19 13:58:22 +0300 (In reply to comment #11) > Можно, и нужно, но врятли это поможет - большое количество людей просто не > пойдут искать информацию, почему у них массово доунгрейдятся пакеты при > обновлении дистрибутива. Я не готов давать свою оценку, но все эти рассуждения из области спекуляции. > И почему это не будет происходить при любом обновлении на новый бранч, вышедший > на новом Sisyphus? Потому что предыдущий бранч будет поддерживаться только в течении относительно небольшого времени, и вероятно поддержка будет касаться только исправления критических проблем и закрытия уязвимостей. Следовательно, новые релизы будут собираться и бекпортироваться значительно реже. > Чем он хуже Sisyphus ? Не знаю. Тем временем: #216554 — apt-conf-branch для p8, #215590 — apt-conf-sisyphus. 175881 14 rider 2018-11-19 14:00:20 +0300 (В ответ на комментарий №13) > (In reply to comment #11) > > > И почему это не будет происходить при любом обновлении на новый бранч, вышедший > > на новом Sisyphus? > > Потому что предыдущий бранч будет поддерживаться только в течении относительно > небольшого времени, и вероятно поддержка будет касаться только исправления > критических проблем и закрытия уязвимостей. Следовательно, новые релизы будут > собираться и бекпортироваться значительно реже. Да, но их уже набэкпортировано и собрано достаточно, что бы при обновлении с p8 на тот Sisyphus, который станет p9 - вылезло такое сообщение. 176530 15 rider 2018-12-08 11:05:53 +0300 Вот с таким конфигом обновляется. Когда ждать правильный preferences в пакете ? # cat /etc/apt/preferences Package: * Pin: release l=Sisyphus Pin-Priority: 1001 176598 16 vseleznv 2018-12-12 14:54:09 +0300 (In reply to comment #15) > Вот с таким конфигом обновляется. Когда ждать правильный preferences в пакете ? > > # cat /etc/apt/preferences > Package: * > Pin: release l=Sisyphus > Pin-Priority: 1001 По видимому, идея использовать механизм apt_preferences неудачная. Помимо смущающего сообщения про DOWNGRADE ещё проявляется куча проблем, такие как, например, "обновление" пакета, собранного локально, пакетов из репозитория, проблема из #35737 и др.. Прорабатываем новый механизм сравнения версий rpm-пакетов. 176773 17 asy 2018-12-18 09:16:46 +0300 (In reply to comment #16) > По видимому, идея использовать механизм apt_preferences неудачная. Может сама идея делать rebuild при копировании неудачная, а удобство сборки в разные бранчи, таким образом полученное, не стоит последствий? Или уж не знаю, может как-то автоматом время сборки в более новых бранчах повышать при таком процессе, хоть тем же rebuild. Но тут вопрос, справится ли борочница. 176774 18 rider 2018-12-18 09:27:43 +0300 Это не поможет. Нужно учитывать тэг дистрибутива в сравнении версий, если я правильно помню - этот вопрос поднимался в devel в другом контексте - использование этого тэга при сборке пакетов в спеке. Наверное, это можно было бы сделать, есть бы в RPMTAG_DISTTAG писался тэг, по имени которого можно проводить какое-то сравнение. Но там сейчас какая-то странная информация, не несущая никакой пользы для исправления этой ошибки: $ rpm -qp --qf '%{RPMTAG_DISTTAG}\n' p8/branch/x86_64/RPMS.classic/libmysqlclient20-5.7.24-alt1.x86_64.rpm p8.216685.100 $ rpm -qp --qf '%{RPMTAG_DISTTAG}\n' /mnt/ftp/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/libmysqlclient20-5.7.24-alt2.x86_64.rpm sisyphus.216505.700 А вот если б в этот тэг писать версию бранча (7,8 или 9 (для текущего Sisyphus)), которую не забывать увеличивать для каждой новой ветви - то её можно было бы использовать в сравнении версии. 176776 19 iv 2018-12-18 09:34:09 +0300 (In reply to comment #18) [...] > Наверное, это можно было бы сделать, есть бы в RPMTAG_DISTTAG писался тэг, по > имени которого можно проводить какое-то сравнение. Но там сейчас какая-то > странная информация, не несущая никакой пользы для исправления этой ошибки: [...] Отчего же? $ rpmevrcmp p8.216685.100 sisyphus.216505.700 -3 176777 20 rider 2018-12-18 09:35:12 +0300 Оттого, что придётся проводить пересборку всех пакетов в момент выпуска нового бранча. 176778 21 rider 2018-12-18 09:38:00 +0300 И да, у нас есть ещё ветки c и (возможно) t. $ rpmvercmp p8 c8 1 176779 22 iv 2018-12-18 09:52:32 +0300 (In reply to comment #20) > Оттого, что придётся проводить пересборку всех пакетов в момент выпуска нового > бранча. Почему Вы так считаете? Напомню, что это сравнение будет нужно только при равенстве %EVR -- новая версия пакета всегда дожна быть новее. То есть, disttag приходит на замену суффикса в релизе -- такой %ubt на стероидах. Так что того, что disttag в p8 < disttag в p9 < disttag в sisyphus достаточно. Переход между разными ветками с одной цифрой -- это другой вопрос. Он вообще когда-нибудь поддерживался? 176780 23 rider 2018-12-18 10:15:05 +0300 Пересборку ? да не для обновления конечно. У нас и сейчас в новой схеме нет возможности каким-то образом идентифицировать, для какого бранча был собран тот или иной пакет, а с DISTTAG это станет ещё тяжелее. Уж если это ubt на стероидах, то тогда точно надо пересобирать, хотя бы для того, что бы гарантировать неизменность пакета после пересборки. 176781 24 rider 2018-12-18 10:20:18 +0300 Но после пересборки произойдёт изменение тэга DISTTAG и де-факто - его уменьшение. Т.е. - те, у кого пакет был установлен с DISTTAG в sisyphus не смогут обновиться. Поэтому правильнее было бы сразу ставить тэг следующего бранча в sisyphus. Но что делать с сертифицированными ветками всё равно не очень понятно. 176782 25 zerg 2018-12-18 10:42:33 +0300 (В ответ на комментарий №21) > И да, у нас есть ещё ветки c и (возможно) t. > $ rpmvercmp p8 c8 Если сейчас неправильное поведение, значит нужно исправить наименование. 176863 26 7911 gbIMoBou 2018-12-20 10:23:53 +0300 Created attachment 7911 Расцветка синтаксиса Midnight Commander 176864 27 gbIMoBou 2018-12-20 10:26:09 +0300 Ой, вроде, новую создавал. Что-то пошло не так, прошу прощения. 176874 28 7911 asy 2018-12-20 15:41:19 +0300 Comment on attachment 7911 Расцветка синтаксиса Midnight Commander Это в bug 35799 176875 29 7911 zerg 2018-12-20 15:43:18 +0300 Comment on attachment 7911 Расцветка синтаксиса Midnight Commander . 176896 30 vseleznv 2018-12-21 19:27:52 +0300 (In reply to comment #18) > Это не поможет. Нужно учитывать тэг дистрибутива в сравнении версий, если я > правильно помню - этот вопрос поднимался в devel в другом контексте - > использование этого тэга при сборке пакетов в спеке. > > Наверное, это можно было бы сделать, есть бы в RPMTAG_DISTTAG писался тэг, по > имени которого можно проводить какое-то сравнение. Но там сейчас какая-то > странная информация, не несущая никакой пользы для исправления этой ошибки: > > $ rpm -qp --qf '%{RPMTAG_DISTTAG}\n' > p8/branch/x86_64/RPMS.classic/libmysqlclient20-5.7.24-alt1.x86_64.rpm > p8.216685.100 > > $ rpm -qp --qf '%{RPMTAG_DISTTAG}\n' > /mnt/ftp/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/libmysqlclient20-5.7.24-alt2.x86_64.rpm > sisyphus.216505.700 > > А вот если б в этот тэг писать версию бранча (7,8 или 9 (для текущего > Sisyphus)), которую не забывать увеличивать для каждой новой ветви - то её > можно было бы использовать в сравнении версии. Как раз-таки disttag планируется использовать для сравнении версии пакетов. В нём таки записан целевой бранч. Планируется в конфиг rpm ввести новую опцию конфигурации (формат пока не специфицирован), в которой записывалось отношение бранчей. (In reply to comment #20) > Оттого, что придётся проводить пересборку всех пакетов в момент выпуска нового > бранча. Может быть это не такая уж и плохая мысль. Получим пакеты, собранные в новом окружении, а те, что не пересоберутся — останутся такими же, как в исходном бранче. Но на самом деле это не обязательно: конфиг rpm может быть разным в зависимости от бранча. (In reply to comment #21) > И да, у нас есть ещё ветки c и (возможно) t. > $ rpmvercmp p8 c8 > 1 Планирует явно прописывать отношения между бранчами, а не лексиографическое сравнение. rpmvercmp для этого не подходит. Более того, предлагается описать отношения для все известных бранчей, но определять отношения только для бранчей одной линейки, т.е. p8 > p7, с8 > c7, но отношения межу p8 и c8 неопределено. Если для описания отношений использовать макрос (назовём его в примере relate_branch_version), то можно использовать символ ":" в качестве разделителя между линейками отношений, упорядоченных по возрастанию, например: relate_branch_version: p6 p7 p8 : c6 c7 c7.1 c8 c8.1 : t6 t7 При этом алгоритм сравнения версий пакетов предлагается таким: 1. Большая эпоха побеждает, иначе 2. Большая версия побеждает, иначе 3. Больший релиз побеждает, иначе 4. Если целевые бранчи пакетов сравнимы, то побеждает больший по порядку, в противном случае (т.е., случае, когда или бранчи совпадают, или они не сравнимы) 5. Больший buildtime побеждает Отмечу также, что самосборные пакеты, в которых disttag пустой, также будут устанавливаться и выигрывать при совпадении EVR сравниваться по пункту 5. 176898 31 rider 2018-12-21 19:41:45 +0300 Ну да, во первых непонятно как будут сравниваться самосборные пакеты. Во вторых, представим ситуацию, когда у нас странным образом в бранч p8 попал пакет, релиз которого взят из Sisyphus, но в бранч p9 этот пакет отправлен не был. Тогда обновления с p8 на p9 не будет (но его и сейчас нет, это правда). Ну а по сути то, что ты предлагаешь - это аналог pin-priority на уровне librpm. Сразу будет вопрос - в каких rpm'ах это придётся реализовать, как это повлияет на обновления в тех самых стабильных ветках, в которых тебе придётся поменять rpm и его логику сравнения. И как это повлияет на межпакетные зависимости. 176899 32 vseleznv 2018-12-21 19:56:00 +0300 (In reply to comment #31) > Ну да, во первых непонятно как будут сравниваться самосборные пакеты. Я явно написал, как будут сравниваться самосборные пакеты. > Во вторых, представим ситуацию, когда у нас странным образом в бранч p8 попал > пакет, релиз которого взят из Sisyphus, но в бранч p9 этот пакет отправлен не > был. Тогда обновления с p8 на p9 не будет (но его и сейчас нет, это правда). Странным образом он попасть не мог, только в процессе бранчевания. Или вы имеете в виду в результате команды task add copy? Обновление будет, если конфиг будет написан так. > Ну а по сути то, что ты предлагаешь - это аналог pin-priority на уровне librpm. Не совсем, но идеи похожи. > Сразу будет вопрос - в каких rpm'ах это придётся реализовать, как это повлияет > на обновления в тех самых стабильных ветках, в которых тебе придётся поменять > rpm и его логику сравнения. Реализовано будет во всем поддерживаемых бранчах. В пределах бранча логика не должна поменяться. > И как это повлияет на межпакетные зависимости. На межподпакетные в итоге никак, а на межпакетные — таким образом, как это описано алгоритмом. 176900 33 rider 2018-12-21 20:04:36 +0300 Я из этого описание не понял. Вообще, наверное было бы здорово дать возможность локально собирать пакеты с такими же межпакетными зависимостями и таким же DISTTAG, как и в репозитории. Иначе происходит странное - пересборка hasher'ом пакета из p8 в среде p8 меняет его зависимости. 176901 34 vseleznv 2018-12-21 20:17:56 +0300 (In reply to comment #33) > Я из этого описание не понял. > Вообще, наверное было бы здорово дать возможность локально собирать пакеты с > такими же межпакетными зависимостями и таким же DISTTAG, как и в репозитории. > Иначе происходит странное - пересборка hasher'ом пакета из p8 в среде p8 меняет > его зависимости. Можно в сборочной среде выставить значение переменной окружения RPM_STRICT_INTERDEPS. Пока вручную. Потом не надо будет: от неё я планирую избавиться в пользу значения тега disttag. 178036 35 rider 2019-02-01 08:09:11 +0300 улучшений пока не заметно. Ждём изменений в apt и rpm 178350 36 rider 2019-02-08 08:01:27 +0300 вчера с p8 до sisyphus не смог обновиться и с rpm из таска (который поддерживает новые виды зависимостей) и с preferences одновременно. - удалялась вся графическая подсистема. Воспроизвелось на workstation K 8.3, установленной в максимальной конфигурации. Попытки обновить apt+rpm тоже не приводили ни к чему хорошему. Когда ожидать починки rpm в p8 ? 178590 37 rider 2019-02-15 08:07:34 +0300 *** Bug 36109 has been marked as a duplicate of this bug. *** 179001 38 rider 2019-02-26 16:54:54 +0300 На данный момент обновление с p8 до Sisyphus работает, удаляется совсем чуть чуть и по причинам, не связанным с rpm. 179002 39 aen 2019-02-26 16:55:38 +0300 Ура! Спасибо! 179092 40 rider 2019-03-01 12:27:13 +0300 прошу прощения, был не прав - лучше не стало. 179096 41 imz 2019-03-01 12:47:30 +0300 (In reply to comment #40) > прошу прощения, был не прав - лучше не стало. На всякий случай скажу вещь, в которой я теперь уверен: обновляться до Sisyphus может иметь смысл только после обновления rpm сначала. По причине https://bugzilla.altlinux.org/show_bug.cgi?id=36180#c42 (потому что rpm-build не генерирует Provides старого формата): Even if in the i586 or x86_64 repo apt can dynamically construct an old-style disttag-less Provides, so that apt doesn't see an unmet dependency php7-ldap->php7-libs, rpm won't do this (I suppose). Old rpm would see this as an unmet dependency: the Provides has a disttag in the version string, but the Requires doesn't. (Only the generation of two Provides (one for compatibility) would make possible the use of old rpm with a repo with new packages.) (Для бранчей можно будет включить генерацию второго Provides, чтобы проще обновлять без предварительного обновления rpm можно было.) 179098 42 rider 2019-03-01 13:31:56 +0300 Да, стандартная схема обновления - обновиться полностью до бранча (включая rpm), потом обновить до Sisyphus. Или ты о чём-то другом ? 179099 43 rider 2019-03-01 13:36:56 +0300 Обновил до p8 перенастроил apt на Sisyphus. apt-get install apt - обновился apt+rpm и удалился apt-indicator. apt-get dist-upgrade удаляет больше четверти пакетов. Странно, вроде как если apt и rpm из Sisyphus, то всё должно начать работать нормально ? нет ? 179101 44 rider 2019-03-01 13:49:35 +0300 Мне кажется, что это проблема в https://bugzilla.altlinux.org/show_bug.cgi?id=36197 179102 45 imz 2019-03-01 13:50:17 +0300 (In reply to comment #42) > Да, стандартная схема обновления - обновиться полностью до бранча (включая > rpm), потом обновить до Sisyphus. Тут нужно сначала ещё новый rpm и/или apt поставить как шаг посередине. > Или ты о чём-то другом ? Я просто о том, что этот тест нельзя делать так же, как обновление внутри бранча. (А обновление внутри бранча надо тоже будет тестировать после включения генерации Provides нового вида.) Т.е. сейчас нельзя совместить эти два теста, примерно прикинуть, какие будут проблемы при обновлении внутри бранча. (Точнее и так понятно, что большие, если представить себе, что Sisyphus -- это примерно состояние бранча.) 179104 46 imz 2019-03-01 13:51:58 +0300 (In reply to comment #44) > Мне кажется, что это проблема в > https://bugzilla.altlinux.org/show_bug.cgi?id=36197 Не знаю. Там сначала какие-то файловые конфликты упомянуты, а их apt не видит. 179106 47 imz 2019-03-01 13:53:11 +0300 (In reply to comment #43) > Обновил до p8 > перенастроил apt на Sisyphus. > apt-get install apt - обновился apt+rpm и удалился apt-indicator. vseleznv@ подготовил новый apt, его нет в Sisyphus пока. > apt-get dist-upgrade удаляет больше четверти пакетов. > > Странно, вроде как если apt и rpm из Sisyphus, то всё должно начать работать > нормально ? нет ? Да (только apt из задания). 179107 48 rider 2019-03-01 13:55:50 +0300 Из какого задания ? Давай я попробую. Там файловые конфликты потому, что apt не справился с переездом библиотеки из libGL в libGLX-mesa. ему надо было просчитать, что libGLX-mesa надо тоже обновлять. 179108 49 rider 2019-03-01 13:58:54 +0300 Поставил apt из задания 223177 - ничего не изменилось. Проблема где-то в libGL, т.к. apt её хочет оставить (kept back), а это приводит явно к удалению всего, что от неё зависит. 179109 50 imz 2019-03-01 14:10:33 +0300 (In reply to comment #48) > Из какого задания ? Давай я попробую. > > Там файловые конфликты потому, что apt не справился с переездом библиотеки из > libGL в libGLX-mesa. ему надо было просчитать, что libGLX-mesa надо тоже > обновлять. Ясно, спасибо за понятное объяснение. Возможно, недоработка в обработке Obsoletes. Может касаться и rpm, и apt. Интересный test case. 181416 51 rider 2019-05-01 09:01:05 +0300 *** Bug 36711 has been marked as a duplicate of this bug. *** 181754 52 imz 2019-05-22 16:58:50 +0300 Хочется проверить с apt для p8 задание 229746 apt для sisyphus задание 229746 Порядок обновления я, конечно, предполагаю такой: сначала обновляем apt и rpm из p8, потом dist-upgrade из p8, потом обновляем apt и rpm из sisyphus, потом dist-upgrade из sisyphus. (Возможно, чтобы apt лучшим для нас образом просчитал обновление, нужно будет пересобрать некоторое множество пакетов в p8 с новым форматом строгих зависимостей. Такое предположение было -- из-за scoring в apt, но было и предположение, что это не важно.) 181755 53 rider 2019-05-22 17:13:15 +0300 Т.е.: - устанавливаем рабочую станцию 8.2 - обновляем её до p8 + задание 229746 - sources.list меняем на Sisyphus + задание 229746 - устанаваливаем apt + rpm из Sisyphus + задание 229746 - обновляем всё остальное. 181756 54 rider 2019-05-22 17:14:34 +0300 Для Sisyphus то какое задание ? 181766 55 imz 2019-05-22 18:43:57 +0300 (In reply to comment #52) > Хочется проверить с > > apt для p8 задание 229746 > apt для sisyphus задание 229746 я имел в виду 229767 для sisyphus (сейчас собирается) > > Порядок обновления я, конечно, предполагаю такой: > > сначала обновляем apt и rpm из p8, > потом dist-upgrade из p8, > потом обновляем apt и rpm из sisyphus, > потом dist-upgrade из sisyphus. > > (Возможно, чтобы apt лучшим для нас образом просчитал обновление, нужно будет > пересобрать некоторое множество пакетов в p8 с новым форматом строгих > зависимостей. Такое предположение было -- из-за scoring в apt, но было и > предположение, что это не важно.) 181767 56 imz 2019-05-22 18:50:33 +0300 (In reply to comment #53) > Т.е.: Да, такой вполне понятный порядок. > - устанавливаем рабочую станцию 8.2 Если делать всё очень пошагово, то здесь сначала можно - sources.list меняем на p8 + задание 229746 - устанаваливаем apt + rpm из p8 + задание 229746 > - обновляем её до p8 + задание 229746 > - sources.list меняем на Sisyphus + задание 229767 > - устанаваливаем apt + rpm из Sisyphus + задание 229767 > - обновляем всё остальное. Последние два шага можно (по моим предположениям) объединить -- не обновлять отдельно apt + rpm из Sisyphus. Тогда мы, кстати, проскочим проблему (пока ещё не решённую) с заменой симлинка благодаря pre-скриптам, если они написаны правильно. Оба варианта эксперимента, конечно, показательны. 181769 57 rider 2019-05-22 20:36:14 +0300 Важно проверить сценарий обновление дистрибутива до p8 + задание с apt/rpm, минуя точечное обновление до apt+rpm из задания. 181770 58 rider 2019-05-22 20:45:14 +0300 Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся - напиши пожалуйста. 181782 59 imz 2019-05-23 02:17:49 +0300 (In reply to comment #58) > Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся - > напиши пожалуйста. Я напишу. Надеюсь, скоро. Но для проверки обновления это, кажется, сейчас даже не принципиально. Можно просто сначала обновить до p8, потом до Sisyphus. (Просто в результиующей системе apt и rpm будут не очень хорошо работать при последующем использовании.) Потому что в процессе обновления apt и rpm из Sisyphus не используется. Алгоритм работы для p8 реализован такой же, как и для Sisyphus, поэтому необходимости использовать именно rpm и apt из Sisyphus не должно быть. 181784 60 imz 2019-05-23 04:28:44 +0300 (In reply to comment #43) > Обновил до p8 > перенастроил apt на Sisyphus. > apt-get install apt - обновился apt+rpm и удалился apt-indicator. > > apt-get dist-upgrade удаляет больше четверти пакетов. У меня, кстати, никогда при моих немногочисленных попытках воспроизвести это это не удавалось. Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере системы ALT Education ничего такого особенного apt-get dist-upgrade не предлагает снести. Так что надежды на тестирование теми, у кого получается вопроизвести пример, когда были проблемы. 181788 61 asy 2019-05-23 11:44:28 +0300 (In reply to comment #60) > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере > системы ALT Education ничего такого особенного apt-get dist-upgrade не > предлагает снести. На самом деле беда другая: просто не обновляет то, что надо обновить, так как пакеты из Sisyphus копируются посредством rebuild и получают более новую дату, чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого количества пакетов - это частный случай проявления. 181789 62 imz 2019-05-23 13:23:41 +0300 (In reply to comment #61) > (In reply to comment #60) > > > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере > > системы ALT Education ничего такого особенного apt-get dist-upgrade не > > предлагает снести. > > На самом деле беда другая: просто не обновляет то, что надо обновить, так как > пакеты из Sisyphus копируются посредством rebuild и получают более новую дату, > чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе > остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого > количества пакетов - это частный случай проявления. Эта беда, насколько я понял из своих проверок вчера, решается. Например, в моей системе на основе p8 после установки apt из задания для p8 после переключения на Sisyphus предлагается обновить пакет update-kernel (пример описанного Вами случая). В моей системе других таких пересобранных без смены релиза пакетов, похоже, попросту не было. 181792 63 m 2019-05-23 15:00:50 +0300 (В ответ на комментарий №61) > (In reply to comment #60) > > > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере > > системы ALT Education ничего такого особенного apt-get dist-upgrade не > > предлагает снести. > > На самом деле беда другая: просто не обновляет то, что надо обновить, так как > пакеты из Sisyphus копируются посредством rebuild и получают более новую дату, > чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе > остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого > количества пакетов - это частный случай проявления. А почему в Альте %EVR, а не %EVRD? Можно сделать D (distribution), если он отсутствует, то считать за ноль, грубо говоря, а приоритетным считать пакет, у которого есть D. 's' как раз больше p, поэтому без доп. хаков sisyphus будет выше pN. 181794 64 imz 2019-05-23 16:27:55 +0300 (In reply to comment #63) > (В ответ на комментарий №61) > > (In reply to comment #60) > > > > > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере > > > системы ALT Education ничего такого особенного apt-get dist-upgrade не > > > предлагает снести. > > > > На самом деле беда другая: просто не обновляет то, что надо обновить, так как > > пакеты из Sisyphus копируются посредством rebuild и получают более новую дату, > > чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе > > остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого > > количества пакетов - это частный случай проявления. > > А почему в Альте %EVR, а не %EVRD? Можно сделать D (distribution), если он > отсутствует, то считать за ноль, грубо говоря, а приоритетным считать пакет, у > которого есть D. 's' как раз больше p, поэтому без доп. хаков sisyphus будет > выше pN. Немного странно в Вашем предложении ссылаться на макросы (к ним не обращаются при определения направления обновления; хотя набор важных для этого значений изначально был таков), но мы такую вещь по сути и реализуем, если я Вас правильно понял. Предлагаемые для тестирования задания -- завершающий этап в этом деле. 181795 65 imz 2019-05-23 16:35:21 +0300 (In reply to comment #63) > (В ответ на комментарий №61) > > (In reply to comment #60) > > > > > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере > > > системы ALT Education ничего такого особенного apt-get dist-upgrade не > > > предлагает снести. > > > > На самом деле беда другая: просто не обновляет то, что надо обновить, так как > > пакеты из Sisyphus копируются посредством rebuild и получают более новую дату, > > чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе > > остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого > > количества пакетов - это частный случай проявления. > > А почему в Альте %EVR, а не %EVRD? Можно сделать D (distribution), если он > отсутствует, то считать за ноль, грубо говоря, а приоритетным считать пакет, у > которого есть D. 's' как раз больше p, поэтому без доп. хаков sisyphus будет > выше pN. Без лишних хаков просто сравнивать эти строки нельзя. Изначально разделители в строке %EVR такие: E:V-R; сравнивать надо покомпонентно. Теперь в APT необходимая для определения направления обновления информация будет представлена строками формата E:V-R:D@T (D -- disttag, T -- buildtime). Обучить новым разделителям надо. Но в rpm, как я говорил, вообще не строки сравниваются, а набор отдельных значений. Обучить тому, что в этом tuple появятся ещё дополнительные значения, тоже нужно. Так что без хаков такое поведение не получишь. Можно релизы специальным образом формировать с похожим эффектом (но не %EVR, а просто Release) -- таков был подход %ubt. 181796 66 m 2019-05-23 17:01:31 +0300 (В ответ на комментарий №65) > Немного странно в Вашем предложении ссылаться на макросы (к ним не обращаются > при определения направления обновления; хотя набор важных для этого значений > изначально был таков), но мы такую вещь по сути и реализуем, если я Вас > правильно понял. Я имел в виду RPMTAG_DISTEPOCH, в Альте такого нет 181798 67 imz 2019-05-23 17:08:24 +0300 (In reply to comment #66) > (В ответ на комментарий №65) > > Немного странно в Вашем предложении ссылаться на макросы (к ним не обращаются > > при определения направления обновления; хотя набор важных для этого значений > > изначально был таков), но мы такую вещь по сути и реализуем, если я Вас > > правильно понял. > Я имел в виду RPMTAG_DISTEPOCH, в Альте такого нет Мы стали использовать RPMTAG_DISTTAG 181832 68 rider 2019-05-24 16:16:28 +0300 С rpm+apt из задания 229746 обновление с p8 до Sisyphus проходит почти гладко (удаляется 22 пакета и там надо смотреть причину удаления по каждому из них). update-kernel поломатый - всегда хочет обновлять ядра. Теперь ждём apt+rpm для Sisyphus. 181839 69 imz 2019-05-24 20:14:52 +0300 (In reply to comment #68) > С rpm+apt из задания 229746 обновление с p8 до Sisyphus проходит почти гладко > (удаляется 22 пакета и там надо смотреть причину удаления по каждому из них). > > update-kernel поломатый - всегда хочет обновлять ядра. Планируется доделать rpm и это должно уйти. Вот у меня задание 229527 не со всеми фичами в apt (disttag-и не сравнивает), промежуточное для тестирования нового подхода. Заодно я туда поместил сейчас rpm. Предположение касательно проблемы с update-kernel такое: Если установить только apt из 229527 в Sisyphus, то проблема update-kernel воспроизведётся в Sisyphus. Если установить ещё и rpm 229527, то проблема уйдёт, потому что rpm -q будет вопринимать строки вида kernel-image-std-def-4.9.177-alt0.M80P.1@1558091468 > Теперь ждём apt+rpm для Sisyphus. 181896 70 imz 2019-05-27 19:29:51 +0300 (In reply to comment #58) > Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся - > напиши пожалуйста. Собралось 229767 181918 71 imz 2019-05-28 11:00:43 +0300 Для Sisyphus нашёл проблему, сделал другое задание: 230598 182055 72 rider 2019-05-31 11:22:26 +0300 С apt+rpm из задания 229746 p8 до Sisyphus обновляется более-менее корректно (удаляется только kdeenlive из нужного). Но я проверял только один сценарий обновления. 182061 73 aen 2019-05-31 12:38:13 +0300 (В ответ на комментарий №72) > С apt+rpm из задания 229746 p8 до Sisyphus обновляется более-менее корректно > (удаляется только kdeenlive из нужного). > > > Но я проверял только один сценарий обновления. Будем надеяться. :) 182140 74 ildar 2019-06-03 13:55:05 +0300 (In reply to comment #71) > Для Sisyphus нашёл проблему, сделал другое задание: > > 230598 на этом апте проапгрейдился с p8 до Sisyphus. Успешно. Но не могу завести hasher, не видит пакета setup. Может кто-нибудь проверить, пожалуйста? Или дайте умный совет, как продиагностировать. 182143 75 imz 2019-06-03 14:02:49 +0300 (In reply to comment #74) > (In reply to comment #71) > > Для Sisyphus нашёл проблему, сделал другое задание: > > > > 230598 > > на этом апте проапгрейдился с p8 до Sisyphus. Успешно. > Но не могу завести hasher, не видит пакета setup. Может кто-нибудь проверить, > пожалуйста? Или дайте умный совет, как продиагностировать. Спасибо за тестирование! Скажите, что в sources.list для hasher и какой командой запускаете? 182144 76 ildar 2019-06-03 14:09:48 +0300 (In reply to comment #75) > Скажите, что в sources.list для hasher и какой командой запускаете? $ hsh $TMP/hasher ~/Projects/RPM/SRPMS/*rpm > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic Пробовал ./apt-cache show setup : тишина. Я так понимаю, что у Вас hasher работает? 182145 77 imz 2019-06-03 14:20:42 +0300 (In reply to comment #76) > (In reply to comment #75) > > Скажите, что в sources.list для hasher и какой командой запускаете? > > $ hsh $TMP/hasher ~/Projects/RPM/SRPMS/*rpm > > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic > > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic > > Пробовал ./apt-cache show setup : тишина. > Я так понимаю, что у Вас hasher работает? Может, не в точности на этой сборке, но на похожей вроде работало. Попробуйте $TMP/hasher/aptbox/apt-get update 182146 78 imz 2019-06-03 14:40:21 +0300 (In reply to comment #76) > (In reply to comment #75) > > Скажите, что в sources.list для hasher и какой командой запускаете? > > $ hsh $TMP/hasher ~/Projects/RPM/SRPMS/*rpm > > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic > > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic > > Пробовал ./apt-cache show setup : тишина. > Я так понимаю, что у Вас hasher работает? Перепроверил. Работает с apt и rpm из этого задания. Правда, у меня sources.list не по http, а file. (Но в этом задании как раз не было ещё изменений в http. Проверю на всякий случай.) 182147 79 imz 2019-06-03 14:57:21 +0300 (In reply to comment #78) > (In reply to comment #76) > > (In reply to comment #75) > > > Скажите, что в sources.list для hasher и какой командой запускаете? > > > > $ hsh $TMP/hasher ~/Projects/RPM/SRPMS/*rpm > > > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic > > > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic > > > > Пробовал ./apt-cache show setup : тишина. > > Я так понимаю, что у Вас hasher работает? > > Перепроверил. Работает с apt и rpm из этого задания. > > Правда, у меня sources.list не по http, а file. (Но в этом задании как раз не > было ещё изменений в http. Проверю на всякий случай.) Это у меня так и не вопроизвелось. Проверьте rpm -q rpm --lastchange, пожалуйста. И попробуйте $TMP/hasher/aptbox/apt-get update Какая ещё диагностика может быть полезна?.. $TMP/hasher/aptbox/apt-cache show setup молчит в каком смысле? Завершается ли (с каким кодом?) или висит? Если висит, то что, например, покажет strace -f -y $TMP/hasher/aptbox/apt-cache show setup 182168 80 ildar 2019-06-04 10:04:58 +0300 (In reply to comment #74) > > 230598 > Но не могу завести hasher, не видит пакета setup. Может кто-нибудь проверить, > пожалуйста? Или дайте умный совет, как продиагностировать. Прошу прощения, это локальная проблема: частично обновлённый сизиф. Обновление gpg решило проблему. 182238 81 imz 2019-06-05 21:52:36 +0300 Для Sisyphus задание-кандидат на то, чтобы стать окончательным (без учёта проблемы замены симлинков на директории) -- 231427 Можно потестировать обновление, поставив apt из него. 182240 82 rider 2019-06-05 21:55:54 +0300 Вань, я правильно понял что с ним не нужно обновлять p8 до задания с apt/rpm ? 182241 83 imz 2019-06-05 22:06:56 +0300 (In reply to comment #82) > Вань, я правильно понял что с ним не нужно обновлять p8 до задания с apt/rpm ? Должно быть не нужно теоретически (но я как правило в таких случаях поступаю иначе: сначала ставлю свежий из старого бранча, а потом перехожу на новый бранч). Правда, проблема с заменой симлинка на директорию вылезет, если использовать rpm-4.13 из Sisyphus. 182242 84 rider 2019-06-05 22:12:13 +0300 А это значит, что обновление у меня не пройдёт. Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками. 182243 85 imz 2019-06-05 22:16:14 +0300 (In reply to comment #84) > А это значит, что обновление у меня не пройдёт. > Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками. Я сейчас скоро ещё для p8 сделаю сборку, можно будет тот и этот заодно протестировать. 182244 86 rider 2019-06-05 22:17:43 +0300 Да, давай попробуем rpm из p8 обновиться до Sisyphus. 182300 87 imz 2019-06-07 22:01:57 +0300 (In reply to comment #81) > Для Sisyphus задание-кандидат на то, чтобы стать окончательным (без учёта > проблемы замены симлинков на директории) -- 231427 > > Можно потестировать обновление, поставив apt из него. Для p8 -- 229746. Можно потестировать обновление, поставив apt из него. 182389 88 imz 2019-06-13 15:01:23 +0300 (In reply to comment #84) > А это значит, что обновление у меня не пройдёт. > Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками. В Sisyphus сейчас закоммитится. Для p9 сразу же после этого будет задание (в EPERM) 231608. Можно потестировать обновление с p8 до p9 после установки apt из него. Для p8 всё так же задание 229746. Можно потестировать обновление с p8 до p9 после установки apt из него. (Оно и симлинк сможет заменить на директорию.) 182742 89 imz 2019-06-27 14:26:54 +0300 (In reply to comment #83) > Правда, проблема с заменой симлинка на директорию вылезет, если использовать > rpm-4.13 из Sisyphus. Для обновления gdb в связи с заменой симлинка https://bugzilla.altlinux.org/show_bug.cgi?id=35492 добавлен прескрипт в задании 233277. Это поможет при rpm-4.0.4 (из p8). Теперь можно попробовать такой сценарий обновления: * допустим, в системе на p8 установлен gdb в начале обновления (и lua). * в p8 сделать dist-upgrade * переключиться на Sisyphus или p9, добавить задание 233277, сделать dist-upgrade 187094 90 lav 2020-01-20 21:19:09 +0300 Возможно, что всё уже решилось? 187095 91 rider 2020-01-21 06:42:18 +0300 теперь сломано обновление с p9 до sisyphus 193392 92 lav 2020-10-21 14:21:10 +0300 (Ответ для Anton Farygin на комментарий #91) > теперь сломано обновление с p9 до sisyphus Не подтверждаю... Как раз сейчас обновляю до Сизифа, потом откатываю до p9, потом опять до Сизифа... 193393 93 rider 2020-10-21 14:23:21 +0300 Это зависит от установленных пакетов. Иногда везёт иногда нет. Ну и если %_priority_distbranch прописывать до обновления, то тоже всё в целом неплохо. 193405 94 asy 2020-10-21 17:59:22 +0300 (In reply to Anton Farygin from comment #91) > теперь сломано обновление с p9 до sisyphus Может это другим багом? В p8 и rpm другой, которым обновление до p9 делается. Вчера и сегодня несколько хостов с p8 до p9 обновил беспроблемно как раз. Без X правда все. Зато один с Апачем и MariaDB. 193408 95 rider 2020-10-21 19:20:12 +0300 Нет, ошибка та же самая и по тем же причинам, просто теперь она в p9 -> sisyphus. ну и не так кардинально как раньше. p8 до p9 обновляется при этом хорошо. 229656 96 rider 2023-07-13 14:09:25 +0300 Теперь сломано обновление с p10 до Sisyphus, если установить, например, рабочую станцию 10.1 и попробовать обновить. 248312 97 antohami 2024-06-28 17:07:23 +0300 (Ответ для Anton Farygin на комментарий #96) > Теперь сломано обновление с p10 до Sisyphus, если установить, например, > рабочую станцию 10.1 и попробовать обновить. Обновление с p10 на Сизиф после бранчевания p11 не поддерживается. Нужно сначала обновиться до p11, а потом до Сизифа. Обновление с p10 до p11 и затем до Сизифа проходит успешно. Считаю проблему решённой. 248317 98 rider 2024-06-28 17:57:43 +0300 Теперь надо не забыть переоткрыть как сломается с p11 до sisyphus. 7911 2018-12-20 10:23:53 +0300 2018-12-20 15:43:18 +0300 Расцветка синтаксиса Midnight Commander Syntax.diff text/plain 921 gbIMoBou LS0tIC91c3Ivc2hhcmUvbWMvc3ludGF4L1N5bnRheC5vcmlnCTIwMTgtMTEtMTMgMTY6NTQ6NTEu MDAwMDAwMDAwICswODAwCisrKyAvdXNyL3NoYXJlL21jL3N5bnRheC9TeW50YXgJMjAxOC0xMi0y MCAxNToyMTowMS44MTEzNzA4NTcgKzA4MDAKQEAgLTM3LDkgKzM3LDEyIEBACiBmaWxlIC4uXCpc XC5sc20kIExTTVxzRmlsZQogaW5jbHVkZSBsc20uc3ludGF4CiAKLWZpbGUgLlwqKGJhc2hfY29t cGxldGlvbnxwcm9maWxlfFxcLihzaHxiYXNoX2xvZ2lufGJhc2hfcHJvZmlsZXxiYXNoX2xvZ291 dHxiYXNoX2FsaWFzZXN8YmFzaF9leHBvcnRzfGJhc2hfaGlzdG9yeXxiYXNocmN8cHJvZmlsZXx6 bG9naW58emxvZ291dHx6cHJvZmlsZXx6c2hlbnZ8enNocmMpKSQgU2hlbGxcc1NjcmlwdCBeIyFc c1wqLyguXCovfHVzci9iaW4vZW52XHMpKFthLXpdP3xiYXxwZGspc2gKK2ZpbGUgLlwqKGJhc2go X2NvbXBsZXRpb258cmMpfHByb2ZpbGV8XFwuKHNofGJhc2gocmN8Xyhjb21wbGV0aW9ufHByb2Zp bGV8bG9nKGlufG91dCl8YWxpYXNlc3xleHBvcnRzfGhpc3RvcnkpKXxwcm9maWxlfHpsb2coaW58 b3V0KXx6cHJvZmlsZXx6c2goZW52fHJjKSkpJCBTaGVsbFxzU2NyaXB0IF4jIVxzXCovKC5cKi98 dXNyL2Jpbi9lbnZccykoW2Etel0/fGJhfHBkaylzaAogaW5jbHVkZSBzaC5zeW50YXgKIAorZmls ZSAuLlwqXFwuKGJ1c25hbWV8KGF1dG8pP21vdW50fG5ldChkZXZ8d29yayl8bGlua3xwYXRofHNl cnZpY2V8c2xpY2V8c29ja2V0fHN3YXB8dGFyZ2V0fHRpbWVyKSQgU3lzdGVtRFxzQ29uZmlnCitp bmNsdWRlIGluaS5zeW50YXgKKwogZmlsZSAuLlwqXFwuKCg/aTpwbHxwbXxwc2dpKXx0KSQgUGVy bFxzUHJvZ3JhbSBeIyEuXCooW1xzL11wZXJsfC91c3IvYmluL3BlcmwpCiBpbmNsdWRlIHBlcmwu c3ludGF4CiAK