Викилоги

Одним из направлений развития РОСЫ является избавление от устаревшего инструментария drakxtools. В частности, в ROSA 2012 Desktop мы планируем избавиться ситуации, когда утилиты конфигурации системы находятся в двух местах — обертке DrakConf для различных программ из drakxtools (иконка «Configure Your Computer» в SimpleWelcome) и «Центре управления KDE» и соответствующих инструментах других DE («Configure Your Desktop»). При этом для части утилит из drakxtools центр управления KDE предлагает более удобные аналоги, однако для некоторых программ достойных альтернатив нет.

В приближающемся релизе мы планируем полностью убрать DrakConf, а утилиты, для которых нет альтернатив в KDE, интегрировать в центр управления KDE. Для этого каждая утилита будет обернута в соответствующий KCM-модуль. Процесс интеграции утилит сейчас в самом разгаре, и первые версии KCM-оберток для ряда утилит уже готовы:

kcm-drakauth
kcm-drakfirewall
kcm-drakguard
kcm-drakinvictus
kcm-draksec
kcm-harddrake
kcm-rpmdrake-sources
kcm-rpmdrake
kcm-rpmdrake-update 
kcm-update-freq
kcm-userdrake
kcm-XFdrake

Вы можете также установить пакет drakconf-kde4, вместе с которым будут установлены те kcm-модули, которые мы планируем включить в дистрибутив по умолчанию.

Hardrake будет доступен в секции «Hardware», большинство других утилит — в секции «System Administration».

Как уже было написано в предыдущем выпуске, недавно появился дополнительный к web-интерфейсу способ взаимодействия с ABF — консольный клиент. После того, как последний месяц упорные усилия разработчиков ABF привели к реализации API, это дало большой простор и для разработки клиента.

Правда, далеко не весь потенциал API пока был задействован, в основном упор был сделан на улучшение работы с базовой функциональностью.

Итак, зачем же нужен этот консольный клиент? Рассмотрим жизненный цикл пакета. Пользователь АБФ захотел взять проект, что-то изменить, собрать проект и опубликовать. Начнем по порядку.

Клонирование git-репозитория

Пусть имя проекта мы знаем. Что нужно делать дальше: лезть в web-часть, вводить имя проекта в поиск, выбирать нужный, переходить на страницу проекта и брать адрес проекта в ABF, выполнять «git clone URL». Хотя погодите, а ведь не нужно! Достаточно выполнить «abf get PROJECT». PROJECT — имя проекта, возможно, с владельцем (например, akirilenko/abf-console-client. Если владелец не указан — берется группа по умолчанию).

Внесение изменений

После того как нужные файлы были изменены, можно выполнить «abf put MSG» и выполнится «git add --all», «git commit -m MSG», «git push». Так же нужно все архивы предварительно загрузить на File-Store и изменить содержимое .abf.yml файла, это тоже долгий и рутинный процесс, особенно если речь идет о такой обработке сотни пакетов в день. Клиент же это делает автоматически при выполнении команды put.

Отправка на сборку

Для этого нужно зайти на web-страницу, найти проект, тыкнуть в несколько галочек и отправить на сборку. Казалось бы, не так уж долго. Но если эти однообразные действия нужно проделывать сотни раз в день — проще это делать через консоль, тем более что можно написать простой скрипт, делающий это в автоматическом режиме. Да здравствует автоматизация!

Процесс сборки

Для проверки текущего состояния сборки нужно заходить на страницу в ABF, искать нужное сборочное задание (если их много — еще нужно помнить ID задания). А можно сделать проще — выполнить «abf buildstatus ID», где ID можно опустить и получить информацию о последнем отправленном с консольного клиента задании (подробнее об этом написано дальше).

Публикация

Опциональный шаг, так как, во-первых, можно собирать с автоматической публикацией, во-вторых, публикация не всегда нужна. В любом случае, abf publish ID опубликует собранное задание без проблем.

Как видим, наличие консольного клиента несколько упрощает жизнь, особенно мейнтейнерам дистрибутива. Поэтому мы стараемся чтобы он шел в ногу со временем и развивался в соответствие с требованиями пользователей. Что было сделано в последней версии:

• В процессе работы с git-репозиториями ABF клиент запоминает их пути в системе. Также, если у Вас уже много репозиториев и Вы хотите кэшировать их пути разом — достаточно выполнить «abf locate update-recursive -d PATH», где PATH — директория с репозиториями. Для чего нужно помнить положение репозиториев? Например, теперь в консоли можно выполнить «abfcd PROJECT» (PROJECT — имя проекта, с группой вначале — import/abf-console-client — или без. Если группа отсутствует — берется группа пользователя по умолчанию). Можно просто узнать директорию проекта — «abf locate -p PROJECT». Так же в будущем команда «abf backport» сможет переносить файлы не только между ветвями одного проекта, но и между разными проектами.

