Вы здесь

Главная › Форум › Gentoo Linux › Общие вопросы

{РЕШЕНО} Не работает клавиша F3 в mc для просмотра файлов

21 декабря, 2008 - 21:07 — Nesmero

Не работает клавиша F3 в mc для просмотра файлов, а вместо этого это действие теперь на Shift+F3 В чем может быть проблема. Единственная моя догадка, что недавно полностью пересобрал мир. У меня нестандарстная клавиатура с мультимедийными клавишами(не работают и не пользуюсь), но раньше все работало.

Форум: 
Общие вопросы
22 декабря, 2008 - 00:27 — klark73

F3, F10, и снова F3 - теперь показывает?
А откуда дровишки (MC)? Чаем не из оверлея?

22 декабря, 2008 - 08:33 — MASSER

вчера переставлял систему с нуля, столкнулся с такой же проблемой, т.е. по кнопкам F3 и F4 не выводится просмотр и редактирование файла в MC, МС родной из портэйджа. По Shift+F3 просмотр запускается. Проблему пока не решил.

—

Regards, S.M.

22 декабря, 2008 - 09:44 — klark73

У меня всё в ажуре:

emerge -vp app-misc/mc
[ebuild R ] app-misc/mc-4.6.3-r105 USE="X gpm nls samba unicode" 0 kB [1]

Версию ебилда брал отсель: http://people.redhat-club.org/inf/mc-slavaz/gentoo/ ;)
Щаззз уж понял, почему лучше собирать без gpm, пожалуй пересоберу, а то раздражает.
Старый проект сдох, не обновляется. Есть куча форков. Это один из самых живых и актуальный.
Убраны старые баги, куча всяких полезных фич типа выбора русских кодировок в текстах и для FTP.

22 декабря, 2008 - 12:50 — Nesmero

klark73 написал:
F3, F10, и снова F3 - теперь показывает?
А откуда дровишки (MC)? Чаем не из оверлея?

Я не пользуюсь шибко верлеем. Какие дровишки?
Пересборка мс с вышеуказанными флагами не помогла. Такая комбинация тыканий тоже( Сборка 4.6.3 не помогла.

22 декабря, 2008 - 15:02 — klark73

Можно по /var/log/emerge.log-у глянуть, что именно вчера обновлялось.
Если дело тоже окажется в glibc, смотреть, что не так с версией.
А вообще странно. Обновлялись в один день, а поведение разное. :(
Даже никаких мыслей нет... Тока, если это обновление затронуло
сам MC, ядро или что-нть типа sys-apps/kbd.

А ветка какая? stable? x86? amd64?

22 декабря, 2008 - 15:28 — klark73

equery depgraph --depth=1 app-misc/mc-4.6.3-r105 ;)

sec-policy/selinux-* сразу исключаются, у меня их не было.
2fsprogs, архиваторы, gettext, pkgconfig X/gmp/samba-зависимые тоже.

Сразу под подозрения попадают glib, slang, ncurses - одно из трёх.
Но я сижу на stable x86, у меня всё в норме...

22 декабря, 2008 - 19:24 — Nesmero

Ветка х86. Разные вариации версий зависимостей не помогли. Дело только в glib. Буду его ломать по разному. Отпишусь позже.

22 декабря, 2008 - 15:40 — klark73

Судя по документации, у вас обновился slang или ncurses.
Судя по ебилду от 4.6.3-r105, mc собирается с slang-ом на уникодных системах (USE=unicode), иначе - с ncurses.
Так что откатывайте назад версию либы и сообщайте результаты! ;)

22 декабря, 2008 - 15:49 — klark73

[ebuild R ] sys-libs/slang-2.1.3-r1 USE="pcre png readline -cjk" 0 kB

это то, что у меня - так уж, до кучи :)

22 декабря, 2008 - 10:20 — neroot

