Викилоги

Инструмент PkgDiff разработан для визуализации изменений в файлах и атрибутах пакетов любых форматов и предназначен для использования мэйнтейнерами и QA-инженерами с целью контроля изменений и предотвращения внесения незапланированных изменений в репозитории ПО, которые могут нарушить сборку или функционирование других пакетов. Одними из самых многочисленных элементов в структуре дистрибутива Linux являются системные библиотеки. Средний дистрибутив содержит несколько тысяч библиотек. При этом они имеют огромное число зависимостей между собой. По этой причине неаккуратное обновление одной библиотеки может нарушить сборку и функционирование других библиотек и в итоге привести к отказу пользовательских приложений.

В новой версии инструмента PkgDiff 1.6 мы добавили возможность проверки совместимости изменений в библиотеках. Это стало возможным благодаря новому инструменту ABI Dumper, который может извлекать информацию об ABI библиотеки из соответствующих debug-файлов, которая затем может быть проанализирована инструментом ABI Compliance Checker. Для проверки совместимости двух пакетов A и B (старая и новая версии одного пакета), пользователь должен подать на вход инструменту соответствующие debug-пакеты и запустить его с дополнительной опцией -details:

pkgdiff -old A-debuginfo.rpm -new B-debuginfo.rpm -details

В отчете добавлена секция ABI Status, в которой показан уровень обратной совместимости API и ABI библиотеки в процентах. Для просмотра детализированных отчетов о совместимости необходимо найти в отчете таблицу Debug Info Files и перейти по ссылкам в колонке Detailed Report.

При компиляции ELF-объектов, таких как разделяемые библиотеки, модули ядра Linux и др., с дополнительной опцией -g, в них добавляется отладочная информация. Эта информация обычно используется стандартным отладчиком gdb для предоставлению пользователю дополнительных возможностей при поиске ошибок во время выполнения программы. С помощью опции -debug-dump утилиты readelf или eu-readelf (из пакета elfutils) данная информация может быть представлена в удобном для прочтения виде.

Важной частью любого ELF-объекта является его бинарный интерфейс (ABI), предоставляемый использующим его приложениям. По-сути он является представлением API объекта на бинарном уровне (после компиляции). При обновлении ELF-объекта в дистрибутиве, важно поддерживать его ABI обратно совместимым, иначе это может привести к нарушению работы приложений. Изменения в ABI вызываются соответствующими изменениями в API объекта или изменением конфигурации сборки и опций компиляции. Чтобы отслеживать изменения в ABI объекта используется разработанный нами ранее инструмент ABI Compliance Checker. Но до настоящего времени он мог анализировать только разделяемые библиотеки посредством извлечения информации об ABI из заголовочных файлов.

Для того, чтобы расширить границы применения и успростить использование инструмента ABI Compliance Checker, мы применяем новый инструмент ABI Dumper для извлечения ABI-информации из отладочной информации объектов. Теперь, с помощью этого инструмента можно отслеживать изменения в ABI не только библиотек, но и, например, модулей ядра. Типичный пример использования заключается в создании дампов ABI для старой и новой версии объекта:

abi-dumper libtest.so.0 -o ABIv0.dump
abi-dumper libtest.so.1 -o ABIv1.dump

и последующем их сравнении:

abi-compliance-checker -l libtest -old ABIv0.dump -new ABIv1.dump

К сожалению, у данного подхода есть свои недостатки. Пожалуй, главным недостатком является невозможность проведения некоторых проверок совместимости. Например, нет возможности проверки изменений значений констант (как дефайнов, так и глобальных данных), так как эти значения подставляются в код при компиляции и отсутствуют в отладочной информации. В целом, могут быть проведены около 98 % всех проверок совместимости. Еще одним недостатком является долгое время работы на больших объектах размером более 50 мб. Для сжатия debug-информации и следовательно уменьшения размеров входных объектов может быть использована утилита dwz.

В РОСЕ доступен packaging-tools — набор скриптов для мэйнтейнеров, изначально разработанный в Ark Linux.

Набор включает генератор spec-фалов для произвольных пакетов — vs — который создает заготовку spec-файла и открывает ее в vim (или в редакторе, заданном в переменных EDITOR или VISUAL). Также предоставляются специализированные генераторы spec-файлов для пакетов определенных типов:

vl

для библиотек

vp

для модулей Perl

vj

для Java-пакетов

Эти генераторы создают заготовки spec-файлов, учитывающие специфику конкретного типа пакетов (например, создаются необходимые подпакеты для библиотек, прописываются используемые в РОСЕ пути установки для Java и так далее).

