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

Ссылки сюда (2) →

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

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

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

Mib-report - еще одна утилита в помощь мэйнтейнерам

Вот уже несколько месяцев мы используем Updates Builder для автоматического обновления пакетов в наших репозиториях. Инструмент неплохо справляется со своей задачей и количество обновленных с помощью него пакетов исчисляется сотнями. Однако практика показала, что одно из узких мест автоматического обновления — это не сам инструментарий, а передаваемая ему на вход информация. Дело в том, что Updates Builder собирает новые версии пакетов на основе данных, получаемых от Upstream Tracker'а. Тот, в свою очередь, проводит мониторинг апстрим-проектов на основе ссылок на исходный код, содержащихся в spec-файлах пакетов RPM. Но эти ссылки часто отсутствуют, а если они и есть, то не всегда актуальны — ведь обычным пользователям такая информация не нужна, при сборке пакетов на ABF она тоже не используется, и поэтому мэйнтейнеры не уделяют ей большого внимания. Как следствие, пробелов в колонке «Available in Upstream» на страничке ROSA Updates Tracker хватает.

Но помимо мониторинга апстрима, можно подглядывать и на репозитории других дистрибутивов. И здесь на помощь приходит утилита mib-report, изначально созданная нашими друзьями из группы Mandriva International Backports. Эта утилита сравнивает версии пакетов в разрабатываемых репозиториях 11 дистрибутивов:

• Rosa Desktop Fresh
• OpenMandriva Cooker
• Mageia Cauldron
• Fedora Rawhide (с учетом RpmFusion)
• PCLinuxOS
• Alt Linux Sisyphus
• OpenSUSE Factory
• PLD
• Gentoo
• Debian
• Ubuntu

При этом mib-report не просто сравнивает версии пакетов, но для RPM-based дистрибутивов выдает ссылки на Source RPM пакет:

$ mib-report --search firefox
Searching for package firefox…
Rosa: 25.0
http://abf-downloads.rosalinux.ru/rosa2012.1/repository/SRPMS/main/updates/firefox-25.0-1.src.rpm
Cooker: 25.0.1
http://abf-downloads.rosalinux.ru/cooker/repository/SRPMS/main/release/firefox-25.0.1-1.src.rpm
Mageia: 24.1.0
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/SRPMS/core/release/firefox-24.1.0-1.mga4.src.rpm
Fedora: 25.0
http://mirror.yandex.ru/fedora/linux/development/rawhide/source/SRPMS/f/firefox-25.0-3.fc21.src.rpm
PCLinuxOS: 25.0
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/pclinuxos/pclinuxos/srpms/SRPMS.pclos/firefox-25.0-1pclos2013.src.rpm
Sisyphus: 25.0
http://mirror.yandex.ru/altlinux/Sisyphus/files/SRPMS/firefox-25.0-alt1.src.rpm
Gentoo: 25.0
http://packages.gentoo.org/package/firefox
Ubuntu: 25.0
http://packages.ubuntu.com/firefox
Homepage URL:
http://www.mozilla.com/firefox/

А внутри SRPM-пакетов можно найти и архив с исходным кодом! Так что даже если мы не можем автоматически найти самую свежую версию программы в апстриме, мы можем «подсмотреть», что имеется в других дистрибутивах. И если у них есть версия новее — то можно взять SRPM-пакет и вытащить из него тарболлы с новым исходным кодом. Заодно обновить URL в нашем пакете, чтобы в следующий раз уже не лазить к соседу.

