Как сообщить об ошибке, когда ubuntu-bug не работает с ошибкой?

Как упомянуто в отчете об ошибках в комментариях это, кажется, проблема "локали".

LC_ALL=C ubuntu-bug python

работы отлично.

Когда Apport - который ubuntu-bug часть - не работает, часто лучше попытаться решить проблему с Apport. Однако возможно сообщить об ошибках без Apport.

Я не знаю, происходит ли определенная ошибка, описанная здесь, из-за ошибки или неверной конфигурации или некоторой другой проблемы. Пользователи, которые видят, что точное сообщение должно попробовать обходное решение описанный Rinzwind. Несколько в более общем плане, хотя не применимый к сообщению об ошибке, показанному здесь, apport-cli команда будет иногда работать когда ubuntu-bug не делает.

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

Сообщение об ошибках без Apport (когда Вы должны),

Существует два особо важных дела.

1. Если Вы сообщаете об ошибке некатастрофического отказа путем выполнения ubuntu-bug package, затем Apport не присоединил бы отслеживание стека и дамп ядра к отчету об ошибках так или иначе. Таким образом, разумно сообщить об ошибке непосредственно на Панели запуска. Как ответ its_me на то, Как я сообщаю об ошибке? говорит:

   Это столь же легко как посещающий Панель запуска и заполняющий 2 или 3 поля, которые являются там. Командная строка не является единственным путем.

   С другой стороны, можно использовать это (замена PACKAGENAME в URL с именем пакета. Например: единица, оболочка гнома, и т.д.):

   http://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug?no-redirect
   

   Это упоминается в документации Ubuntu.

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

2. Сообщение об ошибке, которая вызывает катастрофический отказ без Apport, является более трудоемким, но это может быть сделано традиционным способом. Это состоит из установки отладочных символов для программы, которая отказала и библиотеки, которыми она пользуется, открывая программу в отладчике (для пакетов Ubuntu, gdb должен обычно использоваться), затем пытаясь воспроизвести катастрофический отказ. Получающееся отслеживание стека, произведенное путем выполнения bt в gdb после катастрофического отказа, должно быть применимым, пока все соответствующие отладочные символы были доступны.

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

   Пользователи, рассматривающие выполнение этого, должны определенно считать DebuggingProgramCrash, а также ReportingBugs.

После того как Apport работает снова...

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

Если Вы следуете этому методу и затем решаете добавить файлы таким же образом, как Вы были бы ubuntu-bug метод, можно просто ввести apport-collect REPORTNUMBER, где REPORTNUMBER является количеством ошибки, которая будет в URL Вашего отправленного [ошибка].

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