Ущу один полезный скрипт — это e, небольшая обертка для gendiff. Если вы хотите подготовить патч для некоторого пакета, то вам следует распаковать архив с исходным кодом и отредактировать необходимые файлы с помощью e. На самом деле, этот скрипт вызовет внешний редактор (указанный в переменных EDITOR или VISUAL; по умолчанию используется vim), сохранив перед этим исходный файл с суффиксом rosa2012.1~ (используемый суффикс можно переопределить с помощью опции -s). После внесения всех необходимых модификаций в исходный код, вызовите gendiff для создания патча.

Например, вот так можно подготовить патч для файла test.c из исходного кода someapp-1.2.3 с помощью редактора geany.

 $ tar xzvf someapp-1.2.3.tar.xz
 $ cd someapp-1.2.3
 $ export EDITOR=geany
 $ e test.c
 $ cd ..
 $ gendiff someapp-1.2.3 .rosa2012.1~ >my.patch

Этот способ может показаться немного сложным, но он действительно удобен, если вам необходимо подготовить небольшой патч для исходного кода большого объема.

Поддержка обратной совместимости внешних API интерфейсов является одной из наиболее важных задач при разработке библиотек. Это позволяет проще портировать существующие приложения на новые версии библиотек. Конечно это относится в первую очередь к библиотекам у которых уже есть применения, но и немаловажно для новых библиотек, поскольку при выборе библиотеки часто обращают внимание не только на функциональность, но и на стабильность. Совместимость бывает трех видов: на уровне исходных кодов, бинарная и функциональная. Наличие совместимости на уровне исходных кодов и функциональной совместимости позволяет портировать приложения путем их пересборки без необходимости модификации кода. Бинарная же совместимость является наиболее сильным уровнем совместимости и позволяет запускать старые приложения без их пересборки.

Наиболее сложно поддерживать совместимость C++ библиотек, так как, по сравнению с Си-библиотеками, дополнительно используются манглинг имен функций и виртуальные таблицы, создаваемые компилятором для реализации полиморфизма классов. Виртуальные таблицы могут меняться нелинейным образом при изменении в объявлении классов (добавление или удаление функций, базовых классов, атрибутов наследования и т.д.) и любое такое изменение может привести к неопределенному поведению или падению приложений. Для контроля за составом виртуальных таблиц мы создали специальный инструмент Vtable Dumper, который печатает содержимое всех виртуальных таблиц найденных в бинарных файлах библиотеки. Таким образом можно сравнить вывод инструмента для старой и новой версии библиотеки, найти и предотвратить случайные изменения.

Пример использования инструмента:

vtable-dumper /usr/lib64/libstdc++.so.6

Стоит заметить, что существует альтернативный способ изучения состава виртуальных таблиц с помощью опции -fdump-class-hierarchy компилятора GNU G++. Однако входными данными для его работы являются заголовочные файлы библиотеки и необходима их компиляция, которая может произойти с ошибками и потребовать дополнительных опций, порядка включения файлов и др. Кроме того, заголовочные файлы в отличие от бинарных файлов библиотеки не всегда установлены в системе. Форматы вывода обоих инструментов практически идентичны. Дополнительно инструмент Vtable-Dumper показывает параметры виртуальных функций в таблице и их mangled-имена (опция -mangled).

Далее приведен пример отображения инструментом содержимого виртуальной таблицы одного из классов библиотеки libQtGui:

 Vtable for QIconEnginePlugin
 _ZTV17QIconEnginePlugin: 22 entries
 0     (int (*)(...)) 0
 8     (int (*)(...)) (& _ZTI17QIconEnginePlugin)
 16    (int (*)(...)) QIconEnginePlugin::metaObject() const
 24    (int (*)(...)) QIconEnginePlugin::qt_metacast(char const*)
 32    (int (*)(...)) QIconEnginePlugin::qt_metacall(QMetaObject::Call, int, void**)
 40    (int (*)(...)) QIconEnginePlugin::~QIconEnginePlugin()
 48    (int (*)(...)) QIconEnginePlugin::~QIconEnginePlugin()
 56    (int (*)(...)) QObject::event(QEvent*)
 64    (int (*)(...)) QObject::eventFilter(QObject*, QEvent*)
 72    (int (*)(...)) QObject::timerEvent(QTimerEvent*)
 80    (int (*)(...)) QObject::childEvent(QChildEvent*)
 88    (int (*)(...)) QObject::customEvent(QEvent*)
 96    (int (*)(...)) QObject::connectNotify(char const*)
 104   (int (*)(...)) QObject::disconnectNotify(char const*)
 112   (int (*)(...)) __cxa_pure_virtual
 120   (int (*)(...)) __cxa_pure_virtual
 128   (int (*)(...)) -0x00000000000010
 136   (int (*)(...)) (& _ZTI17QIconEnginePlugin)
 144   (int (*)(...)) _ZThn16_N17QIconEnginePluginD1Ev
 152   (int (*)(...)) _ZThn16_N17QIconEnginePluginD0Ev
 160   (int (*)(...)) __cxa_pure_virtual
 168   (int (*)(...)) __cxa_pure_virtual

