NixTux https://nixtux.ru На этом сайте делимся опытом, скриптами и советами в Linux и Свободных программах Mon, 17 Jan 2022 06:48:14 +0000 ru-RU hourly 1 https://wordpress.org/?v=5.8.3 Зависимости в RPM. Автоматически и вручную проставляемые Requires и Provides. Общая концепция https://nixtux.ru/1124 https://nixtux.ru/1124#respond Mon, 17 Jan 2022 06:28:27 +0000 https://nixtux.ru/?p=1124 В системе зависимостей RPM-пакетов есть 2 основные сущности: Provides — предоставляемые пакетом «возможности», Requires — зависимости пакета — какие «возможности» нужны для работы этого пакета. В этой статье рассмотрим их общую концепцию. Это актуально и для пользователей, и для сборщиков пакетов. Рассматривать будем на примере дистрибутива ROSA 12 (rosa2021.1). В Provides всегда есть «имя_пакета = … Читать далее Зависимости в RPM. Автоматически и вручную проставляемые Requires и Provides. Общая концепция

The post Зависимости в RPM. Автоматически и вручную проставляемые Requires и Provides. Общая концепция first appeared on NixTux.]]>
В системе зависимостей RPM-пакетов есть 2 основные сущности:

  • Provides — предоставляемые пакетом «возможности»,
  • Requires — зависимости пакета — какие «возможности» нужны для работы этого пакета.


В этой статье рассмотрим их общую концепцию. Это актуально и для пользователей, и для сборщиков пакетов. Рассматривать будем на примере дистрибутива ROSA 12 (rosa2021.1).

В Provides всегда есть «имя_пакета = эпоха:версия-релиз», дополнительно могут быть произвольные провайды, как версионированные (foo = X), так и нет (foo).
Requires тоже могут быть как версионированными, так и нет.

Существует система автоматизации генерации провайдов (Provides) и зависимостей (Requires), которая позволяет там, где есть таковая техническая возможность, автоматизировать расставление зависимостей между пакетами: один пакет предоставляет «возможность» (Provides), а другой ее требует (Requires).

Provides и Requires могут быть проставлены как автоматически, так и вручную. Команда вида dnf install foo поставит пакет, имеющий foo в Provides, не обязательно называющийся foo.

Рассмотрим пример.
Посмотрим зависимости установленного пакета patchelf:

$ rpm -q --requires patchelf
libm.so.6()(64bit)
libm.so.6(Glibm_2.14)(64bit)
libm.so.6(Glibm_2.2.5)(64bit)
libm.so.6(Glibm_2.3.4)(64bit)
libm.so.6(Glibm_2.32)(64bit)
libm.so.6(Glibm_2.33)(64bit)
libm.so.6(Glibm_2.4)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libm.so.6()(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GlibmXX_3.4)(64bit)
libstdc++.so.6(GlibmXX_3.4.9)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)

То же самое для любого пакета из репозитория, в т.ч. не установленного, можно посмотреть через пакетный менеджер dnf:
sudo dnf repoquery --requires patchelf

Выше перечислено по одной зависимости на строку. Давайте узнаем, какой же пакет предоставляет libm.so.6()(64bit):

$ rpm -q --whatprovides 'libm.so.6()(64bit)'
glibc-2.33-4.x86_64

Если хочется узнать только имя пакета, без версии и пр.:

$ rpm -q --qf '%{name}\n' --whatprovides 'libm.so.6()(64bit)'
glibc

Сделать то же самое для всех пакетов в репозитории, а не только уже установленных, можно так:
sudo dnf repoquery --whatrequires 'libm.so.6()(64bit)'
sudo dnf repoquery --qf '%{name}' --whatrequires 'libm.so.6()(64bit)'

Посмотрим все провайды пакета glibc:

