http://wiki.rosalab.com/ru/api.php?action=feedcontributions&user=D+uragan&feedformat=atomRosalab Wiki - Вклад участника [ru]2024-03-28T10:56:23ZВклад участникаMediaWiki 1.26.4http://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_TeXLive&diff=19817Сборка пакетов-расширений для TeXLive2022-12-19T21:55:34Z<p>D uragan: + note about scripts folder</p>
<hr />
<div>TeX - система компьютерной вёрстки, широко используемая по всему миру.<br />
<br />
В Linux в настоящее время активно используется реализация от проекта {{Prog|texlive}}, которая включает в себя не просто основные инстурменты верстки,<br />
но и множество дополнений и расширений (дополнительных шрифтов, пакетов с поддержкой разлицных языков, шаблонов диссертаций и презентаций и так далее).<br />
<br />
В РОСЕ каждое такое дополнение оформляется как отдельный RPM-пакет. <br />
<br />
Рассмотрим процесс упаковки расширения с названием '''TEXPKG''' в пакет {{Pkg|texlive-<TEXPKG>}}<br />
<br />
Сначала проверяем, что страничка пакета доступна по адресу http://www.ctan.org/tex-archive/macros/latex/contrib/<TEXPKG>. Эта ссылка должна быть прописана в URL spec-файла. Со странички проекта берем Summary (не более 80 симполов), лицензию (тэг License) и описание (для секции %description). Если есть версия - берем ее со странички, если нет - используем в качестве версии дату, когда вы скачали исходники, в формате ГГГГММДД (например, 20191231).<br />
<br />
Далее ищем в директории http://mirrors.ctan.org/systems/texlive/tlnet/archive/ файл {{File|<TEXPKG>.tar.xz}}.<br />
Там же могут находиться файлы {{File|<TEXPKG>.doc.tar.xz}} и {{File|<TEXPKG>.source.tar.xz}} - если есть, их тоже берем.<br />
<br />
Их надо прописать в качестве Sources:<br />
<br />
Source0: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.tar.xz<br />
Source1: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.doc.tar.xz<br />
Source2: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.source.tar.xz<br />
<br />
Все эти файлы необходимо скачать и загрузить на http://file-store.rosalinux.ru/. Для аутентификации необходимо использовать те же логин и пароль, что и на ABF. Для каждого файла File Store сгенерирует хэш, который необходимо прописать в гите в файле .abf.yml, например как в https://abf.io/import/texlive-accents/blob/rosa2019.1/.abf.yml<br />
<br />
Внутри ахивов обязательно есть папки {{File|tlpkg/tlpobj}} - в них лежат файлы с информацией о пакете. Если вдруг на страничке пакета не оказалось<br />
каких-то данных (версии, описания и тому подобного), то поищите их здесь. Здесь же могут быть прописаны зависимости пакета от других пакетов texlive<br />
(со словом depend) - из надо обязательно указать как Requires в spec-файле.<br />
<br />
Например, если в tlpkg/tlpobj/<TEXPKG> есть запись<br />
<br />
depend babel-belarusian<br />
<br />
то в spec-файле должна присутсвовать соответсвующая зависимоcть<br />
<br />
Requires: texlive-babel-belarusian<br />
<br />
Значение тэга Group для пакетов texlive - всегда '''Publishing'''.<br />
<br />
Как правило, пакеты являются арзитектурно-независимыми, поэтому надо дабавить в spec-файл запись<br />
<br />
BuildArch: noarch<br />
<br />
(если пакет является архитектурно-зависимым, то rpmbuild его не соберет с соответствующей ошибкой - тогда BuildArch надо убрать).<br />
<br />
Всем texlive-пакетам необходимо прописать сборочную зависимость (BuildRequires) от {{Pkg|texlive-tlpkg}}. Этот же пакет<br />
надо указать как предустановочную зависимость ("Requires(pre)"). В качестве пост-установочной зависимости post-скрипта ("Requires(post)") надо указать<br />
{{Pkg|texlive-kpathsea}}.<br />
<br />
Для большинства пакетов, секция '''%prep''' сводится к распаковке архивов, например:<br />
<br />
%setup -c -a0 -a1 -a2<br />
<br />
секция '''%build''' отсутствует, а '''%install''' сводится к копированию директорий, содержащихся внутри архивов (за исключением директории {{File|tlpkg}}), в {{File| %{buildroot}%{_texmfdistdir} }} (которую надо предварительно создать):<br />
<br />
%install<br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar fonts tex doc source %{buildroot}%{_texmfdistdir}<br />
<br />
(проследите, чтобы скопированы были все директории из архивов, кроме tlpkg) <br />
<br />
Эти же директории достаточно указать в секции %files, пометив sources и doc как документацию:<br />
<br />
%files<br />
%{_texmfdistdir}/tex/latex/<TEXPKG><br />
%{_texmfdistdir}/fonts/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/source/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/doc/latex/<TEXPKG><br />
<br />
Подготовив spec-файл и скачав архивы с исходным кодом, необходимо убедиться в возможности собрать пакет с помощью {{Cmd|rpmbuild -bb}}. Если проблем нет - то собираем src.rpm ({{Cmd|rpmbuild -bs}}) и создаем из него проект в своем репозитории на ABF.<br />
<br />
Примеры texlive пакетов:<br />
* https://abf.io/import/texlive-mpgraphics<br />
* https://abf.io/import/texlive-mceinleger<br />
* https://abf.io/import/texlive-makecmds<br />
<br />
(смотрите ветку rosa2019.1)<br />
<br />
== Пакеты со скриптами ==<br />
Для некоторых модулей по ссылке http://ctan.altspu.ru/systems/texlive/tlnet/archive/<br />
доступен не только архив с исходным кодом, но и дополнительные пакеты под разные ОС и архитектуры. Для некоторых модулей таких пакетов нет, однако внутри архива с исходным кодом лежит папка {{File|scripts}}.<br />
Для всех таких модулей помимо описанных выше действий надо произвести дополнительные манипуляции,<br />
добавив файлы, присутсвующие в ОС-специфичных пакетах. Как правило, эти манипуляции<br />
сводятся к созданию символьных ссылок на скрипты в местах, где в ОС располагаются файлы для запуска<br />
(в случае Linux - в директории /bin или /usr/bin).<br />
<br />
Например, для a2ping мы видим следующие файлы:<br />
<br />
...<br />
a2ping.tar.xz<br />
a2ping.win32.tar.xz<br />
a2ping.x86_64-cygwin.tar.xz<br />
a2ping.x86_64-darwin.tar.xz<br />
a2ping.x86_64-darwinlegacy.tar.xz<br />
a2ping.x86_64-linux.tar.xz.<br />
...<br />
<br />
Скачаем a2ping.x86_64-linux.tar.xz и заглянем внутрь - там помимо служебной директории {{File|tlpgk}} мы увидим директорию {{File|bin}}, внутри нее директорию {{File|x86_64-linux}}, а там - символьную ссылку {{File|a2ping}}:<br />
<br />
<pre><br />
$ tar xf a2ping.x86_64-linux.tar.xz<br />
$ ls -l bin/x86_64-linux/<br />
total 0<br />
lrwxrwxrwx 1 user users 41 Oct 4 2018 a2ping -> ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
</pre><br />
<br />
Как видим, ссылается она на скрипт ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
<br />
Сам скрипт находится в архиве с исходным кодом (a2ping.tar.xz), в директории {{File|texmf-dist}}. При сборке пакета, мы должны положить содержимое texmf-dist в директорию %{buildroot}%{_texmfdistdir}, а в директории %{buildroot}%{_bindir} создать соответсвующую символьную ссылку:<br />
<br />
<pre><br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar texmf-dist/* %{buildroot}%{_texmfdistdir}<br />
mkdir -p %{buildroot}%{_bindir}<br />
pushd %{buildroot}%{_bindir}<br />
ln -sf %{_texmfdistdir}/scripts/a2ping/a2ping.pl a2ping<br />
popd<br />
</pre><br />
<br />
Пример:<br />
* https://abf.io/import/texlive-a2ping<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%98%D0%BC%D0%BF%D0%BE%D1%80%D1%82_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B8%D0%B7_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_%D0%B4%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%D0%BE%D0%B2&diff=19057Импорт пакетов из других дистрибутивов2021-11-09T14:32:05Z<p>D uragan: 2019 -> 2021</p>
<hr />
<div>Нередко возникает необходимость собрать в репозитории РОСЫ новые программы, для которых spec-файл не может быть подготовлен автоматически (как в случае модулей Perl, Python и прочего) или хотя бы на основе шаблона.<br />
<br />
В некоторых случаях пригодится утилита [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Spec-gen_-_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D1%83%D0%B5%D0%BC_spec-%D1%84%D0%B0%D0%B9%D0%BB%D1%8B_%D0%B4%D0%BB%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC_%D0%BD%D0%B0_GNU_Autotools_%D0%B8_CMake spec-gen], однако она далека от идеала.<br />
<br />
Однако есть путь проще - возможно, кто-то уже собрал RPM-пакет под другой дистрибутив, и можно позаимствовать spec-файл оттуда. Посмотреть - в каких дистрибутивах уже есть пакет с нужной программой, можно на порталах наподобие [https://pkgs.org Pkgs.org]. Если нужный пакет нашелся, то надо скачать соответствующий src.rpm и установить его в систему:<br />
<br />
$ rpm -i my_program.src.rpm<br />
<br />
При этом spec-файл установится в директорию {{File|~/rpmbuild/SPECS}}, архив с исходным кодом и патчи - в {{File|~/rpmbuild/SOURCES}}.<br />
<br />
Если пакет нашелся в нескольких дистрибутивах, то стоит выбирать наиболее близкие к РОСЕ - OpenMandriva, Mageia или PCLinuxOS. Если в этих системах пакета не нашлось, то можно попробовать RPM для Fedora, и уже совсем в крайнем случае - от SUSE.<br />
<br />
Первым делом, spec-файл от другого дистрибутива необходимо обработать утилитой {{Prog|spec-cleaner}}, которая подправит некоторые известные расхождения с РОСОЙ:<br />
<br />
$ spec-cleaner ~/rpmbuild/SPECS/my_program.spec<br />
<br />
После чего попробовать установить зависимости сборки:<br />
<br />
$ urpmi ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Вполне вероятно, что {{Prog|urpmi}} скажет, что некоторые зависимости не могут быть установлены. В большинстве случаев это происходит из-за разницы в названиях пакетов с одними и теми же программами в разных дистрибутивах и вам надо посмотреть, на что необходимо заменить проблемную запись BuildRequires в spec-файле. Впрочем, возможно некоторых программ еще нет в репозиториях РОСЫ и необходимо сначала собрать их.<br />
<br />
Как только зависимости сборки установлены, можно попробовать собрать пакет, предварительно обработав spec-файл утилитой {{Prog|spec-cleaner}}:<br />
<br />
$ spec-cleaner ~/rpmbuild/SPECS/my_program.spec<br />
$ rpmbuild -bb ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Если при сборке возникли ошибки, то можно проконсультироваться со страничкой [http://wiki.rosalab.ru/ru/index.php/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM часто встречающихся ошибок]. <br />
<br />
Если программа собралась успешно, то результаты сборки можно найти в директории {{File|~/rpmbuild/RPMS}}. Установите собравшиеся пакеты, убедитесь в их работоспособности и собирайте src.rpm:<br />
<br />
$ rpmbuild -bs ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Результатом работы этой программы будем пакет {{File|~/rpmbuild/SRPMS/my_program.src.rpm}}, из которого надо [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F создавать проект на ABF]<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2021.1 (последней на момент написания этой странички, если есть платформа поновее типа rosa2021.1 - то надо выбирать ее).<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_TeXLive&diff=18918Сборка пакетов-расширений для TeXLive2021-04-29T16:22:10Z<p>D uragan: стилевые правки</p>
<hr />
<div>TeX - система компьютерной вёрстки, широко используемая по всему миру.<br />
<br />
В Linux в настоящее время активно используется реализация от проекта {{Prog|texlive}}, которая включает в себя не просто основные инстурменты верстки,<br />
но и множество дополнений и расширений (дополнительных шрифтов, пакетов с поддержкой разлицных языков, шаблонов диссертаций и презентаций и так далее).<br />
<br />
В РОСЕ каждое такое дополнение оформляется как отдельный RPM-пакет. <br />
<br />
Рассмотрим процесс упаковки расширения с названием '''TEXPKG''' в пакет {{Pkg|texlive-<TEXPKG>}}<br />
<br />
Сначала проверяем, что страничка пакета доступна по адресу http://www.ctan.org/tex-archive/macros/latex/contrib/<TEXPKG>. Эта ссылка должна быть прописана в URL spec-файла. Со странички проекта берем Summary (не более 80 симполов), лицензию (тэг License) и описание (для секции %description). Если есть версия - берем ее со странички, если нет - используем в качестве версии дату, когда вы скачали исходники, в формате ГГГГММДД (например, 20191231).<br />
<br />
Далее ищем в директории http://mirrors.ctan.org/systems/texlive/tlnet/archive/ файл {{File|<TEXPKG>.tar.xz}}.<br />
Там же могут находиться файлы {{File|<TEXPKG>.doc.tar.xz}} и {{File|<TEXPKG>.source.tar.xz}} - если есть, их тоже берем.<br />
<br />
Их надо прописать в качестве Sources:<br />
<br />
Source0: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.tar.xz<br />
Source1: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.doc.tar.xz<br />
Source2: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.source.tar.xz<br />
<br />
Все эти файлы необходимо скачать и загрузить на http://file-store.rosalinux.ru/. Для аутентификации необходимо использовать те же логин и пароль, что и на ABF. Для каждого файла File Store сгенерирует хэш, который необходимо прописать в гите в файле .abf.yml, например как в https://abf.io/import/texlive-accents/blob/rosa2019.1/.abf.yml<br />
<br />
Внутри ахивов обязательно есть папки {{File|tlpkg/tlpobj}} - в них лежат файлы с информацией о пакете. Если вдруг на страничке пакета не оказалось<br />
каких-то данных (версии, описания и тому подобного), то поищите их здесь. Здесь же могут быть прописаны зависимости пакета от других пакетов texlive<br />
(со словом depend) - из надо обязательно указать как Requires в spec-файле.<br />
<br />
Например, если в tlpkg/tlpobj/<TEXPKG> есть запись<br />
<br />
depend babel-belarusian<br />
<br />
то в spec-файле должна присутсвовать соответсвующая зависимоcть<br />
<br />
Requires: texlive-babel-belarusian<br />
<br />
Значение тэга Group для пакетов texlive - всегда '''Publishing'''.<br />
<br />
Как правило, пакеты являются арзитектурно-независимыми, поэтому надо дабавить в spec-файл запись<br />
<br />
BuildArch: noarch<br />
<br />
(если пакет является архитектурно-зависимым, то rpmbuild его не соберет с соответствующей ошибкой - тогда BuildArch надо убрать).<br />
<br />
Всем texlive-пакетам необходимо прописать сборочную зависимость (BuildRequires) от {{Pkg|texlive-tlpkg}}. Этот же пакет<br />
надо указать как предустановочную зависимость ("Requires(pre)"). В качестве пост-установочной зависимости post-скрипта ("Requires(post)") надо указать<br />
{{Pkg|texlive-kpathsea}}.<br />
<br />
Для большинства пакетов, секция '''%prep''' сводится к распаковке архивов, например:<br />
<br />
%setup -c -a0 -a1 -a2<br />
<br />
секция '''%build''' отсутствует, а '''%install''' сводится к копированию директорий, содержащихся внутри архивов (за исключением директории {{File|tlpkg}}), в {{File| %{buildroot}%{_texmfdistdir} }} (которую надо предварительно создать):<br />
<br />
%install<br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar fonts tex doc source %{buildroot}%{_texmfdistdir}<br />
<br />
(проследите, чтобы скопированы были все директории из архивов, кроме tlpkg) <br />
<br />
Эти же директории достаточно указать в секции %files, пометив sources и doc как документацию:<br />
<br />
%files<br />
%{_texmfdistdir}/tex/latex/<TEXPKG><br />
%{_texmfdistdir}/fonts/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/source/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/doc/latex/<TEXPKG><br />
<br />
Подготовив spec-файл и скачав архивы с исходным кодом, необходимо убедиться в возможности собрать пакет с помощью {{Cmd|rpmbuild -bb}}. Если проблем нет - то собираем src.rpm ({{Cmd|rpmbuild -bs}}) и создаем из него проект в своем репозитории на ABF.<br />
<br />
Примеры texlive пакетов:<br />
* https://abf.io/import/texlive-mpgraphics<br />
* https://abf.io/import/texlive-mceinleger<br />
* https://abf.io/import/texlive-makecmds<br />
<br />
(смотрите ветку rosa2019.1)<br />
<br />
== Пакеты со скриптами ==<br />
Для некоторых модулей по ссылке http://ctan.altspu.ru/systems/texlive/tlnet/archive/<br />
доступен не только архив с исходным кодом, но и дополнительные пакеты под разные ОС и архитектуры.<br />
Для таких модулей помимо описанных выше дейтсвий надо произвести дополнительные манипуляции,<br />
добавив файлы, присутсвующие в ОС-специфичных пакетах. Как правило, эти манипуляции<br />
сводятся к созданию символьных ссылок на скрипты в местах, где в ОС располагаются файлы для запуска<br />
(в случае Linux - в директории /bin или /usr/bin).<br />
<br />
Например, для a2ping мы видим следующие файлы:<br />
<br />
...<br />
a2ping.tar.xz<br />
a2ping.win32.tar.xz<br />
a2ping.x86_64-cygwin.tar.xz<br />
a2ping.x86_64-darwin.tar.xz<br />
a2ping.x86_64-darwinlegacy.tar.xz<br />
a2ping.x86_64-linux.tar.xz.<br />
...<br />
<br />
Скачаем a2ping.x86_64-linux.tar.xz и заглянем внутрь - там помимо служебной директории {{File|tlpgk}} мы увидим директорию {{File|bin}}, внутри нее директорию {{File|x86_64-linux}}, а там - символьную ссылку {{File|a2ping}}:<br />
<br />
<pre><br />
$ tar xf a2ping.x86_64-linux.tar.xz<br />
$ ls -l bin/x86_64-linux/<br />
total 0<br />
lrwxrwxrwx 1 user users 41 Oct 4 2018 a2ping -> ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
</pre><br />
<br />
Как видим, ссылается она на скрипт ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
<br />
Сам скрипт находится в архиве с исходным кодом (a2ping.tar.xz), в директории {{File|texmf-dist}}. При сборке пакета, мы должны положить содержимое texmf-dist в директорию %{buildroot}%{_texmfdistdir}, а в директории %{buildroot}%{_bindir} создать соответсвующую символьную ссылку:<br />
<br />
<pre><br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar texmf-dist/* %{buildroot}%{_texmfdistdir}<br />
mkdir -p %{buildroot}%{_bindir}<br />
pushd %{buildroot}%{_bindir}<br />
ln -sf %{_texmfdistdir}/scripts/a2ping/a2ping.pl a2ping<br />
popd<br />
</pre><br />
<br />
Пример:<br />
* https://abf.io/import/texlive-a2ping<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM&diff=18913Ошибки сборки пакетов RPM2021-04-08T12:25:14Z<p>D uragan: оформление</p>
<hr />
<div>В данной статье мы собрали несколько часто встречающихся при сборке пакетов RPM ошибок подобного рода и способы их исправления. Этот перечень создан на основе опыта прохождения практики студентами НИУ ВШЭ, но мы надеемся, что он пригодится не только им.<br />
<br />
При сборке новых версий программ с помощью Updates Builder подобные ошибки исправляются автоматически (скриптом [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/analyze_log.sh analyze_log.sh]), так что можно использовать код этого скрипта как подсказку - что надо делать. Впрочем, скрипт не универсален и может не работать в каких-то специфических случаях.<br />
<br />
== error: Installed (but unpackaged) file(s) found ==<br />
Ошибка означает, что в новой версии пакета появились новые файлы, отсутствующие ранее, и rpmbuild не знает, что с ними делать (и нужны ли ли вообще).<br />
<br />
Если вы полагаете, что эти файлы нужны (а это так в 99.9% случаев), необходимо добавить их в секцию %files spec-файла. Если у вас есть несколько подпакетов, то надо сначала определить - к какому из них эти файлы относятся. Универсального рецепта здесь нет, однако есть несколько правил:<br />
<br />
* файлы в директориях {{File|/usr/include}}, {{File|/ust/lib(64)/pkgconfig}}, добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на суффикс .so (например, {{File|libfoo.so}}), также добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на цифру (например, {{File|libfoo.so.1}}), добавляются в пакеты с соответсвующими библиотеками. Согласно правилам РОСЫ, каждая библиотека должна упаковываться в отдельный подпакет, соотевтсвующий ее имени и значению SONAME (как правило, это цифра после суффикса .so - так что файлы {{File|libfoo.so.1}} и {{File|libfoo.so.1.2}} должны находиться в пакете {{Pkg|lib(64)foo1}}). Часто ошибка "Installed but unpackaged files found) в пакетах с библиотеками вызвана изменением значения SONAME - например, вместо {{File|libfoo.so.1}} в новой версии пакета появился файл {{File|libfoo.so.2}}. В этом случае вы также дополнительно увидите ошибку "Cannot find file or directory", сообщающую, что отсутсвует файл {{File|libfoo.so.1}}. Для исправления сборки в такой ситуации достаточно изменить значение макроса major в начале spec-файла:<br />
<br />
%define major 2<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами (например вместо {{File|/usr/lib}} и {{File|/usr/lib64}} необходимо использовать макрос {{Macro|%{_libdir}}}, вместо {{File|/usr/share/man}} - {{Macro|%{_mandir}}} и так далее). Более полный список можно посмотреть с [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/dir_to_macro.pm скрипте из Updates Builder].<br />
<br />
== File not found ==<br />
Ошибка означает, что в новой версии пакета отсутсвуют некоторые файлы, присутствувавшие ранее. Причин для этого может быть несколько:<br />
<br />
* в новой версии действительно нет таких файлов - в этом случае надо просто убрать их описание из секции {{Macro|%files}}<br />
* в новой версии файлы переименованы либо перемещены в другое место. В этом случае вы также увидите ошибку "Installed (but unpackaged) file(s) found", как в случае с библиотеками (см. выше). В случае с библиотеками для исправления сразу обеих ошибок необходимо изменить значение переменной major в начале spec-файла. В общем же случае необходимо исправить секцию {{Macro|%files}}, чтобы она соответсвовала новым реалиям.<br />
* отсутсвующие файлы собираются или не собираются в зависимости от параметров окружения и сборки - опций компиляции или установленных в сборочной среде пакетов (описанных в BuildRequires). Возможно, в новой версии пакета надо использовать какие-то новые опции сборки либо добавить дополнительные сборочные зависимости для получения этих файлов. Выявить такие ситуации можно на основе анализа журналов сборки и вывода команд наподобие configure или cmake, которые сообщают, какие опцилнальные возможности будут включены при сборке, а какие - нет. Например, {{Pkg|squid}} может собираться с поддержкой аутентификации SASL и без нее. В первом случае в пакете будет присутсвовать файл basic_sasl_auth, во втором его не будет. Для ключения/отключения SASL необходимо добавить/удалить значение SASL из параметра --enable-auth-basic команды {{Cmd|configure}}, а также добавить сборочную зависимость (BuildRequires) от {{Pkg|sasl-devel}}.<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами, а также что при описании файлов в секции {{Macro|%files}} могут использоваться символы '?' и '*' (означающие один произвольный символ и любое количество<br />
произвольных символов соответсвенно).<br />
<br />
== cp: cannot stat '<some_file>': No such file or directory ==<br />
Ошибка означает, что rpmbuild не смог найти файл <some_file>, помеченный как {{Macro|%doc}} в секции %files вашего пакета. Возможно, этот файл был переименован (в этом случе вы также увидите ошибку "Installed (but unpackaged) file(s) found") - в этом случае надо изменить имя файла на новое (например, {{File|README}} могут переименовать в {{File|README.md}}).<br />
Если неупакованного файла с близким именем не появилось, то значит старый файл в новой версии отсутсвует и его определение в {{Macro|%doc}} необходимо просто удалить.<br />
<br />
== Reversed (or previously applied) patch detected ==<br />
Ошибка означает, что применявшийся к старой версии пакета патч по крайней мере частично уже применен в новой версии. Обратите внимание, что команда {{Cmd|patch}} делает такой вывод на основе попытки применить только первую часть патча! Если патч сложный и затрагивает несколько файлов или несколько мест одного файла, то необходимо вручную проверить, какие из этих изменений уже есть в новой версии, а каких нет. Для этого можно попробовать применить патч к новой версии вручную, отвечая "n" на вопрос "Assume '-R'" и "y" на предложени продолжить применять остальные части патча.<br />
<br />
Если все изменения из патча действительно уже присутсвуют в новой версии, то патч можно спокойно удалить (физически из Git-репозитория, а также из spec-файла). Если же нет, то необходимо определить - нужны ли в новой версии оставшиеся изменения и если да, то переделать патч соответствующим образом. Такой анализ уже требует некоторых познаний в том, что именно делает патч.<br />
<br />
== /var/tmp/rpm-tmp.xxxxx: line yy: cd: <some_folder_name>: No such file or directory ==<br />
Ошибка означает, что rpmbuild не может определить, в какую директорию ему перейти после распаковки архива с исходным кодом. Имя директории указывается в опции {{Macro|-n}} макроса {{Macro|%setup}} в секции {{Macro|%prep}}. Если эта опция отсутсвует, то подразумевается<br />
использование "-n %{name}-%{version}". Для исправления ошибки необходимо посмотреть, как расположены файлы в новой версии архива с исходным кодом - обычно такой архив содержит директорию вида "<имя_программы>-<версия>", но время от времени разработчики могут что-то изменять (например, переименовывать директорию просто в <имя_программы>. Для исправления<br />
ошибки необходимо соответсвующим образом исправить значение опции "-n" макроса {{Macro|%setup}}.<br />
<br />
== empty-debug-info и debuginfo-without-sources ==<br />
Ошибки означают, что rpmbuild не смог должным образом сформировать подпакет с отладочной информацией. Две основные причины такого поведения:<br />
<br />
* в пакете нет исполнимых файлов или библиотек. Если в пакете при этом вообще нет архитектурно-зависимых файлов (т.е. пакеты для разных архитектур имею абсолютно одинаковое содержимое), то необходимо объявить пакет как независимый от архитектуры, добавив в заголовок spec-файла декларацию "BuildArch: noarch". Если же архитектурно-зависимые файлы все-таки есть (например, какие-то данные могут быть специфичны для каждой арзитектуры; другой типичный пример - проприетарное приложение, которое уже поставляется в виде бинарных файлов бех отладочной информации), то необходимо отключить генерацию debug-пакетов, сбросив определение макроса {{Macro|debug_package}} в начале spec-файла:<br />
<br />
%define debug_package %{nil}<br />
<br />
* скрипты сборки приложения в пакете устроены таким образом, что сразу удаляют отладочную информацию из собранных файлов (например, явно вызывают команду strip либо просто не передают опцию "-g" компилятору). В таких случаях необходимо посмотреть, как заставить скрипты сборки оставить отладочную информацию. Иногда этого можно добиться с помощью переменных среды, а иногда может потребоваться патч, изменяющий сборочные скрипты. Если никакие способы не помогают, то можно отключить генерацию debug-пакетов, как описано выше, но делать так не рекомендуется - эти пакеты очень полезны для анализа ошибок в случае падений приложения.<br />
<br />
Остановимся подробнее на втором пункте. Большинство приложений позволяют настраивать передаваемые компилятору опции при старте сборки - например, при вызове {{Prog|configure}} или {{Prog|cmake}}. Для генерации отладочной информации для подобных приложений вам не нужно прилагать особых усилий - достаточно вместо прямого вызова {{Prog|configure}} или {{Prog|cmake}} использовать соответствующие макросы {{Prog|rpm}} (в нашем примере - {{Macro|%configure2_5x}} или {{Macro|%cmake}} соответственно). Если использование макросов не помогает (либо в проекте не используются стандартные средства типа GNU Autotools или CMake), необходимо изучить схему сборки и посмотреть - нельзя ли на нее повлиять как-то еще - например, специфическими опциями либо переменными окружения. Типичными переменными, которые могут повлиять на сборку, являются {{Var|CFLAGS}}, {{Var|CXXFLAGS}} и {{Var|CPPFLAGS}}. Мы рекомендуем выставить эти переменные в макрос {{Macro|%optflags}}; при этом может оказаться необходимым перед использованием {{Macro|%%optflags}} вызвать макрос {{Macro|%%setup_compile_flag}} (например так сделано в пакете [[https://abf.io/import/slock/commit/78a9ac338470558c7a38d1709ce6d9036e5bb408#diff-F2R24 slock]].<br />
<br />
Обратите внимание на использование кавычек при выставлении переменных среды - они необходимы, поскольку макрос разворачивается в большой набор опций, разделенных пробелами.<br />
<br />
Бывают ситуации, когда повлиять на сборку извне нельзя никак - в скриптах сборки или файлах типа Makefile инструкции сборки "забиты" намертво. В таких случаях необходимо подготовить патч, добавляющий во все вызовы компилятора опцию {{Var|-g}}. Помимо опции {{Var|-g}} у компилятора, повлиять на отладочную информацию может компоновщик - например, его опции {{Var|-s}} и {{Var|-S}}, удаляющие подобные данные из результирующих бинарных файлов. Если такие опции явно передаются компоновщику в скриптах сборки либо файлах Makefile, то необходимо подготовить патч, убирающий их - например, так сделано в пакете [[https://abf.io/import/kicad/commit/c93e3d9911e3b3be485ee5dd01cbea723a087729#diff-13 kicad]].<br />
<br />
== Error: Can't locate Some/Perl/Module.pm in @INC ==<br />
Ошибка означает, что для сборки необходим Perl-модуль {{File|Some/Perl/Module.pm}}, который не был обнаружен в сборочном окружении.<br />
<br />
Для исправления ошибки необходимо добавить сборочную зависимость от такого модуля в spec-файл:<br />
<br />
BuildRequires: perl(Some::Perl::Module)<br />
<br />
Предварительно необходимо убедиться, что такой модуль вообще существует - попробовать его установить с помощью dnf (в rosa2019.1 и новее) либо urpmi (в rosa2016.1):<br />
<br />
# dnf install 'perl(Some::Perl::Module)'<br />
<br />
# urpmi 'perl(Some::Perl::Module)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с модулем в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый модуль может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый модуль необходимо перенести в репозиторий Main.<br />
<br />
== Package(s) suggested but not available ==<br />
Данная ошибка может встречаться при сборке расширений языка R. Она означает, что у собираемого пакета есть необязательная зависимость от каких-то других модулей, которые в сборочной среде отсутствуют. В идеале для каждой такой зависимости необходимо прописать BuildRequires и Requires - например, если ошибка относится к модулю "foo", то нужны зависимости от R-foo:<br />
<br />
BuildRequires: R-foo<br />
Requires: R-foo<br />
<br />
Предварительно необходимо убедиться, что такой пакет вообще есть в репозиториях - вывод команды "urpmq R-foo" должен быть непуст. Если пакета нет, то желательно его сначала собрать и добавить в репозитории. Однако при сборке может оказаться, что он зависит от того пакета, который вы собирали до этого и для которого вы собственно и хотите добавить зависимость R-foo. В этом случае первый пакет можно собрать и без R-foo, закомментировав при этом команду "%{_bindir}/R CMD check %{packname}" в секции %check. После этого можно будет уже собрать R-foo и вернуться к исходному пакету, добавив в него зависимость от R-foo и включив тесты в секции %check<br />
<br />
== ERROR: dependency(ies) not available ==<br />
Данная ошибка также может встречаться при сборке расширений языка R, но в отличие от предыдущей, здесь речь идет об обязательных зависимостях сборки. Без них пакет не может быть собран, поэтому вам необходимо добавить в spec-файл соответсвующие BuildRequiers и Requires, а при необходимости предварительно собрать нужные пакеты в репозитории РОСЫ.<br />
<br />
== hunk FAILED -- saving rejects ==<br />
Данная ошибка означает, что один из патчей (какой именно - указано в выводе rpmbuild) не может быть применен без изменений к новой версии программы. Обычно это означает, что патч необходимо переделать (предварительно определив - нужен ли он еще), что требует определенной квалификации. Однако иногда такая ошибка возникает из-за "строгости" rpmbuild при применении патчей и проблемный патч может быть исправлен в автоматическом режиме с помощью утилиты rediff_patch.<br />
<br />
Для этого достаточно склонировать себе Git-репозиторий, перейти в склонированную папку, поместить туда архив с исходным кодом новой версии и запустит rediff_patch, передав ей нужный патч к качестве аргумента:<br />
<br />
$ abf get myrepo/myproject<br />
$ cd myproject<br />
$ wget http://project-upstream.org/new-version.tgz<br />
$ rediff_patch <some_patch_to_rediff><br />
<br />
Если все сложится удачно, то радом со старым патчем "some_patch_to_rediff" появится новый - "some_patch_to_rediff.new" Если же что-то пойдет не так, то в текущей директории останутся папка "rediff_patch" с подпапками вида "myproject.orig" и "myproject" - содержащие соответсвенно оригинальный исходный код и исходный код, получившийся после попытки применить<br />
патч. Во второй папке вы найдете файлы с расширениями *rej - это куски патчей, которые применить не удалось.<br />
<br />
== package 'foo' not found ==<br />
Аналогична следующей ошибке<br />
<br />
== "No package '.*' found" ==<br />
Такая ошибка возникает, если пакет проверяет необходимые сборочные зависимости с помощью {{Cmd|pkgconfig}} и не обнаруживает одну из них.<br />
<br />
Для исправления ошибки достаточно добавить нужную зависимость сборки в spec-файл:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Предварительно необходимо убедиться, что такая зависимость может быть разрешена - попробовать ее установить с помощью {{Cmd|urpmi}}:<br />
<br />
# urpmi 'pkgconfig(foo)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с соответсвующей библиотекой (как правило, она и называется '''libfoo''') в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый пакет может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый пакет необходимо перенести в репозиторий Main.<br />
<br />
== /usr/bin/ld: cannot find -lfoo ==<br />
Данная ошибка возникает при линковке уже собранных объектных файлов и означает, что линкер не смог найти библиотеку "foo". Для исправления ошибки достаточно добавить зависимость от библиотеки в spec-файл. Чтобы определить, как именно эту зависимость прописать, необходимо сначала поискать devel-пакет для библиотеки {{Pkg|libfoo}} (или {{Pkg|lib64foo}} в 64битной системе) с помощью urpmq:<br />
<br />
# urpmq -a libfoo<br />
lib64foo1<br />
lib64foo-devel<br />
<br />
Интересующий нас пакет - тот, что оканчивается на -devel. Посмотрим, что он предоставляет:<br />
# urpmq --provides libfoo-devel<br />
lib64foo-devel: devel(libfoo(64bit))<br />
lib64foo-devel: lib64sasl-devel[== 2.1.25]<br />
lib64foo-devel: libsasl-devel[== 2.1.25]<br />
lib64foo-devel: libfoo-devel[== 2.1.25]<br />
lib64foo-devel: sasl-devel[== 2.1.25-7]<br />
lib64foo-devel: lib64foo-devel[== 2.1.25-7:2014.1]<br />
lib64foo-devel: pkgconfig(foo)[== 2.1.25-7]<br />
<br />
Из данного набора необходимо выбрать что-то одно. В РОСЕ отдается предпочтение зависимостям вида '''pkgconfig(...)''', так что в нашем примере в spec-файл необходимо добавить следующую строку:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Если pkgconfig(foo) не окажется в выводе urpmq, то надо добавить зависимость от foo-devel, а если и ее нет - то от libfoo-devel.<br />
<br />
== Build.PL: No such file or directory ==<br />
Такая ошибка означает, что предыдущая версия пакета собиралась с помощью скрипт Build.PL, отсутсвующего в новой версии. Часто встречающаяся ситуация - замена Build.PL на Makefile.PL. Если в архиве с исходным кодом новой версии есть скрипт Makefile.PL, то в spec-файле необходимо произвести следующие замены:<br />
<br />
* "/Build.PL installdirs=vendor" -> "Makefile.PL INSTALLDIRS=vendor"<br />
* ./Build install destdir=%{buildroot} -> %makeinstall_std<br />
* perl Build.PL install destdir=%{buildroot} -> %makeinstall_std<br />
* ./Build test -> %make test<br />
* ./Build -> %make<br />
<br />
Для примера можно посмотреть на пакет ...<br />
<br />
Если же скрипта Makefile.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== Makefile.PL: No such file or directory ==<br />
Возможна и обратная ситуация - вместо Makefile.PL разработчики перешли на Build.PL или что-то еще. Если в архиве с новым исходным кодом есть файл Build.PL, то необходимо провести в spec-файле замены, обратные приведенным в предыдущем пункте:<br />
<br />
* "Makefile.PL INSTALLDIRS=vendor" -> "./Build.PL installdirs=vendor"<br />
* %makeinstall_std -> ./Build install destdir=%{buildroot} <br />
* (если предыдущая замена не сработала) %makeinstall_std -> perl Build.PL install destdir=%{buildroot}<br />
* %make test -> ./Build test<br />
* %make -> ./Build<br />
<br />
Если же скрипта Build.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== fg: no job control ==<br />
Ошибка означает, что внутри spec-файла используется макрос RPM, не поддерживаемый в РОСЕ. Поддерживается или нет каждый конкретный макрос, можно узнать с помощью команды {{Cmd|rpm --eval}}:<br />
<br />
$ rpm --eval %macro_name<br />
<br />
Если {{Prog|rpm}} ничего не знает о таком макросе, то результатом выполнения этой команды будет "%macro_name". В противном случае {{Prog|rpm}} развернет определение макроса.<br />
<br />
== Package check "/usr/bin/rpmlint ..." failed ==<br />
Для проверки соблюдения политик сборки и оформления spec-файлов, в Росе используется утилита [[Rpmlint]]. Многие ошибки этой утилиты некритичны, однако многие имеют "вес" (badness) и если суммарный вес ошибок для пакета больше или равен 50, то сборка завершается с ошибкой. Если это ваш случай - то первым делом необходимо поискать в логе ошибки, для которых светится "Badness: 50" и исправлять их. Перечень всех ошибок можно найти здесь: [[Rpmlint Errors]]<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_TeXLive&diff=18912Сборка пакетов-расширений для TeXLive2021-04-08T12:16:23Z<p>D uragan: оформление</p>
<hr />
<div>TeX - система компьютерной вёрстки, широко используемая по всему миру.<br />
<br />
В Linux в настоящее время активно используется реализация от проекта {{Prog|texlive}}, которая включает в себя не просто основные инстурменты верстки,<br />
но и множество дополнений и расширений (дополнительных шрифтов, пакетов с поддержкой разлицных языков, шаблонов диссертаций и презентаций и так далее).<br />
<br />
В РОСЕ каждое такое дополнение оформляется как отдельный RPM-пакет. <br />
<br />
Рассмотрим процесс упаковки расширения с названием '''TEXPKG''' в пакет {{Pkg|texlive-<TEXPKG>}}<br />
<br />
Сначала проверяем, что страничка пакета доступна по адресу http://www.ctan.org/tex-archive/macros/latex/contrib/<TEXPKG>. Эта ссылка должна быть прописана в URL spec-файла. Со странички проекта берем Summary (не более 80 симполов), лицензию (тэг License) и описание (для секции %description). Если есть версия - берем ее со странички, если нет - используем в качестве версии дату, когда вы скачали исходники, в формате ГГГГММДД (например, 20191231).<br />
<br />
Далее ищем в директории http://mirrors.ctan.org/systems/texlive/tlnet/archive/ файл {{File|<TEXPKG>.tar.xz}}.<br />
Там же могут находиться файлы {{File|<TEXPKG>.doc.tar.xz}} и {{File|<TEXPKG>.source.tar.xz}} - если есть, их тоже берем.<br />
<br />
Их надо прописать в качестве Sources:<br />
<br />
Source0: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.tar.xz<br />
Source1: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.doc.tar.xz<br />
Source2: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.source.tar.xz<br />
<br />
Все эти файлы необходимо скачать и загрузить на http://file-store.rosalinux.ru/. Для аутентификации необходимо использовать те же логин и пароль, что и на ABF. Для каждого файла File Store сгенерирует хэш, который необходимо прописать в гите в файле .abf.yml, например как в https://abf.io/import/texlive-accents/blob/rosa2019.1/.abf.yml<br />
<br />
Внутри ахивов обязательно есть папки {{File|tlpkg/tlpobj}} - в них лежат файлы с информацией о пакете. Если вдруг на страничке пакета не оказалось<br />
каких-то данных (версии, описания и тому подобного), то поищите их здесь. Здесь же могут быть прописаны зависимости пакета от других пакетов texlive<br />
(со словом depend) - из надо обязательно указать как Requires в spec-файле.<br />
<br />
Например, если в tlpkg/tlpobj/<TEXPKG> есть запись<br />
<br />
depend babel-belarusian<br />
<br />
то в spec-файле должна присутсвовать соответсвующая зависимоcть<br />
<br />
Requires: texlive-babel-belarusian<br />
<br />
Значение тэга Group для пакетов texlive - всегда '''Publishing'''.<br />
<br />
Как правило, пакеты являются арзитектурно-независимыми, поэтому надо дабавить в spec-файл запись<br />
<br />
BuildArch: noarch<br />
<br />
(если пакет является архитектурно-зависимым, то rpmbuild его не соберет с соответсующей ошибкой - тогда BuildArch надо убрать).<br />
<br />
Всем texlive-пакетам необходимо прописать сборочную зависимость (BuildRequires) от {{Pkg|texlive-tlpkg}}. Этот же пакет<br />
надо указать как предустановочную зависимость ("Requires(pre)"). В качестве пост-установочной зависимости post-скрипта ("Requires(post)") надо указать<br />
{{Pkg|texlive-kpathsea}}.<br />
<br />
Для большинства пакетов, секция '''%prep''' сводится к распаковке архивов, например:<br />
<br />
%setup -c -a0 -a1 -a2<br />
<br />
секция '''%build''' отсутствует, а '''%install''' сводится к копированию директорий, содержащихся внутри архивов (за исключением директории {{File|tlpkg}}), в {{File| %{buildroot}%{_texmfdistdir} }} (которую надо предварительно создать):<br />
<br />
%install<br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar fonts tex doc source %{buildroot}%{_texmfdistdir}<br />
<br />
(проследите, чтобы скопированы были все директории из архивов, кроме tlpkg) <br />
<br />
Эти же директории достаточно указать в секции %files, пометив sources и doc как документацию:<br />
<br />
%files<br />
%{_texmfdistdir}/tex/latex/<TEXPKG><br />
%{_texmfdistdir}/fonts/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/source/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/doc/latex/<TEXPKG><br />
<br />
Подготовив spec-файл и скачав архивы с исходным кодом, необходимо убедиться в возможности собрать пакет с помощью {{Cmd|rpmbuild -bb}}. Если проблем нет - то собираем src.rpm ({{Cmd|rpmbuild -bs}}) и создаем из него проект в своем репозитории на ABF.<br />
<br />
Примеры texlive пакетов:<br />
* https://abf.io/import/texlive-mpgraphics<br />
* https://abf.io/import/texlive-mceinleger<br />
* https://abf.io/import/texlive-makecmds<br />
<br />
(смотрите ветку rosa2019.1)<br />
<br />
== Пакеты со скриптами ==<br />
Для некоторых модулей по ссылке http://ctan.altspu.ru/systems/texlive/tlnet/archive/<br />
доступен не только архив с исходным кодом, но и дополнительные пакеты под разные ОС и архитектуры.<br />
Для таких модулей помимо описанных выше дейтсвий надо произвести дополнительные манипуляции,<br />
добавив файлы, присутсвующие в ОС-специфичных пакетах. Как правило, эти манипуляции<br />
сводятся к созданию символьных ссылок на скрипты в местах, где в ОС располагаются файлы для запуска<br />
(в случае Linux - в директории /bin или /usr/bin).<br />
<br />
Например, для a2ping мы видим следующие файлы:<br />
<br />
...<br />
a2ping.tar.xz<br />
a2ping.win32.tar.xz<br />
a2ping.x86_64-cygwin.tar.xz<br />
a2ping.x86_64-darwin.tar.xz<br />
a2ping.x86_64-darwinlegacy.tar.xz<br />
a2ping.x86_64-linux.tar.xz.<br />
...<br />
<br />
Скачаем a2ping.x86_64-linux.tar.xz и заглянем внутрь - там помимо служебной директории {{File|tlpgk}} мы увидим директорию {{File|bin}}, внутри нее директорию {{File|x86_64-linux}}, а там - символьную ссылку {{File|a2ping}}:<br />
<br />
<pre><br />
$ tar xf a2ping.x86_64-linux.tar.xz<br />
$ ls -l bin/x86_64-linux/<br />
total 0<br />
lrwxrwxrwx 1 user users 41 Oct 4 2018 a2ping -> ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
</pre><br />
<br />
Как видим, ссылается она на скрипт ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
<br />
Сам скрипт находится в архиве с исходным кодом (a2ping.tar.xz), в директории {{File|texmf-dist}}. При сборке пакета, мы должны положить содержимое texmf-dist в директорию %{buildroot}%{_texmfdistdir}, а в директории %{buildroot}%{_bindir} создать соответсвующую символьную ссылку:<br />
<br />
<pre><br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar texmf-dist/* %{buildroot}%{_texmfdistdir}<br />
mkdir -p %{buildroot}%{_bindir}<br />
pushd %{buildroot}%{_bindir}<br />
ln -sf %{_texmfdistdir}/scripts/a2ping/a2ping.pl a2ping<br />
popd<br />
</pre><br />
<br />
Пример:<br />
* https://abf.io/import/texlive-a2ping<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_TeXLive&diff=18911Сборка пакетов-расширений для TeXLive2021-04-08T12:15:42Z<p>D uragan: оформление</p>
<hr />
<div>TeX - система компьютерной вёрстки, широко используемая по всему миру.<br />
<br />
В Linux в настоящее время активно используется реализация от проекта {{Prog|texlive}}, которая включает в себя не просто основные инстурменты верстки,<br />
но и множество дополнений и расширений (дополнительных шрифтов, пакетов с поддержкой разлицных языков, шаблонов диссертаций и презентаций и так далее).<br />
<br />
В РОСЕ каждое такое дополнение оформляется как отдельный RPM-пакет. <br />
<br />
Рассмотрим процесс упаковки расширения с названием '''TEXPKG''' в пакет {{Pkg|texlive-<TEXPKG>}}<br />
<br />
Сначала проверяем, что страничка пакета доступна по адресу http://www.ctan.org/tex-archive/macros/latex/contrib/<TEXPKG>. Эта ссылка должна быть прописана в URL spec-файла. Со странички проекта берем Summary (не более 80 симполов), лицензию (тэг License) и описание (для секции %description). Если есть версия - берем ее со странички, если нет - используем в качестве версии дату, когда вы скачали исходники, в формате ГГГГММДД (например, 20191231).<br />
<br />
Далее ищем в директории http://mirrors.ctan.org/systems/texlive/tlnet/archive/ файл {{File|<TEXPKG>.tar.xz}}.<br />
Там же могут находиться файлы {{File|<TEXPKG>.doc.tar.xz}} и {{File|<TEXPKG>.source.tar.xz}} - если есть, их тоже берем.<br />
<br />
Их надо прописать в качестве Sources:<br />
<br />
Source0: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.tar.xz<br />
Source1: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.doc.tar.xz<br />
Source2: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.source.tar.xz<br />
<br />
Все эти файлы необходимо скачать и загрузить на http://file-store.rosalinux.ru/. Для аутентификации необходимо использовать те же логин и пароль, что и на ABF. Для каждого файла File Store сгенерирует хэш, который необходимо прописать в гите в файле .abf.yml, например как в https://abf.io/import/texlive-accents/blob/rosa2019.1/.abf.yml<br />
<br />
Внутри ахивов обязательно есть папки {{File|tlpkg/tlpobj}} - в них лежат файлы с информацией о пакете. Если вдруг на страничке пакета не оказалось<br />
каких-то данных (версии, описания и тому подобного), то поищите их здесь. Здесь же могут быть прописаны зависимости пакета от других пакетов texlive<br />
(со словом depend) - из надо обязательно указать как Requires в spec-файле.<br />
<br />
Например, если в tlpkg/tlpobj/<TEXPKG> есть запись<br />
<br />
depend babel-belarusian<br />
<br />
то в spec-файле должна присутсвовать соответсвующая зависимоcть<br />
<br />
Requires: texlive-babel-belarusian<br />
<br />
Значение тэга Group для пакетов texlive - всегда '''Publishing'''.<br />
<br />
Как правило, пакеты являются арзитектурно-независимыми, поэтому надо дабавить в spec-файл запись<br />
<br />
BuildArch: noarch<br />
<br />
(если пакет является архитектурно-зависимым, то rpmbuild его не соберет с соответсующей ошибкой - тогда BuildArch надо убрать).<br />
<br />
Всем texlive-пакетам необходимо прописать сборочную зависимость (BuildRequires) от {{Pkg|texlive-tlpkg}}. Этот же пакет<br />
надо указать как предустановочную зависимость ("Requires(pre)"). В качестве пост-установочной зависимости post-скрипта ("Requires(post)") надо указать<br />
{{Pkg|texlive-kpathsea}}.<br />
<br />
Для большинства пакетов, секция '''%prep''' сводится к распаковке архивов, например:<br />
<br />
%setup -c -a0 -a1 -a2<br />
<br />
секция '''%build''' отсутствует, а '''%install''' сводится к копированию директорий, содержащихся внутри архивов (за исключением директории {{File|tlpkg}}), в {{File| %{buildroot}%{_texmfdistdir} }} (которую надо предварительно создать):<br />
<br />
s %install<br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar fonts tex doc source %{buildroot}%{_texmfdistdir}<br />
<br />
(проследите, чтобы скопированы были все директории из архивов, кроме tlpkg) <br />
<br />
Эти же директории достаточно указать в секции %files, пометив sources и doc как документацию:<br />
<br />
%files<br />
%{_texmfdistdir}/tex/latex/<TEXPKG><br />
%{_texmfdistdir}/fonts/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/source/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/doc/latex/<TEXPKG><br />
<br />
Подготовив spec-файл и скачав архивы с исходным кодом, необходимо убедиться в возможности собрать пакет с помощью {{Cmd|rpmbuild -bb}}. Если проблем нет - то собираем src.rpm ({{Cmd|rpmbuild -bs}}) и создаем из него проект в своем репозитории на ABF.<br />
<br />
Примеры texlive пакетов:<br />
* https://abf.io/import/texlive-mpgraphics<br />
* https://abf.io/import/texlive-mceinleger<br />
* https://abf.io/import/texlive-makecmds<br />
<br />
(смотрите ветку rosa2019.1)<br />
<br />
== Пакеты со скриптами ==<br />
Для некоторых модулей по ссылке http://ctan.altspu.ru/systems/texlive/tlnet/archive/<br />
доступен не только архив с исходным кодом, но и дополнительные пакеты под разные ОС и архитектуры.<br />
Для таких модулей помимо описанных выше дейтсвий надо произвести дополнительные манипуляции,<br />
добавив файлы, присутсвующие в ОС-специфичных пакетах. Как правило, эти манипуляции<br />
сводятся к созданию символьных ссылок на скрипты в местах, где в ОС располагаются файлы для запуска<br />
(в случае Linux - в директории /bin или /usr/bin).<br />
<br />
Например, для a2ping мы видим следующие файлы:<br />
<br />
...<br />
a2ping.tar.xz<br />
a2ping.win32.tar.xz<br />
a2ping.x86_64-cygwin.tar.xz<br />
a2ping.x86_64-darwin.tar.xz<br />
a2ping.x86_64-darwinlegacy.tar.xz<br />
a2ping.x86_64-linux.tar.xz.<br />
...<br />
<br />
Скачаем a2ping.x86_64-linux.tar.xz и заглянем внутрь - там помимо служебной директории {{File|tlpgk}} мы увидим директорию {{File|bin}}, внутри нее директорию {{File|x86_64-linux}}, а там - символьную ссылку {{File|a2ping}}:<br />
<br />
<pre><br />
$ tar xf a2ping.x86_64-linux.tar.xz<br />
$ ls -l bin/x86_64-linux/<br />
total 0<br />
lrwxrwxrwx 1 user users 41 Oct 4 2018 a2ping -> ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
</pre><br />
<br />
Как видим, ссылается она на скрипт ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
<br />
Сам скрипт находится в архиве с исходным кодом (a2ping.tar.xz), в директории {{File|texmf-dist}}. При сборке пакета, мы должны положить содержимое texmf-dist в директорию %{buildroot}%{_texmfdistdir}, а в директории %{buildroot}%{_bindir} создать соответсвующую символьную ссылку:<br />
<br />
<pre><br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar texmf-dist/* %{buildroot}%{_texmfdistdir}<br />
mkdir -p %{buildroot}%{_bindir}<br />
pushd %{buildroot}%{_bindir}<br />
ln -sf %{_texmfdistdir}/scripts/a2ping/a2ping.pl a2ping<br />
popd<br />
</pre><br />
<br />
Пример:<br />
* https://abf.io/import/texlive-a2ping<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM&diff=18910Ошибки сборки пакетов RPM2021-04-01T07:28:18Z<p>D uragan: /* Makefile.PL: No such file or directory */ орфография/пунктуация</p>
<hr />
<div>В данной статье мы собрали несколько часто встречающихся при сборке пакетов RPM ошибок подобного рода и способы их исправления. Этот перечень создан на основе опыта прохождения практики студентами НИУ ВШЭ, но мы надеемся, что он пригодится не только им.<br />
<br />
При сборке новых версий программ с помощью Updates Builder подобные ошибки исправляются автоматически (скриптом [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/analyze_log.sh analyze_log.sh]), так что можно использовать код этого скрипта как подсказку - что надо делать. Впрочем, скрипт не универсален и может не работать в каких-то специфических случаях.<br />
<br />
== error: Installed (but unpackaged) file(s) found ==<br />
Ошибка означает, что в новой версии пакета появились новые файлы, отсутствующие ранее, и rpmbuild не знает, что с ними делать (и нужны ли ли вообще).<br />
<br />
Если вы полагаете, что эти файлы нужны (а это так в 99.9% случаев), необходимо добавить их в секцию %files spec-файла. Если у вас есть несколько подпакетов, то надо сначала определить - к какому из них эти файлы относятся. Универсального рецепта здесь нет, однако есть несколько правил:<br />
<br />
* файлы в директориях {{File|/usr/include}}, {{File|/ust/lib(64)/pkgconfig}}, добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на суффикс .so (например, {{File|libfoo.so}}), также добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на цифру (например, {{File|libfoo.so.1}}), добавляются в пакеты с соответсвующими библиотеками. Согласно правилам РОСЫ, каждая библиотека должна упаковываться в отдельный подпакет, соотевтсвующий ее имени и значению SONAME (как правило, это цифра после суффикса .so - так что файлы {{File|libfoo.so.1}} и {{File|libfoo.so.1.2}} должны находиться в пакете {{Pkg|lib(64)foo1}}). Часто ошибка "Installed but unpackaged files found) в пакетах с библиотеками вызвана изменением значения SONAME - например, вместо {{File|libfoo.so.1}} в новой версии пакета появился файл {{File|libfoo.so.2}}. В этом случае вы также дополнительно увидите ошибку "Cannot find file or directory", сообщающую, что отсутсвует файл {{File|libfoo.so.1}}. Для исправления сборки в такой ситуации достаточно изменить значение макроса major в начале spec-файла:<br />
<br />
%define major 2<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами (например вместо {{File|/usr/lib}} и {{File|/usr/lib64}} необходимо использовать макрос {{Macro|%{_libdir}}}, вместо {{File|/usr/share/man}} - {{Macro|%{_mandir}}} и так далее). Более полный список можно посмотреть с [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/dir_to_macro.pm скрипте из Updates Builder].<br />
<br />
== File not found ==<br />
Ошибка означает, что в новой версии пакета отсутсвуют некоторые файлы, присутствувавшие ранее. Причин для этого может быть несколько:<br />
<br />
* в новой версии действительно нет таких файлов - в этом случае надо просто убрать их описание из секции {{Macro|%files}}<br />
* в новой версии файлы переименованы либо перемещены в другое место. В этом случае вы также увидите ошибку "Installed (but unpackaged) file(s) found", как в случае с библиотеками (см. выше). В случае с библиотеками для исправления сразу обеих ошибок необходимо изменить значение переменной major в начале spec-файла. В общем же случае необходимо исправить секцию {{Macro|%files}}, чтобы она соответсвовала новым реалиям.<br />
* отсутсвующие файлы собираются или не собираются в зависимости от параметров окружения и сборки - опций компиляции или установленных в сборочной среде пакетов (описанных в BuildRequires). Возможно, в новой версии пакета надо использовать какие-то новые опции сборки либо добавить дополнительные сборочные зависимости для получения этих файлов. Выявить такие ситуации можно на основе анализа журналов сборки и вывода команд наподобие configure или cmake, которые сообщают, какие опцилнальные возможности будут включены при сборке, а какие - нет. Например, {{Pkg|squid}} может собираться с поддержкой аутентификации SASL и без нее. В первом случае в пакете будет присутсвовать файл basic_sasl_auth, во втором его не будет. Для ключения/отключения SASL необходимо добавить/удалить значение SASL из параметра --enable-auth-basic команды {{Cmd|configure}}, а также добавить сборочную зависимость (BuildRequires) от {{Pkg|sasl-devel}}.<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами, а также что при описании файлов в секции {{Macro|%files}} могут использоваться символы '?' и '*' (означающие один произвольный символ и любое количество<br />
произвольных символов соответсвенно).<br />
<br />
== cp: cannot stat '<some_file>': No such file or directory ==<br />
Ошибка означает, что rpmbuild не смог найти файл <some_file>, помеченный как {{Macro|%doc}} в секции %files вашего пакета. Возможно, этот файл был переименован (в этом случе вы также увидите ошибку "Installed (but unpackaged) file(s) found") - в этом случае надо изменить имя файла на новое (например, {{File|README}} могут переименовать в {{File|README.md}}).<br />
Если неупакованного файла с близким именем не появилось, то значит старый файл в новой версии отсутсвует и его определение в {{Macro|%doc}} необходимо просто удалить.<br />
<br />
== Reversed (or previously applied) patch detected ==<br />
Ошибка означает, что применявшийся к старой версии пакета патч по крайней мере частично уже применен в новой версии. Обратите внимание, что команда {{Cmd|patch}} делает такой вывод на основе попытки применить только первую часть патча! Если патч сложный и затрагивает несколько файлов или несколько мест одного файла, то необходимо вручную проверить, какие из этих изменений уже есть в новой версии, а каких нет. Для этого можно попробовать применить патч к новой версии вручную, отвечая "n" на вопрос "Assume '-R'" и "y" на предложени продолжить применять остальные части патча.<br />
<br />
Если все изменения из патча действительно уже присутсвуют в новой версии, то патч можно спокойно удалить (физически из Git-репозитория, а также из spec-файла). Если же нет, то необходимо определить - нужны ли в новой версии оставшиеся изменения и если да, то переделать патч соответствующим образом. Такой анализ уже требует некоторых познаний в том, что именно делает патч.<br />
<br />
== /var/tmp/rpm-tmp.xxxxx: line yy: cd: <some_folder_name>: No such file or directory ==<br />
Ошибка означает, что rpmbuild не может определить, в какую директорию ему перейти после распаковки архива с исходным кодом. Имя директории указывается в опции {{Macro|-n}} макроса {{Macro|%setup}} в секции {{Macro|%prep}}. Если эта опция отсутсвует, то подразумевается<br />
использование "-n %{name}-%{version}". Для исправления ошибки необходимо посмотреть, как расположены файлы в новой версии архива с исходным кодом - обычно такой архив содержит директорию вида "<имя_программы>-<версия>", но время от времени разработчики могут что-то изменять (например, переименовывать директорию просто в <имя_программы>. Для исправления<br />
ошибки необходимо соответсвующим образом исправить значение опции "-n" макроса {{Macro|%setup}}.<br />
<br />
== empty-debug-info и debuginfo-without-sources ==<br />
Ошибки означают, что rpmbuild не смог должным образом сформировать подпакет с отладочной информацией. Две основные причины такого поведения:<br />
<br />
* в пакете нет исполнимых файлов или библиотек. Если в пакете при этом вообще нет архитектурно-зависимых файлов (т.е. пакеты для разных архитектур имею абсолютно одинаковое содержимое), то необходимо объявить пакет как независимый от архитектуры, добавив в заголовок spec-файла декларацию "BuildArch: noarch". Если же архитектурно-зависимые файлы все-таки есть (например, какие-то данные могут быть специфичны для каждой арзитектуры; другой типичный пример - проприетарное приложение, которое уже поставляется в виде бинарных файлов бех отладочной информации), то необходимо отключить генерацию debug-пакетов, сбросив определение макроса {{Macro|debug_package}} в начале spec-файла:<br />
<br />
%define debug_package %{nil}<br />
<br />
* скрипты сборки приложения в пакете устроены таким образом, что сразу удаляют отладочную информацию из собранных файлов (например, явно вызывают команду strip либо просто не передают опцию "-g" компилятору). В таких случаях необходимо посмотреть, как заставить скрипты сборки оставить отладочную информацию. Иногда этого можно добиться с помощью переменных среды, а иногда может потребоваться патч, изменяющий сборочные скрипты. Если никакие способы не помогают, то можно отключить генерацию debug-пакетов, как описано выше, но делать так не рекомендуется - эти пакеты очень полезны для анализа ошибок в случае падений приложения.<br />
<br />
Остановимся подробнее на втором пункте. Большинство приложений позволяют настраивать передаваемые компилятору опции при старте сборки - например, при вызове {{Prog|configure}} или {{Prog|cmake}}. Для генерации отладочной информации для подобных приложений вам не нужно прилагать особых усилий - достаточно вместо прямого вызова {{Prog|configure}} или {{Prog|cmake}} использовать соответствующие макросы {{Prog|rpm}} (в нашем примере - {{Macro|%configure2_5x}} или {{Macro|%cmake}} соответственно). Если использование макросов не помогает (либо в проекте не используются стандартные средства типа GNU Autotools или CMake), необходимо изучить схему сборки и посмотреть - нельзя ли на нее повлиять как-то еще - например, специфическими опциями либо переменными окружения. Типичными переменными, которые могут повлиять на сборку, являются {{Var|CFLAGS}}, {{Var|CXXFLAGS}} и {{Var|CPPFLAGS}}. Мы рекомендуем выставить эти переменные в макрос {{Macro|%optflags}}; при этом может оказаться необходимым перед использованием {{Macro|%%optflags}} вызвать макрос {{Macro|%%setup_compile_flag}} (например так сделано в пакете [[https://abf.io/import/slock/commit/78a9ac338470558c7a38d1709ce6d9036e5bb408#diff-F2R24 slock]].<br />
<br />
Обратите внимание на использование кавычек при выставлении переменных среды - они необходимы, поскольку макрос разворачивается в большой набор опций, разделенных пробелами.<br />
<br />
Бывают ситуации, когда повлиять на сборку извне нельзя никак - в скриптах сборки или файлах типа Makefile инструкции сборки "забиты" намертво. В таких случаях необходимо подготовить патч, добавляющий во<br />
все вызовы компилятора опцию {{Var|-g}}. Помимо опции {{Var|-g}} у компилятора, повлиять на отладочную информацию может компоновщик - например, его опции {{Var|-s}} и {{Var|-S}}, удаляющие подобные данные из результирующих бинарных файлов. Если такие опции явно передаются компоновщику в скриптах сборки либо файлах Makefile, то необходимо подготовить патч, убирающий их - например, так сделано в пакете [[https://abf.io/import/kicad/commit/c93e3d9911e3b3be485ee5dd01cbea723a087729#diff-13 kicad]].<br />
<br />
== Error: Can't locate Some/Perl/Module.pm in @INC ==<br />
Ошибка означает, что для сборки необходим Perl-модуль {{File|Some/Perl/Module.pm}}, который не был обнаружен в сборочном окружении.<br />
<br />
Для исправления ошибки необходимо добавить сборочную зависимость от такого модуля в spec-файл:<br />
<br />
BuildRequires: perl(Some::Perl::Module)<br />
<br />
Предварительно необходимо убедиться, что такой модуль вообще существует - попробовать его установить с помощью urpmi:<br />
<br />
# urpmi 'perl(Some::Perl::Module)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с модулем в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый модуль может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый модуль необходимо перенести в репозиторий Main.<br />
<br />
== Package(s) suggested but not available ==<br />
Данная ошибка может встречаться при сборке расширений языка R. Она означает, что у собираемого пакета есть необязательная зависимость от каких-то других модулей, которые в сборочной среде отсутсвуют. В идеале для каждой такой зависимости необходимо прописать BuildRequires и Requires - например, если ошибка относится к модулю "foo", то нужны зависимости от R-foo:<br />
<br />
BuildRequires: R-foo<br />
Requires: R-foo<br />
<br />
Предварительно необходимо убедиться, что такой пакет вообще есть в репозиториях - вывод команды "urpmq R-foo" должен быть непуст. Если пакета нет, то желательно его сначала собрать и добавить в репозитории. Однако при сборке может оказаться, что он зависит от того пакета, который вы собирали до этого и для которого вы собственно и хотите добавить зависимость R-foo. В этом случае первый пакет можно собрать и без R-foo, закомментировав при этом команду "%{_bindir}/R CMD check %{packname}" в секции %check. После этого можно будет уже собрать R-foo и вернуться к исходному пакету, добавив в него зависимость от R-foo и включив тесты в секции %check<br />
<br />
== ERROR: dependency(ies) not available ==<br />
Данная ошибка также может встречаться при сборке расширений языка R, но в отличие от предыдущей, здесь речь идет об обязательных зависимостях сборки. Без них пакет не может быть собран, поэтому вам необходимо добавить в spec-файл соответсвующие BuildRequiers и Requires, а при необходимости предварительно собрать нужные пакеты в репозитории РОСЫ.<br />
<br />
== hunk FAILED -- saving rejects ==<br />
Данная ошибка означает, что один из патчей (какой именно - указано в выводе rpmbuild) не может быть применен без изменений к новой версии программы. Обычно это означает, что патч необходимо переделать (предварительно определив - нужен ли он еще), что требует определенной квалификации. Однако иногда такая ошибка возникает из-за "строгости" rpmbuild при применении патчей и проблемный патч может быть исправлен в автоматическом режиме с помощью утилиты rediff_patch.<br />
<br />
Для этого достаточно склонировать себе Git-репозиторий, перейти в склонированную папку, поместить туда архив с исходным кодом новой версии и запустит rediff_patch, передав ей нужный патч к вачестве аргумента:<br />
<br />
$ abf get myrepo/myproject<br />
$ cd myproject<br />
$ wget http://project-upstream.org/new-version.tgz<br />
$ rediff_patch <some_patch_to_rediff><br />
<br />
Если все сложится удачно, то радом со старым патчем "some_patch_to_rediff" появится новый - "some_patch_to_rediff.new" Если же что-то пойдет не так, то в текущей директории останутся папка "rediff_patch" с подпапками вида "myproject.orig" и "myproject" - содержащие соответсвенно оригинальный исходный код и исходный код, получившийся после попытки применить<br />
патч. Во второй папке вы найдете файлы с расширениями *rej - это куски патчей, которые применить не удалось.<br />
<br />
== package 'foo' not found ==<br />
Аналогична следующей ошибке<br />
== "No package '.*' found" ==<br />
Такая ошибка возникает, если пакет проверяет необходимые сборочные зависимости с помощью {{Cmd|pkgconfig}} и не обнаруживает одну из них.<br />
<br />
Для исправления ошибки достаточно добавить нужную зависимость сборки в spec-файл:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Предварительно необходимо убедиться, что такая зависимость может быть разрешена - попробовать ее установить с помощью {{Cmd|urpmi}}:<br />
<br />
# urpmi 'pkgconfig(foo)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с соответсвующей библиотекой (как правило, она и называется '''libfoo''') в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый пакет может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый пакет необходимо перенести в репозиторий Main.<br />
<br />
== /usr/bin/ld: cannot find -lfoo ==<br />
Данная ошибка возникает при линковке уже собранных объектных файлов и означает, что линкер не смог найти библиотеку "foo". Для исправления ошибки достаточно добавить зависимость от библиотеки в spec-файл. Чтобы определить, как именно эту зависимость прописать, необходимо сначала поискать devel-пакет для библиотеки {{Pkg|libfoo}} (или {{Pkg|lib64foo}} в 64битной системе) с помощью urpmq:<br />
<br />
# urpmq -a libfoo<br />
lib64foo1<br />
lib64foo-devel<br />
<br />
Интересующий нас пакет - тот, что оканчивается на -devel. Посмотрим, что он предоставляет:<br />
# urpmq --provides libfoo-devel<br />
lib64foo-devel: devel(libfoo(64bit))<br />
lib64foo-devel: lib64sasl-devel[== 2.1.25]<br />
lib64foo-devel: libsasl-devel[== 2.1.25]<br />
lib64foo-devel: libfoo-devel[== 2.1.25]<br />
lib64foo-devel: sasl-devel[== 2.1.25-7]<br />
lib64foo-devel: lib64foo-devel[== 2.1.25-7:2014.1]<br />
lib64foo-devel: pkgconfig(foo)[== 2.1.25-7]<br />
<br />
Из данного набора необходимо выбрать что-то одно. В РОСЕ отдается предпочтение зависимостям вида '''pkgconfig(...)''', так что в нашем примере в spec-файл необходимо добавить следующую строку:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Если pkgconfig(foo) не окажется в выводе urpmq, то надо добавить зависимость от foo-devel, а если и ее нет - то от libfoo-devel.<br />
<br />
== Build.PL: No such file or directory ==<br />
Такая ошибка означает, что предыдущая версия пакета собиралась с помощью скрипт Build.PL, отсутсвующего в новой версии. Часто встречающаяся ситуация - замена Build.PL на Makefile.PL. Если в архиве с исходным кодом новой версии есть скрипт Makefile.PL, то в spec-файле необходимо произвести следующие замены:<br />
<br />
* "/Build.PL installdirs=vendor" -> "Makefile.PL INSTALLDIRS=vendor"<br />
* ./Build install destdir=%{buildroot} -> %makeinstall_std<br />
* perl Build.PL install destdir=%{buildroot} -> %makeinstall_std<br />
* ./Build test -> %make test<br />
* ./Build -> %make<br />
<br />
Для примера можно посмотреть на пакет ...<br />
<br />
Если же скрипта Makefile.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== Makefile.PL: No such file or directory ==<br />
Возможна и обратная ситуация - вместо Makefile.PL разработчики перешли на Build.PL или что-то еще. Если в архиве с новым исходным кодом есть файл Build.PL, то необходимо провести в spec-файле замены, обратные приведенным в предыдущем пункте:<br />
<br />
* "Makefile.PL INSTALLDIRS=vendor" -> "./Build.PL installdirs=vendor"<br />
* %makeinstall_std -> ./Build install destdir=%{buildroot} <br />
* (если предыдущая замена не сработала) %makeinstall_std -> perl Build.PL install destdir=%{buildroot}<br />
* %make test -> ./Build test<br />
* %make -> ./Build<br />
<br />
Если же скрипта Build.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== fg: no job control ==<br />
Ошибка означает, что внутри spec-файла используется макрос RPM, не поддерживаемый в РОСЕ. Поддерживается или нет каждый конкретный макрос, можно узнать с помощью команды {{Cmd|rpm --eval}}:<br />
<br />
$ rpm --eval %macro_name<br />
<br />
Если {{Prog|rpm}} ничего не знает о таком макросе, то результатом выполнения этой команды будет "%macro_name". В противном случае {{Prog|rpm}} развернет определение макроса.<br />
<br />
== Package check "/usr/bin/rpmlint ..." failed ==<br />
Для проверки соблюдения политик сборки и оформления spec-файлов, в Росе используется утилита [[Rpmlint]]. Многие ошибки этой утилиты некритичны, однако многие имеют "вес" (badness) и если суммарный вес ошибок для пакета больше или равен 50, то сборка завершается с ошибкой. Если это ваш случай - то первым делом необходимо поискать в логе ошибки, для которых светится "Badness: 50" и исправлять их. Перечень всех ошибок можно найти здесь: [[Rpmlint Errors]]<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM&diff=18909Ошибки сборки пакетов RPM2021-03-31T08:19:23Z<p>D uragan: /* Makefile.PL: No such file or directory */</p>
<hr />
<div>В данной статье мы собрали несколько часто встречающихся при сборке пакетов RPM ошибок подобного рода и способы их исправления. Этот перечень создан на основе опыта прохождения практики студентами НИУ ВШЭ, но мы надеемся, что он пригодится не только им.<br />
<br />
При сборке новых версий программ с помощью Updates Builder подобные ошибки исправляются автоматически (скриптом [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/analyze_log.sh analyze_log.sh]), так что можно использовать код этого скрипта как подсказку - что надо делать. Впрочем, скрипт не универсален и может не работать в каких-то специфических случаях.<br />
<br />
== error: Installed (but unpackaged) file(s) found ==<br />
Ошибка означает, что в новой версии пакета появились новые файлы, отсутствующие ранее, и rpmbuild не знает, что с ними делать (и нужны ли ли вообще).<br />
<br />
Если вы полагаете, что эти файлы нужны (а это так в 99.9% случаев), необходимо добавить их в секцию %files spec-файла. Если у вас есть несколько подпакетов, то надо сначала определить - к какому из них эти файлы относятся. Универсального рецепта здесь нет, однако есть несколько правил:<br />
<br />
* файлы в директориях {{File|/usr/include}}, {{File|/ust/lib(64)/pkgconfig}}, добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на суффикс .so (например, {{File|libfoo.so}}), также добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на цифру (например, {{File|libfoo.so.1}}), добавляются в пакеты с соответсвующими библиотеками. Согласно правилам РОСЫ, каждая библиотека должна упаковываться в отдельный подпакет, соотевтсвующий ее имени и значению SONAME (как правило, это цифра после суффикса .so - так что файлы {{File|libfoo.so.1}} и {{File|libfoo.so.1.2}} должны находиться в пакете {{Pkg|lib(64)foo1}}). Часто ошибка "Installed but unpackaged files found) в пакетах с библиотеками вызвана изменением значения SONAME - например, вместо {{File|libfoo.so.1}} в новой версии пакета появился файл {{File|libfoo.so.2}}. В этом случае вы также дополнительно увидите ошибку "Cannot find file or directory", сообщающую, что отсутсвует файл {{File|libfoo.so.1}}. Для исправления сборки в такой ситуации достаточно изменить значение макроса major в начале spec-файла:<br />
<br />
%define major 2<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами (например вместо {{File|/usr/lib}} и {{File|/usr/lib64}} необходимо использовать макрос {{Macro|%{_libdir}}}, вместо {{File|/usr/share/man}} - {{Macro|%{_mandir}}} и так далее). Более полный список можно посмотреть с [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/dir_to_macro.pm скрипте из Updates Builder].<br />
<br />
== File not found ==<br />
Ошибка означает, что в новой версии пакета отсутсвуют некоторые файлы, присутствувавшие ранее. Причин для этого может быть несколько:<br />
<br />
* в новой версии действительно нет таких файлов - в этом случае надо просто убрать их описание из секции {{Macro|%files}}<br />
* в новой версии файлы переименованы либо перемещены в другое место. В этом случае вы также увидите ошибку "Installed (but unpackaged) file(s) found", как в случае с библиотеками (см. выше). В случае с библиотеками для исправления сразу обеих ошибок необходимо изменить значение переменной major в начале spec-файла. В общем же случае необходимо исправить секцию {{Macro|%files}}, чтобы она соответсвовала новым реалиям.<br />
* отсутсвующие файлы собираются или не собираются в зависимости от параметров окружения и сборки - опций компиляции или установленных в сборочной среде пакетов (описанных в BuildRequires). Возможно, в новой версии пакета надо использовать какие-то новые опции сборки либо добавить дополнительные сборочные зависимости для получения этих файлов. Выявить такие ситуации можно на основе анализа журналов сборки и вывода команд наподобие configure или cmake, которые сообщают, какие опцилнальные возможности будут включены при сборке, а какие - нет. Например, {{Pkg|squid}} может собираться с поддержкой аутентификации SASL и без нее. В первом случае в пакете будет присутсвовать файл basic_sasl_auth, во втором его не будет. Для ключения/отключения SASL необходимо добавить/удалить значение SASL из параметра --enable-auth-basic команды {{Cmd|configure}}, а также добавить сборочную зависимость (BuildRequires) от {{Pkg|sasl-devel}}.<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами, а также что при описании файлов в секции {{Macro|%files}} могут использоваться символы '?' и '*' (означающие один произвольный символ и любое количество<br />
произвольных символов соответсвенно).<br />
<br />
== cp: cannot stat '<some_file>': No such file or directory ==<br />
Ошибка означает, что rpmbuild не смог найти файл <some_file>, помеченный как {{Macro|%doc}} в секции %files вашего пакета. Возможно, этот файл был переименован (в этом случе вы также увидите ошибку "Installed (but unpackaged) file(s) found") - в этом случае надо изменить имя файла на новое (например, {{File|README}} могут переименовать в {{File|README.md}}).<br />
Если неупакованного файла с близким именем не появилось, то значит старый файл в новой версии отсутсвует и его определение в {{Macro|%doc}} необходимо просто удалить.<br />
<br />
== Reversed (or previously applied) patch detected ==<br />
Ошибка означает, что применявшийся к старой версии пакета патч по крайней мере частично уже применен в новой версии. Обратите внимание, что команда {{Cmd|patch}} делает такой вывод на основе попытки применить только первую часть патча! Если патч сложный и затрагивает несколько файлов или несколько мест одного файла, то необходимо вручную проверить, какие из этих изменений уже есть в новой версии, а каких нет. Для этого можно попробовать применить патч к новой версии вручную, отвечая "n" на вопрос "Assume '-R'" и "y" на предложени продолжить применять остальные части патча.<br />
<br />
Если все изменения из патча действительно уже присутсвуют в новой версии, то патч можно спокойно удалить (физически из Git-репозитория, а также из spec-файла). Если же нет, то необходимо определить - нужны ли в новой версии оставшиеся изменения и если да, то переделать патч соответствующим образом. Такой анализ уже требует некоторых познаний в том, что именно делает патч.<br />
<br />
== /var/tmp/rpm-tmp.xxxxx: line yy: cd: <some_folder_name>: No such file or directory ==<br />
Ошибка означает, что rpmbuild не может определить, в какую директорию ему перейти после распаковки архива с исходным кодом. Имя директории указывается в опции {{Macro|-n}} макроса {{Macro|%setup}} в секции {{Macro|%prep}}. Если эта опция отсутсвует, то подразумевается<br />
использование "-n %{name}-%{version}". Для исправления ошибки необходимо посмотреть, как расположены файлы в новой версии архива с исходным кодом - обычно такой архив содержит директорию вида "<имя_программы>-<версия>", но время от времени разработчики могут что-то изменять (например, переименовывать директорию просто в <имя_программы>. Для исправления<br />
ошибки необходимо соответсвующим образом исправить значение опции "-n" макроса {{Macro|%setup}}.<br />
<br />
== empty-debug-info и debuginfo-without-sources ==<br />
Ошибки означают, что rpmbuild не смог должным образом сформировать подпакет с отладочной информацией. Две основные причины такого поведения:<br />
<br />
* в пакете нет исполнимых файлов или библиотек. Если в пакете при этом вообще нет архитектурно-зависимых файлов (т.е. пакеты для разных архитектур имею абсолютно одинаковое содержимое), то необходимо объявить пакет как независимый от архитектуры, добавив в заголовок spec-файла декларацию "BuildArch: noarch". Если же архитектурно-зависимые файлы все-таки есть (например, какие-то данные могут быть специфичны для каждой арзитектуры; другой типичный пример - проприетарное приложение, которое уже поставляется в виде бинарных файлов бех отладочной информации), то необходимо отключить генерацию debug-пакетов, сбросив определение макроса {{Macro|debug_package}} в начале spec-файла:<br />
<br />
%define debug_package %{nil}<br />
<br />
* скрипты сборки приложения в пакете устроены таким образом, что сразу удаляют отладочную информацию из собранных файлов (например, явно вызывают команду strip либо просто не передают опцию "-g" компилятору). В таких случаях необходимо посмотреть, как заставить скрипты сборки оставить отладочную информацию. Иногда этого можно добиться с помощью переменных среды, а иногда может потребоваться патч, изменяющий сборочные скрипты. Если никакие способы не помогают, то можно отключить генерацию debug-пакетов, как описано выше, но делать так не рекомендуется - эти пакеты очень полезны для анализа ошибок в случае падений приложения.<br />
<br />
Остановимся подробнее на втором пункте. Большинство приложений позволяют настраивать передаваемые компилятору опции при старте сборки - например, при вызове {{Prog|configure}} или {{Prog|cmake}}. Для генерации отладочной информации для подобных приложений вам не нужно прилагать особых усилий - достаточно вместо прямого вызова {{Prog|configure}} или {{Prog|cmake}} использовать соответствующие макросы {{Prog|rpm}} (в нашем примере - {{Macro|%configure2_5x}} или {{Macro|%cmake}} соответственно). Если использование макросов не помогает (либо в проекте не используются стандартные средства типа GNU Autotools или CMake), необходимо изучить схему сборки и посмотреть - нельзя ли на нее повлиять как-то еще - например, специфическими опциями либо переменными окружения. Типичными переменными, которые могут повлиять на сборку, являются {{Var|CFLAGS}}, {{Var|CXXFLAGS}} и {{Var|CPPFLAGS}}. Мы рекомендуем выставить эти переменные в макрос {{Macro|%optflags}}; при этом может оказаться необходимым перед использованием {{Macro|%%optflags}} вызвать макрос {{Macro|%%setup_compile_flag}} (например так сделано в пакете [[https://abf.io/import/slock/commit/78a9ac338470558c7a38d1709ce6d9036e5bb408#diff-F2R24 slock]].<br />
<br />
Обратите внимание на использование кавычек при выставлении переменных среды - они необходимы, поскольку макрос разворачивается в большой набор опций, разделенных пробелами.<br />
<br />
Бывают ситуации, когда повлиять на сборку извне нельзя никак - в скриптах сборки или файлах типа Makefile инструкции сборки "забиты" намертво. В таких случаях необходимо подготовить патч, добавляющий во<br />
все вызовы компилятора опцию {{Var|-g}}. Помимо опции {{Var|-g}} у компилятора, повлиять на отладочную информацию может компоновщик - например, его опции {{Var|-s}} и {{Var|-S}}, удаляющие подобные данные из результирующих бинарных файлов. Если такие опции явно передаются компоновщику в скриптах сборки либо файлах Makefile, то необходимо подготовить патч, убирающий их - например, так сделано в пакете [[https://abf.io/import/kicad/commit/c93e3d9911e3b3be485ee5dd01cbea723a087729#diff-13 kicad]].<br />
<br />
== Error: Can't locate Some/Perl/Module.pm in @INC ==<br />
Ошибка означает, что для сборки необходим Perl-модуль {{File|Some/Perl/Module.pm}}, который не был обнаружен в сборочном окружении.<br />
<br />
Для исправления ошибки необходимо добавить сборочную зависимость от такого модуля в spec-файл:<br />
<br />
BuildRequires: perl(Some::Perl::Module)<br />
<br />
Предварительно необходимо убедиться, что такой модуль вообще существует - попробовать его установить с помощью urpmi:<br />
<br />
# urpmi 'perl(Some::Perl::Module)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с модулем в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый модуль может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый модуль необходимо перенести в репозиторий Main.<br />
<br />
== Package(s) suggested but not available ==<br />
Данная ошибка может встречаться при сборке расширений языка R. Она означает, что у собираемого пакета есть необязательная зависимость от каких-то других модулей, которые в сборочной среде отсутсвуют. В идеале для каждой такой зависимости необходимо прописать BuildRequires и Requires - например, если ошибка относится к модулю "foo", то нужны зависимости от R-foo:<br />
<br />
BuildRequires: R-foo<br />
Requires: R-foo<br />
<br />
Предварительно необходимо убедиться, что такой пакет вообще есть в репозиториях - вывод команды "urpmq R-foo" должен быть непуст. Если пакета нет, то желательно его сначала собрать и добавить в репозитории. Однако при сборке может оказаться, что он зависит от того пакета, который вы собирали до этого и для которого вы собственно и хотите добавить зависимость R-foo. В этом случае первый пакет можно собрать и без R-foo, закомментировав при этом команду "%{_bindir}/R CMD check %{packname}" в секции %check. После этого можно будет уже собрать R-foo и вернуться к исходному пакету, добавив в него зависимость от R-foo и включив тесты в секции %check<br />
<br />
== ERROR: dependency(ies) not available ==<br />
Данная ошибка также может встречаться при сборке расширений языка R, но в отличие от предыдущей, здесь речь идет об обязательных зависимостях сборки. Без них пакет не может быть собран, поэтому вам необходимо добавить в spec-файл соответсвующие BuildRequiers и Requires, а при необходимости предварительно собрать нужные пакеты в репозитории РОСЫ.<br />
<br />
== hunk FAILED -- saving rejects ==<br />
Данная ошибка означает, что один из патчей (какой именно - указано в выводе rpmbuild) не может быть применен без изменений к новой версии программы. Обычно это означает, что патч необходимо переделать (предварительно определив - нужен ли он еще), что требует определенной квалификации. Однако иногда такая ошибка возникает из-за "строгости" rpmbuild при применении патчей и проблемный патч может быть исправлен в автоматическом режиме с помощью утилиты rediff_patch.<br />
<br />
Для этого достаточно склонировать себе Git-репозиторий, перейти в склонированную папку, поместить туда архив с исходным кодом новой версии и запустит rediff_patch, передав ей нужный патч к вачестве аргумента:<br />
<br />
$ abf get myrepo/myproject<br />
$ cd myproject<br />
$ wget http://project-upstream.org/new-version.tgz<br />
$ rediff_patch <some_patch_to_rediff><br />
<br />
Если все сложится удачно, то радом со старым патчем "some_patch_to_rediff" появится новый - "some_patch_to_rediff.new" Если же что-то пойдет не так, то в текущей директории останутся папка "rediff_patch" с подпапками вида "myproject.orig" и "myproject" - содержащие соответсвенно оригинальный исходный код и исходный код, получившийся после попытки применить<br />
патч. Во второй папке вы найдете файлы с расширениями *rej - это куски патчей, которые применить не удалось.<br />
<br />
== package 'foo' not found ==<br />
Аналогична следующей ошибке<br />
== "No package '.*' found" ==<br />
Такая ошибка возникает, если пакет проверяет необходимые сборочные зависимости с помощью {{Cmd|pkgconfig}} и не обнаруживает одну из них.<br />
<br />
Для исправления ошибки достаточно добавить нужную зависимость сборки в spec-файл:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Предварительно необходимо убедиться, что такая зависимость может быть разрешена - попробовать ее установить с помощью {{Cmd|urpmi}}:<br />
<br />
# urpmi 'pkgconfig(foo)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с соответсвующей библиотекой (как правило, она и называется '''libfoo''') в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый пакет может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый пакет необходимо перенести в репозиторий Main.<br />
<br />
== /usr/bin/ld: cannot find -lfoo ==<br />
Данная ошибка возникает при линковке уже собранных объектных файлов и означает, что линкер не смог найти библиотеку "foo". Для исправления ошибки достаточно добавить зависимость от библиотеки в spec-файл. Чтобы определить, как именно эту зависимость прописать, необходимо сначала поискать devel-пакет для библиотеки {{Pkg|libfoo}} (или {{Pkg|lib64foo}} в 64битной системе) с помощью urpmq:<br />
<br />
# urpmq -a libfoo<br />
lib64foo1<br />
lib64foo-devel<br />
<br />
Интересующий нас пакет - тот, что оканчивается на -devel. Посмотрим, что он предоставляет:<br />
# urpmq --provides libfoo-devel<br />
lib64foo-devel: devel(libfoo(64bit))<br />
lib64foo-devel: lib64sasl-devel[== 2.1.25]<br />
lib64foo-devel: libsasl-devel[== 2.1.25]<br />
lib64foo-devel: libfoo-devel[== 2.1.25]<br />
lib64foo-devel: sasl-devel[== 2.1.25-7]<br />
lib64foo-devel: lib64foo-devel[== 2.1.25-7:2014.1]<br />
lib64foo-devel: pkgconfig(foo)[== 2.1.25-7]<br />
<br />
Из данного набора необходимо выбрать что-то одно. В РОСЕ отдается предпочтение зависимостям вида '''pkgconfig(...)''', так что в нашем примере в spec-файл необходимо добавить следующую строку:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Если pkgconfig(foo) не окажется в выводе urpmq, то надо добавить зависимость от foo-devel, а если и ее нет - то от libfoo-devel.<br />
<br />
== Build.PL: No such file or directory ==<br />
Такая ошибка означает, что предыдущая версия пакета собиралась с помощью скрипт Build.PL, отсутсвующего в новой версии. Часто встречающаяся ситуация - замена Build.PL на Makefile.PL. Если в архиве с исходным кодом новой версии есть скрипт Makefile.PL, то в spec-файле необходимо произвести следующие замены:<br />
<br />
* "/Build.PL installdirs=vendor" -> "Makefile.PL INSTALLDIRS=vendor"<br />
* ./Build install destdir=%{buildroot} -> %makeinstall_std<br />
* perl Build.PL install destdir=%{buildroot} -> %makeinstall_std<br />
* ./Build test -> %make test<br />
* ./Build -> %make<br />
<br />
Для примера можно посмотреть на пакет ...<br />
<br />
Если же скрипта Makefile.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== Makefile.PL: No such file or directory ==<br />
Возможна и обратная ситуация - вместо Makefile.PL разработчици перешли на Build.PL или что-то еще. Если в архиве с новым исходным кодом есть файл Build.PL, то необходимо провести в spec-файле замены, обратные приведенным в предыдущем пункте:<br />
<br />
* "Makefile.PL INSTALLDIRS=vendor" -> "/Build.PL installdirs=vendor"<br />
* %makeinstall_std -> ./Build install destdir=%{buildroot} <br />
* (если предыдущая замена не сработала) %makeinstall_std -> perl Build.PL install destdir=%{buildroot}<br />
* %make test -> ./Build test<br />
* %make -> ./Build<br />
<br />
Если же скрипта Build.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== fg: no job control ==<br />
Ошибка означает, что внутри spec-файла используется макрос RPM, не поддерживаемый в РОСЕ. Поддерживается или нет каждый конкретный макрос, можно узнать с помощью команды {{Cmd|rpm --eval}}:<br />
<br />
$ rpm --eval %macro_name<br />
<br />
Если {{Prog|rpm}} ничего не знает о таком макросе, то результатом выполнения этой команды будет "%macro_name". В противном случае {{Prog|rpm}} развернет определение макроса.<br />
<br />
== Package check "/usr/bin/rpmlint ..." failed ==<br />
Для проверки соблюдения политик сборки и оформления spec-файлов, в Росе используется утилита [[Rpmlint]]. Многие ошибки этой утилиты некритичны, однако многие имеют "вес" (badness) и если суммарный вес ошибок для пакета больше или равен 50, то сборка завершается с ошибкой. Если это ваш случай - то первым делом необходимо поискать в логе ошибки, для которых светится "Badness: 50" и исправлять их. Перечень всех ошибок можно найти здесь: [[Rpmlint Errors]]<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM&diff=18908Ошибки сборки пакетов RPM2021-03-26T14:46:24Z<p>D uragan: + rpmlint</p>
<hr />
<div>В данной статье мы собрали несколько часто встречающихся при сборке пакетов RPM ошибок подобного рода и способы их исправления. Этот перечень создан на основе опыта прохождения практики студентами НИУ ВШЭ, но мы надеемся, что он пригодится не только им.<br />
<br />
При сборке новых версий программ с помощью Updates Builder подобные ошибки исправляются автоматически (скриптом [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/analyze_log.sh analyze_log.sh]), так что можно использовать код этого скрипта как подсказку - что надо делать. Впрочем, скрипт не универсален и может не работать в каких-то специфических случаях.<br />
<br />
== error: Installed (but unpackaged) file(s) found ==<br />
Ошибка означает, что в новой версии пакета появились новые файлы, отсутствующие ранее, и rpmbuild не знает, что с ними делать (и нужны ли ли вообще).<br />
<br />
Если вы полагаете, что эти файлы нужны (а это так в 99.9% случаев), необходимо добавить их в секцию %files spec-файла. Если у вас есть несколько подпакетов, то надо сначала определить - к какому из них эти файлы относятся. Универсального рецепта здесь нет, однако есть несколько правил:<br />
<br />
* файлы в директориях {{File|/usr/include}}, {{File|/ust/lib(64)/pkgconfig}}, добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на суффикс .so (например, {{File|libfoo.so}}), также добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на цифру (например, {{File|libfoo.so.1}}), добавляются в пакеты с соответсвующими библиотеками. Согласно правилам РОСЫ, каждая библиотека должна упаковываться в отдельный подпакет, соотевтсвующий ее имени и значению SONAME (как правило, это цифра после суффикса .so - так что файлы {{File|libfoo.so.1}} и {{File|libfoo.so.1.2}} должны находиться в пакете {{Pkg|lib(64)foo1}}). Часто ошибка "Installed but unpackaged files found) в пакетах с библиотеками вызвана изменением значения SONAME - например, вместо {{File|libfoo.so.1}} в новой версии пакета появился файл {{File|libfoo.so.2}}. В этом случае вы также дополнительно увидите ошибку "Cannot find file or directory", сообщающую, что отсутсвует файл {{File|libfoo.so.1}}. Для исправления сборки в такой ситуации достаточно изменить значение макроса major в начале spec-файла:<br />
<br />
%define major 2<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами (например вместо {{File|/usr/lib}} и {{File|/usr/lib64}} необходимо использовать макрос {{Macro|%{_libdir}}}, вместо {{File|/usr/share/man}} - {{Macro|%{_mandir}}} и так далее). Более полный список можно посмотреть с [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/dir_to_macro.pm скрипте из Updates Builder].<br />
<br />
== File not found ==<br />
Ошибка означает, что в новой версии пакета отсутсвуют некоторые файлы, присутствувавшие ранее. Причин для этого может быть несколько:<br />
<br />
* в новой версии действительно нет таких файлов - в этом случае надо просто убрать их описание из секции {{Macro|%files}}<br />
* в новой версии файлы переименованы либо перемещены в другое место. В этом случае вы также увидите ошибку "Installed (but unpackaged) file(s) found", как в случае с библиотеками (см. выше). В случае с библиотеками для исправления сразу обеих ошибок необходимо изменить значение переменной major в начале spec-файла. В общем же случае необходимо исправить секцию {{Macro|%files}}, чтобы она соответсвовала новым реалиям.<br />
* отсутсвующие файлы собираются или не собираются в зависимости от параметров окружения и сборки - опций компиляции или установленных в сборочной среде пакетов (описанных в BuildRequires). Возможно, в новой версии пакета надо использовать какие-то новые опции сборки либо добавить дополнительные сборочные зависимости для получения этих файлов. Выявить такие ситуации можно на основе анализа журналов сборки и вывода команд наподобие configure или cmake, которые сообщают, какие опцилнальные возможности будут включены при сборке, а какие - нет. Например, {{Pkg|squid}} может собираться с поддержкой аутентификации SASL и без нее. В первом случае в пакете будет присутсвовать файл basic_sasl_auth, во втором его не будет. Для ключения/отключения SASL необходимо добавить/удалить значение SASL из параметра --enable-auth-basic команды {{Cmd|configure}}, а также добавить сборочную зависимость (BuildRequires) от {{Pkg|sasl-devel}}.<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами, а также что при описании файлов в секции {{Macro|%files}} могут использоваться символы '?' и '*' (означающие один произвольный символ и любое количество<br />
произвольных символов соответсвенно).<br />
<br />
== cp: cannot stat '<some_file>': No such file or directory ==<br />
Ошибка означает, что rpmbuild не смог найти файл <some_file>, помеченный как {{Macro|%doc}} в секции %files вашего пакета. Возможно, этот файл был переименован (в этом случе вы также увидите ошибку "Installed (but unpackaged) file(s) found") - в этом случае надо изменить имя файла на новое (например, {{File|README}} могут переименовать в {{File|README.md}}).<br />
Если неупакованного файла с близким именем не появилось, то значит старый файл в новой версии отсутсвует и его определение в {{Macro|%doc}} необходимо просто удалить.<br />
<br />
== Reversed (or previously applied) patch detected ==<br />
Ошибка означает, что применявшийся к старой версии пакета патч по крайней мере частично уже применен в новой версии. Обратите внимание, что команда {{Cmd|patch}} делает такой вывод на основе попытки применить только первую часть патча! Если патч сложный и затрагивает несколько файлов или несколько мест одного файла, то необходимо вручную проверить, какие из этих изменений уже есть в новой версии, а каких нет. Для этого можно попробовать применить патч к новой версии вручную, отвечая "n" на вопрос "Assume '-R'" и "y" на предложени продолжить применять остальные части патча.<br />
<br />
Если все изменения из патча действительно уже присутсвуют в новой версии, то патч можно спокойно удалить (физически из Git-репозитория, а также из spec-файла). Если же нет, то необходимо определить - нужны ли в новой версии оставшиеся изменения и если да, то переделать патч соответствующим образом. Такой анализ уже требует некоторых познаний в том, что именно делает патч.<br />
<br />
== /var/tmp/rpm-tmp.xxxxx: line yy: cd: <some_folder_name>: No such file or directory ==<br />
Ошибка означает, что rpmbuild не может определить, в какую директорию ему перейти после распаковки архива с исходным кодом. Имя директории указывается в опции {{Macro|-n}} макроса {{Macro|%setup}} в секции {{Macro|%prep}}. Если эта опция отсутсвует, то подразумевается<br />
использование "-n %{name}-%{version}". Для исправления ошибки необходимо посмотреть, как расположены файлы в новой версии архива с исходным кодом - обычно такой архив содержит директорию вида "<имя_программы>-<версия>", но время от времени разработчики могут что-то изменять (например, переименовывать директорию просто в <имя_программы>. Для исправления<br />
ошибки необходимо соответсвующим образом исправить значение опции "-n" макроса {{Macro|%setup}}.<br />
<br />
== empty-debug-info и debuginfo-without-sources ==<br />
Ошибки означают, что rpmbuild не смог должным образом сформировать подпакет с отладочной информацией. Две основные причины такого поведения:<br />
<br />
* в пакете нет исполнимых файлов или библиотек. Если в пакете при этом вообще нет архитектурно-зависимых файлов (т.е. пакеты для разных архитектур имею абсолютно одинаковое содержимое), то необходимо объявить пакет как независимый от архитектуры, добавив в заголовок spec-файла декларацию "BuildArch: noarch". Если же архитектурно-зависимые файлы все-таки есть (например, какие-то данные могут быть специфичны для каждой арзитектуры; другой типичный пример - проприетарное приложение, которое уже поставляется в виде бинарных файлов бех отладочной информации), то необходимо отключить генерацию debug-пакетов, сбросив определение макроса {{Macro|debug_package}} в начале spec-файла:<br />
<br />
%define debug_package %{nil}<br />
<br />
* скрипты сборки приложения в пакете устроены таким образом, что сразу удаляют отладочную информацию из собранных файлов (например, явно вызывают команду strip либо просто не передают опцию "-g" компилятору). В таких случаях необходимо посмотреть, как заставить скрипты сборки оставить отладочную информацию. Иногда этого можно добиться с помощью переменных среды, а иногда может потребоваться патч, изменяющий сборочные скрипты. Если никакие способы не помогают, то можно отключить генерацию debug-пакетов, как описано выше, но делать так не рекомендуется - эти пакеты очень полезны для анализа ошибок в случае падений приложения.<br />
<br />
Остановимся подробнее на втором пункте. Большинство приложений позволяют настраивать передаваемые компилятору опции при старте сборки - например, при вызове {{Prog|configure}} или {{Prog|cmake}}. Для генерации отладочной информации для подобных приложений вам не нужно прилагать особых усилий - достаточно вместо прямого вызова {{Prog|configure}} или {{Prog|cmake}} использовать соответствующие макросы {{Prog|rpm}} (в нашем примере - {{Macro|%configure2_5x}} или {{Macro|%cmake}} соответственно). Если использование макросов не помогает (либо в проекте не используются стандартные средства типа GNU Autotools или CMake), необходимо изучить схему сборки и посмотреть - нельзя ли на нее повлиять как-то еще - например, специфическими опциями либо переменными окружения. Типичными переменными, которые могут повлиять на сборку, являются {{Var|CFLAGS}}, {{Var|CXXFLAGS}} и {{Var|CPPFLAGS}}. Мы рекомендуем выставить эти переменные в макрос {{Macro|%optflags}}; при этом может оказаться необходимым перед использованием {{Macro|%%optflags}} вызвать макрос {{Macro|%%setup_compile_flag}} (например так сделано в пакете [[https://abf.io/import/slock/commit/78a9ac338470558c7a38d1709ce6d9036e5bb408#diff-F2R24 slock]].<br />
<br />
Обратите внимание на использование кавычек при выставлении переменных среды - они необходимы, поскольку макрос разворачивается в большой набор опций, разделенных пробелами.<br />
<br />
Бывают ситуации, когда повлиять на сборку извне нельзя никак - в скриптах сборки или файлах типа Makefile инструкции сборки "забиты" намертво. В таких случаях необходимо подготовить патч, добавляющий во<br />
все вызовы компилятора опцию {{Var|-g}}. Помимо опции {{Var|-g}} у компилятора, повлиять на отладочную информацию может компоновщик - например, его опции {{Var|-s}} и {{Var|-S}}, удаляющие подобные данные из результирующих бинарных файлов. Если такие опции явно передаются компоновщику в скриптах сборки либо файлах Makefile, то необходимо подготовить патч, убирающий их - например, так сделано в пакете [[https://abf.io/import/kicad/commit/c93e3d9911e3b3be485ee5dd01cbea723a087729#diff-13 kicad]].<br />
<br />
== Error: Can't locate Some/Perl/Module.pm in @INC ==<br />
Ошибка означает, что для сборки необходим Perl-модуль {{File|Some/Perl/Module.pm}}, который не был обнаружен в сборочном окружении.<br />
<br />
Для исправления ошибки необходимо добавить сборочную зависимость от такого модуля в spec-файл:<br />
<br />
BuildRequires: perl(Some::Perl::Module)<br />
<br />
Предварительно необходимо убедиться, что такой модуль вообще существует - попробовать его установить с помощью urpmi:<br />
<br />
# urpmi 'perl(Some::Perl::Module)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с модулем в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый модуль может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый модуль необходимо перенести в репозиторий Main.<br />
<br />
== Package(s) suggested but not available ==<br />
Данная ошибка может встречаться при сборке расширений языка R. Она означает, что у собираемого пакета есть необязательная зависимость от каких-то других модулей, которые в сборочной среде отсутсвуют. В идеале для каждой такой зависимости необходимо прописать BuildRequires и Requires - например, если ошибка относится к модулю "foo", то нужны зависимости от R-foo:<br />
<br />
BuildRequires: R-foo<br />
Requires: R-foo<br />
<br />
Предварительно необходимо убедиться, что такой пакет вообще есть в репозиториях - вывод команды "urpmq R-foo" должен быть непуст. Если пакета нет, то желательно его сначала собрать и добавить в репозитории. Однако при сборке может оказаться, что он зависит от того пакета, который вы собирали до этого и для которого вы собственно и хотите добавить зависимость R-foo. В этом случае первый пакет можно собрать и без R-foo, закомментировав при этом команду "%{_bindir}/R CMD check %{packname}" в секции %check. После этого можно будет уже собрать R-foo и вернуться к исходному пакету, добавив в него зависимость от R-foo и включив тесты в секции %check<br />
<br />
== ERROR: dependency(ies) not available ==<br />
Данная ошибка также может встречаться при сборке расширений языка R, но в отличие от предыдущей, здесь речь идет об обязательных зависимостях сборки. Без них пакет не может быть собран, поэтому вам необходимо добавить в spec-файл соответсвующие BuildRequiers и Requires, а при необходимости предварительно собрать нужные пакеты в репозитории РОСЫ.<br />
<br />
== hunk FAILED -- saving rejects ==<br />
Данная ошибка означает, что один из патчей (какой именно - указано в выводе rpmbuild) не может быть применен без изменений к новой версии программы. Обычно это означает, что патч необходимо переделать (предварительно определив - нужен ли он еще), что требует определенной квалификации. Однако иногда такая ошибка возникает из-за "строгости" rpmbuild при применении патчей и проблемный патч может быть исправлен в автоматическом режиме с помощью утилиты rediff_patch.<br />
<br />
Для этого достаточно склонировать себе Git-репозиторий, перейти в склонированную папку, поместить туда архив с исходным кодом новой версии и запустит rediff_patch, передав ей нужный патч к вачестве аргумента:<br />
<br />
$ abf get myrepo/myproject<br />
$ cd myproject<br />
$ wget http://project-upstream.org/new-version.tgz<br />
$ rediff_patch <some_patch_to_rediff><br />
<br />
Если все сложится удачно, то радом со старым патчем "some_patch_to_rediff" появится новый - "some_patch_to_rediff.new" Если же что-то пойдет не так, то в текущей директории останутся папка "rediff_patch" с подпапками вида "myproject.orig" и "myproject" - содержащие соответсвенно оригинальный исходный код и исходный код, получившийся после попытки применить<br />
патч. Во второй папке вы найдете файлы с расширениями *rej - это куски патчей, которые применить не удалось.<br />
<br />
== package 'foo' not found ==<br />
Аналогична следующей ошибке<br />
== "No package '.*' found" ==<br />
Такая ошибка возникает, если пакет проверяет необходимые сборочные зависимости с помощью {{Cmd|pkgconfig}} и не обнаруживает одну из них.<br />
<br />
Для исправления ошибки достаточно добавить нужную зависимость сборки в spec-файл:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Предварительно необходимо убедиться, что такая зависимость может быть разрешена - попробовать ее установить с помощью {{Cmd|urpmi}}:<br />
<br />
# urpmi 'pkgconfig(foo)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с соответсвующей библиотекой (как правило, она и называется '''libfoo''') в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый пакет может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый пакет необходимо перенести в репозиторий Main.<br />
<br />
== /usr/bin/ld: cannot find -lfoo ==<br />
Данная ошибка возникает при линковке уже собранных объектных файлов и означает, что линкер не смог найти библиотеку "foo". Для исправления ошибки достаточно добавить зависимость от библиотеки в spec-файл. Чтобы определить, как именно эту зависимость прописать, необходимо сначала поискать devel-пакет для библиотеки {{Pkg|libfoo}} (или {{Pkg|lib64foo}} в 64битной системе) с помощью urpmq:<br />
<br />
# urpmq -a libfoo<br />
lib64foo1<br />
lib64foo-devel<br />
<br />
Интересующий нас пакет - тот, что оканчивается на -devel. Посмотрим, что он предоставляет:<br />
# urpmq --provides libfoo-devel<br />
lib64foo-devel: devel(libfoo(64bit))<br />
lib64foo-devel: lib64sasl-devel[== 2.1.25]<br />
lib64foo-devel: libsasl-devel[== 2.1.25]<br />
lib64foo-devel: libfoo-devel[== 2.1.25]<br />
lib64foo-devel: sasl-devel[== 2.1.25-7]<br />
lib64foo-devel: lib64foo-devel[== 2.1.25-7:2014.1]<br />
lib64foo-devel: pkgconfig(foo)[== 2.1.25-7]<br />
<br />
Из данного набора необходимо выбрать что-то одно. В РОСЕ отдается предпочтение зависимостям вида '''pkgconfig(...)''', так что в нашем примере в spec-файл необходимо добавить следующую строку:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Если pkgconfig(foo) не окажется в выводе urpmq, то надо добавить зависимость от foo-devel, а если и ее нет - то от libfoo-devel.<br />
<br />
== Build.PL: No such file or directory ==<br />
Такая ошибка означает, что предыдущая версия пакета собиралась с помощью скрипт Build.PL, отсутсвующего в новой версии. Часто встречающаяся ситуация - замена Build.PL на Makefile.PL. Если в архиве с исходным кодом новой версии есть скрипт Makefile.PL, то в spec-файле необходимо произвести следующие замены:<br />
<br />
* "/Build.PL installdirs=vendor" -> "Makefile.PL INSTALLDIRS=vendor"<br />
* ./Build install destdir=%{buildroot} -> %makeinstall_std<br />
* perl Build.PL install destdir=%{buildroot} -> %makeinstall_std<br />
* ./Build test -> %make test<br />
* ./Build -> %make<br />
<br />
Для примера можно посмотреть на пакет ...<br />
<br />
Если же скрипта Makefile.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== Makefile.PL: No such file or directory ==<br />
Возможна и обратная ситуация - вместо Makefile.PL разработчици перешли на Build.PL или что-то еще. Если в архиве с новым исходным кодом есть файл Build.PL, то необходимо провести в spec-файле замены, обратные приведенным в предыдущем пункте:<br />
<br />
* "Makefile.PL INSTALLDIRS=vendor" -> "/Build.PL installdirs=vendor"<br />
* %makeinstall_std -> ./Build install destdir=%{buildroot} <br />
* %makeinstall_std -> perl Build.PL install destdir=%{buildroot}<br />
* %make test -> ./Build test<br />
* %make -> ./Build<br />
<br />
Если же скрипта Build.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== fg: no job control ==<br />
Ошибка означает, что внутри spec-файла используется макрос RPM, не поддерживаемый в РОСЕ. Поддерживается или нет каждый конкретный макрос, можно узнать с помощью команды {{Cmd|rpm --eval}}:<br />
<br />
$ rpm --eval %macro_name<br />
<br />
Если {{Prog|rpm}} ничего не знает о таком макросе, то результатом выполнения этой команды будет "%macro_name". В противном случае {{Prog|rpm}} развернет определение макроса.<br />
<br />
== Package check "/usr/bin/rpmlint ..." failed ==<br />
Для проверки соблюдения политик сборки и оформления spec-файлов, в Росе используется утилита [[Rpmlint]]. Многие ошибки этой утилиты некритичны, однако многие имеют "вес" (badness) и если суммарный вес ошибок для пакета больше или равен 50, то сборка завершается с ошибкой. Если это ваш случай - то первым делом необходимо поискать в логе ошибки, для которых светится "Badness: 50" и исправлять их. Перечень всех ошибок можно найти здесь: [[Rpmlint Errors]]<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95&diff=18827Обновление пакетов в РОСЕ2020-11-26T13:32:14Z<p>D uragan: орфография/пунктуация</p>
<hr />
<div>Репозитории РОСЫ содержат тысячи различных пакетов, которые необходимо обновлять по мере выхода новых версий соответствующих программ. Несмотря на [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Updates_builder_-_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%82%D1%81%D0%BB%D0%B5%D0%B6%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_ABF различные средства автоматизации], для обновления многих пакетов требуется участие человека.<br />
<br />
Оценить "свежесть" пакетной базы разных дистрибутивов можно, например, на сайте https://repology.org. Там же можно для каждого пакета определить самую последнюю версию и попробовать собрать ее на ABF.<br />
<br />
Самый простой сценарий обновления заданного пакета [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%22%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%22-Howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95 описан в блоге "Точка РОСЫ"]. Однако он рассчитан на людей, которые не знакомы даже с Git и только могут кликать различные иконки в веб-браузере. От студентов, проходящих у нас практику, мы ожидаем несколько большего и даем им более сложные пакеты, для обновления которых могут потребоваться более серьезные усилия.<br />
<br />
Если обновление по приведенной выше инструкции не проходит, то необходимо склонировать себе проект в машину с РОСОЙ:<br />
<br />
$ abf get <your_abf_login>/<project_name> -b rosa2019.1<br />
<br />
Переходим в директорию <project_name>, кладем в нее архив с исходным кодом новой версии и изменяем внутри файла <project_name>.spec значение тэга Version (если еще не сделали это в веб-интерфейсе).<br />
<br />
Теперь получившийся пакет надо собрать. Для этого сначала надо установить пакеты, которые требуются для его сборки (прописаны в BuildRequires). Для этого внутри директории <project_name> выполняем команду:<br />
<br />
$ urpmi <project_name>.spec<br />
<br />
И запускаем саму сборку с помощью {{Prog|rpmbuild}}:<br />
<br />
$ rpmbuild -bb <project_name>.spec<br />
<br />
если повезет и все соберется сразу, то в этой же директории даем команду отправить все на ABF:<br />
<br />
$ abf put -m «Updated to a new version»<br />
<br />
После чего идем в веб-интерфейс на страничку проекта в своем репозитории и делаем Pull Request в соответствующий проект группы import. Не забывайте выбирать ветку «rosa2019.1»!<br />
<br />
Также не забываем проверять работоспособность результата — для этого необходимо установить собранные пакеты в систему и убедиться, что они работают. Если вы собрали библиотеку/модуль, вам нужно проверить приложение, его использующее. Определить список всех пакетов, использующих данный, можно с помощью команды<br />
<br />
$ urpmq --whatrequires <package_name><br />
<br />
Если есть сомнения в работоспособности пакета или непонятно, как его проверить, то все равно шлите Pull Request. Только отдельно сообщите нам, что функционал новой версии проверить не удалось.<br />
<br />
Если в процессе сборки что-то пошло не так, то надо смотреть на ошибки — если идет ругань на то, что какие-то файлы не найдены (или наоборот, найдены неупакованные файлы), то надо править секцию %files в spec-файле. Могут быть жалобы на то, что не хватает каких-то программ для сборки; в этом случае надо постараться понять - каких именно, доустановить их в систему и прописать соответствующее поле BuildRequiers в spec-файле.<br />
<br />
В целом, ошибки могут быть самые разные, и далеко не со всеми из них можно быстро разобраться. Поэтому если за разумное время пакет собрать не удалось, лучше сообщить о встреченной проблеме разработчикам РОСЫ и перейти к следующему пакету. В качестве результатов работы нам важны как Pull Request'ы на обновление пакетов, которые обновились успешно, так и перечень пакетов, которые собрать не удалось, с описанием ошибок сборки. В последнем случае можно просто прислать журнал сборки для каждого пакета либо попробовать собрать пакет в своем персональном репозитории на ABF и дать нам ссылку на сборку.<br />
<br />
== Поиск новых версий ==<br />
<br />
Немаловажный аспект - определение того, какая версия программы является последней. Безусловно, можно просто обратиться к сайту разработчика, однако могут возникнуть нюансы:<br />
* в пакете может быть указан неверный URL сайта разработчика (хоть мы и [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%9E%D0%B1_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8_URL_%D0%B2_%D0%BC%D0%B5%D1%82%D0%B0%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_RPM-%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 призываем поддерживать ссылки в актуальном состоянии], они все-таки иногда протухают<br />
* самые свежие версии могут иметь проблемы со сборкой либо функционалом<br />
<br />
В подобных случаях полезно посмотреть на версию этой же программы, собранной в других дистрибутивах. Для этого можно воспользоваться нашей утилитой {{Prog|mib-report}} (необходимо в РОСЕ установить соответствующий пакет и запустить утилиту) либо сервисами наподобие [http://pkgs.org Pkgs.org] или [https://repology.org Repology].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95&diff=18825Обновление пакетов в РОСЕ2020-10-29T16:53:48Z<p>D uragan: Replace upstream tracker with repology</p>
<hr />
<div>Репозитории РОСЫ содержат тысячи различных пакетов, которые необходимо обновлять по мере выхода новых версий соответствующих программ. Несмотря на [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Updates_builder_-_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%82%D1%81%D0%BB%D0%B5%D0%B6%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_ABF различные средства автоматизации], для обновления многих пакетов требуется участие человека.<br />
<br />
Оценить "свежесть" пакетной базы разных дистрибутивов можно, например, на сайте https://repology.org. Там же можно для каждого пакета определить самую последнюю версию и попробовать собрать ее на ABF.<br />
<br />
Самый простой сценарий обновления заданного пакета [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%22%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%22-Howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95 описан в блоге "Точка РОСЫ"]. Однако он рассчитан на людей, которые не знакомы даже с Git и только могут кликать различные иконки в веб-браузере. От студентов, проходящих у нас практику, мы ожидаем несоклько большего и даем им более сложные пакеты, для обновления которых могут потребоваться более серьезные усилия.<br />
<br />
Если обновление по приведенной выше инструкции не проходит, то необходимо склонировать себе проект в машину с РОСОЙ:<br />
<br />
$ abf get <your_abf_login>/<project_name> -b rosa2019.1<br />
<br />
Переходим в директорию <project_name>, кладем в нее архив с исходным кодом новой версии и изменяем внутри файла <project_name>.spec значение тэга Version (если еще не сделали это в веб-интерфейсе).<br />
<br />
Теперь получившийся пакет надо собрать. Для этого сначала надо установить пакеты, которые требуются для его сборки (прописаны в BuildRequires). Для этого внутри директории <project_name> выполняем команду:<br />
<br />
$ urpmi <project_name>.spec<br />
<br />
И запускаем саму сборку с помощью {{Prog|rpmbuild}}:<br />
<br />
$ rpmbuild -bb <project_name>.spec<br />
<br />
если повезет и все соберется сразу, то в этой же директории даем команду отправить все на ABF:<br />
<br />
$ abf put -m «Updated to a new version»<br />
<br />
После чего идем в веб-интерфейс на страничку проекта в своем репозитории и делаем Pull Request в соответствующий проект группы import. Не забывайте выбирать ветку «rosa2019.1»!<br />
<br />
Также не забываем проверять работоспособность результата — для этого необходимо установить собранные пакеты в систему и убедиться, что они работают. Если вы собрали библиотеку/модуль, вам нужно проверить приложение, его использующее. Определить список всех пакетов, использующих данный, можно с помощью команды<br />
<br />
$ urpmq --whatrequires <package_name><br />
<br />
Если есть сомнения в работоспособности пакета или непонятно, как его проверить, то все равно шлите Pull Request. Только отдельно сообщите нам, что функционал новой версии проверить не удалось.<br />
<br />
Если в процессе сборки что-то пошло не так, то надо смотреть на ошибки — если идет ругань на то, что какие-то файлы не найдены (или наоборот, найдены неупакованные файлы), то надо править секцию %files в spec-файле. Могут быть жалобы на то, что не хватает каких-то программ для сборки; в этом случае надо постараться понять - каких именно, доустановить их в систему и прописать соответствующее поле BuildRequiers в spec-файле.<br />
<br />
В целом, ошибки могут быть самые разные, и далеко не со всеми из них можно быстро разобраться. Поэтому если за разумное время пакет собрать не удалось, лучше сообщить о встреченной проблеме разработчикам РОСЫ и перейти к следующему пакету. В качестве результатов работы нам важны как Pull Request'ы на обновление пакетов, которые обновились успешно, так и перечень пакетов, которые собрать не удалось, с описанием ошибок сборки. В последнем случае можно просто прислать журнал сборки для каждого пакета либо попробовать собрать пакет в своем персональном репозитории на ABF и дать нам ссылку на сборку.<br />
<br />
== Поиск новых версий ==<br />
<br />
Немаловажный аспект - определение того, какая версия программы является последней. Безусловно, можно просто обратиться к сайту разработчика, однако могут возникнуть нюансы:<br />
* в пакете может быть указан неверный URL сайта разработчика (хоть мы и [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%9E%D0%B1_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8_URL_%D0%B2_%D0%BC%D0%B5%D1%82%D0%B0%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_RPM-%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 призываем поддерживать ссылки в актуальном состоянии], они все-таки иногда протухают<br />
* самые свежие версии могут иметь проблемы со сборкой либо функционалом<br />
<br />
В подобных случаях полезно посмотреть на версию этой же программы, собранной в других дистрибутивах. Для этого можно воспользоваться нашей утилитой {{Prog|mib-report}} (необходимо в РОСЕ установить соответствующий пакет и запустить утилиту) либо сервисами наподобие [http://pkgs.org Pkgs.org] или [https://repology.org Repology].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%C2%AB%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%C2%BB_%E2%80%94_howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%BE%D1%81%D0%B5&diff=18817Блог:Точка Росы/«Сделай сам» — howto для желающих обновлять программы в Росе2020-10-16T09:52:36Z<p>D uragan: + note about file store</p>
<hr />
<div>Запросов от пользователей на обновление тех или иных программ в дистрибутивах ROSA Desktop Fresh мы получаем не много, а очень много. Приходится закрывать [http://forum.rosalab.ru/viewtopic.php?f=48&t=90 слишком разросшиеся темы на форуме], разбивая их на [http://forum.rosalab.ru/viewtopic.php?f=48&t=6522 более мелкие].<br />
<br />
К сожалению, выполнить абсолютно все пожелания разработчики РОСЫ не в состоянии. Однако помочь нам может каждый — вопреки распространенному мнению, для обновления какой-либо программы вовсе не обязательно быть программистом, разбираться в сборке пакетов и прочих премудростях. Во многих случаях вам хватит веб-браузера и желания сделать нечто полезное.<br />
<br />
Итак, вы узнали о выходе новой версии вашей любимой программы и хотите обновить соответствующий пакет в РОСЕ. Для примера, возьмем набирающий популярность редактор {{Prog|Atom}} — у него недавно вышла версия '''1.3.2''', а в репозиториях РОСЫ на момент написания этой статьи — все еще версия '''1.2.0'''. Давайте исправим это досадное недоразумение.<br />
<br />
Первым делом идем и регистрируемся в нашей среде сборки ABF, если вы этого до сих пор не сделали — на http://abf.io кликаем в правом верхнем углу на «Регистрацию», вводим логин/пароль и успешно заходим в систему (регистрация абсолютно свободна, происходит мгновенно и не требует никаких подтверждений).<br />
<br />
Теперь находим с помощью поиска интересующий нас пакет {{Pkg|atom}}, находящийся в группе '''import''' (обязательно используйте эту группу, именно из нее собираются пакеты в официальные репозитории!).<br />
<br />
[[File:Atom1.png|.png|640px|center]]<br />
<br />
Переходите в этот проект и жмите кнопку «Клонировать» («Fork»).<br />
<br />
[[File:Atom10.png|.png|640px|center]]<br />
<br />
В появившемся окне выберите опцию «Клонировать в <ваш_логин>/atom» («Fork to <your_login>/atom»). Этим действием вы склонируете проект в ваш персональный репозиторий, где вы сможете с ним играться в свое удовольствие. Клонирование происходит достаточно быстро, и вы сразу будете перенаправлены на страницу склонированного проекта. Если вы видите сообщение о том, что репозиторий пуст — просто обновите страницу.<br />
<br />
[[File:Atom3.png|.png|320px|center]]<br />
<br />
Следующим пунктом необходимо изменить используемую ветку Git-репозитория на '''rosa2014.1'''. Если эта фраза вам ни о чем не говорит, не пугайтесь — достаточно в выпадающем списке в правом верхнем углу выбрать значение «rosa2014.1» (мы используем эту ветку, начиная с релиза ROSA Desktop Fresh R4 и точно продолжим использовать в R7).<br />
<br />
[[File:Atom4.png|.png|640px|center]]<br />
<br />
Теперь вам необходимо в списке файлов проекта найти файл с расширением «spec» («atom.spec» в нашем случае) и кликнуть на него и затем кликнуть на «Edit» для его редактирования.<br />
<br />
[[File:Atom2.png|.png|640px|center]]<br />
<br />
Все, что вам надо изменить в этом файле — это значение тэга '''Version''', который обычно находится где-то вверху файла. Как мы видим, сейчас здесь указана версия '''1.2.0''', и мы ее заменим на '''1.3.2'''. После этого в окне «Commit message» оставьте некоторое разумное описание произведенных изменений — например, «Updated to version 1.3.2». На этом все — теперь файл можно сохранить соответствующей кнопкой внизу экрана.<br />
<br />
[[File:Atom5.png|.png|640px|center]]<br />
<br />
Далее, необходимо скачать архив с новым исходным кодом (указанный в теге Source) и загрузить его на http://file-store.rosalinux.ru/. Для аутентификации необходимо использовать те же логин и пароль, что и на ABF. Для каждого файла File Store сгенерирует хэш, который необходимо прописать в гите в файле .abf.yml, например как в https://abf.io/import/texlive-accents/blob/rosa2019.1/.abf.yml<br />
<br />
Если кто-то подумал, что этим мы и обновили программу в дистибутиве — спешим огорчить, мы всего лишь подготовились к попытке собрать новую версию, и теперь пора эту попытку произвести. Для этого кликаем на кнопку «New Build», и в появившемся окне выполняем два действия:<br />
* на всякий случай, отключите ваш персональный репозиторий — вдруг там уже есть что-то, что помешает чистоте сборки<br />
* если вы собираете пакет для репозитория Contrib (или просто не уверены, в какой репозиторий вы его собираете), то обязательно отметьте в левой колонке позицию «contrib» в секции «rosa2014.1»<br />
<br />
[[File:Atom7.png|.png|640px|center]]<br />
<br />
После этого можно нажать на кнопку «Start Build» и ждать результата. Если сборка завершится с ошибкой — что ж, «нахаляву» обновить пакет не получилось, надо либо разбираться с ошибками либо бежать за помощью к более осведомленным людям. Если же сборка завершилась успешно, то на страничке сборки вы сможет получить rpm-пакеты с новой версией программы, которые вы можете скачать, установить и попробовать в деле.<br />
<br />
Если новая программ работает как положено, то надо поделиться своими достижениями с остальными членами сообщества (ведь вы помните, что до сих пор мы все действия производили в вашем персональном репозитории?), послав запрос на обновление в основной проект, находящийся в группе import. Делается это посредством нажатием на кнопку «Pull Request» на страничке вашего проекта.<br />
<br />
[[File:Atom8.png|.png|640px|center]]<br />
<br />
В появившемся окне убедитесь, что для исходного и целевого проектов выбрана ветка rosa2014.1, при необходимости нажмите кнопку «Update commits», оставьте некоторое вразумительное сообщение в поле Description и отправьте запрос, нажав на кнопку «Send Pull Request».<br />
<br />
[[File:Atom9.png|.png|640px|center]]<br />
<br />
Разработчики получат уведомление о предлагаемых вами изменениях, рассмотрят их, внесут в основной проект в группе import и соберут новую версию пакета в официальные репозитории.<br />
<br />
== Ложка дегтя ==<br />
В описанном выше подходе к обновлению программ есть два нюанса, для осознания которых необходимо небольшое понимание того, что происходит при попытке собрать новую версию программы.<br />
<br />
Когда ABF начинает сборку пакета, он в качестве одного из предварительных шагов извлекает все файлы, необходимые для сборки — например, архивы с исходным кодом. Все такие файлы указаны в тэгах '''Source''' spec-файла проекта. В этих тэгах можно указывать ссылки (URL) на внешние ресурсы, и если ABF не сможет найти нужные файлы в Git-репозитории либо в своем хранилище бинарных файлов, то он попробует скачать файл по ссылке.<br />
<br />
Как следствие, изложенный выше подход сработает только для проектов, у которых правильно заполнены тэги '''Source'''. Если вы посмотрите в файл atom.spec из нашего примера, то увидите там такую строку:<br />
<br />
Source0: https://github.com/atom/atom/archive/v%{version}.zip<br />
<br />
Здесь приведена ссылка на архив с исходным кодом на github, причем вместо фиксированной версии указан макрос {{Macro|version}}, который автоматически разворачивается в значение тэга '''Version'''. Именно поэтому для сборки новой версии вам достаточно обновить значение этого тэга — дальше система сборки сама отправится скачивать архив с новым исходным кодом. И именно поэтому мы стараемся [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%9E%D0%B1_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8_URL_%D0%B2_%D0%BC%D0%B5%D1%82%D0%B0%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_RPM-%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 поддерживать значения тэгов Source в актуальном состоянии].<br />
<br />
Второй нюанс заключается в том, что скачивать исходный код из интернета при каждой сборке — идея не из лучших, и вообще-то мы ее не приветствуем. Мало ли что может случиться — ссылка перестанет работать или злоумышленник взломает сайт автора программы и подложит туда свои зловредные файлы. Поэтому официально практика скачивания исходного кода из интернета в РОСЕ запрещена, и по крайней мере в основном репозитории ('''main''') мы за этим строго следим. Поэтому при принятии вашего запроса на изменение разработчик РОСЫ скорее всего сам скачает архив с исходным кодом и поместит его в файловое хранилище ABF. Если вы хотите избавить нас и от этой задачи, то, пожалуйста, скачайте нужные файлы самостоятельно и залейте их на http:///file-store.rosalinux.ru. После загрузки вы увидите страничку с именем загруженных файлов и их хэш-суммами:<br />
<br />
[[File:Atom11.png|.png|640px|center]]<br />
<br />
Имя каждого файла и его хэш-сумму, разделенные двоеточием, надо добавить в файл {{Pkg|.abf.yml}} внутри проекта на ABF:<br />
<br />
v1.3.2.zip: a23ab212c70ff02a03d1b7afb036593e36dd891a<br />
<br />
Какие именно файлы нужно загрузить для каждого конкретного проекта — определяется его тэгами '''Source''' — все бинарные файлы, указанные в этих тэгах, нужно загружать на File Store.<br />
<br />
[[Category:ToROSAPoint]]<br />
{{wl-publish: 2015-12-26 22:17:00 +0400 | Denis.silakov }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_TeXLive&diff=18801Сборка пакетов-расширений для TeXLive2020-10-09T02:19:28Z<p>D uragan: + note about .abf.yml</p>
<hr />
<div>TeX - система компьютерной вёрстки, широко используемая по всему миру.<br />
<br />
В Linux в настоящее время активно используется реализация от проекта {{Prog|texlive}}, которая включает в себя не просто основные инстурменты верстки,<br />
но и множество дополнений и расширений (дополнительных шрифтов, пакетов с поддержкой разлицных языков, шаблонов диссертаций и презентаций и так далее).<br />
<br />
В РОСЕ каждое такое дополнение оформляется как отдельный RPM-пакет. <br />
<br />
Рассмотрим процесс упаковки расширения с названием '''TEXPKG''' в пакет {{Pkg|texlive-<TEXPKG>}}<br />
<br />
Сначала проверяем, что страничка пакета доступна по адресу http://www.ctan.org/tex-archive/macros/latex/contrib/<TEXPKG>. Эта ссылка должна быть прописана в URL spec-файла. Со странички проекта берем Summary (не более 80 симполов), лицензию (тэг License) и описание (для секции %description). Если есть версия - берем ее со странички, если нет - используем в качестве версии дату, когда вы скачали исходники, в формате ГГГГММДД (например, 20191231).<br />
<br />
Далее ищем в директории http://mirrors.ctan.org/systems/texlive/tlnet/archive/ файл {{File|<TEXPKG>.tar.xz}}.<br />
Там же могут находиться файлы {{File|<TEXPKG>.doc.tar.xz}} и {{File|<TEXPKG>.source.tar.xz}} - если есть, их тоже берем.<br />
<br />
Их надо прописать в качестве Sources:<br />
<br />
Source0: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.tar.xz<br />
Source1: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.doc.tar.xz<br />
Source2: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.source.tar.xz<br />
<br />
Все эти файлы необходимо скачать и загрузить на http://file-store.rosalinux.ru/. Для аутентификации необходимо использовать те же логин и пароль, что и на ABF. Для каждого файла File Store сгенерирует хэш, который необходимо прописать в гите в файле .abf.yml, например как в https://abf.io/import/texlive-accents/blob/rosa2019.1/.abf.yml<br />
<br />
Внутри ахивов обязательно есть папки {{File|tlpkg/tlpobj}} - в них лежат файлы с информацией о пакете. Если вдруг на страничке пакета не оказалось<br />
каких-то данных (версии, описания и тому подобного), то поищите их здесь. Здесь же могут быть прописаны зависимости пакета от других пакетов texlive<br />
(со словом depend) - из надо обязательно указать как Requires в spec-файле.<br />
<br />
Например, если в tlpkg/tlpobj/<TEXPKG> есть запись<br />
<br />
depend babel-belarusian<br />
<br />
то в spec-файле должна присутсвовать соответсвующая зависимоcть<br />
<br />
Requires: texlive-babel-belarusian<br />
<br />
Значение тэга Group для пакетов texlive - всегда '''Publishing'''.<br />
<br />
Как правило, пакеты являются арзитектурно-независимыми, поэтому надо дабавить в spec-файл запись<br />
<br />
BuildArch: noarch<br />
<br />
(если пакет является архитектурно-зависимым, то rpmbuild его не соберет с соответсующей ошибкой - тогда BuildArch надо убрать).<br />
<br />
Всем texlive-пакетам необходимо прописать сборочную зависимость (BuildRequires) от {{Pkg|texlive-tlpkg}}. Этот же пакет<br />
надо указать как предустановочную зависимость ("Requires(pre)"). В качестве пост-установочной зависимости post-скрипта ("Requires(post)") надо указать<br />
{{Pkg|texlive-kpathsea}}.<br />
<br />
Для большинства пакетов, секция '''%prep''' сводится к распаковке архивов, например:<br />
<br />
%setup -c -a0 -a1 -a2<br />
<br />
секция '''%build''' отсутствует, а '''%install''' сводится к копированию директорий, содержащихся внутри архивов (за исключением директории {{File|tlpkg}}), в {{File| %{buildroot}%{_texmfdistdir} }} (которую надо предварительно создать):<br />
<br />
s %install<br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar fonts tex doc source %{buildroot}%{_texmfdistdir}<br />
<br />
(проследите, чтобы скопированы были все директории из архивов, кроме tlpkg) <br />
<br />
Эти же директории достаточно указать в секции %files, пометив sources и doc как документацию:<br />
<br />
%files<br />
%{_texmfdistdir}/tex/latex/<TEXPKG><br />
%{_texmfdistdir}/fonts/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/source/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/doc/latex/<TEXPKG><br />
<br />
Подготовив spec-файл и скачав архивы с исходным кодом, необходимо убедиться в возможности собрать пакет с помощью {{Cmd|rpmbuild -bb}}. Если проблем нет - то собираем src.rpm ({{Cmd|rpmbuild -bs}}) и создаем из него проект в своем репозитории на ABF.<br />
<br />
Примеры texlive пакетов:<br />
* https://abf.io/import/texlive-mpgraphics<br />
* https://abf.io/import/texlive-mceinleger<br />
* https://abf.io/import/texlive-makecmds<br />
<br />
(смотрите ветку rosa2019.1)<br />
<br />
== Пакеты со скриптами ==<br />
Для некоторых модулей по ссылке http://ctan.altspu.ru/systems/texlive/tlnet/archive/<br />
доступен не только архив с исходным кодом, но и дополнительные пакеты под разные ОС и архитектуры.<br />
Для таких модулей помимо описанных выше дейтсвий надо произвести дополнительные манипуляции,<br />
добавив файлы, присутсвующие в ОС-специфичных пакетах. Как правило, эти манипуляции<br />
сводятся к созданию символьных ссылок на скрипты в местах, где в ОС располагаются файлы для запуска<br />
(в случае Linux - в директории /bin или /usr/bin).<br />
<br />
Например, для a2ping мы видим следующие файлы:<br />
<br />
...<br />
a2ping.tar.xz<br />
a2ping.win32.tar.xz<br />
a2ping.x86_64-cygwin.tar.xz<br />
a2ping.x86_64-darwin.tar.xz<br />
a2ping.x86_64-darwinlegacy.tar.xz<br />
a2ping.x86_64-linux.tar.xz.<br />
...<br />
<br />
Скачаем a2ping.x86_64-linux.tar.xz и заглянем внутрь - там помимо служебной директории tlpgk мы увидим директорию bin, внутри нее директорию x86_64-linux, а там - символьную ссылку a2ping:<br />
<br />
<pre><br />
$ tar xf a2ping.x86_64-linux.tar.xz.<br />
$ ls -l bin/x86_64-linux/<br />
total 0<br />
lrwxrwxrwx 1 user users 41 Oct 4 2018 a2ping -> ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
</pre><br />
<br />
Как видим, ссылается она на скрипт ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
<br />
Сам скрипт находится в архиве с исходным кодом (a2ping.tar.xz), в директории texmf-dist. При сборке пакета, мы должны положить содержимое texmf-dist в директорию. %{buildroot}%{_texmfdistdir}, а в директории %{buildroot}%{_bindir} создать соответсвующую символьную ссылку:<br />
<br />
<pre><br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar texmf-dist/* %{buildroot}%{_texmfdistdir}<br />
mkdir -p %{buildroot}%{_bindir}<br />
pushd %{buildroot}%{_bindir}<br />
ln -sf %{_texmfdistdir}/scripts/a2ping/a2ping.pl a2ping<br />
popd<br />
</pre><br />
<br />
Пример:<br />
* https://abf.io/import/texlive-a2ping<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=Python_policy&diff=18562Python policy2020-03-16T07:53:19Z<p>D uragan: Adopt for rosa2019.1</p>
<hr />
<div>[[Category:Packaging Policies]]<br />
<br />
== Tools ==<br />
<br />
=== bdist_rpm and bdist_rpm5 ===<br />
The fastest way to pack a Python module for ROSA is to use a standard [http://docs.python.org/distutils/builtdist.html#creating-rpm-packages bdist_rpm] python class:<br />
<br />
<pre><br />
python setup.py bdist_rpm<br />
</pre><br />
<br />
Prior to rosa2019.1 and switch to rpm4, one should use bdist-rpm5 instead:<br />
<pre><br />
python setup.py bdist_rpm5<br />
</pre><br />
<br />
If everything goes fine, you will find ready-to-use SRPM inside the dist folder which contains spec file conforming to ROSA Python policy (and the rest of this document is just for your interest then).<br />
<br />
If the tool fails to automatically detect values for some tags (license, description, etc.), it will set these fields to 'UNKNOWN' value.<br />
<br />
Please look for 'UNKNOWN' words in the generated spec and fix them manually.<br />
<br />
Note that bdist_rpm5 worked only for Python2, while bdist_rpm works fine for both Python2 and Python3. However, starting from rosa2019.1 platform for most modules there is no need to build Python2 versions anymore, only Python3 ones should be left.<br />
<br />
=== Py2pack ===<br />
[http://pypi.python.org/pypi/py2pack Py2pack] script can be used to generate RPM spec file from Python modules using Python Package Index (PyPI). Currently py2pack can only generate spec files for OpenSUSE and Fedora, but one may use generated spec as a basis for the ROSA one.<br />
<br />
== Rules ==<br />
<br />
=== Naming ===<br />
The name of a package with Python2 module 'foo' that provides an extension for Python2 library must be of the form {{pkg|python2-foo}}, with foo being lower case. For packages with Python3 modules, 'python3' prefix should be used - {{pkg|python3-foo}}. If the upstream name 'foo' already contains "python", that should be dropped from the name.<br />
<br />
It is recommended to name the project with python module as {{pkg|python-foo}} and define {{pkg|python3-foo}} and {{pkg|python2-foo}} subpackages. Python2 subpackages are not required and should only be built if the module is used by software which is not ported to Python2.<br />
<br />
Rationale: using a prefix is serving as a name space, and clearly shows how to find python modules.<br />
<br />
Having everything in lower case is easier to read, and offers a consistent sorting.<br />
<br />
'''Note:''' User-level applications written in Python do not need to follow these naming rules.<br />
<br />
=== Tags ===<br />
* For Python modules, group should be set to 'Development/Python'<br />
* BuildArch must be noarch for pure Python packages<br />
<br />
=== Build Requires ===<br />
* 'python2' or 'python3' requirement is added automatically once the rpmbuild detects you are using python to build your package. If spec file is created using bdist_rpm, setuptools dependency is also added.<br />
* All other dependencies should be added manually.<br />
* Arch dependent packages (compiled extensions) should require (at least) python2-devel (python3-devel for Python3 packages).<br />
<br />
=== Requires ===<br />
* Mandatory requirement python(abi) = VERSION is added automatically<br />
<br />
== Rpm macro ==<br />
<br />
The following macros are available for Python packagers: <br />
{|class='wikitable'<br />
! Macro (Python2) !! Analogue for Python3 !! Description<br />
|-<br />
| {{macro|%py2_ver}} || {{macro|%py3_ver}} || Get Python version (as reported by invoking 'python -V')<br />
|-<br />
| {{macro|%py2_incdir}} || {{macro|%py3_incdir}} || Path to Python include files (necessary to compile C extensions)<br />
|-<br />
| {{macro|%python2_sitelib}} || {{macro|%python3_sitelib}} || Directory for the installation of third-party extensions which are platform-independent (written in pure Python)<br />
|-<br />
| {{macro|%python2_sitearch}} || {{macro|%python3_sitearch}} || Directory for the installation of third-party extensions which are platform-dependent (C extensions)<br />
|-<br />
| {{macro|%py2_platlibdir}} || N/A yet || Platform-dependent directory for the installation for the standard library<br />
|-<br />
| {{macro|%py2_purelibdir}} || N/A yet || Platform-independent directory for the installation for the standard library<br />
|-<br />
| {{macro|%py2_prefix}} || {{macro|%py3_prefix}} || Site-specific directory prefix where the platform independent Python files are installed (sys.prefix)<br />
|-<br />
| {{macro|%py2_compile(O)}} || N/A yet || Create .pyc files, dropping existing ones, if any. If -O option is specified, the same is performed for .pyo files.<br />
|}<br />
<br />
'''%py_(pure|plat)(site|lib)dir''' are intended to be used in order to place pure Python modules (that are architecture independent) in the same place on all hardware platforms, while putting compiled C extensions to arch-specific folders. For example, pure Python modules will go to /usr/lib/python on both x86 and x86-64, while compiled extensions will go to /usr/lib/python/ on x86 and /usr/lib64/python/ on x86-64. This allows packaging software consisting of pure Python modules only as noarch packages suitable for installing on all platforms.<br />
<br />
For those familiar with [http://docs.python.org/distutils/apiref.html#module-distutils.sysconfig Python distutils] - '''%py_(pure|plat)(site|lib)dir''' correspond to results of ''distutils.sysconfig.get_python_lib()'' with appropriate parameter (plat_specific, standard _lib).<br />
<br />
See http://archives.mandrivalinux.com/cooker/2006-01/msg01404.php for more discussions.<br />
<br />
=== Deprecated Macros ===<br />
Starting with rosa2019.1 platform, all macros with unversioned %py_ prefix are not allowed to be used - one should explicitly specify either %py2_ or %py3_.<br />
<br />
The following macros are also available but marked as deprecated and not recommended:<br />
{|class='wikitable'<br />
! Macro !! Description<br />
|-<br />
| {{macro|%py2_libdir}} || The same as %py2_purelibdir<br />
|-<br />
| {{macro|%py2_sitedir}} || The same as %py2_puresitedir<br />
|-<br />
| {{macro|%py2_platsitedir}} || The same as {{macro|%python2_sitearch}<br />
|-<br />
| {{macro|%py2_puresitedir}} || The same as {{macro|%python2_sitelib}}<br />
|-<br />
| {{macro|%python2_version}} || The same as %py2_ver<br />
|-<br />
| {{macro|%py_requires(d)}} || Insert build dependency on python; if '-d' option is specified then add build dependency on python-devel, as well.<br/> For now, it is recommended to explicitly specify BuildRequires: python and BuildRequires: python-devel.<br />
|}<br />
<br />
== pyc/pyo policy ==<br />
Files should be compiled before rpm creation and included into it as they will otherwise be created if package is run as root and will not be removed on package removal.<br />
<br />
Starting from rosa2019.1 platform, bytecompiled files for Python3 are created automatically, but not forget to include them to the package. For python3, all such files are pushed into {{File|__pycache__}} folder so you may need to add the following line to your spec:<br />
<br />
<pre><br />
%{python3_sitelib}/__pycache_/*<br />
</pre><br />
<br />
=== egg-info ===<br />
If egg-info files or directories are generated by the module's build scripts they must be included in the package because they might be needed by other applications and modules at runtime. So the %files section should contain something like this:<br />
<pre><br />
%{py_platsitedir}/%{name}-*.egg-info<br />
</pre><br />
<br />
=== Automated setup ===<br />
If you use automated setup and invoke something like 'python setup.py install', you may ask python to record names of installed files and then use the recorded list in the %files section:<br />
<br />
<pre><br />
%install<br />
...<br />
python3 setup.py install --root=%{buildroot} --record=FILELIST<br />
...<br />
<br />
%files -f FILELIST<br />
...<br />
</pre><br />
<br />
Note, however, that automatically created file lists are not completely reliable - they don't contain byte-compiled files and t the same time may contain duplicates - more particular, it can contain a directory followed by the whole directory contents, such as:<br />
<pre><br />
/usr/lib/python2.7/site-packages/Jinja2-2.6-py2.7.egg-info<br />
/usr/lib/python2.7/site-packages/Jinja2-2.6-py2.7.egg-info/top_level.txt<br />
/usr/lib/python2.7/site-packages/Jinja2-2.6-py2.7.egg-info/PKG-INFO<br />
...<br />
</pre><br />
<br />
However, for modern rpm it is enough to mention '''/usr/lib/python2.7/site-packages/Jinja2-2.6-py2.7.egg-info''' only. You can filter out extra records using {{cmd|grep}}:<br />
<pre><br />
cat FILELIST | grep -v "egg-info/" > NEW_FILELIST<br />
mv NEW_FILELIST FILELIST<br />
</pre><br />
<br />
== Example spec file ==<br />
Here we only create subpackage for python3. If you also need python2 - please create the same subpackage with python2- prefix.<br />
<br />
<pre><br />
%define module mymodule<br />
<br />
Summary: Example module<br />
Name: python-%{module}<br />
Version: 1.0<br />
Release: 1<br />
Source: %{module}-%{version}.tar.gz<br />
URL: http://mypage.org/mymodule<br />
License: Apache License<br />
Group: Development/Python<br />
BuildArch: noarch<br />
<br />
%description<br />
Example Python module<br />
<br />
#---------------------------------------------------------------------------<br />
%package -n python3-%{module}<br />
Summary: Example module<br />
BuildRequires: python3-devel<br />
BuildRequires: python3-setuptools<br />
<br />
%description -n python3-%{module}<br />
Example Python module<br />
<br />
%files -n python3-%{module}<br />
%{python3_sitelib}/*<br />
<br />
#---------------------------------------------------------------------------<br />
<br />
%prep<br />
%setup -qn %{module}-%{version}<br />
<br />
%build<br />
%py3_build<br />
<br />
%install<br />
%py3_install<br />
</pre><br />
<br />
== Rebuild policy ==<br />
It is known that Python is not completely backward compatible (so if you update e.g. from 2.6 to 2.7, some modules may become broken; the more so for Python3 updates). Due to this 'python(abi)' dependency is set to particular Python version. <br />
<br />
As a result, when Python itself is updated all dependent packages should be rebuilt to handle pick up the new version.<br />
<br />
== Policy in other distributions ==<br />
* [http://fedoraproject.org/wiki/Packaging/Python Fedora python packaging policy]<br />
* [http://www.debian.org/doc/packaging-manuals/python-policy/ Debian python packaging policy]<br />
* [http://en.opensuse.org/openSUSE:Packaging_Python OpenSUSE python packaging policy]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_TeXLive&diff=18533Сборка пакетов-расширений для TeXLive2020-02-14T16:41:32Z<p>D uragan: + packages with scripts</p>
<hr />
<div>TeX - система компьютерной вёрстки, широко используемая по всему миру.<br />
<br />
В Linux в настоящее время активно используется реализация от проекта {{Prog|texlive}}, которая включает в себя не просто основные инстурменты верстки,<br />
но и множество дополнений и расширений (дополнительных шрифтов, пакетов с поддержкой разлицных языков, шаблонов диссертаций и презентаций и так далее).<br />
<br />
В РОСЕ каждое такое дополнение оформляется как отдельный RPM-пакет. <br />
<br />
Рассмотрим процесс упаковки расширения с названием '''TEXPKG''' в пакет {{Pkg|texlive-<TEXPKG>}}<br />
<br />
Сначала проверяем, что страничка пакета доступна по адресу http://www.ctan.org/tex-archive/macros/latex/contrib/<TEXPKG>. Эта ссылка должна быть прописана в URL spec-файла. Со странички проекта берем Summary (не более 80 симполов), лицензию (тэг License) и описание (для секции %description). Если есть версия - берем ее со странички, если нет - используем в качестве версии дату, когда вы скачали исходники, в формате ГГГГММДД (например, 20191231).<br />
<br />
Далее ищем в директории http://mirrors.ctan.org/systems/texlive/tlnet/archive/ файл {{File|<TEXPKG>.tar.xz}}.<br />
Там же могут находиться файлы {{File|<TEXPKG>.doc.tar.xz}} и {{File|<TEXPKG>.source.tar.xz}} - если есть, их тоже берем.<br />
<br />
Их надо прописать в качестве Sources:<br />
<br />
Source0: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.tar.xz<br />
Source1: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.doc.tar.xz<br />
Source2: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.source.tar.xz<br />
<br />
Внутри ахивов обязательно есть папки {{File|tlpkg/tlpobj}} - в них лежат файлы с информацией о пакете. Если вдруг на страничке пакета не оказалось<br />
каких-то данных (версии, описания и тому подобного), то поищите их здесь. Здесь же могут быть прописаны зависимости пакета от других пакетов texlive<br />
(со словом depend) - из надо обязательно указать как Requires в spec-файле.<br />
<br />
Например, если в tlpkg/tlpobj/<TEXPKG> есть запись<br />
<br />
depend babel-belarusian<br />
<br />
то в spec-файле должна присутсвовать соответсвующая зависимоcть<br />
<br />
Requires: texlive-babel-belarusian<br />
<br />
Значение тэга Group для пакетов texlive - всегда '''Publishing'''.<br />
<br />
Как правило, пакеты являются арзитектурно-независимыми, поэтому надо дабавить в spec-файл запись<br />
<br />
BuildArch: noarch<br />
<br />
(если пакет является архитектурно-зависимым, то rpmbuild его не соберет с соответсующей ошибкой - тогда BuildArch надо убрать).<br />
<br />
Всем texlive-пакетам необходимо прописать сборочную зависимость (BuildRequires) от {{Pkg|texlive-tlpkg}}. Этот же пакет<br />
надо указать как предустановочную зависимость ("Requires(pre)"). В качестве пост-установочной зависимости post-скрипта ("Requires(post)") надо указать<br />
{{Pkg|texlive-kpathsea}}.<br />
<br />
Для большинства пакетов, секция '''%prep''' сводится к распаковке архивов, например:<br />
<br />
%setup -c -a0 -a1 -a2<br />
<br />
секция '''%build''' отсутствует, а '''%install''' сводится к копированию директорий, содержащихся внутри архивов (за исключением директории {{File|tlpkg}}), в {{File| %{buildroot}%{_texmfdistdir} }} (которую надо предварительно создать):<br />
<br />
s %install<br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar fonts tex doc source %{buildroot}%{_texmfdistdir}<br />
<br />
(проследите, чтобы скопированы были все директории из архивов, кроме tlpkg) <br />
<br />
Эти же директории достаточно указать в секции %files, пометив sources и doc как документацию:<br />
<br />
%files<br />
%{_texmfdistdir}/tex/latex/<TEXPKG><br />
%{_texmfdistdir}/fonts/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/source/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/doc/latex/<TEXPKG><br />
<br />
Подготовив spec-файл и скачав архивы с исходным кодом, необходимо убедиться в возможности собрать пакет с помощью {{Cmd|rpmbuild -bb}}. Если проблем нет - то собираем src.rpm ({{Cmd|rpmbuild -bs}}) и создаем из него проект в своем репозитории на ABF.<br />
<br />
Примеры texlive пакетов:<br />
* https://abf.io/import/texlive-mpgraphics<br />
* https://abf.io/import/texlive-mceinleger<br />
* https://abf.io/import/texlive-makecmds<br />
<br />
(смотрите ветку rosa2019.1)<br />
<br />
== Пакеты со скриптами ==<br />
Для некоторых модулей по ссылке http://ctan.altspu.ru/systems/texlive/tlnet/archive/<br />
доступен не только архив с исходным кодом, но и дополнительные пакеты под разные ОС и архитектуры.<br />
Для таких модулей помимо описанных выше дейтсвий надо произвести дополнительные манипуляции,<br />
добавив файлы, присутсвующие в ОС-специфичных пакетах. Как правило, эти манипуляции<br />
сводятся к созданию символьных ссылок на скрипты в местах, где в ОС располагаются файлы для запуска<br />
(в случае Linux - в директории /bin или /usr/bin).<br />
<br />
Например, для a2ping мы видим следующие файлы:<br />
<br />
...<br />
a2ping.tar.xz<br />
a2ping.win32.tar.xz<br />
a2ping.x86_64-cygwin.tar.xz<br />
a2ping.x86_64-darwin.tar.xz<br />
a2ping.x86_64-darwinlegacy.tar.xz<br />
a2ping.x86_64-linux.tar.xz.<br />
...<br />
<br />
Скачаем a2ping.x86_64-linux.tar.xz и заглянем внутрь - там помимо служебной директории tlpgk мы увидим директорию bin, внутри нее директорию x86_64-linux, а там - символьную ссылку a2ping:<br />
<br />
<pre><br />
$ tar xf a2ping.x86_64-linux.tar.xz.<br />
$ ls -l bin/x86_64-linux/<br />
total 0<br />
lrwxrwxrwx 1 user users 41 Oct 4 2018 a2ping -> ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
</pre><br />
<br />
Как видим, ссылается она на скрипт ../../texmf-dist/scripts/a2ping/a2ping.pl<br />
<br />
Сам скрипт находится в архиве с исходным кодом (a2ping.tar.xz), в директории texmf-dist. При сборке пакета, мы должны положить содержимое texmf-dist в директорию. %{buildroot}%{_texmfdistdir}, а в директории %{buildroot}%{_bindir} создать соответсвующую символьную ссылку:<br />
<br />
<pre><br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar texmf-dist/* %{buildroot}%{_texmfdistdir}<br />
mkdir -p %{buildroot}%{_bindir}<br />
pushd %{buildroot}%{_bindir}<br />
ln -sf %{_texmfdistdir}/scripts/a2ping/a2ping.pl a2ping<br />
popd<br />
</pre><br />
<br />
Пример:<br />
* https://abf.io/import/texlive-a2ping<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9F%D0%B5%D1%80%D0%B5%D1%85%D0%BE%D0%B4_ROSA_%D1%81_RPM_5_%D0%BD%D0%B0_RPM_4&diff=18451Переход ROSA с RPM 5 на RPM 42020-01-10T15:12:51Z<p>D uragan: Minor styling changes</p>
<hr />
<div>{{Введение|Начиная с rosa2019.1, дистрибутив ROSA Fresh переходит с пакетных менеджеров RPM 5 и urpmi на RPM 4 и DNF. Эта статья описывает основные отличия для пользователей и сборщиков пакетов.}}<br />
<br />
== Откуда куда переход ==<br />
<br />
Более восьми лет в дистрибутивах ROSA Desktop использовался пакетный менеджер [[RPM5]] - форк RPM4, созданный Джеффом Джонсоном. Долгое время RPM5 развивался гораздо активнее своего родителя, что и обсуловило его выбор для РОСЫ. Однако постепенно активность по разработке RPM5 угасла, а RPM4 наоборот - возродился и постепенно не только вобрал большинство интересных свойств RPM5, но и получил множество новых. В настоящее время сайт http://rpm5.org уже недоступен, а ROSA Desktop переходит обратно на RPM 4.<br />
<br />
Было:<br />
* низкоуровневая система управления пакетами RPM 5.4.10 (с более чем сотней патчей, специфичных для РОСЫ)<br />
* высокоуровневый пакетный менеджер urpmi<br />
* mock-urpm<br />
<br />
Стало:<br />
* низкоуровневая система управления пакетами RPM 4.15.1+<br />
* высокоуровневый пакетный менеджер {{Prog|DNF}}<br />
* исчез RPM-тег DistEpoch (не путать с Epoch), но появился DistTag<br />
* вместо mock-urpm используется оригинальный mock<br />
* наиболее часто используемые в командах {{Cmd|urpmi}} и {{Cmd|urpme}} функции преобразовываются в команды {{Cmd|dnf}} ([https://github.com/rpm-software-management/dnf-URPM dnf-URPM])<br />
* будет работающий {{Prog|PackageKit}}, на основе которого планируется графический "Магазин приложений"<br />
<br />
Затронутые платформы: rosa2019.1 (в будущем релизы Rosa Desktop Fresh >= R12, Rosa Enterprise Desktop >= X5) и новее, в старых (rosa2012.1, rosa2012lts, rosa2014.1, rosa2016.1, rosa2019.0) пакетная система не меняется.<br />
<br />
В данный момент для rosa2019.1 создаются одновременно метаданные и для urpmi ([http://abf-downloads.rosalinux.ru/rosa2019.1/repository/x86_64/main/release/ директория] media_info), и для dnf (директория repodata). Метаданные urpmi обновляются при публикации пакетов, как положено, а метаданные dnf временно создаются через cron раз в 5 минут и пока только для main/release, main/updates, contrib/rlease contrib/updates, для non-free и restricted пока нет, но скоро появятся. Если вы парсите метаданные, то не стоит ориентироваться на метаданные от urpmi (media_info), потому что, как написано ниже, пока не ясно, останется он или нет. В rpm4 нет %__NVRA, нет distepoch, но есть disttag. Лучше всего парсить новые метаданные, как метаданные OpenMandriva Cooker/Fedora. В данный момент urpmi в rosa2019.1 вообще не тестируется, метаданные для него могут быть сломаны.<br />
<br />
== Причины для перехода ==<br />
<br />
* ни RPM 5, ни urpmi более не разрабатываются, ROSA и PLD остались единственными их использующими дистрибутивами, причем PLD уже более года прорабатывает переход на rpm4; в мире Linux нецелесообразно пытаться малыми силами тащить такую важную инфраструктурную вещь, как пакетная система<br />
* в RPM 5 в свое время были важные функции, которых не было в RPM 4, но теперь ситуация изменилась в обратную сторону<br />
* апстрим RPM 4 в последнее время очень живой, RPM 4 активно развивается<br />
* неудовлетворительное качество кода RPM 5 в РОСЕ, в котором так и осталось более сотни "костылей" со времен спешного перехода Mandriva на RPM 5 и много недоделанного функционала. Поддержка усложняется тем, что внутри кода RPM 5 содержатся копии многих сторонних проектов, и отвечающий за что-то одно код размазан по огромному количеству файлов (например, см. коммит [https://abf.io/soft/rpm5/commit/5bf4d7c6391be2408e59680999d8a83fb279d64a 5bf4d7]: банально идентификаторы алгоритмов хеширования пришлось добавить в большое количество файлов)<br />
* urpmi, конечно, немного жалко, но желающих в одиночку тянуть urpmi и perl-URPM не нашлось, а какого-либо критически важного функционала, отсутствующего в DNF, в urpmi нет<br />
* нет качественных биндингов urpmi<->PackageKit, а их разработка и поддержка займет большое количество времени, которое можно потратить на другие вещи, и не очень целесообразна, поскольку есть много нюансов; если делать их только самим, то качество получится низким<br />
<br />
== Общий план перехода ==<br />
<br />
(возможны изменения, то, что еще не сделано, является приблизительным видением дальнейшей работы)<br />
<br />
* (СДЕЛАНО) [https://pagure.io/omv-urpmi-to-dnf-migration собрать] стек rpm4 с временными хаками, чтобы можно было использовать ранее собранные rpm5 пакеты *.rpm, например, игнорируя отсутствующую в стеке rpm4 %DISTEPOCH<br />
* (СДЕЛАНО) обеспечить совместимость нового rpm4 с максимально возможным количеством старых макросов<br />
* (СДЕЛАНО) автоматизированно внести массовые изменения в спеки (*.spec) так, чтобы они стали совместимы с RPM 4: меняются как места, которые строго необходимо заменить, так и те, где старый и продолжающий работать макрос меняется на его новый вариант<br />
* (СДЕЛАНО) обеспечить совместимость старого rpm5 с измененными спеками, чтобы можно было из одного спека собирать пакеты и для rpm5 в платформах rosa2016.1 и rosa2019.0 и для rpm4 в платформе rosa2019.1<br />
* (СДЕЛАНО) научить abf-console-client работать с RPM 4 (теперь апстрим общий с OpenMandriva — https://github.com/OpenMandrivaSoftware/abf-console-client, а старый клиент из ROSA на python2 — https://abf.io/soft/abf-console-client — остается только для RPM5)<br />
* (В ПРОЦЕССЕ) провести массовую пересборку пакетов main и contrib, выявив и исправив типовые проблемы (например, уже [https://abf.io/import/rpm/commit/f0381cf1bc4d3d4be0a46172340466fb2f98d6ef запатчен] find-lang.sh из rpm4)<br />
* (В ПРОЦЕССЕ) ранее применявшимся в OpenMandriva скриптом автоматического обновления пакетов, где это возможно, обновить пакеты<br />
* привести [[Файловые триггеры RPM|файловые триггеры RPM 5]] и %trigger* к [https://rpm.org/user_doc/file_triggers.html файловым триггерам RPM 4] (возможно, замапить новые %trigger* в старые для переиспользования спеков rpm4 в rpm5...)<br />
* (СДЕЛАНО) обновить и починить gdb (gdb-add-index теперь используется в rpm, а gdb сейчас сломан из-за несовместимости с Python 3.8)<br />
* портировать [https://abf.io/soft/rpm5/commit/3e3987c7ba54d8b043986ceacc90679f051f1ebf генератор зависимостей QML] и желательно заапстримить его<br />
* починить не собирающиеся пакеты, возможно, снова обновив glibc и gcc<br />
* либо отвязать [https://abf.io/soft/drakxtools drakxtools] от perl-URPM (или перейти на manatools, как минимум настройку часов оттуда точно нужно взять, т.к. она умеет не только в ntpd, а еще и в chrony и systemd-timesyncd, а это [https://abf.io/import/ipa-client47/blob/rosa2019.1/0001-Restore-ntpd-support.patch важно]), либо придется оставить urpmi в качестве существующего параллельно с DNF пакетного менедежера, как в Mageia<br />
* если будет решено оставить urpmi и perl-URPM, то, во-первых, взять их версии из Mageia (они умеют работать c rpm4), во-вторых, перенести /usr/{sbin,bin}/{urpmi,urpme} куда-нибудь в /usr/lib/, а в (s)bin отставить [https://github.com/rpm-software-management/dnf-URPM dnf-URPM]<br />
* после обновления perl-URPM до версии из Mageia или его убирания обновить perl<br />
* если получится избавиться от urpmi, наверняка стоит избавиться от префикса lib64 в названии пакетов, который существует из-за неумения urpmi отличать пакеты с одинаковым названием, но одинаковой архитектурой (но вопрос требует тщательного обдумывания, в т.ч. — не пострадает ли wine)<br />
* переработать пакет [https://abf.io/import/rosa-repos rosa-repos]: вынести main, contrib, non-free и т.д. в отдельные подпакеты<br />
* собрать и обеспечить работу GUI для управления пакетами dnfdranoga<br />
* сделать генерацию метаданных appstream из всего репозитория<br />
* во все пакеты автоматически добавлять метаданные /usr/share/metainfo/*.xml, чтобы в графических "магазинах приложений" были все пакеты, а не только лишь те, в которых есть /usr/share/metainfo/*.xml; возможно, скрыть системные пакеты, имена которых начинаются на lib<br />
* обновить весь стек GNOME и затем обеспечить работу gnome-software<br />
* поскольку в drmdrake был GUI для управления репозиториями, а в dnfdranoga его нет, в пакеты rosa-repos-* добавить метаданные с описанием назначения этих репозиториев и с его переводом на русский язык; в магазинах приложений сделать отдельную категорию пакетов "Репозитории ROSA"; это позволит включать и отключать репозитории одной кнопкой "Установить"/"Удалить" пакет, также улучшит централизацию поставки конфигураций репозиториев<br />
* собрать, обновить и обеспечить работу packagekit<br />
* обеспечить работу оффлайн-обновлений через packagekit+systemd<br />
* портировать хеши файлов по ГОСТ Р 34.11-2012 из rpm5 в rpm4 и желательно заапстримить (rpm4 уже переключен на libgcrypt по умолчанию)<br />
* начать использовать security.ima и интегрировать подписывание в сборочницу, в т.ч. проработать вопрос с ГОСТ<br />
* придумать, как существующие системы обновить до rosa2019.1 с rpm4 и задокументировать (будут проблемы с конвертированием БД rpm)<br />
* осуществить полный переезд в /usr<br />
* проработать нюансы, возникшие после смены %_libexecdir = %_libdir на %_libexecdir = /usr/libexec<br />
* инсталлятор, скорее всего [https://github.com/rhinstaller/anaconda Anaconda], в которой есть в т.ч. режим, похожий на rsync в draklive-install, а также можно сделать выбор пакетов для установки, и есть поддержка kickstart-файлов<br />
* сделать что-то с "бекендом" для urpmi в пакете [https://abf.io/import/system-config-printer system-config-printer], желательно выкинуть и использовать апстримную интеграцию с PackageKit; а сам system-config-printer отвязать от consolehelper и перейти на апстримную интеграцию с policykit, чтобы работала печать тестовых заданий с авторизацией по тикету Kerberos текущего пользователя<br />
* ...<br />
<br />
== Особенности перевода спеков на RPM 4 ==<br />
<br />
Скрипт rpm5-to-rpm4.sh, который автоматически вносит правки в спеки, здесь: https://gitlab.com/abf-mirror/abf-mirror-scripts<br />
<br />
Если вы видите коммиты от "NixTux Commit Bot" с текстом: "bot: rpm5 -> rpm4 (N)", — где N — номер итерации прохода скрипта по всем пакетам в abf.io/import/, то это коммиты, сделанные этим скриптом. Каковы были изменения в скрипте между итерациями, можно посмотреть в git по ссылке выше.<br />
<br />
* уменьшено количество пакетов в базовой сборочной системе, так, basesystem-build больше не зависит от initscripts, gpg и др. (см. [https://abf.io/import/basesystem/commits/rosa2019.1 коммиты]), а из-за отсутствия initscripts больше нет, например, procps-ng с командой ps; минимизация сборочной системы — это скорее хорошо, чем плохо, т.к. ускоряет сборку, а мейнтейнер пакета будет вынужден лучше понимать, как происходит его сборка; при необходимости "потерянные" зависимости добавьте в BuildRequires вручную, [https://abf.io/import/perl/commit/e2785eeabcfb5a0cf1b06c6fb884291d46d7eebd пример]."BuildRequires: /usr/bin/python2"<br />
<br />
По причине отсутствия пакетов python / python3 в базовой системе в BuildRequires не работают макросы %python* из этих пакетов.<br />
<br />
* из базовой сборочной системы убран /usr/bin/python, делайте "BuildRequires: /usr/bin/python" или "BuildRequires: /usr/bin/python2" или "BuildRequires: /usr/bin/python3" при необходимости; обратите внимание, что python3-devel, он же pkgconfig(python3) и аналогично python-devel/pkgconfig(python) не подтягивают /usr/bin/python(3). Характерная ошибка:<br />
BUILDSTDERR: sh: /usr/bin/python: No such file or directory<br />
В настоящий момент /usr/bin/python — это python2.<br />
<br />
* Suggests и Requires(missingok) теперь '''Recommends''': в RPM 5 были только Suggests и Requires(missingok) (а Suggests был алиасом Requires(missingok), а в RPM 4 есть и то, и то, но Recommends работает так, как работал Suggests, а Suggests используется для иных вещей, поэтому заменяем "Suggests:" на "Recommends:", а чтобы такие спеки продолжали работать в RPM 5, мы [https://abf.io/soft/rpm5/commit/fb49a705c7f8fb716f7e5a7ed945bb91901e73ff научили] его понимать Suggests: теперь он считает и Suggests, и Recommends одинаково эквивалентными "Requires(missingok)"<br />
<br />
* Фильтры для автоматического генератора зависимостей (requires) и провайдов (provides) поменялись следующим образом, ниже сначала вариант RPM 4 (новый), затем RPM 5 (старый):<br />
%__requires_exclude -> %__noautoreq<br />
%__provides_exclude -> %__noautoprov<br />
%__requires_exclude_from -> %__noautoreqfiles<br />
%__provides_exclude_from -> %__noautoprovfiles<br />
Нет возможности легко научить RPM 4 понимать %__noautoreq, %__noautoprov, %__noautoreqfiles и %__noautoprovfiles, но есть возможность легко научить RPM 5 понимать оба варианта, что мы и [https://abf.io/soft/rpm5/commit/8c91a49b1f0b167db1b97e2394659f73531d2dfc сделали].<br />
Теперь, если в спеке указаны одновременно старый макрос и эквивалентный ему новый макрос, например:<br />
%define __noautoreq 'libGL.*'<br />
%global __requires_exclude 'libGL.*'<br />
...то rpm5 будет брать только значение старого (__noautoreq) и игнорировать новый (__requires_exclude). Если же указан только новый (__requires_exclude), то будет браться его значение. В большинстве случаев достаточно использовать только новый вариант от RPM 4, т.е. только<br />
%global __requires_exclude 'libGL.*'<br />
...но, если вдруг понадобится задать разные правила для RPM 5 и RPM 4, то укажите оба варианта, тогда RPM 5 возьмет только свой прежний вариант, а RPM 4 только свой. Обратите внимание, что RPM 4 не понимает старые варианты от RPM 5, поэтому для RPM 4 обязательно указать __requires_exclude, а не __noautoreq. %global и %define здесь примерно одно и то же и для RPM 4, и для RPM 5, но документация от разработчиков RPM 4 рекомендует использовать %global, когда как в rpm5 более предпочтительно было %define.<br />
<br />
Про варианты от RPM 4 читайте [https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/ здесь].<br />
<br />
Мы тщательно не изучали особенности раскрытия регулярных выражений в этих макросах-фильтрах, возможны нюансы, новые варианты сделаны эквивалентными старым для большинства типовых случаев.<br />
<br />
* В пакете [https://abf.io/import/rpm-openmandriva-setup rpm-openmandriva-setup] собраны макросы, которые существовали в RPM 5 и которых теперь нет в RPM 4, чтобы они продолжали работать в ROSA. Какие-то макросы просто скопированы, какие-то преобразовываются в их новые варианты. Также мы [https://abf.io/soft/rpm5/commit/d642081cb2497f64eff9e4a2db7c0ee60662f469 добавили] некоторые широко распространенные новые макросы от rpm4 в rpm5, чтобы после их замены в спеках описанным выше скриптом спеки продолжали работать для rosa2016.1 и rosa2019.0 без изменений.<br />
<br />
Типовые замены макросов:<br />
%make -> %make_build<br />
%makeinstall_std -> %make_install<br />
%configure2_5x -> %configure<br />
%setup_compile_flags -> %set_build_flags<br />
%ldflags -> %build_ldflags<br />
Также появились %build_cflags (CFLAGS, флаги компилятора Си), %build_cxxflags (CXXFLAGS, флаги компилятора Cи++), %build_fflags (FFLAGS, флаги компилятора Фортран); в rpm5 они сделаны эквивалентными %optflags; %optflags продолжает существовать, как и раньше.<br />
<br />
Макросы %make_* стали унифицированы с %ninja_*, %meson_* и др., т.е. build означает сборку, install — установку. Возможно изменение политики в отношение макросов.<br />
<br />
* rpm5 с описанными выше изменениями уже опубликован в rosa2019.0 и rosa2016.1<br />
<br />
* Если нет иного выхода, то можно сделать if/else:<br />
%if %{mdvver} >= 201910<br />
< вариант для rpm4 ><br />
%else<br />
< вариант для rpm5 ><br />
%endif<br />
<br />
* rpm4 не позволяет закомментировать %define:<br />
#%define xxx yyy<br />
не будет работать, нужно заменить "#%define" на "#define"<br />
* в rpm4 не поддерживаются стадии BuildRequires, т.е. записи BuildRequires(check), BuildRequires(pre) заменяем на BuildRequires; потеря не велика, это использовалось очень редко и, как оказалось, во всем репозитории только одним из авторов этой статьи, при чем там, где без этого можно обойтись, просто для пущей красоты было<br />
* %_libexecdir теперь не /usr/lib(64), а /usr/libexec<br />
* в RPM 5 директории %_bindir, %_libdir и др. наследовали значение %_prefix, в rpm4 не наследуют, пример правок в пакете [https://abf.io/import/libressl/commits/rosa2019.1 libressl] (мы думаем над тем, как решить эту проблему, чтобы снова наследовалось значение %_prefix)<br />
* в RPM 4 есть такой макрос:<br />
%__pkgconfig_path ^((%{_libdir}|%{_datadir})/pkgconfig/.*\.pc|%{_bindir}/pkg-config)$<br />
Если значение %_libdir переназначено, то файлы *.pc для создания Requires и Provides скриптом [https://github.com/rpm-software-management/rpm/blob/master/scripts/pkgconfigdeps.sh scripts/pkgconfigdeps.sh] будут искаться, возможно, не там, где вы хотите<br />
<br />
[https://abf.io/import/libressl/commit/bcce10a2c4018284b314965c2b1492913d638712 Пример] решения (переназначим этот макрос, указав нужные пути):<br />
%global __pkgconfig_path ^(%{_olibdir}/pkgconfig/.*\\.pc|%{_obindir}/pkg-config)$<br />
В RPM 5 такого макроса нет, поэтому этот %global/%define ему безразличен.<br />
* в RPM нельзя поставить %attr() на символическую ссылку, RPM 5 игнорировал такое, а RPM 4 выдает ошибку в явном виде, пример:<br />
Explicit %attr() mode not applicable to symlink: /builddir/build/BUILDROOT/log4cpp-1.0-6.i386/usr/lib/liblog4cpp.so<br />
Исправление — убрать лишний %attr<br />
* в сборочнице теперь отключен доступ в сеть, часть пакетов не собирается с ошибкой вида:<br />
BUILDSTDERR: error: Bad source: /builddir/build/SOURCES/mds-2.4.2.2.tar.gz: No such file or directory<br />
В таких случаях нужно вручную или с помощью "abf put" закачать исходники пакета на ABF. Раз такие пакеты собирались ранее, значит в них достаточно автоматизированно сделать "abf put" и закоммитить, но для этого нужно составить список таких пакетов<br />
* rpm5 съедал все содержимое папки с %doc, даже если туда положить что-то лишнее, а rpm4 требует явного указания всего содержимого папки /usr/share/doc/%name. Пример ошибки:<br />
DEBUG: BUILDSTDERR: error: Installed (but unpackaged) file(s) found:<br />
DEBUG: BUILDSTDERR: /usr/share/doc/miau/examples/miaurc<br />
При этом в пакете было:<br />
%doc AUTHORS ChangeLog README TODO misc/miaurc<br />
Файл examples/miaurc не прописан ни в %files, ни в %doc, а rpm5 игнорировал такую недоработку спека.<br />
<br />
Другой пример:<br />
# (cg) Copy the whole contrib dir as docs. It contains useful scripts.<br />
mkdir -p %{buildroot}%{_datadir}/doc/git-core<br />
cp -ar contrib %{buildroot}%{_datadir}/doc/git-core<br />
Это рассчитано на поведение rpm5, для rpm4 так делать не нужно.<br />
* rpm5 позволял написать: "%package -n %{name}", а rpm4 выдает ошибку:<br />
BUILDSTDERR: error: line 133: %package -n ipa-client47: package ipa-client47 already exists<br />
Это логично, потому что %package, грубо говоря, используется для подпакетов, а пакет с именем %name уже и так автоматически задан. [https://abf.io/import/ipa-client47/commit/ac6f9e967687fa0aafe72c2b573ccef2cd9fab3f Пример] исправления.<br />
* в RPM4 в макрос %configure входит:<br />
<br />
find . -name config.guess -o -name config.sub | while read i ; do <br />
[ -f /usr/share/libtool/config/"$(basename "$i")" ] && /bin/rm -f "$i" && /bin/cp -fv /usr/share/libtool/config/"$(basename "$i")" "$i" ; <br />
done ; <br />
if [ -e configure.ac -a -e Makefile.am ]; then <br />
find . -name configure.ac |xargs dirname |while read D; do <br />
pushd $D; <br />
if grep -qE '(LT_INIT|LIBTOOL)' configure.ac >/dev/null; then <br />
libtoolize --force ; <br />
fi ; <br />
aclocal $((find . -name "*.m4" 2>/dev/null |grep -vE 'ac(local|include).m4' | xargs dirname) | grep -v '^.$' |sort |uniq |cut -d/ -f2- |while read R; do [ -e $R/configure.ac ] || echo -n "-I$R "; done) ; <br />
automake -a --foreign ; <br />
autoconf ; <br />
popd ; <br />
done ; <br />
fi ;<br />
<br />
Этого не было и нет в %configure(2_5x) в RPM 5, но представляется полезным действием для актуализации сборочных скриптов тарболлов, что особенно важно при сборке на не-x86. Это может потребовать добавления новых BuildRequires, например, gettext-devel.<br />
<br />
Если это пересоздание configure нужно отключить (например, при сборке пакетов libtool и autoconf, где такое действие вызывает как бы циклическую зависимость от самих себя), то:<br />
%define _disable_rebuild_configure 1<br />
<br />
* %exclude работает по-разному: в rpm, если в списке файлов (%files) есть %exclude, то он применяется, чтобы какой-то из файлов, попадающий в перечисленные файлы, не включать в этот список, например: есть файлы file.php, file.sh, file.c, а вы пишите:<br />
%files<br />
file.*<br />
%exclude file.php<br />
Тогда в пакет попадут file.c и file.sh, а file.php не попадет. Но, если вы его вручную не удалите и не положите ни в один пакет, rpm5 выдаст ошибку о неупакованном файле, а rpm4 не выдаст и сам удалит этот файл. Изменение поведения rpm4 обсуждается [https://github.com/rpm-software-management/rpm/issues/994 здесь].<br />
<br />
* генератор зависимостей и провайдов Perl в RPM 4 "смотрит глубже". Например, в пакете autoconf2.1 на строку<br />
require "find.pl";<br />
была выставлена зависимость:<br />
Requires: perl(find.pl)<br />
Но ни один пакет такое не провайдит. RPM 5 такую зависимость не выставлял. [https://abf.io/import/autoconf2.1/commit/8ba0e8375bca02dc3cef22ee2e0417a600c1718b Решилось] патчем, который заменил "require "find.pl";" на "use File::Find qw(find);".<br />
<br />
* байтовая компиляция в Python: в пакете python (python2), рядом с /etc/pythonrc.py, появились /etc/pythonrc.pyc и /etc/pythonrc.pyo, решилось так:<br />
%define _python_bytecompile_build 0<br />
Этот вопрос требует исследования.<br />
<br />
* Перевод дополнительных макросов в пакетах на установку через %install_macro:<br />
В RPM 4 и 5 используются разные места для размещения дополнительных макросов, но, что самое главное, отличаются имена файлов с макросами: в RPM 5 это *.macros, а в RPM 4 — macros.*. В связис этим был придуман макрос '''%install_macro''', который создает универсальный метод установки макросов и в rpm4, и в rpm5. Макрос был добавлен [https://abf.io/import/rpm/blob/rosa2019.1/0001-Add-macro-to-install-files-with-macros.patch в rpm4] и [https://abf.io/soft/rpm5/commit/3d193c2fd90721f63c9fc3e3183c61822a858e75 в rpm5]. [https://abf.io/import/ninja/commit/154c4316aa881dc5074e747a9c728724374a38e8 Пример]:<br />
%install_macro ninja %{SOURCE2}<br />
устанавливает файл %{SOURCE2} в папку с макросами, на rpm4 называя файл macros.ninja, а на rpm5 — ninja.macros. В список файлов пакета (%files) пишем:<br />
%{_rpmmacrodir}/*%{name}*<br />
Под "*%{name}*" попадают и "%{name}.macros", и "macros.%{name}", что позволяет использовать один и тот же спек для сборки и на rpm4, и на rpm5, не делая if/else.<br />
<br />
Примеры перевода пакетов на новую схему установки макросов: [https://abf.io/import/meson/commit/919dffa717e12244f920a4dddde8a314174d06e8 meson], [https://abf.io/import/ninja/commit/154c4316aa881dc5074e747a9c728724374a38e8 ninja], [https://abf.io/import/python/commit/0d2d59cce64562222a7d28f4511db7a57f0ccd8a python2], [https://abf.io/import/python3/commit/b89610d921684a301ac190decf412f7d3e4fb31f python3], [https://abf.io/import/qt5-macros/commit/483f7933638b2e6a743502ca1e3f7183db91457d qt5-macros], [https://abf.io/import/waf/commit/b5db950a83f71d9e46805a33524302e7f16cb92d waf]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D0%BB%D0%BE%D0%B3%D0%B0:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%C2%AB%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%C2%BB_%E2%80%94_howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%BE%D1%81%D0%B5/c000155&diff=18351Обсуждение блога:Точка Росы/«Сделай сам» — howto для желающих обновлять программы в Росе/c0001552019-12-06T09:08:54Z<p>D uragan: Новый комментарий от D uragan: rpm-пакеты, собранные из персональных git-репозиториев, в репы Росы напрямую не добавл…</p>
<hr />
<div>rpm-пакеты, собранные из персональных git-репозиториев, в репы Росы напрямую не добавляются. Сначала разработчики должны форкнуть ваш проект в группу import, а потом уже сами собрать rpm-пакеты.<br />
<br />
Чтобы разработчики этим занялись, можно завести соответствующий запрос в багзиллу, добавив в заголовок для ясности [PACKAGE REQUEST], а в описании дать ссылки на свои проекты в ABF (например так: https://bugzilla.rosalinux.ru/show_bug.cgi?id=8588)<br />
{{wl-comment: Точка Росы/«Сделай сам» — howto для желающих обновлять программы в Росе/c000154 }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D0%BB%D0%BE%D0%B3%D0%B0:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%C2%AB%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%C2%BB_%E2%80%94_howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%BE%D1%81%D0%B5/c000153&diff=18341Обсуждение блога:Точка Росы/«Сделай сам» — howto для желающих обновлять программы в Росе/c0001532019-11-11T09:24:34Z<p>D uragan: Новый комментарий от D uragan: Обязательное подтверждение регистрации вернули, поскольку стало регистрироватьс…</p>
<hr />
<div>Обязательное подтверждение регистрации вернули, поскольку стало регистрироваться слишком много ботов.<br />
<br />
Письма с подтверждением действительно могут либо попадать в спам (gmail), а то и вообще не доходить (рамблер). До многих, тем не менее, доходят без проблем (например, до мейл-ру). Админы ABF в курсе этих проблем, но сроков по решению пока нет.<br />
<br />
Если письмо попало в спам - надо его явно пометить как не-спам, иначе есть шанс, что URL для подтверждения не будет показан. Если совсем не дошло - то лучше попробовать другой адрес. Либо писать в поддержку провайдера почты.<br />
{{wl-comment: Точка Росы/«Сделай сам» — howto для желающих обновлять программы в Росе/c000152 }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95&diff=18340Обновление пакетов в РОСЕ2019-11-11T09:19:06Z<p>D uragan: + link to repology</p>
<hr />
<div>Репозитории РОСЫ содержат тысячи различных пакетов, которые необходимо обновлять по мере выхода новых версий соответствующих программ. Несмотря на [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Updates_builder_-_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%82%D1%81%D0%BB%D0%B5%D0%B6%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_ABF различные средства автоматизации], для обновления многих пакетов требуется участие человека.<br />
<br />
Оценить "свежесть" пакетной базы разных дистрибутивов можно, например, на сайте https://repology.org. Там же можно для каждого пакета определить самую последнюю версию и попробовать собрать ее на ABF.<br />
<br />
Самый простой сценарий обновления заданного пакета [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%22%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%22-Howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95 описан в блоге "Точка РОСЫ"]. Однако он рассчитан на людей, которые не знакомы даже с Git и только могут кликать различные иконки в веб-браузере. От студентов, проходящих у нас практику, мы ожидаем несоклько большего и даем им более сложные пакеты, для обновления которых могут потребоваться более серьезные усилия.<br />
<br />
Если обновление по приведенной выше инструкции не проходит, то необходимо склонировать себе проект в машину с РОСОЙ:<br />
<br />
$ abf get <your_abf_login>/<project_name> -b rosa2019.1<br />
<br />
Переходим в директорию <project_name>, кладем в нее архив с исходным кодом новой версии и изменяем внутри файла <project_name>.spec значение тэга Version (если еще не сделали это в веб-интерфейсе).<br />
<br />
Теперь получившийся пакет надо собрать. Для этого сначала надо установить пакеты, которые требуются для его сборки (прописаны в BuildRequires). Для этого внутри директории <project_name> выполняем команду:<br />
<br />
$ urpmi <project_name>.spec<br />
<br />
И запускаем саму сборку с помощью {{Prog|rpmbuild}}:<br />
<br />
$ rpmbuild -bb <project_name>.spec<br />
<br />
если повезет и все соберется сразу, то в этой же директории даем команду отправить все на ABF:<br />
<br />
$ abf put -m «Updated to a new version»<br />
<br />
После чего идем в веб-интерфейс на страничку проекта в своем репозитории и делаем Pull Request в соответствующий проект группы import. Не забывайте выбирать ветку «rosa2019.1»!<br />
<br />
Также не забываем проверять работоспособность результата — для этого необходимо установить собранные пакеты в систему и убедиться, что они работают. Если вы собрали библиотеку/модуль, вам нужно проверить приложение, его использующее. Определить список всех пакетов, использующих данный, можно с помощью команды<br />
<br />
$ urpmq --whatrequires <package_name><br />
<br />
Если есть сомнения в работоспособности пакета или непонятно, как его проверить, то все равно шлите Pull Request. Только отдельно сообщите нам, что функционал новой версии проверить не удалось.<br />
<br />
Если в процессе сборки что-то пошло не так, то надо смотреть на ошибки — если идет ругань на то, что какие-то файлы не найдены (или наоборот, найдены неупакованные файлы), то надо править секцию %files в spec-файле. Могут быть жалобы на то, что не хватает каких-то программ для сборки; в этом случае надо постараться понять - каких именно, доустановить их в систему и прописать соответствующее поле BuildRequiers в spec-файле.<br />
<br />
В целом, ошибки могут быть самые разные, и далеко не со всеми из них можно быстро разобраться. Поэтому если за разумное время пакет собрать не удалось, лучше сообщить о встреченной проблеме разработчикам РОСЫ и перейти к следующему пакету. В качестве результатов работы нам важны как Pull Request'ы на обновление пакетов, которые обновились успешно, так и перечень пакетов, которые собрать не удалось, с описанием ошибок сборки. В последнем случае можно просто прислать журнал сборки для каждого пакета либо попробовать собрать пакет в своем персональном репозитории на ABF и дать нам ссылку на сборку.<br />
<br />
== Поиск новых версий ==<br />
<br />
Немаловажный аспект - определение того, какая версия программы является последней. Безусловно, можно просто обратиться к сайту разработчика, однако могут возникнуть нюансы:<br />
* в пакете может быть указан неверный URL сайта разработчика (хоть мы и [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%9E%D0%B1_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8_URL_%D0%B2_%D0%BC%D0%B5%D1%82%D0%B0%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_RPM-%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 призываем поддерживать ссылки в актуальном состоянии], они все-таки иногда протухают<br />
* самые свежие версии могут иметь проблемы со сборкой либо функционалом<br />
<br />
В подобных случаях полезно посмотреть на версию этой же программы, собранной в других дистрибутивах. Для этого можно воспользоваться нашей утилитой {{Prog|mib-report}} (необходимо в РОСЕ установить соответствующий пакет и запустить утилиту) либо сервисами наподобие [http://pkgs.org Pkgs.org] или [http://upstream.rosalinux.ru/updates/rosa/2014/ ROSA Upstream Tracker].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_TeXLive&diff=18337Сборка пакетов-расширений для TeXLive2019-10-11T16:50:15Z<p>D uragan: </p>
<hr />
<div>TeX - система компьютерной вёрстки, широко используемая по всему миру.<br />
<br />
В Linux в настоящее время активно используется реализация от проекта {{Prog|texlive}}, которая включает в себя не просто основные инстурменты верстки,<br />
но и множество дополнений и расширений (дополнительных шрифтов, пакетов с поддержкой разлицных языков, шаблонов диссертаций и презентаций и так далее).<br />
<br />
В РОСЕ каждое такое дополнение оформляется как отдельный RPM-пакет. <br />
<br />
Рассмотрим процесс упаковки расширения с названием '''TEXPKG''' в пакет {{Pkg|texlive-<TEXPKG>}}<br />
<br />
Сначала проверяем, что страничка пакета доступна по адресу http://www.ctan.org/tex-archive/macros/latex/contrib/<TEXPKG>. Эта ссылка должна быть прописана в URL spec-файла. Со странички проекта берем Summary (не более 80 симполов), лицензию (тэг License) и описание (для секции %description). Если есть версия - берем ее со странички, если нет - используем в качестве версии дату, когда вы скачали исходники, в формате ГГГГММДД (например, 20191231).<br />
<br />
Далее ищем в директории http://mirrors.ctan.org/systems/texlive/tlnet/archive/ файл {{File|<TEXPKG>.tar.xz}}.<br />
Там же могут находиться файлы {{File|<TEXPKG>.doc.tar.xz}} и {{File|<TEXPKG>.source.tar.xz}} - если есть, их тоже берем.<br />
<br />
Их надо прописать в качестве Sources:<br />
<br />
Source0: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.tar.xz<br />
Source1: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.doc.tar.xz<br />
Source2: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.source.tar.xz<br />
<br />
Внутри ахивов обязательно есть папки {{File|tlpkg/tlpobj}} - в них лежат файлы с информацией о пакете. Если вдруг на страничке пакета не оказалось<br />
каких-то данных (версии, описания и тому подобного), то поищите их здесь. Здесь же могут быть прописаны зависимости пакета от других пакетов texlive<br />
(со словом depend) - из надо обязательно указать как Requires в spec-файле.<br />
<br />
Например, если в tlpkg/tlpobj/<TEXPKG> есть запись<br />
<br />
depend babel-belarusian<br />
<br />
то в spec-файле должна присутсвовать соответсвующая зависимоcть<br />
<br />
Requires: texlive-babel-belarusian<br />
<br />
Значение тэга Group для пакетов texlive - всегда '''Publishing'''.<br />
<br />
Как правило, пакеты являются арзитектурно-независимыми, поэтому надо дабавить в spec-файл запись<br />
<br />
BuildArch: noarch<br />
<br />
(если пакет является архитектурно-зависимым, то rpmbuild его не соберет с соответсующей ошибкой - тогда BuildArch надо убрать).<br />
<br />
Всем texlive-пакетам необходимо прописать сборочную зависимость (BuildRequires) от {{Pkg|texlive-tlpkg}}. Этот же пакет<br />
надо указать как предустановочную зависимость ("Requires(pre)"). В качестве пост-установочной зависимости post-скрипта ("Requires(post)") надо указать<br />
{{Pkg|texlive-kpathsea}}.<br />
<br />
Для большинства пакетов, секция '''%prep''' сводится к распаковке архивов, например:<br />
<br />
%setup -c -a0 -a1 -a2<br />
<br />
секция '''%build''' отсутствует, а '''%install''' сводится к копированию директорий, содержащихся внутри архивов (за исключением директории {{File|tlpkg}}), в {{File| %{buildroot}%{_texmfdistdir} }} (которую надо предварительно создать):<br />
<br />
s %install<br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar fonts tex doc source %{buildroot}%{_texmfdistdir}<br />
<br />
(проследите, чтобы скопированы были все директории из архивов, кроме tlpkg) <br />
<br />
Эти же директории достаточно указать в секции %files, пометив sources и doc как документацию:<br />
<br />
%files<br />
%{_texmfdistdir}/tex/latex/<TEXPKG><br />
%{_texmfdistdir}/fonts/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/source/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/doc/latex/<TEXPKG><br />
<br />
Подготовив spec-файл и скачав архивы с исходным кодом, необходимо убедиться в возможности собрать пакет с помощью {{Cmd|rpmbuild -bb}}. Если проблем нет - то собираем src.rpm ({{Cmd|rpmbuild -bs}}) и создаем из него проект в своем репозитории на ABF.<br />
<br />
Примеры texlive пакетов:<br />
* https://abf.io/import/texlive-mpgraphics<br />
* https://abf.io/import/texlive-mceinleger<br />
* https://abf.io/import/texlive-makecmds<br />
<br />
(смотрите ветку rosa2019.1)<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_TeXLive&diff=18336Сборка пакетов-расширений для TeXLive2019-10-11T16:48:51Z<p>D uragan: Creation</p>
<hr />
<div>TeX - система компьютерной вёрстки, широко используемая по всему миру.<br />
<br />
В Linux в настоящее время активно используется реализация от проекта {{Prog|texlive}}, которая включает в себя не просто основные инстурменты верстки,<br />
но и множество дополнений и расширений (дополнительных шрифтов, пакетов с поддержкой разлицных языков, шаблонов диссертаций и презентаций и так далее).<br />
<br />
В РОСЕ каждое такое дополнение оформляется как отдельный RPM-пакет. <br />
<br />
Рассмотрим процесс упаковки расширения с названием '''TEXPKG''' в пакет {{Pkg|texlive-<TEXPKG>}}<br />
<br />
Сначала проверяем, что страничка пакета доступна по адресу http://www.ctan.org/tex-archive/macros/latex/contrib/<TEXPKG>. Эта ссылка должна быть прописана в URL spec-файла. Со странички проекта берем Summary (не более 80 симполов), лицензию (тэг License) и описание (для секции %description). Если есть версия - берем ее со странички, если нет - используем в качестве версии дату, когда вы скачали исходники, в формате ГГГГММДД (например, 20191231).<br />
<br />
Далее ищем в директории http://mirrors.ctan.org/systems/texlive/tlnet/archive/ файл {{File|<TEXPKG>.tar.xz}}.<br />
Там же могут находиться файлы {{File|<TEXPKG>.doc.tar.xz}} и {{File|<TEXPKG>.source.tar.xz}} - если есть, их тоже берем.<br />
<br />
Их надо прописать в качестве Sources:<br />
<br />
Source0: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.tar.xz<br />
Source1: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.doc.tar.xz<br />
Source2: http://mirrors.ctan.org/systems/texlive/tlnet/archive/<TEXPKG>.source.tar.xz<br />
<br />
Внутри ахивов обязательно есть папки {{File|tlpkg/tlpobj}} - в них лежат файлы с информацией о пакете. Если вдруг на страничке пакета не оказалось<br />
каких-то данных (версии, описания и тому подобного), то поищите их здесь. Здесь же могут быть прописаны зависимости пакета от других пакетов texlive<br />
(со словом depend) - из надо обязательно указать как Requires в spec-файле.<br />
<br />
Например, если в tlpkg/tlpobj/<TEXPKG> есть запись<br />
<br />
depend babel-belarusian<br />
<br />
то в spec-файле должна присутсвовать соответсвующая зависимоcть<br />
<br />
Requires: texlive-babel-belarusian<br />
<br />
Значение тэга Group для пакетов texlive - всегда '''Publishing'''.<br />
<br />
Как правило, пакеты являются арзитектурно-независимыми, поэтому надо дабавить в spec-файл запись<br />
<br />
BuildArch: noarch<br />
<br />
(если пакет является архитектурно-зависимым, то rpmbuild его не соберет с соответсующей ошибкой - тогда BuildArch надо убрать).<br />
<br />
Всем texlive-пакетам необходимо прописать сборочную зависимость (BuildRequires) от {{Pkg|texlive-tlpkg}}. Этот же пакет<br />
надо указать как предустановочную зависимость ("Requires(pre)"). В качестве пост-установочной зависимости post-скрипта ("Requires(post)") надо указать<br />
{{Pkg|texlive-kpathsea}}.<br />
<br />
Для большинства пакетов, секция '''%prep''' сводится к распаковке архивов, например:<br />
<br />
%setup -c -a0 -a1 -a2<br />
<br />
секция '''%build''' отсутствует, а '''%install''' сводится к копированию директорий, содержащихся внутри архивов (за исключением директории tlpkg), в %{buildroot}%{_texmfdistdir} (которую надо предварительно создать):<br />
<br />
%install<br />
mkdir -p %{buildroot}%{_texmfdistdir}<br />
cp -fpar fonts tex doc source %{buildroot}%{_texmfdistdir}<br />
<br />
(проследите, чтобы скопированы были все директории из архивов, кроме tlpkg) <br />
<br />
Эти же директории достаточно указать в секции %files, пометив sources и doc как документацию:<br />
<br />
%files<br />
%{_texmfdistdir}/tex/latex/<TEXPKG><br />
%{_texmfdistdir}/fonts/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/source/latex/<TEXPKG><br />
%doc %{_texmfdistdir}/doc/latex/<TEXPKG><br />
<br />
Подготовив spec-файл и скачав архивы с исходным кодом, необходимо убедиться в возможности собрать пакет с помощью "rpmbuild -bb". Если проблем нет - то собираем src.rpm (rpmbuild -bs) и создаем из него проект в своем репозитории на ABF.<br />
<br />
Примеры texlive пакетов:<br />
https://abf.io/import/texlive-mpgraphics<br />
https://abf.io/import/texlive-mceinleger<br />
https://abf.io/import/texlive-makecmds<br />
<br />
(смотрите ветку rosa2019.1)<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_RPM_-_%D0%B1%D1%8B%D1%81%D1%82%D1%80%D1%8B%D0%B9_%D1%81%D1%82%D0%B0%D1%80%D1%82&diff=18329Сборка RPM - быстрый старт2019-09-24T07:40:00Z<p>D uragan: Fix template usage</p>
<hr />
<div>{{Введение|Этот документ содержит краткий экскурс в сборку RPM-пакетов для систем линейки ROSA Desktop. Документ не претендует на полноту, для более детальной информации смотрите ссылки, приведенные в конце страницы.}}<br />
<br />
== Подготовка к сборке и обзор spec-файла ==<br />
<br />
Сперва давайте разберёмся, что должно быть в системе для сборки rpm-пакета. Обязательно должен быть установлен пакет {{pkg|rpm-build}}. Без него не будет доступна команда rpmbuild. Наряду с ним, по зависимостям поставится еще ряд пакетов, используемых при сборке. В зависимостях для сборки пакета в РОСЕ обычно не принято прописывать компилятор C/C++, по этому поводу рано или поздно вам понадобятся пакеты {{Pkg|gcc}} и {{Pkg|gcc-c++}} Все остальные зависимости должен попросить сам пакет. Конечно бывают промахи, и в процессе сборки вы понимаете, что что-то упустили, но это обычно бывает довольно редко и не критично.<br />
<br />
А что собственно из себя представляет RPM пакет? RPM-пакеты делятся на пакеты с исходниками - {{file|src.rpm}} и пакеты, готовые к установке - {{file|%{arch}.rpm}}. В src.rpm пакетах содержится исходный тарболл (исходник программы), какие-либо другие исходники, пачти и самый главный spec-файл, который управляет процессом сборки. Все эти файлы упакованы в cpio архив. Когда вы пытаетесь войти в src.rpm пакет при помощи файлового менеджера {{Программа|mc}}, вы его увидите. Также в пакете присутствует некоторые файлы с информацией.<br />
<br />
В %{arch}.rpm-пакетах содержится cpio-архив с файлами, которые после установки разложатся по соответствующим каталогам, файлы информации и установочные скрипты.<br />
<br />
Также вы можете встретить без исходного кода. Обычно их создают для проприетарных программ, которые нельзя включать в дистрибутив (исходников нет, а бинарник каким-то образом нужно переделать либо просто запрещено размещать на зеркалах дистрибутива лицензией). Внутри этого пакета находится обычно только spec-файл, а бинарник скачивается и, при необходимости, модифицируется, в процессе установки пакета (например, в post-скрипте, о котором речь пойдет ниже).<br />
<br />
Собирать пакеты можно из-под любого пользователя. Делать это из-под root'а не рекомендуется, т.к. есть вероятность, что корнем для секции инсталляции окажется каталог {{file|/}} и тогда команда {{cmd|rm -rf %{buildroot} }} уничтожит все на свете. Также бывает, что «кривые» пакеты не правильно выполняют инсталляцию, и ставятся не во временный каталог, а прямо куда-нибудь в {{macro|%{_prefix} }} ({{file|/usr}}). Часть файлов будет потеряна, хотя на работоспособности пакета на этой машине понятное дело это не скажется.<br />
<br />
Что нужно сделать, чтобы можно было собирать пакеты из-под обычного пользователя? Первым делом нужно создать в своём домашнем каталоге файл директорию rpmbuild со следующей структурой:<br />
<br />
~/rpmbuild<br />
|-- BUILD<br />
|-- BUILDROOT<br />
|-- RPMS<br />
| |-- i586<br />
| |-- x86_64<br />
| `-- noarch<br />
|-- SOURCES<br />
|-- SPECS<br />
`-- SRPMS<br />
<br />
Каталоги {{file|BUILD}}, {{file|RPMS}}, {{file|SOURCES}}, {{file|SPECS}}, {{file|SRPMS}} вам необходимо создать вручную, подкаталоги каталога {{file|RPMS}} должны создаться автоматически во время сборки в зависимости от архитектуры.<br />
<br />
В РОСЕ не принято писать сборщика пакета и вендора в spec-файлах; эти значения выставляются автоматически системой сборки ABF. Также ABF автоматически подписывает собранные пакеты ключом соответствующего репозитория. Поэтому эти вопросы мы здесь затрагивать не будем.<br />
<br />
<br />
Теперь давайте посмотрим что из себя представляет самый главный файл rpm-пакета, spec-файл. Для примера возьмём его из пакета {{pkg|stardict}}. Этот пакет хорошо подходит для обучения, так как в нем есть несколько тарболов (исходник программы, упакованный {{cmd|tar}}’ом), получается несколько пакетов и есть такая вещь, как схемы. Обычно spec-файл имеет такое же имя, как и сам пакет ({{file|stardict.spec}}). Однако вы можете добавить версию пакета ({{file|stardict-2.spec}}), удобно если вы пытаетесь поддерживать несколько веток программ. Можно даже дать какое-нибудь другое название, однако это мягко говоря не удобно.<br />
<br />
Итак, содержимое файла {{file|stardict.spec}} приведено ниже. Мы сразу будем вставлять комментарии после определенных секций, но если вы соедините все блоки в один и тот же файл, то получите полноценный {{file|stardict.spec}}.<br />
<br />
Spec-файл состоит из секций и шапки:<br />
<br />
Summary: StarDict dictionary<br />
Name: stardict<br />
Version: 2.4.8<br />
Release: 4<br />
License: GPL<br />
URL: http://stardict.sourceforge.net<br />
Group: User Interface/Desktops<br />
Source0: %{name}-%{version}.tar.bz2<br />
Source1: %{name}-tools-%{version}.tar.bz2<br />
Patch0: %{name}-2.4.8-desktop.patch<br />
<br />
'''Summary''' — краткое описание пакета, '''Name''' — название, '''Version''' — версия, '''Release''' — релиз. Последним трем тегам соответствуют макроопределения {{macro|%{name} }}, {{macro|%{version} }}, {{macro|%{release} }}. Их часто используют в дальнейшем. '''Name''' и '''Version''' обычно совпадает с название тарбола. Если же они отличаются, то в принципе ничего страшного, но придётся в некоторых местах spec-файла действовать нестандартными методами. Если вы собираете пакет из cvs, svn и т. д., то рекомендуется в самом начале файла сделать макроопределение {{macro|%define date 20070422}} (именно в таком формате, сами догадайтесь почему) и тег Release определить следующим образом:<br />
<br />
Release: 0.git%{date}.4<br />
<br />
Далее, '''License''' — лицензия, под которой распространяется программа (обычно указано в самом пакете). Раньше в ходу был также тег '''Copyright''', но сейчас он не используется. '''URL''' — сайт программы, '''Group''' — группа, в которую будет входить данный пакет. Обычно следует прикинуть на что этот пакет похож, и посмотреть группу похожего пакета. Придумывать группу самому не стоит, лучше посмотреть в [http://wiki.rosalab.ru/en/index.php/Packaging_group список имеющихся].<br />
<br />
'''Source*''' — исходные тексты, тарболы, просто файлы. В данном примере идут два тарбола с разными программами, что делает сборку намного сложнее. Обычные файлы, например, конфигурации, могут просто копироваться в секции %{{macro|%install}} при помощи команды {{cmd|install}}. У нее простой синтаксис, {{cmd|install -m маска_как_у_chmod что куда}}. При помощи нее можно также создавать каталоги. В нашем примере она не используется, но подробнее про неё можно почитать в man.<br />
<br />
'''Patch''' — патчи, исправления, которые вы или кто-то другой выпустили для данного пакета. Не принято изменять исходный текст самой программы, а затем завертывать ее в тарбол. Принято накладывать заплатки. Делать их можно следующим образом. Распаковываете исходный тарбол, у нас это будет stardict-2.4.8, далее копируете stardict-2.4.8 в stardict-2.4.8.orig. После этого изменяете код в каталоге stardict-2.4.8, выходите из него и отдаете команду diff -ur stardict-2.4.8.orig stardict-2.4.8 > stardict-2.4.8-название_патча.patch. Как видно, до навания патча идёт {{file|%{name}-%{version} }} пакета. В самом spec-файле обязательно следует писать название патча без макроопределений. По крайней мере версию, точно. Иначе при обновлении версии пакета, у вас и обновится версия патча, определённая макросом {{macro|%{version} }}, а патч может быть подойдёт к новой версии программы и без каких либо изменений. Если же во время самой сборки патч не смог наложиться, то его следует либо переделать под данную версию программы, либо отключить в секции {{macro|%setup }}.<br />
<br />
В spec-файлах пакетов многих дистрибутивов вы также можете в заголовке встретить определение {{macro|BuildRoot}} - каталога, в котором осуществляется сборка. В РОСЕ в этом определении нет необходимости, имя BuildRoot формируется автоматически.<br />
<br />
BuildRequires: libgnomeui-devel >= 2.2.0<br />
BuildRequires: scrollkeeper<br />
BuildRequires: gettext<br />
<br />
Requires(post): GConf2<br />
Requires(post): scrollkeeper<br />
Requires(postun): scrollkeeper<br />
<br />
{{macro|BuildRequires}} — секция, в которую через запятую или через пробел прописываются пакеты, которые требуются для сборки нашей программы. Почерпнуть их можно из каких-нибудь файлов README и INSTALL (хотя там редко бывает что-то полезное по этому поводу), из процесса конфигурации (на данный момент обычно это скрипт {{cmd|configure}}) и из самого процесса сборки (иногда configure что-нибудь пропустит и сборка остановится).<br />
<br />
{{macro|Requires}} — в эту секцию записываются пакеты или файлы(!), которые будет требовать данный пакет при установке. При сборке в зависимости автоматически пропишутся все библиотеки, которые наш пакет потребует, но вы также можете указать пакеты вручную. {{Программа|Rpm}} также автоматически прописывает зависимости perl, python, mono и некоторые другие (все эти зависимости прописываются не в spec-файл разумеется, а в сам пакет). Если вам не нужно, чтобы зависимости прописывались автоматически, следует прописать в spec-файл новый тег AutoReq: no. Обычно его прописывают при сборки проприетарных программ, так как {{Программа|rpm}} добавляет внутренние зависимости из собираемой программы.<br />
<br />
В нашем примере используются конструкции {{macro|Requires(post)}} и {{macro|Requires(postun)}} для зависимостей в скриптах установки и удаления. В принципе достаточно и простого {{macro|Requires}}. Здесь особенно нечего комментировать. Просто самому StarDict в процессе работы эти зависимости не нужны. Нужны они только при инсталляции и удалении.<br />
<br />
Есть ещё несколько полезных тегов, которые здесь не используются.<br />
<br />
Provides: название1, название2<br />
<br />
- другие названия, помимо {{macro|%{name} }}, на которые будет откликаться данный пакет. Удобно указывать, если вы сменили название пакета, а другие пакеты продолжают зависеть от старого названия.<br />
<br />
Obsoletes: название1, название2<br />
<br />
— удаление указанных пакетов при установки текущего пакета. Как бы говорится, что данный пакет замещает собой указанные (по функциональности, по набору файлов и т. п.). Можно использовать конструкцию {{macro|название <|>|<=|=|=> версия}}. Тут вы должны сами понимать, что к чему.<br />
<br />
Conflicts: название1, название2<br />
<br />
— перечисляются пакеты, которые конфликтуют с текущим. Подразумевается что указанные пакеты нужно вручную удалить, перед установкой нашего. Также используются конструкции со знаками сравнения и версиями (см. выше).<br />
<br />
Suggests: название1, название2<br />
<br />
- ''мягкие'' зависимости - пакеты, которые добавляют данному пакету дополнительную функциональность (например, кодеки для медиапроигрывателя), но без которых можно обойтись.<br />
<br />
Epoch: число<br />
<br />
— обычно или не указывается совсем или равняется 0. Суть этого параметра вот в чем. Пусть всё наш же пакет {{pkg|stardict}} имеет версию '''2.4.8''', а также есть более старый '''2.4.5'''. Так вот если {{macro|%{epoch} }} у {{pkg|stardict 2.4.5}} будет '''1''', а у {{pkg|2.4.8}} - '''0''', то пакет {{pkg|2.4.5}} будет всегда новее, чем {{pkg|2.4.8}}. О чём при установки вам {{Программа|RPM}} и скажет. Этот параметр удобен, если вы хотите откатиться на предыдущую версию (разумеется, если вы это все выкладываете в публичный репозиторий и хватаете все через {{Программа|urpmi}} или {{Программа|rpmdrake}}. Для «домашних» нужд подойдёт параметр к {{cmd|rpm --force}}). Если определён тег {{macro|Epoch: 0}}, то пакет будет иметь приоритет перед пакетом с непоределённым тегом {{macro|Epoch}}.<br />
<br />
BuildArch: архитектура<br />
<br />
— архитектура, под которую будет собираться наш пакет. Если эта опция не указана, то пакет соберётся под текущую архитектуру. Обычно эту опцию указывают для того, чтобы собирать пакет архитектуры '''noarch''', то есть пакет, в котором нет бинарников.<br />
<br />
ExclusiveArch: архитектура1 архитектура2<br />
<br />
— архитектуры, под которые данный пакет может быть собран. Обычно используется при сборки модулей к ядру.<br />
<br />
На этом шапка заканчивается и начинаются отдельные секции.<br />
<br />
%description<br />
StarDict is an international dictionary written for the GNOME environment.<br />
It has powerful features such as "Glob-style pattern matching," "Scan<br />
seletion word," "Fuzzy search," etc.<br />
<br />
Описание главного пакета, того, у которого будет имя {{macro|%{name} }}<br />
<br />
%package tools<br />
Summary: StarDict-Editor<br />
Requires: %{name} = %{version}-%{release}<br />
Group: User Interface/Desktops<br />
<br />
Здесь мы создаём новый пакет, название которого будет {{pkg|%{name}-tools}}. Если нужно обозвать пакет совсем по другому, то следует сделать, например, так: {{macro|%package -n tools-stardict}}. Версия нового пакета берётся из заданного тега {{macro|Version}}. Обратите внимание на {{macro|Requires}}. В нём прописана зависимость на главный пакет {{pkg|stardict}}. Если бы он имел {{macro|%{epoch} }}, то необходимо было бы обязательно указать {{macro|Requires: %{name}-%{epoch}:%{version}-%{release} }}. Иначе вам просто не удастся установить это пакет.<br />
<br />
%description tools<br />
A simple tool for StarDict.<br />
<br />
Описание второго пакета<br />
<br />
%prep<br />
%setup -q -a1<br />
%patch0 -p1<br />
<br />
Секция {{macro|%prep}} в ней начинается подготовка к сборке. {{macro|%setup}} распаковывает исходники. Опция '''-q''' не показывает вывод распаковывания архива. Опция '''-a1''' используется для распаковки {{macro|%{SOURCE1} }}, второго тарбола внутрь(!) каталога первого тарбола. Соответственно цифра указывает на номер SOURCE. Ещё иногда используется параметр '''-b''', тогда второй тарбол распаковывается в тот же каталог, что и первый. Соответственно если у нас один тарбол, то опции '''-a''', '''-b''' не используются.<br />
<br />
Если у вас первый каталог в тарболе имеет отличное от {{file|%{name}-%{version} }} название, то {{Программа|rpm}} не сможет войти автоматом в этот каталог. В таком случае следует немного изменить {{macro|%setup}}. Если в архиве {{file|stardict-2.4.8.tar.bz2}} первый каталог имеет название, например, просто {{file|stardict}}, то выглядеть это будет так:<br />
<br />
%setup -q -n %{name} -a1<br />
<br />
Сразу после распаковки пакета, перед {{macro|%patch}}, если нужно, можно скопировать файлы, или запустить какие либо программы для изменения исходников. Допустим скопировать файл русификации, или подправить sed’ом какой-нибудь исходник. Просто вызываете здесь {{cmd|cp}}, {{cmd|sed}} или ещё что-то. В качестве корня здесь выступает каталог, в который распаковался первый тарболл (за него отвечает переменная $RPM_BUILD_DIR, но она крайне редко используется).<br />
<br />
При помощи {{macro|%patch}} накладываются патчи. Если вы делали патч, как мы писали выше, то у вас всегда будет параметр '''-p1'''. Также часто используют параметр {{cmd|-b .название_патча}}, для создания резервной копии.<br />
<br />
%build<br />
pushd %{name}-tools-%{version}<br />
%configure<br />
%make<br />
popd<br />
<br />
%configure<br />
%make<br />
<br />
Секция {{macro|%build}}, именно здесь происходит сборка пакета. Обратите внимание на {{cmd|pushd}} и {{cmd|popd}}. Этими командами мы переходим и выходим из каталога второго тарбола. Именно он будет корневым каталогом после {{cmd|pushd}}. После команды {{cmd|popd}} мы вернёмся в каталог первого тарбола. Соответственно если у вас один исходник, то не нужно использовать эти команды.<br />
<br />
Так как у нас две программы в одном пакете, то мы выполняем два раза концигурацию {{macro|%configure}} и два раза {{macro|make}}. Если пакет конфигурируется при помощи {{Программа|autotools}}, то макросом {{macro|%configure}} запускается скрипт {{cmd|configure}} из корня распакованного тарбола. У него обычно бывает много параметров, их можно посмотреть из командной строки при помощи {{cmd|./configure --help}}. После {{macro|%configure}} вы можете указать нужные вам параметры. Заметьте, что вызов {{macro|%configure}} и {{cmd|./configure}} отличаются. В первом случае конфигуратору будут переданы правильные каталоги для инсталляции (а также стандартные параметры), во втором - каталоги по умолчанию.<br />
<br />
После успешной конфигурации идет сборка, а именно макрос {{macro|%make}}, вызывающий одноименную команду с некоторыми дополнтельными параметрами (в частности, на многопроцессорных машинах используется параллельная сборка - опиця '''-j''').<br />
<br />
Если пакет не использует {{Программа|autotools}}, то {{macro|%configure}}, а может и {{macro|%make}} использовтаь не нужно, для сборки прочтите файл README и INSTALL. В РОСЕ есть макросы и на другие случаи жизни - например, {{macro|%cmake}} для одноименного инструмента сборки.<br />
<br />
Когда сборка успешна закончена, в действие вступает секция {{macro|%install}}.<br />
<br />
%install<br />
pushd %{name}-tools-%{version}<br />
%makeinstall_std<br />
popd<br />
<br />
%makeinstall_std<br />
<br />
%find_lang %{name}<br />
<br />
%{{macro|%find_lang}}, поиск файлов локализации. Параметром у неё является название файлов, которые будут лежать после установки в каталоге {{file|%{buildroot}/usr/share/locale/*/LC_MESSAGES/*.mo}}. Обычно оно соответствует {{macro|%{name} }}. Если это не так, пишите другое имя.<br />
<br />
<br />
Во многих spec-файлах вы можете заметить выполнение команды {{cmd|rm -rf %{buildroot} }} или {{cmd|rm -rf $RPM_BUILD_ROOT}} в самом начале секции {{macro|%install}}, а также секцию {{macro|%clean}} с такими же строками. В современной РОСЕ в этом нет необходимости, такая зачистка выполняется автоматически.<br />
<br />
%preun<br />
%preun_uninstall_gconf_schemas %{name}<br />
<br />
Секции для установочных скриптов. Вообще их бывает несколько. {{macro|%pre}} — выполняется перед установкой, {{macro|%post}} — после установки, {{macro|%preun}} — перед удалением, {{macro|%postun}} — после удаления. В нашем примере при удалении удаляются схемы Gconf. Здесь мы предполагаем, что в пакете только одна схема и ее имя совпадает с именем пакета. Обратите внимание, что для удаления схем мы вызываем специальный макрос; этот макрос раскрывается rpmbuild РОСЫ в набор необходимых команд оболочки Shell, которые, собственно, и удаляют схему. Установка схем при установке пакета выполняется автоматически за счет [[Файловые_триггеры_RPM|файловых триггеров RPM]].<br />
<br />
Для каждого пакета могут быть свои скрипты, поэтому следует также почитать документацию. Если никаких скриптов для правильной работы не нужно, то и секции эти не следует использовать. В этих секциях можно применять bash-скрипты (впрочем как и в любых других секциях).<br />
<br />
В секциях {{macro|%files}} мы должны указать какие файлы должны быть упакованы в пакеты. Все файлы должны быть оговорены, в противном случае {{cmd|rpmbuild}} выдаст сообщение о неупакованных файлах.<br />
<br />
Опцией '''-f''' указываются файл, содержащий список обрабатываемых файлов. В нашем случае этот файл содержит пути к файлам локализации. Вы в принципе можете создать свой файл и подсунуть его.<br />
<br />
Для определения каталогов используются специальные макроопределения.<br />
<br />
* {{macro|%{_prefix} }} — {{file|/usr}}<br />
* {{macro|%{_sysconfdir} }} — {{file|/etc}}<br />
* {{macro|%{_bindir} }} — {{file|/usr/bin}}<br />
* {{macro|%{_datadir} }} — {{file|/usr/share}}<br />
* {{macro|%{_libdir} }} — {{file|/usr/lib}} или {{file|/usr/lib64}} в зависимости от разрядности системы<br />
* {{macro|%{_lib} }} — соответственно {{file|/lib}} или {{file|/lib64}}<br />
* {{macro|%{_libexecdir} }} — {{file|/usr/libexec}}<br />
* {{macro|%{_includedir} }} — /{{file|usr/unclude}}<br />
* {{macro|%{_mandir} }} — {{file|/usr/share/man}}<br />
* {{macro|%{_sbindir} }} — {{file|/usr/sbin}}<br />
* {{macro|%{_localstatedir} }} — {{file|/var}}.<br />
* {{macro|%{systemd_libdir} }} — {{file|/usr/lib/systemd}}<br />
<br />
%files -f %{name}.lang<br />
%defattr(-, root, root)<br />
%doc AUTHORS COPYING INSTALL README NEWS<br />
%{_sysconfdir}/gconf/schemas/stardict.schemas<br />
%{_bindir}/stardict<br />
%{_bindir}/stardict-editor<br />
%{_libdir}/bonobo/servers/GNOME_Stardict.server<br />
%{_datadir}/applications/*.desktop<br />
%{_datadir}/stardict<br />
%{_datadir}/locale/*/LC_MESSAGES/*<br />
%{_datadir}/pixmaps/stardict.png<br />
%{_datadir}/gnome/help/%{name}/*<br />
%{_datadir}/idl/GNOME_Stardict.idl<br />
%{_datadir}/omf/*<br />
%doc %{_mandir}/man?/*<br />
<br />
{{macro|%doc}} помечает файлы как документацию. Третья строка копирует указанные файлы в каталог {{file|%{_datadir}/doc/%{name}-%{version} }}. По умолчанию файлы в rpm пакете будут иметь владельцем root’а, а права доступа у низ будут такие же, как и в процессе установки. Если это необходимо поменять, то воспользуйтсь конструкцией {{macro|%defattr}}.<br />
<br />
Далее просто перечисляются файлы.<br />
<br />
%files tools<br />
%{_bindir}/stardict-editor<br />
<br />
Тоже самое для пакета {{pkg|stardict-tools}}. Если бы он назывался {{pkg|tools-stardict}}, то {{macro|%files}} выглядел бы так:<br />
<br />
%files -n tools-%{name}.<br />
<br />
Последнее, что идёт в spec-файле, это {{macro|%changelog}}. В changelog’е вы указывает изменения в пакете по сравнению с предыдущей версией. Синтаксис его примерно следующий.<br />
<br />
%changelog<br />
* Sun Apr 22 2007 Your Name <your@email> - 2.4.8-4<br />
- update desktop patch<br />
<br />
== Макроопределения ==<br />
<br />
Теперь пора познакомиться поближе с макросами и переменными. Допустим, мы собираем пакет из SVN, в данном случае в релиз обычно включается дата ревизии. В самом начале spec-файла нужно определить переменную date:<br />
<br />
%define date 20070612<br />
<br />
Как мы видим, за определение переменных отвечает макроопределение {{macro|%define}}. Теперь в любом месте spec-файла мы можем использовать нашу переменную в виде {{macro|%{date} }} (скобки не обязательны, но в РОСЕ принято брать в скобки переменные, и не брать - макроопределения; так их проще различать). Например, определение основных параметров будет выглядеть примерно так:<br />
<br />
Version: 0.5<br />
Release: 0.svn%{date}.3<br />
<br />
Обратите внимание, что перед датой стоит '''0.''', а после даты - число, которое и увеличивается при необходимости поднять релиз. Зачем так сделано? Когда наконец выйдет окончательная версия (в нашем случае - '''0.5'''), ревизию можно будет убрать, а в релиз прописать просто '''1'''. При этом литерально '''1''' больше, чем любая строка, начинающаяся на '''0''', и пакет будет считаться более новым, чем предварительные пакеты, собиравшиеся на основе ревизий SVN.<br />
<br />
Крайне популярным макроопределением является конструкция<br />
<br />
%if условие<br />
действие1<br />
%else<br />
действие2<br />
%endif<br />
<br />
или просто {{macro|%if}} без {{macro|%else}}. Суть проста, если условие стоящее при {{macro|%if}} истина, то выполняется {{cmd|действие1}}, в противном случае выполняется {{cmd|действие2}}.<br />
<br />
Допустим, мы опять же собираем что-нибудь из SVN. Обычно внутри архива, если он из SVN, вместо каталога {{macro|%{name}-%{version} }} указывают просто {{macro|%{name} }} (архив {{file|sim-0.9.5.tar.bz2}} внутри имеет каталог {{file|sim}}, так как финального релиза sim 0.9.5 не существует. Конечный же релиз будет иметь первым каталогом {{file|sim-0.9.5}}). Чтобы всякий раз не переписывать spec-файл, можно сделать следующие макроопределения:<br />
<br />
%define svn 1<br />
...<br />
%prep<br />
%if %{svn}<br />
%setup -q -n %{name}<br />
%else<br />
%setup -q<br />
%endif<br />
<br />
Если переменная svn не определена, то будет выполняться часть сценария после {{macro|%else}}. Можно также использовать более строгое условие (не забудьте про кавычки):<br />
<br />
%define svn 1<br />
...<br />
%prep<br />
%if "%{svn}" == "1"<br />
%setup -q -n %{name}<br />
%else<br />
%setup -q<br />
%endif<br />
<br />
Внутри всех секций spec-файла мы можем использовать любые команды Linux, без каких либо «наворотов», а вот в шапке файла не всё так просто. Например, нам нужно определить версию firefox для пакета (допустим epiphany) и прописать ее в секцию {{macro|Requires:}}. Выглядеть это будет следующим образом:<br />
<br />
Requires: firefox = %(rpm -q firefox --qf "%%{version}")<br />
<br />
Обратите внимание на то, что внешняя команда выполняется в {{cmd|%()}} (почти, как в bash - {{cmd|$()}}) и в spec-файле необходимо ставить два знака % в параметрах. Таким образом можно вызывать любые команды Linux, например, для определения версии ядра.<br />
<br />
Ещё одним популярным макроопределение является конструкция {{macro|%ifarch}} .. {{macro|%endif}}. Если архитектура соответствует указанной после {{macro|%ifarch}}, то выполняется какое либо действие. Архитектуры бывают i386, i486, i586, i686, i?86, x86_64, и понятное дело некоторые другие, с которыми вы наверно не столкнётесь.<br />
<br />
Как уже отмечалось выше во всех секциях spec-файла вы можете использовать любые команды Shell, включая for, while, if и др.<br />
<br />
== Сборка пакета ==<br />
<br />
Теперь перейдём непосредственно к сборке пакета. Исходники и патчи должны лежать в каталоге {{file|SOURCES}}, а spec файл в каталог {{file|SPECS}}. После этого нужно отдать команду:<br />
<br />
rpmbuild -ba spec-файл<br />
<br />
После этого пакет соберётся (или не соберётся, а вывалится с ошибками), и в подкаталогах каталога {{file|RPMS}} появятся бинарные пакеты, а в каталоге {{file|SRPMS}} появится исходник.<br />
<br />
Очень часто, перед самым завершением сборки, {{cmd|rpmbuild}} выдаёт сообщение о найденных, но неупакованных файлах. Это означает, что вы просто не указали их в секции {{macro|%files}}. Необходимо просто<br />
добавить их туда. Если же вы не хотите чтобы эти файлы попадали в пакет, то можно воспользоваться одним из следующих способов:<br />
<br />
* Добавить в секцию {{macro|%files}} макроопределение<br />
%exclude путь_к_файлу/файл<br />
* Добавить в начало spec-файла макроопределение<br />
%define _unpackaged_files_terminate_build 0<br />
<br />
Если необходимо собрать только бинарник или только исходник, то вместо '''-ba''' следует использовать '''-bb''' и '''-bs''' соответственно. Из полезных параметров {{cmd|rpmbuild}} можно отметить '''-clean''' (удалить весь мусор), '''-rmsource''' (удалить исходники из каталога {{file|SOURCE}}) и '''-target=архитектура''' (собрать пакет под конкретную архитектуру).<br />
<br />
Можно также выполнять сценарии только в определённой секции. Описывать подобные параметры мы здесь не будем, см. '''man rpmbuild'''.<br />
<br />
<br />
== Сборка RPM пакета из уже установленного в системе ==<br />
<br />
Иногда случается ситуация, что какой-то пакет уже установлен в системе (может быть в очень старой системе) и очень хочется получить rpm’ку с ним, а она как раз и не сохранилась. Также может захотеться собрать по быстрому пакет с изменёнными под ваши нужды конфигурационными файлами.<br />
<br />
Для решения этой проблемы следует воспользоваться утилитой rpmrebuild. Эта написанная на bash утилита доступна в contrib-репозитории РОСЫ.<br />
<br />
Работать с ней крайне просто. Нужно отдать всего лишь команду:<br />
<br />
rpmrebuild название_установленного_пакета<br />
<br />
Если какой-либо файл был изменён, то вам об этом сообщат, но процесс сборки не прервётся.<br />
<br />
{{Программа|Rpmrebuild}} обладает огромным количеством параметров, например, вы можете изменять release пакета, changelog, скрипты, секции Requires, описания пакета и многое другое. Можете даже просто напросто изменить spec-файл, который скрипт сгенерирует сам. Он правда будет немного страшный, но это все же лучше, чем ничего.<br />
<br />
Все параметры можно посмотреть при помощи<br />
<br />
rpmrebuild --help<br />
<br />
и<br />
<br />
rpmrebuild --help-plugins<br />
<br />
== См. также ==<br />
[[Основы RPM]]<br />
<br />
[[:Категория: Packaging Guidelines|Создание пакетов ROSA]]<br />
<br />
<br />
{{Сообщение|title=Примечание|msg=Эта страница основана на заметках из блога "Записки о Linux":<br />
* [http://tigro.info/wp/?p=270 Сборка пакетов. Глава 1. RPM. Часть 1. Какие RPM-пакеты бывают, и где их искать]<br />
* [http://tigro.info/wp/?p=287 Сборка пакетов. Глава 1. RPM. Часть 2. Подготовка к сборке и обзор spec-файла]<br />
* [http://tigro.info/wp/?p=316 Сборка пакетов. Глава 1. RPM. Часть 3. Макроопределения и сборка пакетов]<br />
|img=Idea.png}}<br />
<br />
[[Категория:Управление пакетами]]<br />
[[Категория:Packaging Guidelines]]<br />
[[Категория:Инструменты_разработки]]<br />
<br />
[[En:Building RPMs - Quick Start]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%98%D0%BC%D0%BF%D0%BE%D1%80%D1%82_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B8%D0%B7_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_%D0%B4%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%D0%BE%D0%B2&diff=18320Импорт пакетов из других дистрибутивов2019-08-19T14:18:22Z<p>D uragan: + spec-cleaner</p>
<hr />
<div>Нередко возникает необходимость собрать в репозитории РОСЫ новые программы, для которых spec-файл не может быть подготовлен автоматически (как в случае модулей Perl, Python и прочего) или хотя бы на основе шаблона.<br />
<br />
В некоторых случаях пригодится утилита [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Spec-gen_-_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D1%83%D0%B5%D0%BC_spec-%D1%84%D0%B0%D0%B9%D0%BB%D1%8B_%D0%B4%D0%BB%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC_%D0%BD%D0%B0_GNU_Autotools_%D0%B8_CMake spec-gen], однако она далека от идеала.<br />
<br />
Однако есть путь проще - возможно, кто-то уже собрал RPM-пакет под другой дистрибутив, и можно позаимствовать spec-файл оттуда. Посмотреть - в каких дистрибутивах уже есть пакет с нужной программой, можно на порталах наподобие [https://pkgs.org Pkgs.org]. Если нужный пакет нашелся, то надо скачать соответствующий src.rpm и установить его в систему:<br />
<br />
$ rpm -i my_program.src.rpm<br />
<br />
При этом spec-файл установится в директорию {{File|~/rpmbuild/SPECS}}, архив с исходным кодом и патчи - в {{File|~/rpmbuild/SOURCES}}.<br />
<br />
Если пакет нашелся в нескольких дистрибутивах, то стоит выбирать наиболее близкие к РОСЕ - OpenMandriva, Mageia или PCLinuxOS. Если в этих системах пакета не нашлось, то можно попробовать RPM для Fedora, и уже совсем в крайнем случае - от SUSE.<br />
<br />
Первым делом, spec-файл от другого дистрибутива необходимо обработать утилитой {{Prog|spec-cleaner}}, которая подправит некоторые известные расхождения с РОСОЙ:<br />
<br />
$ spec-cleaner ~/rpmbuild/SPECS/my_program.spec<br />
<br />
После чего попробовать установить зависимости сборки:<br />
<br />
$ urpmi ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Вполне вероятно, что {{Prog|urpmi}} скажет, что некоторые зависимости не могут быть установлены. В большинстве случаев это происходит из-за разницы в названиях пакетов с одними и теми же программами в разных дистрибутивах и вам надо посмотреть, на что необходимо заменить проблемную запись BuildRequires в spec-файле. Впрочем, возможно некоторых программ еще нет в репозиториях РОСЫ и необходимо сначала собрать их.<br />
<br />
Как только зависимости сборки установлены, можно попробовать собрать пакет, предварительно обработав spec-файл утилитой {{Prog|spec-cleaner}}:<br />
<br />
$ spec-cleaner ~/rpmbuild/SPECS/my_program.spec<br />
$ rpmbuild -bb ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Если при сборки возникли ошибки, то можно проконсультироваться со страничкой [http://wiki.rosalab.ru/ru/index.php/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM часто встречающихся ошибок]. <br />
<br />
Если программа собралась успешно, то результаты сборки можно найти в директории {{File|~/rpmbuild/RPMS}}. Установите собравшиеся пакеты, убедитесь в их работоспособности и собирайте src.rpm:<br />
<br />
$ rpmbuild -bs ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Результатом работы этой программы будем пакет {{File|~/rpmbuild/SRPMS/my_program.src.rpm}}, из которого надо [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F создавать проект на ABF]<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2019.1 (последней на момент написания этой странички, если есть платформа поновее типа rosa2019.1 - то надо выбирать ее).<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%98%D0%BC%D0%BF%D0%BE%D1%80%D1%82_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B8%D0%B7_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_%D0%B4%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%D0%BE%D0%B2&diff=18282Импорт пакетов из других дистрибутивов2019-07-03T10:04:36Z<p>D uragan: Now we use 2019.1 branch</p>
<hr />
<div>Нередко возникает необходимость собрать в репозитории РОСЫ новые программы, для которых spec-файл не может быть подготовлен автоматически (как в случае модулей Perl, Python и прочего) или хотя бы на основе шаблона.<br />
<br />
В некоторых случаях пригодится утилита [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Spec-gen_-_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D1%83%D0%B5%D0%BC_spec-%D1%84%D0%B0%D0%B9%D0%BB%D1%8B_%D0%B4%D0%BB%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC_%D0%BD%D0%B0_GNU_Autotools_%D0%B8_CMake spec-gen], однако она далека от идеала.<br />
<br />
Однако есть путь проще - возможно, кто-то уже собрал RPM-пакет под другой дистрибутив, и можно позаимствовать spec-файл оттуда. Посмотреть - в каких дистрибутивах уже есть пакет с нужной программой, можно на порталах наподобие [https://pkgs.org Pkgs.org]. Если нужный пакет нашелся, то надо скачать соответствующий src.rpm и установить его в систему:<br />
<br />
$ rpm -i my_program.src.rpm<br />
<br />
При этом spec-файл установится в директорию {{File|~/rpmbuild/SPECS}}, архив с исходным кодом и патчи - в {{File|~/rpmbuild/SOURCES}}.<br />
<br />
Если пакет нашелся в нескольких дистрибутивах, то стоит выбирать наиболее близкие к РОСЕ - OpenMandriva, Mageia или PCLinuxOS. Если в этих системах пакета не нашлось, то можно попробовать RPM для Fedora, и уже совсем в крайнем случае - от SUSE.<br />
<br />
Первым делом, spec-файл от другого дистрибутива необходимо обработать утилитой {{Prog|spec-cleaner}}, которая подправит некоторые известные расхождения с РОСОЙ:<br />
<br />
$ spec-cleaner ~/rpmbuild/SPECS/my_program.spec<br />
<br />
После чего попробовать установить зависимости сборки:<br />
<br />
$ urpmi ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Вполне вероятно, что {{Prog|urpmi}} скажет, что некоторые зависимости не могут быть установлены. В большинстве случаев это происходит из-за разницы в названиях пакетов с одними и теми же программами в разных дистрибутивах и вам надо посмотреть, на что необходимо заменить проблемную запись BuildRequires в spec-файле. Впрочем, возможно некоторых программ еще нет в репозиториях РОСЫ и необходимо сначала собрать их.<br />
<br />
Как только зависимости сборки установлены, можно попробовать собрать пакет:<br />
<br />
$ rpmbuild -bb ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Если при сборки возникли ошибки, то можно проконсультироваться со страничкой [http://wiki.rosalab.ru/ru/index.php/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM часто встречающихся ошибок]. <br />
<br />
Если программа собралась успешно, то результаты сборки можно найти в директории {{File|~/rpmbuild/RPMS}}. Установите собравшиеся пакеты, убедитесь в их работоспособности и собирайте src.rpm:<br />
<br />
$ rpmbuild -bs ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Результатом работы этой программы будем пакет {{File|~/rpmbuild/SRPMS/my_program.src.rpm}}, из которого надо [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F создавать проект на ABF]<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2019.1 (последней на момент написания этой странички, если есть платформа поновее типа rosa2019.1 - то надо выбирать ее).<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95&diff=18281Обновление пакетов в РОСЕ2019-07-03T10:04:16Z<p>D uragan: Now we use 2019.1 branch</p>
<hr />
<div>Репозитории РОСЫ содержат тысячи различных пакетов, которые необходимо обновлять по мере выхода новых версий соответствующих программ. Несмотря на [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Updates_builder_-_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%82%D1%81%D0%BB%D0%B5%D0%B6%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_ABF различные средства автоматизации], для обновления многих пакетов требуется участие человека.<br />
<br />
Самый простой сценарий обновления заданного пакета [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%22%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%22-Howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95 описан в блоге "Точка РОСЫ"]. Однако он рассчитан на людей, которые не знакомы даже с Git и только могут кликать различные иконки в веб-браузере. От студентов, проходящих у нас практику, мы ожидаем несоклько большего и даем им более сложные пакеты, для обновления которых могут потребоваться более серьезные усилия.<br />
<br />
Если обновление по приведенной выше инструкции не проходит, то необходимо склонировать себе проект в машину с РОСОЙ:<br />
<br />
$ abf get <your_abf_login>/<project_name> -b rosa2019.1<br />
<br />
Переходим в директорию <project_name>, кладем в нее архив с исходным кодом новой версии и изменяем внутри файла <project_name>.spec значение тэга Version (если еще не сделали это в веб-интерфейсе).<br />
<br />
Теперь получившийся пакет надо собрать. Для этого сначала надо установить пакеты, которые требуются для его сборки (прописаны в BuildRequires). Для этого внутри директории <project_name> выполняем команду:<br />
<br />
$ urpmi <project_name>.spec<br />
<br />
И запускаем саму сборку с помощью {{Prog|rpmbuild}}:<br />
<br />
$ rpmbuild -bb <project_name>.spec<br />
<br />
если повезет и все соберется сразу, то в этой же директории даем команду отправить все на ABF:<br />
<br />
$ abf put -m «Updated to a new version»<br />
<br />
После чего идем в веб-интерфейс на страничку проекта в своем репозитории и делаем Pull Request в соответствующий проект группы import. Не забывайте выбирать ветку «rosa2019.1»!<br />
<br />
Также не забываем проверять работоспособность результата — для этого необходимо установить собранные пакеты в систему и убедиться, что они работают. Если вы собрали библиотеку/модуль, вам нужно проверить приложение, его использующее. Определить список всех пакетов, использующих данный, можно с помощью команды<br />
<br />
$ urpmq --whatrequires <package_name><br />
<br />
Если есть сомнения в работоспособности пакета или непонятно, как его проверить, то все равно шлите Pull Request. Только отдельно сообщите нам, что функционал новой версии проверить не удалось.<br />
<br />
Если в процессе сборки что-то пошло не так, то надо смотреть на ошибки — если идет ругань на то, что какие-то файлы не найдены (или наоборот, найдены неупакованные файлы), то надо править секцию %files в spec-файле. Могут быть жалобы на то, что не хватает каких-то программ для сборки; в этом случае надо постараться понять - каких именно, доустановить их в систему и прописать соответствующее поле BuildRequiers в spec-файле.<br />
<br />
В целом, ошибки могут быть самые разные, и далеко не со всеми из них можно быстро разобраться. Поэтому если за разумное время пакет собрать не удалось, лучше сообщить о встреченной проблеме разработчикам РОСЫ и перейти к следующему пакету. В качестве результатов работы нам важны как Pull Request'ы на обновление пакетов, которые обновились успешно, так и перечень пакетов, которые собрать не удалось, с описанием ошибок сборки. В последнем случае можно просто прислать журнал сборки для каждого пакета либо попробовать собрать пакет в своем персональном репозитории на ABF и дать нам ссылку на сборку.<br />
<br />
== Поиск новых версий ==<br />
<br />
Немаловажный аспект - определение того, какая версия программы является последней. Безусловно, можно просто обратиться к сайту разработчика, однако могут возникнуть нюансы:<br />
* в пакете может быть указан неверный URL сайта разработчика (хоть мы и [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%9E%D0%B1_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8_URL_%D0%B2_%D0%BC%D0%B5%D1%82%D0%B0%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_RPM-%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 призываем поддерживать ссылки в актуальном состоянии], они все-таки иногда протухают<br />
* самые свежие версии могут иметь проблемы со сборкой либо функционалом<br />
<br />
В подобных случаях полезно посмотреть на версию этой же программы, собранной в других дистрибутивах. Для этого можно воспользоваться нашей утилитой {{Prog|mib-report}} (необходимо в РОСЕ установить соответствующий пакет и запустить утилиту) либо сервисами наподобие [http://pkgs.org Pkgs.org] или [http://upstream.rosalinux.ru/updates/rosa/2014/ ROSA Upstream Tracker].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D1%81_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8F%D0%BC%D0%B8_Perl&diff=18280Сборка пакетов с модулями Perl2019-07-03T10:03:47Z<p>D uragan: Now we use 2019.1 branch</p>
<hr />
<div>В мире существует огромное множество модулей для языка Perl, большинство которых находится на сайте [http://www.cpan.org/ CPAN]. Чтобы упростить установку этих модуле в РОСЕ, они оформляются в виде пакетов rpm - в таком случае их можно поставить через стандартный менеджер пакетов.<br />
<br />
Для автоматического создания пакетов с модулями Perl используется утилита cpan2dist с бэкендом CPANPLUS-Dist-Mdv. Утилита сама находит и скачивает архив с исходным кодом, формирует spec-файл с инструкциями сборки и пытается собрать пакет.<br />
<br />
Перед запуском утилиты необходимо создать все требуемые ей директории:<br />
<br />
$ mkdir -p ~/rpmbuild/RPMS ~/rpmbuild/SOURCES ~/rpmbuild/SPECS ~/rpmbuild/SRPMS ~/rpmbuild/tmp<br />
<br />
Пакет для модуля Foo::Bar создается следующей командой:<br />
<br />
$ cpan2dist --format CPANPLUS::Dist::Mdv Foo::Bar<br />
<br />
Если повезет, то все соберется сразу и в результате у вас будет лежать собранный пакет, а также пакет src.rpm - {{File|~/rpmbuild/SRPMS/perl-Foo-Bar-<version>.src.rpm}}.<br />
<br />
Получившийся в результате пакет необходимо попробовать установить с помощью urpmi:<br />
<br />
$ urpmi --test ~/rpmbuild/RPMS/<pkg_arch>/perl-Foo-Bar-<version>.rpm<br />
<br />
Здесь <pkg_arch> может принимать значение i586, x86_64 или noarch – это зависит от архитектуры вашей системы и от того, помечен ли пакет как независимый от архитектуры (это определяется наличием конструкции "BuildArch: noarch" в spec-файле).<br />
Посмотрите на вывод rpmbuild – он выводит пути к собранным пакетам. Если {{Prog|urpmi}} сообщит, что не может установить зависимость типа '''perl(A::B)''', то вам нужно также озаботиться созданием пакета для модуля '''A::B'''. Для сборки нашего модуля он не нужен, но вот для его работы понадобится.<br />
<br />
Если все ok, то на основе пакета src.rpm ({{File|~/rpmbuild/SRPMS/perl-Foo-Bar-<version>.src.rpm}}) необходимо [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F сделать проект на ABF] в своем репозитории.<br />
<br />
Если вызов {{Prog|cpan2dist}} завершился с ошибкой, то необходимо с этой ошибкой разбираться. Типичная причина ошибки - необходимость для сборки других модулей, которых еще нет в репозиториях РОСЫ. В таком случае вы получите сообщение, что urpmi не смог установить зависимость типа '''perl(C::D)'''. В таком случае надо сначала создать пакет с модулем '''C::D''', установить его в систему и попробовать снова запустить {{Prog|cpan2dist}}.<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2019.1 (последней на момент написания этой странички, если есть платформа поновее - то надо выбирать ее).<br />
<br />
Более подробная информация о правилах оформления модулей Perl приведена на странице [[Perl policy]].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0_R&diff=18279Сборка пакетов-расширений для языка R2019-07-03T10:03:28Z<p>D uragan: Now we use 2019.1 branch</p>
<hr />
<div>'''R''' — язык программирования для статистической обработки данных и работы с графикой. Среда, в которой производится обработка, также называется '''R'''. Для этой среды существует множество вспомогательных расширений, реализующих дополнительные функции. Каждое такое расширение, не входящее в базовую поставку R, оформляется в РОСЕ как отдельный пакет.<br />
<br />
Пакеты создаются полуавтоматически скриптом {{Prog|R2spec}}, который необходимо запускать в установленной РОСЕ, имеющей доступ в интернет. Для получения скрипта необходимо установить пакет {{Pkg|R2spec}}. Все последующие действия необходимо выполнять в консоли/терминале.<br />
<br />
Пакет для расширения '''foo''' создается с помощью скрипта следующим образом:<br />
<br />
$ R2spec -p foo<br />
<br />
Скрипт ищет последнюю версию расширения foo в публичных репозиториях (в частности, в [https://cran.r-project.org/src/contrib/ CRAN]). В случае успеха архив с исходным кодом скачивается в директорию {{File|~/rpmbuild/SOURCES}}, а также создается spec-файл {{File|~/rpmbuild/SPECS/R-foo.spec}} с инструкциями для сборки rpm-пакета из этого кода. Этот файл надо передать утилите rpmbuild, чтобы она попробовала собрать пакет:<br />
<br />
$ rpmbuild -bb ~/rpmbuild/SPECS/R-foo.spec<br />
<br />
Если соберется сразу — отлично, можно делать src.rpm:<br />
<br />
$ rpmbuild -bs ~/rpmbuild/SPECS/R-foo.spec<br />
<br />
и затем [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F делать из него проект на ABF] в своем репозитории.<br />
<br />
Но обычно пакет сразу не собирается, и приходится либо дорабатывать spec-файл, либо сначала собирать дополнительные пакеты (необходимые для сборки данного). Поэтому заранее сложно сказать, сколько в итоге пакетов придется обработать.<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2019.1 (последней на момент написания этой странички, если есть платформа поновее - то надо выбирать ее).<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D1%81_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8F%D0%BC%D0%B8_Python&diff=18278Создание пакетов с модулями Python2019-07-03T10:03:07Z<p>D uragan: Now we use 2019.1 branch</p>
<hr />
<div>Подготовка пакета для модуля языка '''Python''' может быть осуществлена с помощью модуля {{Prog|bdist_rpm5}}. Этот способ подходит для модулей, собираемых с помощью {{Prog|setuptools}}. Определить, относится ли ваш модуль к этому виду, очень просто - достаточно посмотреть, есть ли в лиректории с его исходным кодом файл {{File|setup.py}}. Если есть, то переходим в директорию с исходным кодом модуля и запускаем следующую команду:<br />
<br />
$ python setup.py bdist_rpm5<br />
<br />
Как минимум, эта команда создаст spec-файл в поддиректории {{File|build/bdist.linux-x86_64/rpm/SPECS}} (либо {{File|build/bdist.linux-i686/rpm/SPECS}}, если у вас 32битная система).<br />
<br />
{{Prog|bdist_rpm5}} сразу же попробует собрать пакет с использованием этого файла, и если вам повезет и пакет действительно соберется, то в поддиректории {{File|build/bdist.linux-x86_64/rpm/RPMS}} вы обнаружите результаты сборки. В этом случае можно смело брать src.rpm файл из поддиректории {{File|build/bdist.linux-x86_64/rpm/SRPMS}} и [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F|создавать из него проект на ABF].<br />
<br />
Если же сборка пакета завершилась с ошибкой, то необходимо доработать spec-файл и уже самостоятельно попробовать собрать с его помощью пакет с помощью команды <br />
<br />
rpmbuild -bb <имя_spec_файла><br />
<br />
Как только пакет успешно соберется, создаем src.rpm с помощью {{Cmd|rpmbuild -bs}} и делаем из него проект на ABF.<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2019.1 (последней на момент написания этой странички, если есть платформа поновее - то надо выбирать ее).<br />
<br />
Более подробная информация о правилах оформления модулей Python приведена на странице [[Python policy]].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D1%81_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8F%D0%BC%D0%B8_Python3&diff=18277Создание пакетов с модулями Python32019-07-03T10:02:03Z<p>D uragan: Now we use 2019.1 branch</p>
<hr />
<div>'''Python3''' - современная линейка версий языка и интерпретатора Python, вот уже несколько лет усиленно вытесняющая Python2. Поскольку многие проекты все еще ориентируются на Python2, то для многих модулей Python в РОСЕ предусмотрено два варианта - для Python2 и Python3. Оформляются эти "варианты" как отдельные пакеты - обычно {{Pkg|python-foo}} содержит модуль '''foo''' для Python2, а {{Pkg|python3-foo}} - '''foo''' для Python3.<br />
<br />
Если в репозитории уже есть пакет {{Pkg|python-foo}}, то можно достаточно быстро создать на его основе {{Pkg|python3-foo}} (если пакета нет, то необходимо сначала [[Создание пакетов с модулями Python|его создать]]). Для этого ищем проект для '''python-foo''' в [http://abf.io/import группе import на ABF] - и клонируем его в свой репозиторий в ABF под именем '''python3-foo''' (с помощью кнопки «Fork»).<br />
<br />
Далее клонируем git-репозиторий проекта на локальную машину, переключаемся на ветку Git с названием "rosa2019.1" и переименовываем spec-файл {{File|python-foo.spec}} в {{File|python3-foo.spec}}. Для верности, обрабатываем этот файл инструментом {{Prog|spec-cleaner}}. Выглядит это в командной строке примерно так:<br />
<br />
$ abf get <your_abf_login>/python3-foo -b rosa2019.1<br />
$ cd python3-foo<br />
$ git mv python-foo.spec python3-foo.spec<br />
$ spec-cleaner python3-foo.spec<br />
<br />
После чего внутри файла python3-foo прочесываем поля '''BuildRequires''', '''Requiers''', '''Suggest''' и '''Conflicts''' на предмет наличия там строк, начинающихся с «python-» или «pythonegg». Такие вхождения меняем на python3- и python3egg соответственно. Т.е. такие вот строки:<br />
<br />
BuildRequires: python-devel<br />
Requires: pythonegg(setuptools)<br />
<br />
Должны преобразоваться в такие:<br />
<br />
BuildRequires: python3-devel<br />
Requires: python3egg(setuptools)<br />
<br />
Теперь смотрим на секции {{Macro|%build}}, {{Macro|%install}} и {{Macro|%check}} (если есть) и заменяем там вызов команды {{Cmd|python}} на вызов {{Cmd|python3}}.<br />
<br />
Наконец, смотрим на секцию {{Macro|%files}} и заменяем макросы, начинающиеся на {{Macro|%{py_}}, соответствующими макросами, начинающимися на {{Macro|%{py3_}}. Например, такая строка:<br />
<br />
%{py_platsitedir}/%{module}/foo.py*<br />
<br />
должна превратиться в такую:<br />
<br />
%{py3_platsitedir}/%{module}/foo.py*<br />
<br />
Такую замену макросов {{Macro|%{py_}} надо сделать и в других местах spec-файла, если эти макросы там вдруг встретятся.<br />
<br />
Теперь получившийся пакет надо собрать. Для этого сначала надо установить пакеты, которые требуются для его сборки (прописаны в BuildRequires). Для этого внутри директории {{File|python3-foo}} выполняем команду:<br />
<br />
$ urpmi python3-foo.spec<br />
<br />
Если вам сообщат, что зависимости не могут быть установлены, т. к. не хватает пакета {{Pkg|python3-bar}}, то вам надо сначала собрать {{Pkg|python3-bar}}, а уже потом возвращаться к {{Pkg|python3-foo}}.<br />
<br />
Если все ok, то извлекаем с ABF необходимые для сборки файлы и запускаем саму сборку с помощью {{Prog|rpmbuild}}:<br />
<br />
$ abf fetch<br />
$ rpmbuild -bb python3-foo.spec<br />
<br />
В идеале, все должно собраться сразу. Часто могут возникать проблемы из-за того, что где-то забыли поменять «python» на «python3» или «py» на «py3». Иногда встречаются и специфические для python3 ошибки, так что если за разумное время пакет собрать не удалось, лучше обратиться к разработчикам РОСЫ.<br />
<br />
Получившийся в результате пакет необходимо попробовать установить с помощью {{Prog|urpmi}}:<br />
<br />
$ urpmi --test ~/rpmbuild/RPMS/<pkg_arch>/python3-foo-<version>.rpm<br />
<br />
Здесь <pkg_arch> может принимать значение i586, x86_64 или noarch – это зависит от архитектуры вашей системы и от того, помечен ли пакет как независимый от архитектуры (это определяется наличием конструкции "BuildArch: noarch" в spec-файле). Посмотрите на вывод rpmbuild – он выводит пути к собранным пакетам. Если urpmi сообщит, что не может установить зависимость типа {{Pkg|python3-pad}}, то вам нужно также озаботиться созданием пакета {{Pkg|python3-pad}}. Для сборки {{Pkg|python3-foo}} он не нужен, но вот для его работы понадобится.<br />
<br />
Наконец, неплохо бы убедиться в работоспособности полученного модуля - хотя бы написать небольшой скрипт на python3, импортирующий этот модуль.<br />
<br />
Как только пакет успешно собрался, отправляем результаты назад на ABF:<br />
<br />
$ abf put -m "Created python3 module"<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2019.1 (последней на момент написания этой странички, если есть платформа поновее - то надо выбирать ее). <br />
<br />
И докладываем разработчикам РОСЫ о том, что пакет готов и лежит на ABF.<br />
<br />
Более подробная информация о правилах оформления модулей Python приведена на странице [[Python policy]].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9F%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B0_%D1%81%D1%82%D1%83%D0%B4%D0%B5%D0%BD%D1%82%D0%BE%D0%B2&diff=17552Категория:Практика студентов2018-09-22T05:36:36Z<p>D uragan: </p>
<hr />
<div>В данной категории находятся типовые примеры задач, выполняемых студентами в рамках практики в РОСЕ.<br />
<br />
Для выполнения любой задачи предварительно необходимо:<br />
# Зарегистрироваться в нашей [http://abf.io сборочной среде ABF] и [http://wiki.rosalab.ru/en/index.php/ABF_Getting_Started познакомиться с ней].<br />
# Установить себе на машину (можно на виртуальную) [http://wiki.rosalab.ru/ru/index.php/ROSA_релиз последнюю версию системы ROSA Desktop Fresh] и установить в ней пакеты {{Pkg|abf-console-client}}, {{Pkg|rpm-build}} и {{Pkg|mock-urpm}}.<br />
# Получить базовое представление о системе контроля версий Git, а также о [http://wiki.rosalab.ru/ru/index.php/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_RPM_-_%D0%B1%D1%8B%D1%81%D1%82%D1%80%D1%8B%D0%B9_%D1%81%D1%82%D0%B0%D1%80%D1%82 сборке пакетов RPM].<br />
<br />
<br />
Основная работа производится на машине внутри РОСЫ (частично - в командной строке), результаты отправляются на ABF.<br />
<br />
Результатом работы является набор пакетов в персональном репозитории студента на ABF. Если это новые пакеты, но необходимо сообщить ментору их перечень - если все в порядке, они будут перенесены в основные репозитории РОСЫ. Если речь идет об обновлении существующих пакетов, то надо сразу делать Pull Request в основной Git-репозиторий.</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%98%D0%BC%D0%BF%D0%BE%D1%80%D1%82_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B8%D0%B7_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_%D0%B4%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%D0%BE%D0%B2&diff=17551Импорт пакетов из других дистрибутивов2018-09-22T05:34:20Z<p>D uragan: </p>
<hr />
<div>Нередко возникает необходимость собрать в репозитории РОСЫ новые программы, для которых spec-файл не может быть подготовлен автоматически (как в случае модулей Perl, Python и прочего) или хотя бы на основе шаблона.<br />
<br />
В некоторых случаях пригодится утилита [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Spec-gen_-_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D1%83%D0%B5%D0%BC_spec-%D1%84%D0%B0%D0%B9%D0%BB%D1%8B_%D0%B4%D0%BB%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC_%D0%BD%D0%B0_GNU_Autotools_%D0%B8_CMake spec-gen], однако она далека от идеала.<br />
<br />
Однако есть путь проще - возможно, кто-то уже собрал RPM-пакет под другой дистрибутив, и можно позаимствовать spec-файл оттуда. Посмотреть - в каких дистрибутивах уже есть пакет с нужной программой, можно на порталах наподобие [https://pkgs.org Pkgs.org]. Если нужный пакет нашелся, то надо скачать соответствующий src.rpm и установить его в систему:<br />
<br />
$ rpm -i my_program.src.rpm<br />
<br />
При этом spec-файл установится в директорию {{File|~/rpmbuild/SPECS}}, архив с исходным кодом и патчи - в {{File|~/rpmbuild/SOURCES}}.<br />
<br />
Если пакет нашелся в нескольких дистрибутивах, то стоит выбирать наиболее близкие к РОСЕ - OpenMandriva, Mageia или PCLinuxOS. Если в этих системах пакета не нашлось, то можно попробовать RPM для Fedora, и уже совсем в крайнем случае - от SUSE.<br />
<br />
Первым делом, spec-файл от другого дистрибутива необходимо обработать утилитой {{Prog|spec-cleaner}}, которая подправит некоторые известные расхождения с РОСОЙ:<br />
<br />
$ spec-cleaner ~/rpmbuild/SPECS/my_program.spec<br />
<br />
После чего попробовать установить зависимости сборки:<br />
<br />
$ urpmi ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Вполне вероятно, что {{Prog|urpmi}} скажет, что некоторые зависимости не могут быть установлены. В большинстве случаев это происходит из-за разницы в названиях пакетов с одними и теми же программами в разных дистрибутивах и вам надо посмотреть, на что необходимо заменить проблемную запись BuildRequires в spec-файле. Впрочем, возможно некоторых программ еще нет в репозиториях РОСЫ и необходимо сначала собрать их.<br />
<br />
Как только зависимости сборки установлены, можно попробовать собрать пакет:<br />
<br />
$ rpmbuild -bb ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Если при сборки возникли ошибки, то можно проконсультироваться со страничкой [http://wiki.rosalab.ru/ru/index.php/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM часто встречающихся ошибок]. <br />
<br />
Если программа собралась успешно, то результаты сборки можно найти в директории {{File|~/rpmbuild/RPMS}}. Установите собравшиеся пакеты, убедитесь в их работоспособности и собирайте src.rpm:<br />
<br />
$ rpmbuild -bs ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Результатом работы этой программы будем пакет {{File|~/rpmbuild/SRPMS/my_program.src.rpm}}, из которого надо [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F создавать проект на ABF]<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2016.1 (последней на момент написания этой странички, если есть платформа поновее типа rosa2019.1 - то надо выбирать ее).<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D1%81_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8F%D0%BC%D0%B8_Perl&diff=17550Сборка пакетов с модулями Perl2018-09-22T05:33:21Z<p>D uragan: </p>
<hr />
<div>В мире существует огромное множество модулей для языка Perl, большинство которых находится на сайте [http://www.cpan.org/ CPAN]. Чтобы упростить установку этих модуле в РОСЕ, они оформляются в виде пакетов rpm - в таком случае их можно поставить через стандартный менеджер пакетов.<br />
<br />
Для автоматического создания пакетов с модулями Perl используется утилита cpan2dist с бэкендом CPANPLUS-Dist-Mdv. Утилита сама находит и скачивает архив с исходным кодом, формирует spec-файл с инструкциями сборки и пытается собрать пакет.<br />
<br />
Перед запуском утилиты необходимо создать все требуемые ей директории:<br />
<br />
$ mkdir -p ~/rpmbuild/RPMS ~/rpmbuild/SOURCES ~/rpmbuild/SPECS ~/rpmbuild/SRPMS ~/rpmbuild/tmp<br />
<br />
Пакет для модуля Foo::Bar создается следующей командой:<br />
<br />
$ cpan2dist --format CPANPLUS::Dist::Mdv Foo::Bar<br />
<br />
Если повезет, то все соберется сразу и в результате у вас будет лежать собранный пакет, а также пакет src.rpm - {{File|~/rpmbuild/SRPMS/perl-Foo-Bar-<version>.src.rpm}}.<br />
<br />
Получившийся в результате пакет необходимо попробовать установить с помощью urpmi:<br />
<br />
$ urpmi --test ~/rpmbuild/RPMS/<pkg_arch>/perl-Foo-Bar-<version>.rpm<br />
<br />
Здесь <pkg_arch> может принимать значение i586, x86_64 или noarch – это зависит от архитектуры вашей системы и от того, помечен ли пакет как независимый от архитектуры (это определяется наличием конструкции "BuildArch: noarch" в spec-файле).<br />
Посмотрите на вывод rpmbuild – он выводит пути к собранным пакетам. Если {{Prog|urpmi}} сообщит, что не может установить зависимость типа '''perl(A::B)''', то вам нужно также озаботиться созданием пакета для модуля '''A::B'''. Для сборки нашего модуля он не нужен, но вот для его работы понадобится.<br />
<br />
Если все ok, то на основе пакета src.rpm ({{File|~/rpmbuild/SRPMS/perl-Foo-Bar-<version>.src.rpm}}) необходимо [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F сделать проект на ABF] в своем репозитории.<br />
<br />
Если вызов {{Prog|cpan2dist}} завершился с ошибкой, то необходимо с этой ошибкой разбираться. Типичная причина ошибки - необходимость для сборки других модулей, которых еще нет в репозиториях РОСЫ. В таком случае вы получите сообщение, что urpmi не смог установить зависимость типа '''perl(C::D)'''. В таком случае надо сначала создать пакет с модулем '''C::D''', установить его в систему и попробовать снова запустить {{Prog|cpan2dist}}.<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2016.1 (последней на момент написания этой странички, если есть платформа поновее типа rosa2019.1 - то надо выбирать ее).<br />
<br />
Более подробная информация о правилах оформления модулей Perl приведена на странице [[Perl policy]].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B4%D0%BB%D1%8F_%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0_R&diff=17549Сборка пакетов-расширений для языка R2018-09-22T05:33:01Z<p>D uragan: </p>
<hr />
<div>'''R''' — язык программирования для статистической обработки данных и работы с графикой. Среда, в которой производится обработка, также называется '''R'''. Для этой среды существует множество вспомогательных расширений, реализующих дополнительные функции. Каждое такое расширение, не входящее в базовую поставку R, оформляется в РОСЕ как отдельный пакет.<br />
<br />
Пакеты создаются полуавтоматически скриптом {{Prog|R2spec}}, который необходимо запускать в установленной РОСЕ, имеющей доступ в интернет. Для получения скрипта необходимо установить пакет {{Pkg|R2spec}}. Все последующие действия необходимо выполнять в консоли/терминале.<br />
<br />
Пакет для расширения '''foo''' создается с помощью скрипта следующим образом:<br />
<br />
$ R2spec -p foo<br />
<br />
Скрипт ищет последнюю версию расширения foo в публичных репозиториях (в частности, в [https://cran.r-project.org/src/contrib/ CRAN]). В случае успеха архив с исходным кодом скачивается в директорию {{File|~/rpmbuild/SOURCES}}, а также создается spec-файл {{File|~/rpmbuild/SPECS/R-foo.spec}} с инструкциями для сборки rpm-пакета из этого кода. Этот файл надо передать утилите rpmbuild, чтобы она попробовала собрать пакет:<br />
<br />
$ rpmbuild -bb ~/rpmbuild/SPECS/R-foo.spec<br />
<br />
Если соберется сразу — отлично, можно делать src.rpm:<br />
<br />
$ rpmbuild -bs ~/rpmbuild/SPECS/R-foo.spec<br />
<br />
и затем [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F делать из него проект на ABF] в своем репозитории.<br />
<br />
Но обычно пакет сразу не собирается, и приходится либо дорабатывать spec-файл, либо сначала собирать дополнительные пакеты (необходимые для сборки данного). Поэтому заранее сложно сказать, сколько в итоге пакетов придется обработать.<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2016.1 (последней на момент написания этой странички, если есть платформа поновее типа rosa2019.1 - то надо выбирать ее).<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D1%81_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8F%D0%BC%D0%B8_Python&diff=17548Создание пакетов с модулями Python2018-09-22T05:32:29Z<p>D uragan: </p>
<hr />
<div>Подготовка пакета для модуля языка '''Python''' может быть осуществлена с помощью модуля {{Prog|bdist_rpm5}}. Этот способ подходит для модулей, собираемых с помощью {{Prog|setuptools}}. Определить, относится ли ваш модуль к этому виду, очень просто - достаточно посмотреть, есть ли в лиректории с его исходным кодом файл {{File|setup.py}}. Если есть, то переходим в директорию с исходным кодом модуля и запускаем следующую команду:<br />
<br />
$ python setup.py bdist_rpm5<br />
<br />
Как минимум, эта команда создаст spec-файл в поддиректории {{File|build/bdist.linux-x86_64/rpm/SPECS}} (либо {{File|build/bdist.linux-i686/rpm/SPECS}}, если у вас 32битная система).<br />
<br />
{{Prog|bdist_rpm5}} сразу же попробует собрать пакет с использованием этого файла, и если вам повезет и пакет действительно соберется, то в поддиректории {{File|build/bdist.linux-x86_64/rpm/RPMS}} вы обнаружите результаты сборки. В этом случае можно смело брать src.rpm файл из поддиректории {{File|build/bdist.linux-x86_64/rpm/SRPMS}} и [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F|создавать из него проект на ABF].<br />
<br />
Если же сборка пакета завершилась с ошибкой, то необходимо доработать spec-файл и уже самостоятельно попробовать собрать с его помощью пакет с помощью команды <br />
<br />
rpmbuild -bb <имя_spec_файла><br />
<br />
Как только пакет успешно соберется, создаем src.rpm с помощью {{Cmd|rpmbuild -bs}} и делаем из него проект на ABF.<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2016.1 (последней на момент написания этой странички, если есть платформа поновее типа rosa2019.1 - то надо выбирать ее).<br />
<br />
Более подробная информация о правилах оформления модулей Python приведена на странице [[Python policy]].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D1%81_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8F%D0%BC%D0%B8_Python3&diff=17547Создание пакетов с модулями Python32018-09-22T05:31:51Z<p>D uragan: </p>
<hr />
<div>'''Python3''' - современная линейка версий языка и интерпретатора Python, вот уже несколько лет усиленно вытесняющая Python2. Поскольку многие проекты все еще ориентируются на Python2, то для многих модулей Python в РОСЕ предусмотрено два варианта - для Python2 и Python3. Оформляются эти "варианты" как отдельные пакеты - обычно {{Pkg|python-foo}} содержит модуль '''foo''' для Python2, а {{Pkg|python3-foo}} - '''foo''' для Python3.<br />
<br />
Если в репозитории уже есть пакет {{Pkg|python-foo}}, то можно достаточно быстро создать на его основе {{Pkg|python3-foo}} (если пакета нет, то необходимо сначала [[Создание пакетов с модулями Python|его создать]]). Для этого ищем проект для '''python-foo''' в [http://abf.io/import группе import на ABF] - и клонируем его в свой репозиторий в ABF под именем '''python3-foo''' (с помощью кнопки «Fork»).<br />
<br />
Далее клонируем git-репозиторий проекта на локальную машину, переключаемся на ветку Git с названием "rosa2016.1" и переименовываем spec-файл {{File|python-foo.spec}} в {{File|python3-foo.spec}}. Для верности, обрабатываем этот файл инструментом {{Prog|spec-cleaner}}. Выглядит это в командной строке примерно так:<br />
<br />
$ abf get <your_abf_login>/python3-foo -b rosa2016.1<br />
$ cd python3-foo<br />
$ git mv python-foo.spec python3-foo.spec<br />
$ spec-cleaner python3-foo.spec<br />
<br />
После чего внутри файла python3-foo прочесываем поля '''BuildRequires''', '''Requiers''', '''Suggest''' и '''Conflicts''' на предмет наличия там строк, начинающихся с «python-» или «pythonegg». Такие вхождения меняем на python3- и python3egg соответственно. Т.е. такие вот строки:<br />
<br />
BuildRequires: python-devel<br />
Requires: pythonegg(setuptools)<br />
<br />
Должны преобразоваться в такие:<br />
<br />
BuildRequires: python3-devel<br />
Requires: python3egg(setuptools)<br />
<br />
Теперь смотрим на секции {{Macro|%build}}, {{Macro|%install}} и {{Macro|%check}} (если есть) и заменяем там вызов команды {{Cmd|python}} на вызов {{Cmd|python3}}.<br />
<br />
Наконец, смотрим на секцию {{Macro|%files}} и заменяем макросы, начинающиеся на {{Macro|%{py_}}, соответствующими макросами, начинающимися на {{Macro|%{py3_}}. Например, такая строка:<br />
<br />
%{py_platsitedir}/%{module}/foo.py*<br />
<br />
должна превратиться в такую:<br />
<br />
%{py3_platsitedir}/%{module}/foo.py*<br />
<br />
Такую замену макросов {{Macro|%{py_}} надо сделать и в других местах spec-файла, если эти макросы там вдруг встретятся.<br />
<br />
Теперь получившийся пакет надо собрать. Для этого сначала надо установить пакеты, которые требуются для его сборки (прописаны в BuildRequires). Для этого внутри директории {{File|python3-foo}} выполняем команду:<br />
<br />
$ urpmi python3-foo.spec<br />
<br />
Если вам сообщат, что зависимости не могут быть установлены, т. к. не хватает пакета {{Pkg|python3-bar}}, то вам надо сначала собрать {{Pkg|python3-bar}}, а уже потом возвращаться к {{Pkg|python3-foo}}.<br />
<br />
Если все ok, то извлекаем с ABF необходимые для сборки файлы и запускаем саму сборку с помощью {{Prog|rpmbuild}}:<br />
<br />
$ abf fetch<br />
$ rpmbuild -bb python3-foo.spec<br />
<br />
В идеале, все должно собраться сразу. Часто могут возникать проблемы из-за того, что где-то забыли поменять «python» на «python3» или «py» на «py3». Иногда встречаются и специфические для python3 ошибки, так что если за разумное время пакет собрать не удалось, лучше обратиться к разработчикам РОСЫ.<br />
<br />
Получившийся в результате пакет необходимо попробовать установить с помощью {{Prog|urpmi}}:<br />
<br />
$ urpmi --test ~/rpmbuild/RPMS/<pkg_arch>/python3-foo-<version>.rpm<br />
<br />
Здесь <pkg_arch> может принимать значение i586, x86_64 или noarch – это зависит от архитектуры вашей системы и от того, помечен ли пакет как независимый от архитектуры (это определяется наличием конструкции "BuildArch: noarch" в spec-файле). Посмотрите на вывод rpmbuild – он выводит пути к собранным пакетам. Если urpmi сообщит, что не может установить зависимость типа {{Pkg|python3-pad}}, то вам нужно также озаботиться созданием пакета {{Pkg|python3-pad}}. Для сборки {{Pkg|python3-foo}} он не нужен, но вот для его работы понадобится.<br />
<br />
Наконец, неплохо бы убедиться в работоспособности полученного модуля - хотя бы написать небольшой скрипт на python3, импортирующий этот модуль.<br />
<br />
Как только пакет успешно собрался, отправляем результаты назад на ABF:<br />
<br />
$ abf put -m "Created python3 module"<br />
<br />
Для надежности, следует попробовать собрать пакет уже на ABF - это позволяет выявить ошибки, которые можно пропустить при локальной сборке. Для этого необходимо перейти на страничку вашего проекта, нажать "New Build" и в появившемся окне слева отметить галочками репозитории main и contrib для платформы rosa2016.1 (последней на момент написания этой странички, если есть платформа поновее типа rosa2019.1 - то надо выбирать ее). <br />
<br />
И докладываем разработчикам РОСЫ о том, что пакет готов и лежит на ABF.<br />
<br />
Более подробная информация о правилах оформления модулей Python приведена на странице [[Python policy]].<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%98%D0%BC%D0%BF%D0%BE%D1%80%D1%82_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B8%D0%B7_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_%D0%B4%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%D0%BE%D0%B2&diff=17280Импорт пакетов из других дистрибутивов2018-05-04T11:37:12Z<p>D uragan: Новая страница: «Нередко возникает необходимость собрать в репозитории РОСЫ новые программы, для которы…»</p>
<hr />
<div>Нередко возникает необходимость собрать в репозитории РОСЫ новые программы, для которых spec-файл не может быть подготовлен автоматически (как в случае модулей Perl, Python и прочего) или хотя бы на основе шаблона.<br />
<br />
В некоторых случаях пригодится утилита [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Spec-gen_-_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D1%83%D0%B5%D0%BC_spec-%D1%84%D0%B0%D0%B9%D0%BB%D1%8B_%D0%B4%D0%BB%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC_%D0%BD%D0%B0_GNU_Autotools_%D0%B8_CMake spec-gen], однако она далека от идеала.<br />
<br />
Однако есть путь проще - возможно, кто-то уже собрал RPM-пакет под другой дистрибутив, и можно позаимствовать spec-файл оттуда. Посмотреть - в каких дистрибутивах уже есть пакет с нужной программой, можно на порталах наподобие [https://pkgs.org Pkgs.org]. Если нужный пакет нашелся, то надо скачать соответствующий src.rpm и установить его в систему:<br />
<br />
$ rpm -i my_program.src.rpm<br />
<br />
При этом spec-файл установится в директорию {{File|~/rpmbuild/SPECS}}, архив с исходным кодом и патчи - в {{File|~/rpmbuild/SOURCES}}.<br />
<br />
Если пакет нашелся в нескольких дистрибутивах, то стоит выбирать наиболее близкие к РОСЕ - OpenMandriva, Mageia или PCLinuxOS. Если в этих системах пакета не нашлось, то можно попробовать RPM для Fedora, и уже совсем в крайнем случае - от SUSE.<br />
<br />
Первым делом, spec-файл от другого дистрибутива необходимо обработать утилитой {{Prog|spec-cleaner}}, которая подправит некоторые известные расхождения с РОСОЙ:<br />
<br />
$ spec-cleaner ~/rpmbuild/SPECS/my_program.spec<br />
<br />
После чего попробовать установить зависимости сборки:<br />
<br />
$ urpmi ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Вполне вероятно, что {{Prog|urpmi}} скажет, что некоторые зависимости не могут быть установлены. В большинстве случаев это происходит из-за разницы в названиях пакетов с одними и теми же программами в разных дистрибутивах и вам надо посмотреть, на что необходимо заменить проблемную запись BuildRequires в spec-файле. Впрочем, возможно некоторых программ еще нет в репозиториях РОСЫ и необходимо сначала собрать их.<br />
<br />
Как только зависимости сборки установлены, можно попробовать собрать пакет:<br />
<br />
$ rpmbuild -bb ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Если при сборки возникли ошибки, то можно проконсультироваться со страничкой [http://wiki.rosalab.ru/ru/index.php/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM часто встречающихся ошибок]. <br />
<br />
Если программа собралась успешно, то результаты сборки можно найти в директории {{File|~/rpmbuild/RPMS}}. Установите собравшиеся пакеты, убедитесь в их работоспособности и собирайте src.rpm:<br />
<br />
$ rpmbuild -bs ~/rpmbuild/SPECS/my_program.spec<br />
<br />
Результатом работы этой программы будем пакет {{File|~/rpmbuild/SRPMS/my_program.src.rpm}}, из которого можно [http://wiki.rosalab.ru/ru/index.php/ABF:_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8#.D0.A1.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B0_.D1.81_.D0.BD.D1.83.D0.BB.D1.8F создавать проект на ABF]<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM&diff=17279Ошибки сборки пакетов RPM2018-05-04T11:33:09Z<p>D uragan: </p>
<hr />
<div>В данной статье мы собрали несколько часто встречающихся при сборке пакетов RPM ошибок подобного рода и способы их исправления. Этот перечень создан на основе опыта прохождения практики студентами НИУ ВШЭ, но мы надеемся, что он пригодится не только им.<br />
<br />
При сборке новых версий программ с помощью Updates Builder подобные ошибки исправляются автоматически (скриптом [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/analyze_log.sh analyze_log.sh]), так что можно использовать код этого скрипта как подсказку - что надо делать. Впрочем, скрипт не универсален и может не работать в каких-то специфических случаях.<br />
<br />
== error: Installed (but unpackaged) file(s) found ==<br />
Ошибка означает, что в новой версии пакета появились новые файлы, отсутствующие ранее, и rpmbuild не знает, что с ними делать (и нужны ли ли вообще).<br />
<br />
Если вы полагаете, что эти файлы нужны (а это так в 99.9% случаев), необходимо добавить их в секцию %files spec-файла. Если у вас есть несколько подпакетов, то надо сначала определить - к какому из них эти файлы относятся. Универсального рецепта здесь нет, однако есть несколько правил:<br />
<br />
* файлы в директориях {{File|/usr/include}}, {{File|/ust/lib(64)/pkgconfig}}, добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на суффикс .so (например, {{File|libfoo.so}}), также добавляются в devel-пакеты<br />
* файлы библиотек в директориях {{File|/lib(64)}} и {{File|/usr/lib(64)}}, оканчивающиеся на цифру (например, {{File|libfoo.so.1}}), добавляются в пакеты с соответсвующими библиотеками. Согласно правилам РОСЫ, каждая библиотека должна упаковываться в отдельный подпакет, соотевтсвующий ее имени и значению SONAME (как правило, это цифра после суффикса .so - так что файлы {{File|libfoo.so.1}} и {{File|libfoo.so.1.2}} должны находиться в пакете {{Pkg|lib(64)foo1}}). Часто ошибка "Installed but unpackaged files found) в пакетах с библиотеками вызвана изменением значения SONAME - например, вместо {{File|libfoo.so.1}} в новой версии пакета появился файл {{File|libfoo.so.2}}. В этом случае вы также дополнительно увидите ошибку "Cannot find file or directory", сообщающую, что отсутсвует файл {{File|libfoo.so.1}}. Для исправления сборки в такой ситуации достаточно изменить значение макроса major в начале spec-файла:<br />
<br />
%define major 2<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами (например вместо {{File|/usr/lib}} и {{File|/usr/lib64}} необходимо использовать макрос {{Macro|%{_libdir}}}, вместо {{File|/usr/share/man}} - {{Macro|%{_mandir}}} и так далее). Более полный список можно посмотреть с [https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/dir_to_macro.pm скрипте из Updates Builder].<br />
<br />
== File not found ==<br />
Ошибка означает, что в новой версии пакета отсутсвуют некоторые файлы, присутствувавшие ранее. Причин для этого может быть несколько:<br />
<br />
* в новой версии действительно нет таких файлов - в этом случае надо просто убрать их описание из секции {{Macro|%files}}<br />
* в новой версии файлы переименованы либо перемещены в другое место. В этом случае вы также увидите ошибку "Installed (but unpackaged) file(s) found", как в случае с библиотеками (см. выше). В случае с библиотеками для исправления сразу обеих ошибок необходимо изменить значение переменной major в начале spec-файла. В общем же случае необходимо исправить секцию {{Macro|%files}}, чтобы она соответсвовала новым реалиям.<br />
* отсутсвующие файлы собираются или не собираются в зависимости от параметров окружения и сборки - опций компиляции или установленных в сборочной среде пакетов (описанных в BuildRequires). Возможно, в новой версии пакета надо использовать какие-то новые опции сборки либо добавить дополнительные сборочные зависимости для получения этих файлов. Выявить такие ситуации можно на основе анализа журналов сборки и вывода команд наподобие configure или cmake, которые сообщают, какие опцилнальные возможности будут включены при сборке, а какие - нет. Например, {{Pkg|squid}} может собираться с поддержкой аутентификации SASL и без нее. В первом случае в пакете будет присутсвовать файл basic_sasl_auth, во втором его не будет. Для ключения/отключения SASL необходимо добавить/удалить значение SASL из параметра --enable-auth-basic команды {{Cmd|configure}}, а также добавить сборочную зависимость (BuildRequires) от {{Pkg|sasl-devel}}.<br />
<br />
Помните, что при добавлении файлов в секции {{Macro|%files}} принято заменять некоторые стандартные пути макросами, а также что при описании файлов в секции {{Macro|%files}} могут использоваться символы '?' и '*' (означающие один произвольный символ и любое количество<br />
произвольных символов соответсвенно).<br />
<br />
== cp: cannot stat '<some_file>': No such file or directory ==<br />
Ошибка означает, что rpmbuild не смог найти файл <some_file>, помеченный как {{Macro|%doc}} в секции %files вашего пакета. Возможно, этот файл был переименован (в этом случе вы также увидите ошибку "Installed (but unpackaged) file(s) found") - в этом случае надо изменить имя файла на новое (например, {{File|README}} могут переименовать в {{File|README.md}}).<br />
Если неупакованного файла с близким именем не появилось, то значит старый файл в новой версии отсутсвует и его определение в {{Macro|%doc}} необходимо просто удалить.<br />
<br />
== Reversed (or previously applied) patch detected ==<br />
Ошибка означает, что применявшийся к старой версии пакета патч по крайней мере частично уже применен в новой версии. Обратите внимание, что команда {{Cmd|patch}} делает такой вывод на основе попытки применить только первую часть патча! Если патч сложный и затрагивает несколько файлов или несколько мест одного файла, то необходимо вручную проверить, какие из этих изменений уже есть в новой версии, а каких нет. Для этого можно попробовать применить патч к новой версии вручную, отвечая "n" на вопрос "Assume '-R'" и "y" на предложени продолжить применять остальные части патча.<br />
<br />
Если все изменения из патча действительно уже присутсвуют в новой версии, то патч можно спокойно удалить (физически из Git-репозитория, а также из spec-файла). Если же нет, то необходимо определить - нужны ли в новой версии оставшиеся изменения и если да, то переделать патч соответствующим образом. Такой анализ уже требует некоторых познаний в том, что именно делает патч.<br />
<br />
== /var/tmp/rpm-tmp.xxxxx: line yy: cd: <some_folder_name>: No such file or directory ==<br />
Ошибка означает, что rpmbuild не может определить, в какую директорию ему перейти после распаковки архива с исходным кодом. Имя директории указывается в опции {{Macro|-n}} макроса {{Macro|%setup}} в секции {{Macro|%prep}}. Если эта опция отсутсвует, то подразумевается<br />
использование "-n %{name}-%{version}". Для исправления ошибки необходимо посмотреть, как расположены файлы в новой версии архива с исходным кодом - обычно такой архив содержит директорию вида "<имя_программы>-<версия>", но время от времени разработчики могут что-то изменять (например, переименовывать директорию просто в <имя_программы>. Для исправления<br />
ошибки необходимо соответсвующим образом исправить значение опции "-n" макроса {{Macro|%setup}}.<br />
<br />
== empty-debug-info и debuginfo-without-sources ==<br />
Ошибки означают, что rpmbuild не смог должным образом сформировать подпакет с отладочной информацией. Две основные причины такого поведения:<br />
<br />
* в пакете нет исполнимых файлов или библиотек. Если в пакете при этом вообще нет архитектурно-зависимых файлов (т.е. пакеты для разных архитектур имею абсолютно одинаковое содержимое), то необходимо объявить пакет как независимый от архитектуры, добавив в заголовок spec-файла декларацию "BuildArch: noarch". Если же архитектурно-зависимые файлы все-таки есть (например, какие-то данные могут быть специфичны для каждой арзитектуры; другой типичный пример - проприетарное приложение, которое уже поставляется в виде бинарных файлов бех отладочной информации), то необходимо отключить генерацию debug-пакетов, сбросив определение макроса {{Macro|debug_package}} в начале spec-файла:<br />
<br />
%define debug_package %{nil}<br />
<br />
* скрипты сборки приложения в пакете устроены таким образом, что сразу удаляют отладочную информацию из собранных файлов (например, явно вызывают команду strip либо просто не передают опцию "-g" компилятору). В таких случаях необходимо посмотреть, как заставить скрипты сборки оставить отладочную информацию. Иногда этого можно добиться с помощью переменных среды, а иногда может потребоваться патч, изменяющий сборочные скрипты. Если никакие способы не помогают, то можно отключить генерацию debug-пакетов, как описано выше, но делать так не рекомендуется - эти пакеты очень полезны для анализа ошибок в случае падений приложения.<br />
<br />
Остановимся подробнее на втором пункте. Большинство приложений позволяют настраивать передаваемые компилятору опции при старте сборки - например, при вызове {{Prog|configure}} или {{Prog|cmake}}. Для генерации отладочной информации для подобных приложений вам не нужно прилагать особых усилий - достаточно вместо прямого вызова {{Prog|configure}} или {{Prog|cmake}} использовать соответствующие макросы {{Prog|rpm}} (в нашем примере - {{Macro|%configure2_5x}} или {{Macro|%cmake}} соответственно). Если использование макросов не помогает (либо в проекте не используются стандартные средства типа GNU Autotools или CMake), необходимо изучить схему сборки и посмотреть - нельзя ли на нее повлиять как-то еще - например, специфическими опциями либо переменными окружения. Типичными переменными, которые могут повлиять на сборку, являются {{Var|CFLAGS}}, {{Var|CXXFLAGS}} и {{Var|CPPFLAGS}}. Мы рекомендуем выставить эти переменные в макрос {{Macro|%optflags}}; при этом может оказаться необходимым перед использованием {{Macro|%%optflags}} вызвать макрос {{Macro|%%setup_compile_flag}} (например так сделано в пакете [[https://abf.io/import/slock/commit/78a9ac338470558c7a38d1709ce6d9036e5bb408#diff-F2R24 slock]].<br />
<br />
Обратите внимание на использование кавычек при выставлении переменных среды - они необходимы, поскольку макрос разворачивается в большой набор опций, разделенных пробелами.<br />
<br />
Бывают ситуации, когда повлиять на сборку извне нельзя никак - в скриптах сборки или файлах типа Makefile инструкции сборки "забиты" намертво. В таких случаях необходимо подготовить патч, добавляющий во<br />
все вызовы компилятора опцию {{Var|-g}}. Помимо опции {{Var|-g}} у компилятора, повлиять на отладочную информацию может компоновщик - например, его опции {{Var|-s}} и {{Var|-S}}, удаляющие подобные данные из результирующих бинарных файлов. Если такие опции явно передаются компоновщику в скриптах сборки либо файлах Makefile, то необходимо подготовить патч, убирающий их - например, так сделано в пакете [[https://abf.io/import/kicad/commit/c93e3d9911e3b3be485ee5dd01cbea723a087729#diff-13 kicad]].<br />
<br />
== Error: Can't locate Some/Perl/Module.pm in @INC ==<br />
Ошибка означает, что для сборки необходим Perl-модуль {{File|Some/Perl/Module.pm}}, который не был обнаружен в сборочном окружении.<br />
<br />
Для исправления ошибки необходимо добавить сборочную зависимость от такого модуля в spec-файл:<br />
<br />
BuildRequires: perl(Some::Perl::Module)<br />
<br />
Предварительно необходимо убедиться, что такой модуль вообще существует - попробовать его установить с помощью urpmi:<br />
<br />
# urpmi 'perl(Some::Perl::Module)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с модулем в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый модуль может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый модуль необходимо перенести в репозиторий Main.<br />
<br />
== Package(s) suggested but not available ==<br />
Данная ошибка может встречаться при сборке расширений языка R. Она означает, что у собираемого пакета есть необязательная зависимость от каких-то других модулей, которые в сборочной среде отсутсвуют. В идеале для каждой такой зависимости необходимо прописать BuildRequires и Requires - например, если ошибка относится к модулю "foo", то нужны зависимости от R-foo:<br />
<br />
BuildRequires: R-foo<br />
Requires: R-foo<br />
<br />
Предварительно необходимо убедиться, что такой пакет вообще есть в репозиториях - вывод команды "urpmq R-foo" должен быть непуст. Если пакета нет, то желательно его сначала собрать и добавить в репозитории. Однако при сборке может оказаться, что он зависит от того пакета, который вы собирали до этого и для которого вы собственно и хотите добавить зависимость R-foo. В этом случае первый пакет можно собрать и без R-foo, закомментировав при этом команду "%{_bindir}/R CMD check %{packname}" в секции %check. После этого можно будет уже собрать R-foo и вернуться к исходному пакету, добавив в него зависимость от R-foo и включив тесты в секции %check<br />
<br />
== ERROR: dependency(ies) not available ==<br />
Данная ошибка также может встречаться при сборке расширений языка R, но в отличие от предыдущей, здесь речь идет об обязательных зависимостях сборки. Без них пакет не может быть собран, поэтому вам необходимо добавить в spec-файл соответсвующие BuildRequiers и Requires, а при необходимости предварительно собрать нужные пакеты в репозитории РОСЫ.<br />
<br />
== hunk FAILED -- saving rejects ==<br />
Данная ошибка означает, что один из патчей (какой именно - указано в выводе rpmbuild) не может быть применен без изменений к новой версии программы. Обычно это означает, что патч необходимо переделать (предварительно определив - нужен ли он еще), что требует определенной квалификации. Однако иногда такая ошибка возникает из-за "строгости" rpmbuild при применении патчей и проблемный патч может быть исправлен в автоматическом режиме с помощью утилиты rediff_patch.<br />
<br />
Для этого достаточно склонировать себе Git-репозиторий, перейти в склонированную папку, поместить туда архив с исходным кодом новой версии и запустит rediff_patch, передав ей нужный патч к вачестве аргумента:<br />
<br />
$ abf get myrepo/myproject<br />
$ cd myproject<br />
$ wget http://project-upstream.org/new-version.tgz<br />
$ rediff_patch <some_patch_to_rediff><br />
<br />
Если все сложится удачно, то радом со старым патчем "some_patch_to_rediff" появится новый - "some_patch_to_rediff.new" Если же что-то пойдет не так, то в текущей директории останутся папка "rediff_patch" с подпапками вида "myproject.orig" и "myproject" - содержащие соответсвенно оригинальный исходный код и исходный код, получившийся после попытки применить<br />
патч. Во второй папке вы найдете файлы с расширениями *rej - это куски патчей, которые применить не удалось.<br />
<br />
== package 'foo' not found ==<br />
Аналогична следующей ошибке<br />
== "No package '.*' found" ==<br />
Такая ошибка возникает, если пакет проверяет необходимые сборочные зависимости с помощью {{Cmd|pkgconfig}} и не обнаруживает одну из них.<br />
<br />
Для исправления ошибки достаточно добавить нужную зависимость сборки в spec-файл:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Предварительно необходимо убедиться, что такая зависимость может быть разрешена - попробовать ее установить с помощью {{Cmd|urpmi}}:<br />
<br />
# urpmi 'pkgconfig(foo)'<br />
<br />
Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с соответсвующей библиотекой (как правило, она и называется '''libfoo''') в репозитории РОСЫ.<br />
<br />
Обратите внимание, что необходимый пакет может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый пакет необходимо перенести в репозиторий Main.<br />
<br />
== /usr/bin/ld: cannot find -lfoo ==<br />
Данная ошибка возникает при линковке уже собранных объектных файлов и означает, что линкер не смог найти библиотеку "foo". Для исправления ошибки достаточно добавить зависимость от библиотеки в spec-файл. Чтобы определить, как именно эту зависимость прописать, необходимо сначала поискать devel-пакет для библиотеки {{Pkg|libfoo}} (или {{Pkg|lib64foo}} в 64битной системе) с помощью urpmq:<br />
<br />
# urpmq -a libfoo<br />
lib64foo1<br />
lib64foo-devel<br />
<br />
Интересующий нас пакет - тот, что оканчивается на -devel. Посмотрим, что он предоставляет:<br />
# urpmq --provides libfoo-devel<br />
lib64foo-devel: devel(libfoo(64bit))<br />
lib64foo-devel: lib64sasl-devel[== 2.1.25]<br />
lib64foo-devel: libsasl-devel[== 2.1.25]<br />
lib64foo-devel: libfoo-devel[== 2.1.25]<br />
lib64foo-devel: sasl-devel[== 2.1.25-7]<br />
lib64foo-devel: lib64foo-devel[== 2.1.25-7:2014.1]<br />
lib64foo-devel: pkgconfig(foo)[== 2.1.25-7]<br />
<br />
Из данного набора необходимо выбрать что-то одно. В РОСЕ отдается предпочтение зависимостям вида '''pkgconfig(...)''', так что в нашем примере в spec-файл необходимо добавить следующую строку:<br />
<br />
BuildRequires: pkgconfig(foo)<br />
<br />
Если pkgconfig(foo) не окажется в выводе urpmq, то надо добавить зависимость от foo-devel, а если и ее нет - то от libfoo-devel.<br />
<br />
== Build.PL: No such file or directory ==<br />
Такая ошибка означает, что предыдущая версия пакета собиралась с помощью скрипт Build.PL, отсутсвующего в новой версии. Часто встречающаяся ситуация - замена Build.PL на Makefile.PL. Если в архиве с исходным кодом новой версии есть скрипт Makefile.PL, то в spec-файле необходимо произвести следующие замены:<br />
<br />
* "/Build.PL installdirs=vendor" -> "Makefile.PL INSTALLDIRS=vendor"<br />
* ./Build install destdir=%{buildroot} -> %makeinstall_std<br />
* perl Build.PL install destdir=%{buildroot} -> %makeinstall_std<br />
* ./Build test -> %make test<br />
* ./Build -> %make<br />
<br />
Для примера можно посмотреть на пакет ...<br />
<br />
Если же скрипта Makefile.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== Makefile.PL: No such file or directory ==<br />
Возможна и обратная ситуация - вместо Makefile.PL разработчици перешли на Build.PL или что-то еще. Если в архиве с новым исходным кодом есть файл Build.PL, то необходимо провести в spec-файле замены, обратные приведенным в предыдущем пункте:<br />
<br />
* "Makefile.PL INSTALLDIRS=vendor" -> "/Build.PL installdirs=vendor"<br />
* %makeinstall_std -> ./Build install destdir=%{buildroot} <br />
* %makeinstall_std -> perl Build.PL install destdir=%{buildroot}<br />
* %make test -> ./Build test<br />
* %make -> ./Build<br />
<br />
Если же скрипта Build.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.<br />
<br />
== fg: no job control ==<br />
Ошибка означает, что внутри spec-файла используется макрос RPM, не поддерживаемый в РОСЕ. Поддерживается или нет каждый конкретный макрос, можно узнать с помощью команды {{Cmd|rpm --eval}}:<br />
<br />
$ rpm --eval %macro_name<br />
<br />
Если {{Prog|rpm}} ничего не знает о таком макросе, то результатом выполнения этой команды будет "%macro_name". В противном случае {{Prog|rpm}} развернет определение макроса.<br />
<br />
[[Категория:Практика студентов]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D1%81%D0%B2%D0%B5%D0%B6%D0%B8%D1%85_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B2_%D0%B2%D0%B8%D0%B4%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%BE%D0%B2&diff=16669Блог:Точка Росы/Установка свежих версий приложений в виде контейнеров2017-12-13T09:37:25Z<p>D uragan: Apps are now on flathub.org</p>
<hr />
<div>Несмотря на слово '''Fresh''' в названии нашего открытого дистрибутива, мы вовсе не стремимся всеми силами поместить в него самые свежие версии всех приложений. Все основные программы (входящие в репозиторий main) проходят тщательную проверку нашего QA и в случае обнаружения проблем (особенно регрессий) мы их либо чиним сами, либо ждем исправлений от апстрима.<br />
<br />
Однако время от времени все-таки хочется попробовать новую версию какого-нибудь приложения, несмотря на ее ошибки не дожидаясь ее появления в официальных репозиториях. Нередко для этого можно использовать неофициальные сборки от разработчиков и членов сообщества (например, немало интересного можно найти в репозиториях https://rosa.pkgs.org/2016.1/stan8-x86_64/ от наших [http://rosalinux.strefa.pl/ пользователей из Польши].<br />
<br />
Но есть и альтернатива - приносить пакеты не в виде пакетов RPM, а в виде самодостаточных контейнеров. Подробнее об эих технологиях можно узнать, например, [http://samag.ru/archive/article/3464 в этой статье], а применительно к РОСЕ и десктопным приложениям можно сразу воспользоваться инструментарием {{Prog|flatpak}}, доступным в репозиториях '''ROSA Desktop Fresh''', начиная с релиза '''R9'''.<br />
<br />
Для начала, поставим сам {{Prog|flatpak}}:<br />
<br />
$ urpmi flatpak<br />
<br />
А теперь перейдем в [https://flathub.org/apps.html каталог приложений], скачаем файл ''flatpakref'' для нужного приложения и передадим его инструменту:<br />
<br />
$ flatpak install --from https://flathub.org/repo/appstream/com.skype.Client.flatpakref<br />
$ flatpak run com.skype.Client<br />
<br />
И вуаля - в два клика мы запустили новый Skype.<br />
<br />
На данный момент приложений в каталоге не очень-то много. Но с другой стороны, есть очень интересные и востребованные программы, свежие версии которых интересны многим пользователям - тот же Skype, LibreOffice, Spotify, Pitivi, Linphone и ряд других.<br />
<br />
[[File:Skype flatpak.png]]<br />
<br />
{{wl-publish: 2017-09-01 08:34:31 +0300 | D uragan }}<br />
{{wl-publish: 2017-09-01 15:15:39 +0300 | D uragan }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D0%BB%D0%BE%D0%B3%D0%B0:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D1%81%D0%B2%D0%B5%D0%B6%D0%B8%D1%85_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B2_%D0%B2%D0%B8%D0%B4%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%BE%D0%B2/c000147&diff=16668Обсуждение блога:Точка Росы/Установка свежих версий приложений в виде контейнеров/c0001472017-12-13T09:23:12Z<p>D uragan: </p>
<hr />
<div>Приложения теперь надо искать на https://flathub.org/apps.html :)<br />
<br />
Вот и Skype:<br />
<br />
flatpak install --from https://flathub.org/repo/appstream/com.skype.Client.flatpakref<br />
<br />
{{wl-comment: }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D0%BB%D0%BE%D0%B3%D0%B0:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D1%81%D0%B2%D0%B5%D0%B6%D0%B8%D1%85_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B2_%D0%B2%D0%B8%D0%B4%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%BE%D0%B2/c000147&diff=16667Обсуждение блога:Точка Росы/Установка свежих версий приложений в виде контейнеров/c0001472017-12-13T09:22:53Z<p>D uragan: Новый комментарий от D uragan: Приложения теперь надо искать на https://flathub.org/apps.html :) Вот и Skype: # flatpak install --from https://flathu…</p>
<hr />
<div>Приложения теперь надо искать на https://flathub.org/apps.html :)<br />
<br />
Вот и Skype:<br />
<br />
# flatpak install --from https://flathub.org/repo/appstream/com.skype.Client.flatpakref<br />
{{wl-comment: }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D0%BB%D0%BE%D0%B3%D0%B0:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D1%81%D0%B2%D0%B5%D0%B6%D0%B8%D1%85_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B2_%D0%B2%D0%B8%D0%B4%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%BE%D0%B2/c000146&diff=16666Обсуждение блога:Точка Росы/Установка свежих версий приложений в виде контейнеров/c0001462017-12-13T09:20:26Z<p>D uragan: Новый комментарий от D uragan: К сожалению, сейчас skype убрали из приложений flatpak. Попытка обратиться к https://s3.amazonaws.co…</p>
<hr />
<div>К сожалению, сейчас skype убрали из приложений flatpak. Попытка обратиться к https://s3.amazonaws.com/alexlarsson/skype-repo/skype.flatpakref выдает Access Denied.<br />
<br />
В целом список приложений flatpak как-то неожиданно сильно сдулся - сейчас на сайте https://flatpak.org/apps.html видно всего несколько штук.<br />
{{wl-comment: }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Docker-%D0%BE%D0%B1%D1%80%D0%B0%D0%B7_%D0%B4%D0%BB%D1%8F_ROSA_Desktop_Fresh_R9&diff=16297Блог:Точка Росы/Docker-образ для ROSA Desktop Fresh R92017-09-12T11:49:51Z<p>D uragan: Новая страница: « "Где взять образ Docker для РОСЫ" - нередко задаваемый вопрос. Например, такой образ полезен …»</p>
<hr />
<div><br />
"Где взять образ Docker для РОСЫ" - нередко задаваемый вопрос. Например, такой образ полезен в ситуации, когда хочется быстро отладить сборку какого-то пакета, а установленной РОСЫ под рукой нет. Разворачивать ради такой такой задачи виртуальную машину - излишество, а вот создать за пару секунд контейнер - самое то.<br />
<br />
Для rosa2016.1 образы можно найти здесь:<br />
<br />
https://hub.docker.com/r/dsilakov/rosa/<br />
https://hub.docker.com/r/sibsau/rosa/<br />
<br />
А если понадобится платформа 2014.1, то его можно найти тут:<br />
https://hub.docker.com/r/fgagarin/rosa/<br />
<br />
Запуск контейнера осуществляется стандартным образом:<br />
<br />
# docker run -it --rm dsilakov/rosa<br />
<br />
[[File:docker_rosa.png]]<br />
<br />
Файлы и скрипты, которые можно использовать для сборки образов, лежат здесь: https://abf.io/soft/docker-brew-rosa<br />
<br />
Желающие делать производные образы либо дорабатывать текущие - welcome.<br />
<br />
{{wl-publish: 2017-09-12 15:15:39 +0300 | D uragan }}<br />
{{wl-publish: 2017-09-12 14:49:51 +0300 | D uragan }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A4%D0%B0%D0%B9%D0%BB:Docker_rosa.png&diff=16296Файл:Docker rosa.png2017-09-12T11:29:47Z<p>D uragan: </p>
<hr />
<div></div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D1%81%D0%B2%D0%B5%D0%B6%D0%B8%D1%85_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9_%D0%B2_%D0%B2%D0%B8%D0%B4%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%BE%D0%B2&diff=16283Блог:Точка Росы/Установка свежих версий приложений в виде контейнеров2017-09-01T12:15:39Z<p>D uragan: Новая страница: «Несмотря на слово '''Fresh''' в названии нашего открытого дистрибутива, мы вовсе не стремимся…»</p>
<hr />
<div>Несмотря на слово '''Fresh''' в названии нашего открытого дистрибутива, мы вовсе не стремимся всеми силами поместить в него самые свежие версии всех приложений. Все основные программы (входящие в репозиторий main) проходят тщательную проверку нашего QA и в случае обнаружения проблем (особенно регрессий) мы их либо чиним сами, либо ждем исправлений от апстрима.<br />
<br />
Однако время от времени все-таки хочется попробовать новую версию какого-нибудь приложения, несмотря на ее ошибки не дожидаясь ее появления в официальных репозиториях. Нередко для этого можно использовать неофициальные сборки от разработчиков и членов сообщества (например, немало интересного можно найти в репозиториях https://rosa.pkgs.org/2016.1/stan8-x86_64/ от наших [http://rosalinux.strefa.pl/ пользователей из Польши].<br />
<br />
Но есть и альтернатива - приносить пакеты не в виде пакетов RPM, а в виде самодостаточных контейнеров. Подробнее об эих технологиях можно узнать, например, [http://samag.ru/archive/article/3464 в этой статье], а применительно к РОСЕ и десктопным приложениям можно сразу воспользоваться инструментарием {{Prog|flatpak}}, доступным в репозиториях '''ROSA Desktop Fresh''', начиная с релиза '''R9'''.<br />
<br />
Для начала, поставим сам {{Prog|flatpak}}:<br />
<br />
$ urpmi flatpak<br />
<br />
А теперь перейдем в [http://flatpak.org/apps.html каталог приложений], скачаем файл ''flatpakref'' для нужного приложения и передадим его инструменту:<br />
<br />
$ flatpak install --from https://s3.amazonaws.com/alexlarsson/skype-repo/skype.flatpakref<br />
$ flatpak run com.skype.Client<br />
<br />
И вуаля - в два клика мы запустили новый Skype.<br />
<br />
На данный момент приложений в каталоге не очень-то много. Но с другой стороны, есть очень интересные и востребованные программы, свежие версии которых интересны многим пользователям - тот же Skype, LibreOffice, Spotify, Pitivi, Linphone и ряд других.<br />
<br />
[[File:Skype flatpak.png]]<br />
<br />
{{wl-publish: 2017-09-01 08:34:31 +0300 | D uragan }}<br />
{{wl-publish: 2017-09-01 15:15:39 +0300 | D uragan }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A4%D0%B0%D0%B9%D0%BB:Skype_flatpak.png&diff=16282Файл:Skype flatpak.png2017-09-01T12:14:46Z<p>D uragan: </p>
<hr />
<div></div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%A2%D0%BE%D0%BD%D0%BA%D0%BE%D1%81%D1%82%D0%B8_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B_%D1%81_Urpmi&diff=16238Тонкости работы с Urpmi2017-08-04T19:25:55Z<p>D uragan: Fix option names</p>
<hr />
<div><br />
<br />
{{Программа|urpmi}} вне всяких сомнений является одним из наиболее важных инструментов ROSA. С помощью {{Программа|urpmi}} вы с лёгкостью сможете управлять пакетами. Если вы совладаете с {{Программа|urpmi}}, вы никогда не будете испытывать «ад зависимостей», на который жалуются многие неопытные пользователи. Например, простая команда {{cmd|urpmi sylpheed}} установит почтовый клиент [http://sylpheed.sraoss.jp/en/ Sylpheed], а вместе с ним и все необходимые библиотеки.<br />
= Где получить дополнительную информацию об {{Программа|urpmi}} =<br />
<br />
Urpmi — важный инструмент для всех пользователей ROSA, и он требует какое-то время для изучения. Эта страница даёт обзор наиболее часто используемых параметров. Следующие ресурсы позволяют получить дополнительную информацию об urpmi:<br />
<br />
{{Примечание|на man-страницах можно узнать обо всех параметрах urpmi; страницы руководств — самые актуальные источники информации;}}<br />
<br />
== Использование {{Программа|urpmi}} ==<br />
=== Краткий список базовых функций ===<br />
<br />
Вместо xxx часто можно использовать xxx.rpm, тогда операция будет проведена не над пакетом из пакетной базы, а над конкретным пакетом из текущей папки.<br />
<br />
<table border="0" cellspacing="0" cellpadding="1" style="border-style: solid; border-width: 1px; border-color: #AED6F2"> <tr><th bgcolor="#AED6F2" width="300"> <strong>Команда</strong> </th><th bgcolor="#AED6F2"> <strong>Что делает</strong> </th></tr><br />
<tr><td>{{Cmd|urpmi --auto-update}}</td><td>выполняет обновление системы то текущего состояния репозиториев</td></tr><br />
<tr><td>{{Cmd|urpmq -i xxx}}</td><td>показывает информацию о пакете xxx </td></tr><br />
<tr><td>{{Cmd|urpmq -il xxx}}</td><td>показывает информацию о пакете xxx и список файлов, которые он устанавливает</td></tr><br />
<tr><td>{{Cmd|urpmq --changelog xxx}}</td><td>выводит журнал изменений пакета</td></tr><br />
<tr><td>{{Cmd|urpmq --whatrequires xxx}}</td><td>показывает, какие пакеты требуются пакету xxx</td></tr><br />
<tr><td>{{Cmd|urpmf /путь/к/файлу}}</td><td>какой пакет установил «файл» в каталог «/путь/к»</td></tr><br />
<tr><td>{{Cmd|urpmi --fuzzy --test xxx}}</td><td>показывает все rpm, совпадающие со строкой «xxx»</td></tr><br />
<tr><td>{{Cmd|rpm -qf /path/to/file}}</td><td>то же, что и urpmf, но ищет среди установленных пакетов</td></tr><br />
<br />
<tr><td>{{Cmd|urpmi.update updates}}</td><td>обновляет локальные данные о доступных пакетах хранилища «updates» </td></tr><br />
<tr><td>{{Cmd|urpmi.update -a}} </td><td>обновляет локальные данные о доступных пакетах, принадлежащих ко всем источникам</td></tr><br />
<tr><td>&nbsp;</td><td>&nbsp;</td></tr><br />
<tr><th bgcolor="#AED6F2"> <strong>Команда</strong> </th><th bgcolor="#AED6F2"><strong>Что делает</strong></th></tr><br />
<tr><td>{{Cmd|urpme xxx}}</td><td>удаляет пакет «xxx» (и все пакеты, зависящие от этого пакета)</td></tr><br />
<tr><td>{{Cmd|urpmi --keep xxx.rpm}}</td><td> устанавливает пакет «xxx.rpm», содержащийся в текущем каталоге, со всеми зависимостями этого пакета, но если что-нибудь в результате установки должно быть удалено, пакет установлен не будет.</td></tr><br />
<tr><td>{{Cmd|urpmi --update --auto-select}}</td><td>устанавливает доступные обновления с включённых источников</td></tr><br />
<tr><td>{{Cmd|urpmi --test --keep --auto --auto-select}}</td><td>обновить все пакеты с включённых источников, но ничего не устанавливать и не удалять, просто сообщить, что это будет работать</td></tr><br />
<tr><td>{{Cmd|urpmi --keep --auto --auto-select}}</td><td>обновить все пакеты из включённых источников, но ничего не удалять, просто сообщить если что-то не работает</td></tr><br />
<tr><td>{{Cmd|urpmi --auto-select}}</td><td>автоматически выбрать пакеты, которые можно обновить</td></tr><br />
</table><br />
<br />
Полный список опций '''urpmi'''<br />
<pre><br />
Это свободное программное обеспечение и может распространяться согласно условиям GNU GPL.<br />
<br />
использование:<br />
--help - показать эту справку<br />
--media - использовать только указанные источники,<br />
перечисленные через запятую<br />
--excludemedia - не использовать указанные источники,<br />
перечисленные через запятую<br />
--update - использовать только источник обновления<br />
--searchmedia - использование только указанных источников для поиска<br />
запрошенных пакетов<br />
--sortmedia - сортировать источники по подстрокам, перечисленным<br />
через запятую.<br />
--synthesis - использовать указанный synthesis вместо БД urpmi<br />
--auto - неинтерактивный режим; на вопросы даются ответы по умолчанию<br />
--auto-req - автоматически делать выбор между несколькими альтернативами.<br />
--auto-media - when provided with remote files, try to add media from<br />
that files locations.<br />
--auto-select - автоматически выбрать пакеты для обновления системы<br />
--auto-update - обновить источник, а затем систему<br />
--no-md5sum - отключить проверку файла MD5SUM<br />
--force-key - принудительно обновить gpg-ключ<br />
--auto-orphans - удалить сирот без вывода запроса<br />
--no-auto-req - при наличии альтернатив, спрашивать пользователя.<br />
--no-auto-media - when provided with remote files, do not try to add media<br />
from that files locations.<br />
--no-suggests - не выбирать автоматически рекомендованные пакеты<br />
--no-uninstall - никогда не предлагать удалять пакет, прерывать установку<br />
--no-install - не устанавливать пакеты (только загрузить)<br />
--keep - по возможности сохранять существующие пакеты,<br />
отклонять запрошенные пакеты, которые приводят к удалению<br />
--force-req-update - Обновлять все зависимости пакета.<br />
--no-force-req-update - Не обновлять зависимости пакета, если они уже установлены.<br />
--split-level - разбить на мелкие транзакции, если будут<br />
устанавливаться или обновляться дополнительные<br />
пакеты кроме указанных, по умолчанию 1<br />
--split-length - размер мелкой транзакции, по умолчанию 8<br />
--fuzzy, -y - поиск на основе нечёткой логики<br />
--buildrequires - установить требуемые для сборки пакеты<br />
--install-src - установить только пакеты с исходными кодами<br />
(без бинарных файлов)<br />
--clean - перед началом операции удалить rpm-файлы из кэша<br />
--noclean - не удалять rpm-файлы из кэша<br />
--justdb - обновить базу данных, но не изменять файловую систему<br />
--downgrade - сменить версию пакета с текущей установленной на<br />
наиболее актуальную раннюю<br />
--replacepkgs - принудительно установить уже установленные пакеты<br />
--force - принудительно выполнить, даже если некоторые пакеты<br />
не существуют<br />
--allow-nodeps - разрешить устанавливать пакеты без проверки зависимостей<br />
после запроса у пользователя<br />
--allow-force - разрешить устанавливать пакеты без проверки зависимостей<br />
и целостности после запроса у пользователя<br />
--allow-suggests - автоматически выбирать рекомендованные пакеты<br />
--parallel - распределённое выполнение urpmi через машины алиаса<br />
--root - использовать другой корень для установки rpm-файла<br />
--urpmi-root - использовать другой корень для базы данных urpmi<br />
и установки пакетов<br />
--use-distrib - настроить urpmi на лету из дерева distrib; полезно<br />
для установки в chroot с параметром --root<br />
--metalink - сгенерировать и использовать локальные метассылки<br />
--download-all - download all needed packages before trying to install them<br />
(this is the default behavior)<br />
--no-download-all - скачивать каждый пакет непосредственно перед его установкой<br />
--downloader - program to use to retrieve distant files.<br />
known programs: wget, curl, prozilla, aria2<br />
--curl-options - дополнительные параметры, передаваемые в программу curl<br />
--rsync-options- дополнительные параметры, передаваемые в программу rsync<br />
--wget-options - дополнительные параметры, передаваемые в программу wget<br />
--prozilla-options - дополнительные параметры, передаваемые в программу prozilla<br />
--aria2-options- дополнительные параметры, передаваемые в программу aria2<br />
--limit-rate - ограничить скорость загрузки<br />
--retry-hard - перезапустить программу скачивания файлов в случае ошибки,<br />
выждав время, указанное в опции --download-timeout.<br />
--download-timeout - время ожидания перед очередной попыткой запустить программу скачивания файлов<br />
(актуальна только при использовании опции --retry-hard). <br />
--resume - возобновить загрузку частично загруженных файлов<br />
(--no-resume отключает её; по умолчанию отключена)<br />
--proxy - использовать указанный HTTP-прокси; по умолчанию<br />
используется порт 1080 (формат - <хост_прокси[:порт]>)<br />
--proxy-user - пользователь и пароль для аутентификации на прокси<br />
(формат - <пользователь:пароль>)<br />
--bug - сохранить отчёт об ошибках в каталог, определённый<br />
следующим аргументом<br />
--env - использовать особое окружение (обычно отчёт<br />
об ошибке)<br />
--verify-rpm - проверять подписи rpm перед установкой<br />
(--no-verify-rpm отключает её; по умолчанию включена)<br />
--test - проверить возможность корректной установки<br />
--excludepath - исключить пути, перечисленные через запятую<br />
--excludedocs - исключить файлы документации (docs)<br />
--ignoresize - не проверять дисковое пространство перед установкой<br />
--ignorearch - разрешать устанавливать rpm-файлы для несоответствующих<br />
архитектур<br />
--noscripts - не выполнять scriptlet'ы пакета<br />
--notriggers - не выполнять триггер(ы) пакета<br />
--nofdigests - не проверять дайджест файла(ов) <br />
--fastunsafe - меняет надежность и верификацию на скорость. Альяс к:<br />
--tune-rpm=nofsync<br />
--nofdigests<br />
--no-verify-rpm<br />
--replacefiles - игнорировать конфликты файлов<br />
--repackage - повторно упаковывать файлы перед удалением<br />
--skip - пакеты, установка которых будет пропущена<br />
--prefer - предпочитаемые пакеты<br />
--more-choices - если найдены разные пакеты, предложить больше<br />
вариантов, чем предлагается по умолчанию<br />
--nolock - не блокировать базу данных rpm<br />
--strict-arch - обновить пакеты только с такой же архитектурой<br />
-a - выбрать все совпадения из командной строки<br />
-p - разрешить искать пакеты в provides<br />
-P - не искать пакеты в provides<br />
--quiet, -q - тихий режим (quiet)<br />
--verbose, -v - подробный режим<br />
--debug - очень подробный режим<br />
<br />
</pre><br />
<br />
= {{Программа|urpmi.addmedia}} =<br />
<br />
Всё начинается с добавления репозитория (или «хранилища», «зеркала»). Репозиторий можно добавить с помощью программы {{Программа|urpmi.addmedia}}.<br />
<br />
По умолчанию, установленная ROSA Desktop Fresh уже содержит все основные репозитории. Если же вы хотите подключить дополнительный источник (например, кто-то на форуме посоветовал попробовать пакеты из его персонального репозтория на ABF), вы всегда можете сделать это вручную.<br />
<br />
<pre><br />
urpmi.addmedia имя_источника ftp://ftp.сайт.com/путь/к/ROSA/RPMS<br />
</pre><br />
<br />
Но удобнее использовать программу с графическим интерфейсом (команда {{cmd|edit-urpm-sources.pl}}). Эту же программу можно запустить из центра управления ROSA (раздел «Управление программами», пункт «Настройки источников настройки/обновления ПО»).<br />
<br />
Для каждой версии ROSA имеются четыре репозитория:<br />
* <b>main</b> — содержит наиболее важные программы, поддерживаемые ROSA;<br />
* <b>contrib</b> — содержит дополнительные программы, добавленные участниками сообщества ROSA, но которые не обязательно должны получать обновления по безопасности;<br />
* <b>non-free</b> — содержит некоторые программы, которые не являются свободными.<br />
* <b>restricted</b> — содержит программы, которые могут быть запрещены к использованию в некоторых странах, где действуют патенты на программное обеспечение.<br />
<br />
Каждый репозиторий подразделяется ещё на 3:<br />
<br />
* <b>release</b> — здесь лежат пакеты в том состоянии, в котором они находились на момент выхода релиза;<br />
* <b>updates</b> — здесь лежат пакеты, обновлённые со дня выхода релиза. При добавлении хранилища с обновлениями добавьте переключатель {{cmd|--update}}, чтобы {{Программа|urpmi}} мог отличить это хранилище от обычных хранилищ;<br />
* <b>testing</b> — используется для тестирования свежих обновлений, что позволяет участникам, сообщающим об ошибках, проверить корректность обновлений.<br />
<br />
Чтобы устанавливать пакеты с зеркала, urpmi необходимо предоставить один из файлов, хранящих в сжатом виде либо <i>минимально необходимый</i>, лиюо <i>полный</i> набор данных о пакетах.<br />
<br />
Полный список опций {{Программа|urpmi.addmedia}}<br />
<br />
<pre><br />
Использование: urpmi.addmedia [параметры] <название> <url><br />
где <url> один из:<br />
[file:/]/<путь><br />
ftp://<логин>:<пароль>@<хост>/<путь><br />
ftp://<хост>/<путь><br />
http://<хост>/<путь><br />
cdrom://<путь><br />
<br />
Использование: urpmi.addmedia [параметры] --distrib --mirrorlist <url><br />
Использование: urpmi.addmedia [параметры] --mirrorlist <url> <название> <относительный путь><br />
<br />
Примеры:<br />
<br />
urpmi.addmedia --distrib --mirrorlist '$MIRRORLIST'<br />
urpmi.addmedia --mirrorlist '$MIRRORLIST' backports media/main/backports<br />
urpmi.addmedia --distrib --zeroconf<br />
<br />
<br />
а [параметры] могут быть следующими<br />
--help - показать эту справку<br />
--wget - использовать wget для загрузки удалённых файлов<br />
--curl - использовать curl для загрузки удалённых файлов<br />
--prozilla - использовать prozilla для загрузки удалённых файлов<br />
--aria2 - использовать aria2 для загрузки удалённых файлов<br />
--mirrorbrain - использовать мета-ссылку, созданную на стороне сервера.<br />
--metalink - сгенерировать и использовать локальные метассылки<br />
--limit-rate - ограничить скорость загрузки<br />
--proxy - использовать указанный HTTP-прокси; по умолчанию<br />
используется порт 1080 (формат - <хост_прокси[:порт]>)<br />
--proxy-user - пользователь и пароль для аутентификации на прокси<br />
(формат - <пользователь:пароль>)<br />
--update - создать источник обновления или отбросить<br />
источники без обновлений (при использовании с --distrib)<br />
--xml-info - использовать особую политику для загрузки xml-файлов<br />
варианты: never, on-demand, update-only, always. cf urpmi.cfg(5)<br />
--probe-synthesis - использовать файл synthesis<br />
--probe-rpms - использовать rpm-файлы (вместо synthesis-файла)<br />
--no-probe - не искать файл synthesis<br />
--urpmi-root - использовать другой корень для базы данных urpmi<br />
и установки пакетов<br />
--distrib - автоматически создать все источники из источника<br />
установки<br />
--interactive - (вместе с --distrib) ожидать подтверждения для каждого<br />
из источников<br />
--all-media - (вместе с --distrib) добавить все перечисленные<br />
источники<br />
--virtual - создать виртуальный источник, который всегда<br />
является самым актульным<br />
--no-md5sum - отключить проверку файла MD5SUM<br />
--nopubkey - не импортировать публичный ключ из добавленного источника<br />
--raw - добавить источник в config, но не обновлять его<br />
-q - тихий режим (quiet)<br />
-v - подробный режим<br />
<br />
</pre><br />
<br />
=== Восстановление потерянных источников (cds) ===<br />
<br />
Если в списке хранилищ отсутствуют некоторые CD или DVD, то их можно добавить в список с помощью команды: <pre>urpmi.addmedia --distrib cdrom removable://mnt/cdrom</pre>. В момент запуска команды на исполнения в приводе компакт-дисков должен находиться носитель, который нужно добавить в список.<br />
<br />
{{Примечание|Приведённый формат команды соответствует системам, версия которых ниже 2007.1. Все отсоединяемые устройства теперь монтируются в каталоге ''/media''.}}<br />
<br />
=== Копирование CD в домашний каталог и использование копий в urpmi ===<br />
<br />
Если вам не нравится жонглировать дисками при обновлении системы и у вас есть свободное место, создайте каталог (например: {{Источник|/home/uid/CDS/}}), скопируйте в этот каталог рекурсивно каталоги {{Источник|base/}} и {{Источник|ROSA/}} (т. е. вместе со всем содержимым их вложенных подкаталогов) с первого установочного CD. Затем, скопируйте все каталоги, начиная с {{Источник|RPMS2}} вплоть до {{Источник|RPMS8}}, со всех CD/DVD в каталог {{Источник|ROSA/}}. После извлечения или отключения установочных CD выполните следующую команду от имени суперпользователя root:<br />
<br />
<pre><br />
urpmi.addmedia --distrib HD file://home/uid/CDS<br />
</pre><br />
<br />
По окончании копирования выполните следующие команды:<br />
<br />
<pre><br />
cd /home/uid/CDS<br />
genhdlist<br />
</pre><br />
<br />
Затем, воспользуйтесь менеджером источников. К нему можно получить доступ из центра управления ROSA ({{Меню|центр управления ROSA --> Управление программами --> Настройка источников установки/обновления ПО}}). Выберите созданный вами каталог и отключите все записи, имеющие отношение к CD.<br />
<br />
Другой метод заключается в копировании образов ISO в различные точки монтирования. Подробнее смотри [[#Copy_CDs_to_Hard_Drive_and_mounting_each_in_loopback|копирование CD на жёсткий диск и последующее их монтирование]].<br />
<br />
=== Копирование rpms (включая установочные CD) в отдельный каталог. Использование копии в urpmi ===<br />
<br />
Создайте каталог для хранения всех rpms, например {{Источник|~/RPMS}}<br />
<br />
Чтобы скопировать сразу «кучу» rpms (с установочных CD, например):<br />
<br />
<pre><br />
find /INSTALL_CDS/ -name *.rpm -print -exec cp {} ~/RPMS \;<br />
</pre><br />
<br />
Если вы скопировали установочные CD на жёсткий диск, или у вас есть их образы ISO на диске (о том, как монтировать образы, смотри [[#Copy_CDs_to_Hard_Drive|копирование CD на жёсткий диск]]), это можно сделать за один шаг. <br />
<br />
В этом примере CD монтируются как {{Источник|/INSTALL_CDS/CD1}}, {{Источник|/INSTALL_CDS/CD2}} и т. д. <br />
<br />
<pre><br />
cd ~/RPMS<br />
<br />
genhdlist<br />
</pre><br />
<br />
Это приведёт к созданию файлов {{Источник|hdlist.cz}} и {{Источник|sythesis.hdlist.cz}}, которые основываются на том, что они найдут в каталоге, в котором находятся.<br />
<br />
Найдите публичные ключи для rpms и скопируйте их в {{Источник|~/RPMS/pubkey}}. Они должны находиться в {{Источник|INSTALL_CDS/CD1/media/media_info}}:<br />
<br />
<pre><br />
mkdir ~/RPMS/pubkey<br />
<br />
cp /INSTALL_CDS/CD1/media/media_info/pubkey* ~/RPMS/pubkey/<br />
</pre><br />
<br />
Затем, от имени суперпользователя добавьте источник:<br />
<br />
<pre><br />
urpmi.addmedia local_rpms file://home/uid/RPMS/<br />
</pre><br />
<br />
{{Примечание|Обратите внимание на вкладку «Обсуждение» соответствующей английской статьи.}}<br />
<br />
=== Добавление источника для дистрибутива ===<br />
<br />
{{Программа|urpmi}} может добавить источники (т. е. main, updates, contrib ...) с выбранного зеркала с помощью одной-единственной команды. Наберите в командной строке следующую команду от имени суперпользователя:<br />
<br />
<pre><br />
urpmi.addmedia --distrib ftp://'MIRROR_SITE'/pub/ROSA/official/'VERSION'/'ARCH'<br />
</pre><br />
<br />
где:<br />
* 'MIRROR_SITE' действующий URL сервера ftp;<br />
* 'VERSION' версия вашей системы ROSA, для который вы хотите добавить источник<br />
* 'ARCH' одна из двух архитектур: i586 или x86_64, или возможно другая, которая существует не для всех версий ROSA (например sparc, pcc и т. д.).<br />
<br />
= {{Программа|urpmi.update}} =<br />
<br />
Команда {{cmd|urpmi.update}} обновляет список пакетов репозитория. Этот список меняется всякий раз, когда на сервере меняются пакеты. Таким образом, список необходимо обновлять каждый раз, когда вы захотите установить новый пакет с репозитория, в котором возможны изменения среди пакетов, например ROSA Cooker. Если вы пользуетесь репозиторием стабильного релиза, то такой репозиторий обычно не изменяется, поэтому нет необходимости обновлять список пакетов перед установкой какого-либо пакета. Это работает примерно следующим образом:<br />
<br />
<pre><br />
urpmi.update название_источника<br />
</pre><br />
<br />
или<br />
<br />
<pre><br />
urpmi.update -a<br />
</pre><br />
<br />
Аргумент -a означает "все источники".<br />
<br />
Полный список опций {{Программа|urpmi.update}}:<br />
<br />
<pre><br />
использование: urpmi.update [параметры] <название> ...<br />
где <название> - название обновляемого источника<br />
--help - показать эту справку<br />
--wget - использовать wget для загрузки удалённых файлов<br />
--curl - использовать curl для загрузки удалённых файлов<br />
--prozilla - использовать prozilla для загрузки удалённых файлов<br />
--aria2 - использовать aria2 для загрузки удалённых файлов<br />
--metalink - сгенерировать и использовать локальные метассылки<br />
--limit-rate - ограничить скорость загрузки<br />
--proxy - использовать указанный HTTP-прокси; по умолчанию<br />
используется порт 1080 (формат - <хост_прокси[:порт]>)<br />
--proxy-user - пользователь и пароль для аутентификации на прокси<br />
(формат - <пользователь:пароль>)<br />
--update - обновить только источника с обновлениями<br />
--no-md5sum - отключить проверку файла MD5SUM<br />
--force-key - принудительно обновить gpg-ключ<br />
--ignore - не обновлять, пометить источник как игнорируемый<br />
--no-ignore - не обновлять, пометить источник как включённый<br />
--urpmi-root - использовать другой корень для базы данных urpmi<br />
и установки пакетов<br />
--probe-rpms - не использовать файл synthesis; использовать непосредственно rpm-файлы<br />
-a - выбрать все включенные несъёмные источники<br />
-f - принудительно обновить файл synthesis<br />
-ff - беспрекословно обновить файл synthesis<br />
-q - тихий режим (quiet)<br />
-v - подробный режим<br />
</pre><br />
<br />
= {{Программа|urpmi.removemedia}} =<br />
<br />
Если Вы хотите избавиться от репозитория, используйте следующую команду:<br />
<br />
<pre><br />
urpmi.removemedia nameofmedia<br />
</pre><br />
<br />
Полный список опций {{Программа|urpmi.removemedia}}:<br />
<br />
<pre><br />
использование: urpmi.removemedia (-a | <название> ...)<br />
где <название> - название удаляемого источника.<br />
--help - показать эту справку<br />
-a - выбрать все источники<br />
-y - нечёткое совпадение названий источников<br />
-q - тихий режим (quiet)<br />
-v - подробный режим<br />
--urpmi-root - использовать другой корень для базы данных urpmi<br />
и установки пакетов<br />
</pre><br />
<br />
= {{Программа|urpmf}} =<br />
<br />
С помощью {{Программа|urpmf}} можно узнать, к какому пакету принадлежит тот или иной файл, а также посмотреть описание пакета и т. п.<br />
<br />
Допустим, что вы хотите скомпилировать программу, написанную на языке программирования C, а компилятор жалуется на отсутствие файла {{Источник|jpeglib.h}}. Достаточно набрать следующую команду:<br />
<br />
{{cmd|urpmf jpeglib.h}}<br />
<br />
Например, вывод команды выглядит следующим образом:<br />
<br />
<pre><br />
libjpeg62-devel:/usr/include/jpeglib.h<br />
mozilla-devel:/usr/include/mozilla-1.4a/jpeg/jpeglib.h<br />
</pre><br />
<br />
Это означает, что заголовочный файл {{Источник|jpeglib.h}} является частью пакета {{pkg|libjpeg62-devel}}. Теперь, чтобы его установить, нужно набрать следующую команду:<br />
<br />
{{cmd|urpmi libjpeg62-devel}}<br />
<br />
Другой пример. Допустим, что вы хотите установить почтовый клиент, но вы не знаете ни одного почтового клиента для Linux. Вы можете выполнить поиск по описанию пакетов, используя выражения «mail» и «client». Например, команда {{cmd|urpmf --summary mail -a client}} возвратила следующее: <br />
<br />
<pre><br />
evolution:Integrated GNOME mail client, calendar and address book.<br />
squirrelmail:Squirrelmail is a webmail client for PHP4.<br />
sylpheed-claws:Enhanced version of the Sylpheed e-mail client<br />
comsat:A mail checker client and comsat mail checking server.<br />
cscmail:CSCMail is a GTK email client written in Perl<br />
sylpheed:A GTK+ based, lightweight, and fast e-mail client<br />
tradeclient:Email Client with PIM features for X<br />
</pre><br />
<br />
Параметр {{cmd|--summary}} используется для поиска по описанию. {{cmd|-a}} означает логическое «И».<br />
<br />
Полный список опций {{Программа|urpmf}}:<br />
<br />
<pre><br />
Это свободное программное обеспечение и может распространяться согласно условиям GNU GPL.<br />
<br />
использование: urpmf [параметры] путь-выражение<br />
--help - показать эту справку<br />
--version - показать номер версии программы<br />
--env - использовать особое окружение (обычно отчёт<br />
об ошибке)<br />
--excludemedia - не использовать указанные источники,<br />
перечисленные через запятую<br />
--literal, -l - не искать соответствия шаблону, использовать аргумент<br />
как буквенную строку<br />
--urpmi-root - использовать другой корень для базы данных urpmi<br />
и установки пакетов<br />
--media - использовать только указанные источники,<br />
перечисленные через запятую<br />
--sortmedia - сортировать источники по подстрокам, перечисленным<br />
через запятую.<br />
--use-distrib - использовать указанный путь к источнику<br />
--synthesis - использовать указанный synthesis вместо БД urpmi<br />
--uniq - не выводить идентичные строки<br />
--update - использовать только источник обновления<br />
--verbose - подробный режим<br />
-i - не учитывать регистр в шаблонах<br />
-I - учитывать регистр в шаблонах (по умолчанию)<br />
-F<str> - изменить разделитель полей (по умолчанию - ':')<br />
Выражения для шаблонов:<br />
text - любой текст считается регулярным выражением,<br />
если только не используется -l<br />
-e - включить код perl непосредственно как perl -e<br />
-a - двоичный оператор AND<br />
-o - бинарный оператор OR<br />
! - унарный NOT<br />
( ) - левая и правая скобки<br />
Список тегов:<br />
--qf - выходной формат в стиле printf<br />
пример: '%name:%files'<br />
--arch - архитектура<br />
--buildhost - машина, на которой был собран пакет<br />
--buildtime - время сборки<br />
--conffiles - конфигурационные файлы<br />
--conflicts - конфликтующие теги<br />
--description - описание пакета<br />
--distribution - дистрибутив<br />
--epoch - epoch<br />
--filename - имя пакета<br />
--files - список файлов в пакете<br />
--group - группа<br />
--license - лицензия<br />
--name - имя пакета<br />
--obsoletes - теги obsoletes (устаревшие)<br />
--packager - создатель пакета<br />
--provides - теги provides (предоставляются)<br />
--requires - теги requires (требуются)<br />
--size - установленный размер<br />
--sourcerpm - rpm с исходными кодами<br />
--suggests - теги suggests (рекомендуются)<br />
--summary - сводка<br />
--url - url<br />
--vendor - поставщик<br />
-m - источник, в котором был найден пакет<br />
-f - показать версию, релиз и архитектуру с названием<br />
</pre><br />
<br />
= {{Программа|urpmi}} =<br />
<br />
Это — главная команда программы управления пакетами, которая используется для установки пакетов вместе со всеми зависимостями:<br />
<br />
<pre><br />
urpmi имя_пакета<br />
</pre><br />
<br />
Например, если вы считаете, что {{Программа|Sylpheed}} — достойный для установки почтовый клиент, его можно установить с помощью команды: {{cmd|urpmi sylpheed}}.<br />
<br />
'''Замечание''': команда {{cmd|urpmi имя_пакета}} не обязательно установит последнюю версию пакета. {{Программа|Urpmi}} сравнивает номер версии установленного пакета с номером версии пакета из включённого источника. Исключение составляет тот факт, что иногда обновление пакета доступно под немного иным названием, обе версии пакета, старая и новая, остаются доступными во включённом источнике. Это делается по причинам обратной совместимости. <br />
<br />
Here is a notable example {{cmd|urpmi autoconf}} will not result in the latest version being installed, for the highest version of that package name is autoconf2.5-2.60.<br />
<br />
Вместо этого следует использовать команду {{cmd|urpmi autoconf2.5}}, которая приведёт к установке последней версии 2.5*. <br />
<br />
{{Примечание|Заметьте, что в вашей системе могут быть установлены 2 версии: ROSA автоматически выберет наиболее подходящую. <br />
Для получения более подробной информации по данному примеру смотри ''/usr/share/doc/autoconf-2.13/IMPORTANT.README.MDK''.}}<br />
<br />
Ниже даётся несколько замечаний об использовании команды {{cmd|urpmq —fuzzy}}, разъясняющих, как избежать в будущем подобных проблем с версиями.<br />
<br />
Ещё один пример использования {{Программа|urpmi}} — <b>обновление системы с помощью последних обновлений по безопасности и баг-фиксам</b>.<br />
<br />
<pre><br />
urpmi.update updates && urpmi --update --auto-select<br />
</pre><br />
<br />
В этом примере предполагается, что у {{Программа|urpmi}} есть источник под названием «updates», который был объявлен при добавлении как «источник обновлений». Поскольку содержимое источника обновлений меняется часто, необходимо периодически проверять наличие новых обновлений с помощью urpmi.update. Символы <b>{{cmd|&&}}</b> означают «если первая команда успешно выполнена, выполнить вторую команду». Во второй команде ключ {{cmd|--update}} означает «искать только в источниках, заявленных как обновляемые», а ключ {{cmd|--auto-select}} означает «выбрать доступные обновления для пакетов, установленных в системе». {{Программа|Urpmi}} выведет список пакетов, доступных для обновления, и спросит разрешения о продолжении своей работы.<br />
<br />
Если добавить ключ {{cmd|--auto}}, все обновляемые пакеты будут обновлены, ''' включая''' все требуемые зависимости. Если вы предпочитаете использовать графический интерфейс, воспользуйтесь программой {{Программа|rpmdrake}} из центра управления ROSA: {{Меню|Управление программами}} → {{Меню|Обновление системы}}.<br />
<br />
<br />
<br />
== {{Программа|urpmi --parallel}} ==<br />
<br />
В параллельном режиме работы {{Программа|urpmi}} обновления загружаются на одну из машин, а она в свою очередь раздаёт их остальным компьютерам, входящим в локальную сеть (смотри [http://archives.mandrivalinux.com/expert/2006-03/msg00001.php]).<br />
<br />
Команда {{cmd|urpmi --parallel}} установит обновления на всех определённых вами компьютерах. Подробнее смотри man-страницу {{Программа|urpmi}} ({{cmd|man urpmi}}), а также [http://www.happyassassin.net/2005/05/04/a-quick-guide-to-urpmi-parallel].<br />
<br />
Параллельный режим urpmi работает следующим образом: вы запускаете на выполнение команду {{cmd|urpmi}}, которая выполняется параллельно на нескольких машинах. Машина, на который вы запустили команду, тестирует результат на каждой машине из группы по очереди, загружает все необходимые пакеты для всех машин группы, предоставляет соответствующие пакеты каждый машине, затем, вызывает {{Программа|urpmi}} на машине для выполнения актуальной установки. Это отличная идея для быстрой установки программ на всех ваших компьютерах, или даже для поддержания программного обеспечения на всех компьютерах в актуальном состоянии с помощью нескольких команд, кроме того, это позволяет экономно использовать полосу пропускания канала, так как каждый необходимый пакет загружается только один раз. Единственный недостаток в настоящий момент — вы не можете включить сервер в группу, что является недостатком для малых домашних локальных сетей.<br />
<br />
Итак, как же этом пользоваться. На самом деле, всё просто. Сначала проверьте, что вы можете достучаться с сервера до каждой клиентской машины через {{Программа|ssh}} от имени суперпользователя (вы можете ввести идентификационную фразу или пароль, или можно использовать {{cmd|ssh-add}} для настройки ключей). Итак, надо установить {{pkg|urpmi-parallel-ssh}} на серверной машине, и исправить файл {{Источник|/etc/urpmi/parallel.cfg}}, он должен выглядеть примерно таким образом:<br />
<br />
<pre><br />
local:ssh:toy:htpc<br />
</pre><br />
<br />
первый параметр — имя группы (оставлено на ваше усмотрение), второй параметр оставьте «ssh». Оставшиеся параметры — имя хостов машин в группе. Их может быть сколько угодно (сервер не должен входить в их список: {{Программа|urpmi}} просто откажется работать, обнаружив свои lock-файлы).<br />
<br />
Далее, вы можете использовать этот файл. На сервере наберите команду:<br />
<br />
<pre><br />
urpmi --parallel local somepackage<br />
</pre><br />
<br />
До тех пор, пока {{Программа|urpmi}} на сервере будет иметь доступ ко всем пакетам, необходимым всем клиентским машинам из своих источников urpmi, всё должно работать гладко. Простейший способ гарантировать это — иметь на всех машинах (на сервере и клиентах) одни и те же источники urpmi.<br />
<br />
Кроме того, можно постоянно поддерживать группу машин в актуальном состоянии. Например, чтобы содержать все машины обновлёнными, в домашней сети, которая включает машины zen (сервер), toy и htpc, запустите следующую последовательность команд на zen:<br />
<br />
<pre><br />
fanout "localhost toy htpc" "urpmi.update -a"<br />
</pre><br />
<br />
программа {{Программа|fanout}} запускает одну команду на нескольких машинах одновременно, используя {{Программа|ssh}}.<br />
<br />
<pre><br />
urpmi -auto-select -keep -noclean -v<br />
</pre><br />
<br />
{{cmd|noclean}} оставляет пакеты на машине zen после установки; это значит, что когда команда {{cmd|parallel}} будет запущена в следующий раз, она не станет скачивать эти пакеты заново.<br />
<br />
<pre><br />
urpmi --parallel local -auto-select -keep -v<br />
</pre><br />
<br />
<br />
= {{Программа|urpme}} =<br />
<br />
{{cmd|urpme}} — команда, предназначенная для удаления программного обеспечения с компьютера. Также как и {{Программа|urpmi}}, {{Программа|urpme}} обрабатывает зависимости и извещает пользователя, что установленное программное обеспечение зависит от того программного обеспечения, которое он собирается удалить. В таком случае, у пользователя есть возможность отменить процедуру удаления или удалить пакет вместе с другими зависящими от него пакетами. Использование:<br />
<br />
{{cmd|urpme название_пакета}}<br />
<br />
Например, в системе установлено 2 почтовых клиента: Sylpheed и Evolution. В этом случае, если один из клиентов не используется, его можно удалить. К тому же, таким образом можно освободить немного места на жёстком диске. Чтобы удалить пакет Evolution, воспользуйтесь следующей командой:<br />
<br />
{{cmd|urpme evolution}}<br />
<br />
==Удаление пакет сирот==<br />
<br />
Сначала надо сформировать пакеты сироты после удаления программы:<br />
<br />
urpme --report-orphans <программа><br />
<br />
Потом надо удали сами осиротевшие (не нужные) пакеты:<br />
<br />
urpme --auto-orphans<br />
<br />
Полный список опций {{Программа|urpme}}<br />
<br />
<pre><br />
Это свободное программное обеспечение и может распространяться согласно условиям GNU GPL.<br />
<br />
использование:<br />
--help - показать эту справку<br />
--auto - автоматически выбрать пакет из предлагаемых<br />
--auto-orphans - удалить сирот<br />
--test - проверить возможность корректного удаления<br />
--force - принудительно выполнить, даже если некоторые пакеты<br />
не существуют<br />
--parallel - распределённое выполнение urpmi через машины алиаса<br />
--repackage - повторно упаковывать файлы перед удалением<br />
--root - использовать другой корень для удаления rpm-файлов<br />
--urpmi-root - использовать другой корень для базы данных urpmi<br />
и установки пакетов<br />
--justdb - обновить базу данных, но не изменять файловую систему<br />
--noscripts - не выполнять scriptlet'ы пакета<br />
--notriggers - не выполнять триггер(ы) пакета<br />
--fastunsafe - меняет надежность и верификацию на скорость. Альяс к:<br />
--tune-rpm=nofsync<br />
--use-distrib - настроить urpme на лету из дерева distrib; полезно<br />
для установки/удаления в/из chroot с параметром --root<br />
--verbose, -v - подробный режим<br />
-a - выбрать все пакеты, удовлетворяющие выражению<br />
--report-orphans - вычислять пакеты-сироты после удаления пакетов.<br />
</pre><br />
<br />
= {{Программа|urpmq}} =<br />
<br />
{{Программа|urpmq}} позвляет Вам запрашивать базу данных {{Программа|rpm}}, благодаря чему Вы можете выяснить информацию о пакетах, установленных Вами, а так же о других вещах в базе данных, например о том, какие у Вас имеются источники установки. <br />
<pre><br />
[root@isis root]# urpmq --list-media <br />
contrib<br />
cooker<br />
plf<br />
</pre><br />
Предостережение: Используя {{Программа|urpmq}} для поиска пакетов, удостоверьтесь, что понимаете разницу между использованием его с опцией <i>--fuzzy</i> и без нее. Вы можете не найти некоторые пакеты, которые Вы искали если не будете осторожными. Если {{Программа|urpmq}} находит пакет, название которого точно соответствует Вашему запросу, по умолчанию она выводит только название этого пакета, и Вы не увидите других пакетов, которые содержат то же название.<br />
<br />
Например: <br />
<br />
<pre><br />
<br />
# Представьте, что Ваш лучший друг рассказал Вам о vegastrike, классной 3D-игре.<br />
[root@localhost augustin]# urpmq vegastrike <br />
vegastrike <br />
# Круто! Есть пакет ROSA с точно таким именем!<br />
# Но Вы не видите других пакетов, которые содержат то же мя!<br />
<br />
# Запросим еще раз: обратите внимание на пропущенную 'e' в конце названия пакета<br />
[root@localhost augustin]# urpmq vegastrik <br />
No package named vegastrik<br />
The following packages contain vegastrik: vegastrike, vegastrike-data<br />
You should use "-a" to use all of them<br />
# В этот раз результат запроса сильно отличается<br />
# Мы увидели уже не один, а два пакета. <br />
<br />
# Сравните следующий запрос с предыдущими двумя<br />
[root@localhost augustin]# urpmq --fuzzy vegastrike <br />
vegastrike<br />
vegastrike-data<br />
// Обратите внимание на разницу, которую обеспечивает --fuzzy<br />
</pre><br />
<br />
{{cmd|urpmq --fuzzy}} так же очень полезна, когда нужно узнать какие другие доступные версии пакета имеются: иногда новая мажорная версия не предоставляет полной обратной совместимости. По этой причине, новая версия может распространяться под немного другим именем пакета. Сейчас, Вы уверены, что не пропустите ничего. <br />
<br />
Например:<br />
<br />
<pre><br />
[root@localhost augustin]# urpmi mplayer<br />
#Это не установит последнюю версию проигрывателя<br />
[root@localhost augustin]# urpmq --fuzzy mplayer<br />
The following packages contain mplayer:<br />
kmplayer<br />
mplayer<br />
mplayer-fonts<br />
mplayer-gui<br />
mplayer-skins<br />
mplayer1.0<br />
mplayer1.0-gui<br />
mplayerplugin<br />
transcode<br />
xmms-mplayer<br />
# Видите! Новый релиз 1.0 распространяется под другим названием <br />
# Вы предупреждены!<br />
</pre><br />
<br />
Полный список опций {{Программа|urpmq}}:<br />
<br />
<pre><br />
Это свободное программное обеспечение и может распространяться согласно условиям GNU GPL.<br />
<br />
использование:<br />
--help - показать эту справку<br />
--update - использовать только источник обновления<br />
--media - использовать только указанные источники,<br />
перечисленные через запятую<br />
--searchmedia - использовать только указанные источники для поиска<br />
запрошенных (или обновляемых) пакетов<br />
--excludemedia - не использовать указанные источники,<br />
перечисленные через запятую<br />
--sortmedia - сортировать источники по подстрокам, перечисленным<br />
через запятую.<br />
--synthesis - использовать указанный synthesis вместо БД urpmi<br />
--auto-select - автоматически выбрать пакеты для обновления системы<br />
--auto-orphans - показать список сирот<br />
--not-available<br />
- выводит список установленных пакетов, не доступных ни в одном источнике.<br />
--no-suggests - не выбирать автоматически рекомендованные пакеты<br />
--fuzzy - поиск на основе нечёткой логики (эквивалент -y)<br />
--keep - по возможности сохранять существующие пакеты,<br />
отклонять запрошенные пакеты, которые приводят к удалению<br />
--list - показать список доступных пакетов<br />
--list-media - показать список доступных источников<br />
--list-url - показать список доступных источников и их url<br />
--list-nodes - показать список доступных узлов при использовании --parallel<br />
--list-aliases - показать список доступных алиасов parallel<br />
--dump-config - показать конфигурацию в виде аргумента для urpmi.addmedia<br />
--src - следующий пакет содержит исходные коды (эквивалент -s)<br />
--sources - показать URL исходных кодов выбранных пакетов<br />
--force - принудительно выполнить, даже если некоторые пакеты<br />
не существуют<br />
--ignorearch - разрешить запрашивать rpm-файлы для несоответствующих архитектур<br />
--parallel - распределённое выполнение urpmi через машины алиаса<br />
--root - использовать другой корень для установки rpm-файла<br />
--urpmi-root - использовать другой корень для базы данных urpmi<br />
и установки пакетов<br />
--use-distrib - настроить urpmi на лету из дерева distrib.<br />
Параметр позволяет опросить дерево дистрибутива.<br />
--wget - использовать wget для загрузки удалённых файлов<br />
--curl - использовать curl для загрузки удалённых файлов<br />
--prozilla - использовать prozilla для загрузки удалённых файлов<br />
--proxy - использовать указанный HTTP-прокси; по умолчанию<br />
используется порт 1080 (формат - <хост_прокси[:порт]>)<br />
--proxy-user - пользователь и пароль для аутентификации на прокси<br />
(формат - <пользователь:пароль>)<br />
--env - использовать особое окружение (обычно отчёт<br />
об ошибке)<br />
--changelog - показать журнал изменений<br />
--conflicts - показать конфликты<br />
--obsoletes - показать устаревшие файлы<br />
--provides - показать предоставляемые файлы<br />
--requires - показать требуемые файлы<br />
--suggests - показать рекомендуемые файлы<br />
--sourcerpm - показать исходный rpm-пакет<br />
--summary, -S - показать сводку<br />
--verbose, -v - подробный режим<br />
--requires-recursive, -d<br />
- опросить зависимости пакета<br />
--whatrequires - реверсивный поиск требуемых для пакета файлов<br />
--whatrequires-recursive<br />
- расширенный реверсивный поиск (включая виртуальные пакеты)<br />
--whatprovides, -p<br />
- поиск в provides для поиска пакетов<br />
-a - выбрать все совпадения из командной строки<br />
-c - показать все данные для удаляемого пакета<br />
--evrd - print epoch, version, release and distepoch.<br />
-f - показать версию, релиз и архитектуру с названием<br />
-g - показать группы с названиями<br />
-i - показать информацию в удобной для чтения форме<br />
-l - показать список файлов в пакете<br />
-m - эквивалент -du<br />
-r - показать версию и релиз с названием<br />
-s - следующий пакет содержит исходные коды (эквивалент --src)<br />
-u - удалить пакет, если уже установлена более новая версия<br />
-y - поиск на основе нечёткой логики<br />
(эквивалент --fuzzy)<br />
-Y - эквивалент -y, но без учёта регистра<br />
</pre><br />
<br />
<br />
== gurpmi ==<br />
<br />
{{программа|gurpmi}} — графический фронт-энд для программы {{программа|urpmi}}. Может использоваться из командной строки для установки и поиска пакетов. Используется программой {{программа|rpmdrake}} для отображения сообщений о необходимости выполнения некоторых действий со стороны пользователя.<br />
<br />
== rpmdrake ==<br />
<br />
Для тех же задач ROSA предлагает набор графических инструментов. Подробнее см. [[Tools/MandrivaUpdate|Rpmdrake]].<br />
<br />
== smart ==<br />
<br />
Пакеты {{pkg|smart}}, {{pkg|smart-update}} и {{pkg|smart-gui}}, первоначально использовавшиеся фирмой Conectiva, представляют собой инструменты, основанные на языке программирования Python. Пакеты доступны в {{источник|contrib}}. Эти инструменты отличаются высокой скоростью работы, достаточной надёжностью, а также имеют некоторые преимущества перед оригинальными инструментами ROSA. Официально не поддерживаются. Домашняя страница: [http://labix.org/smart Smart Home]. На данный момент доступны во многих других дистрибутивах.<br />
<br />
= Вопросы безопасности =<br />
<br />
== Проблемы безопасности ==<br />
<br />
Чтобы программа {{программа|urpmi}} могла устанавливать пакеты, она должна быть запущена с привилегиями суперпользователя. Хитрый злоумышленник может обмануть пользователя, подсунув ему пакет для установки. Такие пакеты на первый взгляд выглядят как обычные пакеты, которыми регулярно пользуются множество пользователей, но в данном случае опасность заключается в том, что этот пакет может содержать программу-троян или какой-либо другой вредоносный код. Как только пакет будет установлен в системе, приложение может выпустить в систему какой-нибудь вирус, червя или даже программу-шпиона... До настоящего времени нам неизвестно о попытках использования таких эксплоитов, но в ближайшие несколько лет, когда GNU/Linux получит более широкое распространение, возможно, кто-то захочет попытаться это претворить в жизнь. К счастью, таких людей ждёт неудача, потому что внимание, уделяемое безопасности, всегда было неотъемлимой частью Linux-сообщества. Большинство пакетов имеют подпись, которая подтверждает подлинность пакета. Подробнее см. [[Docs/SysAdmin/Security/GnuPG|GnuPG]].<br />
<br />
Злоумышленник может попытаться внедрить вредоносную программу в пакет. Перед установкой {{программа|urpmi}} проверит целостность пакета, используя хэш-код MD5, и включённый в пакет ключ gpg. Подробнее см. соответствующий раздел.<br />
<br />
Иногда при работе с {{программа|urpmi}} могут быть получены следующие строки:<br />
<br />
<pre><br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
<br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
</pre><br />
<br />
Непонятно, в чём же здесь проблема: может быть файл был повреждён во время обновления, а может, процесс {{программа|urpmi}} был принудительно завершён нетерпеливым пользователем.<br />
<br />
Решение проблемы: удалить файл {{Источник|/var/lib/rpm/Pubkeys}}, повторно импортировать открытые ключи. См. [[Docs/SysAdmin/Security/GnuPG#rpm_package_validation_with_GnuPG_keys|GnuPG]].<br />
<br />
=== Хэширование MD5 ===<br />
<br />
Хэш MD5 представляет собой код, включённый в rpm-пакет. Этот код позволяет {{программа|urpmi}} проверить хэш пакета. Если по каким-либо причинам файл был повреждён, {{программа|rpm}} и {{программа|urpmi}} откажутся его устанавливать. <br />
<br />
Пример:<br />
<br />
<pre><br />
[root@localhost augustin]# urpmi kdesdk<br />
rpmdb: /var/lib/rpm/Pubkeys: unexpected file type or format<br />
error: cannot open Pubkeys index using db3 - Invalid <br />
argument (22)<br />
The following packages have bad signatures:<br />
/var/cache/urpmi/rpms/kdesdk-3.1.3-9mdk.i586.rpm: Invalid <br />
signature ((SHA1) DSA sha1 MD5 GPG GPG#70771ff3 NOT OK)<br />
Do you want to continue installation ? (y/N) y<br />
installing /var/cache/urpmi/rpms/kdesdk-3.1.3-9mdk.i586.rpm<br />
error: /var/cache/urpmi/rpms/kdesdk-3.1.3-9mdk.i586.rpm: MD5 <br />
digest: BAD Expected(97f2ba5a91888cd3af40f89be6b65868) != <br />
(393221db35071aa90eaa73816a9a5ba8)<br />
unable to install package <br />
/var/cache/urpmi/rpms/kdesdk-3.1.3-9mdk.i586.rpm<br />
</pre><br />
<br />
В данном случае было получено два уведомления <i>Invalid signature ((SHA1) DSA sha1 MD5 GPG GPG#70771ff3 NOT OK)</i> и <i>MD5 digest: BAD Expected(97f2ba5a91888cd3af40f89be6b65868) != (393221db35071aa90eaa73816a9a5ba8)</i>. Файл {{Источник|kdesdk-3.1.3-9mdk.i586.rpm}} повреждён и установлен не будет.<br />
<br />
Решение: удалить файл из {{Источник|/var/cache/urpmi/rpms/}} и скачать его заново. Попытаться ещё раз установить его с помощью {{программа|urpmi}} или {{cmd|rpm --import <filename>}}<br />
<br />
Если это не помогло, значит используемое зеркало содержит повреждённый файл. Попытайтесь скачать файл вручную с двух-трёх других зеркал и сохранить его в каталоге {{Источник|/var/cache/urpmi/rpms/}}. Всегда удаляйте вручную предыдущий скачанный файл перед последующей попыткой использования другого зеркала. Затем, установите его снова с помощью {{программа|urpmi}}.<br />
<br />
Если после нескольких попыток будет возникать одна и та же проблема, возможно, что повреждённый файл попал на каждый ftp-сервер. Обратитесь в форум или список рассылки, возможно, что другие пользователи также столкнулись с этой проблемой. В таком случае, скорее всего новый файл появится в ближайшее время.<br />
<br />
= Решение проблем =<br />
<br />
== База данных RPM заблокирована ==<br />
<br />
От имени суперпользователя можно ввести:<br />
<br />
<pre><br />
killall urpmi urpmi.update urpme rpm urpmi.addmedia<br />
rm -f /var/lib/urpmi/.LOCK /var/lib/rpm/.RPMLOCK<br />
</pre><br />
<br />
Если это не разблокирует базу, можно перезагрузить систему.<br />
<br />
С другой стороны, такое использование программы {{программа|killall}} повышает риск повреждения базы данных RPM, так как вы не позволяете программам, работающим с базой, завершить свою работу. Поэтому будьте осторожны, используя данный приём.<br />
<br />
== Пересборка базы данных ==<br />
<br />
Может статься, что база rpm-пакетов поломалась. В таком случае, вы можете получить сообщение, что не установленный пакет уже установлен или наоборот.<br />
Чтобы исправить, воспользуйтесь командами:<br />
<br />
{{cmd|rm -rf /var/lib/rpm/__db}}*<br><br />
{{cmd|rpm --rebuilddb}}<br />
<br />
: * Неплохой идеей может быть периодической резервное копирование директории {{Источник|/var/lib/rpm}}. В этом случае вы всегда сможете вернуть предыдущую рабочую версию такими командами:<br />
<br />
{{cmd|rpm -ivh --justdb --noscripts --notriggers}}<br />
<br />
{{Примечание|В современном rpm5, опция rebuilddb устарела. Для восстановления базы, необходимо использовать соответствующую утилиту {{prog|db_recover}} из berkleydb внутри директории {{file|/var/lib/rpm}}. Например, если в системе используется libdb-5.1, то команда будет выглядеть следующим образом: {{cmd|cd /var/lib/rpm && db51_recover -ev}} }}<br />
<br />
== Ошибка "medium contrib uses an invalid list" ==<br />
<br />
<pre><br />
rm /var/lib/urpmi/list.contrib<br />
</pre><br />
<br />
Эта команда устранит ошибку, не влияя на установку пакетов.<br />
<br />
== RPM package verification ==<br />
<br />
Очень полезным при проверке сломавшейся системы может оказаться проверка установленных пакетов на соответствие базе данных пакетов.<br />
<br />
<pre><br />
rpm -Va<br />
</pre><br />
<br />
Эта команда сообщит вам, какие пакеты изменились с момента установки. Она покажет все несоответствия установленных в системе файлов тому, что должно быть, согласно базе urpmi. При непредвиденном отключении питания, зависании системы и других форс-мажорных обстоятельствах (и человеческом факторе) некоторые файлы могут повредиться или исчезнуть. Узнав, какие пакеты повреждены, вы можете переустановить их и исправить работу системы. Таким образом можно восстановить работоспособность даже незагружающейся системы, войдя в неё при помощи какого-нибудь Live-CD. Для переустановки пакетов используйте команду<br />
<pre><br />
urpmi --replacepkgs пакет_1 пакет_2 …<br />
</pre><br />
<br />
Для проверки одного пакета используйте команду {{Программа|rpm -V имя_пакета}} (достаточно только имени пакета).<br />
<br />
Для проверки контрольной суммы пакета (md5sum), хэша и цифровой подписи gpg:<br />
<br />
<pre><br />
rpm -K foo.123.rpm<br />
</pre><br />
или<br />
<pre><br />
rpm -K foo*<br />
</pre><br />
<br />
= Обновление до последней версии Росы с помощью {{Программа|urpmi}} =<br />
<br />
Urpmi также может быть использован для обновления вышей машины до более новой версии Росы. Для этого необходимо добавить репозитории с новыми пакетами и запустить {{Программа|urpmi --auto-update}}.<br />
<br />
= Другие возможности {{Программа|urpmi}} =<br />
<br />
== Установка пакета из сети и из локального файла ==<br />
<br />
{{Программа|urpmi}} может быть использован для установки локальных файлов {{Источник|rpm}} с разрешением всех зависимостей. Например, если вы собрали новую версию пакета {{Источник|foo-1.0-1bar.rpm}}, вы можете его установить в систему с помощью {{cmd|urpmi foo-1.0-1bar.rpm}}. Более того, в качестве аргумента можно задать ссылку на http или ftp сервер (и даже ssh, при условии, что и на сервере, и на клиенте установлен rsync).<br />
<br />
== Получение списка зависимостей перед установкой ==<br />
<br />
С помощью {{Программа|urpmq}} вы можете получить детальную информацию о зависимостях пакетов rpm. <br />
<br />
* {{cmd|urpmq -d}} выведет список всех пакетов, которые необходимы для установки заданного rpm.<br />
* используйте опцию <b>{{cmd|-m}}</b> для вывода только тех пакетов, которые еще не установлены в системе. <br />
* {{cmd|--sources}} выведет ссылки, с которых будут скачаны необходимые пакеты.<br />
<br />
Таким образом, команда {{cmd|urpmq -d -m --sources}} выведет вам список ссылок на пакеты, которые необходимо доустановить в систему. Такой список полезен, если у вас плохое соединение с Интернет и вы хотите скачать пакеты где-то в другом месте.<br />
<br />
== Получение информации о пакетах ==<br />
<br />
С помощью {{Программа|urpmq -i}} вы можете получить детальную информацию о пакете из репозитория. Попробуйте {{Программа|urpmq -i bash}}.<br />
<br />
= Установка ПО не в формате RPM =<br />
<br />
По возможности, для установки ПО вы должны использовать RPM-пакеты из репозиториев ROSA. Мы уверены, что наши репозитории содержат все необходимое для большинства пользователей. Тем не менее, иногда возникает необходимость поставить программу, отсутствующую в репозитории.<br />
<br />
Старайтесь не устанавливать ПО в обход базы данных RPM. Также не устанавливайте пакеты при помощи {{Программа|rpm --nodeps}}; мы не можем гарантировать, что установленное таким образом ПО будет корректно функционировать и не сломает систему.<br />
<br />
== Компилирование исходных кодов ==<br />
<br />
Вместо уже знакомой тройки команд:<br />
<br />
<pre><br />
./configure<br />
make<br />
make install<br />
</pre><br />
<br />
используйте {{программа|checkinstall}}:<br />
<br />
<pre><br />
./configure<br />
make<br />
checkinstall<br />
</pre><br />
<br />
После этого вы получите пакет, который можно установить с помощью {{Программа|urpmi}}, а потом удалить с помощью этой же программы. Исходный код некоторых приложений уже содержит spec-файл, и вы можете попробовать его использовать для сборки RPM-пакета:<br />
<br />
{{cmd|rpmbuild -tb ballname.tar.gz}}<br />
<br />
=== Установка двоичных пакетов ===<br />
<br />
Такие программы должны находиться в каталоге {{Источник|/usr/local}}. Этот каталог предназначен для хранения неофициальных пакетов.<br />
<br />
=== Проприетарные драйвера ===<br />
<br />
Все проприетарные драйвера находятся в хранилище {{источник|non-free}}. <br />
<br />
=== Пересборка RPMS ===<br />
<br />
Если у вас есть rpm-пакет, собранный для системы, отличающей от вашей, его можно пересобрать. Подробнее см. [[Development/Howto/RPM|сборка пакетов]].<br />
<br />
= Копирование CD/DVD на жёсткий диск и их последующее монтирование =<br />
<br />
Если вам не нравится постоянно менять носители в приводе, вы можете сохранить образы носителей на жёстком диске, настроив {{программа|urpmi}} на использование образов носителей вместо физических носителей.<br />
<br />
Сначала, создайте каталог для образов ISO носителей:<br />
<br />
<pre><br />
mkdir ~/iso<br />
</pre><br />
<br />
Скопируйте все носители в соответствующие каталоги:<br />
<br />
<pre><br />
dd if=/dev/cdrom of=~/iso/cd1<br />
dd if=/dev/cdrom of=~/iso/cd2<br />
dd if=/dev/cdrom of=~/iso/cd3<br />
...<br />
</pre><br />
<br />
От имени суперпользователя создайте точки монтирования для каждого носителя:<br />
<br />
<pre><br />
mkdir /mnt/cd1<br />
mkdir /mnt/cd2<br />
mkdir /mnt/cd3<br />
...<br />
</pre><br />
<br />
Смонтируйте носители с помощью команд:<br />
<br />
<pre><br />
mount -t iso9660 -o loop /home/uid/iso/cd1 /mnt/cd1<br />
mount -t iso9660 -o loop /home/uid/iso/cd2 /mnt/cd2<br />
mount -t iso9660 -o loop /home/uid/iso/cd3 /mnt/cd3<br />
...<br />
</pre><br />
<br />
Внесите изменения в файл {{Источник|/etc/urpmi/urpmi.cfg}}.<br />
<br />
Пример исходного файла:<br />
<pre><br />
Installation\ CD\ 1\ (cdrom1) removable://mnt/cdrom/media/main {<br />
hdlist: hdlist.Installation CD 1 (cdrom1).cz<br />
key-ids: 70771ff3<br />
removable: /dev/hdc<br />
with_hdlist: ../../media/media_info/hdlist1.cz<br />
}<br />
</pre><br />
<br />
Изменённый файл:<br />
<br />
<pre><br />
Installation\ CD\ 1\ (cdrom1) file://mnt/cd1/media/main {<br />
hdlist: hdlist.Installation CD 1 (cdrom1).cz<br />
key-ids: 70771ff3<br />
with_hdlist: ../../media/media_info/hdlist1.cz<br />
}<br />
</pre><br />
<br />
Другими словами, измените ''removable://mnt/cdrom'' на ''file://mnt/cd1'' для каждого носителя cd1, cd2, cd3 и т. д. Также удалите строки, содержащие запись ''removable'':<br />
<br />
<pre><br />
removable: /dev/hdc<br />
</pre><br />
<br />
[[Категория:Управление пакетами]]<br />
[[Категория:Инструменты_разработки]]<br />
<br />
[[en:urpmi]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/ABF:_%D1%80%D0%B0%D0%B7%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D1%83%D0%B5%D0%BC_Pull_Request&diff=15645Блог:Точка Росы/ABF: разблокируем Pull Request2016-12-14T05:37:05Z<p>D uragan: D uragan переименовал страницу Блог:Точка Росы/ABF: разаблокируем Pull Request в Блог:Точка Росы/ABF: разблокируем Pull Request</p>
<hr />
<div>За годы разработки РОСЫ мы получили тысячи Pull Request’ов от добровольных помощников из сообщества (в частности, [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%22%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%22-Howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95 запросы на обновление тех или иных программ]). Жизненный путь большинства запросов очень прост — разработчик изучает предлагаемые изменения, и если все в порядке, то просто нажимает кнопку {{Cmd|Смерджить}}, после чего нажатием еще одной кнопки отправляет новую версию программы на сборку. Итого — если изменения выглядят корректными, то от разработчика требуется всего два клика мышкой.<br />
<br />
Чтобы подобный сценарий был осуществим, необходимо еще одно условие (помимо корректности изменений) — {{Prog|Git-сервер ABF}} должен быть в состоянии автоматически перенести ваши изменения в репозитории РОСЫ. Понять, так это или нет, очень просто — если сразу после создания запроса он находится в состоянии {{Var|Готов к мерджу}}, то все хорошо. Если же он сразу оказался в состоянии {{Var|Заблокирован}}, то что-то пошло не так и для принятия ваших изменений разработчикам придется приложить существенно больше усилий, чем пара кликов мышкой. Однако вы можете им помочь, изменив свой проект так, чтобы изменения все-таки можно было перенести автоматически.<br />
<br />
Первым делом убедитесь, что вы сделали запрос на изменение в нужную ветку Git-репозитория (ветка соответствует имени платформы — {{Macro|rosa2014.1}}, {{Macro|rosa2016.1}} и так далее).<br />
<br />
Если с ветками все в порядке, то причиной блокировки вашего запроса является параллельное внесение изменений в проект другими участниками. Поясним это, рассмотрев типичный процесс подготовки изменений:<br />
<br />
# пользователь создает «форк» проекта, который хочет изменить, в свой репозиторий;<br />
# пользователь вносит необходимые изменения в свою копию проекта;<br />
# пользователь создает запрос на изменение (Pull Request) в исходный проект.<br />
<br />
Если за время, когда пользователь вносил изменения в свой проект, кто-то изменил исходный проект (например, принял Pull Request от другого пользователя), то с большой вероятностью {{Prog|ABF}} не сможет автоматически влить изменения. Именно в такой ситуации и получится заблокированный Pull Request. Строго говоря, если вы изменяли одни файлы, а разработчик — другие, то блокировки не будет. Однако специфика сборки rpm-пакетов такова, что при внесении любых изменений вам надо как минимум пересобрать пакет с поднятием версии или релиза, а для этого надо изменить spec-файл. Поэтому 99 % изменений в проекте изменяют и spec-файл, как следствие — почти всегда параллельные изменения приводят к невозможности автоматически их объединить.<br />
<br />
Итак, что же делать в такой ситуации?<br />
<br />
== Путь первый - самый простой ==<br />
Удалите свой проект на ABF и повторите весь процесс сначала - форкните исходный проект себе в репозиторий, внесите свои изменения (вы ведь не забыли сохранить локальную копию своего проекта перед его удалением на ABF?) и заново отправьте Pull Request.<br />
<br />
Вместо удаления своего проекта вы можете сделать форк исходного с другим именем (при форке проекта вы можете задать любое имя) и в дальнейшем работать с ним.<br />
<br />
Такой подход не займет много времени и хорошо подходит для большинства случаев. Однако стоит помнить, что при этом вы потеряете историю собственных изменений. Если эта история вам дорога, то можно воспользоваться альтернативным способом.<br />
<br />
== Путь второй - самый правильный ==<br />
ABF выполняет слияние изменений с помощью команды {{Cmd|git merge}}. Блокировка запроса случается в том случае, если эта команда завершается неудачей. Разрешение проблем в такой ситуации требует вмешательства человека; вмешаться в процесс вливания изменений в проект РОСЫ пользователь не может, однако он может проделать процесс в обратном направлении - перенести с помощью {{Prog|Git}} все изменения из исходного проекта в свой.<br />
<br />
Делается это с помощью следующих команд, которые необходимо выполнить внутри директории с клонированным проектом из вашего репозитория (назовем проект '''foo'''):<br />
<br />
$ abf remote import<br />
$ git merge import/<target_branch><br />
<br />
Клиент {{Prog|abf}} немного облегчает жизнь - то же самое непосредственно с помощью {{Prog|git}} можно проделать следующим образом:<br />
<br />
$ git remote add import https://abf.io/import/<project_name>.git<br />
$ git fetch import<br />
$ git merge import/<target_branch><br />
<br />
Команда {{Cmd|git merge}} сообщит вам, что в определенных файлах обнаружены конфликты. Вам надо просмотреть каждый из этих файлов и найти места конфликтов, отмеченные разделителями "<<<<" и ">>>>". Каждое из таких мест необходимо отредактировать и привести к тому виду, который они должны иметь с вашей точки зрения. Когда все готово, необходимо закоммитить ваши изменения:<br />
<br />
$ git commit <перечень_измененных_файлов> -m "Merge upstream changes"<br />
$ git push<br />
<br />
После этого можно снова отправлять Pull Request - на сей раз он не должен оказаться заблокированным.<br />
<br />
Для тех, кто не хочет ограничиваться формальным знанием нужных "заклинаний", а хочет понять их суть, отсылаем к [https://git-scm.com/book/ru/v1/Ветвление-в-Git-Удалённые-ветки руководству по системе Git].<br />
<br />
В завершении хотелось бы призвать наших добровольных помощников не оставлять свои запросы в состоянии "заблокирован", а по возможности вливать изменения, сделанные на стороне РОСЫ. Как ни удивительно, но "разблокировать" запрос со стороны пользователя проще, чем со стороны разработчика.<br />
{{wl-publish: 2016-12-14 08:34:31 +0300 | D uragan }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/ABF:_%D1%80%D0%B0%D0%B7%D0%B0%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D1%83%D0%B5%D0%BC_Pull_Request&diff=15646Блог:Точка Росы/ABF: разаблокируем Pull Request2016-12-14T05:37:05Z<p>D uragan: D uragan переименовал страницу Блог:Точка Росы/ABF: разаблокируем Pull Request в Блог:Точка Росы/ABF: разблокируем Pull Request</p>
<hr />
<div>#перенаправление [[Блог:Точка Росы/ABF: разблокируем Pull Request]]</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/ABF:_%D1%80%D0%B0%D0%B7%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D1%83%D0%B5%D0%BC_Pull_Request&diff=15644Блог:Точка Росы/ABF: разблокируем Pull Request2016-12-14T05:36:06Z<p>D uragan: оформление</p>
<hr />
<div>За годы разработки РОСЫ мы получили тысячи Pull Request’ов от добровольных помощников из сообщества (в частности, [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%22%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%22-Howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95 запросы на обновление тех или иных программ]). Жизненный путь большинства запросов очень прост — разработчик изучает предлагаемые изменения, и если все в порядке, то просто нажимает кнопку {{Cmd|Смерджить}}, после чего нажатием еще одной кнопки отправляет новую версию программы на сборку. Итого — если изменения выглядят корректными, то от разработчика требуется всего два клика мышкой.<br />
<br />
Чтобы подобный сценарий был осуществим, необходимо еще одно условие (помимо корректности изменений) — {{Prog|Git-сервер ABF}} должен быть в состоянии автоматически перенести ваши изменения в репозитории РОСЫ. Понять, так это или нет, очень просто — если сразу после создания запроса он находится в состоянии {{Var|Готов к мерджу}}, то все хорошо. Если же он сразу оказался в состоянии {{Var|Заблокирован}}, то что-то пошло не так и для принятия ваших изменений разработчикам придется приложить существенно больше усилий, чем пара кликов мышкой. Однако вы можете им помочь, изменив свой проект так, чтобы изменения все-таки можно было перенести автоматически.<br />
<br />
Первым делом убедитесь, что вы сделали запрос на изменение в нужную ветку Git-репозитория (ветка соответствует имени платформы — {{Macro|rosa2014.1}}, {{Macro|rosa2016.1}} и так далее).<br />
<br />
Если с ветками все в порядке, то причиной блокировки вашего запроса является параллельное внесение изменений в проект другими участниками. Поясним это, рассмотрев типичный процесс подготовки изменений:<br />
<br />
# пользователь создает «форк» проекта, который хочет изменить, в свой репозиторий;<br />
# пользователь вносит необходимые изменения в свою копию проекта;<br />
# пользователь создает запрос на изменение (Pull Request) в исходный проект.<br />
<br />
Если за время, когда пользователь вносил изменения в свой проект, кто-то изменил исходный проект (например, принял Pull Request от другого пользователя), то с большой вероятностью {{Prog|ABF}} не сможет автоматически влить изменения. Именно в такой ситуации и получится заблокированный Pull Request. Строго говоря, если вы изменяли одни файлы, а разработчик — другие, то блокировки не будет. Однако специфика сборки rpm-пакетов такова, что при внесении любых изменений вам надо как минимум пересобрать пакет с поднятием версии или релиза, а для этого надо изменить spec-файл. Поэтому 99 % изменений в проекте изменяют и spec-файл, как следствие — почти всегда параллельные изменения приводят к невозможности автоматически их объединить.<br />
<br />
Итак, что же делать в такой ситуации?<br />
<br />
== Путь первый - самый простой ==<br />
Удалите свой проект на ABF и повторите весь процесс сначала - форкните исходный проект себе в репозиторий, внесите свои изменения (вы ведь не забыли сохранить локальную копию своего проекта перед его удалением на ABF?) и заново отправьте Pull Request.<br />
<br />
Вместо удаления своего проекта вы можете сделать форк исходного с другим именем (при форке проекта вы можете задать любое имя) и в дальнейшем работать с ним.<br />
<br />
Такой подход не займет много времени и хорошо подходит для большинства случаев. Однако стоит помнить, что при этом вы потеряете историю собственных изменений. Если эта история вам дорога, то можно воспользоваться альтернативным способом.<br />
<br />
== Путь второй - самый правильный ==<br />
ABF выполняет слияние изменений с помощью команды {{Cmd|git merge}}. Блокировка запроса случается в том случае, если эта команда завершается неудачей. Разрешение проблем в такой ситуации требует вмешательства человека; вмешаться в процесс вливания изменений в проект РОСЫ пользователь не может, однако он может проделать процесс в обратном направлении - перенести с помощью {{Prog|Git}} все изменения из исходного проекта в свой.<br />
<br />
Делается это с помощью следующих команд, которые необходимо выполнить внутри директории с клонированным проектом из вашего репозитория (назовем проект '''foo'''):<br />
<br />
$ abf remote import<br />
$ git merge import/<target_branch><br />
<br />
Клиент {{Prog|abf}} немного облегчает жизнь - то же самое непосредственно с помощью {{Prog|git}} можно проделать следующим образом:<br />
<br />
$ git remote add import https://abf.io/import/<project_name>.git<br />
$ git fetch import<br />
$ git merge import/<target_branch><br />
<br />
Команда {{Cmd|git merge}} сообщит вам, что в определенных файлах обнаружены конфликты. Вам надо просмотреть каждый из этих файлов и найти места конфликтов, отмеченные разделителями "<<<<" и ">>>>". Каждое из таких мест необходимо отредактировать и привести к тому виду, который они должны иметь с вашей точки зрения. Когда все готово, необходимо закоммитить ваши изменения:<br />
<br />
$ git commit <перечень_измененных_файлов> -m "Merge upstream changes"<br />
$ git push<br />
<br />
После этого можно снова отправлять Pull Request - на сей раз он не должен оказаться заблокированным.<br />
<br />
Для тех, кто не хочет ограничиваться формальным знанием нужных "заклинаний", а хочет понять их суть, отсылаем к [https://git-scm.com/book/ru/v1/Ветвление-в-Git-Удалённые-ветки руководству по системе Git].<br />
<br />
В завершении хотелось бы призвать наших добровольных помощников не оставлять свои запросы в состоянии "заблокирован", а по возможности вливать изменения, сделанные на стороне РОСЫ. Как ни удивительно, но "разблокировать" запрос со стороны пользователя проще, чем со стороны разработчика.<br />
{{wl-publish: 2016-12-14 08:34:31 +0300 | D uragan }}</div>D uraganhttp://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/ABF:_%D1%80%D0%B0%D0%B7%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D1%83%D0%B5%D0%BC_Pull_Request&diff=15643Блог:Точка Росы/ABF: разблокируем Pull Request2016-12-14T05:34:31Z<p>D uragan: Новая страница: «За годы разработки РОСЫ мы получили тысячи Pull Request'ов от добровольных помощников из сооб…»</p>
<hr />
<div>За годы разработки РОСЫ мы получили тысячи Pull Request'ов от добровольных помощников из сообщества (в частности, [http://wiki.rosalab.ru/ru/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/%22%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9_%D1%81%D0%B0%D0%BC%22-Howto_%D0%B4%D0%BB%D1%8F_%D0%B6%D0%B5%D0%BB%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D1%82%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B_%D0%B2_%D0%A0%D0%9E%D0%A1%D0%95 запросы на обновление тех или иных программ]). Жизненный путь большинства запросов очень прост - разработчик изучает предлагаемые изменения, и если все в порядке, то просто нажимает кнопку "Смерджить", после чего нажатием еще одной кнопки отправляет новую версию программы на сборку. Итого - если изменения выглядят корректными, то от разработчика требуется всего два клика мышкой.<br />
<br />
Чтобы подобный сценарий был осуществим, необходимо еще одно условие (помимо корректности изменений) - Git-сервер ABF должен быть в состоянии автоматически перенести ваши изменения в репозитории РОСЫ. Понять, так это или нет, очень просто - если сразу после создания запроса он находится в состоянии "Готов к мерджу", то все ok. Если же он сразу оказался в состоянии "Заблокирован", то что-то пошло не так и для принятия ваших изменений разработчикам придется приложить существенно больше усилий, чем пара кликов мышкой. Однако вы можете им помочь, изменив свой проект так, чтобы изменения все-таки можно было перенести автоматически.<br />
<br />
Первым делом убедитесь, что вы сделали запрос на изменение в нужную ветку Git-репозитория (ветка соответствует имени платформы - {{Macro|rosa2014.1}}, {{Macro|rosa2016.1}} и так далее).<br />
<br />
Если с ветками все в порядке, то причиной блокировки вашего запроса является параллельное внесение изменений в проект другими участниками. Поясним это, рассмотрев типичный процесс подготовки изменений:<br />
<br />
# пользователь создает "форк" проекта, который хочет изменить, в свой репозиторий;<br />
# пользователь вносит необходимые изменения в свою копию проекта;<br />
# пользователь создает запрос на изменение (Pull Request) в исходный проект.<br />
<br />
Если за время, когда пользователь вносил изменения в свой проект, кто-то изменил исходный проект (например, принял Pull Request от другого пользователя), то с большой вероятностью ABF не сможет автоматически влить изменения. Именно в такой ситуации и получится заблокированный Pull Request. Строго говоря, если вы изменяли одни файлы, а разработчик - другие, то блокировки не будет. Однако специфика сборки rpm-пакетов такова, что при внесении любых изменений вам надо как минимум пересобрать пакет с поднятием версии или релиза, а для этого надо изменить spec-файл. Поэтому 99% изменений в проекте изменяют и spec-файл, как следствие - почти всегда параллельные изменения приводят к невозможности автоматически их объединить.<br />
<br />
Итак, что же делать в такой ситуации?<br />
<br />
== Путь первый - самый простой ==<br />
Удалите свой проект на ABF и повторите весь процесс сначала - форкните исходный проект себе в репозиторий, внесите свои изменения (вы ведь не забыли сохранить локальную копию своего проекта перед его удалением на ABF?) и заново отправьте Pull Request.<br />
<br />
Вместо удаления своего проекта вы можете сделать форк исходного с другим именем (при форке проекта вы можете задать любое имя) и в дальнейшем работать с ним.<br />
<br />
Такой подход не займет много времени и хорошо подходит для большинства случаев. Однако стоит помнить, что при этом вы потеряете историю собственных изменений. Если эта история вам дорога, то можно воспользоваться альтернативным способом.<br />
<br />
== Путь второй - самый правильный ==<br />
ABF выполняет слияние изменений с помощью команды {{Cmd|git merge}}. Блокировка запроса случается в том случае, если эта команда завершается неудачей. Разрешение проблем в такой ситуации требует вмешательства человека; вмешаться в процесс вливания изменений в проект РОСЫ пользователь не может, однако он может проделать процесс в обратном направлении - перенести с помощью {{Prog|Git}} все изменения из исходного проекта в свой.<br />
<br />
Делается это с помощью следующих команд, которые необходимо выполнить внутри директории с клонированным проектом из вашего репозитория (назовем проект '''foo'''):<br />
<br />
$ abf remote import<br />
$ git merge import/<target_branch><br />
<br />
Клиент {{Prog|abf}} немного облегчает жизнь - то же самое непосредственно с помощью {{Prog|git}} можно проделать следующим образом:<br />
<br />
$ git remote add import https://abf.io/import/<project_name>.git<br />
$ git fetch import<br />
$ git merge import/<target_branch><br />
<br />
Команда {{Cmd|git merge}} сообщит вам, что в определенных файлах обнаружены конфликты. Вам надо просмотреть каждый из этих файлов и найти места конфликтов, отмеченные разделителями "<<<<" и ">>>>". Каждое из таких мест необходимо отредактировать и привести к тому виду, который они должны иметь с вашей точки зрения. Когда все готово, необходимо закоммитить ваши изменения:<br />
<br />
$ git commit <перечень_измененных_файлов> -m "Merge upstream changes"<br />
$ git push<br />
<br />
После этого можно снова отправлять Pull Request - на сей раз он не должен оказаться заблокированным.<br />
<br />
Для тех, кто не хочет ограничиваться формальным знанием нужных "заклинаний", а хочет понять их суть, отсылаем к [https://git-scm.com/book/ru/v1/Ветвление-в-Git-Удалённые-ветки руководству по системе Git].<br />
<br />
В завершении хотелось бы призвать наших добровольных помощников не оставлять свои запросы в состоянии "заблокирован", а по возможности вливать изменения, сделанные на стороне РОСЫ. Как ни удивительно, но "разблокировать" запрос со стороны пользователя проще, чем со стороны разработчика.<br />
{{wl-publish: 2016-12-14 08:34:31 +0300 | D uragan }}</div>D uragan