• В первых версиях консольный клиент имел лишь зачаточную версию консольного автодополнения, теперь же дополняется практически все: имена опций, ветви git, в «abf build» дополняются имена репозиториев для сборки и для сохранения (причем набор последних зависит от проекта, и потому дополняются только если проект был указан ранее в строке опцией --project/-p). Как результат, работать с консольным клиентом становится гораздо приятнее, ведь не нужно каждый раз писать длинные названия или вспоминать, что же можно указать в --save-to-repository. В первые разы дополнение работает с задержками (порядка 0.5-1 сек), но со временем данные кэшируются и задержки сильно уменьшаются.

• Появилась проверка spec-файла. Можно выполнить «abf clean» в директории git-репозитория, и буден выведен список проблем, найденных в spec-файле. В случае если один из source или patch файлов не может быть найден (если файл был указан не по URL, отсутствует в .abf.yml и отсутствует в директории со spec-файлом), будет выдано сообщение об ошибке. Так же могут быть выданы некоторые предупреждения, например, если файл одновременно указан в .abf.yml и присутствует в директории. Так же выдаются предупреждения о "лишних файлах", которые присутствуют в директории или в .abf.yml, но не требуются для сборки. Команда «abf clean --auto-remove» удалит эти файлы.

Данный тест запускается автоматически при отправке на сборку из директории с проектом. Будут напечатаны все предупреждения, а в случае наличия ошибок задание не будет отправлено. Отменить выполнение проверки при отправке на сборку можно опцией --skip-spec-check.

• При отправке заданий на сборку консольный клиент не только выводит на экран ID отправленных заданий, но и запоминает их и связывает с проектом. Теперь «abf buildtstatus» напишет информацию о последних заданиях, а при указании опции --project/-p (или если Вы в директории git-репозитория) — о последних для данного проекта.

• Что касается работы с API — существенно уменьшено количество ненужных запросов. Дело в том, что запрос, например, репозитория, дает так же частичную информацию о платформе, в которой этот репозиторий находится. Часто этой информации достаточно. Раньше из этого использовался только id, по которому выполнялся еще один API запрос для загрузки всех данных. В результате раньше первый запуск клиента порождал десятки ненужных запросов. Сейчас же создается новый объект «platform» и в него помещается вся доступная информация, а сам объект помечается как «stub». Если же попытаться получить значение поля, которое еще не загружено но должно присутствовать в классе — будет выполнен новый вызов API и вся информация будет загружена.

• Еще одна интересная особенность нового клиента — использование ETag для кэширования данных сервера с автоматической их валидацией. Как результат — без опасности работать с устаревшими данными, получаем ускорение работы. В данный момент ABF не настроен для полной поддержки этой технологии, но в скором времени обработка таких кэшированных запросов будет действительно быстрой, а так же такие запросы не будут влиять на счетчик запросов (напомним, что сейчас установлен лимит в 500 запросов к API в час).

Как видите, развитие продукта не останавливается. Все ваши отзывы (как положительные, так и отрицательные), предложения и пожелания приветствуются.

В блоге РОСЫ на Facebook был опубликован рассказ о наших продуктах, представленных на LinuxCon Europe 2012. А вот некоторые впечатления о других участниках и о конференции в целом.

Конференция была очень насыщенной — доклады шли в пять параллельных потоков. При этом нередко параллельно проходили доклады, предназначенные для схожих целевых аудиторий — так что приходилось делать нелегкий выбор, на что сходить. Частично это компенсировалось доступностью слайдов (сейчас многие презентации можно найти на сайте Linux Foundation и возможностью «отловить» докладчиков в перерывах или вечером на каком-нибудь мероприятии от организаторов — где проходило немало дискуссий на технические темы в неформальной обстановке. Впрочем, и на самой конференции обстановка была далека от формальной — люди приходили, чтобы пообщаться на близкие им темы и узнать что-то новое (а не за футболками, ручками и прочими сувенирами, хотя всяких подарков раздавали множество).

Доклады были как сугубо технические, так и организационно-философского характера. Из популярных технических тем:

• облачные вычисления (спектр представленных компаний и проектов был очень велик — Citrix, Apache Cloudstack, OpenNebula, IBM, HP, и даже Microsoft);
• близкие к ним вопросы виртуализации (в основной части конференции рассказывали и про KVM, и про Xen, а заодно и про решения Parallels, а после основной части прошла серия семинаров про KVM и oVirt);
• отдельная секция была посвящена Tizen (который также активно рекламировался сотрудниками Intel на их стенде);
• в течение целого дня шли семинары про распределенную файловую систему GlusterFS.

Безусловно, лидерами по количеству посетителей являлись доклады приглашенных участников — не только по тому, что параллельно с ними не шло никаких презентаций, но и потому что темы были актуальны, а докладчики — интересны.

Линус Торвальдс обошелся без презентации и какой-то конкретной темы («Я же не знаю, что именно вам интересно» — «Nvidia!» — «На этот вопрос уже дал исчерпывающий ответ:)»), вместо этого получился развлекательно-познавательный диалог с ведущим и залом. Конечно, не все вопросы носили шутливый характер — например, была затронута проблема взаимодействия разработчиков ядра с создателями Android, которые временами сильно затягивают с открытием своих наработок, не говоря уже об их передаче в основную ветку разработки. Создатель ядра Linux не выразил большой озабоченности этим вопросом, предложив вспомнить ситуацию десятилетней давности, когда разработчики ведущих дистрибутивов (RedHat, SUSE) предпочитали поддерживать множество собственных патчей к ядру, а не работать над общей кодовой базой. Постепенно положение дел нормализовалось — хотя разработка многих патчей по-прежнему происходит внутри дистрибутивов, они активно сотрудничают с другими командами — в частности, непосредственно с разработчиками ядра. Торвальдс выразил уверенность, что и в случае с Android будет выработан процесс, выгодный для обеих сторон.