$ rpm -q --provides glibc
/sbin/ldconfig
config(glibc) = 6:2.33-4
glibc = 6:2.33-4
glibc(x86-64) = 6:2.33-4
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.2.5)(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
ld-linux-x86-64.so.2(GLIBC_2.4)(64bit)
ld.so = 6:2.33-4
ldconfig = 6:2.33-4
lib64nss_files2 = 6:2.33-4
libBrokenLocale.so.1()(64bit)
libBrokenLocale.so.1(GLIBC_2.2.5)(64bit)
libCNS.so()(64bit)
libGB.so()(64bit)
libISOIR165.so()(64bit)
libJIS.so()(64bit)
libJISX0213.so()(64bit)
libKSC.so()(64bit)
libSegFault.so()(64bit)
libanl.so.1()(64bit)
libanl.so.1(GLIBC_2.2.5)(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.10)(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.12)(64bit)
libc.so.6(GLIBC_2.13)(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.16)(64bit)
libc.so.6(GLIBC_2.17)(64bit)
libc.so.6(GLIBC_2.18)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.2.6)(64bit)
libc.so.6(GLIBC_2.22)(64bit)
libc.so.6(GLIBC_2.23)(64bit)
libc.so.6(GLIBC_2.24)(64bit)
libc.so.6(GLIBC_2.25)(64bit)
libc.so.6(GLIBC_2.26)(64bit)
libc.so.6(GLIBC_2.27)(64bit)
libc.so.6(GLIBC_2.28)(64bit)
libc.so.6(GLIBC_2.29)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.3.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.30)(64bit)
libc.so.6(GLIBC_2.32)(64bit)
libc.so.6(GLIBC_2.33)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.5)(64bit)
libc.so.6(GLIBC_2.6)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libc.so.6(GLIBC_2.8)(64bit)
libc.so.6(GLIBC_2.9)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libdl.so.2(GLIBC_2.3.3)(64bit)
libdl.so.2(GLIBC_2.3.4)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.15)(64bit)
libm.so.6(GLIBC_2.18)(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libm.so.6(GLIBC_2.23)(64bit)
libm.so.6(GLIBC_2.24)(64bit)
libm.so.6(GLIBC_2.25)(64bit)
libm.so.6(GLIBC_2.26)(64bit)
libm.so.6(GLIBC_2.27)(64bit)
libm.so.6(GLIBC_2.28)(64bit)
libm.so.6(GLIBC_2.29)(64bit)
libm.so.6(GLIBC_2.31)(64bit)
libm.so.6(GLIBC_2.32)(64bit)
libm.so.6(GLIBC_2.4)(64bit)
libmvec.so.1()(64bit)
libmvec.so.1(GLIBC_2.22)(64bit)
libnsl.so.1()(64bit)
libnsl.so.1(GLIBC_2.2.5)(64bit)
libnss_compat.so.2()(64bit)
libnss_db.so.2()(64bit)
libnss_dns.so.2()(64bit)
libnss_files.so.2()(64bit)
libnss_hesiod.so.2()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.11)(64bit)
libpthread.so.0(GLIBC_2.12)(64bit)
libpthread.so.0(GLIBC_2.18)(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.2.6)(64bit)
libpthread.so.0(GLIBC_2.28)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
libpthread.so.0(GLIBC_2.3.3)(64bit)
libpthread.so.0(GLIBC_2.3.4)(64bit)
libpthread.so.0(GLIBC_2.30)(64bit)
libpthread.so.0(GLIBC_2.31)(64bit)
libpthread.so.0(GLIBC_2.4)(64bit)
libresolv.so.2()(64bit)
libresolv.so.2(GLIBC_2.2.5)(64bit)
libresolv.so.2(GLIBC_2.3.2)(64bit)
libresolv.so.2(GLIBC_2.9)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
librt.so.1(GLIBC_2.3.3)(64bit)
librt.so.1(GLIBC_2.3.4)(64bit)
librt.so.1(GLIBC_2.4)(64bit)
librt.so.1(GLIBC_2.7)(64bit)
libthread_db.so.1()(64bit)
libthread_db.so.1(GLIBC_2.2.5)(64bit)
libthread_db.so.1(GLIBC_2.3)(64bit)
libthread_db.so.1(GLIBC_2.3.3)(64bit)
libutil.so.1()(64bit)
libutil.so.1(GLIBC_2.2.5)(64bit)
rtld(GNU_HASH)
should-restart = system

Сделать то же самое для не установленного пакета можно так:
sudo dnf repoquery --provides glibc

Кстати, dnf repoquery можно сокращать до dnf rq:
sudo dnf rq --provides glibc

Откуда же в пакете glibc появился провайд libm.so.6()(64bit)? Найдем эту библиотеку среди файлов этого пакета:

