avr
Можете очень легко систему “уронить”.
Я пока не представляю сценария, позволяющего “уронить” систему из-за ошибок на зеркале. Для всех загруженных пакетов “проверяется целостность”, то есть их хеш сверяется с записанным в базе данных репозитория.
Насколько я понимаю, чтобы “уронить” систему, недостаточно просто ошибок.
Требуется внесение зеркалом согласованных изменений в пакеты и базу одновременно. Так?
У меня последние версии всех пакетов.
xfce4-xkb-plugin включён.
Лампочка работает.
В настройках xfce, разделе “Клавиатура – Раскладка” включено “Использовать системные параметры”.
sirocco
Gudvin-t
1. Мигалка scroll led
С xfce4-xkb-plugin несовместимо.
xfce4-xkb-plugin НЕ УМЕЕТ включать эту лампочку САМ.
Если прописать её через XKB, он нормально переключает и лампочка тоже работает.
В чём именно состоит несовместимость?
lwin_toggle
Как показал поиск в гугле, полные списки можно нарыть в /usr/share/X11/xkb/rules/*.lst
Насчёт совместимости с Psi+ ничего пока сказать не могу (лично у меня этой проблемы не возникало), а вот чтобы работал индикатор ScrollLock, надо чтобы это было сделано через xkb, например прописано в xorg.conf или
setxkbmap us,ru\(winkeys\) variant grp:ctrl_shift_toggle,grp_led:scroll
в .xinitrc
Такое обычно бывает, когда у пользователя (под которым запускается scanimage) не хватает прав для доступа к сканеру.
Лечение – добавить пользователя в группу scanner и перезайти.
ElSonador
На одной машине ждет, пока отмонтируется, на другой нет.
Правильно, это и есть то, что я назвал “несогласованность”. Что-то там не успевает в срок, на разных машинах по-разному, даже на одной и той же через раз.
Я пока такой жути с гигабайтом не наблюдал, но потребление памяти у него действительно со временем (точнее при переключениях по новым окнам) только растёт, видимо это и есть то, что называется “утечка”. Пока около 190М, впрочем, похожие цифры у многих компонентов xfce, и скорей всего, приходятся на общие библиотеки.
udev-141 это очень старая версия (апрель 2009), она у меня стояла в Slackware-13.0

Как я недавно выяснил, именно она и была (по крайней мере, у меня) последней “нетормозной”. В следующей, то есть 142, был изменён метод обработки подключаемых дисков, и пошло-поехало. Откатываться на 141 я не стал, так как она требует переписывания под неё многих правил. Если интересно, исходники всех версий есть на сайте udev, а правила к ней можно найти в пакетах от “релизных” дистрибутивов, хотя бы от того же Slackware-13.0.
http://www.kernel.org/pub/linux/utils/k … 41.tar.bz2
ftp://ftp.gwdg.de/pub/linux/slackware/s … i486-3.txz
ftp://ftp.gwdg.de/pub/linux/slackware/s … ce/a/udev/
При желании из этого можно даже слепить рабочий пакет для арч.

Лично я пока ограничился экспериментами, поскольку в udev-166 вроде наметились некоторые улучшения, а текущие глюки пока ещё не настолько раздражают, чтобы всерьёз заняться такого рода некромантией :)
По моим наблюдениям, новые версии udev стали работать очень медленно и несогласованно. Реакция на изменение состояние устройства может сильно запаздывать или вообще не срабатывать, например извлечение флешек через eject отражается в /dev/ со второго раза (в udev-166 иногда и с первого), при подключении флешки с двумя разделами один из них может иногда “не обнаружиться”, DVD-R сразу после монтирования может вдруг снова оказаться не смонтированным, и т.д.

Последняя версия udev, в которой этого не наблюдалось, была 141.