Bug 56619

bcd я починил, вопрос со сборкой отдельного пакета с новой версией и правильного provides остается открытым.

Также сломались ceres-solver[1] и regard3d[2]

1. https://git.altlinux.org/beehive/logs/Sisyphus/x86_64/archive/2025/1028/error/ceres-solver-2.2.0-alt2

2. https://git.altlinux.org/beehive/logs/Sisyphus/x86_64/archive/2025/1028/error/regard3d-1.0.0-alt1.1

Принял к рассмотрению.
По поводу regard3d. Он же сломался по причине отсутствия -devel пакет у libexGTK3.0 (https://git.altlinux.org/gears/w/wxGTK3.0.git?p=wxGTK3.0.git;a=commitdiff;h=ae5f821896bdd1ee6bacc4f3fc5f0e5d3acbfa91).
Или я что-то упустил?

(In reply to Ulysses Apokin from comment #3)
> Принял к рассмотрению.
> По поводу regard3d. Он же сломался по причине отсутствия -devel пакет у
> libexGTK3.0
> (https://git.altlinux.org/gears/w/wxGTK3.0.git?p=wxGTK3.0.git;a=commitdiff;
> h=ae5f821896bdd1ee6bacc4f3fc5f0e5d3acbfa91).
> Или я что-то упустил?

wxGTK тоже, там поломано в нескольких местах.

(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #4)
> (In reply to Ulysses Apokin from comment #3)
> > Принял к рассмотрению.
> > По поводу regard3d. Он же сломался по причине отсутствия -devel пакет у
> > libexGTK3.0
> > (https://git.altlinux.org/gears/w/wxGTK3.0.git?p=wxGTK3.0.git;a=commitdiff;
> > h=ae5f821896bdd1ee6bacc4f3fc5f0e5d3acbfa91).
> > Или я что-то упустил?
> 
> wxGTK тоже, там поломано в нескольких местах.

я честно пытался починить и это, но там уже вылазит несовместимость на уровне кода нового wxGTK, поэтому оставляю на усмотрение мантейнера.

Привет!

Если https://packages.altlinux.org/en/tasks/399910/ это попытка посмотреть, то прошу принять к сведению, что для blender исправление стоит брать отсюда https://git.altlinux.org/people/lakostis/packages/?p=blender.git&a=commit&h=cc0125788957df9adf0bd0c3bd44844139fe2832

К сожалению, пакет blender все так же захвачен неадекватными людьми, поэтому приходится поддерживать его отдельно.

Привет. Сборка блендер вроде прошла успешна, но я попробую взять из твоего репозитория. А что не так с блендер? Я не в курсе  ЛОРа, но судя по списку изменений, твои таски принимают регулярно. Также хочу сказать, что у меня нету доступа на отправку тасков в репозиторий, я сам  запрашиваю и ожидаю аппрувы. Тем не менее, я думаю, что с этим таском больших проблем не будет.

> Сборка блендер вроде прошла успешна
А, извиняюсь, невнимательно посмотрел.
Спасбо за патч :)

blender готовится обновление, ничего с ним делать не надо.

(In reply to Anton Farygin from comment #9)
> blender готовится обновление, ничего с ним делать не надо.

Хорошо, тогда пока исключю его из таска. Но потом все равно потребуется его ребилд, потому что в eigen3 будет переименованы библиотеки из *.so в *so.X.Y.Z, чтобы соответсвовать SLibsPolicy. И таким образом все пакеты, зависящие от eigen3 будут слинкованы неправильно. На *.so, а не на *.so.X.

(In reply to Anton Farygin from comment #9)
> blender готовится обновление, ничего с ним делать не надо.

Потырите патчи как обычно из моей сборки? В 4.5 все равно эти патчи нужны, никаких движений в upstream от вас лично я не видел.

(In reply to Ulysses Apokin from comment #10)
> (In reply to Anton Farygin from comment #9)
> > blender готовится обновление, ничего с ним делать не надо.
> 
> Хорошо, тогда пока исключю его из таска. Но потом все равно потребуется его
> ребилд, потому что в eigen3 будет переименованы библиотеки из *.so в
> *so.X.Y.Z, чтобы соответсвовать SLibsPolicy. И таким образом все пакеты,
> зависящие от eigen3 будут слинкованы неправильно. На *.so, а не на *.so.X.

Пришлите мне задание на review, я посмотрю. Вот из этого описания непонятно что происходит.

(In reply to Anton Farygin from comment #12)
> (In reply to Ulysses Apokin from comment #10)
> > (In reply to Anton Farygin from comment #9)
> > > blender готовится обновление, ничего с ним делать не надо.
> > 
> > Хорошо, тогда пока исключю его из таска. Но потом все равно потребуется его
> > ребилд, потому что в eigen3 будет переименованы библиотеки из *.so в
> > *so.X.Y.Z, чтобы соответсвовать SLibsPolicy. И таким образом все пакеты,
> > зависящие от eigen3 будут слинкованы неправильно. На *.so, а не на *.so.X.
> 
> Пришлите мне задание на review, я посмотрю. Вот из этого описания непонятно
> что происходит.

https://git.altlinux.org/tasks/399910/gears/40/git

(In reply to Ulysses Apokin from comment #13)
> (In reply to Anton Farygin from comment #12)
> > (In reply to Ulysses Apokin from comment #10)
> > > (In reply to Anton Farygin from comment #9)
> > > > blender готовится обновление, ничего с ним делать не надо.
> > > 
> > > Хорошо, тогда пока исключю его из таска. Но потом все равно потребуется его
> > > ребилд, потому что в eigen3 будет переименованы библиотеки из *.so в
> > > *so.X.Y.Z, чтобы соответсвовать SLibsPolicy. И таким образом все пакеты,
> > > зависящие от eigen3 будут слинкованы неправильно. На *.so, а не на *.so.X.
> > 
> > Пришлите мне задание на review, я посмотрю. Вот из этого описания непонятно
> > что происходит.
> 
> https://git.altlinux.org/tasks/399910/gears/40/git

в пакете, судя по всему, сделано что-то не то. 
Вы на 100% уверены что то, к чему вы добавляете soname - это SharedLibrary  а не плагин ?
Если раскрыть все зависимости тут:
https://packages.altlinux.org/ru/sisyphus/srpms/eigen3/what_depends/by_binary
то можно убедиться что кроме как для сборки этот пакет никому не нужен.

И да, автор ошибки сам не понял что написал - желчь и эмоциональные фрустрации мешают думать. Так бывает. Ментейнеру пакета надо внимательнее анализировать поступающие в его сторону ошибки, тщательно фильтруя и анализируя все сообщения на предмет разумности и при этом фильтровать троллинг, провокации и агрессию.

(In reply to Anton Farygin from comment #15)
> И да, автор ошибки сам не понял что написал - желчь и эмоциональные
> фрустрации мешают думать. Так бывает. Ментейнеру пакета надо внимательнее
> анализировать поступающие в его сторону ошибки, тщательно фильтруя и
> анализируя все сообщения на предмет разумности и при этом фильтровать
> троллинг, провокации и агрессию.

Вы что то путаете - все вышесказанное это стиль общения ООО, поздно одевать пенсне. Да, eigen это не shared library, а template library, как например stb. И ее обновление хорошо бы согласовать со всеми зависимыми пакетами, а не тупо собрать новую версию и убежать. SharedLibrary Policy тут бы пригодилась, если это обновление нужно провести максимально неинвазивно (т.е. сохранив старые и новые -devel пакеты). Т.е. все что написано в ошибке верно, а уж как это понято, это ваши проблемы.

PS жду новую версию blender, наверное, это будет пакет года, который затмит, все что собирали в сизифе за прошедшее время.

(In reply to Anton Farygin from comment #15)
> И да, автор ошибки сам не понял что написал - желчь и эмоциональные
> фрустрации мешают думать. Так бывает. Ментейнеру пакета надо внимательнее
> анализировать поступающие в его сторону ошибки, тщательно фильтруя и
> анализируя все сообщения на предмет разумности и при этом фильтровать
> троллинг, провокации и агрессию.
(In reply to Anton Farygin from comment #14)
> (In reply to Ulysses Apokin from comment #13)
> > (In reply to Anton Farygin from comment #12)
> > > (In reply to Ulysses Apokin from comment #10)
> > > > (In reply to Anton Farygin from comment #9)
> > > > > blender готовится обновление, ничего с ним делать не надо.
> > > > 
> > > > Хорошо, тогда пока исключю его из таска. Но потом все равно потребуется его
> > > > ребилд, потому что в eigen3 будет переименованы библиотеки из *.so в
> > > > *so.X.Y.Z, чтобы соответсвовать SLibsPolicy. И таким образом все пакеты,
> > > > зависящие от eigen3 будут слинкованы неправильно. На *.so, а не на *.so.X.
> > > 
> > > Пришлите мне задание на review, я посмотрю. Вот из этого описания непонятно
> > > что происходит.
> > 
> > https://git.altlinux.org/tasks/399910/gears/40/git
> 
> в пакете, судя по всему, сделано что-то не то. 
> Вы на 100% уверены что то, к чему вы добавляете soname - это SharedLibrary 
> а не плагин ?
> Если раскрыть все зависимости тут:
> https://packages.altlinux.org/ru/sisyphus/srpms/eigen3/what_depends/by_binary
> то можно убедиться что кроме как для сборки этот пакет никому не нужен.


Да, вы правы. В таком случае закрыть багу?
Или нужно будет подговить пакет -devel к тому, что его может быть два в случае ломки API - с новой и старой версией.

Изучу более дотошно для чего нужны еще eigen3_blas и _lapack. Глянул, что в suse их сборка вообще отключена.

(In reply to Anton Farygin from comment #14)
> в пакете, судя по всему, сделано что-то не то. 
> Вы на 100% уверены что то, к чему вы добавляете soname - это SharedLibrary 
> а не плагин ?

Думаю, что это не плагины, а библиотекио.

Документация по этой теме скудная, но вот на чем я сделал такие выводы:

LAPACK и BLAS - это стандарты API для библиотек, выполняющих операции линейной алгебры.
https://en.wikipedia.org/wiki/LAPACK 
https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms

Соответственно, eigen3 предоставляет одну из реализаций этих библиотек. (При этом это не часть именно eigen3 - библиотеки шаблонов).
В CMakeLists.txt:
 62 # Determine if we should build BLAS/LAPACK implementations.
 63 option(EIGEN_BUILD_BLAS "Toggles the building of the Eigen Blas library" ${PROJECT_IS_TOP_LEVEL})
 64 option(EIGEN_BUILD_LAPACK "Toggles the building of the included Eigen LAPACK library" ${PROJECT_IS_TOP_LEVEL})

И можно взять какие-нибудь функции из спецификации и посмотреть, что они реализованы:
[builder@localhost .in]$ readelf -s /usr/lib64/libeigen_blas.so.5.0.1 | grep gemm
    28: 0000000000016a30  1693 FUNC    GLOBAL DEFAULT   12 sgemm_
    46: 000000000003e7b0  1677 FUNC    GLOBAL DEFAULT   12 dgemm_
   102: 00000000000bddd0  2784 FUNC    GLOBAL DEFAULT   12 zgemmtr_
   105: 00000000000170d0  1787 FUNC    GLOBAL DEFAULT   12 sgemmtr_
   163: 000000000003ee40  1803 FUNC    GLOBAL DEFAULT   12 dgemmtr_
   169: 0000000000069020  1913 FUNC    GLOBAL DEFAULT   12 cgemm_
   183: 00000000000bd860  1391 FUNC    GLOBAL DEFAULT   12 zgemm_
   184: 00000000000697a0  2911 FUNC    GLOBAL DEFAULT   12 cgemmtr_

В документации eigen3 есть упоминание, как использовать сторонние BLAS и LAPACK https://libeigen.gitlab.io/eigen/docs-nightly/TopicUsingBlasLapack.html

В Сизифе программы слинкованы на другие реализации, вроде OpenBLAS и т.д., если им это нужно.
В suse эти библиотеки от eigen3 тоже не используются, и сборка этих библиотек отключена.
А в fedora они собираются.

Соответственно, вопрос о упаковке eigen3 согласно SLibsPolicy можно свести к следующему:

1. Нужна ли сборка BLAS и LAPACK от eigen3?
2. Нужна ли поддержка нескольких -devel пакетов для eigen3?

а попробуйте пообщаться по этому поводу с апстримом ?

Следить за развитием ситуации можно по ссылке:
https://gitlab.com/libeigen/eigen/-/merge_requests/2080

"lib" в имена devel-подпакетов не пихайте, пожалуйста. Это не библиотеки.

(In reply to Sergey V Turchin from comment #22)
> "lib" в имена devel-подпакетов не пихайте, пожалуйста. Это не библиотеки.

Это предложили в [devel]-рассылки. На данный момент такого изменения нет. Или я что-то упустил?

Апстрим принял изменение, которое я подготовил, в основной состав.
https://gitlab.com/libeigen/eigen/-/commit/a73501cc76371c1e5ba649070275158a3b01d031
Таск с заданием:
https://git.altlinux.org/tasks/401479/logs/events.7.1.log

Сборка происходит из новой версии 5.0.1+git<commit> с нашим изменением.

На данный момент поступило несколько предложений.

- Переименовать eigen3-devel в libeigen3-devel.
   Исходя из обсуждения в списке рассылки, я думаю, что от этого изменения мы отказываемся.


- Отказ от сборки нескольких версий -devel подпакетов в случае обратно-несовместимых изменений.
  Я думаю, если мы хотим плавной миграции на новые обратно-несовместимые версии, что и было причиной появления данной баги, стоит собирать несколько версий -devel пакетов. Потому что eigen3 - это библиотека шаблонов.

(Ответ для Ulysses Apokin на комментарий #23)
> > "lib" в имена devel-подпакетов не пихайте, пожалуйста. Это не библиотеки.
> На данный момент такого изменения нет.
> Или я что-то упустил?
Ааа, ок. Это я перебздел.

> Provides: %name-blas = %EVR
> Obsoletes: %name-blas < %EVR
и подобные. Эти имена пакетов _никогда_ не поменяются, зато могут поменяться в вашем spec и станут ошибкой. Надо
Provides: eigen3-blas = %EVR
Obsoletes: eigen3-blas < %EVR

(In reply to Sergey V Turchin from comment #27)
> > Provides: %name-blas = %EVR
> > Obsoletes: %name-blas < %EVR
> и подобные. Эти имена пакетов _никогда_ не поменяются, зато могут поменяться
> в вашем spec и станут ошибкой. Надо
> Provides: eigen3-blas = %EVR
> Obsoletes: eigen3-blas < %EVR

Спасибо за замечание. Обязательно исправлю.

(Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #0)
> shared library policy
Не вижу, чтобы вы там предлагали не подтереться. https://lists.altlinux.org/pipermail/devel/2025-August/219461.html

(In reply to Ulysses Apokin from comment #28)
Собирайте в исходном пакете eigen пятую версию со всеми адаптированными зависимостями, в соответствии с Shared Libs Policy.

ITK одобряют 5 версию:
https://github.com/InsightSoftwareConsortium/ITK/pull/5590

FreeCAD:
https://github.com/FreeCAD/FreeCAD/pull/24099

Третья версия получает обновления и требуется как минимум для fcl:
https://gitlab.com/libeigen/eigen/-/tree/3.4

Подготовкой пакета для третьей версии занимался silverducks@, вы можете скооперироваться для разрешения проблемы.

у fcl в master ветке есть патчи для поддержки пятой версии - просто приложите их и не надо плодить дубли пакетов.

Всем доброе утро.
Не очень удобно читать и отвечать в рассылке. Письма некоторых участников у меня попадают в спам, а от некоторых даже реджектятся и я могу их прочитать, только если их процитировали в ответе.

Я видел возражение, что у нас eigen3, а не eigen5, несмотря на смену мажорной версии.
Согласно информации, которую предоставил апстрим, текущая версия библиотеки 3.5.0.1, до обратно-несовместимого изменения она была 3.3.4.0. См. https://gitlab.com/libeigen/eigen/-/releases#versioning
В связи с этим, название пакета соответствует действительности.

Замечание, которое сделал Сергей в https://bugzilla.altlinux.org/show_bug.cgi?id=56619#c27 я исправил.

По поводу переименования пакетов eigen3-blas и eigen3-lapack в libeigen3_blas%soversioin и libeigen3_lapack%soversion вместо eigen3-blas%soversion и eigen3-lapack%soversion. Я не против такого переименования. Тем не менее должен заметить, что такое наименование eigen3-blas и eigen3-lapack используется в RHEL, и в случае текущего варианта наименования, мы будем менее оринигальными в позитивном смысле по сравнению с RHEL. Предлагаю прийти к консенсусу.

По поводу сборки eigen3.3.4.1. Я думал, что ее вопрос сборки уже не обсуждается. И в этой баге идет работа по поводу того, как подготовить пакет для плавной миграции на новую версию в случае обратно-несовместимых изменений. И в качестве побочного эффекта обновление 5.0.0->5.0.1. Мне необходимы пояснения и указания по этому вопросу.

(Ответ для Ulysses Apokin на комментарий #32)
> Замечание, которое сделал Сергей в
> https://bugzilla.altlinux.org/show_bug.cgi?id=56619#c27 я исправил.
Туда же:
Provides: %name = %EVR
Obsoletes: %name < %EVR
тоже неоднозначно. Возможно, корректнее будет к нему добавить
Provides: eigen3 = %EVR
Obsoletes: eigen3 < %EVR

P.S.
Requires: подпакет = %EVR
можно писать, как 
Requires: подпакет

Исправил. Таск тот же.
Если других замечаний/предложений нет, можете выдать аппрув.
Или можно подождать Антона, поскольку он мой рецензент.