$ rpm -ql glibc | grep libm.so.6
/lib64/libm.so.6

Убедимся, что это 64-разрядная библиотека:

$ file $(realpath /lib64/libm.so.6)
/lib64/libm-2.33.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=2416a17b6d6afdf08c8bc3fd2f4e78c2353a4f88, for GNU/Linux 4.14.0, not stripped

Для пакета, в котором лежит разделяемая библиотека, RPM автоматически формирует провайд по имени библиотеки: libfoo.so.N()(64bit), где libfoo.so.N ­— это soname библиотеки, далее идет значение макроса %_arch_tag_suffix, которое пустое для 32-битных ELF-файлов и имеет значение ()(64bit) для 64-битных.

Проверим soname библиотеки:

$ patchelf --print-soname /lib64/libm-2.33.so
libm.so.6

Обратите внимание, что soname "вшит" в сам ELF-файл и чисто технически не обязан совпадать с именем файла.

Посмотрим на значение макроса %_arch_tag_suffix в 64 и 32-битных случаях:

[user@notb1 ~]$ rpm -E "%_arch_tag_suffix"
()(64bit)
[user@notb1 ~]$ setarch i386 rpm -E "%_arch_tag_suffix"

[user@notb1 ~]$

Этого макроса не было в старых версиях RPM и нет в, например, rpm-build 4.0 в ALT Linux, однако фактические провайды такие же, просто этот "суффикс" не вынесен в макрос.

Мы рассмотрели, почему у RPM-пакета glibc появился провайд (Provides) libm.so.6()(64bit). Теперь рассмотрим, почему у пакета patchelf автоматически появилась зависимость (Requires) libm.so.6()(64bit).

Здесь все просто: в исполняемом ELF-файле /usr/bin/patchelf прописана зависимость от библиотеки libm.so.6, а сам файл является 64-битным, а значит и библиотека нужна 64-битная; соединяем "libm.so.6" и "()(64bit)" и получаем "libm.so.6()(64bit)", что добавляется в зависимости пакета, в котором лежит файл /usr/bin/patchelf.

Посмотрим на список библиотек, необходимых для запуска patchelf:

$ patchelf --print-needed /usr/bin/patchelf
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6

Видите среди них libm.so.6? Это оно!

RPM также поддерживает версионирование символов в библиотеках. Среди зависимостей пакета patchelf выше была такая: libc.so.6(GLIBC_2.33)(64bit). Откуда же взялось (GLIBC_2.33)?

Посмотрим на символы, требуемые ELF-файлом:

$ readelf -a /usr/bin/patchelf | grep @GLIBC_2.33
0000004251e8  004900000007 R_X86_64_JUMP_SLO 0000000000000000 stat64@GLIBC_2.33 + 0
    73: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND [...]@GLIBC_2.33 (10)

Видим, что используется функция stat64, которая появилась в библиотеке glibc версии 2.33. Это было выяснено и записано в ELF-файл на этапе его сборки (компиляции, линковки и пр.).

Посмотрим, из какой библиотеки на самом деле подгружается символ stat64 при запуске patchelf, т.е. какая библиотека предоставляем функцию stat64:

$ LD_DEBUG=symbols /lib64/ld-linux-x86-64.so.2 /usr/bin/patchelf --help
<...>
1968:	symbol=stat64;  lookup in file=/usr/bin/patchelf [0]
1968:	symbol=stat64;  lookup in file=/lib64/libstdc++.so.6 [0]
1968:	symbol=stat64;  lookup in file=/lib64/libm.so.6 [0]
1968:	symbol=stat64;  lookup in file=/lib64/libgcc_s.so.1 [0]
1968:	symbol=stat64;  lookup in file=/lib64/libc.so.6 [0]
<...>

Последней в списке идет libc.so.6, а значит символ взят из нее. Если вы с удивлением прочитали команду выше, то рекомендую почитать man ld-linux (аналог для FreeBSD — man rtld).

Как видите, если предоставляемые библиотекой символы версионированы, то RPM определит зависимость не только от библиотеки, но и от ее минимально необходимой версии.

