Created attachment 16475 [details] Открытый gpg Ник: kiper Почта: Gedert Korney <kiper@altlinux.org> Адрес пересылки почты: korney3g1@yandex.ru Цель: Научиться и собирать пакеты
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.
