CERTINFO was included upstream:
commit f6c335d63f2da025a0a3efde1fe59e3bb7189b70
Author: Patrick Monnerat <pm@datasphere.ch>
Date: Wed Oct 30 11:12:06 2013 +0100
NSS: support for CERTINFO feature
Change-Id: I83de2fd863f9387b83b5ebcbec70cbe6df7681d4
Reviewed-on: https://gerrit.libreoffice.org/9307
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
Includes some type conversion fixes.
Change-Id: I84f886e9f922acd780d46baea97f2d87c5ac700b
Reviewed-on: https://gerrit.libreoffice.org/9306
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
coverity seems to think that code execution can continue
after a coverity test fails, but it will effectively halt
and not trundle into the dereference of the tested-for-NULL
pointer, try a [+kill] on the fail method
Change-Id: I07c9a074b5681c367a31637c8af78d52a9c88d59
Fix error: 'gltf_get_model_center_pos' has C-linkage specified, but returns
user-defined type 'glm::vec3' (aka 'tvec3<mediump_float>') which is
incompatible with C.
I don't really understand the reason for the extern "C" use in
libgltf.h. After all, the header clearly is intended to be included from C++
code (after all, the use of 'extern "C"' is unconditional and it is not valid
in C), and the implementation of the functions is in C++. Also, we build
libgltf as a static library, so it can't be the case that we would need to
look up its symbols dynamically (when unmangled names would be better). But
maybe I am missing something.
Change-Id: I19f025610301f8c535178a83f4ab2e58455bad57
ba54eca1817e84a1f1d1beec312ca87b8b059649 replaces the existing -Wshadow
fixes with a GCC pragma, however we also want to be able to build with clang.
Change-Id: I522f3c549adf65b98522561ab7167258dfda48b5
plus further work in i18npool to make that build
adapt i18npool to ICU 53 upgrade, fdo#77071
Korean charset collator can't be built from ko_charset.txt because of
"The runtime code decomposes Hangul syllables on the fly, with recursive
processing but without making the Jamo pieces visible for matching. It
does not work with certain types of contextual mappings."
"While handling a Hangul syllable, contractions starting with Jamo L or
V would not see the following Jamo of that syllable." (this is where we
bail out already with the first syllable of ko_charset.txt)
Another condition to fail is described as "A contraction ending with
Jamo L or L+V would require generating Hangul syllables in
addTailComposites() (588 for a Jamo L), or decomposing a following
Hangul syllable on the fly, during contraction matching."
Excluded the file from the build for ICU >=53 and hope that ICU in the
mean time handles Korean collation correctly.
Additionally, ICU 53 took ages (if it would had finished at all) to
build the collator from zh_TW_charset.txt because of the \u#### escaped
notation. Converted the file's content to characters using
http://www.rishida.net/tools/conversion/
Change-Id: I64213214b4870e7077f72b95fee1ddc9782c2b21
Reviewed-on: https://gerrit.libreoffice.org/9204
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Also, for some reason building the endian check thing fails when trying to use
Clang for Android, so just hardcode it.
Change-Id: I04fb7ba4f88a1dc6a4e743b39e7c0cd19d7e3598