The post Зависимости в RPM. Автоматически и вручную проставляемые Requires и Provides. Общая концепция first appeared on NixTux.]]>
https://nixtux.ru/1124/feed 0
Как быстро скачать видео с GetCourse на Linux скриптом https://nixtux.ru/1118 https://nixtux.ru/1118#respond Mon, 03 Jan 2022 17:35:30 +0000 https://nixtux.ru/?p=1118 Написал простой скрипт для скачивания видео с GetCourse без перекодирования: https://github.com/mikhailnov/getcourse-video-downloader Некоторые инструкции в интернете предлагают скачивать видео с GetCourse с помощью VLC, однако это требует перекодирования видео. Этот скрипт скачивает видео-уроки с Геткурса без перекодирования. Работает на Linux, BSD, macOS и в др. UNIX-подобных окружениях. Для работы необходимы bash и curl. Сначала найдите ссылку … Читать далее Как быстро скачать видео с GetCourse на Linux скриптом

The post Как быстро скачать видео с GetCourse на Linux скриптом first appeared on NixTux.]]>
Написал простой скрипт для скачивания видео с GetCourse без перекодирования: https://github.com/mikhailnov/getcourse-video-downloader

Некоторые инструкции в интернете предлагают скачивать видео с GetCourse с помощью VLC, однако это требует перекодирования видео.

Этот скрипт скачивает видео-уроки с Геткурса без перекодирования. Работает на Linux, BSD, macOS и в др. UNIX-подобных окружениях.

Для работы необходимы bash и curl.

    Сначала найдите ссылку на видео:

  1. Откройте страницу с видео в браузере Chromium / Google Chrome
  2. Нажмите правой правой кнопкой мыши на видео, выберите «Просмотреть код»
  3. В открывшемся коде найдите: <video id="vgc-player_html5_api" data-master="ДЛИННАЯ_ССЫЛКА"
  4. Скопируйте эту ссылку (ДЛИННАЯ_ССЫЛКА)

Откройте терминал и выполните команду скачивания этого скрипта:
curl -L --output /tmp/getcourse-video-downloader.sh https://github.com/mikhailnov/getcourse-video-downloader/raw/master/getcourse-video-downloader.sh

Затем запустите скрипт:
bash /tmp/getcourse-video-downloader.sh "ДЛИННАЯ_ССЫЛКА" "Имя файла.ts"

Первым аргументом идет ссылка, вторым — имя файла, куда сохранить скачанное, рекомендуемое расширение — ts.

The post Как быстро скачать видео с GetCourse на Linux скриптом first appeared on NixTux.]]>
https://nixtux.ru/1118/feed 0
Лечим ШГ в Thunderbird 91 https://nixtux.ru/1115 https://nixtux.ru/1115#respond Tue, 28 Dec 2021 07:56:10 +0000 https://nixtux.ru/?p=1115 В Thunderbird 91 по сравнению с 78 испортилась отрисовка шрифтов. Стало ШГ. Список писем стало тяжело читать, текст писем тоже. Буквы стали как бы расплывчатыми. Вот здесь VladikSS наглядно показал проблему скриншотами: https://bugzilla.mozilla.org/show_bug.cgi?id=1732583. Как же это исправить, как сделать отрисовку букв нормальной в Thunderbird 91? Открываем редактор расширенных настроек: Далее нужно в поиск вставить: «gfx.webrender.force-disabled», … Читать далее Лечим ШГ в Thunderbird 91

The post Лечим ШГ в Thunderbird 91 first appeared on NixTux.]]>
В Thunderbird 91 по сравнению с 78 испортилась отрисовка шрифтов. Стало ШГ. Список писем стало тяжело читать, текст писем тоже. Буквы стали как бы расплывчатыми. Вот здесь VladikSS наглядно показал проблему скриншотами: https://bugzilla.mozilla.org/show_bug.cgi?id=1732583. Как же это исправить, как сделать отрисовку букв нормальной в Thunderbird 91?

Открываем редактор расширенных настроек:

Далее нужно в поиск вставить: «gfx.webrender.force-disabled», нажать на появившийся результат поиска, чтобы он стал жирным — включенным.

Перезапустить Thunderbird. Текст снова станет легко и приятно читать.