Именно такую возможность мы и внедряем сейчас в наш инструментарий автоматического обновления пакетов — теперь он будет учитывать не только информацию от Upstream Tracker, но и данные от mib-report. Хотелось бы подчеркнуть, что из SRPM-пакетов других дистрибутивов мы извлекаем только архивы с исходным кодом, а ни в коем случае не патчи (поскольку без вмешательства человека сложно понять, актуален ли патч для нас или нет) и не spec-файлы (поскольку у нас есть все основания считать, что наши spec-файлы — одни из самых простых и понятных, и нет нужды загромождать их монструозными конструкциями, используемыми во многих других дистрибутивах).

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

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 10 91% Порадовала :) 1 9% Оставила равнодушным -_- 0 0% Огорчила :( 0 0%

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

Типографская раскладка Бирмана

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

И только «изобретатель Интернета» Винтон Серф верил в силу печатного общения, хотя у него были к этому основания

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

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

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

Сейчас, мы общаемся с огромным количеством людей, большинство из которых мы никогда не встретим лично, и часто оцениваем друг друга именно по качеству текстов — как говорится, «the medium is the message»©. Особенно это важно профессионалам — журналистам, блоггерами, и просто «редакторам контента».

Да, несмотря на то, что мы часто видим безграмотные сообщения («не пускайте школьников в Интернет, он от них глупеет»©), а, может, именно из-за этого, в моде снова грамота, «албанское» поветрие забыто. Но если с орфографией-пунктуацией примерно все понятно — вспоминай правила, следи за своими любимыми ошибками, то следующий уровень текстовой культуры — это типографика.

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

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

Так вышло, что на стандартной клавиатуре поселилось лишь небольшое подмножество печатных символов, и нам приходится в текстах, как Остапу Бендеру с его сломанной машинкой без буквы «e», заменять длинные и короткие тире, дефисы → жалким «минусом», типографские кавычки-лапки — знаком дюйма, многозначительные троеточия «…» — грубой россыпью обычных точек, не говоря уже о более редких, но все же полезных знаках валют градуса, копирайта, и т.п. — они все есть в стандартных шрифтовых наборах, но увы, доступ к ним затруднен.

Эстетам печатного слова игнорирование типографики рвет душу!

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

---

Что же делать? Один из вариантов решения этой проблемы — Compose-режим, когда зажав клавишу-модификатор надо отстучать специальную последовательность клавиш, и если вам повезло и вы правильно ее запомнили и ввели — вам таки выпадет приз — тот самый хитрый типографский символ. Но. Это адски тяжело, почти как набирать текст в TeX-е, причем вслепую. Причем этому трудно научиться — ибо на самой клавиатуре ничто не может напомнить вам об этих символах, да и вообще, использование модальных режимов и многосимвольных последовательностей — дико неудобно, сбивает с ритма и мыслей, ведь для эффективности должна быть так — «один удар — один символ», иначе не выйдет быстрой слепой печати. Не говоря уже о том, что «Compose» и схожие режимы совершенно по-разному реализованы в Linux и Windows мире.

Что же делать, учитывая, что программируемые клавиатуры со сменными символами не факт, что взлетят даже в далеком будущем, а везде стандартом являются классические qwerty-клавиатуры?

Да, есть еще возможность использовать полуавтоматическую типографизацию, используя «автозамены» текстовых процессоров, всякие «онлайн-типографы», но это все не то, жалкие костыли, вместо естественного и правильного решения.

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

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

С ней все становится в порядке не только с тире™ и «кавычками», но появляется куча способов обогатить свой текст, даже если это скучная форма для ввода простого комментария

• Кошерно оформить простые формулы 1¼ $ ≈ € ≈ ⅓£, i²=-1, 20°×Ѵ4≈40°±3°
• Можно упомянуть и ѣ-стыд™, да и вообще, сослаться на любой мем «уже сейчас видно, что все это будет глючить и тормозить»©
• «Я угадала знак ∞»
• ¿ hablan más español

Эх, а какие возможности «пунктуации 2.0» дают стрелки ←↓↑→…

В любом случае, в этой раскладке самые полезные типографские символы, отобранные ведущими собаков дизайнерами, общеизвестный стандарт, прошедший проверку временем.

Теперь о грустном. Автор, реализовал ее поддержку только для Win и Мак (он ведь дизайнер).

Разумеется, в Linux-мире нашлись добрые люди, реализовавшие одну из самых первых версий раскладки, в KDE и GNOME.

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

Да, в GNOME3 это выпилили [1] с таким комментарием "Toggling different arrangements of punctuation characters is crazy and produces lots of bugs. Typographic characters should be available without having to adjust a setting and these characters are available through the Third Level Chooser key. We need to develop a better solution though (see Extra Characters).". Типа мы все сделаем правильно, по науке, продумав дизайн, КОГДА-НИБУДЬ.

А пока → …

---

Good news, everyone!

Мы еще летом, провели нетривиальную работу, и

• реализовали типографскую раскладку Бирмана в GNOME SHELL.
• довели типографскую раскладку в KDE до полного «стандарта Бирмана».

---

Включить типографскую раскладку в нашем GNOME проще простого → не надо ничего ставить, просто в настройках «Параметры → Клавиатура → Комбинации клавиш → Ввод → Клавиша альтернативных символов», надо задать удобную вам клавишу, лично я рекомендую старый добрый «правый ALT». ↓↓↓

Т.е. в наших дистрибутивах все уже есть, просто мы не Typo-Nazi, и не можем насильно заставить вас этим пользоваться, а только просим — зайдите в настройки, включите типографские раскладки правым альтом (ну или другой любимой вами клавишей), ну и начните с «кавычек-лапок» и длинных тире — даже только этим мы вместе сделаем мир, ну или хотя бы Рунет, лучше!

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 44 54% Порадовала :) 22 27% Оставила равнодушным -_- 6 7% Огорчила :( 9 11%

Разместил Stanislav.fomin 23 декабря 2013 20:27 (GMT), 5 комментариев.

Визуализация результатов деятельности Updates Builder

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

Списки отслеживаемых им пакетов можно найти на вики — для РОСЫ и для OpenMandriva. Эти списки достаточно велики, однако в реальности у некоторых пакетов апстрим-версии выходят редко, для других не получается автоматически отследить новые версии… Каков же реальный объем работ, проводимых Updates Builder’ом на ABF?

Конечно, мэйнтейнеры и вообще пользователи ABF могут оценить это по общей статистике сборок, но теперь есть способ проще — скрипты запуска Updates Builder’а сами формируют отчеты о его работе и выкладывают на upstream-tracker.org. Страничка результатов для РОСЫ находится здесь, а тут можно посмотреть отчеты по OpenMandriva.

Названия колонок достаточно говорящие, но некоторые из них стоит пояснить дополнительно.

Колонка «Merged Automatically?» может быть непустой только для успешных сборок. Она сообщает — были ли изменения перенесены в основную ветку Git-репозитория непосредственно роботами. Полностью автоматический перенос производится только для пакетов из репозитория Contrib, для основных пакетов, поддерживаемых сотрудниками РОСЫ, отправляется Pull Request на перенос изменений из ветки auto_update.

Колонка «Errors Recognized» пытается подсказать, почему именно не собралась новая версия. Скрипты запуска Updates Builder’а анализируют журналы упавших сборок и выявляют часто встречающиеся причины — ошибку применения патча, отсутствие файла и тому подобное. Сейчас этот анализ очень прост и распознает меньше десятка ошибок, но в будущем мы надеемся расширить охват.

«Last Build Date» отражает дату последней попытки обновить пакет. Для каждого пакета в таблице содержится только одна строчка, соответствующая последней попытке Updates Builder’а собрать его новую версию.

Надеюсь, эти отчеты смогут дать общую картину того, чем занимается Updates Builder. Учтите, что эти отчеты отражают именно результат работы Updates Builder’а. Если на основе этих результатов человек доработал обновленный пакет и собрал его, либо принял Update Request, в отчете это никак не отразится.

Разместил Denis.silakov 16 декабря 2013 19:45 (GMT), нет комментариев.

Поумневший инсталлятор и больше удобства в консоли

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

Однако, на самом деле, инсталляция может понадобиться неоднократно:

• теперь ведь обычно в семье несколько компьютеров (декстопов и планшетов).
• переинсталляция — это самый простой способ исправить любые неисправности, произошедшие как из-за ошибок собственного администрирования, после апгрейда/смены оборудования, либо из-за сбоев железа или системы обновлений.
• часто инсталлятором пользуется «продвинутый пользователь», устанавливая систему знакомым и родственникам.

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

---

Good news, everyone!

Во-первых, теперь при инсталляции используются технологии GeoIP, чтобы догадаться, где находится пользователь, и с вероятностью >90% правильно угадать:

• Язык ввода
• Локализацию
• TimeZone

Идея использовать GeoIP для угадывания языка-локализации-таймзоны…

Отличная 25 57% Неплохая 13 30% Неважно 2 5% Ошибочна 4 9%

Во-вторых, инсталлятор пытается придумать удачное имя для вашего компьютера. Казалось бы, это исключительно человеческая прерогатива («Адам назвал тигра тигром, потому что он был похож на тигра…»), но на практике, проводя юзабилити-тестирования, наблюдая за пользователями дистрибутива, мы обнаружили, что подавляющее большинство пользователей совершенно не хотели задумываться над этим вопросом в процессе инсталляции, и в результате, инсталлируемый лептоп получал ужасно оригинальное имя «localhost.localdomain». Это было даже у некоторых разработчиков…

Из-за этого потом возникает куча неудобств: несколько «localhostов» в локальной сети, неуникальные названия расползаются в системы удаленного администрирования или коллаборации (разные там дропбоксы и т.п.), и эту проблему проще предотвратить, чем прописывать как все это настраивать в скучной документации, которую никто не читает.

Как же назвать новорожденный Linux-desktop?

• Во-первых, мы спрашиваем логин первого пользователя и разумно предположить, чей это будет ноутбук или десктоп.
• Во-вторых, мы опрашиваем автоматически сам инсталлируемый десктоп, на тему производителя или модели. На самый худой конец, если мы не поняли, что это, инсталлятор по ряду эвристик выясняет, ноутбук это или десктоп — и именует соответственно «Laptop» или «desktop»

В результате, вместо «localhost.localdomain» мы получаем вполне вменяемый «masha-hp-2730», «stas-acer-travelmate-2480» или «vasya-desktop». В любом случае (если что-то не совсем угадали, или хочется что-то свежепридуманное внести в имя), сгенерированное имя можно поправить с меньшими временными затратами, чем придумывать с нуля и заново.

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

---

---

И наконец, вопрос прав.

Мы разумно предполагаем, что первый пользователь, которого зарегистрируют при инсталляции — будет системным админитратором. И хотя все — инсталляцию, настройки, в наших десктопах можно сделать через пользовательский интерфейс, часто, если пользователь-администратор владеет клавиатурой, все это сделать через консоль. Особенно это удобно, если не надо вводить root-ового пароля, используя sudo для отдельных команд, или sudo bash для интерактивных пользовательских сессий.

Поэтому, мы сделали так — самый первый пользователь, который создается при инсталляции (это либо единственный пользователь, либо «семейный администратор»), считается системным администратором, он внесен в группу wheel в sudoers и таким образом, получает большой бонус к удобству настройки и инсталляции, без необходимости вводить, и даже помнить root-овый пароль

Идея «прописать» первого пользователя в sudoers…

Отличная 28 80% Неплохая 5 14% Неважно 0 0% Ошибочна 2 6%

---

Ну, и как обычно, спросим…

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 8 20% Порадовала :) 26 65% Оставила равнодушным -_- 5 13% Огорчила :( 1 3%

Разместил Stanislav.fomin 3 декабря 2013 17:10 (GMT), 4 комментария.

OpenMandriva Association - встреча в Праге

С 22 по 24 ноября в Праге прошла встреча OpenMandriva Association — первая встреча основных участников разработки OpenMandriva, призванная наладить личные связи друг с другом, подвести итоги подготовки релиза OpenMandriva 2013.0, а также обсудить планы на будущее. Поскольку разработчики РОСЫ принимают участие в создании OpenMandriva, то и мы там были представлены.

География участников встречи получилась очень обширной — были участники из Бразилии, Германии, Индии (правда, удаленно — из-за проблем с визой), Италии, Польши, России, США, Франции и Швейцарии.

Сидят (слева направо): Denis Silakov, Marco Benatto, Cristina (rugyada), Maik Wagner, Kate Lebedeff, Jean-Claude Vanier

Стоят (слева направо): Robert Xu, Crispin Boylan (crisb), Bernhard Rosenkränzer (bero), Jochen Schönfelder (arisel), Nicolò Costanza, Raphaël Jadot (ashledombos), Tomasz Gajc (TPG), Colin Close (itchka), Paulo César Pereira de Andrade (pcpa)

Большое внимание было уделено вопросам организации разработки дистрибутива. Прошедший год характеризовался в первую очередь созданием фактически нового коллектива, формированием различных команд (ответственных за инфраструктуру, локализацию, собственно разработку и так далее), притиркой участников друг к другу. Неудивительно, что процесс подготовки первого релиза несколько затянулся — с момента выход Alpha-версии до финального релиза прошло пять месяцев. Однако теперь разработчики набрались необходимого опыта, наладили взаимоотношения и готовы думать о том, как работать над следующими релизами. В частности, все согласились с необходимостью иметь четкий план подготовки релизов со сроками и действиями, которые необходимо к этим срокам сделать. Была высказана идея в потребности менеджера проекта для разработчиков, который бы выполнял в первую очередь организационную работу — помогал с планированием, координировал усилия и тому подобное. Заодно в первом приближении сошлись на том, что следующий релиз следует ожидать примерно через год.

Из различных организационных моментов, которые обсуждались на встрече, можно отметить следующие:

• регулярная сборка ISO-образов со всеми обновлениями — чтобы после установки с образа не было необходимости сразу же ставить сотни обновленных пакетов; заодно рассмотрели и вопрос о налаживании выпуска DVD-дисков и USB-флешек с OpenMandriva для раздачи на различных мероприятиях и, возможно, для продажи;
• необходимость регулярного информирования аудитории о том, как идет процесс разработки дистрибутива — у нас вот есть «Точка РОСЫ», и OpenMandriva тоже хотела бы иметь регулярно обновляемый блог и новостную рассылку;
• необходимость поддержки релизов качественной документацией (например, в старой Мандриве было принято выкладывать документацию в виде HTML на сайте http://doc.mandriva.com/index.php, в РОСЕ мы предпочитаем использовать вики);
• бурное обсуждение вызвали вопросы, связанные с QA и контролем качества дистрибутива — пока у OpenMandriva нет четких политик по работе с сообщениями об ошибках, но они обязательно появятся с ростом популярности системы. Приятно, что в качестве хорошо поставленного процесса был приведен и регламент работы QA в РОСЕ, однако для OpenMandriva такой регламент вряд ли подходит — ведь этот дистрибутив развивается исключительно добровольцами и, возможно, его разработке требует менее формализованных процессов.

Сугубо технических обсуждений практически не велось, однако были рассмотрены некоторые глобальные направления, как то:

• использование clang в качестве компилятора по умолчанию — решили, что разработчики OpenMandriva попробуют ради эксперимента пересобрать весь репозиторий с использованием clang; Беро (Bernhard Rosenkränzer) пообещал привлечь одного из разработчиков LLVM к анализу проблем, которые при этом возникнут;
• избавление от drakxtools — разработчики OpenMandriva, как и мы, уже вдоволь «насладились» счастьем поддержки этого стека надстроек над Gtk2 более чем десятилетней давности с сомнительного качества кодом. Избавление от него — дело долгое, и решено было начать с инсталлятора, как одной из основных программ, завязанных на drakxtools. Небольшим мозговым штурмом попробовали прикинуть, что какими характеристиками должен удовлетворять новый инсталлятор. В плане реализации решили, что инсталлятор должен быть написан на Qt без привлечения дополнительных прослоек/надстроек, но также должен уметь работать и из командной строки и по сети. Однако главный вопрос пока остается открытым — кто именно будет заниматься этой работой, ведь задача достаточно серьезная, и если ей заниматься по вечерам на досуге, то времени она может отнять много.
• возможные аналоги urpmi — в первую очередь, речь шла об использовании libzypp и libsolv;
• адаптация Wayland.

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

• возможность привязывания проектов ABF к проектам на каком-либо сервере Transifex для удобной работы по локализации приложений, разработка которых ведется на ABF (в первую очередь это специфически для РОСЫ и OpenMandriva программы — urpmi, rpmdrake, drakxtools и основанные на них утилиты);
• дополнительные средства отслеживания активностей по работе над репозиторием — например, git-хуки, отправляющие e-mail заинтересованным разработчикам при коммите в тот или иной проект.

Наконец, одной из горячих тем стал вопрос, заданный на Facebook-странице OpenMandriva в комментариях к выпуску релиза — «Чем OpenMandriva отличается от РОСЫ»? Ведь OpenMandriva и РОСА действительно во многом основываются на одинх и тех же пакетах, что неудивительно — процесс переноса разработок активно идет в обе стороны, а многие разработчики одновременно работают над обоими дистрибутивами. К тому же в OpenMandriva решили использовать по умолчанию SimpleWelcome, так что и внешних различий оказалось не так много и вопросы пользователей вполне логичны. Но конечно, OpenMandriva — это не просто ROSA Desktop Fresh с переделанными иконками. Разработчики OpenMandriva хотели разъяснить этот момент и подчеркнуть уникальные особенности своей системы, в то же время не отрицая большого сходства с РОСОЙ. Главная мысль которая пронизывала все обсуждение — это что разработчики РОСЫ и OpenMandriva сотрудничают, а не «таскают» наработки друг друга. Однако различные подходы к разработке обуславливают и различия в системах, основной из которых является факт использования в OpenMandriva новых, но еще недостаточно хорошо протестированных технологий и продуктов — ведь в OpenMandriva нет таких строгих критериев QA, как в РОСЕ, и многое отдается на откуп мэйнтейнерам. Результирующий текст, описывающий разницу между OpenMandriva и ROSA можно найти на FAQ-страничке OpenMandriva.

Отмечу, что встреча вышла очень насыщенной. Изначально предполагалось, что официальное обсуждение будет проходить в субботу и воскресенье с 10:00 до 17:00, однако выяснилось, что большинство участников уезжают во второй половине воскресенья. В итоге часть программы перенесли на субботу, и работа в этот день кипела с утра до вечера с недолгим перерывом на обед в виде пиццы. Стоит ли говорить, что и в неофициальной обстановке существенная часть разговоров велась все на те же темы разработки и развития дистрибутива:) При этом работа проходила очень организованно — выступления были по делу, без пространно-философских рассуждений о жизни, докладчиков не перебивали, и даже дискуссии велись с уважением к мнению других сторон — к сожалению, в мире Open Source такая атмосфера царит далеко не всегда. Такой ответственный подход позволил обсудить большой пласт вопросов за относительно небольшой промежуток времени и при этом принять ряд серьезных конструктивных решений.

В целом, впечатления от встречи остались очень благоприятные. Разработчики OpenMandriva настроены на серьезную работу, а также на активное сотрудничество с РОСОЙ — все уверены, что совместная работа пойдет на пользу обеим системам. Так что в новый год — с новыми планами:)

