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