(В ответ на комментарий №0)
> Если на sisyphus.ru предполагалось, что spec написан в кодировке koi8-r, то
> теперь предполагается, что он написан в кодировке UTF-8, а указанные кодировки
> в Summary(ru_RU.KOI8-R), %description -l ru_RU.KOI8-R  игнорируются.

Дело в том что ни sisyphus.ru ни prometheus.a.o ничего в плане спеков и их кодировок не делает. Просто на sisyphus.ru использовалась кодировка KOI8-R для страниц, а на prometheus я сконвертил всё в UTF-8.

Какие предложения по поводу не игнорирования кодировки? И на каких страницах?

(В ответ на комментарий №1)
> Какие предложения по поводу не игнорирования кодировки? И на каких страницах?

Есть предложение по обработке последовательности Summary(ln_LN.encoding).
Либо проходить 2 раза, в первый раз в поисках этой последовательности, либо изменять кодировку входных данных на лету после встречи такой последовательности.

(В ответ на комментарий №2)
> (В ответ на комментарий №1)
> > Какие предложения по поводу не игнорирования кодировки? И на каких страницах?
> 
> Есть предложение по обработке последовательности Summary(ln_LN.encoding).
> Либо проходить 2 раза, в первый раз в поисках этой последовательности, либо
> изменять кодировку входных данных на лету после встречи такой
> последовательности.

Повторюсь:

> Какие предложения по поводу не игнорирования кодировки? И на каких страницах?

Я пока не понимаю что, где и зачем.

Предложение не игнорировать кодировку на странице вывода spec-файла (см. URL для примера).

То есть отсеки с внутренней кодировкой spec-файлов преобразовать в кодировку UTF-8, чтобы далее при отображении этих спек-файлов не было нечитаемых символов.

Сложность в том, что в одном файле могут быть пункты с разной кодировкой:
CP1251, UTF8, KOI8-u.

(В ответ на комментарий №4)
> Предложение не игнорировать кодировку на странице вывода spec-файла (см. URL
> для примера).
> 
> То есть отсеки с внутренней кодировкой spec-файлов преобразовать в кодировку
> UTF-8, чтобы далее при отображении этих спек-файлов не было нечитаемых
> символов.
> 
> Сложность в том, что в одном файле могут быть пункты с разной кодировкой:
> CP1251, UTF8, KOI8-u.

Предлагаю не решать политические вопросы техническим путём. Пишите спеки в UTF-8 и проблем не будет.

NOTABUG -> WONTFIX

Жаль, а интересная задача по идее :)
Да и в policy нигде не видел, чтобы было требование писать в какой-либо одной кодировке...

(В ответ на комментарий №7)
> Жаль, а интересная задача по идее :)

Приходите лучше сразу с патчем. :)

Created attachment 4851 [details]
Вот конвертер кодировок на Java (jar-файл)

Я написал конвертер кодировок в utf-8.

Created attachment 4852 [details]
Исходный код конвертера (Java).

И исходник.

Прошу учесть код конвертора :).

Вот сложный случай:
http://prometheus.altlinux.org/en/Platform5/srpms/wget/spec
Для него некорректно работает.

Нужно найти способ получения кодировки для указанной локали...

Уточню один момент. После миграции на ruby 1.9.2 на прометее теперь не показываются спек-файлы которые содержат символы из не UTF-8 кодировки.

Мы показываем specfile расчитывая что всё в нём написано в UTF-8, а то, что не в UTF-8 отображается нечитаемым образом и это исправляться не будет:
https://beta.packages.altlinux.org/ru/sisyphus/srpms/wallpapers-mike/specfiles/