Разместил Denis.silakov 25 ноября 2013 16:32 (GMT), нет комментариев.

Ядро nrjQL - "сердце" РОСЫ

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

Ядро Linux содержит огромное количество настроек и из одного и того же исходного кода можно собрать ядра, работающие совершенно по-разному. Кроме того, существует большое количество патчей, не входящих в основную ветку разработки, но представляющих интерес для определенных групп пользователей. Неудивительно, что различные дистрибутивы, даже базируясь на одной и той же версии исходного кода от Линуса Торвальдса, предоставляют своим пользователям ядра, имеющие серьезные отличия.

В РОСЕ используются варианты ядра Linux, изначально созданные участниками группы MIB (Mandriva International Backports) и получившие обозначения nrj и nrjQL. Что означают эти обозначения и что за ними стоит? Даем слово Николо Констанца (Nicolò Costanza), собирающему ядра для нашей ОС:

С технической точки зрения, в конфигурации «NRJ» для CPU and RCU включены опции Full Preemption (CPU Preemption, RCU Preempt tree). Набор патчей «QL» включает в себя различные патчи из набора Кона Коливаса (CK1) — такие, как планировщик работы с диском BFQ и планировщик задач BFS. Стоит отметить использование UKSM для лучшего управления памятью и TOI для улучшенной функциональности спящего режима. Все эти разработки созданы с учетом потребностей настольных машин и ноутбуков обычных пользователей. Так что мы стараемся получить ядро, с котором бы ОС для конечного пользователя выглядела бы как система реального времени в плане времени отклика приложений, с которыми он непосредственно работает.

Каково происхождение имени? Мы думали над коротким именем, в 2-4 символа. Было рассмотрено несколько вариантов, и в конце концов участники MIB остановились на NRJ. Среди других вариантов был, например, kernel-viagra, но оно одобрения не получил:) Название NRJ подчеркивает, что ядро действует на компьютер как энергетик на человека — такой вот RED BULL для машины, но это имя мы использовать не могли, равно как и другие зарегистрированные торговые знаки. В ситуациях, когда компьютер загружен различными задачами, а пользователю требуется высокая скорость реакции ОС, ядро NRJ добавляет вашей машине энергии. С ядром nrjQL ваша машина способна выполнять большой объем работ, в то же время сохраняя высокую отзывчивость.

Вот такое вот у нас ядро, если вкратце.

Отметим, что Николо собирает несколько вариантов ядер — как минимум, vanilla, nrj-laptop и nrj-desktop. За ходом работ всегда можно наблюдать в реопзитории Нико на ABF. Наконец, историю патчей и их использования в РОСЕ можно почитать на форуме MIB.

Репозиторий Нико на ABF — практически каждое минорное обновление ядра собирается и тестируется для РОСЫ

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

Наши дистрибутивы используете? Какие? Опрос.

Секундучку внимания, если вы используете какой-нибудь из наших десктопных дистрибутивов — пожалуйста, отметьте, какой — ваше мнение очень важно для нас!

