{РЕШЕНО} Не работает клавиша F3 в mc для просмотра файлов
Nesmero 21 декабря, 2008 - 22:07
Не работает клавиша F3 в mc для просмотра файлов, а вместо этого это действие теперь на Shift+F3 В чем может быть проблема. Единственная моя догадка, что недавно полностью пересобрал мир. У меня нестандарстная клавиатура с мультимедийными клавишами(не работают и не пользуюсь), но раньше все работало.
»
- Для комментирования войдите или зарегистрируйтесь
F3, F10, и снова F3 - теперь
F3, F10, и снова F3 - теперь показывает?
А откуда дровишки (MC)? Чаем не из оверлея?
такая же проблема с F3 в MC
вчера переставлял систему с нуля, столкнулся с такой же проблемой, т.е. по кнопкам F3 и F4 не выводится просмотр и редактирование файла в MC, МС родной из портэйджа. По Shift+F3 просмотр запускается. Проблему пока не решил.
Regards, S.M.
Я тоже обновился вчера вечером
У меня всё в ажуре:
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.
Какие дровишки?
Я не пользуюсь шибко верлеем. Какие дровишки?
Пересборка мс с вышеуказанными флагами не помогла. Такая комбинация тыканий тоже( Сборка 4.6.3 не помогла.
Можно по
Можно по /var/log/emerge.log-у глянуть, что именно вчера обновлялось.
Если дело тоже окажется в glibc, смотреть, что не так с версией.
А вообще странно. Обновлялись в один день, а поведение разное. :(
Даже никаких мыслей нет... Тока, если это обновление затронуло
сам MC, ядро или что-нть типа sys-apps/kbd.
А ветка какая? stable? x86? amd64?
Таки появилась мысля :)
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, у меня всё в норме...
Категорически согласен
Ветка х86. Разные вариации версий зависимостей не помогли. Дело только в glib. Буду его ломать по разному. Отпишусь позже.
Судя по документации, у вас
Судя по документации, у вас обновился slang или ncurses.
Судя по ебилду от 4.6.3-r105, mc собирается с slang-ом на уникодных системах (USE=unicode), иначе - с ncurses.
Так что откатывайте назад версию либы и сообщайте результаты! ;)
emerge -vp slang
[ebuild R ] sys-libs/slang-2.1.3-r1 USE="pcre png readline -cjk" 0 kB
это то, что у меня - так уж, до кучи :)
Столкнулся с теми же
Столкнулся с теми же симптомами.
После обновления glibc.
Пересборка мира не помогла. :(
Делай, что должен, и будь, что будет.
Обновил мс до 4.6.3, обновил
Обновил мс до 4.6.3, обновил kbd до 1.15 - толку ноль.
Делай, что должен, и будь, что будет.
emerge -vp kbd
[ebuild R ] sys-apps/kbd-1.13-r1 USE="nls" 0 kB
Именно все так. :) Сейчас
Именно все так. :)
Сейчас обновляю 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х
Делай, что должен, и будь, что будет.
.
я тоже словил этот баг, но убрав "tc-export BUILD_CC" смог перейти на 5.7
Млин, не нашел, где это
Млин, не нашел, где это поправить. :(
Подскажите?
Разобрался. В ebuild комментарий поставил.
Делай, что должен, и будь, что будет.
Вот так не проканает?
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]
Не проканало даже так:
[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 делать не буду - решил половить обновление.
Делай, что должен, и будь, что будет.
Я просто показал версии и
Я просто показал версии и USE-флаги установленного у меня ПО.
У вас совсем иные версии, чего уж тут.
Но самое интересное - совсем другой MC (версия, USE-флаги)! ;)
Были как у Вас. :) Показал
Были как у Вас. :)
Показал результат обновления и экспериментов с use.
В смысле, что не работает даже! с моим набором.
Жду патча на glibc. Млин.
Делай, что должен, и будь, что будет.
Slang vs ncurces
Похоже стоит провести эксперименты с флагами ncurses slang.
ncurses плохо живет с UTF-8. Там же частые причины с "расшифровыванием" функциональных клавиш.
Не канает
Не помогла никакая пересборка версий и glib и самого mc все откутывал и нифига((
Есть одно решение:)
Помогла установка системы с нуля :)) За одно убрались некоторые другие баги, накопившиеся за полтора года:)
Хотя сравнивая старую систему из stage4 и новую, которая получилась никаких особых отличий по версиям нет.
Использовал /etc/portage/* и make.conf из старой системы, как и многие другие конфигурационные файлы.
Ещё одна мысль...
Нашёл что в оверлейной 4.6.3 та же проблема бывает.
F3/F4 - это работа с обработанными данными.
F3 (Shift-F3) - просмотр raw, т.е. без обработки.
Shift-F4 - просто создать новый файл.
Осталось понять, кто/что отвечает за "обработку"...
Надо бы сорцы глянуть! ;)
За обработку отвечает переключатель F8
выше ошибся: не 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
и всё нормально работает ;)
Вот
Может это вам, что и даст...
[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"
Так сходу видно, что ветка
Так сходу видно, что ветка тестовая, по версиям куча отличий.
Но похоже нашёл простой воркэраунд (тока для версии 4.6.3-r105):
F9 -> Настройки -> Конфигурация
убрать флажки:
[x] Встроенный редактор
[x] Встроенный просмотр
Нажать F1 и внимательно прочесть HELP
Затем выйти и сохранить эти настройки.
То бишь мона юзать не встроенный, а внешний редактор/вьювер.
А по тому что Вы вывели, совершенно очевидно что проблемный glibc.
В том числе обеспечивает mmap()-syscall именно glibc.
Вы тестер что ли? :)
Нет)
не помогло, что вы сказали. На Ф3 используется нано, а если Ф4 то ваще ничего. Теперь ваще отображаются только точки((
А где взять не глючный glibc?)
В соседней ветке похоже
В соседней ветке похоже разобрались!
Всё оказалось сильно проще...
http://gentoo.ru/node/13155
> На Ф3 используется нано, а если Ф4 то ваще ничего.
HELP не прочли (там про переменные окружения) ;)
> А где взять не глючный glibc?
Untested ветка - для тестеров и девелоперов. ;)
Как в хендбуке написано - так и лучше!
Сидеть на стабильной ветке,
а при необходимости - отдельные вещи размаскировывать.
Ух, ща флейм начнётся! =)))
эээ
Ну мне и это не помогло сильно.
А если у меня изначально была ~x86, то где мне что поменять чтобы сидеть на стейбле?
Боюсь, только всё с нуля
Боюсь, только всё с нуля ставить. Незнаю, может стоит
попробовать поставить x86 в make.conf и emerge -vauDN world ?.. :)
Ещё вариант, взять поменьше glibc из тех же портежей,
но оно потянет за собой тоже очень много...
Я как-то долго экспериментировал с '~',
потом надоело заниматься решением проблем,
хотя они конечно все решаемы, вот и
вернулся на стабильную ветку...
Полохо
не дает мне система откатиться пишет "aborting to save your system"
а так?
emerge -vae system && \
emerge -vauDN world ?
mc
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
далее - см.выше :)
это не система считает что
это не система считает что откатывать нельзя, его действительно нельзя откатывать
Почему? Если сразу же за этим
Почему?
Если сразу же за этим сделать пересборку мира... ?
Делай, что должен, и будь, что будет.
Например потому, что сделать
Например потому, что сделать пересборку мира не получится
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
теоритически, откатить можно
теоритически, откатить можно лиш в случае если поставить его, а потом не собирая ниодного пакета откатить. если что-то пересобиралось - кирдык
Прежде чем откатывать...
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 - быстрее...
Неа
Вышеописаное не работает.
UPD: Читаем ниже...чел разобрался. Ждем ответов.
Проблема точно из-за glibc
Проблема точно из-за 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, если удастся, то думаю, с большой долей вероятности никаких проблем не должно быть в дальнейшем.
Если что - отпишусь тут о таковых.
Товарищи, подскажите поточнее!
Какая версия glibc ТОЧНО не работала?
А какая - ТОЧНО работала?
Посмотрим хоть разницу в реализации mmap(),
найдём эту грёбанную регрессию, запостим баг -
хоть доброе дело сделаем =)))
Какая версия glibc ТОЧНО не
В ответе
Откатился с похоже появившейся совсем недавно версии 2.8_p20080602-r1 на чуть менее раннюю 2.8_p20080602-r1 - проблема исчезла.,сорри, допустил опечатку.
Даунгрейд был с 2.9_p20081201 на 2.8_p20080602-r1, он и решил проблему.
Пока вроде проблем не наблюдаю;, уже на новой (даунгрейдженой) версии glibc (и пересобранным на ней gcc) (пере)собрано несколько десятков приложений - вроде бы всё гладко.
Бобик сдулся! =)))
Ну не смог я найти ошибку. :(
Зато нашёл кучу всего другого интересного:
Разницы в реализации 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().
Ибо тогда должно глючить ну буквально ффсё!!!
Значит ошибка не так тривиальна.
Но дальше уже ковырять не стал...
Не это ли?)
При загрузке выводит это:
*device-mapper uses addon code which is deprecated
*andmay not be available in the future.
Решено
Проблема решилась обновлением мира ввиду:
sys-libs/glibc-2.9_p20081201-r1
ну можете еще и:
sys-devel/gcc-4.3.2-r1
Да, действительно. Как всегда
Да, действительно.
Как всегда - надо было просто немного подождать.
Зато научились даунгрейдить glibc. :)
Делай, что должен, и будь, что будет.
Небольшое уточнение
Даунгрейд 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.
Про пересборку Вы абсолютно
Про пересборку Вы абсолютно правы. :)
И вообще - СПАСИБО! Вам за участие в этой проблеме/топике. :)
Делай, что должен, и будь, что будет.
Решил сюда запостить по принадлежности...
r362 уже кто-нть юзал / ебилд видел? а r504?
http://people.redhat-club.org/inf/mc-slavaz/source/mc-4.6.3-r504.tar.bz2
Просто один камрад схожий БАГ в другом дистре ЗАБАГЗИЛЛИЛ.
Так вот его месяц как ПОФИКСИЛИ...