The post Лечим ШГ в Thunderbird 91 first appeared on NixTux.]]>
https://nixtux.ru/1115/feed 0
Установка ROSA 2021.1 по kickstart на сервер в ДЦ https://nixtux.ru/1104 https://nixtux.ru/1104#respond Wed, 25 Aug 2021 14:18:11 +0000 https://nixtux.ru/?p=1104 В видео показывается воспроизводимая установка ROSA Server R12/X5 на удаленный сервер по кикстарт-сценарию. Подробная инструкция здесь: http://wiki.rosalab.ru/ru/index.php/Anaconda Образ ОС: https://abf.io/platforms/rosa2021.1/products/279 (ссылка на YouTube: https://www.youtube.com/watch?v=l7DfYSA3Bdw)

The post Установка ROSA 2021.1 по kickstart на сервер в ДЦ first appeared on NixTux.]]>
В видео показывается воспроизводимая установка ROSA Server R12/X5 на удаленный сервер по кикстарт-сценарию.

Подробная инструкция здесь: http://wiki.rosalab.ru/ru/index.php/Anaconda
Образ ОС: https://abf.io/platforms/rosa2021.1/products/279

(ссылка на YouTube: https://www.youtube.com/watch?v=l7DfYSA3Bdw)

The post Установка ROSA 2021.1 по kickstart на сервер в ДЦ first appeared on NixTux.]]>
https://nixtux.ru/1104/feed 0
Скрытие плашки с IP-адресом в IPMI (BMC) Supermicro. Скрытие элемента сайта в браузере. https://nixtux.ru/1095 https://nixtux.ru/1095#respond Wed, 25 Aug 2021 11:01:20 +0000 https://nixtux.ru/?p=1095 Захотел снять экранное видео, в котором нужно показать графическую консоль управления сервером Supermicro (BMC, IPMI). При записи видео будет виден IP-адрес IPMI, но его «палить» не хочу, чтобы в случае обнаружения уязвимостей в ПО консоли нельзя было прицельно взломать именно мой сервер. Не люблю обрабатывать отснятые видео, поэтому проще скрыть IP-адрес заранее. На скриншоте ниже … Читать далее Скрытие плашки с IP-адресом в IPMI (BMC) Supermicro. Скрытие элемента сайта в браузере.

The post Скрытие плашки с IP-адресом в IPMI (BMC) Supermicro. Скрытие элемента сайта в браузере. first appeared on NixTux.]]>
Захотел снять экранное видео, в котором нужно показать графическую консоль управления сервером Supermicro (BMC, IPMI). При записи видео будет виден IP-адрес IPMI, но его «палить» не хочу, чтобы в случае обнаружения уязвимостей в ПО консоли нельзя было прицельно взломать именно мой сервер. Не люблю обрабатывать отснятые видео, поэтому проще скрыть IP-адрес заранее. На скриншоте ниже показана сама консоль.

Было:

Стало:

Чтобы IP-адрес не был виден в адресной строке браузера, в файл /etc/hosts на своем рабочем ПК добавил строку:

IP-адрес ipmi-miran

Благодаря этому в браузере можно открывать веб-интерфейс BMC не по IP-адресу, а по имени «ipmi-miran». Из адресной строки IP-адрес исчез. Однако он остался в шапке веб-интерфейса. Как же его скрыть?

Установил расширение Adguard для Firefox.
Во встроенных в браузер инструментах разработчика нашел, что в веб-интерфейсе IPMI плашка, которую надо скрыть, находится в HTML-теге td с определенным ID:

Открыл настройки Adguard, раздел «Пользовательские правила».
Добавил следующее правило фильтрации (согласно документации):

ipmi-miran$$td[id="_headermiddle"]

Перезагрузил веб-интерфейс, плашка успешно скрылась:

Именно Firefox потому, что, как пишет документация по Adguard, подобная фильтрация в Chrome/Chromium невозможна.

The post Скрытие плашки с IP-адресом в IPMI (BMC) Supermicro. Скрытие элемента сайта в браузере. first appeared on NixTux.]]>
https://nixtux.ru/1095/feed 0
Цвета файлов RPM в мета-пакетах https://nixtux.ru/1085 https://nixtux.ru/1085#respond Sat, 28 Nov 2020 16:45:57 +0000 https://nixtux.ru/?p=1085 Переделал пакет task-x11 в rosa2019.1: — заменил шрифты dejavu и liberation на freesans, его достаточно для отображения большинства символов — заменил все Requires на Recommends, т.к. на 2019.1 образы собираем с включенной установкой слабых зависимостей, Requires в task-пакетах, мне кажется, не имеют смысла теперь — убрал noarch — добавил зависимости от mesa и в случае … Читать далее Цвета файлов RPM в мета-пакетах

