Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Content (9 страница со старыми записями)

Новая вики-статья: EKG2

Это архивная статья

image0 В вики проекта появилась новая статья, подробно описывающая работу с консольным многопротокольным IM-клиентом EKG2.

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

Истекли патенты на JBIG1

Представители Fedora-Legal сообщили заинтересованным лицам, что последний из известных патентов на JBIG1 истекает 4го апреля 2012 года. В связи с этим начат процесс импортирования из RPMFusion необходимых библиотек для работы с этим стандартом сжатия, активно используемых в факс-аппаратах и сопутствующем программном обеспечении.

О пользе свободного времени для локализации

Это архивная статья

Сегодня вечером Кевин Раймонд (Kévin Raymond) сообщил в рассылке для переводчиков об обновлении содержимого сайта fedoracommunity.org, на котором собраны сайты всех региональных сообществ Fedora. Никаких кардинальных изменений, но тем не менее модули для перевода пополнились новыми строками. Поскольку материал для перевода очень простой и к тому же у меня выдался спокойный вечер, я быстренько перевела новые строки.

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

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

Так что присоединяйтесь! (Если что, команда локализации тусуется здесь, а о том, как к ней присоединиться, написано здесь).

29 марта: Тестовый день Gnome Shell Software Rendering

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

Тестирование очень простое: достаточно загрузить Live-образ и проверить, что запустился Gnome Shell.

К тестированию приглашаются:

  • старое x86-железо, в частности, процессоры не поддерживающие SSE2 (AMD Geode и pre-Athlon-64, Intel pre-Pentium-4 и т.п.),
  • ARM, PowerPC, и прочие не x86-архитектуры,
  • виртуальные машины, отличные от KVM,
  • старые видеокарты: Intel 8xx, Radeon pre-R300, NVIDIA pre-GeForce-6,

ну и, разумеется, все остальные участники, желающие посмотреть на Gnome практически 3.4 в действии.

Инструкция по участию: Test Day: 2012-03-29 Gnome Shell Software Rendering

Не забывайте отписываться о результатах на вики-странице!

Роспуск управляющего комитета Glibc

Это архивная статья

Сегодня было объявлено о самороспуске управляющего комитета Glibc.

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

Поддержка NVIDIA Kepler в Nouveau

Это архивная статья

Phoronix `сообщает <>`__, что начальная поддержка новейшей видеоархитектуры от NVIDIA - Kepler, была добавлена в Nouveau инженерами Red Hat и участниками проекта Fedora David Airlie и Ben Skeggs (который также активно участвует в проекте Debian) спустя считанные часы после официального анонса компанией-производителем. Пока, конечно, там ничего особо нет, но как минимум, карта теперь не будет работать под управлением совершенно примитивного vesa-драйвера. И это - без какой-либо техдокументации от NVIDIA. Сравните с ATI/AMD картами, которые, несмотря на имеющуюся документацию и официальную поддержку от производителя, получают ту же базовую функциональность спустя недели после официального анонса. Еще для сравнения с ATI - Intel стараются реализовывать поддержку оборудования в драйверах до его официального анонсирования.

Docutils System Messages

System Message: ERROR/3 (<string>, line 21); backlink

Anonymous hyperlink mismatch: 1 references but 0 targets. See "backrefs" attribute for IDs.

Проблемы с UEFI на Macbook Air.

Это архивная статья

Активный участник проекта Fedora и работник Red Hat, Matthew Garrett, продолжает продолжать серию статей про проблемы с UEFI. В этот раз он натолкнулся на удивительную проблему - UEFI позволяет прошивке wi-fi карты изменять память ядра напрямую, без участия процессора (DMA). Прочитайте статью целиком, это очень увлекательное чтение о том, как сложно было поймать за руку firmware за таким хулиганством. Кстати, предлагаем пофантазировать, какие возможности открываются с такой функциональностью UEFI.

Darkserver и работа над ошибками в Fedora

Это архивная статья

Участником Fedora и работником Red Hat Kushal Das было официально объявлено о введении в строй Darkserver, специального сервиса, для онлайн-хранения полной информации о сборке приложения. На этом сервисе по так называемому build-id будут доступны ссылки на логи сборки, debug-информацию и собранные RPM-пакеты в Koji.

Наверное все знают или догадываются, что в Open Source одной из важнейших ситуаций в общении между разработчиками и пользователями, является исправление ошибок. В идеальном мире пользователь, столкнувшись с ошибкой, изучает ситуацию, при которой она возникла, запускает дебаггер, проводит пошаговую отладку, находит ошибку, тратит некоторое время на пересборки и подготовку патча с исправлением, регистрируется на feature/issue-трекере (если уже не зарегистрирован), подробно сообщает об ошибке и условиях, при которой она возникает, и прилагает исправление. Разработчики дружелюбно приветствуют его, успешно воспроизводят ошибку по описанию и с радостью принимают его исправление.