Некоторые сессионные доклады также собрали приличное количество слушателей (так что многим пришлось даже стоять) — например, рассказ Джеймса Боттомли (James Bottomley) о ситуации с UEFI (Джеймс пообещал, что в скором будущем Linux Foundation договорится с Microsoft и подписанный ключом MS загрузчик, который можно будет использовать для загрузки основной системы). Тьяго Масиэйра (Thiago Macieira) с докладом про Qt Project также собрал немало слушателей — многие с интересом следят за постепенным открытием процесса разработки Qt.

По своему опыту скажу, что, например, открытый баг-трекер для Qt — действительно полезная вещь, располагающая к привлечению сторонних участников — имея дело c тестами LSB, мы иногда находим потенциальные ошибки в самом Qt, но еще года два-три назад процесс обработки сообщений о таких ошибках был абсолютно непрозрачен. Временами складывалось впечатление, что некоторые сообщения просто исчезают где-то за интерфейсом заведения отчета об ошибке — без дополнительного общения с разработчиками Qt нельзя было ни посмотреть его статус, ни узнать, работает ли кто-то над его исправлением. Теперь Qt стал гораздо ближе к сообществу. Правда, на вопрос Тьяго «кто из присутствующих подписан на список рассылки разработчиков Qt Project» руку поднял только Ларс Нол (Lars Knoll) — ведущий архитектор проекта.

Помимо докладов, немало информации можно было получить на стендах компаний и проектов. Было немало стендов, связанных с облачными вычислениями и виртуализацией, некоторые стенды демонстрировали дистрибутивы и связанные с ними решения — помимо РОСЫ, в эту категорию попадали Fedora/RedHat, Suse, WindRiver (с прицелом на встраиваемые системы) и ряд других. Представители Oracle рассказывали не только о своем дистрибутиве на основе RedHat, но и о других открытых проектах (в частности, MySQL), заверяя всех, что корпорация нацелена на взаимовыгодное сотрудничество с сообществом.

Усилиями Intel и WindRiver, много внимания было сосредоточено на встраиваемых системах под управлением Linux. Intel вовсю рекламировал Tizen и демонстрировал прототип IVI на его основе. Многие посетители смотрели на Tizen настороженно, памятую о судьбе его предшественников — Moblin и MeeGo, — фактически канувших в небытие.

Также представители Intel вовсю расписывали достоинства использования архитектуры x86 для создания устройств на основе Android — причем одним из ключевых моментов были не достоинства архитектуры как таковой, а удобство разработки. Ведь создание приложений под Android обычно производится на обычной настольной машине (которая в подавляющем большинстве случаев имеет архитектуру x86), а тестирование осуществляется в эмуляторе QEMU. За счет использования аппаратной поддержки виртуализации, производительность QEMU при эмуляции платформы x86 на порядок лучше, чем в случае ARM, что существенно ускоряет тестирование и обкатку приложений (да и просто делает эти процессы более удобными и не столь мучительными).

Интересно, что именно на стенде Intel наиболее активно рекламировался Android — стенд Google также был посвящен этой ОС, но был существенно скромнее, и каких-то агрессивных маркетинговых акций представители интернет-гиганта не проводили.

В общем и целом, LinuxCon Europe 2012 получился очень познавательным и насыщенным - даже рассказ о наиболее запомнившихся аспектах растянулся на пару страниц:).

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

Теперь все основные операции с ABF, за исключением взаимодействия с базой мантейнеров и сборкой продуктов (созданием ISO-образов), могут производиться посредством ABF API.

Документация доступна здесь: http://abf-doc.rosalinux.ru/. В настоящее время ABF API предоставляет около 60 функций.

API находится в стадии «бета» и в будущем возможны изменения, несовместимые с текущей реализацией.

Основным продуктом, где ABF API уже активно используется, является консольный клиент ABF.