Выпуск стабильных обновлений для дистрибутива Linux — непростая задача. Необходимо убедиться, что все пользовательские приложения продолжат корректно функционировать после обновления. Их можно разбить на две группы — базовые (из дистрибутива) и персональные (самостоятельно установленные пользователем из других источников). Базовые приложения можно относительно легко проверить, установив их в обновленный дистрибутив и вручную проверив их функциональность. О приложениях же второй группы разработчикам дистрибутива ничего не известно. Поэтому проверяют не только работоспособность приложений, но и детально изучают список всех изменений в пакетах.

Совместимость изменений в системных библиотеках можно проверять с помощью инструмента ABI Compliance Checker. Для проверки изменений в остальных пакетах мы разработали инструмент DistDiff. С помощью этого инструмента можно визуализировать изменения во всех пакетах дистрибутива и быстро их просмотреть на предмет нарушения совместимости. На вход этому инструменту надо лишь предоставить две директории — со старыми и новыми пакетами. В режиме по-умолчанию инструмент проверяет изменения в интерфейсных файлах (библиотеки, модули, скрипты, исполняемые файлы и т. д.), потенциально влияющих на совместимость, но может проверять и все файлы с помощью опции -all-files.

Работает инструмент на основе разработанного нами ранее инструмента PkgDiff для сравнения и визуализации изменений в пакетах.

Наши разработчики стараются улучшить и дополнить любую программу, с которой имеют дело.

Поэтому они создали ещё 5 патчей для загрузчика GRUB2. Патчи были отправлены в апстрим GRUB2 и приняты.

→ продолжить чтение…

Нашими разработчиками был сделан патч для настройщика GRUB2 — kcm-grub2. Патч исправляет ошибку, тянущуюся с момента выхода GRUB2 версии 2.00.

Начиная с версии 2.00, изменилась структура меню загрузчика — появились вложенные меню. В связи с этим стало невозможно с помощью настройщика GRUB2 выбрать пункт по умолчанию, когда этот пункт находится во вложенном меню.

После применения патча эта опция заработала. Также список пунктов загрузки в настройщике теперь строится с учётом вложенных меню.

Патч был отослан в апстрим настройщика и будет обязательно встроен в следующую версию.

Команда «Точки РОСЫ» представляет вам первоапрельский выпуск нашего бюллетеня. Он рассчитан на тех читателей, кто ценит хорошую шутку. Даже если она имеет совершенно серьезный формат. Надеемся, вы сможете отличить вымысел от правды. Присылайте свои варианты на адрес rosa-point@rosalab.ru.

Первые 50 правильно ответивших читателей, получат наши фирменные футболки.

А пока давайте перейдем к нашим текущим новостям!

ROSA на собственном компьютере — это замечательно, но нередко возникают ситуации, когда вы хотите работать в привычной среде на чужих машинах, сменить ОС на которых вы не можете.

Во многих случаях спасет режим livecd, в котором можно загрузить и РОСУ. Однако хотя Live-режим позволяет делать многое, не трогая основную машину, у него есть как минимум три недостатка:

• сохранить результаты вашей работы вы можете сохранить на жесткий диск компьютера, но вот сохранить их на флешку, с которой загрузилась система, не так-то просто;
• нет возможности изменить настройки системы, сохранить их и использовать при последующих загрузках;
• наконец, запись ISO-образ на флешку для загрузки в Live-режиме подразумевает использование всей флешки целиком — даже если у вас «объемный» носитель на десятки гигабайт, вам придется перед записью образа

сохранить все данные с флешки в какое-то другое место.

Всех этих недостатков лишен дистрибутив MagOS Linux. Сборки MagOS традиционно формировались на основе Mandriva, а с недавних пор стал доступен вариант на основе ROSA Marathon.

Сборки дистрибутива доступны по адресу http://magos.sibsau.ru/repository/dist/. Сборка на основе ROSA Marathon имеет суффикс 2012lts (на момент написания заметки последней сборкой был MagOS_2012lts_20130228.tar.gz).