В этой-же реальности все намного сложнее, болезненнее и менее захватывающе.

Зачастую пользователь не умеет пользоваться отладчиком, так что разбираться с логами отладки и бэктрейсом падения приходится мэйнтейнеру. Для этого хорошо бы как-то получить сами логи, а, значит, у пользователя должен быть доступ к отладочной информации. Пользователь может просто не желать или даже не иметь возможности скачивать и ставить сотни мегабайт debuginfo пакетов ради нахождения причины ошибки, а готов предоставить лишь coredump-файл. Пользователь может пересобрать пакет сам, поставить его откуда-то еще, со сторонних репозиториев, а значит надо еще удостовериться, сможет-ли мэйнтейнер узнать, является ли приложение входящим в его зону ответственности или нет? Для решения этих и некоторых других задач, у Fedora было уже довольно много сделано. Были сделаны репозитории, хранящие дополнительную отладочную информацию (debuginfo пакеты), был сделан метод автоматического уведомления мэйнтейнеров об ошибках (программа abrt), была реализована "фича" по добавлению BuildID в приложения, чтоб автоматически сопоставлять coredump, версию пакета и debuginfo.

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

К сожалению, этого еще мало, хотя уже очень много по сравнению с куцыми возможностями работы над ошибками в проприетарных системах. Несмотря на то, что все кирпичики уже есть, полноценной распределенной системы анализа ошибок еще нет. Пользователь до сих пор нуждается в скачивании debuginfo пакетов - например, если он желает разбираться с ошибкой лично, а не отправлять логи падения на сервер (в которых, так как это моментальный снимок "внутренностей" программы, может содержаться его личная информация). Для преодоления этой сложности ранее были предложены некоторые решения, например специальная файловая система на базе FUSE - DebuginfoFS, но они так и не были доведены до конца. Кстати, это хорошая тема для студента-участника GSoC! Вообще, проблема принятия пользовательских отчетов об ошибках и реакции на них, это то, что отличает серьезное коммьюнити от кучки тинейджеров форкающих форк форка форка. Например, понятно, что для успешного исправления ошибки, хорошо бы чтоб разработчик смог ее воспроизвести.

Это значит, что у разработчика должна быть точно такая же среда, как и у пользователя. А как этого добиться, если у пользователя туча "USE-флагов", "система настроена под себя", "система оптимизирована пересборкой с -O99 под мою архитектуру" и т.п.? Можно, конечно, исправить проблему и в этом случае, но каков тогда будет КПД исправления? В дистрибутивах с повторяющимися результатами, с идентичными бинарными сборками, исправление сразу затронет всех пользователей продукта, а в системах "настроенных под себя" - может быть ограничено лишь некоторой группой пользователей. Опять-же, чем многочисленнее и/или технически грамотнее количество пользователей, тем более точно будет описана проблема, тем четче будут ответы на вопросы разработчика, что может значительно ускорить исправление. А как быть, если мэйнтейнер приложения в твоем дистрибутиве никогда им сам не пользовался, не знает, как оно устроено, и просто добился того, что оно как-то собралось? В некоторых дистрибутивах есть мэйнтейнеры, которые на добровольных началах управляют сотнями пакетов приложений (порой они еще и по своей наивности гордятся этим). А ведь в общем случае, это значит, что в целом ими производится некачественная работа над ошибками. Еще надо отметить, что некоторые, ставшие популярными среди начинающих, "простые" дистрибутивы в явном виде сообщают, что сообщения об ошибках надо посылать сразу в upstream, т.е. полностью отстраняются от участия в исправлении. Удивительно, но их фанбои порой громко кричат о "безглючности" их "простого" и "передового" дистрибутива "с самым свежим софтом". Конечно, если закрыть глаза на проблему, то она сразу-же исчезнет.

Сбор предложений вариантов названия для Fedora 18

Это архивная статья

Photo of Beefy Miracle Сообщество Fedora не стоит на месте и уже потихоньку начинает подготовку к Fedora 18. Традиционно первым шагом является выбор кодового названия релиза. О том, как это происходит, я уже писала в предверии Fedora 15 (см.

пост).

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

Кроме правил и воображения вас ничто не должно ограничивать! Интересно посмотреть, кто будет соревноваться с Beefy Miracle :) Ну а историю названий Fedora можно посмотреть здесь.

UPD. Названия можно будет добавлять до 27 марта включительно.

FESCo отменил переход на Journald

Это архивная статья

На прошедшем сегодня собрании FESCo начали принимать "фичи" для Fedora 18. Среди принятых:

И наконец, наверное наиболее важная новость, это то, что единогласно (8 голосов против, 0 за) было принято решение **отказаться от перехода** на Journald. В свете последних улучшений в системе журналирования событий, те нововведения, которые привносит этот компонент, уже не так актуальны. Отказ касается только включения этой "фичи" в Fedora 18, и возможно ее предложат в измененном виде, учтя критику, в Fedora 19 или позже.