Следующее новшество ABF — это встроенные комментарии: теперь ABF позволяет вам комментировать как коммиты целиком, так и обсуждать конкретные строки кода. Теперь вы можете более конкретно обсуждать spec-файлы, патчи или новый код. Попробуйте!

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

Такая ситуация возникает, если пакет с нужной библиотекой не устанавливается по зависимостям, либо содержит библиотеку слишком новой (или слишком старой) версии, в которой отсутствуют нужные функции.

Для автоматического отслеживания подобных случаев, мы настроили на FBA анализ всех ELF-файлов репозиториев РОСЫ с целью сопоставления предоставляемых и требуемых наборов бинарных символов и библиотек. Отчеты автоматически публикуются здесь:

• http://fba.rosalinux.ru/test/elf_closure/

Еще одной проблемой, с которой приходится время от времени сталкиваться при работе над большими репозиториями, является наличие в одном репозитории пакетов, один из которых объявлен устаревшим («obsolete») в пользу другого. Зачастую это вынужденная мера, так как от устаревшего пакета могут зависеть другие проекты, и до их обновления удалить его из репозитория нельзя. Однако имея несколько тысяч пакетов, отслеживать текущую ситуацию с зависимостями и удалять ставшие ненужными пакеты нелегко. FBA теперь помогает и в решении этой задачи, предоставляя отчеты об устаревших пакетах:

• http://fba.rosalinux.ru/test/repomanage_obsoletes/

Всем отличного настроения, и да пребудет с вами удачная компиляция, не глючат программы, а ядро никогда не валится в панику!

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

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

Для сбора и публикации подобной статистики мы разработали отдельный сайт — http://fba.rosalinux.ru/.

FBA производит мониторинг репозиториев РОСЫ, размещенных на ABF, и их анализ с помощью инструментов urpm-tools и Upstream Tracker.

В настоящее время доступны следующие виды отчетов:

• замкнутость репозиториев по зависимостям;
• сравнение версий пакетов с родственными дистрибутивами и с апстримом;
• наличие в репозиториях устаревших пакетов;
• отчеты ROSA Package Popularity о наиболее используемых пакетах;
• отчеты Upstream Tracker об обратной совместимости различных версий библиотек.

Вот уже почти полтора года, как сервис облачного хранения 2Safe работает в режиме тестирования, и очень не многие знают, о том, что этот сервис умеет. Попробуем разобраться по порядку.

Текст рассчитан на узкий круг специалистов и в нем преобладают специфические термины и примеры кода. В общем Developers only.

API полностью покрывает все функции сервиса, чтобы через него абсолютно полноценно его использовать: выполнять всяческие проверки, регистрировать и удалять учетные записи, управлять файлами и многое другое.

Полный список всех функций представлен 2Safe_API, ну а мы попробуем неспешно написать простенький консольный клиент.

Пример может оказаться вполне полезным скажем для скриптования автоматизации наиболее часто выполняемых операций.

Сразу договоримся, что писать мы будем на Perl и будем использовать библиотеку, автор которой Ваш покорный слуга perl-lib2safe. Библиотека доступна в Contrib репозитории ROSA 2012 Marathon и ROSA 2012 Desktop ^[1]
И так устанавливаем:

$ sudo urpmi perl-lib2safe

В библиотеке самую малость изменены названия функций из оригинального API но они не перестали быть понятными. Например list_dir -> ls, copy_file -> cp и т.д. Читаем справку:

$ man lib2safe 

Открываем наш любимый текстовый редактор:

$ vi test2safe-client.pl

И пишем мега-программу:

#!/usr/bin/perl
 
use lib2safe;
 
my $psync = new lib2safe (URL => 'https://api.2safe.com/');
#Кстати можно и без параметров вовсе.
#https://api.2safe.com/ есть дефолтовое значение урла.
 
my $mylogin = $psync->login(login=>'mylogin', password=>'****');
#Вот так вот просто авторизовываемся уже зарегистрированным ранее пользователем.
 
#Проверяем статус авторизации
die('Error Authorize') unless
  ($$mylogin{response}{success} && $$mylogin{response}{success} eq 'true');
 
 
my $ls = $psync->ls();
#без параметров просматривается содержимое
#корневой директории авторизованного пользователя.
 
my $new_dir = $psync->mkdir(dir_id => $$ls{response}{root}{id}, dir_name => 'new_dir');
#Создали в корне новую папочку с именем "new_dir"
 
my $testfile = $psync->put(dir_id => $$new_dir{response}{dir_id}, file => "test2safe-client.pl", name => '2safe-client.pl');
# А тут заливаем во вновь созданную папочку наш скрипт но под другим именем.

Ради справедливости следует заметить, что в примере приведены лишь несколько функций. Всего в библиотеке их реализовано более 40, перечислю лишь разделы:

• Пользовательские функции
• Функции по работе с файловой системой
• Функции по работе с блокировками
• Функции расшаривания и публикации объектов
• Функции по работе с версионностью

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

1. ↑ на текущий момент выпущена только Alpha версия

РОСА содержит тысячи пакетов с различными приложениями, библиотеками и утилитами. Для ряда пакетов мы гарантируем качественную поддержку, для некоторых — только обеспечиваем базовую функциональность.

Чтобы помочь разработчикам РОСЫ узнать, какие пакеты наиболее важны для пользователей, мы подготовили специальный инструмент — rosa-popularity-contest — который собирает статистику о пакетах, используемых в установленной системе. Раз в неделю инструмент посылает отчет на наш сервер, где производится подсчет статистики.

Чтобы принять участие в таком исследовании, достаточно просто установить пакет rosa-popularity-contest. Больше никаких действий со стороны пользователя не требуется — инструмент работает в полностью автоматическом режиме.

Анализ использования пакетов производится на основе сведений о времени последнего доступа (atime) к файлам пакета. Детали работы rosa-popularity-contest описаны на нашей вики.

Отчеты по репозиториям публикуются здесь: http://fba.rosalinux.ru/popcon/

Для каждого пакета отчет содержит следующие численные показатели:

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

Установите этот пакет — всего два слова в консоли, и вы сделаете мир лучше!

 urpmi rosa-popularity-contest

Всем доброго дня! Это первый выпуск нашего технологического бюллетеня — краткой сводки новостей о разработке, происходящей внутри компании «РОСА». Выпуск первый, а потому в нем еще имеются некоторые шероховатости и недоработки, которые мы попробуем обязательно исправить в грядущих выпусках. Выпуская такие сводки новостей мы хотели бы ориентироваться на то, что интересно сообществу. Поэтому хотелось бы выслушать ваши отзывы и пожелания по данному документу. Все, что считаете нужным — вопросы, отзывы, пожелания, угрозы :) — отправляйте на адрес rosa-point@rosalab.ru.

При разработке дистрибутива одной из главных задач является выбор пакетов для него. При решении этой задачи полезно провести анализ репозиториев других дистрибутивов и узнать — что они посчитали важным для своих пользователей?

Для сравнения репозиториев urpmi у нас есть замечательный инструмент urpm-repodiff. С его помощью можно, в частности, сравнивать репозитории РОСЫ, Mandriva и Mageia.

Полный отчет о сравнении репозиториев ROSA 2012 Desktop (main+contrib), Mandriva Cooker и Mageia Cauldron можно найти здесь. Отдельно можно посмотреть список пакетов, отсутствующих в РОСЕ, но имеющихся в родственных дистрибутивах.

Отчеты обновляются ежедневно.

Стандарт Linux Standard Base (LSB), разрабатываемый одноименной рабочей группой консорциума The Linux Foundation, — это не только текстовый документ, но и набор различных программных продуктов, призванных упростить создание дистрибутивов и приложений, соответствующих стандарту.

Благодаря совместным усилиям разработчиков РОСЫ и инженеров The Linux Foundation, репозитории с программными продуктами LSB теперь доступны в формате urpmi и могут быть подключены в дистрибутивах РОСЫ.

Для подключения репозиториев с последними выпущенными версиями инструментария LSB в 32-битной системе, необходимо в консоли с правами root выполнить следующую команду:

  urpmi.addmedia lsb http://ftp.linuxfoundation.org/pub/lsb/repositories/rpm/lsb-4.1/repo-ia32/

Также можно подключить репозиторий со «snapshot»-версиями инструментов:

  urpmi.addmedia lsb-snapshot http://ftp.linuxfoundation.org/pub/lsb/repositories/rpm/lsb-snapshot/repo-ia32/

Для 64-битных систем понадобятся следующие команды:

  urpmi.addmedia lsb64 http://ftp.linuxfoundation.org/pub/lsb/repositories/rpm/lsb-4.1/repo-x86_64/
  urpmi.addmedia lsb64-snapshot http://ftp.linuxfoundation.org/pub/lsb/repositories/rpm/lsb-snapshot/repo-x86_64/

После этого в системе будут доступны для установки пакеты LSB. Все эти пакеты можно разделить на три группы:

• инструменты для оценки переносимости приложений и их проверки на соответствие стандарту LSB; основным инструментом является Linux Application Checker (пакет lsb-task-app-testkit, запуск — командой /opt/lsb/app-checker/bin/app-checker-start.pl);
• тесты для проверки соответствия дистрибутивов стандарту LSB и фреймворк для их запуска и анализа результатов — Linux Distribution Checker; чтобы получить все тесты и фреймворк, необходимо установить пакет lsb-task-dist-testkit;
• инструментарий LSB SDK для разработки переносимых приложений (пакет lsb-task-sdk).

