Викилоги

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

Мы считаем, что как и все в РОСЕ, консоль должна быть удобна для использования. И одним из главных критериев удобства является используемый шрифт. Выбор шрифта — во многом дело вкуса, и как выяснилось, «родные» шрифты из KDE устраивают далеко не всех.

Так, некоторые пользователи считают наиболее удобным шрифт, использовавшийся в ряде дистрибутивов (например, в openSUSE 10.x) для консоли KDE3. После перехода на KDE4 шрифты сменились, но до сих пор есть приверженцы старого шрифта. Если вы входите в число этих людей, то у нас для вас радостная новость — этот шрифт теперь доступен и в наших дистрибутивах. Достаточно установить пакет fonts-bitmap-misc-console, после чего в настройках Konsole будет доступен новый шрифт с названием Console (только фиксированный размер, 12).

Еще одним популярным шрифтом является Source Code Pro от разработчиков Adobe (http://blogs.adobe.com/typblography/2012/09/source-code-pro.html). Этот шрифт также доступен в репозиториях наших систем (пакет SourceCodePro). Хотя этот шрифт не поддерживает кириллицу и многие другие национальные наборы символов, он может прийтись по вкусу программистам, много работающим с исходным кодом различных приложений.

В декабре мы представили альфа-версию новой утилиты — updates_builder, которая, как мы надеемся, будет полезна многим нашим разработчикам и мантейнерам.

Вкратце, инструмент делает следующее:

• проверяет доступность обновлений в апстриме
• если обновление имеется, то утилита скачивает соответствующий тарболл с исходным кодом, загружает его в файловое хранилище ABF, обновляет spec-файл и файл .abf.yml в соответствующем проекте группы import и запускает сборку.

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

Не беспокойтесь за сохранность текущих проектов — все изменения производятся в отдельной ветке Git-репозитория — 'auto_update' — а сборка осуществляется в репозиторий import_personal).

Более детальную информацию можно найти здесь:

• http://wiki.rosalab.ru/ru/index.php/Updates_builder

В настоящее время инструмент доступен в репозитории

• http://abf.rosalinux.ru/downloads/akirilenko_personal/repository/

Информацию об обновлениях инструмент берет с upstream-tracker.org (http://upstream-tracker.org/updates/rosa/2012/):

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

Конечно, это всего лишь тестовая версия, и еще предстоит доработать многие технические детали. Однако после серии экспериментов уэе можно сказать, что updates_builder вполне успешно справляется со своими задачами. С помощью него мы уже обновили ряд пакетов в ROSA 2012 Desktop.

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

Медленно но верно, мы добрались до третьего выпуска нашего бюллетеня. За время, прошедшее с момента предыдущего номера, мы представили релиз операционной системы ROSA Enterprise Linux Server, а в декабре планируем выпустить новый дистрибутив ROSA Desktop 2012.

Очень надеемся, что это не помешает нам подготовить новогодний выпуск «Точки РОСЫ» и призываем вас принять в нем активное участие (читайте об этом первый материал текущего выпуска). Надеемся на вашу помощь и поддержку.

Не скроем, приятно получать от вас положительные отзывы и слова поддержки. Еще более полезно изучать критические замечания. Но что заставляет по-настоящему гордиться, так это волна аналогичных проектов в русскоязычном Linux-сообществе, которую мы вызвали своим примером. Если это еще не эпидемия, то вирус точно :-).

ABF API продолжает развиваться; рассмотрим изменения, реализованные в последнее время.

Во-первых, мы добавили новое поле со ссылкой на Git-репозиторий проекта в блок project во всех вызовах API, где такой блок присутствует:

 "git_url": "path to project git"

Используйте это поле при необходимости. Это изменение не должно сказаться на уже существующих инструментах, используюзих ABF API.

Также мы добавили несколько новых вызовов API:

• Search API — http://abf-doc.rosalinux.ru/v1/search/
• Получение списков сборок для проекта — http://abf-doc.rosalinux.ru/v1/buildlists/#list-build-lists-for-a-project

… и сейчас мы работаем над вызовами Maintainers API (API для работы с базой данных мантейнеров), которые будут доступны в ближайшем будущем — http://abf-doc.rosalinux.ru/v1/maintainers/

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

• отмена сборочного задания (http://abf-doc.rosalinux.ru/v1/buildlists/#cancel-build-list)
• публикация сбороки (http://abf-doc.rosalinux.ru/v1/buildlists/#publish-build-list)
• отмена публикации (http://abf-doc.rosalinux.ru/v1/buildlists/#reject-publish-build-list)

Пожалуйста, обратите внимания на эти изменения и при необходимости скорректируйте ваши приложения.

Оставайтесь с нами!

Как многие наверняка знают, в 2010 году закончился срок действия соответствующего патента и библиотека freetype, начиная с версии 2.4.0, стала собираться с включенным по умолчанию интерпретатором байт-кода. Это позволило значительно улучшить внешний вид шрифтов при использовании межточечного сглаживания. Однако если межточечное сглаживание не используется (некоторые пользователи его отключают, так как не всем нравятся, когда буквы переливаются всеми цветами радуги), то интерпретатор байт-кода скорее ухудшает вид шрифтов, чем улучшает. Хотя это зависит от конкретного шрифта, конечно. И дело вкуса.

На следующей картинке — пример шрифта Liberation Sans c отключенным BCI (слева) и включенным (справа). Межточечное сглаживание отключено, стиль хинтинга «полный». Как видно, при использовании BCI буква «Р» слилась с буквой «у», буква «t» выглядит слишком тонкой и т. п.

Чтобы позволить пользователю легко включать и отключать BCI, была добавлена галочка в настройках сглаживания шрифтов в KDE4:

Благодаря иностранным коллегам, строка настройки уже переведена на следующие языки:

• de
• en
• es
• fr
• it
• nl
• pt_br
• ro
• ru

P.S. В Магее полтора года назад был такой фича-реквест, но там фичу до сих пор не добавили.

Не секрет, что за основу нашей операционной системы «РОСА Сервер» был взят самый известный и стабильный дистрибутив RehHat Enterprise Linux (RHEL). В этот дистрибутив были добавлены фирменные приложения от компании РОСА, чтобы улучшить функциональность дистрибутива для наших заказчиков. При этом для обеспечения работы данных приложений в дистрибутив были внесены изменения и в системную часть. Как всем известно, такие изменения могут нарушать бинарную совместимость между дистрибутивами и затруднить^[1] перенос приложений между дистрибутивами.

При внесении изменений в пакетную базу, взятую от RHEL, мы ставили задачу сохранить полную бинарную совместимость с родительским дистрибутивом — это должно гарантировать, что все приложения, работающие в RHEL, будут успешно запускаться и работать в ROSA Server. Для контроля бинарной совместимости в процессе разработки мы применяли специальные инструменты — в частности, ABI Compliance Checker, разрабатываемый на данный момент в компании РОСА. Инструмент предназначен для поиска изменений в библиотеках, которые могут приводить к нарушению совместимости.

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

1. ↑ При нарушении бинарной совместимости, может потребоваться перекомпиляция, а возможно и модификация программ

Одним из направлений развития РОСЫ является избавление от устаревшего инструментария 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