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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
A number of issues have been raised after the fix, and this patch
tries to correct all of them, though most were related to
postvalidation.
https://bugzilla.gnome.org/show_bug.cgi?id=730290
and other reports on list, off-list and on Red Hat bugzilla
Cross-compiling the python bindings is a bit difficult today, as the
configure script will figure out the site packages dir
(PYTHON_SITE_PACKAGES) by either:
- Generating the path to the site-package target directories using
libdir, and see if it exists. As it is not possible to point to the
full path of the sysroot, since that will yield the wrong install
path, and that the directory does not neccessarily exist on the host,
this approach will not work.
- Fetch the site packages dir from the python interpreter as pointed to
by --with-python. Since this python interpreter will point to the
sysroot, the install dir generated will be inside the sysroot and thus
not work.
This patch approaches the problem by adding the possibility of
explicitly stating the install dir of the python packages, leaving it up
to the cross-compilation environment to specify it. The patch does not
affect the default case (non-cross compilation).
Signed-off-by: Jonas Eriksson <jonas.eriksson@enea.com>
Avoid freeing the currently set name until after having assigned the new name,
this allows one to call xmlNodeSetName (node, node->name + 1) to set the new
name of the node to a substring of the current name without introducing any
crash and without requiring an extra strdup().
The XPath engine tries to guarantee that every XPath function can pop
'nargs' non-NULL values off the stack. libxslt, for example, relies on
this assumption. But the check isn't thorough enough if there are errors
during the evaluation of arguments. This can lead to segfaults:
https://mail.gnome.org/archives/xslt/2013-December/msg00005.html
This commit makes the handling of function arguments more robust.
* Bail out early when evaluation of XPath function arguments fails.
* Make sure that there are 'nargs' arguments in the current call frame.
Middle dot pairs (as in [1]) turned to grave accents/backticks,
section signs to dollars (for compatibility with ASCII).
[1] http://www.w3.org/TR/xmlschema-1/
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
For https://bugzilla.gnome.org/show_bug.cgi?id=711149
In Function:
int xmlCharEncCloseFunc(xmlCharEncodingHandler *handler)
If the freed handler is any one of handlers[i] list, then it will make that
hanldlers[i] as dangling. This may lead to crash issues at places where
handlers is read.
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.
