> Oct 24 18:21:51 <sberg_> dtardon, why is libetonyek-0.1.7.tar.xz containing
> generated src/lib/KEY1Token.inc; is that by design or by mistake?
> Oct 24 18:23:32 <dtardon> sberg_, that's for windows
> Oct 24 18:24:15 <sberg_> dtardon, yuck; then you should at least have
> generated it with a gperf that no longer emits "register" ;)
> Oct 24 18:25:35 <dtardon> sberg_, bundled libetonyek is built as shared lib;
> the windows build is done as a Library, because the gcc wrapper for msvc
> cannot do shared libs. and it's easier to include the .inc files in the
> tarball than to re-create them using a CustomTarget inside libreoffice...
> Oct 24 18:25:58 <dtardon> sberg_, i'm using gperf on f27
> Oct 24 18:26:19 <dtardon> ... which is 3.1
> Oct 24 18:29:26 <sberg_> dtardon, then maybe they only fixed gperf past 3.1; I
> have a local checkout (that still claims to be 3.1, though) that came with a
> commit dropping that "register" usage
Change-Id: I6a3d965cedbe05582d9e42f5595876c19a1b91a6
- fixes a very minor CVE: CVE-2017-1000254
- the Windows nmakefiles we were previously using have been
removed, so we use the *other* Windows nmake build system now
- /EHs override is pointless, default /EHsc should work fine
- the macros defined in ExternalProject are not needed any more
- curl-msvc-schannel.patch.1: drop, not needed with new makefiles
- curl-osx.patch.1: none of it applies, presumably fixed upstream
Change-Id: I15c71b9c82c31d286d935b57543a1b0216123b66
Reviewed-on: https://gerrit.libreoffice.org/43724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Mapping ODF/librevenge tab to \t in HTML is not a great idea, as it's
ignorable whitespace. Go with NBSPs and a breakable space instead, that
is much closer visually (15 is just an arbitrary number, it's what MS
Word uses in its HTML export, LO Writer HTML export doesn't handle
this).
Adapt the empty paragraph case to also use NBSP for consistency.
Change-Id: I131802416499eb4f3a83a333b37ca20b59fcd56a
On one hand, we don't want to split inside a section as there might be
elements we need to close/open at split boundary, OTOH this is currently
not a problem as we don't produce any output for sections.
So remove the level management for sections (this way allowing headings
to split inside sections), let's get back to this when there is a
concept how e.g. multiple columns would be represented in EPUB.
Use case is when sections are used to just group paragraph together and
mark all of them read-only: in this case it's unexpected that headings
are handled differently to not-in-section ones.
Change-Id: If419624f8eec4a6f676ad7f186484c0035f62626
Reviewed-on: https://gerrit.libreoffice.org/43482
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...with versions of those files from the latest
<http://ftp.gnu.org/gnu/automake/automake-1.15.tar.xz>.
The current versions would fail for Flathub aarch64 builds.
Change-Id: I4b42fa7c04f0570b31170b72d8a42786ae1dc252
...with versions of those files from the latest
<http://ftp.gnu.org/gnu/automake/automake-1.15.tar.xz>.
The current versions would fail for Flathub aarch64 builds.
Change-Id: Id53754e989244134bdc533eb7f37e08c598b03e0
At least for me on Linux since LO 5.3, 'soffice
sw/qa/extras/rtfexport/data/fdo72031.rtf' shows "Å" (rendered in "DejaVu Sans")
instead of "⊕" (rendered in "Standard Symbols L"). That's presumably because
47ea13ef8d "Kill the old Unix layout engines"
removed support for Type 1 fonts (see "Ignore Type 1 fonts" in
FontCfgWrapper::addFontSet, vcl/unx/generic/fontmanager/fontconfig.cxx), and my
(Fedora 25) /usr/share/fonts/default/Type1/s050000l.pfb "Standard Symbols L" is
a Type 1 font. So we fell back to fontconfig's generic (weak) suggestion of
"DejaVu Sans" as a substitute for "Symbol".
So extend our fc_local.conf to suggest our "OpenSymbol" as a substitute for
"Symbol".
As that fc_local.conf was originally brought along by --with-fonts, which is
enabled by default but can be disabled, compilation of fc_local.conf from the
various snippets is moved to postprocess.
macOS and Windows were never affected, as they both come with a "Symbol" font
installed in the system. (And we don't install fc_local.conf on Windows at
all.)
Change-Id: I8d6d87f24974577fd66f5f3989f606237ebb3d75
Reviewed-on: https://gerrit.libreoffice.org/42670
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Compiling against the 10.13 SDK with --with-macosx-version-min-
required set to 10.9 or 10.10 (or defaulted, meaning 10.9) causes a
compilation error now. Earlier SDKs did not catch it if you were using
connectx() even if targeting pre-10.11.
Try the approach from https://github.com/curl/curl/pull/1336/commits .
Change-Id: I7cac294931c8afa6ff26a6ca9cf4491aff249de0
...<https://dl.bintray.com/boostorg/release/1.65.1/source/boost_1_65_1.tar.bz2>.
One reason to upgrade is that with 1.63 CppunitTest_tools_test started to fail
with -fsanitize=signed-integer-overflow after
331e2e5ed3 "long->sal_Int32 in Fraction",
> workdir/UnpackedTarball/boost/boost/integer/common_factor_rt.hpp:300:5: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
> #0 0x7f0f99bea71b in boost::integer::detail::gcd_optimal_evaluator<int>::operator()(int, int) const workdir/UnpackedTarball/boost/boost/integer/common_factor_rt.hpp:300:5
> #1 0x7f0f99bea52a in int boost::integer::detail::gcd_optimal<int>(int const&, int const&) workdir/UnpackedTarball/boost/boost/integer/common_factor_rt.hpp:372:16
> #2 0x7f0f99be7d70 in int boost::integer::gcd<int>(int const&, int const&) workdir/UnpackedTarball/boost/boost/integer/common_factor_rt.hpp:435:12
> #3 0x7f0f99be7620 in boost::rational<int>::normalize() workdir/UnpackedTarball/boost/boost/rational.hpp:559:17
> #4 0x7f0f99bdff29 in rational_FromDouble(double) tools/source/generic/fract.cxx:449:12
> #5 0x7f0f99bdf8b4 in Fraction::Fraction(double) tools/source/generic/fract.cxx:93:25
> #6 0x7f0f9a1bb987 in tools::FractionTest::testMinLongDouble() tools/qa/cppunit/test_fract.cxx:79:18
> #7 0x7f0f9a1bddd2 in void std::_Bind<std::_Mem_fn<void (tools::FractionTest::*)()> (tools::FractionTest*)>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) /usr/lib/gcc/x86_64-redhat-linux/6.4.1/../../../../include/c++/6.4.1/functional:933:11
> #8 0x7f0f9a1bdbe9 in void std::_Bind<std::_Mem_fn<void (tools::FractionTest::*)()> (tools::FractionTest*)>::operator()<, void>() /usr/lib/gcc/x86_64-redhat-linux/6.4.1/../../../../include/c++/6.4.1/functional:991:17
> #9 0x7f0fa5eb53b0 in CppUnit::TestCaseMethodFunctor::operator()() const workdir/UnpackedTarball/cppunit/src/cppunit/TestCase.cpp:32:5
> #10 0x7f0fa5e1bd1b in CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) workdir/UnpackedTarball/cppunit/src/cppunit/DefaultProtector.cpp:15:12
> #11 0x7f0fa5e8653d in CppUnit::ProtectorChain::ProtectFunctor::operator()() const workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25
> #12 0x7f0fa5e7fb7c in CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:86:18
> #13 0x7f0fa5f17fe0 in CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) workdir/UnpackedTarball/cppunit/src/cppunit/TestResult.cpp:182:28
> #14 0x7f0fa5eb398c in CppUnit::TestCase::run(CppUnit::TestResult*) workdir/UnpackedTarball/cppunit/src/cppunit/TestCase.cpp:91:13
> #15 0x7f0fa5eb7887 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:64:30
> #16 0x7f0fa5eb6a78 in CppUnit::TestComposite::run(CppUnit::TestResult*) workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:23:3
> #17 0x7f0fa5eb7887 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:64:30
> #18 0x7f0fa5eb6a78 in CppUnit::TestComposite::run(CppUnit::TestResult*) workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:23:3
> #19 0x7f0fa5f46655 in CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) workdir/UnpackedTarball/cppunit/src/cppunit/TestRunner.cpp:47:27
> #20 0x7f0fa5f16a66 in CppUnit::TestResult::runTest(CppUnit::Test*) workdir/UnpackedTarball/cppunit/src/cppunit/TestResult.cpp:149:9
> #21 0x7f0fa5f475c6 in CppUnit::TestRunner::run(CppUnit::TestResult&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) workdir/UnpackedTarball/cppunit/src/cppunit/TestRunner.cpp:96:14
> #22 0x534a01 in (anonymous namespace)::ProtectedFixtureFunctor::run() const sal/cppunittester/cppunittester.cxx:316:20
> #23 0x532ac4 in sal_main() sal/cppunittester/cppunittester.cxx:466:20
> #24 0x5324f2 in main sal/cppunittester/cppunittester.cxx:373:1
> #25 0x7f0fa436e430 in __libc_start_main /usr/src/debug/glibc-2.24-66-gd5a4092c36/csu/../csu/libc-start.c:289
> #26 0x4387b9 in _start (workdir/LinkTarget/Executable/cppunittester+0x4387b9)
Change-Id: Id1c3b216ee18c1d622768dc960ac257d5415c664
Reviewed-on: https://gerrit.libreoffice.org/42427
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
If invoked with --build=x86_64-unknown-linux-gnu, its configure will use
the same for the host platform, so pass --host too.
Change-Id: I4548c48db1811f31c7c78b2c0c74c1abb79784ba