Сборка представляет собой обычный тарболл с тремя директориями — boot, MagOS, MagOS-Data. Архив необходимо распаковать и скопировать эти три директории на флешку. Существующие данные с накопителя удалять не нужно, однако имейте в виду — системе понадобится около 2Гб места,

Обратите внимание, что флешка должна быть смонтирована без опции noexec, чтобы иметь возможность запускать скрипты непосредственно с нее (это понадобиться только для превращения флешки в загрузочную). ROSA использует эту опцию по умолчанию, поэтому необходимо подключить накопитель вручную из командной строки. Для этого запустите консоль с правами суперпользователя (например, нажмите Alt-F2 и введите «kdesu konsole») и выполните команду:

 mount -o remount,exec /dev/sdx /mount_point 

где:

• /dev/sdx — файл устройства, соответствующей вашей флешке,
• /mount_point — директория, куда она смонтирована.

Теперь скопируйте директории boot, MagOS, MagOS-Data в директорию /mount_point, перейдите в директорию /mount_point/boot/syslinux и запустите скрипт install.lin.

Вас спросят, уверены ли вы, что хотите сделать устройство загрузочным; чтобы согласиться, нажмите Enter.

После этого выйдите из директории /mount_point и отмонтируйте флешку командой umount /mount_point.

А теперь перезагрузите машину и загрузитесь с флешки — перед вами предстанет меню загрузки MagOS Linux, предлагающее на выбор три варианта загрузки.

Система основана на ROSA, однако для по умолчанию для KDE используется стандартный вид, без SimpleWelcome и RocketBar.

Помимо KDE, можно выбрать Gnome и LXDE; для этого необходимо завершить сеанс пользователя, после чего выбрать тип сессии. Имя/пароль пользователя по умолчанию — user/magos.

MagOs Linux можно установить на флешку не только из под Linux, но и из-под Windows. Можно ее установить и на обычную машину — в качестве самостоятельной системы, либо «внутрь» уже установленной Windows.

Более подробную документацию можно найти на вики MagOS.

Консорциум The Linux Foundation представил обновленную версию (4.1.8) инструмента Linux Application Checker (AppChecker), предназначенного для анализа совместимости приложений с различными дистрибутивами Linux, а также для их тестирования на соответствие стандарту Linux Standard Base (LSB). В настоящее время в базе данных AppChecker’а для платформы x86 содержатся сведения о 84 дистрибутивах, среди которых теперь есть и ROSA 2012 Marathon. Мы планируем и в дальнейшем сотрудничать с инженерами Linux Foundation, предоставляя им необходимую информацию о релизах ROSA.

AppChecker проверяет совместимость приложения с конкретным дистрибутивом, сопоставляя набор требуемых ему разделяемых библиотек и бинарных символов с наборами библиотек и символов, предоставляемых ОС. Удовлетворение таких зависимостей является необходимым условием успешного запуска программы в ОС — если какая-то библиотека или символ отсутствуют, то запуск приложения в дистрибутиве невозможен. Список необходимых приложению библиотек и бинарных символов получается на основе анализа исполнимых бинарных файлов приложения (в формате ELF) и разделяемых библиотек. Естественно, учитываются только те зависимости, которые не удовлетворяются библиотеками самого приложения. Фактически, AppChecker эмулирует работу загрузчика при старте приложения; если в системе нет необходимых библиотек или функций, приложение просто не запустится (либо упадет, если используется «ленивое» связывание).

Стоит отметить, что AppChecker содержит данные не обо всех библиотеках, имеющихся в репозиториях системы, а только о достаточно распространенных. Более точно — гарантируется точность информации о библиотеках из этого списка — http://linuxbase.org/navigator/browse/rawlib.php?cmd=display-approved, насчитывающего чуть менее полутора тысяч библиотек, в то время как репозитории большинства дистрибутивов, в том числе и ROSA, содержат несколько тысяч библиотек. Если приложение использует библиотеку не из этого списка, то AppChecker честно сообщит, что не располагает сведениями о ее присутствии в различных дистрибутивах.

В качестве примера использования, можно проверить, что распространяемая с сайта http://mozilla.org сборка браузера Firefox (на момент написания этой заметки — версии 19.0.2) не может быть использована в устаревших системах, таких как Fedora 10 или Ubuntu 9.04.

Команда «Точки РОСЫ» с радостью представляет вам новый выпуск нашего бюллетеня. Он первый для нас в новом 2013 году. Год обещает быть очень интересным. Взять хотя бы тот факт, что «Точка РОСЫ» изменит формат. Этот выпуск будет последним, который вы получите в виде файла. В марте мы планируем перейти на web-вариант, обновляемый непрерывно.

Конечно же не стоит забывать про грядущие анонсы и обновления наших продуктов!

