Created attachment 7910 [details] сломанное отображаение раскладок Сломано отображение раскладок (смотреть скрин во вложении). Сломалось в период 27.09.2018-23.10.2018. Сам alterator-xkb не обновлялся в этот период.
Забавный баг, висящий на nobody. Проблема с теми grp, у которых в описании есть ';'. Как-то похоже на фронтенде эта ';' обрабатывается особым образом. Проверил, добавление строчки sed -i 's/;/,/g' options в конец функции dump_cache снимает проблему, но это какой-то совсем костыльный костыль. Есть подозрение, что это связано с изменением в самом альтераторе: * Wed Aug 29 2018 Paul Wolneykien <manowar at altlinux.org> 5.3-alt1 - Allow semicolon-separated values for the *-list types. manowar@, не посмотрите, что тут лучше сделать? Отмечу, что описания grp (вариантов переключения раскладки) прилетают из пакета xkeyboard-config. Там ';' в них появились в коммите 10cf5acd90327a0b9e115964c8c4f52b4575cd4b, который вошел в 2.25-alt1, попавший в Сизиф 15 октября 2018, что соответсвует указанному периоду возникновения проблемы.
> Есть подозрение, что это связано с изменением в самом альтераторе: > > * Wed Aug 29 2018 Paul Wolneykien <manowar at altlinux.org> 5.3-alt1 > - Allow semicolon-separated values for the *-list types. Очень похоже.
Created attachment 7976 [details] Отладочный вывод перед (widget rows labels)
Уже меньше похоже. Я вставил отладочный вывод вот сюда: (cond ((member t '("listbox" "combobox")) (let* ((r (or (widget row) '#((label . "")))) (labels (map (lambda(x) (enumref-fill-row x r)) variants))) ---------------->>>> (widget rows labels))) и получил вот такой, вполне пристойный список названий (см. файл xkb.labels).
Created attachment 7977 [details] Команда для заполнения выпадающего списка значений
Насколько я могу судить вот по этой XMLке (https://bugzilla.altlinux.org/attachment.cgi?id=7977), элементы списка можно распарсить, потому что они отделены друг от друга ;; — двойным знаком точки с запятой, а не одинарным (кроме последнего). Однако мне, признаться, неизвестно, был ли такой формат передачи значений для браузера всегда или что-то действительно сломалось. Сергей?
(В ответ на комментарий №6) > отделены друг от друга ;; — двойным знаком точки с > запятой, а не одинарным (кроме последнего). Не двойной, а два одинарных. Если пустые элементы игнорировать, поплывёт.
Не понял. Что исправлять-то?
Видимо, уже поплыло. Попробуй сравнить с xml-ом на p8.
(В ответ на комментарий №5) > Команда для заполнения выпадающего списка значений Не хватает ";" в некоторых местах. После "Caps Lock на первую раскладку" и "Левая Win на первую раскладку", например.
(In reply to comment #10) > (В ответ на комментарий №5) > > Команда для заполнения выпадающего списка значений > Не хватает ";" в некоторых местах. > После "Caps Lock на первую раскладку" и "Левая Win на первую раскладку", > например. Это не нехватает. Это пункт списка, содержащий ';', которую надо отобразить в этом пункте как ';'.
(В ответ на комментарий №11) > надо отобразить в этом пункте как ';'. Зачем её там отображать?
Не о том спор, по-моему. Что сломалось-то и где? Это регресс или нет?
(В ответ на комментарий №13) > Не о том спор, по-моему. Что сломалось-то и где? Это регресс или нет? На сколько я теперь понял, лишние знаки ";". Из-за них колбасит список, т.к. это разделитель.
(In reply to comment #12) > (В ответ на комментарий №11) > > надо отобразить в этом пункте как ';'. > Зачем её там отображать? В данном случае это не разделитель item'ов в select, а часть описания способа переключения раскладки. In english: "Caps Lock to first layout; Shift+Caps Lock to last layout" http://git.altlinux.org/gears/x/xkeyboard-config.git?p=xkeyboard-config.git;a=blob;f=rules/base.xml.in;h=de88d403b23e29ae6f3d74d8459960f184d60463;hb=9793f3bed0e3ef4fefe3e2d6f46e9d222bc68caf#l6195 In russian: "Caps Lock на первую раскладку; Shift+Caps Lock на последнюю раскладку" http://git.altlinux.org/gears/x/xkeyboard-config.git?p=xkeyboard-config.git;a=blob;f=po/ru.po;h=27a1251f04f0fb82378e156b99603cf1923e1072;hb=9793f3bed0e3ef4fefe3e2d6f46e9d222bc68caf#l3530 Как я писал выше, можно подхачить бекенд и заменить ';' на ','. sed-ом. Если альтератор не способен отобразить пукты select, содержащие ';', надо так и сделать. Если способен, надо поправить где-то ещё чтобы такой случай корректно обрабатывался.
(В ответ на комментарий №15) > Как я писал выше, можно подхачить бекенд и заменить ';' на ','. sed-ом. Если > альтератор не способен отобразить пукты select, содержащие ';', надо так и > сделать. ';' считается разделителем и всё тут. Т.е. только на другой символ заменить.
Еще там встречяаются всякие '<'. Посмотрите, может заэскейпить получится.
(В ответ на комментарий №16) > (В ответ на комментарий №15) > > Как я писал выше, можно подхачить бекенд и заменить ';' на ','. sed-ом. Если > > альтератор не способен отобразить пукты select, содержащие ';', надо так и > > сделать. > ';' считается разделителем и всё тут. Т.е. только на другой символ заменить. Сергей, что именно является разделителем — одна (;) или только две (;;) ? Судя по XML, который я прикрепил выше, alterator-lookout полагает, что разделителем элементов списка является ;; — две тзпт. alterator-browser-qt считает иначе? Если да, то почему и когда это началось? Просто Антон завёл багу так, как будт-то бы это регресс и раньше всё работало. Антон, на какой версии работает? p8?
(В ответ на комментарий №18) > Сергей, что именно является разделителем — одна (;) или только две (;;) ? Одна. > Судя > по XML, который я прикрепил выше, alterator-lookout полагает, что разделителем > элементов списка является ;; — две тзпт. Нет, не полагает. Одна. Там присутствует обязательный элемент. В данном случае он пустой.
> (В ответ на комментарий №18) > Там присутствует обязательный элемент. В данном случае он пустой. А-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а-а… Теперь дошло!
(В ответ на комментарий №18) > Сергей, что именно является разделителем — одна (;) или только две (;;) ? Судя > по XML, который я прикрепил выше, alterator-lookout полагает, что разделителем > элементов списка является ;; — две тзпт. alterator-browser-qt считает иначе? > Если да, то почему и когда это началось? Просто Антон завёл багу так, как > будт-то бы это регресс и раньше всё работало. > > Антон, на какой версии работает? p8? alterator-browser-qt5-3.0.5-alt1.M80P.1, это та же версия, что и в Сизифе (%ubt). iv@ же вполне точно определил, когда это началось: >Отмечу, что описания grp (вариантов переключения раскладки) прилетают из пакета >xkeyboard-config. Там ';' в них появились в коммите >10cf5acd90327a0b9e115964c8c4f52b4575cd4b, который вошел в 2.25-alt1, попавший в >Сизиф 15 октября 2018, что соответсвует указанному периоду возникновения >проблемы. 15 октября 2018 началось. xkeyboard-config виноват, даёт нам то, что некорректно понимает alterator-browser-qt5 27.09.2018 точно работало. Сохранилась регулярка.
(В ответ на комментарий №21) > xkeyboard-config виноват, даёт нам то, что некорректно понимает > alterator-browser-qt5 Не. Скорее, apterator-xkb некорректно передаёт. alterator-browser-qt5 понимает ровно то, что ему дали.
(В ответ на комментарий №22) > (В ответ на комментарий №21) > > xkeyboard-config виноват, даёт нам то, что некорректно понимает > > alterator-browser-qt5 > Не. Скорее, apterator-xkb некорректно передаёт. > alterator-browser-qt5 понимает ровно то, что ему дали. Согласен. alterator-xkb фактически не менялся с 2009 года. Устарел...
Да они оба как бы не менялись в этом плане, но входные данные обрабатывает alterator-xkb, а формат передачи к alterator-browser-qt изменению не подлежит.
(В ответ на комментарий №24) > Да они оба как бы не менялись в этом плане, но входные данные обрабатывает > alterator-xkb, а формат передачи к alterator-browser-qt изменению не подлежит. Ок, формат разделения на элементы менять не будем. Придумай, однако, на что заменить ";" в передаче, чтобы пользователь на экране увидел именно его. Я поставлю соответствующий фильтр в alterator-lookout.
(В ответ на комментарий №17) > Еще там встречяаются всякие '<'. Посмотрите, может заэскейпить получится.
(В ответ на комментарий №26) > (В ответ на комментарий №17) > > Еще там встречяаются всякие '<'. Посмотрите, может заэскейпить получится. < — это символ "меньше" (<). А я про точку с запятой. Можно код символа указать через ; Пойдёт так?
(В ответ на комментарий №27) > < — это символ "меньше" (<). А я про точку с запятой. Можно код символа > указать через ; Пойдёт так? Хотя нет, не пойдёт. Такая замена сама содержит в себе ";". Нужно что-то другое, чтобы заменялось на ";" внутри самого alterator-browser-qt, после разбора XML. Выбирай.
(В ответ на комментарий №28) > Хотя нет, не пойдёт. Такая замена сама содержит в себе ";". Нужно что-то > чтобы заменялось на ";" внутри самого alterator-browser-qt, после разбора XML. Т.к. alterator-browser-qt ничего не знает о передаваемых данных, то трогать ничего не будет. Только передавать туда-обратно, как до сих пор делал.
(В ответ на комментарий №29) > (В ответ на комментарий №28) > > Хотя нет, не пойдёт. Такая замена сама содержит в себе ";". Нужно что-то > > чтобы заменялось на ";" внутри самого alterator-browser-qt, после разбора XML. > Т.к. alterator-browser-qt ничего не знает о передаваемых данных, то трогать > ничего не будет. Только передавать туда-обратно, как до сих пор делал. Сергей, вам не кажется, что вы нам втираете какую-то дичь? Вот тут http://git.altlinux.org/gears/a/alterator-browser-qt5.git?p=alterator-browser-qt5.git;a=blob;f=alterator-browser-qt/widgets/al_listbox.cc;h=b38f18c35ac1cd2061d531d3d8f5dc713308192e;hb=94a4cdc6d514abfceab3e3e416c00284b9e27e0b#l129 , например, данные не просто передаются туда-обратно, а сохраняются для последующей визуализаии. И здесь можно было бы восстановить ";" из какой-нибудь последовательности других символов. А ещё лучше было бы взять вот эту часть http://git.altlinux.org/gears/a/alterator-browser-qt5.git?p=alterator-browser-qt5.git;a=blob;f=alterator-browser-qt/widgets/al_listbox.cc;h=b38f18c35ac1cd2061d531d3d8f5dc713308192e;hb=94a4cdc6d514abfceab3e3e416c00284b9e27e0b#l285 (и 280 тоже) и добавить туда поддержку нормального разделения элементов списка, вместо value.split(";", ...). Допустим, сделать <item>...</item> в том же XML, в котором уже сейчас приходит оболочка этих элементов.
(В ответ на комментарий №30) > Сергей, вам не кажется, что вы нам втираете какую-то дичь? Вам вотрут любую дичь, вы её тупо передадите дальше и обвините следующего, что он что-то не понял? > добавить туда поддержку нормального разделения элементов списка, Хотите ломать -- я не против, ломайте, но без меня.
А может стоит посмотреть, как сделано, в шаге инсталлятора "Выбор языка"? Там то всё нормально. К тому он же умеет менять раскладку ещё и для tty. И есть вот такой баг: https://bugzilla.altlinux.org/show_bug.cgi?id=30932 Может можно адаптировать этот модуль инсталлятора как модуль для альтератора на замену alterator-xkb?
Давайте, прежде всего, выясним, нужна ли нам поддержка вывода любых символов в виджетах типа список, выпадающий список и т.д.? Если нужна, то логично проапгрейдить формат передачи данных между aterator-lookout и alterator-browser-qt так, чтобы не возникало путаницы. Если не нужна, то логичнее всего заменить ";" на "," в самом начале, как предлагал Иван. Но это отсрочка до следующего прецедента.
(В ответ на комментарий №33) > логично Еще логичнее переписать alterator с нуля, поэтому если вы не собираетесь заниматься разработкой alterator, то и ломать не надо. > Если не нужна, то логичнее всего заменить ";" на "," в самом начале, как > предлагал Иван. На входе достаточно привести данные в нужный вид. Т.е. в бэкенде. > Но это отсрочка до следующего прецедента. Раз в 10 лет такие преценденты можно не считать проблемой.
(В ответ на комментарий №34) > (В ответ на комментарий №33) > > логично > Еще логичнее переписать alterator с нуля, поэтому если вы не собираетесь > заниматься разработкой alterator, то и ломать не надо. > > > Если не нужна, то логичнее всего заменить ";" на "," в самом начале, как > > предлагал Иван. > На входе достаточно привести данные в нужный вид. Т.е. в бэкенде. > > > Но это отсрочка до следующего прецедента. > Раз в 10 лет такие преценденты можно не считать проблемой. Пожалуй. Как дела с этой багой, коллеги?
Поясню: тут или нужно тянуть наследство неудачного формата передачи данных дальше (и поставить костыль из комментария #1) или усовершенствовать этот формат вполне конкретным образом. Я вполне определённо высказывался за второй вариант (поскольку в первом моя помощь, очевидно, не требуется). Однако поддержки со стороны мэйнтейнера пакета alterator-browser-qt не получил.
(В ответ на комментарий №36) > Поясню: тут или нужно тянуть наследство неудачного формата передачи данных > дальше (и поставить костыль из комментария #1) или усовершенствовать этот > формат вполне конкретным образом. Я вполне определённо высказывался за второй > вариант (поскольку в первом моя помощь, очевидно, не требуется). Однако > поддержки со стороны мэйнтейнера пакета alterator-browser-qt не получил. Я полагаю, что сейчас, во время бранчей горячки, стоит выбрать первый вариант, пусть и нехороший, и повесить багу о втором. Меня в cc:. Если это принимается, то прошу Вас поправить. Спасибо.
Ок
alterator-xkb-3.0-alt3 -> sisyphus: Mon Feb 18 2019 Paul Wolneykien <manowar@altlinux> 3.0-alt3 - Workaround ALTBUG #35797: replace ';' with ',' in the enumerated data (closes: #35797).
Спасибо!
Исправлено. Спасибо!
Обнаружил, что не всё починилось. Если выбрать раскладку alt+shift, то при следующем запуске alterator будет показывать пустое поле. С остальными раскладками такого не наблюдается. manowar@, посмотрите, пожалуйста.
Будем посмотреть…
(В ответ на комментарий №42) > Обнаружил, что не всё починилось. Если выбрать раскладку alt+shift, то при > следующем запуске alterator будет показывать пустое поле. С остальными > раскладками такого не наблюдается. > > manowar@, посмотрите, пожалуйста. Кстати, оно просто не назначается. Потому и поле пустое.
Хм... Там происходит нечто странное: # LC_ALL="en" LANGUAGE="en:ru" xkbdatadump # grep 'alt_shift_toggle' options rp:alt_shift_toggle Alt+Shift При этом для остальных раскладок имеем правильный дамп: # grep 'ctrl_alt_toggle' options grp:ctrl_alt_toggle Alt+Ctrl
Там какой-то страшный разбор XML, написанный на C. И в ходе него, действительно, тепяется буква "g": (gdb) p *u value has been optimized out (gdb) s do_reset (u=0x4060a0) at xkbdatadump.c:103 103 do_reset(u); (gdb) p *u $15 = {el = 0x0, file = 0x405260, mode = 1, layname = 0x409560 "grp", name = 0x412210 "rp:alt_shift_toggle", laydescription = 0x40a410 "Switching to another layout", description = 0x40fca0 "Alt+Shift"} Наверняка всплыла очередная ошибка с обращением к памяти в связи с переходом на новый компилятор. Если есть силы — помогайте.
Я собрал его вот с таким патчем: static void XMLCALL cdata_handler(void *data,const char *buffer, int len) { + char buf[256]; user_data *u = data; + snprintf( buf, len, "%s", buffer ); + fprintf( stderr, "CDATA: '%s'\n", buf ); + if (!u->el) return; и получил результат: # LC_ALL="en" LANGUAGE="en:ru" xkbdatadump 2>&1 | grep 'alt_shift' CDATA: 'rp:alt_shift_toggl' Получается, что неполные данные передаются уже в callback-функцию cdata_handler() от XML_Parser.
(In reply to comment #47) > Я собрал его вот с таким патчем: > > static void XMLCALL > cdata_handler(void *data,const char *buffer, int len) > { > + char buf[256]; > user_data *u = data; > > + snprintf( buf, len, "%s", buffer ); len+1? > + fprintf( stderr, "CDATA: '%s'\n", buf ); > + > if (!u->el) return; > > и получил результат: > > # LC_ALL="en" LANGUAGE="en:ru" xkbdatadump 2>&1 | grep 'alt_shift' > CDATA: 'rp:alt_shift_toggl' > > Получается, что неполные данные передаются уже в callback-функцию > cdata_handler() от XML_Parser. А если добавить в /usr/share/X11/xkb/rules/xorg.xml пару пробелов на пару строк выше grp:alt_shift_toggle, прилетает правильно. Очень похоже на баг в expat.
Да, кстати, забыл написать, что в исходном файле всё в порядке: # rpm -qf /usr/share/X11/xkb/rules/xorg.xml xkeyboard-config-2.25-alt1.noarch # grep 'alt_shift_toggle' /usr/share/X11/xkb/rules/xorg.xml <name>grp:alt_shift_toggle</name>
(В ответ на комментарий №48) > выше grp:alt_shift_toggle, прилетает правильно. Очень похоже на баг в expat. Ну или в xkbdatadump.c есть ошибки с malloc()/free() которые приводят к ошибкам.
Мои опасения, похоже, подтвердились: # LC_ALL="en" LANGUAGE="en:ru" xkbdatadump 2>&1 | grep -e 'MALLOC' -e 'STRDUP' | wc -l 6780 # LC_ALL="en" LANGUAGE="en:ru" xkbdatadump 2>&1 | grep -e 'FREE' | wc -l 4591 Это я решил посчитать, сколько раз память выделяется и сколько освобождается. Вот таким образом: @@ -35,8 +35,11 @@ typedef struct user_data_struct { void do_free(char **item) { - if (*item) free(*item); - *item = 0; + if (*item) { + free(*item); + *item = 0; + fprintf (stderr, "FREE\n"); + } } @@ -47,6 +50,7 @@ do_assign(char **target,const char *destination,int len) if (destination && (len > 0)) { *target=malloc(len+1); + fprintf (stderr, "MALLOC\n"); @@ -73,6 +77,7 @@ element_start(void *data, const char *el, const char **attr) user_data *u = data; u->el = strdup(el); + fprintf (stderr, "STRDUP\n"); Наверное, можно было через strace тоже.
Ну то, что оно течёт, видно и невооруженным валгриндом: $ valgrind --leak-check=full xkbdatadump ==7351== Memcheck, a memory error detector ==7351== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7351== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==7351== Command: xkbdatadump ==7351== ==7351== ==7351== HEAP SUMMARY: ==7351== in use at exit: 21,300 bytes in 2,190 blocks ==7351== total heap usage: 7,018 allocs, 4,828 frees, 135,302 bytes allocated ==7351== ==7351== 143 (56 direct, 87 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 4 ==7351== at 0x48399A2: calloc (vg_replace_malloc.c:762) ==7351== by 0x401237: main (xkbdatadump.c:161) ==7351== ==7351== 793 bytes in 92 blocks are definitely lost in loss record 3 of 4 ==7351== at 0x4837753: malloc (vg_replace_malloc.c:309) ==7351== by 0x4B399C9: strdup (strdup.c:42) ==7351== by 0x4014A3: element_start (xkbdatadump.c:75) ==7351== by 0x4890775: doContent (xmlparse.c:2922) ==7351== by 0x4890F1B: contentProcessor (xmlparse.c:2584) ==7351== by 0x4892893: doProlog (xmlparse.c:4604) ==7351== by 0x4892FF7: prologProcessor (xmlparse.c:4321) ==7351== by 0x4895407: XML_ParseBuffer (xmlparse.c:2081) ==7351== by 0x40129E: main (xkbdatadump.c:173) ==7351== ==7351== 20,364 bytes in 2,093 blocks are definitely lost in loss record 4 of 4 ==7351== at 0x4837753: malloc (vg_replace_malloc.c:309) ==7351== by 0x4B399C9: strdup (strdup.c:42) ==7351== by 0x4014A3: element_start (xkbdatadump.c:75) ==7351== by 0x4890775: doContent (xmlparse.c:2922) ==7351== by 0x4890F1B: contentProcessor (xmlparse.c:2584) ==7351== by 0x4895407: XML_ParseBuffer (xmlparse.c:2081) ==7351== by 0x40129E: main (xkbdatadump.c:173) ==7351== ==7351== LEAK SUMMARY: ==7351== definitely lost: 21,213 bytes in 2,186 blocks ==7351== indirectly lost: 87 bytes in 4 blocks ==7351== possibly lost: 0 bytes in 0 blocks ==7351== still reachable: 0 bytes in 0 blocks ==7351== suppressed: 0 bytes in 0 blocks ==7351== ==7351== For counts of detected and suppressed errors, rerun with: -v ==7351== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) Но это не выглядит, как проблема. Да, неаккуратно, но для утилиты, которая один раз запускается и быстро выходит это не критично. В то же время никаких double free, а также доступа к невыделенной или неинициализированной памяти валгринд не обнаруживает.
Посмотрел ещё раз, с патчем, очень похожем на comment #47, но с len+1 в strncpy, так что оно не обрезает последний символ: diff --git a/alterator-xkb/tools/xkbdatadump/xkbdatadump.c b/alterator-xkb/tools/xkbdatadump/xkbdatadump.c index 43b3bd1..32d4448 100644 --- a/alterator-xkb/tools/xkbdatadump/xkbdatadump.c +++ b/alterator-xkb/tools/xkbdatadump/xkbdatadump.c @@ -132,8 +132,12 @@ element_stop(void *data, const char *el) static void XMLCALL cdata_handler(void *data,const char *buffer, int len) { + char buf[256]; user_data *u = data; + snprintf( buf, len+1, "%s", buffer ); + fprintf( stderr, "CDATA: '%s'\n", buf ); + if (!u->el) return; if (!strcmp(u->el,"name")) Если посмотреть внимательно, имеем такой кусочек: CDATA: ' ' CDATA: 'g' CDATA: 'rp:alt_shift_toggle' CDATA: ' Это валидное поведение expat и вообще любого xml-парсера: он может вызывать character data handler сколько угодно раз хоть для каждого символа в отдельности. xkbdatadump, очевидно, такого не ожидает, хотя должен.
(В ответ на комментарий №53) > Если посмотреть внимательно, имеем такой кусочек: > CDATA: ' ' > CDATA: 'g' > CDATA: 'rp:alt_shift_toggle' > CDATA: ' > > > Это валидное поведение expat и вообще любого xml-парсера: он может вызывать > character data handler сколько угодно раз хоть для каждого символа в > отдельности. xkbdatadump, очевидно, такого не ожидает, хотя должен. О, теперь понятно. Спасибо.
(In reply to comment #53) > Это валидное поведение expat и вообще любого xml-парсера: он может вызывать > character data handler сколько угодно раз хоть для каждого символа в > отдельности. xkbdatadump, очевидно, такого не ожидает, хотя должен. Посмотрел на код -- получается, xkbdatadump надо значительно так переписать. Могу этим заняться на выходных.
(В ответ на комментарий №55) > (In reply to comment #53) > > Это валидное поведение expat и вообще любого xml-парсера: он может вызывать > > character data handler сколько угодно раз хоть для каждого символа в > > отдельности. xkbdatadump, очевидно, такого не ожидает, хотя должен. > > Посмотрел на код -- получается, xkbdatadump надо значительно так переписать. > Могу этим заняться на выходных. Ну, я вроде начал уже. Решил переписать на статику вообще. Если нужно будет, потом сделаем realloc(). Но пока кажется, что это лишнее.
(В ответ на комментарий №56) > (В ответ на комментарий №55) > > (In reply to comment #53) > > > Это валидное поведение expat и вообще любого xml-парсера: он может вызывать > > > character data handler сколько угодно раз хоть для каждого символа в > > > отдельности. xkbdatadump, очевидно, такого не ожидает, хотя должен. > > > > Посмотрел на код -- получается, xkbdatadump надо значительно так переписать. > > Могу этим заняться на выходных. > > Ну, я вроде начал уже. Решил переписать на статику вообще. Если нужно будет, > потом сделаем realloc(). Но пока кажется, что это лишнее. Как дела? Выходные заканчиваются. :)
Точно. Я просто забыл собрать в тот раз. Отправил test only в Сизиф сейчас: http://git.altlinux.org/tasks/230470/ .
(В ответ на комментарий №58) > Точно. Я просто забыл собрать в тот раз. Отправил test only в Сизиф сейчас: > http://git.altlinux.org/tasks/230470/ . Failed
Да, нужно доделать. Завтра займусь этим.
TESTED. Я проверил на относительно свежем Сизифе и там оно работает. Коммитим / закрываем?
(В ответ на комментарий №61) > TESTED. Я проверил на относительно свежем Сизифе и там оно работает. Коммитим / > закрываем? Я сейчас проверю.
(В ответ на комментарий №62) > (В ответ на комментарий №61) > > TESTED. Я проверил на относительно свежем Сизифе и там оно работает. Коммитим / > > закрываем? > > Я сейчас проверю. Коммитьте, закрывайте. Спасибо!
Спасибо
*** Bug 36800 has been marked as a duplicate of this bug. ***
http://git.altlinux.org/tasks/archive/done/_225/230470/logs/events.3.3.log
