IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For https://bugzilla.gnome.org/show_bug.cgi?id=719515
fixes htmlParseTryOrFinish to interpret HTML_PARSE_NODEFDTD,
and updates xmllint to actually pass --nodefdtd to the push
version of the HTML parser
For https://bugzilla.gnome.org/show_bug.cgi?id=712528
Related to https://bugzilla.redhat.com/show_bug.cgi?id=877567
There is a bug in xzlib.c which causes certain compressed XML files to fail to
load correctly. The code in xz_decomp which attempts to verify the checksum
and length of the expanded data fails if the checksum or length at the end of
the file crosses a 1024 byte boundary. It calls gz_next4 to get those two
values. This function uses the stream state in state->zstrm, but calls
xz_avail which uses the state->strm stream info. This causes gz_next4 to
signal a premature EOF if the data it is fetching crosses a 1024 byte boundary.
This means that liblzma’s Libs.private will be included in LZMA_LIBS if
linking the libraries statically, ensuring that there are no undefined
symbol errors from liblzma’s private libraries.
If pkg-config isn’t installed, or if liblzma.pc couldn’t be found, fall
back to using AC_CHECK_LIB as before. This will cause static linking to
fail, but that’s not a regression.
This does not introduce a compile time dependency on pkg-config.
https://bugzilla.gnome.org/show_bug.cgi?id=711026
If libxml2 is built and linked against liblzma, the latter needs to appear in
libxml2’s Libs.private pkg-config field, otherwise static linking against
libxml2 will fail due to unresolved liblzma symbols.
https://bugzilla.gnome.org/show_bug.cgi?id=711026
My attempt to optimize XPath expressions containing '//' caused a
regression reported in bug #695699. This commit disables the
optimization for expressions of the form '//foo[predicate]'.
https://bugzilla.gnome.org/show_bug.cgi?id=698550
Somehow the behaviour of the internal parser routine changed
slightly when encountering CR/LF, which led to a bug when
parsing document with non-ascii Names
The switch to xzlib had for consequence that the compression
level of the input was not gathered anymore in ctxt->input->buf,
then the parser compression flags was left to -1 and propagated
to the resulting document.
Fix the I/O layer to get compression detection in xzlib,
then carry it in the input buffer and the resulting document
This should fix
https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3456
https://bugzilla.gnome.org/show_bug.cgi?id=698582
xmlCleanupParser calls xmlCleanupGlobals() and then
xmlResetLastError() but the later reallocate the global
data freed by previous call. Just swap the two calls.
Reported by Petr Sumbera <petr.sumbera@oracle.com>
Two threads entering xmlInitializeDict concurently could lead
to a lockup due to multiple initializations of the lock used.
To avoid this problem move this to a new private function
called from xmlOnceInit() and deprecate the old initalizer.
Since threaded programs must call xmlInitParser() and this
will lead to dereference of private data and the call to
xmlOnceInit() guaranteed to be unique this should be safe now.