Впереди многочисленные улучшения ABF, исправления ROSA Desktop Fresh, новые релизы сервера... Да много чего, не будем раскрывать карты раньше времени :).

А пока давайте перейдем к нашим текущим новостям!

Как многие из вас наверняка знают, мы осуществляем постоянный мониторинг репозиториев РОСЫ с целью выявления потенциальных проблем в пакетной базе. Постоянно обновляемые результаты этого мониторинга для линейки Desktop уже долгое время доступны на сайте http://fba.rosalinux.ru (к слову, недавно мы добавили новый тип отчетов — «File Conflicts» — выявляющий пакеты, содержащие одинаковые файлы, но не помеченные явно как конфликтующие с помощью тега Conflicts).

Однако Desktop не является единственным направлением разработки РОСЫ; не менее важным продуктом является линейка серверных операционных систем — ROSA Enterprise Linux Server (RELS). С недавних пор на FBA доступны отчеты о состоянии репозиториев и этой ОС. В настоящее время для RELS предоставляются те же виды отчетов, что и для ROSA Desktop, за исключением анализа альтернатив (которые планируется добавить в обозримом будущем).

Как можно видеть из отчетов, пакетная база RELS находится в очень хорошем состоянии — типичными цифрами для подобных отчетов являются десятки и сотни потенциальных проблем, в то время как для RELS процент проблемных пакетов близок к нулю.

Наши программисты разработали улучшение для настройщика GRUB2 (kcm-grub2). Добавлена функция выбора языка загрузчика. Это удобно в тех случаях, когда пользователю нужно, чтобы язык загрузчика был отличен от языка системы.

Можно выбрать «язык системы», и тогда поведение как настройщика, так и скрипта обновления конфигурации GRUB2 (update-grub2) будет стандартным: язык загрузчика будет таким же, как язык системы.

Помимо того, можно выбрать конкретный язык, например, «English» или «Русский». Тогда в результате обновления конфигурации (путём сохранения новой конфигурации настройщиком GRUB2 или путём вызова скрипта update-grub2) при загрузке мы увидим меню GRUB2 на выбранном языке.

Патч, добавляющий опцию выбора языка загрузчика, был отправлен в upstream и будет встроен в следующую версию программы.

«bash: foo: команда не найдена» — часто видите подобное сообщение? А хочется, чтобы кроме этого было еще и написано, почему она не найдена? Скажем, не установлен нужный пакет, или просто опечатка. Вероятно, не так уж мало людей зависали после следующих действий:

 $ rpmbuild
 bash: rpmbuild: команда не найдена
 
$ sudo urpmi rpmbuild
  Нет пакета с названием rpmbuild
  Следующие пакеты содержат rpmbuild: java-rpmbuild, rpmbuildupdate
  Чтобы выбрать все, используйте параметр «-a»

В том числе и для таких случаев был создан инструмент command-not-found для ROSA! Он является аналогом инструментов из других дистрибутивов, но для ROSA/Mandriva раньше его не было. Все что нужно для получения более дружественной консоли — установить пакет command-not-found и открыть новый терминал. Попробуйте написать что-то странное:

 $ foo
 Команда foo не найдена. Возможно, имелось в виду:
   Команда 'fio' из пакета пакет 'fio' (contrib)
   Команда 'fop' из пакета пакет 'fop' (main, установлен)
   Команда 'for' из пакета пакет 'execline' (contrib)
   Команда 'zoo' из пакета пакет 'zoo' (restricted)

Замечательно! Я же как раз zoo хотел вызвать, ошибся. (Кстати, замечаем что пакет fop у нас уже установлен, но в этот раз не он нам нужен)

 $ zoo
  Команда 'zoo' найдена в:
     пакет 'zoo' (restricted)
  Вы можете установить его, выполнив:
     urpmi zoo
 Хотите сделать это сейчас? (д/Н)

Все что остается — ввести «д» (или «y»). Не хотите получать предложения установить пакет? Установите переменную окружения COMMAND_NOT_FOUND_TURN_OFF_INSTALL_PROMPT=1, и больше Вам не будут задавать глупых вопросов.

Стоит заметить, что при вызове не через терминал (TTY) программа не будет выполнять никаких проверок и писать чего-то особого, она просто выведет «команда не найдена», как и просто bash. К тому же, что бы command-not-found ни написала, она всегда будет завершена с кодом 127, как это делает bash в таком случае.

Еще одна особенность command-not-found: анализ установленных пакетов и поиск запрашиваемой команды.

 $ ifconfig
  Команда 'ifconfig' найдена в:
     пакет 'net-tools' (main, установлен)
 Файл /sbin/ifconfig существует! Проверьте переменную окружения PATH или вызывайте команду, используя абсолютный путь.

