Bug 50974

Created attachment 16476 [details]
Открытый ssh

Ментор: Андрей Лимачко <liannnix@altlinux.org>

Менторство подтверждаю

В gpg ключе uid должен быть вида "Имя Фамилия <ник@altlinux.org>".
Gpg ключ лучше делать бессрочным.

Кандидат предложил на рассмотрение репозиторий с предварительно подготовленным репозиторием для сборки пакета abnfc:
https://github.com/kiper220-alt/abnfc/tree/alt_spec

По содержанию у меня возникли следующие замечания:
1. Зачем вот этот коммит? https://github.com/kiper220-alt/abnfc/commit/8207c8d9c56a3d001dbbe09cf258de05792aa720
Файл .gitignore никак не влияет на сборку, а его наличие и содержимое, на мой взгляд, вопрос апстрима. Добавлять его в gear-репозиторий не нужно.
2. По спеку https://github.com/kiper220-alt/abnfc/commit/69033add39a454b530c27cf858d8b0d1515acc8c :
Нужно добавить VCS

Всё исправил. Заново сгенерированный GPG ключ пришлю чуть попозже.

Created attachment 16586 [details]
Новый открытый gpg

Прошу перевести кандидата сразу на этап 2.3.

Ментор есть, ключи в порядке.

ssh ключ на gitery.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.3.

Пакет asn1c: https://git.altlinux.org/people/kiper/packages/asn1c.git
tag подписан и готов к сборке. Хотелось бы получить доступ к сборочнице.