Столкнулся с теми же симптомами.
После обновления glibc.
Пересборка мира не помогла. :(

—

Делай, что должен, и будь, что будет.

22 декабря, 2008 - 15:26 — neroot

Обновил мс до 4.6.3, обновил kbd до 1.15 - толку ноль.

—

Делай, что должен, и будь, что будет.

22 декабря, 2008 - 15:51 — klark73

[ebuild R ] sys-apps/kbd-1.13-r1 USE="nls" 0 kB

22 декабря, 2008 - 16:30 — neroot

Именно все так. :)
Сейчас обновляю slang, glib, ncurses.
---
Обновил
slang-2.1.4
glib-2.18.3
ncurses-5.6-r2
Толку ноль. Попутно словил баг ncurses-5.7 (https://bugs.gentoo.org/249363), поэтому остался на 5.6х

—

Делай, что должен, и будь, что будет.

23 декабря, 2008 - 01:39 — klark73

emerge -vp slang ncurses glib kbd mc
[ebuild R ] sys-libs/ncurses-5.6-r2 USE="gpm unicode -debug -doc -minimal -nocxx -profile -trace" 0 kB [0]
[ebuild R ] dev-libs/glib-2.16.5 USE="-debug -fam -hardened (-selinux) -xattr" 0 kB [0]
[ebuild R ] sys-apps/kbd-1.13-r1 USE="nls" 0 kB [0]
[ebuild R ] sys-libs/slang-2.1.3-r1 USE="pcre png readline -cjk" 0 kB [0]
[ebuild R ] app-misc/mc-4.6.3-r105 USE="nls samba unicode -X -gpm" 0 kB [1]

23 декабря, 2008 - 14:18 — neroot

[ebuild R ] sys-libs/ncurses-5.7 USE="gpm unicode -ada -debug -doc -minimal -nocxx -profile -trace" 0 kB
[ebuild R ] dev-libs/glib-2.18.3 USE="-debug -doc -fam -hardened (-selinux) -xattr" 0 kB
[ebuild R ] sys-apps/kbd-1.15 USE="nls" 0 kB
[ebuild R ] sys-libs/slang-2.1.4 USE="pcre png readline -cjk" 0 kB
[ebuild R ] app-misc/mc-4.6.3 USE="7zip background editor gpm network nls unicode vfs -X -attrs -dnotify -ext2undel -samba" 0 kB

Пока убрал галочки использовать внутренние просмотрщик и редактор и выставил переменные окружения.
Дангрейд glibc делать не буду - решил половить обновление.

—

Делай, что должен, и будь, что будет.

23 декабря, 2008 - 14:24 — klark73

Я просто показал версии и USE-флаги установленного у меня ПО.
У вас совсем иные версии, чего уж тут.
Но самое интересное - совсем другой MC (версия, USE-флаги)! ;)

23 декабря, 2008 - 14:39 — neroot

Были как у Вас. :)
Показал результат обновления и экспериментов с use.
В смысле, что не работает даже! с моим набором.
Жду патча на glibc. Млин.

—

Делай, что должен, и будь, что будет.

23 декабря, 2008 - 11:55 — Kevol

Похоже стоит провести эксперименты с флагами ncurses slang.
ncurses плохо живет с UTF-8. Там же частые причины с "расшифровыванием" функциональных клавиш.

22 декабря, 2008 - 20:44 — Nesmero