Инструменты LSB рассчитаны прежде всего на разработчиков приложений и дистрибутивов, однако могут быть интересны и обычным пользователям. Например, Linux Application Checker позволяет проверить возможность запуска того или иного приложения в основных дистрибутивах Linux.

Более детальную информацию по работе с репозиториями LSB можно найти на сайте The Linux Foundation.

Отчет Linux Application Checker для пакета vim-minimal из ROSA 2012 Marathon

vim-minimal из Росы может быть без перекомпиляции запущен в Mandriva 2010.1, Oracle 6, RHEL 6 и SLES 11 SP1, но не в Asianux 3.0, CentOS 5.2 или Fedora 7.

Одним из инструментов, используемых для контроля состояния репозиториев РОСЫ, является urpm-repoclosure, проверяющий замкнутость репозиториев по зависимостям.

Изначально urpm-repoclosure умел проверять замкнутость одного конкретного репозитория или заданного набора пакетов. Однако структура репозиториев РОСЫ таковы, что «самодостаточным» репозиторием является только main; при анализе замкнутости contrib и non-free следует учитывать, что пакеты из этих репозиториев могут использовать и пакеты из main. Кроме того, необходимо учитывать наличие обновлений в ветках updates, которые могут замещать пакеты из веток release.

До сих пор для анализ чего-то кроме main/release, мы, чтобы оставить только самые свежие версии пакетов, копировали все нужные пакеты в одно место с их последующей обработкой urpm-repomanage. Но такой подход подразумевает работой непосредственно с пакетами, что является ресурсоемким занятием. В то же время urpm-repoclosure поддерживает существенно более быстрый способ работы — на основе файлов synthesis.hdlist (опция -hdlist).

Недавно мы добавили в urpm-repoclosure поддержку работы с несколькими файлами synthesis.hdlist — теперь он может самостоятельно их «объединять», убирая устаревшие версии пакетов. Более того — можно указать, какие из дополнительных репозиториев содержат обновления анализируемых пакетов (файл со списком соответствующих synthesis.hdlist передается опции -update-hdlists), а какие служат лишь для удовлетворения их зависимостей -dep-hdlists). Теперь анализ репозитория contrib можно провести, используя всего четыре файла synthesis.hdlist (из main/release, main/updates, contrib/release и contrib/updates):

 echo "synthesis.hdlist-contrib.updates" > updates.list
 echo "synthesis.hdlist-main.release" > dep.list
 echo "synthesis.hdlist-main.updates" >> dep.list

 urpm-repoclosure -hdlist synthesis.hdlist-contrib.updates -update-hdlists updates.list -dep-hdlists dep.list

Схожим образом можно проверять замкнутость персональных репозиториев на ABF.

Наконец, для удобства отображения urpm-repoclosure теперь умеет генерировать отчеты в формате HTML. Никаких дополнительных опций для этого указывать не надо — HTML-отчет создается автоматически вместе с текстовым. Пример HTML-отчетов можно посмотреть на ежедневно обновляемой страничке с отчетами по состоянию репозиториев ROSA 2012 Marathon и ROSA 2012 Desktop: http://upstream-tracker.org/repoclosure_logs/

Во время недавнего анализа совместимости ROSA 2012 Marathon с обновлениями из RP1, встретили неожиданную проблему — входящая в binutils утилитаc++filt^[1] падала с ошибкой сегментации на достаточно больших объемах данных.

Видимо, за долгие годы существования утилиты никто еще не заставлял ее переваривать десятки тысяч имен за один раз:)

Впрочем, проблема была тривиальная (хотя это можно сказать о многих ошибках, приводящих к проблемам в работе с памятью в программах на C) и разработчики binutils выдали исправление уже через несколько часов после заведения бага.

1. ↑ Преобразующая mangled-имена бинарных символов C++ в человеко-читаемый текст — чтобы вместо _ZNSt14numeric_limitsIfE9is_moduloE увидеть std::numeric_limits<float>::is_modulo

Одним из ключевых нововведений в ROSA 2012 Desktop на системном уровне стал переход от RPM 5.3 к RPM 5.4, а также связанного с ним вспомогательного инструментария (в частности, spec-helper). Ветка RPM 5.4 находится в разработке более полутора лет. В течение первого года разработки она рассматривалась как экспериментальная, однако к настоящему времени код стабилизирован и тщательно протестирован, и RPM 5.4 готов к использованию в реальных системах.

При разработке ветки 5.4 большое внимание уделялось стабильности работы; сейчас можно утверждать, что вероятность возникновения нарушений в базе данных RPM 5.4 существенно меньше, чем в случае RPM 5.3 (во всяком случае, пока не было выявлено случаев поломок базы RPM, что иногда происходило с RPM 5.3). При этом стабильность не пошла в ущерб скорости работы, которая в среднем повысилась. В частности, был проведен рефакторинг макроопределений в RPM с целью избавления от загрузки неиспользуемых макросов при каждом запуске rpm.