Так же в составе command-not-found поставляется утилита «cnf», которая позволяет делать все то же самое, что описано выше (на самом деле она и вызывается каждый раз, когда bash не может выполнить команду). Иными словами, «cnf foo» даст тот же вывод, как если написать «foo» в консоли. Есть еще один сценарий использования cnf: программа уже установлена, но нужно узнать, из какого пакета она пришла.

Вероятно, к этому моменту Вы уже установили command-not-found. Если да — заметили что вместе с ним установился некий пакет command-not-found-data. Этот пакет содержит базу данных (файл в формате JSON), из которой берется информация при работе cnf. Но так как репозитории постоянно изменяются, информацию из этой базы нужно периодически обновлять, поэтому раз в неделю данный пакет автоматически пересобирается с актульными данными и приходит к Вам вместе с остальными обновлениями.

Надеемся, ваше общение с консолью станет намного более приятным :)

После нескольких месяцев разработки увидела свет первая версия системы автоматизированного тестирования дистрибутивов ROSA Linux, «ROSA Autotest».

На данный момент система работает с ROSA Desktop Fresh 2012 и делает следующее:

• Ежедневно проверяет, появились ли новые установочные ISO-образы для данного дистрибутива на ABF, загружает их на локальную машину для последующего тестирования.
• Проверяет на виртуальных машинах, можно ли с этих образов:
  • запустить ОС в live-режиме.
  • установить ОС.