Какой из наших дистрибутивов-систем вы используете в данный момент:

ROSA 2011 1 1% ROSA MARATHON 7 10% ROSA FRESH KDE 41 60% ROSA FRESH GNOME 9 13% ROSA FRESH LXDE 6 9% Неупомянутый дистрибутив от ROSA (секретные и т.п.). 3 4% Ничего из перечисленного 1 1%

Разместил Stanislav.fomin 21 ноября 2013 16:32 (GMT), 2 комментария.

Точка Росы №8

Выпускаем очередной дайджест, «точку сборки» технологических новостей компании, впрочем, новости не только технологические, и не только о фичах наших продуктов — также мы публикуем обзоры и видеозаписи IT-шных конференций, т.е. вещи интересные даже тем, кто далек от мира Linux/опенсорс/системное программирование. В любом случае — только хорошие и интересные новости!

Представляем его и в обычном формате вебжурнала «подборка статей с обложкой», так и в oldschool PDF-файле c полусотней страниц.

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

Итак, в восьмой выпуск «Точки РОСЫ» войдут:

«Фичи» — наши наработки и доработки, все для юзабилити и надежности: Мы покончили с национальной дискриминацией хоткеев в GNOME! Хоткеи для Windows-свитчеров. Смело переходите на GNOME! GNOME для нетбуков — режим без тормозов WiFi и Broadcom - работа над ошибками Легализация Gnome-tweak-tool

Инструменты мантейнера, качество репозитория: Urpmi, rpmdrake и автоматический выбор зависимостей Работаем над качеством пакетов, или Новости Rpmlint Linux Kernel ABI Tracker - инструмент для отслеживания изменений в ABI ядра Updates Builder – Pull Request'ы и автоматическое исправление ошибок сборки

IT-конференции — мы снимаем и публикуем записи разных IT-конференций, это интересно даже тем, кто не связан с Linux и Open-Source: talks.rosalab.com — конференции, которые всегда с вами OSSDEVCONF-2013 (Десятая конференция разработчиков свободных программ) OSDN-UA-2013 (Всеукраинская конференция разработчиков и пользователей свободных программ) LinuxCon Europe 2013 - О поиске "гонок" в ядре Linux Осенний листопад конференций! SECR, ProductCamp, AgileKitchen, WUD — смотрите все

Новости наших сайтов: Редизайн wiki.rosalab.ru — стильная мода для нашей вики talks.rosalab.com — конференции, которые всегда с вами

Как обычно, описание большого числа доработок GRUB2: Ряд улучшений и багфиксов для GRUB2 GRUB2: новый функционал - размеры и положение терминала

И еще раз отдельно — статьи-опросы, займут считанные секунды вашего внимания: Редизайн wiki.rosalab.ru — стильная мода для нашей вики Наши дистрибутивы используете? Какие? Опрос.

Кстати, в одной из статей предложен challenge с наградой «ноутбук с ROSA», может это кого-нибудь заинтересует.

И совсем скоро, через считанные дни мы зарелизим всю линейку наших десктопных дистрибутивов (ROSA FRESH KDE/GNOME/LXDE), и перед этим будут еще серия статей, про реализованные фичи, с боями исправленные баги, ну и может о внутренних процессах — разработки и тестирования, юзабилити исследований и т.п.

Разместил Stanislav.fomin, Alexey.yermakov, Stanislav.fomin, Alexey.yermakov, Eugene.shatokhin, Denis.silakov и Andrey.ponomarenko 21 ноября 2013 16:06 (GMT), нет комментариев.

Редизайн wiki.rosalab.ru — стильная мода для нашей вики

Мы планируем активно наполнять wiki.rosalab.ru документацией, ценными статьями, переводами, блогами наших команд, и многим другим… но нас смущает один момент.

Дизайн. Дизайн обычных вики-систем, он неплох, он сбалансирован так, чтобы было неплохо и читателю, и удобно редактору. Но «неплохо» — это недостаточно, ведь мы хотим привлечь не только опытных специалистов, которые привыкли к MediaWikам, дефакто стандарту баз знаний open-source проектов, но и, сорри, за избитый эфмемизм, «обычных пользователей» — на самом деле тех, кто «я не хочу ничего править, я хочу быстро почитать, и чтобы все было красиво и позитивно».

И в мире вебдизайна идут волны модного дизайна, «clear and simple», так, чтобы глаз отдыхал на иллюстрациях и дизайне, а все стандартные дизайны MediaWiki — это про плотные блоки пролинкованного текста сетевых энциклопедий, с кучей торчащих инструментов редактирования, доступа к истории правок, и т.п.

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

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

Итак, встречайте макет дизайна для нашей вики →

→ продолжить чтение…

Разместил Stanislav.fomin 14 ноября 2013 16:17 (GMT), 3 комментария.

Linux Kernel ABI Tracker - инструмент для отслеживания изменений в ABI ядра

Ядро операционной системы Linux постоянно развивается: улучшается поддержка оборудования, оптимизируются различные подсистемы ядра и др. В результате этого размер ядра и количество его ABI/API интерфейсов постоянно растет от версии к версии. При этом, в процессе разработки, могут быть изменены некоторые старые интерфейсы, что может неблагоприятно повлиять на работу других программных компонентов, использующих интерфейсы ядра: модулей, драйверов, динамических средств тестирования и трассировки ядра и др.

Для регулярного автоматического анализа изменений в интерфейсах ядра мы разработали инструмент Kernel ABI Tracker. Этот инструмент следит за появлением новых версий ядра на офф. сайте kernel.org, собирает их и анализирует изменения с помощью набора базовых инструментов. Для каждой версии ядра создается так называемый ABI dump ("снимок" или "дамп" ABI ядра) из его debug-информации при помощи инструмента ABI Dumper. Дамп ABI включает в себя информацию о всех публичных экспортируемых интерфейсах ядра, их параметрах и структуре типов данных. Для получения отчета об изменениях в двух версиях ядра сравниваются два соответствующих дампа ABI при помощи инструмента ABI Compliance Checker. В отчете описаны все изменения в интерфейсах ядра и разделены по уровню опасности для приложений. Отдельно описаны добавленные и удаленные интерфейсы, изменения в типах данных и в параметрах интерфейсов. Кроме своего прямого назначения дампы ABI могут также использоваться для других видов анализа интерфейса ядра сторонними разработчиками и поэтому доступны для скачивания всем желающим.

Интерфейс инструмента предоставляет отчеты о результатах тестирования defconfig-конфигураций всех последних longterm, stable и mainline версий ядра. На главной странице показан график зависимости количества интерфейсов ядра от версии. На данный момент результаты получены для двух архитектур: x86 и x86_64. Поддержка архитектуры arm планируется в ближайшее время. Также планируется тестирование других конфигураций ядра, например, allyesconfig.

Базовые инструменты ABI Dumper и ABI Compliance Checker, ранее разработанные в компании РОСА для проверки совместимости Си-библиотек, потребовали существенных изменений для возможности анализа изменений в ядре Linux. В силу огромной глубины дерева структур данных ядра и большого количества интерфейсов, требуемые для обработки одной версии ядра процессорное время и объем оперативной памяти были неудовлетворительными и вследствие были оптимизированы в несколько раз до нормальных величин. В результате этих улучшений, инструменты теперь работают быстрее при анализе библиотек большого объема. Код новых версий этих инструментов был выложен на их офф. сайте.

Разместил Andrey.ponomarenko 12 ноября 2013 14:50 (GMT), нет комментариев.

Работаем над качеством пакетов, или Новости Rpmlint

Одним из инструментов проверки корректности пакетов, с которым волей или неволей имеет дело каждый мэйнтейнер, является Rpmlint. Этот инструмент, проверяющий соответствие пакетов политикам дистрибутива, запускается автоматически при каждой сборке на ABF. Также мы проводим регулярный мониторинг репозиториев РОСЫ на портале FBA.

Правила сборки пакетов не высечены в камне и меняются со временем. Кроме того, время от времени появляются новые идеи - что еще можно статически проверять в собранных пакетах. Не стоит на месте и Rpmlint. Недавно мы провели его рефакторинг, выбросив неактуальные для РОСЫ проверки - вызов ldconfig в post-скриптах, определение и очистка BuildRoot и ряд других. Эти проверки уже долгое время не использовались, но загромождали код и увеличивали время работы инструмента.

Помимо чистки кода, мы добавили и ряд новых возможностей.

