Блог:Точка Росы
Блог с постами технической направленности, чтобы погордиться сделанной работой, и поделиться результатами исследований, сделанными в текущей рутине.
Если вы умеете пользоваться RSS/Atom агрегаторами — подписывайтесь!. По любым возникающим вопросам можно писать сюда.
Весь контент данного блога распространяется на условиях Creative Commons Attribution-ShareAlike 3.0 License (CC-BY-SA)
Репозитории 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.
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/
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
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.
Обновления дистрибутива и обратная совместимость
С точки зрения разработчиков, поддержка выпущенного дистрибутива заключается преимущественно в исправлении ошибок и устранении проблем с безопасностью в его компонентах. Для решения этих задач создаются патчи, либо производится обновление ПО до более новых версий, где проблема уже решена. Большинство подобных обновлений затрагивает только саму программу, однако в ряде случаев изменения могут сказаться и на других компонентах системы. Особенно остро этот вопрос стоит в случае обновления библиотек, используемых многими приложениями. Ведь обновление до новой версии или даже наложение патча может привести к изменению внешнего интерфейса (API/ABI) библиотеки и, как следствие, — к неработоспособности использующих ее программ. Полбеды, если это программа из репозитория дистрибутива — такую ситуацию мы можем отследить и обновить саму программу. Но если пользователи установили стороннее ПО, то потеря работоспособности этого ПО после обновления явно не вызовет восторга.
С момента выхода ROSA 2012 Marathon прошло немногим более трех месяцев, и за это время были обновлены несколько сотен пакетов — в том числе и библиотек. Безусловно, каждое обновление проходит проверку нашим отделом QA, но вероятность пропустить «нехорошее» изменение всегда присутствует. Поэтому мы решили провести исследование — насколько сильно отличается API библиотек в «оригинальной» ROSA 2012 Marathon и недавно выпущенном обновленном образе RP1.
Для исследования мы использовали инструментарий ABI compliance Checker, доступный на сайте http://upstream-tracker.org. Результаты анализа можно наблюдать здесь:
Как видим, обновления библиотек практически не привели к изменению из API/ABI. В некоторых библиотеках появились новые функции, но это не влияет на обратную совместимость. Из серьезных модификаций можно выделить добавление модификатора 'const' к возвращаемым значениям ряда функций в libbabl (согласно документации, наличие 'const' там неявно подразумевалось и ранее, а теперь «закреплено» формально), а также удаление нескольких функций из libdc1394 (для устранения конфликта с libusb). Так что если вы установили в систему какие-то сторонние приложения — можно не беспокоится, после обновлений их работоспособность не нарушится.
Конечно, три месяца — небольшой срок, особенно по сравнению со пятилетним сроком поддержки Marathon, но мы постараемся и дальше следить за обратной совместимостью и гарантировать работу установленных приложений (пусть даже и не имеющих отношения к РОСе) после установки всех обновлений.
Кастомные чекбоксы в багзилле
Многие знают, что Bugzilla — популярная система багтрекинга, которая также используется и у нас для отслеживания багов в ROSA Desktop, — содержит такую интересную вкусность, как добавление «настраиваемых полей» или «кастомных полей» в тикеты. То есть можно, не исправляя код, через «админку» создать новое поле, которое можно будет заполнять по определённым правилам и — что ещё важнее — использовать при фильтрации и поиске багов.
При этом такая функциональность не повсеместна. Например, авторы некоторых систем отслеживания багов активно ей противодействуют. Но в багзилле она есть, и мы ей активно пользуемся, например, чтобы давать пользователю поле для ввода имени RPM пакета (в недалёком будущем это свяжет багзиллу с базой данных мэйнтэйнеров на ABF). А чуть позднее, понадобилось добавить поле для того, чтобы помечать баги, для решения которых нужно исправить скрипты сборки дистрибутива. Казалось бы, чего может быть проще: добавил кастомное поле типа «галочка» («checkbox») — и вперёд. Но тут мы столкнулись с проблемой.
Оказалось, кастомного поля типа «checkbox» в Bugzilla просто нет.
Настраиваемые поля могли иметь тип «строка», «число», «баг», «выпадающий список» и даже «выбор нескольких вариантов из предложенных», но просто чекбокса — не было. Значит, нужно добавить.
При этом, разумеется, надо нами нависала бритва Оккама, призывающая не плодить сущности без необходимости, — особенно если тебе напложенное и поддерживать. Следовало подумать — каким из вышеприведённых полей соответствует чекбокс? Вдруг такая логика уже есть, но просто неочевидна? Поле такое действительно имеется — «выбор нескольких вариантов» с всего одной альтернативой. То есть или ты её выбираешь, или нет, что соответствует логике чекбокса. Как это выглядит на практике:
По сути, это готовый чекбокс. Отмечено «yes» — значит «checked». Не отмечено — не «checked». Но этот интерфейс, который был бы понятен, если бы альтернатив было несколько, похож не то на поле ввода, не то на баг, и пользователям пришлось бы дольше объяснять, что к чему. Решением было автоматически, никого не спрашивая, превращать такие «выборы», где есть только одна альтернатива, в протестные митинги и демонстрации на Болотной в «checkbox». И тогда вместо той некрасивой картинки у пользователей был бы интуитивно понятный чекбокс:
Конечно, можно было бы сделать это кейвордом, но кейворды менее удобны: их надо запоминать, вводить клавиатурой, а чекбокс — всегда на виду, и надо только кликнуть мышкой.
Это решение развёрнуто на багзилле РОСЫ , а если хотите поставить у себя, то вот вам патч к багзилле версии 4.2: Файл:Bugzilla 4.2 checkbox.patch, лицензия BSD.
Альтернативные способы установки РОСЫ
Традиционным способом установки «РОСы» на физическую машину является запись установочного образа системы (iso-файла) на Flash или DVD-диск и последующая загрузка с него. Однако записывать образ на съемный носитель не обязательно — загрузка возможна непосредственно с iso-файла, расположенного на жестком диске. Если на вашей машине уже установлен какой-либо Linux-дистрибутив, то вы можете скачать в нем образ ОС ROSA и загрузиться с него, используя загрузчик вашего дистрибутива, как это описано здесь.
Энтузиасты, работающие в ОС Windows, могут установить загрузчик Grub4dos и сконфигурировать его так же, как описано в инструкции для Grub.
Также мы понимаем, что многие пользователи для знакомства с системой используют виртуальные машины. Наиболее популярным средством виртуализации в мире открытого ПО является программа VirtualBox. Для тех, кто хочет использовать VirtualBox для знакомства с нашей системой, на нашей вики имеются детальные инструкции.
Использование других средств виртуализации также не должно вызвать затруднений, однако в некоторых случаях могут понадобится дополнительные настройки. Например, если вы работаете в операционной системе MacOS X и хотите использовать программу Parallels Desktop для запуска Росы, вам могут пригодиться советы от Максима Куприянова.
Загрузчик ROSA Marathon с добавленными пунктами для загрузки с iso-образа («ROSA Live» и «ROSA Install»)
Отслеживание статусов пакетов в ROSA 2012 Desktop
В инструментарий ROSA Updates Tracker, предназначенный для сравнения версий пакетов РОСЫ и родственных систем с апстримом, добавлена поддержка разрабатываемого релиза ROSA 2012 Desktop: http://upstream-tracker.org/updates/rosa/2012.1/
В настоящее время производится сравнение версий пакетов с ROSA 2012 Marathon, Mandriva Cooker и Mageia Cauldron.
Данные собираются с помощью автоматизированных инструментов и в некоторых случаях возможно появление «странных» результатов, но для подавляющего большинства пакетов все должно работать корректно. Также в настоящее время для ряда пакетов инструментарий не может самостоятельно определить ссылку, по которой необходимо скачивать свежие пакеты апстрима. Однако инструментарий постоянно совершенствуется и со временем «белых пятен» будет становиться все меньше и меньше.
Обратите внимание, что на момент написания этой заметки часть пакетов еще не была пересобрана для новой системы. Для таких пакетов статистика отсутствует.
Для пакетов библиотек, изменения в которых отслеживаются сайтом http://upstream-tracker.org, доступен анализ совместимости различных версий. Такой анализ призван помочь мантейнерам оценить — насколько болезненным будет переход на новую версию. Вот так, например, выглядит отчет о совместимости различных версий lame: http://upstream-tracker.org/versions/lame.html
Статистика ROSA Updates Tracker обновляется ежедневно.
Мониторинг репозиториев РОСЫ
На сайте http://upstream-tracker.org, поддерживаемом сотрудниками РОСЫ, добавлены две секции со статистическими отчетами о состоянии наших репозиториев.
Первая секция предосталяет отчеты о пакетах с недостающими зависимостями (генерируемый утилитой urpm-repoclosure):
http://upstream-tracker.org/repoclosure_logs/
Вторая секция содержит информацию об устаревших пакетах (для которых есть более новые версии в тех же репозиториях), которые могут быть удалены с серверов (отчет строится с помощью urpm-repomanage):
http://upstream-tracker.org/repomanage_logs/
В настоящее время отчеты отображаются в виде простого текста, в том виде, в котором они генерируются инструментами. В будущем планируется реализовать более функциональное представление и интегрировать отчеты с системой сборки ABF.
Статистика на upstream-tracker.org обновляется ежедневно.
