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

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

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

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

Вклад в апстрим настройщика GRUB2 — выбор языка загрузчика

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

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

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

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

Разместил Vladimir Testov 8 февраля 2013 17:37 (GMT), нет комментариев.

Command-not-found

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

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

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

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

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

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

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

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

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

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

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

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

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

Разместил Akirilenko 31 января 2013 12:47 (GMT), нет комментариев.

Система автоматизированного тестирования

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

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

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

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

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

Разместил Eugene.shatokhin 28 января 2013 12:16 (GMT), нет комментариев.

ABF 2.0 — новая система сборки

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

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

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

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

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

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

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

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

Разместил Denis.silakov 15 января 2013 17:05 (GMT), нет комментариев.

Инструменты РОСЫ в upstream-разработках

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

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

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

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

Разместил Denis.silakov 14 января 2013 11:29 (GMT), нет комментариев.

Точка Росы №4

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

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

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

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

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

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

Разместил Stanislav.fomin 26 декабря 2012 13:10 (GMT), нет комментариев.

FBA: обновленный внешний вид, новые разделы и улучшения в отчетах

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

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

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

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

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

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

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

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

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

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

Вклад в апстрим Grub2

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

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

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

Разместил Vladimir Testov 12 декабря 2012 10:46 (GMT), нет комментариев.

Шрифты для консоли в РОСЕ

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

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

Updates builder - автоматическое отслеживание и сборка обновлений пакетов в ABF

В декабре мы представили альфа-версию новой утилиты — 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.

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

Точка Росы №3

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

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

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

Разместил Stanislav.fomin 1 декабря 2012 13:10 (GMT), нет комментариев.

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), нет комментариев.

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

[1]