• Подключает на установленных системах стандартные источники обновлений и выполняет обновление ПО.
• С помощью Autotest (http://autotest.github.com/) запускает несколько тестов на установленных системах:
  • тест средств для работы с часами («hwclock»);
  • стресс-тест для компонентов ядра, отвечающих за работу файловых систем («dbench»);
  • несложные тесты компонентов, отвечающих за поддержку IPv6 («ipv6connect»);
  • и т.д.

В дальнейшем набор тестов планируется существенно расширить.

Результаты тестирования доступны на FBA: http://fba.rosalinux.ru/autotest/.

Вместе с новым годом, на ABF пришла новая сборочная подсистема. Изначально ее можно было использовать ее для сборки пакетов в персональные репозитории, а после успешного тестового периода вся сборка была переведена на нее.

Что вы получаете от использования новой системы сборки?

• улучшенная стабильность, масштабируемость и безопасность; в частности, для пользовательских задач теперь используются временные виртуальные машины;
• возможность отмены уже запущенных заданий (до настоящего времени можно было отменять только задания, ожидающие сборки);
• сокращенный автоматически обновляемый журнал всех стадий процесса сборки в веб-интерфейсе (ранее был доступен только журнал непосредственно сборки). Все подробные журналы также доступны, как и раньше;
• универсальные сборочные клиенты: любой дистрибюутив получит столько клиентов, сколько имеется в наличии в данный момент;
• отличные возможности по поддержке различных дистрибутивов посредством универсальных веб- и сборочных клиентов;
• публикация пакета теперь является транзакцией: в случае ошибки, репозиторий возвращается в исходное состояние. Также добавлен журнал процесса публикации;
• полные журналы для каждого сборочного задания — пакеты и журналы будут доступны непосредственно со страницы сборки после публикации (в настоящее время журналы удаляются после публикации пакета);
• использование mock-urpm для сборки пакетов под РОСУ (ранее использовались специализированные скрипты, которые не могли быть использованы для локальной сборки);
• тег «packager» теперь выставляется автоматически;
• проверка собранного пакета посредством его установки в chroot; если проверка завершается с ошибкой, то вся сборка завершается со статусом «Test Failed» и пакет не публикуется, даже если вы выставили флаг автоматической публикации. Однако собранный пакет не удаляется, и если вы твердо уверены, что с ним все в порядке (например, нужные зависимости собрались в соседнем проекте), то вы можете его опубликовать;
• полное удаление устаревших пакетов при публикации их более новых версий для всех платформ;
• одновременную публикацию заданных 32-битных пакетов как 32-битные, так и 64-битные репозитории для систем, основанных на RHEL;
• возможность давать ссылку на конкретную строчку в файле в веб-интерфейсе, например https://abf.rosalinux.ru/import/e_modules/blob/master/e_modules.spec#L73;
• возможность отката публикации пакета администраторами платформ и репозиториями;
• возможность удалять файлы из файлового хранилища (http://abf-doc.rosalinux.ru/v1/file-store/#destroy-file);
• возможность не использовать персональный репозиторий как источник пакетов, даже если производится сборка в него;
• сбор данных о пакетах (имена, версии, релизы) для RELS (ранее такая информация собиралась только для РОСЫ).

Обратите внимание, что в новой системе сборки для собранных, но не опубликованных проектов, не создаются контейнеры. Это сделано для экономии времени, поскольку во многих случаях контейнеры не нужны, а скачать результирующие пакеты можно непосредственно со страницы с результатами сборки. Однако при необходимости вы можете создать контейнер и подключить его в качестве репозитория, кликнув на соответствующую кнопку в результатах сборки.

Новые возможности ABF — сборка прошла успешно, но собранный пакет не смог поставиться в chroot-окружение. Тем не менее, пакет не удален (его можно скачать наравне с srpm по ссылкам внизу страницы), его можно опубликовать в целевой репозиторий или создать для него контейнер

Что стоит ожидать в ближайшем будущем?

• краткие сообщения о причинах неудачи сборки;
• подключение других персональных платформ при сборки под собственную платформу;
• возможность кеширования chroot-окружений для пакетов — это позволяет ускорить сборку ценой потенциальных проблем безопасности и риском потери возможности пересобрать все пакеты с нуля;
• пакеты в персональных репозиториях будут подписываться ключом, автоматически генерируемым ABF (таким же образом, как это сейчас делается для основных платформ);
• устаревшие пакеты, удаленные после публикации более новых версий, еще будут некоторое время доступны для скачивания; это, в частности, позволит не ломать сборку ISO-образов во время активной работы над пакетной базой;
• возможность использования ABF в роли сервера непрерывной интеграции (Continuos Integration, CI);
• регистрация без приглашений!

Оставайтесь с нами:)

В процессе создания РОСЫ мы не только разрабатываем и адаптируем различные пакеты для дистрибутива, но и работаем над инструментами для разработчиков.

Одним из таких инструментов является API Sanity Checker, предназначенный для полностью автоматической генерации тестов для С/C++ библиотек. Для работы инструмента необходимы только заголовочные файлы с декларациями библиотечных функций (и всех необходимых типов данных). На основе такой информации, API Sanity Checker генерирует тесты, вызывающие каждую из функций библиотеки с необходимыми аргументами. Такие автоматически сгенерированные тесты обычно служат шаблоном для написания более полных наборов (с перебором различных значений параметров, их комбинаций и т.п.).

Инструмент является полностью открытым (исходный код можно найти здесь) и может использоваться (и используется) всеми желающими. Например, не так давно API Sanity Checker был интегрирован во внутренний цикл разработки популярной open-source библиотеки GammaLib. В результате применения инструмента в библиотеке были найдены и исправлены 11 ошибок (https://cta-jenkins.irap.omp.eu/job/gammalib-sanity/).

Мы рекомендуем всем апстрим разработчикам различных Си/C++ библиотек последовать этому успешному примеру. Затрачиваемые ресурсы для создания (автоматической генерации) тестового набора минимальны, а количество найденных ошибок может быть существенным.

Приветствуем вас в нашем предновогоднем выпуске «Точки РОСЫ»! Заканчивается очередной год. Обычно в такое время принято подводить итоги. Что было сделано за прошедший год нашей командой? Результаты более чем интересные:

• Развернута своя собственная инфраструктура разработки на базе ABF — git-репозитории, cреда сборки пакетов и iso-образов дистрибутива. Да-да, подумать только — еще год назад у нас не было собственной сборочной среды! Работа над самой ABF не остановилась, и ее разработчики продолжают нас радовать все новыми и новыми возможностями. Запуск ABF позволил серьезно ускорить работу над нашими дистрибутивами.
• Был выполнен перенос кодовой базы из Kenobi на ABF. Это был очень нелегкий путь, но результаты того стоили.
• Развернута своя собственная wiki cначала на двух, а теперь уже на трех языках.
• Появился собственный форум forum.rosalab.ru, где можно задать вопрос

представителям компании, а иногда даже и разработчикам (и да, форум тоже многоязычный, хотя начиналось все с двух языков).

• Появились сообщества пользователей дистрибутивов ROSA в других странах — Украине, США, Бразилии, Италии, Румынии, Германии;
• За прошедший год были выпущены два релиза — с долговременной поддержкой ROSA Marathon 2012 и дистрибутив для домашних пользователей ROSA Desktop.Fresh 2012 (с самым последним ПО), выпущен серверный дистрибутив — ROSA Enterprise Linux Server. Все они были с энтузиазмом встречены мировым сообществом, вызвали многочисленные публикации не только в России, но и далеко за ее пределами.

Много это или мало, не беремся судить. Но думается, что будущий год будет для нас как минимум не хуже!

Всех с наступающими праздниками, удачно их встретить и провести! Желательно, конечно, подальше от компьютера, но вряд ли это удастся большинству из нас ;).

За последние месяцы мы добавили немало видов отчетов на сайт http://fba.rosalinux.ru, осуществляющий мониторинг репозиториев РОСЫ. Во всем этом множестве отчетов стало легко запутаться, так что мы реорганизовали главное меню:

Работа над добавлением новых разделов постоянно продолжается — в будущем мы планируем добавить отчеты Rpmlint, отчеты по файловым конфликтам, и циклическим зависимостям.

Пробные версии такой статистики можно будет наблюдать на FBA в ближайшем будущем. А пока что разрешите представить еще один новый вид отчетов — статистику по «альтернативам»: зависимостям, которые могут быть удовлетворены сразу несколькими пакетами.

В силу ряда причин, в репозиториях РОСЫ содержится достаточно большое количество пакетов с одинаковыми записями в Provides. В некоторых случаях это обоснованно, однако временами такие альтернативы излишни и только смущают пользователей, получающих кучу вопросов о том, какой именно пакет они хотели бы установить для удовлетворения той или иной зависимости. К сожалению, наличию большого количества альтернатив в последнее время не уделялось должного внимания. Как результат, не все пакеты с одинаковыми записями в Provides действительно являются альтернативами с функциональной точки зрения. Иногда это обусловлено историческими причинами, иногда — результатом некорректной работы генератора зависимостей, иногда — неаккуратным подходом мантейнеров к формированию зависимостей. Как результат, при неправильном выборе альтернативы установленные приложения не работают и приводят к ошибкам наподобие этой.

До сих пор сомнительные и некорректные альтернативы выявлялись и исправлялись от случая к случаю — либо когда мантейнеры лично сталкивались с вызванными ими конфликтами, либо, когда приходил соответствующий запрос от пользователя. Однако теперь мы добавили необходимые средства анализ в FBA (благо, urpm-repograph уже давно умеет делать все необходимое), так что репозитории РОСЫ подвергаются постоянному мониторингу в том числе и на предмет наличия пакетов с одинаковыми Provides.

Результаты мониторинга можно наблюдать здесь — http://fba.rosalinux.ru/test/repomanage_alternatives/.

Если вы считаете, что какие-то альтернативы следует убрать — не стесняйтесь сообщать об этом разработчикам дистрибутива:) Естественно, некоторые дублирования вполне легитимны. Со временем мы будем отделять такие случаи и не считать их ошибками.

