ALT Linux Bugzilla – #24379

Блокирует сборку libxml-ruby и всего RoR.

(In reply to comment #1)
> Блокирует сборку libxml-ruby и всего RoR.

Сборку блокирует сборочница, а вовсе не какие-то там жалкие пакеты.
Пожалуйста, если у тебя есть возможность, то попробуй исправить сам.

Сейчас у нас нет полноценного мейнтейнера пакета libxml2, который мог бы проанализировать ситуацию и дать обоснованное заключение.

Я сейчас тупо обновляю libxml2 до новой версии 2.7.8, в которой исправлены crash-баги.

Поручиться в том, что libxml2 работает неправильно, я не могу.
Разбираться в правильности реализации API у меня сейчас возможности нет.

Ввиду вышеперечисленного предлагаю жаловаться Daniel Veillard в апстрим (можно и в Федорную багзиллу, поскольку он там является мейнтейнером libxml2).

А может все-таки что-нибудь попробуем сделать?
Не хотелось бы вылета RoR.

(In reply to comment #4)
> А может все-таки что-нибудь попробуем сделать?
> Не хотелось бы вылета RoR.

У нас, в Fedora и Debian практически одинаковые пакеты libxml2.
Поскольку для них API, реализованный в libxml2, не является препятствием для упаковки libxml-ruby, напрашивается очевидный вывод: libxml2 не блокирует сборку libxml-ruby и всего остального.

Конечно libxml2 не блокирует сборку libxml-ruby, если этот libxml-ruby вообще не собирать.

Я понял, скриптовые языки в репозитарии никому нахрен не упёрлись.  Спасибо за конструктивный ответ.

(In reply to comment #6)
> Конечно libxml2 не блокирует сборку libxml-ruby, если этот libxml-ruby вообще
> не собирать.

Как же, интересно, _все_ остальные собирают libxml-ruby и не страдают от того, что у libxml2 якобы неправильно реализованный API?

> Я понял, скриптовые языки в репозитарии никому нахрен не упёрлись.  Спасибо за
> конструктивный ответ.

Похоже, что бывший мейнтейнер libxml-ruby просто забил на свои пакеты и хочет напоследок свалить с больной головы на здоровую.  Ну что же, спасибо, г-н бывший мейнтейнер. :(

(In reply to comment #7)
> Как же, интересно, _все_ остальные собирают libxml-ruby и не страдают от того,
> что у libxml2 якобы неправильно реализованный API?
"Все остальные" не заморачиваются с тестами.

> Похоже, что бывший мейнтейнер libxml-ruby просто забил на свои пакеты и хочет
> напоследок свалить с больной головы на здоровую.  Ну что же, спасибо, г-н
> бывший мейнтейнер. :(
Похоже, что некоторые неполноценные* мейнтейнеры реагируют только на истерику, при чём инициированную только другими неполноценными* мейнтейнерами.  Бывшему мейнтейнеру libxml-ruby не очень приятно что-то делать в такой обстановке.  Ну что же, спасибо, г-н неполноценный* мейнтейнер. :(

*) bug 24379 comment 3

(In reply to comment #8)
> (In reply to comment #7)
> > Как же, интересно, _все_ остальные собирают libxml-ruby и не страдают от того,
> > что у libxml2 якобы неправильно реализованный API?
> "Все остальные" не заморачиваются с тестами.

Главное правило разработчика свободного софта "тебе надо - тебе и делать" не забыл?  Это твои тесты, ты и заморачивайся.
К сожалению, помогать тебе в этом вопросе я больше не хочу.

(In reply to comment #9)
> Это твои тесты, ты и заморачивайся.
Мне понимать это как "ты что, самый умный что ли - тесты при сборке запускать?" ?

(In reply to comment #10)
> (In reply to comment #9)
> > Это твои тесты, ты и заморачивайся.
> Мне понимать это как "ты что, самый умный что ли - тесты при сборке запускать?"
> ?

Это понимать как "сам выясняй, почему тесты не проходят, сам готовь патч, сам объясняй апстриму, почему этот патч правильный, и тогда все лавры достанутся тебе".

(В ответ на комментарий №10)
> (In reply to comment #9)
> > Это твои тесты, ты и заморачивайся.
> Мне понимать это как "ты что, самый умный что ли - тесты при сборке запускать?"
> ?

Сперва было то же самое в форме просьбы:
#2: ldv@: "Пожалуйста, если у тебя есть возможность, то попробуй исправить
сам."

(In reply to comment #12)
> Сперва было то же самое в форме просьбы:
> #2: ldv@: "Пожалуйста, если у тебя есть возможность, то попробуй исправить
> сам."
У меня нет такой возможности.  Невозможно убедить неполноценного* мейнтейнера исправить баг в своём пакете.  И невозможно выслушивать нравоучения на ломаном английском от другого неполноценного* мейнтейнера по поводу точечек в Release и использования слова "NMU" в %changelog.

Впрочем, всё это уже неважно:

$ ssh git.alt help
ssh: Permission denied (publickey).

*) bug 24379 comment 3

(In reply to comment #13)
> (In reply to comment #12)
> > Сперва было то же самое в форме просьбы:
> > #2: ldv@: "Пожалуйста, если у тебя есть возможность, то попробуй исправить
> > сам."
> У меня нет такой возможности.

У меня тем более нет такой возможности, поскольку УМВР.

Я попробую разобраться.

Created attachment 4726 [details]
t.c

Вот тебе testcase.  Наслаждайся.

$ gcc -Wall -o t t.c `pkg-config --cflags --libs libxml-2.0`
$ ./t
usage: ./t XML [SET_ERR_FUNC]
$ ./t "<tag"                                                
SEC: 0x0xdeadbeef
$ ./t "<tag" 1
SEC: 0x(nil)

Created attachment 4728 [details]
a patch by Sergei Epiphanov

http://lists.altlinux.org/pipermail/devel/2010-December/187512.html и около

Created attachment 4731 [details]
libxml-error.patch

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

(In reply to comment #18)
> Я бы сделал вот так. Сломаться ничего не должно, но нужно проверить.
Как себя ведёт testcase?

Код у автора очень путанный. В идеале __xmlRaiseError() совсем бы переделать.

$ ./t "<tag" 
SEC: 0x0xdeadbeef

$ ./t "<tag" 1
SEC: 0x0xbadf00d

(In reply to comment #20)
> $ ./t "<tag" 
> SEC: 0x0xdeadbeef
> $ ./t "<tag" 1
> SEC: 0x0xbadf00d

Оба раза должен вызываться structured_error_callback (SEC) с параметром 0xdeadbeef (ctxt->userData).

(В ответ на комментарий №21)
> Оба раза должен вызываться structured_error_callback (SEC) с параметром
> 0xdeadbeef (ctxt->userData).

А когда должно вызываться structuredErrorFunc ?

xmlSetStructuredErrorFunc() - Function to reset the handler and the error context for out of context structured error messages.

Он и ресетит. На мой взгляд ошибка в том, что не была вызвана structuredErrorFunc().

В данном примере думаю что вообще не должно.  Потому как есть ctxt->sax->serror (или как там это поле называется).  Это видимо используется другими парсерами.

(В ответ на комментарий №24)
> В данном примере думаю что вообще не должно.  Потому как есть ctxt->sax->serror
> (или как там это поле называется).  Это видимо используется другими парсерами.

Судя по коду функции structured callback channel имеет приоритет над 
callback channel, который берётся из контекста.

Об этом написано тут:

http://git.gnome.org/browse/libxml2/commit/?id=1de382eb061b70b07040b3932c4b6082eb3ded79

error.c: when defined use the structured error report over any generic one

Created attachment 4732 [details]
testcase

Чуть-чуть параметризовал тесткейс.
Теперь можно проверить сочетания обработчиков.

Created attachment 4733 [details]
libxml-error.patch

Вот патч, который исправляет libxml2.

На самом деле для апстрима тут три патча (зависит от вменяемости апстрима). Дело в том, что авторы просто забывают чистить старый код и плодят одни костыли поверх других.

$ ./t false false
$

$ ./t true false
Setting xmlSetStructuredErrorFunc()
SEF: 0xbadf00d

$ ./t false true
Setting ctxt->sax->serror
SEC: 0xdeadbeef

$ ./t true true
Setting xmlSetStructuredErrorFunc()
Setting ctxt->sax->serror
SEC: 0xdeadbeef

Также умиляет:

$ grep -m1 -A6 test_xmlSetStructuredErrorFunc testapi.c
test_xmlSetStructuredErrorFunc(void) {
    int test_ret = 0;


    /* missing type support */
    return(test_ret);
}

$ stat -c '%s' testapi.c
1423394

Автор патчей другой. Ему и карты в руки.

В смысле ldv@?

Created attachment 4742 [details]
Исправленый testcase

В последнем testcase есть ошибки, прикладываю исправленный.

(In reply to comment #30)
> Created an attachment (id=4742) [details]
> Исправленый testcase

Сергей, техническое обсуждение уже давно переехало в кулуары,
а ссылки на testcase и патчи можно найти по адресу
https://bugzilla.gnome.org/show_bug.cgi?id=638618

libxml2-1:2.7.8-alt4 -> sisyphus:

* Wed Jan 12 2011 Dmitry V. Levin <ldv@altlinux> 1:2.7.8-alt4
- Fixed structured error handlers interoperability regression introduced
  between 2.7.3 and 2.7.4 libxml2 releases (closes: #24379).