http://bugzilla.kernel.org/show_bug.cgi?id=15188
Происходит ли такое еще у кого-нибудь?
p.s. Пытаюсь придумать как бы это однозначно воспроизвести, ибо ждать бага по полдня весьма уныло.
Думаю вот попробовать сие чудо. Каковы потенциальные плюсы и минусы?
Запись в багтрекере: http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/250
Здесь я хочу предупредить тех кто юзает маки с таблицей разделов GPT: не используйте новый parted 2.x до исправления этой ошибки, либо обязательно делайте gptsync после любого использования.
Столкнулся с совершенно неожиданной для себя проблемой. Есть диск, записанный в Nero под виндой, там файлы с длинными именами кириллицей (поубивал бы за такое, но юзерам не объяснишь). Надо дописать на него один файлик, при этом не убив имена у других. Что Brasero, что k3b - импортируют старую сессию с именами вида «1_____.doc».
Что тут можно сделать, и можно ли впринципе?
p.s. Разгребаю последствия перевода одной пожилой особы на линукс :)
http://habrahabr.ru/blogs/games/81349/#habracut
Ъ
Верховный суд Южной Кореи вынес вердикт относительно статуса виртуальных валют в онлайновых играх. Отныне такие валюты официально считаются эквивалентом реальных денежных единиц. Вердикт окончательный и обжалованию не подлежит.
Это очень важное решение, которое создаёт прецедент. Во-первых, теперь полностью легализован обмен виртуальной валюты на реальную, даже в играх, где это запрещено правилами игры, например, в WoW. То есть корейские пользователи могут делать это, не опасаясь уголовного преследования (хотя игровой аккаунт у них всё равно могут закрыть, потому что игра принадлежит американской фирме Blizzard).
Во-вторых, виртуальные валюты отныне легализованы и полностью вписываются во всю юридическую систему, включая уголовное и административное право, а также в налоговое законодательство.
И самое важное, если виртуальные валюты признаны эквивалентом реальных, то национальные правительства лишаются монополии на эмиссию денег! Возможно, это и есть начало золотой эпохи частных денег, о которой так давно мечтают либертарианцы.
Вообще, дело дошло до Верховного суда благодаря двум корейцам, которых судили за получение нелегального дохода от торговли виртуальными товарами из вселенной Lineage II. Однако, Верховный суд оправдал предпринимателей.
Кто-то тут ждал, поэтому - сабж :)
Changelog: http://qt.nokia.com/developer/changes/changes-4.6.1
Суть такова: есть программа, которая при работе использует базу данных на sqlite. Возможен случай, когда необходимо одновременно обратиться к одной и той же базе из нескольких экземпляров программы. SQLite при этом матерится, говоря о том что database is locked by another process. Можно ли это как-то обойти?
Как такое может быть?
root@mops64:~/mpkg/lib/build# make
[ 3%] Building CXX object CMakeFiles/mpkg.dir/mpkg.o
/root/mpkg/lib/mpkg.cpp: In member function ‘int mpkgDatabase::commit_actions()’:
/root/mpkg/lib/mpkg.cpp:1352: ошибка: нет декларации ‘uint64_t’ в этой области видимости
/root/mpkg/lib/mpkg.cpp:1352: ошибка: expected ‘;’ before ‘sz’
/root/mpkg/lib/mpkg.cpp:1361: ошибка: нет декларации ‘sz’ в этой области видимости
make[2]: *** [CMakeFiles/mpkg.dir/mpkg.o] Ошибка 1
make[1]: *** [CMakeFiles/mpkg.dir/all] Ошибка 2
make: *** [all] Ошибка 2
gcc 4.4.2, две почти одинаковые системы, одна x86 - там всё ок, другая x86_64, там не работает. Впервые вижу чтоб gcc не узнавал базовые типы. Куда копать?
Собираю себе пакет qt4. Ну собралось, всё ок, устанавливаю, всё установилось, отлично, едем дальше. Лезу править метаданные в qt4-doc (ибо забыл slack-desc положить), пытаюсь собрать - и понимаю что ничего не работает. Через пару секунд выясняю что улетучилась значительная часть либ из /usr/lib64. Ну, меня тут же охватывает паранойя, теория заговора, фаза лун юпитера и всё такое, ибо ну совершенно не понимаю откуда такая фигня может быть внезапно. Грешу уже даже на пакетный менеджер, на ext4 накрывшийся на ходу, на оперативку, на злобный ботнет из индии, который сканил меня весь день, и тут меня осенило заглянуть в doinst.sh последнего пакета...
Внимание, занавес:
( cd usr/lib64 ; rm -rf *.so* )
( cd usr/lib64 ; ln -sf qt-4.6.0/lib64/*.so* *.so* )
Сейчас вот собираюсь разбираться где я это так скрипт сборки извратил что оно мне такое сгенерило, систему в реинсталл (ибо восстанавливать дольше), но лулзов доставило :)
http://rghost.ru/795108/image.png
Для Ъ не будет.
Очень странный глюк, но воспроизводится к счастью легко.
Запускаем fluxbox, запускаем любую GTK-шную программу (например gvim), открываем диалог открытия файла, вытаскиваем его целиком мышкой на второй рабочий стол и, не отпуская - тащим обратно. Я получаю сегфолт флукса (и как следствие - перезапуск иксов).
Что странно - это происходит только с диалогом открытия файлов GTK. Ни при каких других обстоятельствах такого нету.
Помогите отловить источник проблемы, попробуйте сделать это у себя и укажите из какого дистра и какие версии gtk, fluxbox, libxcb и xorg-server.
bluez 4.57, openobex 1.5, blueman 1.21. Собрал, поставил, адаптер не видит.
hcitool показывает что девайс на месте:
root@mac:/home/aix# hcitool dev
Devices:
hci0 00:16:CB:31:B0:E4
Куда копать?
Товарищи, поделитесь кто-нибудь конфигом ванильного ядра 2.6.32.2, собранного либо универсально, либо под ноут с Intel'овским видео.
Суть вот какая: у меня начиная с 32-rc7 глючит видео: периодически экран дергается (как будто синхронизация слетает), и плюс к этому в ядрах до 32.0 включительно оно просто висло с серым экраном через какое-то время. С ядром 31.6 и предыдущими всё ок.
Пример конфига нужен для того, чтобы отсеять вариант с некорректной конфигурацией.
Я не могу смотреть с друзьями фильмы, которые у меня на харде, потому что они не знают английского. От фильмов в переводе - тошнит. Что мне делать?
Задача в общем-то банальная: выяснить, сколько займут места данные после распаковки архива. Для tar.gz это делается элементарно: gzip -l $FILENAME. А вот для xz такого ключика пока нет - пишет «not implemented yet». Пока решаю задачу с помощью костыля: xzcat $FILENAME | wc -c , но помимо того что это изврат - это еще и жутко медленно. Может быть, есть какие-нибудь не очень сложные способы выяснить это быстрее?
Такие есть в природе?
Уже не первый раз сталкиваюсь с совершенно непонятной мне ошибкой. Суть в том, что при некоторых уж очень странных обстоятельствах программа при завершении своей работы выдает такое (конец чуть обрезал, там много однообразного):
*** glibc detected *** mpkg: corrupted double-linked list: 0x0902f018 ***
======= Backtrace: =========
/lib/libc.so.6(+0x701c4)[0xb732c1c4]
/lib/libc.so.6(+0x733d0)[0xb732f3d0]
/lib/libc.so.6(cfree+0x72)[0xb7332492]
/lib/libc.so.6(+0x2ee6d)[0xb72eae6d]
/lib/libc.so.6(+0x2eeaf)[0xb72eaeaf]
/lib/libc.so.6(__libc_start_main+0xed)[0xb72d2b9d]
mpkg[0x80507c1]
======= Memory map: ========
08048000-08069000 r-xp 00000000 08:05 3092 /usr/bin/mpkg
08069000-0806a000 rw-p 00021000 08:05 3092 /usr/bin/mpkg
0902f000-0a21d000 rw-p 00000000 00:00 0 [heap]
b6c00000-b6c21000 rw-p 00000000 00:00 0
b6c21000-b6d00000 ---p 00000000 00:00 0
b6d46000-b6d71000 r--p 00000000 08:05 50483 /usr/share/locale/ru/LC_MESSAGES/libc.mo
b6d71000-b6d9b000 r--p 00000000 08:05 600 /usr/share/locale/ru/LC_MESSAGES/mpkg.mo
b6d9b000-b6dda000 r--p 00000000 08:05 57950 /usr/lib/locale/ru_RU.utf8/LC_CTYPE
b6dda000-b6ddc000 rw-p 00000000 00:00 0
b6ddc000-b6df2000 r-xp 00000000 08:05 112741 /lib/libpthread-2.11.so
b6df2000-b6df3000 r--p 00015000 08:05 112741 /lib/libpthread-2.11.so
b6df3000-b6df4000 rw-p 00016000 08:05 112741 /lib/libpthread-2.11.so
b6df4000-b6df7000 rw-p 00000000 00:00 0
Условия при которых такое случается - очень странные: сейчас это дело происходит исключительно если в директории есть директория с определенным именем, причем это имя никак с самой программой не связано.
Подскажите, что это, и как это отлаживать?
Уже начинаю грешить на баг в glibc, но интуиция подсказывает что это таки моя ошибка.
kdm из KDE 4.3.3, собран с PAM.
Действия:
1. Вводим пароль неправильно, жмем Enter, не пускает 2. Вводим еще раз (неважно - правильно или нет), жмем Enter.
У меня после этого валится kdm. По интернетам - куча подобных багрепортов, вроде этого: https://bugzilla.redhat.com/show_bug.cgi?id=506171
В логи падает вот это:
Nov 12 17:12:26 btr kdm_greet[28979]: Cannot read from core Nov 12 17:12:26 btr kdm[28972]: Unknown session exit code 0 (sig 6) from manager process
Плз, помогите понять в каком месте проблема и что патчить/куда слать багрепорт.
Имеем: видеокарта NVidia GeForce 6100, проприетарные дрова стоят (190.40), последние иксы (1.7) с HAL.
Без xorg.conf автоматом грузится драйвер nv. Понятное дело, что можно создать xorg.conf и прописать всё там, но вот стало интересно - как это сделать через HAL? Где задаются правила, по которым автоопределение в иксах выбирает драйвер для видеокарты?
Сорри что в talks, просто меня тут один знакомый уже извел: как убрать вставку иксового буфера по клику средней кнопкой мыши? Все интернеты перерыл - тишина...
| ← назад | следующие → |