Помимо добавления новых отчетов, мы работаем и над улучшением существующих. Так, на многих страницах теперь можно не только узнать имя пакета, в котором есть та или иная ошибка, но и получить список пакетов, зависящих от сломанного. Это особенно актуально при анализе замкнутости репозитория — ведь если какой-то пакет невозможно установить из-за неудовлетворенных зависимостей, то и все зависящие от него пакеты также не могут быть установлены. Поэтому важно оценить — сколько пакетов (и каких) лишится пользователь в результате поломки зависимостей. Например, в отчетах о замкнутости репозиториев можно перейти к табличке Broken Packages; в ней для каждого пакета будет указано, сколько пакетов от него зависит; при клике на цифру будет показан перечень таких пакетов. Если вместо количества пакетов стоит знак вопроса — значит, в репозитории есть более новая версия этого же пакета. Поэтому конкретно от этой версии никто не зависит.

Наконец, еще одно полезное улучшение — имена SRPM-пакетов в отчетах repoclosure теперь являются ссылками на соответствющие проекты в ABF. Так что вы можете со страницы отчета сразу попасть на страницу проекта в ABF, и более того, там сразу будет выбрана необходимая ветка Git-репозитория.

Реализуя концепт, разработанный нашим дизайнером, мы добавили новый функционал для визуальной темы Grub2. Появилась возможность графического оформления неактивных пунктов меню (конкретнее, item_pixmap_style). В результате были созданы тёмные полупрозрачные области с закруглёнными краями. Это создаёт новые возможности для дизайна темы загрузчика.

Также в программе grub-mkfont, которая отвечает за конвертацию шрифтов в понятный для загрузчика формат, мы нашли ошибку. Из-за того, что было невозможно задавать один из параметров (ascent), при попытке отобразить в консоли символы, специфичные для локального языка, например, русского, все символы в консоли начинали отображаться некорректно. После исправления ошибки удалось достичь решения проблем с «артефактами», увеличенным межстрочным расстоянием и недорисованными символами.

Оба изменения отправлены в апстрим и приняты.