The post Цвета файлов RPM в мета-пакетах first appeared on NixTux.]]>
Переделал пакет task-x11 в rosa2019.1:

— заменил шрифты dejavu и liberation на freesans, его достаточно для отображения большинства символов
— заменил все Requires на Recommends, т.к. на 2019.1 образы собираем с включенной установкой слабых зависимостей, Requires в task-пакетах, мне кажется, не имеют смысла теперь
— убрал noarch
— добавил зависимости от mesa и в случае x86_64 дополнительно от 32-битной mesa (Requires: mesa(x86-32))
— для не-noarch пакетах в зависимостях добавил постфикс %{_isa}, т.е., например:
было: Recommends: xhost
стало: Recommends: xhost%{_isa}
Это раскроется так: Recommends: xhost(x86-64)

На rpm4+dnf можно установить одновременно 64-битный и 32-битный пакеты, даже если в них одинаковые файлы. В rpm это называется file coloring — цвета файлов, на 64-битной системе цвет 64-битных файлов приориоритетнее 32-битных, например, если поставить bash.x86_64 и bash.i686, то /usr/bin/bash будет 64-битным.

Благодаря этому mesa.x86_64 и mesa.i686 могут быть установлены одновременно несмотря на общие файлы /usr/share/drirc.d/

Т.е., если пользователю нужны и 64-битные, и 32-битные зависимости task-x11, он может сделать:
dnf install task-x11.x86_64 task-x11.i686
или
dnf install ‘task-x11(x86-64)’ ‘task-x11(x86-32)’

Спек можно посмотреть здесь: https://abf.io/import/task-x11/blob/rosa2019.1/task-x11.spec
Написанное актуально по состоянию на коммит 69c1b56a38.

The post Цвета файлов RPM в мета-пакетах first appeared on NixTux.]]>
https://nixtux.ru/1085/feed 0
Как работает генератор зависимостей и провайдов devel() RPM https://nixtux.ru/1077 https://nixtux.ru/1077#respond Sun, 22 Nov 2020 13:26:49 +0000 https://nixtux.ru/?p=1077 Записал видео, в котором попытался показать, как работает генератор зависимостей (Requires) и Provides для RPM, автоматизирующий их проставление в RPM-пакетах. devel() зависимости и провайды в дистрибутиве ROSA были в rpm5, для rpm4 в ходе перехода на rpm4 написал работающий по похожей логике генератор на bash. Рассматривается генератор: https://abf.io/import/devel-rpm-generators Также показано, как запускать генератор вручную для … Читать далее Как работает генератор зависимостей и провайдов devel() RPM

The post Как работает генератор зависимостей и провайдов devel() RPM first appeared on NixTux.]]>
Записал видео, в котором попытался показать, как работает генератор зависимостей (Requires) и Provides для RPM, автоматизирующий их проставление в RPM-пакетах. devel() зависимости и провайды в дистрибутиве ROSA были в rpm5, для rpm4 в ходе перехода на rpm4 написал работающий по похожей логике генератор на bash.

Рассматривается генератор: https://abf.io/import/devel-rpm-generators
Также показано, как запускать генератор вручную для его отладки.
Документация по генераторам: https://rpm.org/user_doc/dependency_generators

The post Как работает генератор зависимостей и провайдов devel() RPM first appeared on NixTux.]]>
https://nixtux.ru/1077/feed 0
Выступление на OSDAY-2020. Переход ROSA на RPM 4, задачи пакетной системы и ее улучшение. https://nixtux.ru/1052 https://nixtux.ru/1052#comments Fri, 06 Nov 2020 13:58:49 +0000 https://nixtux.ru/?p=1052 Более восьми лет в дистрибутивах ROSA использовался пакетный менеджер RPM5 — форк RPM4, созданный Джеффом Джонсоном, автором RPM. Долгое время RPM5 развивался гораздо активнее своего родителя, что и обусловило его выбор для ROSA. Однако, постепенно активность по разработке RPM5 угасла, а RPM4 наоборот возродился и постепенно не только вобрал большинство интересных свойств RPM5, но и … Читать далее Выступление на OSDAY-2020. Переход ROSA на RPM 4, задачи пакетной системы и ее улучшение.

