$subj Скорее всего это связано с https://bugzilla.altlinux.org/show_bug.cgi?id=38791#c13 и https://bugzilla.altlinux.org/show_bug.cgi?id=38791#c21 Лог ошибки: http://git.altlinux.org/tasks/259989/build/200/x86_64/srpm.log В нём есть следующая строка: <13>Oct 16 11:46:14 rpmi: llvm10.0-devel-10.0.1-alt2 sisyphus+256264.100.7.1 1598863527 installed Вместо llvm10.0-devel ожидается llvm11.0-devel. При локальной сборке через hasher проблема не воспроизводится. Проблема проявляется исключительно на сборочнице.
Честно говоря, я не в курсе, как сейчас на сборочнице обстоят дела с llvm.
К сожалению, при действующей схеме упаковки llvm дефолтная версия llvm вынужденно прибита гвоздями прямо в сборочной системе и влияет сразу на все репозитории. Исправить это можно только одним способом: перейти на схему упаковки llvm, используемую для gcc.
Поскольку над заданием 259989 я продолжаю работать, документирую другой способ воспроизведения проблемы. http://git.altlinux.org/gears/c/castxml.git?p=castxml.git;a=blob;f=.gear/castxml.spec;h=87a7c818fdc62dbe0c60bde5cb3330ef68b86367;hb=0c4e80cbd9afff5dc0d653be5bb4022dc7510576#l15 Здесь указано llvm-devel без явной версии. В логе ежедневной пересборки: http://git.altlinux.org/beehive/logs/Sisyphus-x86_64/latest/success/castxml-0.3.6-alt1 <13>Oct 20 05:41:20 rpmi: llvm10.0-devel-10.0.1-alt2 sisyphus+256264.100.7.1 1598863527 installed Ожидается, аналогично примеру выше, llvm11.0-devel на текущий момент.
В тестовой пересборке, как и в основной, следующие пакеты прибиты гвоздями: clang10.0 clang10.0-analyzer clang10.0-devel clang10.0-devel-static clang10.0-doc clang10.0-libs lld10.0 lld10.0-devel lld10.0-doc llvm10.0 llvm10.0-devel llvm10.0-devel-static llvm10.0-doc llvm10.0-libs Гвозди по сути одинаковые, но прибиты в двух разных местах.
(Ответ для Dmitry V. Levin на комментарий #2) > К сожалению, при действующей схеме упаковки llvm дефолтная версия llvm > вынужденно прибита гвоздями прямо в сборочной системе и влияет сразу на все > репозитории. Исправить это можно только одним способом: перейти на схему > упаковки llvm, используемую для gcc. Тут дело не только в схеме сборки llvm, но и в выборе виртуального пакета llvm-devel и других таких пакетов через виртуальные provide с помощью hasher, который в свою очередь использует для этого apt. Например, сейчас в p9 есть llvm10.0-devel-10.0.0-alt0.1.p9 с виртуальным provide "llvm-devel = 10.0.0-alt0.1.p9" и llvm7.0-devel-7.0.1-alt4.rel с виртуальным provide "llvm-devel = 7.0.1-alt4.rel". Насколько я помню, из-за кривого алгоритма сравнения, т.е. фактически посимвольного сравнения, в apt версия 7.0.1-alt4.rel внезапно оказывается "выше" чем 10.0.0-alt0.1.p9, поскольку "7 > 1", и выбирается на самом деле более старая версия llvm-devel. > Исправить это можно только одним способом: ... Если это сравнение версий исправить, то костыли в сборочнице больше не будут нужны. Что-то мешает исправлению данной проблемы через исправление связки hasher+apt?
(In reply to Aleksei Nikiforov from comment #5) > Что-то мешает исправлению данной проблемы через исправление связки > hasher+apt? Оставляя в стороне ваш анализ ситуации с выбором пакетов, могу заметить, что hasher к выбору пакетов отношения не имеет. Что касается каких-либо нетривиальных изменений в apt, то их намертво заблокировал packagekit, за что вам отдельное спасибо.
(Ответ для Dmitry V. Levin на комментарий #6) > (In reply to Aleksei Nikiforov from comment #5) > > Что-то мешает исправлению данной проблемы через исправление связки > > hasher+apt? > > Оставляя в стороне ваш анализ ситуации с выбором пакетов, могу заметить, что > hasher к выбору пакетов отношения не имеет. > hasher делегирует резолвинг пакетов и их версий apt-у, т.е. косвенно участвует в этом процессе. > Что касается каких-либо нетривиальных изменений в apt, то их намертво > заблокировал packagekit, за что вам отдельное спасибо. И это заявление тоже не соответствует действительности.
(In reply to Aleksei Nikiforov from comment #5) > Насколько я помню, из-за кривого алгоритма сравнения, т.е. фактически > посимвольного сравнения, в apt версия 7.0.1-alt4.rel внезапно оказывается > "выше" чем 10.0.0-alt0.1.p9, поскольку "7 > 1", и выбирается на самом деле > более старая версия llvm-devel. Нет, apt использует rpmvercmp() из librpm, поэтому 7.0.1-alt4.rel должно быть меньше, чем 10.0.0-alt0.1.p9. Или я неправильно понял проблему?
(Ответ для Vladimir D. Seleznev на комментарий #8) > (In reply to Aleksei Nikiforov from comment #5) > > Насколько я помню, из-за кривого алгоритма сравнения, т.е. фактически > > посимвольного сравнения, в apt версия 7.0.1-alt4.rel внезапно оказывается > > "выше" чем 10.0.0-alt0.1.p9, поскольку "7 > 1", и выбирается на самом деле > > более старая версия llvm-devel. > > Нет, apt использует rpmvercmp() из librpm, поэтому 7.0.1-alt4.rel должно > быть меньше, чем 10.0.0-alt0.1.p9. Или я неправильно понял проблему? Возможно, где-то и используется, но похоже не везде. Воспроизведение этой проблемы в apt (и hasher) простое. Берём виртуалку (или реальную машину) с p9, полностью обновлённую, без установленных пакетов llvm*-devel. # apt-get install llvm-devel Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Виртуальный пакет llvm-devel предоставляется следующими пакетами: llvm7.0-devel p9+229920.100.1.1@1558623861 llvm10.0-devel p9+251708.500.4.1@1589910711 Необходимо точно указать, какой из пакетов должен быть установлен. E: Виртуальный пакет llvm-devel предоставляется многими пакетами. Можно заметить, что llvm7.0-devel стоит выше, чем llvm10.0-devel. hasher вызывает примерно такую-же команду, но с какими-то дополнительными опциями или настройками чтобы apt не выходил с ошибкой, а устанавливал самую свежую версию (верхнюю из такого списка). Та же самая команда на свежем Сизифе: # apt-get install llvm-devel Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Виртуальный пакет llvm-devel предоставляется следующими пакетами: llvm11.0-devel sisyphus+259849.100.1.1@1602620070 llvm10.0-devel sisyphus+256264.100.7.1@1598863527 Необходимо точно указать, какой из пакетов должен быть установлен. E: Виртуальный пакет llvm-devel предоставляется многими пакетами. Можно убедиться в описаном выше предположении. Поставил на эту же машину с p9 hasher и добавил пользователю нужные настройки через hasher-useradd и перелогинился. $ hsh --initroot-only $ hsh-install llvm-devel В выводе будет llvm7.0-devel, а не llvm10.0-devel. Из-за этой проблемы, похоже, на сборочницу был вкорячен костыль для выбора llvm10.0 вместо llvm9.0 или llvm7.0, и теперь он даёт о себе знать, выбирая на сборочнице llvm10.0 вместо llvm11.0. А локально всё в порядке.
(In reply to Aleksei Nikiforov from comment #9) > (Ответ для Vladimir D. Seleznev на комментарий #8) > > (In reply to Aleksei Nikiforov from comment #5) > > > Насколько я помню, из-за кривого алгоритма сравнения, т.е. фактически > > > посимвольного сравнения, в apt версия 7.0.1-alt4.rel внезапно оказывается > > > "выше" чем 10.0.0-alt0.1.p9, поскольку "7 > 1", и выбирается на самом деле > > > более старая версия llvm-devel. > > > > Нет, apt использует rpmvercmp() из librpm, поэтому 7.0.1-alt4.rel должно > > быть меньше, чем 10.0.0-alt0.1.p9. Или я неправильно понял проблему? > > Возможно, где-то и используется, но похоже не везде. > > Воспроизведение этой проблемы в apt (и hasher) простое. > > Берём виртуалку (или реальную машину) с p9, полностью обновлённую, без > установленных пакетов llvm*-devel. > > # apt-get install llvm-devel > Чтение списков пакетов... Завершено > Построение дерева зависимостей... Завершено > Виртуальный пакет llvm-devel предоставляется следующими пакетами: > llvm7.0-devel p9+229920.100.1.1@1558623861 > llvm10.0-devel p9+251708.500.4.1@1589910711 > Необходимо точно указать, какой из пакетов должен быть установлен. > E: Виртуальный пакет llvm-devel предоставляется многими пакетами. > > Можно заметить, что llvm7.0-devel стоит выше, чем llvm10.0-devel. hasher > вызывает примерно такую-же команду, но с какими-то дополнительными опциями > или настройками чтобы apt не выходил с ошибкой, а устанавливал самую свежую > версию (верхнюю из такого списка). > > Та же самая команда на свежем Сизифе: > # apt-get install llvm-devel > Чтение списков пакетов... Завершено > Построение дерева зависимостей... Завершено > Виртуальный пакет llvm-devel предоставляется следующими пакетами: > llvm11.0-devel sisyphus+259849.100.1.1@1602620070 > llvm10.0-devel sisyphus+256264.100.7.1@1598863527 > Необходимо точно указать, какой из пакетов должен быть установлен. > E: Виртуальный пакет llvm-devel предоставляется многими пакетами. > > Можно убедиться в описаном выше предположении. Поставил на эту же машину с > p9 hasher и добавил пользователю нужные настройки через hasher-useradd и > перелогинился. > > $ hsh --initroot-only > $ hsh-install llvm-devel > > В выводе будет llvm7.0-devel, а не llvm10.0-devel. Попробовал на Сизифе. Не воспроизвелось: $ hsh --ini [...skip...] $ hsh-install llvm-devel <13>Oct 21 12:06:31 rpmi: llvm11.0-libs-11.0.0-alt1 sisyphus+259849.100.1.1 1602620070 installed <13>Oct 21 12:06:37 rpmi: clang11.0-libs-11.0.0-alt1 sisyphus+259849.100.1.1 1602620070 installed <13>Oct 21 12:06:38 rpmi: llvm11.0-11.0.0-alt1 sisyphus+259849.100.1.1 1602620070 installed <13>Oct 21 12:06:39 rpmi: llvm11.0-devel-11.0.0-alt1 sisyphus+259849.100.1.1 1602620070 installed Попробовал ещё три раза после этого: результат такой же. Для репозитория p9 действительно hsh-install llvm-devel устанавливает llvm7.0-devel. Очень странно, надо исследовать.
(Ответ для Vladimir D. Seleznev на комментарий #10) > Попробовал на Сизифе. Не воспроизвелось: > Релевантный отрывок из https://bugzilla.altlinux.org/show_bug.cgi?id=39087#c9: > теперь он даёт о себе знать, выбирая на сборочнице llvm10.0 вместо llvm11.0. А локально всё в порядке. Акцентирую: "А локально всё в порядке." > $ hsh --ini > [...skip...] > $ hsh-install llvm-devel > <13>Oct 21 12:06:31 rpmi: llvm11.0-libs-11.0.0-alt1 sisyphus+259849.100.1.1 > 1602620070 installed > <13>Oct 21 12:06:37 rpmi: clang11.0-libs-11.0.0-alt1 sisyphus+259849.100.1.1 > 1602620070 installed > <13>Oct 21 12:06:38 rpmi: llvm11.0-11.0.0-alt1 sisyphus+259849.100.1.1 > 1602620070 installed > <13>Oct 21 12:06:39 rpmi: llvm11.0-devel-11.0.0-alt1 sisyphus+259849.100.1.1 > 1602620070 installed > > Попробовал ещё три раза после этого: результат такой же. > > Для репозитория p9 действительно hsh-install llvm-devel устанавливает > llvm7.0-devel. Очень странно, надо исследовать. А на сборочнице вместо llvm7.0-devel в p9 будет llvm10.0-devel, скорее всего.
(In reply to Dmitry V. Levin from comment #4) > В тестовой пересборке, как и в основной, следующие пакеты прибиты гвоздями: > > clang10.0 > clang10.0-analyzer > clang10.0-devel > clang10.0-devel-static > clang10.0-doc > clang10.0-libs > lld10.0 > lld10.0-devel > lld10.0-doc > llvm10.0 > llvm10.0-devel > llvm10.0-devel-static > llvm10.0-doc > llvm10.0-libs > > Гвозди по сути одинаковые, но прибиты в двух разных местах. В качестве "временного" решения можно добавить в этот список аналогичные имена с 11.0.
(In reply to Dmitry V. Levin from comment #2) > К сожалению, при действующей схеме упаковки llvm дефолтная версия llvm > вынужденно прибита гвоздями прямо в сборочной системе и влияет сразу на все > репозитории. Исправить это можно только одним способом: перейти на схему > упаковки llvm, используемую для gcc. Задание http://webery.altlinux.org/263468, помимо своих прочих преимуществ, призвано разрешить эту багу для мажорных версий llvm >= 11.
Тем временем 1-го ноября были добавлены коммиты (girar 0fdadcc20a0e9d83102a87aae06646b2a1dcc3df, beehive d09ca702ea5adbcbb3da7469f60e4dc5d21789ce) с говздями про clang11/llvm11.
(Ответ для Dmitry V. Levin на комментарий #14) > Тем временем 1-го ноября были добавлены коммиты (girar > 0fdadcc20a0e9d83102a87aae06646b2a1dcc3df, beehive > d09ca702ea5adbcbb3da7469f60e4dc5d21789ce) с говздями про clang11/llvm11. И похоже это не сработало: http://git.altlinux.org/tasks/266163/build/100/x86_64/srpm.log <13>Feb 11 07:23:34 rpmi: clang10.0-10.0.1-alt2 sisyphus+256264.100.7.1 1598863527 installed <13>Feb 11 07:23:34 rpmi: clang10.0-devel-10.0.1-alt2 sisyphus+256264.100.7.1 1598863527 installed <13>Feb 11 07:23:35 rpmi: llvm10.0-10.0.1-alt2 sisyphus+256264.100.7.1 1598863527 installed <13>Feb 11 07:23:35 rpmi: llvm10.0-devel-10.0.1-alt2 sisyphus+256264.100.7.1 1598863527 installed http://git.altlinux.org/tasks/266163/gears/100/git?p=git;a=blob;f=.gear/castxml.spec;h=46e76ca884ce5264cf8fe2d32b4bbe384e214d62;hb=ba8a08ae66c9897db8bf3fcb52a0ba15c846be89#l15 15 BuildRequires: llvm-devel lld 16 # The llvm cmake files get confused if the static libraries are 17 # not present even though we don't link against them. 18 BuildRequires: llvm-devel-static 19 BuildRequires: clang-devel 20 # Required clang libraries are built statically at the moment 21 BuildRequires: clang-devel-static
Отмечу, что только что ещё раз взял и проверил локальную сборку. На текущем Сизифе и локально приезжает llvm10.0... Стал проверять и заметил следующее: При использовании архива за 2020/10/15 с llvm11.0-11.0.0-alt1 локально приезжает llvm11.0-devel/clang11.0-devel. При использовании архива за 2020/01/10 с llvm11.0-11.0.0-alt2 локально уже приезжает llvm10.0-devel/clang10.0-devel. С учётом того, что теперь проблема воспроизводится локально, нельзя определить точно есть ли проблема на сборочнице. Вполне возможно, что указанные ранее коммиты поправили её. Также есть небольшая вероятность, что сборка llvm11.0-11.0.0-alt2 могла вновь внести эту проблему и на сборочницу.
(Ответ для Aleksei Nikiforov на комментарий #16) > При использовании архива за 2020/01/10 с llvm11.0-11.0.0-alt2 локально уже > приезжает llvm10.0-devel/clang10.0-devel. 2020/01/10 -> 2021/01/10
Так, с появлением llvm-common-* старые гвозди стали мешать. Осталось понять, достаточно ли их просто удалить, или теперь вместо них надо прибить гвоздями llvm-common-*?
(Ответ для Dmitry V. Levin на комментарий #18) > Так, с появлением llvm-common-* старые гвозди стали мешать. > Осталось понять, достаточно ли их просто удалить, или теперь вместо них надо > прибить гвоздями llvm-common-*? Я думаю, лучшим вариантом было бы сначала решить проблему при локальной сборке, а уже затем смотреть надо ли что-либо дополнительно делать на стороне сборочницы. Эта бага была мной создана именно из-за расхождения поведения на сборке локально и на сборочнице. Сейчас такого расхождения не видно на Сизифе. Ещё, если бы Вы об этих изменениях на сборочнице сообщили раньше, можно было бы все пакеты уже давно без проблем пересобрать с llvm11.0 и при отсутствии необходимости - удалить llvm10.0 из Сизифа. Или же Вы могли сами пересобрать эти пакеты. Я уверен, что почти для всех достаточно было сделать пересборку без всяких изменений. К сожалению, возможность была упущена, а у меня самостоятельно узнать о том, что на сборочнице данная проблема была исправлена, возможности не было.
Поменял гвозди, результат: $ echo clang10.0 |join -11 -22 -o2.1 - /beehive/stats/Sisyphus-x86_64/ufb-2 |join -t$'\t' - /ALT/acl/list.packages.sisyphus bcc vt @everybody bpftrace vt @everybody deepin-draw lvol @everybody firefox-esr cas @everybody ispc vt @everybody llvm10.0 shrek python3-module-llvmlite grenka @python
Я тут наворотил вот такое задание: http://webery.altlinux.org/log/sisyphus/tested/266316/logs/events.1.1.log #100 llvm-common 11.0.1-alt1 -> 11.0.1-alt2 Sun Feb 14 2021 Arseny Maslennikov <arseny@altlinux> 11.0.1-alt2 - Obsolete the Sisyphus LLVM packages that do not use llvm-alt-tool-wrappers. % git diff 11.0.1-alt1..@^ diff --git a/llvm-common.spec b/llvm-common.spec index fe75248..8de6698 100644 --- a/llvm-common.spec +++ b/llvm-common.spec @@ -15,6 +15,20 @@ Source: llvm-alt-tool-wrapper.c Source1: alt-packaging-wrap-cmake-script Source2: alt-packaging-produce-rpm-macros-llvm-common +# We want to have these obsoletions to win apt's generic provider selection +# against pre-wrapped llvm packages. +Obsoletes: clang <= 11.0.0-alt1 +Obsoletes: clang-devel <= 11.0.0-alt1 +Obsoletes: clang-devel-static <= 11.0.0-alt1 +Obsoletes: clang-doc <= 11.0.0-alt1 +Obsoletes: lld <= 11.0.0-alt1 +Obsoletes: lld-devel <= 11.0.0-alt1 +Obsoletes: lld-doc <= 11.0.0-alt1 +Obsoletes: llvm <= 11.0.0-alt1 +Obsoletes: llvm-devel <= 11.0.0-alt1 +Obsoletes: llvm-devel-static <= 11.0.0-alt1 +Obsoletes: llvm-doc <= 11.0.0-alt1 + %define _libexecdir /usr/libexec %package -n rpm-macros-%name Возможно, это изменение способно заменить гвозди.
(In reply to Arseny Maslennikov from comment #21) > Я тут наворотил вот такое задание: > > http://webery.altlinux.org/log/sisyphus/tested/266316/logs/events.1.1.log > > #100 llvm-common 11.0.1-alt1 -> 11.0.1-alt2 > Sun Feb 14 2021 Arseny Maslennikov <arseny@altlinux> 11.0.1-alt2 > - Obsolete the Sisyphus LLVM packages that do not use > llvm-alt-tool-wrappers. [...] > Возможно, это изменение способно заменить гвозди. Боюсь, что мы это узнаем не раньше, чем оно будет закоммичено.
(In reply to Dmitry V. Levin from comment #22) > (In reply to Arseny Maslennikov from comment #21) > > Я тут наворотил вот такое задание: > > > > http://webery.altlinux.org/log/sisyphus/tested/266316/logs/events.1.1.log > > Возможно, это изменение способно заменить гвозди. > > Боюсь, что мы это узнаем не раньше, чем оно будет закоммичено. Ну ладно, засунул в сизиф. [#266316] DONE (try 2) llvm-common.git=11.0.1-alt2
После коммита 175105ed3117a4a14b512007a2c89c5b4b0c80af версия llvm больше не прибита гвоздями.