Не помогла никакая пересборка версий и glib и самого mc все откутывал и нифига((

22 декабря, 2008 - 22:01 — smal

Помогла установка системы с нуля :)) За одно убрались некоторые другие баги, накопившиеся за полтора года:)
Хотя сравнивая старую систему из stage4 и новую, которая получилась никаких особых отличий по версиям нет.
Использовал /etc/portage/* и make.conf из старой системы, как и многие другие конфигурационные файлы.

23 декабря, 2008 - 01:52 — klark73

Нашёл что в оверлейной 4.6.3 та же проблема бывает.

F3/F4 - это работа с обработанными данными.
F3 (Shift-F3) - просмотр raw, т.е. без обработки.
Shift-F4 - просто создать новый файл.

Осталось понять, кто/что отвечает за "обработку"...
Надо бы сорцы глянуть! ;)

23 декабря, 2008 - 07:57 — klark73

выше ошибся: не F3 (Shift-F3), а:
F13 (Shift-F3) - просмотр raw, т.е. без обработки.

За обработку отвечает переключатель F8 (raw/parse mode)
в режиме просмотра (т.е. F3, потом F8/F8/F8/.../F8),
а также содержимое /etc/mc/mc.ext

есть подозрение, что после апдейта не сделан dispatch-conf
(или etc-update - кому что больше нравится).

если же дело не в этом, нужен вывод mc -V
заодно сразу проверить (а может лучше даже вообще прибить)
содержимое ~/.mc (так, на всякий случай) =)))
и конечно же сделать env | grep TERM

есть ещё одна догадка...
что в системе отвечает за mmap()-отображение файла?
# sys-libs/glibc (/usr/include/sys/mman.h)
случаем не glibc? а ядро/модули fglrx/nvidia не пересобирались?
потому что отображение файлов в памяти через mmap()/malloc()
выполняется в зависимости от работы/доступности mmap()...

можно посмотреть, что пересобрано с USE=mmap (equery hasuse mmap)
и проверить функциональность этих прог -
если тоже глючат, тогда уже рыть дальше в этом направлении -

то бишь проверить для начала:
modprobe configs # если необходимо
zcat /proc/config.gz | egrep 'X86_PAT|STRICT_DEVMEM'

у мну:
# CONFIG X86_PAT is not set
# CONFIG_STRICT_DEVMEM is not set

emerge -vp glibc
[ebuild R ] sys-libs/glibc-2.6.1 USE="gd nls -debug -glibc-omitfp (-hardened) (-multilib) -profile (-selinux) -vanilla" 0 kB

и всё нормально работает ;)

23 декабря, 2008 - 12:11 — Nesmero

Может это вам, что и даст...

[ebuild R ] sys-libs/ncurses-5.7 USE="gpm unicode -ada -debug -doc -minimal -nocxx -profile -trace" 0 kB [0]
[ebuild R ] dev-libs/glib-2.18.3 USE="xattr -debug -doc -fam -hardened (-selinux)" 0 kB [0]
[ebuild R ] sys-apps/kbd-1.15 USE="nls" 0 kB [0]
[ebuild R ] sys-libs/slang-2.1.4 USE="cjk pcre png readline" 0 kB [0]
[ebuild R ] app-misc/mc-4.6.3 USE="7zip X background editor gpm network nls samba unicode vfs -attrs -dnotify -ext2undel"

mc -V
GNU Midnight Commander, версия 4.6.3
Виртуальная файловая система: tarfs, extfs, cpiofs, ftpfs, fish, smbfs, undelfs
Со встроенным редактором
С установленной в системе библиотекой S-Lang с базой данных terminfo
C поддержкой внутренней командной оболочки
С поддержкой фоновых операций
С поддержкой мыши в xterm и консоли Linux
С поддержкой событий X11
С поддержкой интернационализации
С поддержкой многих кодировок
Data types: char 8 int 32 long 32 void * 32 off_t 64 ecs_char 8

env | grep TERM
TERM=xterm
DCOP_YAKUAKE_TERMINAL=1
COLORTERM=

Стирать сожержимое ~/.mc бесполезно.

equery hasuse mmap
[ Searching for USE flag mmap in all categories among: ]
* installed packages
[I--] [ ] media-libs/libao-0.8.8 (0)

zcat /proc/config.gz | egrep 'X86_PAT|STRICT_DEVMEM'
# CONFIG_X86_PAT is not set
# CONFIG_STRICT_DEVMEM is not set

emerge -vp glibc
[ebuild R ] sys-libs/glibc-2.9_p20081201 USE="gd nls -debug -glibc-compat20 -glibc-omitfp (-hardened) (-multilib) -profile (-selinux) -vanilla"

23 декабря, 2008 - 12:21 — klark73

Так сходу видно, что ветка тестовая, по версиям куча отличий.
Но похоже нашёл простой воркэраунд (тока для версии 4.6.3-r105):

F9 -> Настройки -> Конфигурация
убрать флажки:
[x] Встроенный редактор
[x] Встроенный просмотр

Нажать F1 и внимательно прочесть HELP
Затем выйти и сохранить эти настройки.

То бишь мона юзать не встроенный, а внешний редактор/вьювер.
А по тому что Вы вывели, совершенно очевидно что проблемный glibc.
В том числе обеспечивает mmap()-syscall именно glibc.
Вы тестер что ли? :)

23 декабря, 2008 - 12:45 — Nesmero

не помогло, что вы сказали. На Ф3 используется нано, а если Ф4 то ваще ничего. Теперь ваще отображаются только точки((
А где взять не глючный glibc?)

23 декабря, 2008 - 12:51 — klark73

В соседней ветке похоже разобрались!
Всё оказалось сильно проще...
http://gentoo.ru/node/13155

> На Ф3 используется нано, а если Ф4 то ваще ничего.
HELP не прочли (там про переменные окружения) ;)

> А где взять не глючный glibc?
Untested ветка - для тестеров и девелоперов. ;)
Как в хендбуке написано - так и лучше!
Сидеть на стабильной ветке,
а при необходимости - отдельные вещи размаскировывать.
Ух, ща флейм начнётся! =)))

23 декабря, 2008 - 12:57 — Nesmero

Ну мне и это не помогло сильно.
А если у меня изначально была ~x86, то где мне что поменять чтобы сидеть на стейбле?

23 декабря, 2008 - 13:03 — klark73

Боюсь, только всё с нуля ставить. Незнаю, может стоит
попробовать поставить x86 в make.conf и emerge -vauDN world ?.. :)

Ещё вариант, взять поменьше glibc из тех же портежей,
но оно потянет за собой тоже очень много...

Я как-то долго экспериментировал с '~',
потом надоело заниматься решением проблем,
хотя они конечно все решаемы, вот и
вернулся на стабильную ветку...

23 декабря, 2008 - 13:13 — Nesmero

не дает мне система откатиться пишет "aborting to save your system"

23 декабря, 2008 - 13:15 — klark73

emerge -vae system && \
emerge -vauDN world ?

23 декабря, 2008 - 14:51 — willy

glibc не даунгрейдится по-нормальному, так как система
щщитает, что низя этого делать и прерывает сборку.
мона попробовать ebuild /usr/portage/sys-libs/glibc-2.8_p20080602.ebuild package
сделать... Хотя, если чессно, идея - дрянь.
Я забыл, однако - надо ebukild %) отредактировать.
if has_version '>'${CATEGORY}/${PF} ; then -
заменил на if has_version '<'${CATEGORY}/${PF} ; then (строка 225)
sudo ebuild /usr/portage/sys-libs/glibc/glibc-2.8_p20080602.ebuild digest
далее - см.выше :)

23 декабря, 2008 - 16:51 — evadim

это не система считает что откатывать нельзя, его действительно нельзя откатывать

24 декабря, 2008 - 13:02 — neroot

Почему?
Если сразу же за этим сделать пересборку мира... ?

—

Делай, что должен, и будь, что будет.

24 декабря, 2008 - 15:03 — krigstask

Например потому, что сделать пересборку мира не получится

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

24 декабря, 2008 - 21:09 — evadim

теоритически, откатить можно лиш в случае если поставить его, а потом не собирая ниодного пакета откатить. если что-то пересобиралось - кирдык

23 декабря, 2008 - 13:52 — klark73

mmap() реализуется ядром, но для userspace вывоз реализуется glibc.
если glibc не виноватая, то на mmap() в ядре кроме PAT влияет ещё и PAE.

если после команд:
modprobe configs # если нужно
zcat /proc/config.gz | grep HIGHMEM64G
не увидите этого:
# CONFIG_HIGHMEM64G is not set
попробуйте просто перезагрузиться,
добавив в строчку загрузки ядра (GRUB/LILO) nopae

если это сработает, можно выбрать в ядре:
Processor type and features --->
High Memory Support (4GB) --->
[*] MTRR (Memory Type Range Register) support
[ ] x86 PAT support
это и есть:
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
# CONFIG_X86_PAT is not set

а иначе у вас сейчас PAE-ядро
но шансов что поможет - почти нет, поэтому
просто "на попробовать" boot-опцию nopae - быстрее...

25 декабря, 2008 - 21:45 — Nesmero

Вышеописаное не работает.
UPD: Читаем ниже...чел разобрался. Ждем ответов.

25 декабря, 2008 - 21:38 — WiseLord

Проблема точно из-за glibc (не glib).
Не далее как вчера начал устанавливать новую систему, в основном - в стабильной ветке, но некоторые вещи (gcc, glibc, xorg, kde4) взять последних имеющихся версий. После установки mc обнаружил что F3 и F4 не работают.
Вспомнил, что недавно читал про это на форуме, попробовал другие версии glib, ncurses, slang, mc - не помогало.
В итоге решился на этот шаг - даунгрейд glibc.
Откатился с похоже появившейся совсем недавно версии 2.8_p20080602-r1 на чуть менее раннюю 2.8_p20080602-r1 - проблема исчезла.
Значит дело - именно в glibc.
Проблему "невозможности" даунгрейда обошёл, подправив имя папки в /var/db/pkg/sys-libs/ (сохранив старую копию и сделав с неё бинарник quickpkg на случай если что-то пойдёт не так. Тем самым заставил думать portage, что я пересобираю версию, а не обновляю.
Пересборка прошла удачно, содержимое каталога в /var/db/pkg/sys-libs/2.8_p20080602-r1 обновилось, так что по идее база не нарушена.
Сейчас запустил на пересборку gcc, если удастся, то думаю, с большой долей вероятности никаких проблем не должно быть в дальнейшем.
Если что - отпишусь тут о таковых.

26 декабря, 2008 - 01:18 — klark73

Какая версия glibc ТОЧНО не работала?
А какая - ТОЧНО работала?

Посмотрим хоть разницу в реализации mmap(),
найдём эту грёбанную регрессию, запостим баг -
хоть доброе дело сделаем =)))

26 декабря, 2008 - 03:05 — WiseLord 

Какая версия glibc ТОЧНО не работала?
А какая - ТОЧНО работала?

В ответе
Откатился с похоже появившейся совсем недавно версии 2.8_p20080602-r1 на чуть менее раннюю 2.8_p20080602-r1 - проблема исчезла.,
сорри, допустил опечатку.
Даунгрейд был с 2.9_p20081201 на 2.8_p20080602-r1, он и решил проблему.
Пока вроде проблем не наблюдаю;, уже на новой (даунгрейдженой) версии glibc (и пересобранным на ней gcc) (пере)собрано несколько десятков приложений - вроде бы всё гладко.

26 декабря, 2008 - 16:22 — klark73

Ну не смог я найти ошибку. :(

Зато нашёл кучу всего другого интересного:

Разницы в реализации mmap() между этими glibc нет.
Для i86_32 есть разница в низкоуровневых блокировках.
Для x86_64/nptl ушло пара определений из pthreaddef.h
Вне glibc (в связке с MC) это ни на что не повлияло.
Существенно изменён malloc.c ;-)

Но это ещё не всё...
Поддержка mmap() в целом для mc-4.6.3-r105 осталась,
она детектитится и юзается в нескольких местах,
при этом, её как раз-таки убрали из view.c, vfs.c,
забыв подправить help, который теперь несоответствует.
т.о. теперь всё упирается только в malloc().

Конечно сомнительно, что глючный malloc().
Ибо тогда должно глючить ну буквально ффсё!!!
Значит ошибка не так тривиальна.
Но дальше уже ковырять не стал...

26 декабря, 2008 - 16:38 — Nesmero

При загрузке выводит это:

*device-mapper uses addon code which is deprecated
*andmay not be available in the future.

27 декабря, 2008 - 13:28 — Nesmero

Проблема решилась обновлением мира ввиду:
sys-libs/glibc-2.9_p20081201-r1
ну можете еще и:
sys-devel/gcc-4.3.2-r1

27 декабря, 2008 - 20:28 — neroot

Да, действительно.
Как всегда - надо было просто немного подождать.
Зато научились даунгрейдить glibc. :)

—

Делай, что должен, и будь, что будет.

27 декабря, 2008 - 21:21 — klark73

Даунгрейд glibc был вроде бы (судя по сырцам) с glibc-2.9 на glibc-2.8. А в этом случае читаем:

Если один из основных пакетов (glibc, gcc, binutils) надо обновить на новую младшую версию, то безопаснее персобрать LFS. Вы можете сделать это пересборкой всех пакетов в порядке их зависимостей. Мы это не рекомендуем. Например, если glibc-2.2.x необходимо обновить до glibc-2.3.x, то безопаснее пересобрать. Для незначительного обновления версий обычно работает простая переустановка, но не гарантировано. Например, обновление от glibc-2.3.1 до glibc-2.3.2 обычно не будет означать каких-либо проблем.

взято отсель: http://lfs-ru.nm.ru/blfs/introduction/important.html#intro-important-pkgmgt

Это конечно offtop, но всё же повод. С glibc динамически линкуется практически любая прога. При переходе с версии на версию, ABI меняется не часто, но такое бывает случается. Но даже в LFS ничего не гарантируется!.. ;-) В любом случае, желательно потом обновить system/world.

28 декабря, 2008 - 12:25 — neroot

Про пересборку Вы абсолютно правы. :)
И вообще - СПАСИБО! Вам за участие в этой проблеме/топике. :)

—

Делай, что должен, и будь, что будет.

31 января, 2009 - 04:55 — klark73

r362 уже кто-нть юзал / ебилд видел? а r504?
http://people.redhat-club.org/inf/mc-slavaz/source/mc-4.6.3-r504.tar.bz2

Просто один камрад схожий БАГ в другом дистре ЗАБАГЗИЛЛИЛ.
Так вот его месяц как ПОФИКСИЛИ...

Russian Gentoo Linux Community © 2005—2026
Gentoo — торговая марка Gentoo Foundation, Inc.
Сервер работает под управлением Gentoo Linux
Сайт работает под управлением CMS Drupal