Помимо рефакторинга, повышения стабильности работы и исправления небольших ошибок, RPM 5.4 содержит и ряд нововведений:

• реализована поддержка зависимостей typelib(…) и 'set: version'
• реализована поддержка «тильды» в версиях пакетов (для совместимости с RPMv4)
• добавлена базовая поддержка ODBC и возможность работы с SQL-запросами
• …

Впрочем, такие нововведения мантейнерам еще только предстоит оценить по достоинству. А вот c некоторыми особенностями нового RPM и сопряженного с ним инструментария многие уже столкнулись при подготовке ROSA Desktop 2012:

• С переходом на RPM 5.4 мы стали использовать встроенный генератор зависимостей RPM (вместо применявшихся ранее генераторов, разработанных в Mandriva). Такой подход позволяет работать над генераторами зависимостей консолидированно с апстримом. Естественно, при переходе на новый инструментарий были и сложности — именование зависимостей в генераторе RPM5 несколько отличается от применявшегося в Mandriva, и некоторые избыточные названия зависимостей были удалены. Поэтому потребовалась адаптация spec-файлов и их чистка от зависимостей, который больше не предоставляются другими пакетами в результате сборки с новым RPM.

• rpmbuild теперь проявляет больше интеллекта при перечислении файлов, принадлежащих пакету — например, если в секции %files вы перечислили файлы, находящиеся в некоторой директории, то нет необходимости упоминать саму директорию. В то же время rpmbuild строго относится к дублирующимся файлам; если вы сначала указали в секции %files директорию, а потом — какую-то из ее поддиректорий или файл внутри нее, то это будет воспринято как излишнее дублирование информации и сборка такого пакета будет завершена с ошибкой.

• Изменилось поведение макроса find_lang, занимающегося поиском файлов локализации в пакете. Предыдущая реализация в случае отсутствия таких файлов завершалась успешно и возвращала пустой список; новый же find_lang в таких ситуациях выдает ошибку. Такое изменение призвано форсировать удаление вызова find_lang из процесса сборки тех пакетов, где вызов find_lang не имеет смысла, а только отнимает время.

• spec-helper теперь автоматически удаляет *la-файлы. Необходимость в таких файлах отпала давно, однако до сих пор они входили во многие пакеты. В процессе подготовки нового релиза мы произвели чистку spec-файлов в репозитории Main, и теперь в пакетах из этого репозитория *la файлов нет. На очереди Contrib :)

Казалось бы, относительно небольшие изменения. Тем не менее, они оказывают влияние на всю пакетную базу, и именно на адаптацию пакетов к новому RPM5 ушла существенная доля усилий при подготовке Alpha-релиза ROSA Desktop 2012.

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

С момента выхода ROSA 2012 Marathon прошло немногим более трех месяцев, и за это время были обновлены несколько сотен пакетов — в том числе и библиотек. Безусловно, каждое обновление проходит проверку нашим отделом QA, но вероятность пропустить «нехорошее» изменение всегда присутствует. Поэтому мы решили провести исследование — насколько сильно отличается API библиотек в «оригинальной» ROSA 2012 Marathon и недавно выпущенном обновленном образе RP1.

Для исследования мы использовали инструментарий ABI compliance Checker, доступный на сайте http://upstream-tracker.org. Результаты анализа можно наблюдать здесь:

http://upstream-tracker.org/compatibility/ROSA_2012_LTS_to_ROSA_2012_LTS_RP1/x86/abi_compat_report.html

Как видим, обновления библиотек практически не привели к изменению из API/ABI. В некоторых библиотеках появились новые функции, но это не влияет на обратную совместимость. Из серьезных модификаций можно выделить добавление модификатора 'const' к возвращаемым значениям ряда функций в libbabl (согласно документации, наличие 'const' там неявно подразумевалось и ранее, а теперь «закреплено» формально), а также удаление нескольких функций из libdc1394 (для устранения конфликта с libusb). Так что если вы установили в систему какие-то сторонние приложения — можно не беспокоится, после обновлений их работоспособность не нарушится.

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

Многие знают, что Bugzilla — популярная система багтрекинга, которая также используется и у нас для отслеживания багов в ROSA Desktop, — содержит такую интересную вкусность, как добавление «настраиваемых полей» или «кастомных полей» в тикеты. То есть можно, не исправляя код, через «админку» создать новое поле, которое можно будет заполнять по определённым правилам и — что ещё важнее — использовать при фильтрации и поиске багов.

При этом такая функциональность не повсеместна. Например, авторы некоторых систем отслеживания багов активно ей противодействуют. Но в багзилле она есть, и мы ей активно пользуемся, например, чтобы давать пользователю поле для ввода имени RPM пакета (в недалёком будущем это свяжет багзиллу с базой данных мэйнтэйнеров на ABF). А чуть позднее, понадобилось добавить поле для того, чтобы помечать баги, для решения которых нужно исправить скрипты сборки дистрибутива. Казалось бы, чего может быть проще: добавил кастомное поле типа «галочка» («checkbox») — и вперёд. Но тут мы столкнулись с проблемой.