The post Выступление на OSDAY-2020. Переход ROSA на RPM 4, задачи пакетной системы и ее улучшение. first appeared on NixTux.]]>
Более восьми лет в дистрибутивах ROSA использовался пакетный менеджер RPM5 — форк RPM4, созданный Джеффом Джонсоном, автором RPM. Долгое время RPM5 развивался гораздо активнее своего родителя, что и обусловило его выбор для ROSA. Однако, постепенно активность по разработке RPM5 угасла, а RPM4 наоборот возродился и постепенно не только вобрал большинство интересных свойств RPM5, но и получил множество новых. В докладе рассмотрены задачи пакетной системы дистрибутива GNU/Linux, накопившиеся проблемы, пути их решения и новые улучшения, сделанные в ходе перехода на RPM 4.

PDF: osday-2020-mikhailnov.pdf

Ниже презентация послайдово в виде картинок и видеозапись.

















The post Выступление на OSDAY-2020. Переход ROSA на RPM 4, задачи пакетной системы и ее улучшение. first appeared on NixTux.]]>
https://nixtux.ru/1052/feed 1
Автоматический статический анализ с помощью PVS Studio при сборке RPM-пакетов https://nixtux.ru/1041 https://nixtux.ru/1041#respond Wed, 14 Oct 2020 09:42:10 +0000 https://nixtux.ru/?p=1041 Возникла задача автоматизировать статический анализ пакетов в составе дистрибутива. Наилучший инструмент для этого — PVS Studio, потому что умеет перехватывать вызовы компилятора с помощью strace, таким образом, не требуя никаких изменений в сборочных скриптах. Сначала под наблюдением pvs-studio-analyzer запускается сборка, собирает лог, затем запускается анализатор этого лога и формируется отчет. Рассмотрим, как такое настроить, избежав … Читать далее Автоматический статический анализ с помощью PVS Studio при сборке RPM-пакетов

The post Автоматический статический анализ с помощью PVS Studio при сборке RPM-пакетов first appeared on NixTux.]]>
Возникла задача автоматизировать статический анализ пакетов в составе дистрибутива. Наилучший инструмент для этого — PVS Studio, потому что умеет перехватывать вызовы компилятора с помощью strace, таким образом, не требуя никаких изменений в сборочных скриптах. Сначала под наблюдением pvs-studio-analyzer запускается сборка, собирает лог, затем запускается анализатор этого лога и формируется отчет. Рассмотрим, как такое настроить, избежав внесения правок в каждый пакет.

В качестве операционной системы будем рассматривать rosa2019.1 (dnf + rpm4). Я использую сборки rootfs и systemd-nspawn (snr). Сначала установим необходимые для работы пакеты:
dnf install git-core bash abf basesystem-build how-to-use-pvs-studio-free

С помощью утилиты how-to-use-pvs-studio-free нужно в исходники добавить заголовки PVS Studio. Эти исходники затем будут отстрипаны от бинарников и попадут в debugsource-подпакеты, которые публикуются в репозиторий. Установим ее из репозитория:
sudo dnf install how-to-use-pvs-studio-free

Ставим саму PVS Studio:

wget  https://files.viva64.com/pvs-studio-latest.rpm -O pvs-studio-latest.rpm
sudo dnf install pvs-studio-latest.rpm

Включаем бесплатную лицензию:
pvs-studio-analyzer credentials PVS-Studio Free FREE-FREE-FREE-FREE