(Ответ для kiper на комментарий #11)
> Пакет asn1c: https://git.altlinux.org/people/kiper/packages/asn1c.git
> tag подписан и готов к сборке. Хотелось бы получить доступ к сборочнице.

Пакет к сборке не готов.

1. URL должен указывать на homepage.
2. Зачем в зависимостях autoconf-common?
3. Нужно включить тесты
4. Для компиляции уже скопилированного asn1c кода на C требуются поставляемые с компилятором исходники и headers, которые лучше паковать отдельно, к примеру, в asn1c-devel подпакет.
5. Не упакованы маны, доки, examples, и ещё длинный список всего. Нужно разобраться так, чтобы _unpackaged_files_terminate_build 1 не срабатывал.

(Ответ для Andrey Limachko на комментарий #12)
> (Ответ для kiper на комментарий #11)
> > Пакет asn1c: https://git.altlinux.org/people/kiper/packages/asn1c.git
> > tag подписан и готов к сборке. Хотелось бы получить доступ к сборочнице.
> 
> Пакет к сборке не готов.
> 
> 1. URL должен указывать на homepage.
> 2. Зачем в зависимостях autoconf-common?
> 3. Нужно включить тесты
> 4. Для компиляции уже скопилированного asn1c кода на C требуются
> поставляемые с компилятором исходники и headers, которые лучше паковать
> отдельно, к примеру, в asn1c-devel подпакет.
> 5. Не упакованы маны, доки, examples, и ещё длинный список всего. Нужно
> разобраться так, чтобы _unpackaged_files_terminate_build 1 не срабатывал.

Большое спасибо за правки!
1. Теперь URL указывает на homepage, а VCS на оригинальный репозиторий.
2. BuildRequires устанавливал из соображение минимально установленной системы. Если ориентироваться на gear-hsh, в котором, действительно, autoconf-common прописывать не нужно, то вашу мысль понял. Я убрал BuildRequires :)
3. Тесты проект не проходит, потому решил откатить его к тэгу, на котором тесты проходят. Изначально тесты проглядел из-за своей невнимательности.
4. Моё упущение. Исправил! Часть изменений, вроде `*.h` и `*.c` файлов в пакете asn1c-devel, а часть, вроде asn1c заголовков и конфигов, которые нужны при компиляции в пакете asn1c. Также в asn1c упаковываются маны и доки.
5. см. п.4 :)

Насчёт example-ов идей нет, как упаковать. Если только положить сами исходники. 
Сборка через gear-hsh проходит успешно. Собирается 3 пакета: asn1c, asn1c-devel и asn1c-debuginfo.

Tag: https://git.altlinux.org/people/kiper/packages/?p=asn1c.git;a=tag;h=refs/tags/0.9.28-alt1
Commit: https://git.altlinux.org/people/kiper/packages/?p=asn1c.git;a=commit;h=93e40aace766eb3d872329f81ae912b47a85b2a7

Вцелом, нормально.

examples можно положить "как есть" в пакет вида asn1c-examples.

А так все норм. Поправь экзамплы и можно отправлять на сборку.

Кандидат готов отправлять пакеты на сборочницу. Прошу перевести его на 
этап 3.

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.
Адрес подписан на devel@.

T/J/S -> 3.6.

(Ответ для Andrey Limachko на комментарий #14)
> Вцелом, нормально.
> 
> examples можно положить "как есть" в пакет вида asn1c-examples.
> 
> А так все норм. Поправь экзамплы и можно отправлять на сборку.

examples положил как есть в каталоге `%_libdir/%name`.
Произвёл тестовую сборку на gyle в задаче #379178.

(Ответ для kiper на комментарий #17)
> (Ответ для Andrey Limachko на комментарий #14)
> > Вцелом, нормально.
> > 
> > examples можно положить "как есть" в пакет вида asn1c-examples.
> > 
> > А так все норм. Поправь экзамплы и можно отправлять на сборку.
> 
> examples положил как есть в каталоге `%_libdir/%name`.
> Произвёл тестовую сборку на gyle в задаче #379178.

С `%_libdir/%name` я немного погорячился...
Сейчас examples лежат в `%buildroot%_datadir/%name/`.
Помимо всего поправил пути, и вместо asn1c используется макрос `%name`
Произвёл тестовую сборку исправленной версии на gyle в задаче #379814.

---

В задаче #379814 заметил warning по поводу того, что подпакеты examples и devel могут быть noarch. Уже поправил и собрал тестовую сборку в задаче #379820.

P.S. Прошу простить, в следующий раз буду внимательнее!!!

(Ответ для kiper на комментарий #18)
> (Ответ для kiper на комментарий #17)
> > (Ответ для Andrey Limachko на комментарий #14)
> > > Вцелом, нормально.
> > > 
> > > examples можно положить "как есть" в пакет вида asn1c-examples.
> > > 
> > > А так все норм. Поправь экзамплы и можно отправлять на сборку.
> > 
> > examples положил как есть в каталоге `%_libdir/%name`.
> > Произвёл тестовую сборку на gyle в задаче #379178.
> 
> С `%_libdir/%name` я немного погорячился...
> Сейчас examples лежат в `%buildroot%_datadir/%name/`.
> Помимо всего поправил пути, и вместо asn1c используется макрос `%name`
> Произвёл тестовую сборку исправленной версии на gyle в задаче #379814.
> 
> ---
> 
> В задаче #379814 заметил warning по поводу того, что подпакеты examples и
> devel могут быть noarch. Уже поправил и собрал тестовую сборку в задаче
> #379820.
> 
> P.S. Прошу простить, в следующий раз буду внимательнее!!!

Зачем в spec'е заявлен пакет asn1c-devel, если в него, по итогу сборки, ничего не попадает?

(Ответ для Andrey Limachko на комментарий #19)
> (Ответ для kiper на комментарий #18)
> > (Ответ для kiper на комментарий #17)
> > > (Ответ для Andrey Limachko на комментарий #14)
> > > > Вцелом, нормально.
> > > > 
> > > > examples можно положить "как есть" в пакет вида asn1c-examples.
> > > > 
> > > > А так все норм. Поправь экзамплы и можно отправлять на сборку.
> > > 
> > > examples положил как есть в каталоге `%_libdir/%name`.
> > > Произвёл тестовую сборку на gyle в задаче #379178.
> > 
> > С `%_libdir/%name` я немного погорячился...
> > Сейчас examples лежат в `%buildroot%_datadir/%name/`.
> > Помимо всего поправил пути, и вместо asn1c используется макрос `%name`
> > Произвёл тестовую сборку исправленной версии на gyle в задаче #379814.
> > 
> > ---
> > 
> > В задаче #379814 заметил warning по поводу того, что подпакеты examples и
> > devel могут быть noarch. Уже поправил и собрал тестовую сборку в задаче
> > #379820.
> > 
> > P.S. Прошу простить, в следующий раз буду внимательнее!!!
> 
> Зачем в spec'е заявлен пакет asn1c-devel, если в него, по итогу сборки,
> ничего не попадает?

Всё, нашёлся -devel пакет. Больше вопросов, вроде бы, нету. Аппрувлю.

Мне захотелось собрать пакет wasmtime, т.к. пакет довольно интересный и к тому же написан на Rust. Можно собрать интересный пакет и посмотреть, как собирается Rust :)

Подготовил репозиторий на gitery: https://git.altlinux.org/people/kiper/packages/wasmtime.git

Попытался собрать, однако сборка падает на i586, задачи: #388106 #388124.

Буду пытаться разобраться!

По wasmtime пока не разобрался, однако параллельно с этим собрал другой пакет.

У нас в репозитории есть интересный пакет: re2c, однако последний раз он собирался 5 апреля 2022, версия 2.2-alt1. Я склонировал себе репу, обновил до версии 4.2-alt1 и произвёл тестовую сборку. Обновлял, как и текущий сопровождающий.

Хотел бы уточнить, нужно ли обновить Url(https://re2c.org/) и добавить Vcs(https://github.com/skvadrik/re2c)?

Задание сборочницы: #388260
Репозиторий: https://git.altlinux.org/people/kiper/packages/re2c.git

(Ответ для kiper на комментарий #22)
> По wasmtime пока не разобрался, однако параллельно с этим собрал другой
> пакет.
> 
> У нас в репозитории есть интересный пакет: re2c, однако последний раз он
> собирался 5 апреля 2022, версия 2.2-alt1. Я склонировал себе репу, обновил
> до версии 4.2-alt1 и произвёл тестовую сборку. Обновлял, как и текущий
> сопровождающий.
> 
> Хотел бы уточнить, нужно ли обновить Url(https://re2c.org/) и добавить
> Vcs(https://github.com/skvadrik/re2c)?
> 
> Задание сборочницы: #388260
> Репозиторий: https://git.altlinux.org/people/kiper/packages/re2c.git

Задачу #388319 одобрил. re2c и wasmtime уже попали в sisyphus.

> Хотел бы уточнить, нужно ли обновить Url(https://re2c.org/) и добавить
> Vcs(https://github.com/skvadrik/re2c)?
Да, нужно, но уже поздно :)
Два дня назад вышла новая версия re2c. Стоит обновить, а заодно и поправить Url с Vcs.

(Ответ для Andrey Limachko на комментарий #23)
> (Ответ для kiper на комментарий #22)
> > Хотел бы уточнить, нужно ли обновить Url(https://re2c.org/) и добавить
> > Vcs(https://github.com/skvadrik/re2c)?
> Да, нужно, но уже поздно :)
> Два дня назад вышла новая версия re2c. Стоит обновить, а заодно и поправить
> Url с Vcs.

Произвёл обновление в задаче #388803. Обновил Url с Vcs. Помимо re2c произвёл тестовую пересборку зависящих от re2c пакетов в той же задаче.

Обновил wasmtime с 34.0.1-alt1 до 35.0.0-alt1.
В EPERM.
задача: #391011.
Ожидаю апрув.

(Ответ для kiper на комментарий #25)
> Обновил wasmtime с 34.0.1-alt1 до 35.0.0-alt1.
> В EPERM.
> задача: #391011.
> Ожидаю апрув.

Зачем так делать?
> %files examples
> %dir %_datadir/%name
> %dir %_datadir/%name/examples
> %_datadir/%name/examples/*

Дочтаточно так:
> %files examples
> %dir %_datadir/%name
> %_datadir/%name/examples

Так можно и явно указать на владение %_datadir/%name и положить в пакет содержимое %_datadir/%name/examples.

Можно было бы сделать и ещё проще: %_datadir/%name. Но так лучше не делать. В таком случае в пакет wasmtime-examples попадёт вся директория %_datadir/%name, в последующих обновлениях в ней может появиться что-то другое, отличное от examples, о чём мы просто так уже не узнаем.

(Ответ для Andrey Limachko на комментарий #26) 
> Зачем так делать?
> > %files examples
> > %dir %_datadir/%name
> > %dir %_datadir/%name/examples
> > %_datadir/%name/examples/*
> 
> Дочтаточно так:
> > %files examples
> > %dir %_datadir/%name
> > %_datadir/%name/examples

Исправил и собрал в той же задачи в EPERM!

(Ответ для kiper на комментарий #27)
> (Ответ для Andrey Limachko на комментарий #26) 
> > Зачем так делать?
> > > %files examples
> > > %dir %_datadir/%name
> > > %dir %_datadir/%name/examples
> > > %_datadir/%name/examples/*
> > 
> > Дочтаточно так:
> > > %files examples
> > > %dir %_datadir/%name
> > > %_datadir/%name/examples
> 
> Исправил и собрал в той же задачи в EPERM!

Уехало в sisyphus.

Собрал пакет litecli и cli_helpers(зависимость) в задаче #392269.
Хотелось бы понять, а как правильно готовить python3.

Например в https://git.altlinux.org/people/slev/public/?p=python_spec.git&a=blob&f=python_latest.spec&h=314116952ebe1d11e68acfe448eb30914eb65497&hb=main показано, что нужно указать `%def_with check`, но не совсем понятно, что это делает, потому у себя не прописал.

Не совсем понятно, имеет ли `pypi_name` и `mod_name` какое-то особое значение?

Также не совсем понятно, во что превращается `@NAME@` и в чём разница между `%patch -p1` и `%autopatch -p1`.

Хотелось бы понять что означают некоторые макросы, т.к. не получается найти информацию по этому поводу, а `rpm --eval` молчит :)

P.S. Задача test-only и будет правиться, но если что-то не так, говорите! Буду рад любым правкам.

(Ответ для kiper на комментарий #29)
> Собрал пакет litecli и cli_helpers(зависимость) в задаче #392269.
> Хотелось бы понять, а как правильно готовить python3.
> 
> Например в
> https://git.altlinux.org/people/slev/public/?p=python_spec.
> git&a=blob&f=python_latest.
> spec&h=314116952ebe1d11e68acfe448eb30914eb65497&hb=main показано, что нужно
> указать `%def_with check`, но не совсем понятно, что это делает, потому у
> себя не прописал.
Макрос `%def_with check` включает тесты, а именно то, что обёрнуто макросом %if_with check ... %endif

> 
> Не совсем понятно, имеет ли `pypi_name` и `mod_name` какое-то особое
> значение?
pypi_name - имя модуля из pypi.
mod_name - имя каталога с модулем в site-packages.

> 
> Также не совсем понятно, во что превращается `@NAME@` и в чём разница между
@NAME@ в данном случае подразумевает подстановку pypi имени пакета. По ссылке же приводится шаблон спека, который нужно подгонять под конкретный пакет.

> `%patch -p1` и `%autopatch -p1`.
`%patch -p1` к конкретному патчу. `%patch -p1` равен `%patch1 -p1`. Для других патчей нужно указывать как-то так: `%patch1 -p1`, `%patch2 -p1` и т.д.
`%autopatch -p1` применяет все имеющиеся патчи автоматом, без явного перечисления.

> 
> Хотелось бы понять что означают некоторые макросы, т.к. не получается найти
> информацию по этому поводу, а `rpm --eval` молчит :)
Берём пакет rpm-macros-<что-то> и смотрим его содержимое. Затем находим, к примеру, файлик `/usr/lib/rpm/macros.d/pyproject` и смотрим. Если повезёт, то там даже будут комментарии.

> 
> P.S. Задача test-only и будет правиться, но если что-то не так, говорите!
> Буду рад любым правкам.

По python3-module-cli_helpers:
1. pypi_name (cli_helpers) не соответствует реальному имени из pypi (https://pypi.org/project/cli-helpers/).
2. В качестве Url для python3 модулей, желательно использовать ссылку на pypi.
3. Почему закомментированы тесты?

По litecli:
1. %description не должен содержать строк длиннее 72 символов.
2. Желательно разделить пакет на два подпакеты: litecli и python3-module-litecli. В одном лежит %_bindir/%pypi_name, а в другом - содердимое %python3_sitelibdir/.

По обоим пакетам:
1. В патчах, видимо, выпиливаются тесты, которые по каким то причинам не отрабатывают во время сборки. Желательно, если есть возможность, отключать их в spec'e опциями %pyproject_run_pytest, а не патчить код.

В следующем python3 модуле желательно попробовать другую схему сборки, с макросами rpm-macros-pyproject. Подробнее по ссылке https://www.altlinux.org/Management_of_Python_dependencies_sources. В сообществе бытуют разные мнения о том, стоит ли использовать эту схему или нет. Я предпочитаю использовать.

В любом случае, кандидату полезно познакомиться с обоими схемами.

(Ответ для Andrey Limachko на комментарий #30)
> Макрос `%def_with check` включает тесты, а именно то, что обёрнуто макросом
> %if_with check ... %endif
> pypi_name - имя модуля из pypi.
> mod_name - имя каталога с модулем в site-packages.
> `%patch -p1` к конкретному патчу. `%patch -p1` равен `%patch1 -p1`. Для
> других патчей нужно указывать как-то так: `%patch1 -p1`, `%patch2 -p1` и т.д.
> `%autopatch -p1` применяет все имеющиеся патчи автоматом, без явного
> перечисления.

понял.

(Ответ для Andrey Limachko на комментарий #30)
> Берём пакет rpm-macros-<что-то> и смотрим его содержимое. Затем находим, к
> примеру, файлик `/usr/lib/rpm/macros.d/pyproject` и смотрим. Если повезёт,
> то там даже будут комментарии.

хорошо.

(Ответ для Andrey Limachko на комментарий #30)
> По python3-module-cli_helpers:
> 1. pypi_name (cli_helpers) не соответствует реальному имени из pypi

Исправил, добавил `Provides: python3-module-%{pep503_name %pypi_name} = %EVR`.

(Ответ для Andrey Limachko на комментарий #30)
> (https://pypi.org/project/cli-helpers/).
> 2. В качестве Url для python3 модулей, желательно использовать ссылку на
> pypi.

Исправил.

(Ответ для Andrey Limachko на комментарий #30)
> 3. Почему закомментированы тесты?

Пытался понять, кто их вызывает(вызывал `%pyproject_install`). Т.к. то была тестовая сборка, комментарий не убрал.


(Ответ для Andrey Limachko на комментарий #30)
> По litecli:
> 1. %description не должен содержать строк длиннее 72 символов.

Почему-то мне запомнилось про 80... Исправил!

> 2. Желательно разделить пакет на два подпакеты: litecli и
> python3-module-litecli. В одном лежит %_bindir/%pypi_name, а в другом -
> содердимое %python3_sitelibdir/.

Разделил


> По обоим пакетам:
> 1. В патчах, видимо, выпиливаются тесты, которые по каким то причинам не
> отрабатывают во время сборки. Желательно, если есть возможность, отключать
> их в spec'e опциями %pyproject_run_pytest, а не патчить код.

Исправил. 


(Ответ для Andrey Limachko на комментарий #31)
> В следующем python3 модуле желательно попробовать другую схему сборки, с
> макросами rpm-macros-pyproject. Подробнее по ссылке
> https://www.altlinux.org/Management_of_Python_dependencies_sources. В
> сообществе бытуют разные мнения о том, стоит ли использовать эту схему или
> нет. Я предпочитаю использовать.
> 
> В любом случае, кандидату полезно познакомиться с обоими схемами.

Применил в сборке `litecli`. Кроме исправлений, сборку `cli_helpers` не менял.

Собрал в той же самой задаче(пока тестовая): #392457.

P.S. Имя пакета `python3-module-cli_helpers` не менял связи с таковым именованием её автором, но добавил provides для python3-module-%{pep503_name %pypi_name}, как это показано в https://git.altlinux.org/people/slev/public/?p=python_spec.git&a=blob&f=python_latest.spec&hb=main.
`%pep503_name` как раз возвращает нормализованное pypi имя пакета.

P.P.S Не ясно, стоит ли добавлять отдельный provides для `python3(%{pep503_name %pypi_name})`, т.к. он в основном используется при автоматическом поиске зависимостей, где подставляется имя модуля, а имя модуля как раз `cli_helpers`...

(Ответ для kiper на комментарий #32)
> Пытался понять, кто их вызывает(вызывал `%pyproject_install`). Т.к. то была
> тестовая сборка, комментарий не убрал.
Ошибся. Перепроверил пока писал комментарий и забыл убрать :)

Собрал 3 задачи в eperm:
392269 - 2 питоновских пакета. litecli + зависимость в виде cli_helpers. litecli содержит патч, вырезающий часть функционала связи с отсутствующим собранным python3(llm) (конкретно функционал, связанный с данной библиотекой), т.к. зависимость не опциональна. Пакеты новые.
392292 - утилита на golang для произведении ping разными методами. Пакет новый.
392457 - wasmtime. В данной задачи исправления по сборке пакета. 

P.S. в случае wasmtime теперь используются soname, который также является частью названия бинарных пакетов, связи с чем возникает вопрос, а нужно ли прописывать Provides, например: libwasmtime для libwasmtime1? Данный вопрос почему-то у меня возник только сейчас...

(Ответ для kiper на комментарий #32)
> (Ответ для Andrey Limachko на комментарий #30)
> > По python3-module-cli_helpers:
> > 1. pypi_name (cli_helpers) не соответствует реальному имени из pypi
> 
> Исправил, добавил `Provides: python3-module-%{pep503_name %pypi_name} =
> %EVR`.
> 
> (Ответ для Andrey Limachko на комментарий #30)
> > (https://pypi.org/project/cli-helpers/).
> > 2. В качестве Url для python3 модулей, желательно использовать ссылку на
> > pypi.
> 
> Исправил.
Это всё хорошо, только наоборот. PyPi имя модуля - cli-helper. https://pypi.org/project/cli-helpers/. А вот имя модуля, которое применяется при  импорте в python - как раз cli_helper. Так что модуль, репозиторий и SRPM должны называться python3-module-cli-helper.

(Ответ для kiper на комментарий #34)
> Собрал 3 задачи в eperm:
> 392269 - 2 питоновских пакета. litecli + зависимость в виде cli_helpers.
> litecli содержит патч, вырезающий часть функционала связи с отсутствующим
> собранным python3(llm) (конкретно функционал, связанный с данной
> библиотекой), т.к. зависимость не опциональна. Пакеты новые.
По хорошему, в таких случаях не выпиливают функционал, а собирают недостающие либы. Для alt1 нормально, но потом нужно сделать alt2 сборку с llm.

> 392292 - утилита на golang для произведении ping разными методами. Пакет
> новый.
Выглядит хорошо. Уехало в sisyphus.

> 392457 - wasmtime. В данной задачи исправления по сборке пакета. 
> 
> P.S. в случае wasmtime теперь используются soname, который также является
> частью названия бинарных пакетов, связи с чем возникает вопрос, а нужно ли
> прописывать Provides, например: libwasmtime для libwasmtime1? Данный вопрос
> почему-то у меня возник только сейчас...
По wasmtime. Выглядит вроде нормально, но полной уверенности нет. Прошу взглянуть iv@ и оценить, пожалуйста.
Замечания:
1. Зачем для лицензии делать отдельный пакет common? Достаточно использовать макрос %doc. Он и создаст директорию с нужным именем и версией.

> Прошу взглянуть iv@ и оценить, пожалуйста.

Прошу прощения, я потерял просьбу посмотреть сюда в каких-то чятиках, спасибо Корнею что напомнил.

В целом, было бы проще поревьювить эти изменения, если бы они были разбиты на отдельные коммиты, как это принято в разработке.

В плане внедрения Shared Libs Policy я вижу одну проблему, которая делает всю проделанную работу достаточно бессмысленной -- это зависимость вида

+%package -n lib%name%soversion
[...]
+Requires: %name-common = %EVR

Если мы хотим, чтобы следующий lib%name%soversion стоял в одной системе с этим пакетом, нужно, чтобы в этой зависимости было '>= %EVR' например.

У других пакетов можно оставить '='.


А ещё нумерацию выдуманных здесь soname'ов я бы начал всё-таки с нуля.


> а нужно ли прописывать Provides, например: libwasmtime для libwasmtime1? 

Думаю нет.


Ещё несколько мыслей по поводу изменений спека.

Комментарий

# Set textrel=relaxed for i586, i686

бесполезен, так как следующие три строчки делают именно это очевидным образом. Гораздо важнее было бы написать, зачем это сделано, то есть какие проблемы/задачи решаются, так, чтобы было понятно, когда это послабление проверок можно будет удалить.


Использование patchelf для выставления soname это, на мой взгляд, слишком сурово. patchelf сам по себе иногда приводит к очень странным последствиям (моя личная травма это #48494). К тому же, если апстрим однажды всё-таки начнёт выставлять soname, patchelf его спокойно перетрёт это может очень легко остаться незамеченным. У патча на какой-нибудь CMakeLists.txt (или куда там) гораздо больше шансов своевременно отвалиться.


> +- fix: issue https://bugzilla.altlinux.org/55586.

Лучше всё-таки описать суть изменений, а ссылку на багу привести в формате, описанном тут: https://www.altlinux.org/Руководство_по_написанию_changelog#Автозакрытие_багов

Собрал новую версию wasmtime 37.0.0-alt1 в задании #392457 (eperm).
Внёс все предложенные изменения, но мог что-то упустить или не правильно понять, так что прошу взглянуть на всякий случай.

P.S. В соответствии с обновлением https://www.altlinux.org/RPM/Rust явное создание .cargo/config.toml было заменено на использование макроса %rust_prep.