Блог:Точка Росы

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

Если вы умеете пользоваться агрегаторами RSS/Atom, подписывайтесь!. По любым вопросам можно писать сюда.

Весь контент данного блога распространяется на условиях Creative Commons Attribution-ShareAlike 3.0 License (CC-BY-SA)

ABF API: изменения, новые вызовы и планы

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)

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

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

Разместил Denis.silakov 30 ноября 2012 09:30 (GMT), нет комментариев.

Включение интерпретатора байт-кода в настройках сглаживания шрифтов KDE4

Как многие наверняка знают, в 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. В Магее полтора года назад был такой фича-реквест, но там фичу до сих пор не добавили.

Разместил Denis.silakov 30 ноября 2012 08:47 (GMT), нет комментариев.

Результаты тестирования бинарной совместимости ROSA Server и RHEL

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

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

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

Для визуализации изменений во всех пакетах дистрибутива мы сделали специальный инструмент DistDiff, который запускает PkgDiff на изменившихся пакетах, содержащих интерфейсные файлы, и выводит статистическую информацию об изменениях в специальный отчет. Отчет об изменениях был проанализирован экспертами по бинарной совместимости из компании РОСА, в результате чего большинство изменений были признаны совместимыми, а несовместимые изменения были исправлены до релиза — изменения в пакетах, указанные в финальной версии отчета по указанной ссылке, к нарушениям совместимости не ведут. Таким образом, ROSA Server является на 100 % совместимой с RHEL на бинарном уровне.

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

Разместил Denis.silakov 20 ноября 2012 14:21 (GMT), нет комментариев.

Интеграция DrakConf и KDE Control Center

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

Разместил Denis.silakov 19 ноября 2012 14:26 (GMT), нет комментариев.

ABF console client

Как уже было написано в предыдущем выпуске, недавно появился дополнительный к 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 в час).

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

Разместил Akirilenko 19 ноября 2012 11:46 (GMT), нет комментариев.

LinuxCon Europe 2012

В блоге РОСЫ на 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 получился очень познавательным и насыщенным - даже рассказ о наиболее запомнившихся аспектах растянулся на пару страниц:).

Разместил Denis.silakov 19 ноября 2012 11:38 (GMT), нет комментариев.

ABF: базовый API, встроенные комментарии

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

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

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

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

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

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

Разместил Denis.silakov 29 октября 2012 17:23 (GMT), нет комментариев.

FBA: отчеты о замкнутости репозиториев по бинарным символам и "Obsolete" пакетах

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

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

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

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

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

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

Разместил Denis.silakov 17 октября 2012 10:03 (GMT), нет комментариев.

Точка Росы №2

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

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

Разместил Stanislav.fomin 12 октября 2012 16:11 (GMT), нет комментариев.

FBA - Frontend Brother of ABF

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

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

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

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

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

Разместил Denis.silakov 5 октября 2012 15:14 (GMT), нет комментариев.

Простой клиент 2Safe.com. Обзор API.

Вот уже почти полтора года, как сервис облачного хранения 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, перечислю лишь разделы:

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

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

Да простят меня перлокодеры 80+лвл за мой французский.

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

Разместил Sergey.sokolov 5 октября 2012 13:54 (GMT), нет комментариев.

ROSA Popularity Contest - исследование популярности пакетов

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

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

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

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

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

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

Installed	процент респондентов, у которых пакет установлен
Vote	процент респондентов, использовавших пакет в течение последнего месяца
Old	процент респондентов, не использовавших пакет
Recent	процент респондентов, недавно обновивших пакет; нельзя достоверно сказать, используют ли они его или нет
No-files	процент респондентов, для которых информация об использовании пакета недоступна (например, пакет установлен на ФС, примонтированную с опцией 'noatime')

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

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

 urpmi rosa-popularity-contest

Разместил Denis.silakov 2 октября 2012 09:56 (GMT), нет комментариев.

Точка Росы №1

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

Разместил Stanislav.fomin 28 сентября 2012 17:21 (GMT), нет комментариев.

Сравнение репозиториев ROSA 2012 Desktop, Mandriva Cooker и Mageia Cauldron

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

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

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

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

Разместил Denis.silakov 22 сентября 2012 19:09 (GMT), нет комментариев.

Репозитории LSB доступны в формате urpmi

Стандарт 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.

Разместил Denis.silakov 18 сентября 2012 15:49 (GMT), нет комментариев.

Urpm-repoclosure - анализ нескольких репозиториев и HTML-отчеты

Одним из инструментов, используемых для контроля состояния репозиториев РОСЫ, является 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/

Разместил Denis.silakov 17 сентября 2012 11:06 (GMT), нет комментариев.

Segmentation fault в c++filt

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

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

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

Теперь c++filt вполне успешно справляется и с гигабайтами данных:)

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

Разместил Denis.silakov 7 сентября 2012 12:36 (GMT), нет комментариев.

ROSA Desktop 2012: от RPM 5.3 к RPM 5.4

Одним из ключевых нововведений в 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.

Разместил Denis.silakov 31 августа 2012 15:31 (GMT), нет комментариев.

Обновления дистрибутива и обратная совместимость

С точки зрения разработчиков, поддержка выпущенного дистрибутива заключается преимущественно в исправлении ошибок и устранении проблем с безопасностью в его компонентах. Для решения этих задач создаются патчи, либо производится обновление ПО до более новых версий, где проблема уже решена. Большинство подобных обновлений затрагивает только саму программу, однако в ряде случаев изменения могут сказаться и на других компонентах системы. Особенно остро этот вопрос стоит в случае обновления библиотек, используемых многими приложениями. Ведь обновление до новой версии или даже наложение патча может привести к изменению внешнего интерфейса (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, но мы постараемся и дальше следить за обратной совместимостью и гарантировать работу установленных приложений (пусть даже и не имеющих отношения к РОСе) после установки всех обновлений.

Разместил Denis.silakov 29 августа 2012 12:17 (GMT), нет комментариев.

Кастомные чекбоксы в багзилле

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

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

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

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

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

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

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

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

Разместил Павел 24 августа 2012 11:59 (GMT), нет комментариев.

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

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

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

[1]