Теперь суть в следующем. Как известно, RPM превращает секцию спека %prep в shell-скрипт /var/tmp/*.sh и запускает его, аналогично делает с секциями %build и %install. Мы сделаем обертку, которая будет запускать эти скрипты вместо %_buildshell (/bin/sh).

Создаем файл /usr/bin/pvs-prep со следующим текстом:

#!/bin/sh
set -eu
sh "$2"
( cd "$1"
how-to-use-pvs-studio-free -c 2 -m .
)

Этот скрипт будет на стадии %prep добавлять шапку с рекламой PVS Studio в исходники.

Создаем файл /usr/bin/pvs-builder со следующим текстом:

#!/bin/bash
set -eu
name="$1"
script="$2"
test -f "$script"
[ -n "$2" ]
/usr/bin/pvs-studio-analyzer trace -- /bin/bash -e "$script"
mkdir -p "$HOME/pvs-logs/raw-logs"
pvs-studio-analyzer analyze -o "$HOME/pvs-logs/${name}" -j "$(nproc)" #-C /usr/bin/clang
rm -fr "$HOME/pvs-logs/html-logs/${name}"
mkdir -p "$HOME/pvs-logs/html-logs/${name}"
plog-converter -a GA:1,2 -t fullhtml "$HOME/pvs-logs/${name}" -o "$HOME/pvs-logs/html-logs/${name}"
mv -v "$HOME/pvs-logs/html-logs/${name}/fullhtml"/* "$HOME/pvs-logs/html-logs/${name}/"
rm -fr "$HOME/pvs-logs/html-logs/${name}/fullhtml"

Этот скрипт будет запускать скрипт %build под трассировщиком PVS Studio, а затем создавать отчет.

Делаем их исполняемыми:
chmod +x /usr/bin/pvs-builder /usr/bin/pvs-prep

Не используем /usr/local/bin, поскольку он не входит в $PATH в RPM.

Теперь в файл /etc/rpm/macros дописываем:

%__spec_prep_cmd /usr/bin/pvs-prep "%{_sourcedir}"
%__spec_build_cmd /usr/bin/pvs-builder %{name}

(см. https://github.com/rpm-software-management/rpm/issues/1399)

И всё. Каждая сборка проекта на C/C++ будет создавать HTML-отчет в папке $HOME/pvs-logs/html-logs/имя_пакета.

Чтобы не мучиться с mock, можно собирать список пакетов так:
cat list_sec_sorted.txt | while read -r line; do pushd $line && dnf builddep --allowerasing -y *.spec && abf rpmbuild ; popd; done
т.е. ставить сборочные зависимости в ту же систему, но разрешать удалять лишние пакеты, если устанавливаемые зависимости текущего пакета конфликтуют с зависимостями одного из предыдущих пакетов.

The post Автоматический статический анализ с помощью PVS Studio при сборке RPM-пакетов first appeared on NixTux.]]>
https://nixtux.ru/1041/feed 0
Автоматизация GDB с помощью xdotool https://nixtux.ru/1035 https://nixtux.ru/1035#respond Sat, 10 Oct 2020 23:37:41 +0000 https://nixtux.ru/?p=1035 Понадобилось в отладчике gdb очень много раз повторить одинаковое действие, чтобы поймать значения переменных, которые были в момент сегфолта. Открыл 2 терминала, в одном запустил программу под gdb, поставил точку остановки (breakpoint), запустил (run), другой средствами оконного менеджера закрепил поверх других окон, запустив в нем: sleep 5; while true ; do xdotool type c && … Читать далее Автоматизация GDB с помощью xdotool

The post Автоматизация GDB с помощью xdotool first appeared on NixTux.]]>
Понадобилось в отладчике gdb очень много раз повторить одинаковое действие, чтобы поймать значения переменных, которые были в момент сегфолта.

Открыл 2 терминала, в одном запустил программу под gdb, поставил точку остановки (breakpoint), запустил (run), другой средствами оконного менеджера закрепил поверх других окон, запустив в нем:
sleep 5; while true ; do xdotool type c && for type in A B ; do xdotool key KP_Enter && xdotool key p && xdotool key space && for i in $type E V R ; do xdotool type $i ; done; done && xdotool key KP_Enter ; sleep 0; if ! ps aux | grep -vE 'gdb|grep' | grep -q '/usr/bin/python3 /usr/bin/livecd-creator' ; then break ; fi; done
Этот код вводит нужные команды в gdb и проверяет, не остановился ли процесс, т.е. не произошел ли сегфолт, а если произошел, то перестает их вводить. Пошел по своим делам, оно само отработало, вернулся, передо мной был наглядный результат.

The post Автоматизация GDB с помощью xdotool first appeared on NixTux.]]>
https://nixtux.ru/1035/feed 0