Во-первых, мы усилили проверки пакетов, исполнимые файлы или библиотеки которых выставляют параметр RPATH. Этот параметр влияет на то, в каких каталогах производится поиск библиотек при загрузке приложения - пути, указанные в RPATH, просматриваются в первую очередь. Пользоваться этой возможностью следует аккуратно, особенно в библиотеках, которые могут использоваться другими компонентами дистрибутива. В РОСЕ при необходимости использовать RPATH в каком-либо пакете рекомендуется помещать все библиотеки, доступ к которым будет контролироваться RPATH, в отдельный подкаталог директории /usr/lib (желательно, чтобы имя подкаталога совпадало с именем пакета - например, /usr/lib/fglrx содержит библиотеки, специфичные для fglrx). Если же RPATH указывает на директорию, в которой могут оказаться не ожидавшиеся авторами пакета библиотеки, то поведение приложений может оказаться непредсказуемым. Часто встречающимся примером такого рода является установка RPATH в системные значения наподобие /lib или /usr/lib. Как показала практика, установка RPATH в такие значения может оказаться даже фатальной - например, мы недавно исправили проблему с Empathy, "падавшего" на системе с драйверами Nvidia из-за RPATH, выставленного в библиотеке libwebkit (используемой Empathy). Отныне Rpmlint выявляет такие ситуации непосредственно при сборке пакета и при обнаружении исполнимого файла или библиотеки, в которых RPATH установлен в /lib, /usr/lib, /lib64 или /usr/lib64, останавливает сборку с ошибкой.

Во-вторых, по просьбе команды локализации, мы добавили проверку desktop-файлов в пакетах на предмет наличия в них непереведенных на русский язык описаний. Локализация таких файлов является важной, ведь именно информация из них используется для предоставления пользователю сведений о приложении, запускаемом при нажатии на ту или иную иконку. Поскольку такая проверка предназначена только для русскоязычных разработчиков, мы не стали включать его в основную ветку Rpmlint, распространяемую с РОСОЙ. Этот тест используется только при запуске тестов на FBA и результаты его можно наблюдать в соответствующих разделах FBA. Например, для репозитория main дистрибутива ROSA Desktop Fresh R1:

Непереведенные названия

Непереведенные описания

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

Наконец, Rpmlint теперь может проверять корректность суффиксов в названиях пакетов. В РОСЕ каждой версии дистрибутива соответствует свой суффикс, который автоматически выставляется средой сборки. Однако бывают ситуации, когда пакет не собирается на ABF, а подкладывается в репозиторий руками из другой версии дистрибутива. Например, некоторые пакеты имеют кольцевые сборочные зависимости, и для пересборки таких пакетов под новую версию дистрибутива проще всего использовать уже собранные зависимости из предыдущей версии. Как правило, "подложенные" пакеты удаляются из репозитория, как только в них отпадает необходимость. Однако человек может и забыть удалить какой-либо пакет, поэтому надежнее автоматизировать их отслеживание. Чем теперь и занимается Rpmlint, а точнее - проверка non-standard-distsuffix.

Список "корректных" суффиксов необходимо задавать в настройках Rpmlint, в параметре ValidDistSuffixes.

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

WiFi и Broadcom - работа над ошибками

