LANG=C man gpasswd[ДОБЕЙТЕ]
Не удаётся увидеть англоязычную странице справки по команде gpasswd(ни из-под юзера ни из-под root'a).
При вводе LANG=C man gpasswd получаю пустую страницу и подпись:
lines ?-?/? (END)
Сама страница в /usr/share/man/man1/gpasswd.1.bz2 присутствует. И если сделать вручную:bzcat ...gpasswd.1.bz2 | nroff -Tascii -mandoc -c | less -isr всё отлично отображается.
Несколько переменных среды :
NROFF=/usr/bin/enconv -L ru -x KOI8-R | /usr/bin/nroff -Tlatin1 -c -mandoc MANPAGER=iconv -c -f koi8-r -t utf-8 | /usr/bin/less -isr PAGER=/usr/bin/less MANPATH=/usr/local/share/man:/usr/share/man:/usr/share/man/ru:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.18/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Сколько тут на форуме гентушников ? Попробуйте (на x86) установить пакет enca-1.9-r1(он в ~x86) и запустить команду :
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -L ru -x UTF-8 -VVVVVVVVVVV
Отпишите результат и моя душа обретёт покой :).
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- Для комментирования войдите или зарегистрируйтесь
Пошли по второму кругу! =)))
Вот, а у меня всё работает! ;-)
Надо было всё-таки сделать так...
:) А в MANPAGER у вас что ?
:) А в MANPAGER у вас что ?
И версии man и man-pages, а также man-pages-ru было бы великолепно увидеть.
У меня глобально русский настроен...
Поэтому, если есть, по дефолту показываются русские маны. Но это легко обойти ключом -M path, а ключом -W можно увидеть, откуда man берёт man (какой каламбурчик получилсо):
На данный момент на двух разных ноутах (amd64 stable) установлены: sys-apps/man-1.6f-r2, sys-apps/groff-1.19.2-r1, sys-apps/help2man-1.36.4, app-i18n/man-pages-ru-0.98, sys-apps/man-pages-3.15, sys-apps/man-pages-posix-2003a, app-i18n/enca-1.9. В /etc/make.conf LINGUAS="ru en", руками доставлялась только enca. Переменная окружения MANPAGER у меня не установлена (но есть MANPATH). Всё остальное уже показывал раньше, ничего не менял с тех пор...
Только не пиши больше "решето", а то так и будет "насквозь" полезная инфа проскакивать! =)))
Так, во-первых, спс за инфу и
Так, во-первых, спс за инфу и за ключики к man -М и -W очень удобные. С версиями всё ок.
А также всё чудесно и с путями к манам. По default смотрит в /usr/share/man/ru, а с LANG=C
смотрит в /usr/share/man.
Путём проб и ошибок обнаружил следующее:
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -L ru -x KOI8-Rдаёт нулевой результат. А именно эта часть конвейера исп. у меня в процессе формирования man страниц.
Так что ошибка точно тут.
Покажите мне, пожалуйста, вывод :
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | encaиbzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -L ru -x KOI8-Rиegrep "^.bz2" /etc/man.confи спс ;).PS sys-apps/shadow у вас какой-версии ?
:(
По всем строчкам, кроме последней, какая-то фигня получается!
Последняя говорит: .bz2 /bin/bzip2 -c -d
> с LANG=C смотрит в /usr/share/man
У меня LANG=C на поведение man не влияет.
Вообще-то я имел ввиду ТАКИЕ УСТАНОВКИ.
Там важно дать имя, начинающееся с трёх нулей, чтобы было до 00basic.
Важно всё, что в нём, хотя PAGER можно и в другом файле подправить.
Важно, что не используется iconv, но используется enca.
Я менял только NROFF в /etc/man.conf!
Кстати, у меня везде UTF-8...
P.S.: =sys-apps/shadow-4.0.18.2 (USE: cracklib nls pam)
P.P.S: Вот так попробуй! ;-)
И по первой тоже фигня ??? Не
И по первой тоже фигня ??? Не может быть :(. Фигня по второй строчке свидетельствует что перекодирование происходит.
>Вообще-то я имел ввиду ТАКИЕ УСТАНОВКИ.
Я про это понял. Погоды не делают к сожалению.
iconv не используется, пользуюсь enconv.
Собственно в чём странность и где всё застревает:
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | encaГоворит нам про кодировку символов. У меня она оказывается (La)TeX control sequences. Её то и не хочет enconv перекодировывать в KOI8-R.
Примечательно, что все остальные файлы gpasswd на других языках хранятся в отличной от "(La)TeX control sequences" кодировке, а именно в UTF-8 и конечно отображаются нормально.
Ну и что? Оно жить-то не мешает! ;-)
Т.е. вот эта строчка:
enconv: no convertor is able/allowed to perform conversion TeX..KOI8-R on file `STDIN'
изначально идёт в STDERR, а не в STDOUT.. ;-)
Но в любом случае, на выходе всё равно идёт неизменный форматированный текст.
Так что причина никак не в этом, я думаю...
Вот оно, спасибо. Значит
Вот оно, спасибо. Значит пишет что никакой конв не может/ему не разрешили конвертить TeX и пропускает текст дальше по пайпу, он идёт в nroff и всё окей. Но у меня он так не поступает. Нет сообщения об ошибке и не хочет дальше текст пропускать.
Возникли ещё идеи...
1. А вот так работает?
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 > /tmp/bzxxx; sleep 10; enconv -L ru -x KOI8-R 2>/dev/null < /tmp/bzxxx2. Может пересобрать bzip2 (-static)?
emerge -va1 =app-arch/bzip2-1.0.5-r1К слову, bzip2 независим от чего-либо!... ;-)
3. Какая версия glibc? Случайно не 2.9*? Это может быть глюк с реализацией пайпов...
Нет, так тоже не хочет.
Нет, так тоже не хочет. Пересобрал @system @world - не помогло. Ошибка возникает в проге enca. Вот кусок кода из файла convert.c:
int convert(File *file, EncaEncoding from_enc) { Convertor *conv; int extern_failed = 0; int err; if (options.verbosity_level) { fprintf(stderr, "%s: converting `%s': %s\n", program_name, ffname_r(file->name), format_request_string(from_enc, options.target_enc, 0)); } /* do nothing when requested encoding is current encoding (`nothing' may include copying stdin to stdout) */ if (from_enc.charset == options.target_enc.charset && from_enc.surface == options.target_enc.surface) { if (file->name != NULL) return ERR_OK; else return copy_and_convert(file, file, NULL); } /* try sequentially all allowed convertors until we find some that can perform the conversion or exahust the list */ conv = convertors; while (conv != NULL) { if (options.verbosity_level > 1) { fprintf(stderr, " trying to convert `%s' using %s\n", ffname_r(file->name), conv->conv->name); } err = ((ConvertorData *)conv->conv->data)->convfunc(file, from_enc); if (err == ERR_OK) return ERR_OK; if ((((ConvertorData *)conv->conv->data)->flags & CONV_EXTERN) != 0) { fprintf(stderr, "%s: external convertor failed on `%s', " "probably destroying it\n", program_name, ffname_w(file->name)); extern_failed = 1; } /* don't tempt fate in case of i/o or other serious problems */ if (err != ERR_CANNOT) return ERR_IOFAIL; conv = conv->next; } /* no convertor able/allowed to perform given conversion, that's bad */ fprintf(stderr, "%s: no convertor is able/allowed to perform " "conversion %s on file `%s'\n", program_name, format_request_string(from_enc, options.target_enc, 0), ffname_r(file->name)); /* nevertheless stdin should be copied to stdout anyway it cannot make more mess */ if (file->name == NULL) copy_and_convert(file, file, NULL); return ERR_CANNOT; }Осталось разобраться с gdb и выснить код возвращаемый функцией convert. В примере с файлом gpasswd(который в LateX) должен выполнится код начиная с fprintf(stderr, "%s: no convertor is able/allowed, там дальше будет stdin в stdout отправляться, как раз то что надо, но у меня почему-то так не происходит.
Версия glibc-2.6.1
STOP! Ты не прав! =)))
Вот эта строка выше:
return copy_and_convert(file, file, NULL);говорит о том, что ф-я copy_and_convert() ВОЗВРАЩАЕТСЯ. А поскольку мы видим сообщение "%s: no convertor is able/allowed...", то ф-я convert() в любом случае у тебя (и у меня тоже!) вернёт ERR_CANNOT, т.е. эта потуга ни даст ничего ровным счётом! ;-) Я бы сделал так. Во-первых, пересобрал бы enca. Если не поможет, сделай ebulid unpack, и подправь в коде ф-ии convert() эти строчки:
/* nevertheless stdin should be copied to stdout anyway it cannot make more mess */ fprintf(stderr, "IS PIPE? %s\n", (file->name == NULL) ? "YES": "NO"); if (file->name == NULL) copy_and_convert(file, file, NULL); fprintf(stderr, "Converted...\n"); return ERR_CANNOT;после чего ebuild compile && ebuild install. Теперь нужно запустить enca и понять, что попало в STDERR. Наконец, можно установить strace и прогнать им, кажется это проще, чем разбираться с dbg... :)
У меня нехорошее предчувствие, что кто-то портит file->name ("IS PIPE? NO") и оно != NULL (выше разумеется). Как вариант ("IS PIPE? YES"), придётся лезть в copy_and_convert() и уже смотреть, чего с ней не так...
>Вот эта строка выше: >return
>Вот эта строка выше: return copy_and_convert(file, file, NULL); говорит о том, что ф-я copy_and_convert() ВОЗВРАЩАЕТСЯ
Возвращается в случае если до туда дойдёт то выполнение.
>>А поскольку мы видим сообщение "%s: no convertor is able/allowed..."", то ф-я convert() в любом случае у тебя (и у меня тоже!) вернёт ERR_CANNOT
Я то его как раз и не вижу. Срабатывает какой-то из пред return.
Enca пересобирал уже сто раз. В том что проверка
if (file->name == NULL)сделана в целях определения работаем мы с stdin или файлом(соответственно следует писать в файл или дальше в stdout) у меня сомнений не вызывает.PS А как у вас сработает это :
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -VVVVVVVVVVV -L ru -x KOI8-RНе обращайте внимания на такое количество V. Не разобрался я как у них с verbosity level, а может там и не разобраться вовсе:
Извиняюсь, сам не прав был! =)))
Упустил вот это высказывание: ... и пропускает текст дальше по пайпу, он идёт в nroff и всё окей. Но у меня он так не поступает. Нет сообщения об ошибке и не хочет дальше текст пропускать. :-( Раз так, то конечно, оно у тебя до тудова и не доходит!!! Кстати, выше, под словом "ВОЗВРАЩАЕТСЯ" имел ввиду, что ф-я copy_and_convert() может возвращать управление в вызывающий код convert().
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -VVVVVVVVVVV -L ru -x KOI8-R Opening file `/usr/share/locale/locale.alias' in mode r stat()-ing `/usr/share/locale/locale.alias' (fd 3) for its size File `/usr/share/locale/locale.alias' size is 2586 Closing file `/usr/share/locale/locale.alias' Explicitely specified target charset: KOI8-R Adding convertor `built-in' Adding convertor `iconv' Initializing language ru Fake-opening stdin/stdout in mode r+b enconv: converting `STDIN': TeX..KOI8-R trying to convert `STDIN' using built-in trying to convert `STDIN' using iconv enconv: no convertor is able/allowed to perform conversion TeX..KOI8-R on file `STDIN' copying `STDIN' to `STDOUT' ... форматированный вывод поскипан ...Эх, жаль, что этот баг не у меня... =)))
P.S.: Поищи на предмет вот этого в сорцах:
trying to convert `STDIN' using iconvВ особенности, чего там с iconv...
P.S.S.:
/usr/share/locale/locale.alias относится к sys-libs/glibc ;-)
У меня он 2586 байт, md5sum: 6fc3625723b82f5898c73ff612b583fb
+
:) С русским маном всё хорошо, английский не хочет.
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -L ru -x KOI8-R- ничего не выводит, пусто. Как будто enconv не знает Latex, хотя в мане про него написано.Вот она ошибка!
enconv -L ru -x KOI8-R - ничего не выводит, пусто
В ядре выставлялась поддерка KOI8-R?
locale -a -- показывает поддержку KOI8-R?
locale-gen выполнялся в процессе установки?
>В ядре выставлялась поддерка
>В ядре выставлялась поддерка KOI8-R?
Да
>locale -a -- показывает поддержку KOI8-R?
>locale-gen выполнялся в процессе установки?
Однозначно да.
Напасть какая-то :(
Бывает! :(
Попробуй ещё:
либо через revep-rebuild (хотя конечно не панацея от всех бед), вдруг поможет...
Вообще-то только три пакета в цепочке задействовано:
Поскольку исходный файл имеется (кодировку определяет),
что-то не так именно с app-i18n/enca - её и нужно лечить...
Да, так и есть, уже в
Да, так и есть, уже в исходниках блуждаю. Нашёл функцию, которая отвечает за перекодировку,а в случае провала выводит сообщение об ошибке и копирует stdin в stdout. Это в файле convert.c строка 104. Функция convert. Осталось выяснить почему она так не делает у меня :).
Ну очень хочется увидеть
Ну очень хочется увидеть
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | encaМожет на paste.org запостите, если там много и вам не сложно, хотя там лишь имя кодировки д.б.
Так пойдёт?
bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -L ru -x KOI8-R 2>/dev/null
а "... | enca" показал постом выше...
bzip2 -c -d
У меня он выбирает librecode...
Фууууух, вообщем вроде
Фууууух, вообщем вроде победил. После долгих блужданий в коде выяснил как это всё работает. Сначала enca строит список конвертеров, потом спрашивает по очереди их могут ли они переконвертить текст, предварительно определив конечно его кодировку.
Значит когда у меня доходит очередь до librecode - он чего-то отвечает что не против переконвертить latex(и не конвертит).
enca --list convertors(так же интересно, что у вас будет)У меня даёт такой результат :
такая строка в /etc/man.conf всё спасает, но это лишь так сказать 'костыль':
NROFF enconv -L ru -x UTF-8 -C built-in,iconv,extern | ...-С говорит ему список конвертеров для использования, т.е. мы минуем librecode.
Нашёл по librecode. Относится к пакету recode, про него сказано что он очень бажный и много чего не хорошего.
Вообщем пакет enca тянет за
Вообщем пакет enca тянет за собой recode. 1. Есть ли он у вас в системе ? 2. Каков порядок конвертеров у вас (enca --list converters) ? 3. Какая версия recode ?
Разумеется его нет!
А нафик он нужен? :)
Я ещё года два назад, как разбирался, понял, что только iconv.
Поэтому в /etc/make.conf: USE="iconv -recode" и emerge @world ;-)
Но уже не помню, почему не стал ставить тогда recode. Давно дело было...
Про него написано, что он
Про него написано, что он powerful tool для ковертирования. Странно - убрал -recode из USE, а он всё равно тянется. Enca тянет
Разобрался! ;-)
equery g --depth=1 app-i18/enca ;-)
снесите/замаскируйте 1.9-r1 и поставьте =app-i18/enca-1.9 -- только последняя версия тянет за собой recode!
Для полного счастья не
Для полного счастья не хватает чтобы enca-1.9-r1 кто-нибудь протестил на x86 на ту же ошибку и если она подтвердится надо изменить wiki.
Люди, не юзайте тестовый софт!!! ;-)
А чего её тестить и причём тут x86? Судя по ветке, разобрались досконально!
К тому же версия и без того ~ТЕСТОВАЯ =))) Кстати, солюшн у нас был уже... несколько раз!
>Кстати, солюшн у нас был
>Кстати, солюшн у нас был уже... несколько раз!
Когда :)? Я удивился почему сразу не исправил в начале ветки, когда пробовал 1.9 версию. Оказалось что и в ней исходный код очень сходный и так же используется librecode. Отличия которые я нашёл в ebuild'ах это отстутствие зависимости к recode у 1.9. Но так как сначала поставил 1.9-r1 и recode с ним, то в момент теста 1.9 он по прежнему юзал librecode. Если бы я сделал после установки 1.9 emerge --depclean, то может меньше времени бы затратили.
>А чего её тестить и причём тут x86?
В wiki написано, что надо ставить ~x86 версию, вот и хочу знать как у x86 с этой проблемой, чтобы поправить wiki и предупредить эту ошибку для пользователей x86.
[ДОБИЛ]: Иначе и быть не могло! =)))
pavilion ~ # uname -a Linux pavilion 2.6.26-hardened-r9 #4 SMP PREEMPT Thu Jan 29 02:55:04 MSK 2009 x86_64 Intel(R) Pentium(R) 4 CPU 3.40GHz GenuineIntel GNU/Linux pavilion ~ # emerge -va1 enca These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-text/recode-3.6-r2 USE="nls" 1,711 kB [ebuild U ] app-i18n/enca-1.9-r1 [1.9] USE="-doc%" 492 kB Total: 2 packages (1 upgrade, 1 new), Size of downloads: 2,203 kB Would you like to merge these packages? [Yes/No] y ... компиляция/инсталляция поскипана ... pavilion ~ # enca --list convertors built-in librecode iconv extern pavilion ~ # bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -L ru -x UTF-8 -VVVVVVVVVVV Opening file `/usr/share/locale/locale.alias' in mode r stat()-ing `/usr/share/locale/locale.alias' (fd 3) for its size File `/usr/share/locale/locale.alias' size is 2586 Closing file `/usr/share/locale/locale.alias' Explicitely specified target charset: UTF-8 Adding convertor `built-in' Adding convertor `librecode' Initializing language ru Fake-opening stdin/stdout in mode r+b enconv: converting `STDIN': TeX..UTF-8 trying to convert `STDIN' using built-in trying to convert `STDIN' using librecode pavilion ~ # emerge -va1 enca These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-i18n/enca-1.9 [1.9-r1] USE="(-doc%)" 0 kB Total: 1 package (1 downgrade), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] y ... процес даунгрейда версии поскипан ... pavilion ~ # enca --list convertors built-in librecode iconv extern pavilion ~ # bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -L ru -x UTF-8 -VVVVVVVVVVV Opening file `/usr/share/locale/locale.alias' in mode r stat()-ing `/usr/share/locale/locale.alias' (fd 3) for its size File `/usr/share/locale/locale.alias' size is 2586 Closing file `/usr/share/locale/locale.alias' Explicitely specified target charset: UTF-8 Adding convertor `built-in' Adding convertor `librecode' Initializing language ru Fake-opening stdin/stdout in mode r+b enconv: converting `STDIN': TeX..UTF-8 trying to convert `STDIN' using built-in trying to convert `STDIN' using librecode pavilion ~ # emerge -Ca recode >>> These are the packages that would be unmerged: app-text/recode selected: 3.6-r2 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. Would you like to unmerge these packages? [Yes/No] y ... процесс очистки диска от этого убожества поскипан ... # АААААА! ЭТО сломалось! :-( pavilion ~ # enca --list convertors enca: error while loading shared libraries: librecode.so.0: cannot open shared object file: No such file or directory pavilion ~ # bzip2 -c -d /usr/share/man/man1/gpasswd.1.bz2 | enconv -L ru -x UTF-8 -VVVVVVVVVVV enconv: error while loading shared libraries: librecode.so.0: cannot open shared object file: No such file or directory pavilion ~ # emerge -va1 enca These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-i18n/enca-1.9 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] y ... пересвязывание DLL-ей поскипано ))) ... # После чего всё успешно заработало!!! # Любопытное различие! ;-) pavilion ~ # nano -w /usr/portage/app-i18n/enca/enca-1.9.ebuild pavilion ~ # nano -w /usr/portage/app-i18n/enca/enca-1.9-r1.ebuildКому пришла такая мысль сделать такой ебилд и зачем librecode в [R]DEPEND ? :o
НЕ ДОБИЛ! у вас же x86-64
Безумно сильно похоже на мини брифинг нашего приключения с enca. Насчёт записи в [R]DEPEND не скажу. А вот когда вы даунгрейдили с 1.9-r1 до 1.9 и удалили recode можно объяснить одной строчкой всё из того же convert.c
static const Abbreviation CONVERTORS[] = { { "built-in", &cdata_builtin }, #ifdef HAVE_LIBRECODE { "librecode", &cdata_librecode }, #endif /* HAVE_LIBRECODE */enca-1.9 скомпилилась с поддержкой librecode, потом вы грохнули recode, отсюда и ошибка.
Таки-добил ;-)
Во-первых, я устойчиво не понимаю здесь разницы между x86 и amd64!
А как насчёт остальных архитектур? :)
Настаиваю, что проблема не в ~arch.
И как выяснилось, даже не в версиях enca!!!
Всё дело в кривых ебилдах - да, они оба кривые! =)))
#ifdef HAVE_LIBRECODE...#ifdefОбратите внимание, что во время сборки enca-1.9
configure-скрипт находит librecode.so в ЖИВОЙ СИСТЕМЕ!
Потенциальный баг для revdep-rebuild и чекера ебилдов.
enca-1.9-r1.ebuild не страдает от потери консистентности
системы, но тупо тянет за собой эту бажную кривизну 'recode'.
Именно это всё я и попытался показать в листинге выше.
Теперь, разобравшись, "мы просто обязаны" внести исправление в portage! =)))
Потести пожалуйсто, если не сложно!
app-i18n/enca-1.9-r2 [1 months ago]...
=)
>>Во-первых, я устойчиво не понимаю здесь разницы между x86 и amd64!
Пакет app-text/recode при сборке под x86 вдруг работает верно, тогда нечего и править. Насчёт остальных архитектур: будет довольно сложно проверить работу пакета recode, может для них он верно работает. Конечно главная проблема не в ~arch, а опять же в пакете recode, ~arch ebuild лишь инициирует эту проблему.
>Обратите внимание, что во время сборки enca-1.9
configure-скрипт находит librecode.so в ЖИВОЙ СИСТЕМЕ!
А где ему ещё искать ? оО. Пакет стоит - компилит с его поддержкой. А то что он(пакет) висит в системе без зависимостей - это вы не доглядели, это не проблема make'а.
>>Теперь, разобравшись, "мы просто обязаны" внести исправление в portage! =)))
Эта фраза меня вообще напугала, не готов я вносить изменения в portage.
Я думаю разрабы сами решат вопрос, не зря ebuild помечен как ~, можно помочь им в этом и сообщить, так сказать дать прямую наводку.
Хорошая мысль добавить recode через use, вполне логическая.
Так работет 1.9-r2 или нет?
> Пакет app-text/recode при сборке под x86 вдруг работает верно, тогда нечего и править...
Как показала наша с вами переписка, работает он сейчас в этом вопросе одинаково неверно! ;-)
> > Обратите внимание, что во время сборки enca-1.9
> > configure-скрипт находит librecode.so в ЖИВОЙ СИСТЕМЕ!
> А где ему ещё искать ?
Прошу прощения, лоханулся. Я именно так сначала и подумал, хотя это абсолютно невероятно.
По ходу отладки ебилда и разборок с configure разобралсо, в чём там собака порылась... :)
Ключ --with[out]-librecode решает этот вопрос, по умолчанию либа-таки тянется.
Так что насчёт "живой системы" забираю свои слова взад!!! =)))
> > Теперь, разобравшись, "мы просто обязаны" внести исправление в portage! =)))
> Эта фраза меня вообще напугала, не готов я вносить изменения в portage.
А вам и не надо, я это уже ПОЧТИ сделал! ;-)
Просто прежде, чем багзилить, думал вы тоже потестите ебилд...
> Хорошая мысль добавить recode через use, вполне логическая.
Я этот ебилд сразу протестировал на amd64 прежде чем выкладывать.
Кстати, по той же в точности схеме, что листинг, демонстрирующий баг (выше).
Избавиться от самой неприятной проблемы удалось только со второго раза.
Теперь, даже если в системе уже стоит app-text/recode, enca сдедует логике use-флага.
Если включен - будет использовать (и подтягивать при сборке), если нет, то не будет.
Сделан он на базе 1.9-r1 и отличий почти нет. Так что должен работать... ;-)
Кстати, моё мнение, что с точки зрения сборщика дистра кривая - только ecnca-1.9.
Насчёт enca-1.9-r1 тоже беру свои слова взад! И кто там говорил про ~stable? =)))
Отмечу, что никакой баг мы не исправили.
Он как был (как вы верно заметили - в recode), так там и сидит.
Но у нас ведь была несколько иная задача и мы её вроде бы решили...
Так я не понял, вы протестировали этот ебилд на x86? Работает?..
Не знаю
>>Теперь, даже если в системе уже стоит app-text/recode, enca сдедует логике use-флага.
>>Если включен - будет использовать (и подтягивать при сборке), если нет, то не будет.
Наверно проблема решена на 5+. Congratulations.
>>Так я не понял, вы протестировали этот ебилд на x86?
Нет, вот я прошу добейте, затестите у кого x86, у меня 64.
Наша переписка показала это для 64.
Сори!
А я по нескольким вашим высказываниям ошибочно подумал, что речь об x86 (~x86)...
Ну тогда попробую забагзиллить, пущай народ тестит...
С первым багрепортом меня! =)))
БАГ - в багзилле вместе с ебилдом. Bug ID: #257256 ;-)
Пущай community теперь тестит (и не только на [~]x86)...
P.S.: Я так понимаю, до оффдерева это дойдёт не скоро (если вообще дойдёт)...
Congratulations
Посмотрел баг, спасибо за помощь. Можно было написать и короче конечно :), там для emerge --info в самом начале есть поле. Это фигня. Вот о чём подумал.
Если у нас в системе стоит пакет recode по какой-то другой ветке, зависимости. Я думаю тут надо подходить с другой стороны. Добавлять use-флаг к enca,но так чтобы флаг воздействовал на исходный код enca. Как должно быть вижу прозрачно, но как сделать методами ebuild'ов не знаю. Надеюсь в скором времени сяду (дома за комп =)) и разберусь.
Дык ведь именно это я и сделал! ;-)
В предложенном ебилде энки 1.9-r2. Т.е. там теперь даже если стоит GNU recode в системе, при сборке пакета с USE="-recode", эта либа не используется. Я всё проверил, но только на amd64...
Нашёл решение!
У меня похожая проблема (локаль UTF-8):
-C не помогло, ни в каких комбинациях.
Да и вообще enca не даёт 100% результат по определению. Так что я решил иначе: зачем конвертировать все файлы подряд? Достаточно только русские маны.
Написал вот такой скрипт (/usr/local/bin/enroff):
#!/bin/sh data=$(mktemp --tmpdir enroff-XXXXXXXXXX) cat /dev/stdin > $data name=$(enca -i $data) if [[ $name == "KOI8-R" || $name == "UTF-8" ]]; then conv="-D$name" fi groff -mandoc -Tutf8 $conv $data rm $dataЗатем прописал в /etc/man.conf:
Ясное дело, что можно менять на вкус и цвет, добавить новые кодировки или не конвертировать только для заданных кодировок (как то (La)TeX control sequences), но идея, надеюсь, ясна.
Теперь у меня всё равботает ок 8-).
Per aspera ad astra!
Цитата:У меня похожая
То что man.1 закодирован в Latex это не проблема. Какие могут быть комбинации ? В теме разжёвано до предела, до кода enca, вариантов нет. Или у вас другая проблема или вы придумали костыль.
>>Да и вообще enca не даёт 100% результат по определению.
Так они развиваются в этом направлении.
Как уже писалось вся проблема была в работе с либой librecode, в доке к enca сказано, что enca не на 100% работает с ней и всё что от вас требуется это отказаться от её использования.
PS: лучше напишите, что у вас enca --list convertors показывает