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

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

Приглашаем принять участие в завтрашнем тестировании работы 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

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

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

Участником 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, т.е. полностью отстраняются от участия в исправлении. Удивительно, но их фанбои порой громко кричат о "безглючности" их "простого" и "передового" дистрибутива "с самым свежим софтом". Конечно, если закрыть глаза на проблему, то она сразу-же исчезнет.