Викилоги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публикация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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