Оказалось, кастомного поля типа «checkbox» в Bugzilla просто нет.

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

При этом, разумеется, надо нами нависала бритва Оккама, призывающая не плодить сущности без необходимости, — особенно если тебе напложенное и поддерживать. Следовало подумать — каким из вышеприведённых полей соответствует чекбокс? Вдруг такая логика уже есть, но просто неочевидна? Поле такое действительно имеется — «выбор нескольких вариантов» с всего одной альтернативой. То есть или ты её выбираешь, или нет, что соответствует логике чекбокса. Как это выглядит на практике:

По сути, это готовый чекбокс. Отмечено «yes» — значит «checked». Не отмечено — не «checked». Но этот интерфейс, который был бы понятен, если бы альтернатив было несколько, похож не то на поле ввода, не то на баг, и пользователям пришлось бы дольше объяснять, что к чему. Решением было автоматически, никого не спрашивая, превращать такие «выборы», где есть только одна альтернатива, в протестные митинги и демонстрации на Болотной в «checkbox». И тогда вместо той некрасивой картинки у пользователей был бы интуитивно понятный чекбокс:

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

Это решение развёрнуто на багзилле РОСЫ , а если хотите поставить у себя, то вот вам патч к багзилле версии 4.2: Файл:Bugzilla 4.2 checkbox.patch, лицензия BSD.

Традиционным способом установки «РОСы» на физическую машину является запись установочного образа системы (iso-файла) на Flash или DVD-диск и последующая загрузка с него. Однако записывать образ на съемный носитель не обязательно — загрузка возможна непосредственно с iso-файла, расположенного на жестком диске. Если на вашей машине уже установлен какой-либо Linux-дистрибутив, то вы можете скачать в нем образ ОС ROSA и загрузиться с него, используя загрузчик вашего дистрибутива, как это описано здесь.

Энтузиасты, работающие в ОС Windows, могут установить загрузчик Grub4dos и сконфигурировать его так же, как описано в инструкции для Grub.

Также мы понимаем, что многие пользователи для знакомства с системой используют виртуальные машины. Наиболее популярным средством виртуализации в мире открытого ПО является программа VirtualBox. Для тех, кто хочет использовать VirtualBox для знакомства с нашей системой, на нашей вики имеются детальные инструкции.

Использование других средств виртуализации также не должно вызвать затруднений, однако в некоторых случаях могут понадобится дополнительные настройки. Например, если вы работаете в операционной системе MacOS X и хотите использовать программу Parallels Desktop для запуска Росы, вам могут пригодиться советы от Максима Куприянова.

Загрузчик ROSA Marathon с добавленными пунктами для загрузки с iso-образа («ROSA Live» и «ROSA Install»)

В инструментарий ROSA Updates Tracker, предназначенный для сравнения версий пакетов РОСЫ и родственных систем с апстримом, добавлена поддержка разрабатываемого релиза ROSA 2012 Desktop: http://upstream-tracker.org/updates/rosa/2012.1/

В настоящее время производится сравнение версий пакетов с ROSA 2012 Marathon, Mandriva Cooker и Mageia Cauldron.

Данные собираются с помощью автоматизированных инструментов и в некоторых случаях возможно появление «странных» результатов, но для подавляющего большинства пакетов все должно работать корректно. Также в настоящее время для ряда пакетов инструментарий не может самостоятельно определить ссылку, по которой необходимо скачивать свежие пакеты апстрима. Однако инструментарий постоянно совершенствуется и со временем «белых пятен» будет становиться все меньше и меньше.

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

Для пакетов библиотек, изменения в которых отслеживаются сайтом http://upstream-tracker.org, доступен анализ совместимости различных версий. Такой анализ призван помочь мантейнерам оценить — насколько болезненным будет переход на новую версию. Вот так, например, выглядит отчет о совместимости различных версий lame: http://upstream-tracker.org/versions/lame.html

Статистика ROSA Updates Tracker обновляется ежедневно.

На сайте http://upstream-tracker.org, поддерживаемом сотрудниками РОСЫ, добавлены две секции со статистическими отчетами о состоянии наших репозиториев.

Первая секция предосталяет отчеты о пакетах с недостающими зависимостями (генерируемый утилитой urpm-repoclosure):

http://upstream-tracker.org/repoclosure_logs/

Вторая секция содержит информацию об устаревших пакетах (для которых есть более новые версии в тех же репозиториях), которые могут быть удалены с серверов (отчет строится с помощью urpm-repomanage):

http://upstream-tracker.org/repomanage_logs/

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

Статистика на upstream-tracker.org обновляется ежедневно.