Две проблемы, связанные с обработкой ошибок, были исправлены нашими разработчиками в проприетарном драйвере для WiFi-адаптеров Broadcom (broadcom-wl, он же broadcom-sta, он же wl). Обе эти проблемы (#2146, #2667) приводили к падению ядра при загрузке системы на ноутбуках у некоторых наших пользователей.

Кстати, на момент подготовки этого материала указанные ошибки далеко не во всех популярных дистрибутивах Linux были исправлены.

→ продолжить чтение…

Разместил Eugene.shatokhin 29 октября 2013 17:27 (GMT), нет комментариев.

LinuxCon Europe 2013 - О поиске "гонок" в ядре Linux

22 октября состоялось выступление нашего сотрудника Евгения Шатохина на конференции LinuxCon Europe 2013. Речь шла о средствах поиска таких трудноуловимых ошибок, как «состояния гонки», они же «data races» в компонентах ядра Linux (слайды, пояснения к слайдам).

По одному из определений, data race — это такая ситуация, когда два или более потока выполнения (threads) одновременно обращаются к одной и той же области памяти и хотя бы один из этих потоков что-то записывает в эту область памяти.

Такие ситуации далеко не всегда просто выявить, а последствия у них могут быть самыми разными, от незначительных до критических. Для ядра Linux это особенно актуально: код драйверов, например, может выполняться многими потоками одновременно. Добавим к этому обработку прерываний и других асинхронных событий, а также учтём, что правила синхронизации доступа к общим данным из разных потоков далеко не всегда описаны чётко (а нередко — не описаны вообще)…

Об инструментах, позволяющих выявлять data races в компонентах ядра Linux, в основном, и шла речь в выступлении. Наиболее подробно — о системах KernelStrider и RaceHound, одним из основных разработчиков которых Евгений и является.

KernelStrider собирает информацию об анализируемом компоненте ядра (например, драйвере) в процессе работы этого компонента. Информация об обращениях к памяти, выделении и освобождении памяти, блокировках и т. д. затем, уже в user space, анализируется инструментом ThreadSanitizer (Google). Алгоритм поиска races коротко описан тут.

KernelStrider может в некоторых случаях выдавать сообщения о data races там, где data races нет («false positives»). Например, при анализе сетевых драйверов такое было в случаях, когда драйвер отключал генерацию прерываний соотв. устройством и затем обращался к каким-то общим данным, не опасаясь конфликтов с функцией-обработчиком прерываний.

Система RaceHound позволяет проверить результаты, полученные с помощью KernelStrider, найти среди них те, которые, действительно говорят о data races. RaceHound работает так:

• На инструкцию в коде ядра, которая может быть «замешана» в data race, ставится программная точка прерывания («software breakpoint»).
• Когда эта точка прерывания срабатывает, RaceHound определяет адрес области памяти, куда эта инструкция обратится, и ставит аппаратную точку прерывания («hardware breakpoint»), чтобы отследить обращения нужного вида к этой области (только запись или произвольные обращения).
• Делается небольшая задержка перед выполнением интересующей инструкции.
• Если во время задержки какой-то другой поток обратится к указанной области памяти, аппаратная точка прерывания сработает и RaceHound сообщит о найденной data race.

То есть при анализе компонентов ядра KernelStrider работает своего рода «детективом-аналитиком», сужая круг «подозреваемых» — мест в коде, которые могут участвовать в data races. RaceHound тогда — система слежки за этими подозреваемыми. Если ей удаётся поймать подозреваемого с поличным (то есть при выполнении конфликтующих доступов к памяти) — всё ясно. Если не удаётся — это ничего не значит.

Как во время, так и после доклада, вопросов было довольно много. Слушателей интересовали, например, такие вещи, как:

• Планируется ли поддержка ARM (пока всё работает только на x86), — возможно, но не в ближайшем будущем.
• Может ли KernelStrider пропускать data races (то есть возможны ли false negatives) — да, может в некоторых случаях, в основном, из-за особенностей алгоритма работы ThreadSanitizer и из-за неточностей используемых правил определения порядка событий.
• Переживает ли KernelStrider suspend/resume — да, переживает.
• Можно ли с помощью KernelStrider и RaceHound анализировать не только модули ядра, но и само ядро — пока нет.
• Можно ли в KernelStrider инструментировать код анализируемого драйвера не при загрузке этого драйвера, как сейчас, а при компиляции — очень вероятно; это одно из возможных направлений развития.
• и т. д.

В обсуждении data races, найденных указанными выше инструментами, активно участвовали сотрудники Intel, что немудрено: речь шла о races в сетевом драйвере e1000, разработанном как раз в этой компании. Во время обсуждения выяснился интересный факт: для обращений к памяти в некоторых частях сетевых драйверов средства синхронизации использовать почему-то не принято, хотя там из-за этого могут быть «гонки» (они там и обнаружились). Это, в частности, относится к NAPI и функциям драйвера, участвующим в передаче данных по сети. Вроде бы всё так делается, чтобы избежать потерь производительности из-за блокировок, но ни оценок этих потерь, ни конкретных рекомендаций, как при этом избежать проблем из-за «гонок», пока найти не удалось.

В целом, похоже, что отношение к data races у многих разработчиков ядра такое:

— Что-то из-за этой data race упало или стало работать неправильно?

— Пока не замечали.

— А, ну, ладно.

И на этом разговор кончается.

Логично? Вроде бы да, но, если вспомнить, например, вот эту статью, всё уже не так очевидно.

Разместил Eugene.shatokhin 29 октября 2013 12:15 (GMT), 3 комментария.

Ряд улучшений и багфиксов для GRUB2

Наши разработчики продолжают работать над улучшением загрузчика GRUB2.

Были реализованы и приняты в апстрим ещё 14 патчей.

→ продолжить чтение…

Разместил Vladimir Testov 22 октября 2013 10:08 (GMT), нет комментариев.

OSDN-UA-2013

Неделю, только опубликовав видео с OSSDEVCONF-2013, поехал с с миссией видеосьемки в Киев, на конфу с длинным названием «Всеукраинская конференция разработчиков и пользователей свободных программ», нареку ее сразу для краткости OSDN-UA-2013 (собственно аббревиатуру «OSDN-UA» я уже использовал в прошлом году, когда тоже снимал ее и публиковал видео, так что с «брендингом и неймингом» все ОК).

Да, путь неблизкий, SYSTEM INTERRUPTS таможнями и пограничниками, все дела, хотя в этот раз добрался удачней. В прошлом году организаторы рекомендовали мне взять такси на вокзале… и мне достался какой-то сельский крендель, который возил меня (с распечатанным адресом и картой) битый час, и умудрился высадить за пять км от цели — и я еще час плюхал пешком ориентируясь по Яндекс.Картам. В этот раз я опросил Яндекс.Карты сразу, и обнаружил, что до места конференции можно 20 минут доехать на самом модном евротранспорте — трамвае, параллельно устроив себе небольшую экскурсию. Опять куча оборудования, хотя и поменьше.

Место было прошлогоднее, в бывшем ДОСААФ-клубе. В принципе, хороший зал — большой, вместительный, с мягкими креслами, но… погода внесла некоторые коррективы — уже были заморозки, но отопительный сезон еще не начался… так что зал превратился в промороженную пещеру (народ выходил греться на улицу), а конференция заслуженно приобрела статус реально «отмороженной».

Так что не удивляйтесь, что увидите на видео зал закутанных людей в шапках и куртках, и кстати — не удивляйтесь, что увидите зал. Ибо несмотря на то, что народ от камер обычно прячется:

--- Где сядем?

--- Да все равно, главное --- не возле камер.

©

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

Конечно, эта самая воспринимаемость сильно бы улучшилась прокачкой presentation skills, после прошлогодней конференции я буквально умолял Мишу Шигорина сделать рассылку моей памятки докладчику, ибо тут был и подготовленный ноут со стилус-экраном и возможностью на нем рисовать, ноут поставлен на трибуну, удобно к докладчику — можно было добавить интерактива… хотя хотелось бы выполнить хотя бы программу-минимум — чтобы докладчик не читал слайды с экрана, развернувшись к аудитории задом. Увы, даже с этой мелочью окончательно справиться не удалось — эти неправильные рефлексы у многих уже на уровне подкорки, и их надо как раба, выдавливать из себя по капле.

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

Хватит о бытовухе, перейдем к краткому обзору докладов. Как обычно, видео смонтировано с записью экрана, приложены «развернутые» слайды для моментального обзорного ознакомления, и в пару кликов можно выйти на другие доклады автора или его страничку в соцсети, ну а если кого-то покусал RSM, или ненависть к флешу — там везде есть ссылки на HTML5-видео, впрочем, его можно также тупо скачать пачкой, и не читать мою классификацию-ревью дальше.

→ продолжить чтение…

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

Хоткеи для Windows-свитчеров. Смело переходите на GNOME!

Про «инновационную оболочку», ну или если многословно и официально — «окружение рабочего стола, GNOME SHELL», в сообществе линуксоидов сложилось несколько превратное, хотя и местами обоснованное мнение, что это слишком инновационно и не для «простых людей». Некоторые даже причисляют GNOME SHELL к так называемым post desktop интерфейсам, уходящим вдаль от классической метафоры «захламленного рабочего стола», с переключением задач через вездесущую панель.

Да, в GNOME SHELL есть большая схожесть с MacOS, и можно было бы надеятся, что эта схожесть сможет привлечь макюзеров…, но взглянем в глаза жестокой правде — их доля тоже невелика, в то время как высока их «верность Яблоку».

А основная масса потенциальных пользователей Linux Desktop, это — вольные или невольные пользователи Windows, и хотелось бы зазвать именно их, причем не только на схожие интерфейсы KDE/LXDE, но и на GNOME SHELL — ведь на самом деле, GNOME вполне расширяем, там легко поставить привычную панель задач, а визуальные метафоры GNOME SHELL тоже вполне неплохи, и хотя их почему-то считают «планшетоориентированными», они весьма эффективны, например, для ноутбуков с небольшим экраном.

Более того, аскетичная минималистичность GNOME SHELL, с минимумом открытых и мигающих панелей-виджетов и прочих свистелок и перделок, ориентирована в первую очередь на продвинутого пользователя, который уже несколько лет как ушел от исследовательского тыкания в эти самые виджеты и гаджеты, он уже вполне понимает про приложения, окна и их переключение, он владеет базовыми хоткеями, ему уже надо «работу работать», а не «скрепку Боба» и кучу мигающих скеоморфных значков, отвлекающих его от документов, текста, кода…

Но. Если достаточно легко понять изменение некоторых метафор (лаунчер «не иерархическое меню по кнопке пуск, а полноэкранное», «Dash» вместо панели, нижний док вместо «tray»…), то вот изменить клавиатурные навыки невозможно очень, очень непросто. Они уже «опустились» на уровень рефлексов и костного мозга, и если смена Desktop Environment — это как новый автомобиль — да, множество мелочей находится в непривычных местах, возможен ступор при поиске кнопок управления стеклоподъемниками и т.п., то управлять машиной, если перепутаны педали — нереально (см. также размышления в Blog:Точка Росы/Мы покончили с национальной дискриминацией хоткеев в GNOME!). Особенно, если приходится ездить на разных машинах.

Собственно среднепродвинутый Win-бизнес-пользователь привык к продвинутым Windows клавиатурным хоткеям серии «WIN+XXX», когда по WIN-E у него откроется «Проводник по файлам», по WIN-D → уберется свалка окон, чтобы открыть свалку ярлыков на нескучных обоях, а кнопки «WIN←» и «WIN→» легко, без специальных тайлинг-менеджеров и виртуальных рабочих столов наведут порядок в перекрывающихся окнах. Это было замечено и девствене пробовавшими linux desktop пользователями на наших юзабилити-сессиях, и собственно, сотрудниками компании, которые еще помнят Windows.

Особенно, если параллельно нужно использовать декстопы на GNOME и Windows, ведь это сейчас совершенно нормальная ситуация. Времена, когда люди становились в очередь к компьютеру прошли, сейчас наоборот, вполне возможно, когда на лично-развлекательном ноутбуке — GNOME, а на работе нужно сидеть в постылой Windows XP. Или наоборот, дома игровой бокс с виндами, а на работе — строгий корпоративный GNOME.

На всех клавиатурах есть привычная кнопка «WIN», и есть куча привычных навыков — «позвать файловый менеджер по WIN-E», «WIN-D, чтобы убрать свалку окон со стола, чтобы увидеть помойк аккуратно разложенные иконки на любовно выбранных обоях», «WIN+←» или «WIN+→», чтобы сделать мгновенно сделать тайлинг окон на большом мониторе, или «WIN+↑», чтобы наоборот, максимизировать окно на маленьком экране лептопа…

Так вот, если смотреть на стандартные хоткеи самых распространенных DE, то оказывается, что многие Windows-хоткеи совпадают с как раз с хоткеями GNOME по умолчанию.

К сожалению, правда, далеко не все.

---

Good news everyone!

Мы реализовали «ROSA Hotkeys» — специальное расширение для GNOME, который поддерживает большую часть самых необходимых хоткеев.

Расширение для GNOME, обеспечивающее поддержку ряда широко известных горячих клавиш для управления рабочим столом.

Запускалки

Win+L

(и/или Ctrl+Alt+Del) — Заблокировать компьютер.

Win+R

Открыть окно «Выполнить».

Win+Е

Запуск файлового навигатора (Nautilus).

• Shift+Ctrl+N

  Создать новую папку.

Win+F

Открыть окно поиска.

Сtrl+Shift+Esc

Открытие диспетчера задач (Запуск gnome-system-monitor).

Win+Pause

Свойства системы (Центр управления) .

---

Окна

Win+D

Показать рабочий стол (свернуть все окна).

Win+Home

Свернуть все окна, кроме активного.

Win+←/Win+→

Вертикальный Tiling — окно занимает полмонитора слева/справа соответственно.

Win+Shift+↑

Развернуть по максимуму окно по вертикали.

---

Многомониторные конфигурации

Win+Shift+←/Win+Shift+→

Перенаправить окно на соседний монитор.

Win+P

Переключение режимов «проектора» — клон → расширенный стол → только второй монитор → только основной.

---

По умолчанию, это расширение установлено и включено.

• Если оно не установлено, то установите его:

urpmi gnome-shell-rosa-hotkeys

• Если оно выключено, то его надо включить через «Параметры → Дополнительные параметры системы → Расширения Shell → ROSA hotkeys».

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

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 9 27% Порадовала :) 18 55% Оставила равнодушным -_- 5 15% Огорчила :( 1 3%

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

Легализация Gnome-tweak-tool

Согласно концепции GNOME-строителей, восходящей к патернализму яблочной компании, пользователю не нужны настройки системы, ведь в правильно сделанной системе все уже правильно!

Отсюда и серьезная бедность настроек GNOME SHELL по сравнению с KDE, в котором, правда серьезно ударились в другую крайность, и что самое обидное — настройки то остаются, только они исключены из стандартных «Параметров», и заметены под плинтус доступны из отдельных утилит, в частности, утилиты gnome-tweak-tool, недоступной из стандартного интерфейса, да и зачастую не входящую в образ дистрибутива.

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

В целом, сейчас ситуация с настройками GNOME SHELL скорее близка к ненасыщенной — многие очевидно необходимые настройки спрятаны в gnome-tweak-tool. Некоторые настройки мы выносим с чулана gnome-tweak-tool на свет «Параметров», например, «Настройки шрифтов», но в любом случае, надо сделать его «легализовать твикер», сделав туда легким вход любому пользователю.

И мы сделали это, добавив вызов gnome-tweak-tool из «Параметров», назвав его, после некоторых дебатов, «Тонкие настройки»

Да, название получилось длинноватое и скучно… Впрочем, если у вас есть удачные предложения — пишите в комментарии, рассмотрим все варианты!

Разместил Stanislav.fomin 15 октября 2013 17:32 (GMT), 2 комментария.

GNOME для нетбуков — режим без тормозов

Несмотря на то, что у нового пользователя название GNOME вызывает ассоциации с гномами, чем-то небольшим и компактным, современный GNOME (>3.6.2) очень плохо подходит для нетбуков и слабого железа.

Разработчики-гномеры всегда устремлены в будущее, и заложились на то, что в компьютере обязательно есть мощная видеокарта, на которую они и возложили все оконные хитрости, со всеми суперэффектами, свистелками и … А если такая видеокарта не обнаруживалась, всем этим приходилось заниматься процессору, и возникал очевидный эффект → «уже сейчас видно, что все будет глючить и тормозить™».

Теоретически, в GNOME есть специальный режим, «GNOME classic», от которого пользователь ожидал, что там все будет, «как при бабушкеGNOME2» — c меню в левом верхнем углу, без свистелок но и без тормозов. К сожалению, нет — меню в этом режиме появлялось, но вот тормоза и свистелки никуда не девались, причем тормозит и оконная система, и даже видео — тупо не посмотреть без дергания сериальчики, даже не в HD!

Дело в том, что в GNOME 3.8 решено было полностью отказаться от режима совместимости (fallback-режима), работающего со старыми проверенными компонентами окружения Gnome — gnome-panel и metacity, в пользу сосредоточения всех усилий разработчиков на дальнейшем развитии gnome-shell, без оглядки на «старое железо». В результате, gnome-panel перестал развиваться и остановился на версии 3.6.2, а из компонентов среды, таких как gnome-settings-daemon и nautilus был вырезан функционал по взаимодействию с gnome-panel.

Мы решили поправить ситуацию и начали с портирования gnome-panel на библиотеки из состава GNOME 3.8. После этого, мы вернули необходимый функционал по взаимодействию с gnome-panel в gnome-settings-daemon и nautilus, и тем самым восстановили fallback-режим в GNOME 3.8.

Теперь все летает даже на вымершем классе нетбуков, и если вы хотите подарить старый нетбук теще — уже не обязательно ставить LXDE или WinXP, а можно и новый GNOME с привычным обличьем.

Тестируем воспроизведением видео высокого разрешения:

Кстати, совсем свежий проект Gnome Flashback ставит своей целью добиться того же и даже большего — помимо простого восстановления работоспособности, планируется продолжать развитие компонентов, в том числе портировать их на GTK+3.

Но на данный момент произведено лишь портирование gnome-panel для работы в GNOME 3.8 и восстановление сессионной записи для Gnome Fallback.

Тем не менее, очень надеемся, что этот проект будет развиваться, так как иметь поддержку нужного функционала в upstream’е — всегда хорошо.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 48 25% Порадовала :) 127 66% Оставила равнодушным -_- 13 7% Огорчила :( 5 3%

---

Update

К сожалению (а может и к счастью), обнаружилось, что этот режим не востребован. Поэтому начиная с GNOME 3.12, и релиза R5, мы его исключаем. Для слабых компьютеров, мы по-прежнему рекомендуем использовать либо LXDE, либо оптимизацию KDE.

Видео лицензионное, самодельное, секретное — запись демонстрации UX Team

По статистике установок, отзывам, и опросам

Разместил Alexey.yermakov 30 сентября 2013 18:43 (GMT), нет комментариев.

OSSDEVCONF-2013

19-22 сентября в Калуге прошла Десятая конференция разработчиков свободных программ, там же, мы назвали ее для краткости и твиттера OSSDEVCONF-2013. Собственно раньше она проходила в Обнинске, но в этот раз организаторам удалось найти более приличное место, и не сильно дальше от Москвы, место, удобное для туризма — старинный русский город, колыбель Циолковского, и при этом еще есть интернет и островки высоких технологий.

Туда высадился и десант из «РОСЫ» — с докладами, и, что, возможно более интересно, с кучей видеотехники — сто килограмм штативов, камер, фотоаппаратов, ноутбуков и прочего. Да, мы стараемся снять и опубликовать проходящие конференции про линукс и опенсорс (см. например, OSDN-UA-2012, PingWinFest-2012, OSEDUCONF-2013, ROSS-2013, OSSDEVCONF-2013), чтобы увеличить аудиторию докладов (см. Blog:Точка Росы/talks.rosalab.com — конференции, которые всегда с вами).

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

Но в этот раз все было в очень цивилизованном месте, в IT-центре «Астрал», который хоть и находился среди пасторальных российских пейзажей прошлого тысячелетия, но в котором все было отлично и с проекторами, и со звуком, комфортными креслами и столиками, и кстати, с кофе, бутербродами и плюшками — так что если вы думали приехать, но не собрались — зря. Wish you were here!

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

Сорри за качество фото, там были фотографы с большими объективами, но у них почему-то не получились, поэтому пришлось надергать кадров из видео.

В целом, очень большая часть докладов была связана с организатором — ALT LINUXом, и ALT-овая тусовка была и среди докладчиков и среди участников (см. «видеофотки» справа). Технологии сборки и дистростроительства, история и перспективные эксперименты с ARM-овым железом, всего понемногу:

• Прошлое, настоящее и будущее школьного комплекта ALT Linux (Андрей Черепанов, OSSDEVCONF-2013)
• Systemd в ALTLinux (Алексей Шабалин, OSSDEVCONF-2013)
• Mkimage-profiles, как инструмент укрощения ARM (Михаил Шигорин, OSSDEVCONF-2013)

• Крутим ARM в руках (Глеб Фотенгауэр-Малиновский, OSSDEVCONF-2013)
• Deepsolver. Статус разработки и предложения (Михаил Пожидаев, OSSDEVCONF-2013)

• кластер автоматизации сопровождения пакетов (Игорь Власенко, OSSDEVCONF-2013)

---

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

Про это и доклады и двухчасовой мастер класс Игоря Власенко, и доклад нашего ведущего системного архитектора:

• ROSA Updates Builder — автоматическое обновление пакетов из апстрима (Денис Силаков, OSSDEVCONF-2013)

За скобками обсуждений об оптимальной автоматизации, правда остался философский вопрос — ведь все таки изначально «дистростроительство с ментейнерами» подразумевало действительно, «феодальные наделы», множество ручной, «ремесленной» работы, «цеховые» регламенты «гильдии» ментейнеров, и плотную, духовную или практическую связь ментейнера с пакетом, когда ментейнер отлично разбирался и во внешнем, и внутреннем интерфейсе поддерживаемой софтины, активно пользовался ей, замечал косяки сборки, отвалившиеся фичи, баги, да и следил за изменениями, минимизируя шансы внедрения подлых закладок. А теперь, когда изменения роботизированно расползаются по репозиториями, а пакеты лишаются «души», то даже опенсорс не может служить защитой от внедрения хитрых типов уязвимостей, о чем и был доклад-дискуссия Проблема доверенного компилятора в механизме сертификации ПО (Дмитрий Державин, OSSDEVCONF-2013)

---

Лично меня очень заинтересовали доклады Михаила Пожидаева. В одном он рассказал о обреченном?смелом подходе к инсталляции пакетов через решение NP-полных задач → Статус разработки и предложения (Михаил Пожидаев, OSSDEVCONF-2013).

Немедленно вспоминается классика:

… — Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.

— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как её решать.

— Как-то странно ты рассуждаешь, Кристо… Как же искать решение, когда его нет? Бессмыслица какая-то…

— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идёт о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос… © «Понедельник начинается в субботу»

Честно говоря, при всем уважении к смелости подхода, возможно это тупиковый путь, причем для всех RPM-дистрибутивов. В любом случае, это очень интересная задача, наверно надо будет ее обсудить со студентами (тянет на диплом, а в магическом случае полного решения — на Филдсовскую премию).

Второй же его доклад → Luwrain. ОС для людей с проблемами зрения (Михаил Пожидаев, OSSDEVCONF-2013), внезапно решено было закончить реальной демонстрацией того, что практически никто не видел → интерфейсом для слепых пользователей. Это было удивительно и пугающе, практически постапокалепсичная картина → затемненный подвал, мигающие черные буквы на красном фоне, механический голос компьютера и последние люди у клавиатуры… Это надо видеть, и это наверно обязательно надо посмотреть UX-специалистам, ибо UX → это не про раскрашивание кнопочек и шрифты.

---

Разумеется, не обошлось без роботов, рожденных как ползать, так и летать → был доклад и даже целый мастер-класс → Образовательный проект по робототехнике УМКИ на основе СПО (Игорь Воронин, OSSDEVCONF-2013)

---

Ребята из ИСПРАНа, поддерживающие проект «Linux Driver Verification», рассказали о мощных технологиях статического анализа, которыми они мучают линуксовые ядра, к сожалению, насколько я понял, сами технологии тащить в отдельное дистростроительство сильно непросто, с другой стороны, пока эти ребята работают, ядро линукса улучшается во всех дистрибутивах.

• Оценка покрытия кода при статическом анализе (Павел Андрианов, OSSDEVCONF-2013)
• Генерация модели окружения для группы модулей ядра для статической верификации (Илья Захаров, OSSDEVCONF-2013)

---

Веселая дискуссия вышла и по окончании доклада О свободных форматах публикации результатов научных исследований (Филипп Занько, OSSDEVCONF-2013) → ведь действительно, все старые форматы, ориентированные на обязательную страничную печать статей, и распространение через монопольных монстроиздательства, надо выпиливать, переходя к

• свободному распространению
• веб-публикации материалов.

И раздумывать надо уже над конкретными технологиями «авторинга», чтобы можно было максимально и совместно создавать контент, эффективно донося идеи до аудитории.

В некотором смысле, можно сравнить oldschool бумажные сборники тезисов конференции и страницы с аннотированным видео докладов → возможно пока еще бумага и нужна, но еще несколько лет, и бумажные носители точно можно будет списывать, а в вебпубликации, кроме текста, картинок и формул (уже можно в SVG-виде), видео и аудио, появятся какие-нибудь живые интерактивные модели, и вопрос, что лучше будет закрыт окончательно.

---

Были еще и другие доклады, например,

• Простой стек технологий для BDD-style разработки SPA на coffescript (Михаил Быков, OSSDEVCONF-2013)

но в целом, думаю, можно завершить наш краткий обзор, и рекомендовать читателю (вы еще с нами? — поздравляю, вы осилили мои многобукв!) собственно перейти к просмотру заинтересовавших докладов.

---

Впрочем, еще один момент. Без потерь обойтись не удалось. Были и материальные поломки (колесо, аккумулятор ноутбука и т.п.). И, нематериальные — возможно потерян один доклад. Несмотря на многократную перестраховку (сьемка экрана фотоаппаратом, скринкастом на ноутбуке и захват фреймбгаббером), некий фейл случился → испорчен MP4 файл с записью экрана.

Если вы действительно разбираетесь в видео, (ffmpeg, VLC, untrunk, mplayer, mencoder я уже пробовал), попробуйте починить. Вот торрент с этим файлом (8GB!), если у кого получится — напишите мне, обещаю подарить ноутбук с ROSA Fresh.

И кстати — пишите мне, если вдруг видите косяки монтажа (не видно что-нибудь, или не слышно) — пока еще исходники есть, все это можно поправить. А вот если баги не заметят за несколько недель, значит,… значит…, наверно их и не надо править.

Разместил Stanislav.fomin 30 сентября 2013 14:18 (GMT), нет комментариев.

Updates Builder – Pull Request'ы и автоматическое исправление ошибок сборки

Репозитории ROSA Desktop Fresh R1 содержат порядка 15.000 пакетов, способных удовлетворить нужды практически любого пользователя. Однако поддержка такого обширного набора библиотек, приложений, утилит и прочих программных компонентов — задача непростая. Ведь новые версии многих программ выходят очень часто, и мэйнтейнерам необходимо оперативно отслеживать их появление, собирать их для РОСЫ, тестировать и решать — стоит ли обновлять пакет в репозитории до новой версии. Для автоматизации подобных задач мы используем инструмент Updates Builder, осуществляющий мониторинг апстрима и автоматически собирающий новые версии программ на ABF.

До недавнего времени процесс работы Updates Builder’а был незатейлив — он брал имеющийся spec-файл от старой версии пакета, заменял в нем версию и имя файла с исходным кодом и пытался собрать новый пакет. Практика продемонстрировала эффективность такого подхода — достаточно часто новые версии содержат минимум изменений по сравнению с предыдущими, и никаких серьезных изменений в spec-файле для их сборки не требуется. Как результат — за три месяца использования Updates Builder’а мы с его помощью обновили несколько сотен пакетов. Но аппетит приходит во время еды, и нам захотелось еще больше повысить эффективность инструмента.

Как оказалось, часто новые версии пакетов не собираются по тривиальным причинам — например, в новой версии добавились новые файлы, появилась потребность в новых зависимостях сборки и так далее. Эти изменения приводят к ошибкам сборки, которые можно исправить небольшой модификацией spec-файла. Однако многие изменения довольно типичны и требуют внесения одних и тех же корректировок в spec-файл. Так почему бы не возложить задачу внесения таких корректировок на автоматизированный инструментарий?

Для реализации такой возможности мы разработали скрипты анализа ошибок, возникших при сборке пакета. Скрипты запускаются автоматически в случае, если сборка новой версии пакета с помощью Updates Builder’а завершилась неудачно. При обнаружении одной из ошибок, известных скриптам, они сами вносят в spec-файл изменения, которые должны позволить избавиться от этой ошибки, и отправляют пакет на пересборку. Этот процесс может иметь несколько итераций — ведь после исправления одной ошибки могут появляться другие. Таким образом, процесс работы Updates Builder’а в РОСЕ устроен следующим образом:

Список ошибок, которые скрипты в состоянии исправить на данный момент, таков:

• ставшие ненужными патчи
  • Reverse (or previously applied) patch detected
• Нехватка сборочных зависимостей Perl
  • Can’t locate <perl_module> in @INC
• Добавленные или удаленные файлы:
  • File not found / File not found by glob
  • Отсутствие файла, указанного в %doc
  • Installed (but unpackaged) file(s) found
• Ошибки rpmlint
  • debuginfo-without-sources и empty-debuginfo-package

Исправление этих ошибок носит эвристический характер и мы не можем гарантировать, что исправление корректно, даже если после его внесения пакет собрался успешно. Например, ошибки debuginfo-without-sources и empty-debuginfo-package сейчас решаются просто отключением сборки debug-пакета; но возможно, более правильным было бы пометить пакет как архитектурно-независимый (noarch) или добавить какие-то флаги сборки, в отсутствии которых не генерируется отладочная информация. Поэтому перед переносом предложенных Updates Buider’ом обновлений в основной репозиторий, мэйнтейнерам следует присмотреться — какие изменения были внесены в spec-файл и не стоит ли их скорректировать.

К слову об анализе предлагаемых Updates Builder’ом обновлений и их переносе в основные репозитории — этот процесс недавно стал гораздо более удобным и наглядным. До сих пор Updates Builder только оповещал о результатах сборки по e-mail, после чего мэйнтейнерам необходимо было самим смотреть, какие изменения были внесены в ветке auto_update Git-репозитория и сливать эти изменения в основную ветку. Теперь в случае успешной сборки на ABF формируется Pull Request на внесение изменений в целевую ветку, так что мэйнтейнеры могут визуально изучить все модификации и принять их нажатием одной кнопки.

Pull Request от Updates Builder’а для python-m2crypto — можно обновиться до версии 0.21.1

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

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

« новейшие ‹ 20 более новых … 20 более старых › старейшие »