Re: Build failure on x86 linux: undefined reference to `__atomic_load'

[Luke Benes]

Noel,
I can successfully build LO on i686 with 
LDFLAGS="-latomic"

This is overkill. I think patch is needed for the cuckoo module that you added 
in https://cgit.freedesktop.org/libreoffice/core/commit/?id=3749d9af3745
for IA-32 clang. I attempted to do this but I'm not family with how this 
patching/external system works. If you could give me some tips or something to 
try, I'd be happy to test it out for you.  

-Luke

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

[Luke Benes]

Rene,
> Or clang needs -latomic and gcc not.
Yes, it does. Looks like a known bug in clang:
 https://bugs.llvm.org/show_bug.cgi?id=45785

Building with "-DCMAKE_CXX_FLAGS=-latomic", resolves the undefined reference to 
`__atomic_load' and allows the build to complete successfully. However, it 
causes clang to spam 
clang-12: warning: -latomic: 'linker' input unused 
[-Wunused-command-line-argument]

when building.

-Luke

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

[Luke Benes]

Thanks for helping me to try to reproduce this. I'm building with clang-14. Are 
you building with gcc? I've confirmed that when I built libcuckoo from 
https://github.com/efficient/libcuckoo with clang, I get a similar failure to 
the initial failure. When I build it with gcc-11, the build is successful. 

At this point, it appears to be a bug in clang. 

-Luke


[ 14%] Linking CXX executable hellohash
/usr/bin/ld: CMakeFiles/hellohash.dir/hellohash.cc.o: in function 
`std::atomic::load(std::memory_order) const':
hellohash.cc:(.text._ZNKSt6atomicIdE4loadESt12memory_order[_ZNKSt6atomicIdE4loadESt12memory_order]+0x39):
 undefined reference to `__atomic_load'
clang-14: error: linker command failed with exit code 1 (use -v to see 
invocation)
make[2]: *** [examples/CMakeFiles/hellohash.dir/build.make:97: 
examples/hellohash] Error 1
make[1]: *** [CMakeFiles/Makefile2:358: examples/CMakeFiles/hellohash.dir/all] 
Error 2

$ clang --version
clang version 14.0.0 (https://github.com/llvm/llvm-project.git 
c78ed20784ee7ffb60b0879197e34225325aafd0)
Target: i686-pc-linux-gnu

Build failure on x86 linux: undefined reference to `__atomic_load'

[Luke Benes]

Noel,
After commit 3749d9af3745c0eaff7239e379578e4e2af89e9d
tdf#130795 use concurrent hashmap in SharedStringPool
On both OpenSUSE Tumbleweed and Arch 32, I see the build failure below. Would 
you like any additional debugging info? 

-Luke

[DEP] LNK:Library/libsvllo.so
[LNK] Library/libsvllo.so
/usr/lib/gcc/i586-suse-linux/11/../../../../i586-suse-linux/bin/ld: 
/core/workdir/CxxObject/svl/source/misc/sharedstringpool.o: in function 
`libcuckoo::cuckoohash_map<_rtl_uString*, std::pair, svl::(anonymous namespace)::HashFunction, svl::(anonymous 
namespace)::EqualsFunction, std::allocator > >, 4u>::cuckoo_status 
libcuckoo::cuckoohash_map<_rtl_uString*, std::pair, svl::(anonymous namespace)::HashFunction, svl::(anonymous 
namespace)::EqualsFunction, std::allocator > >, 
4u>::cuckoo_fast_double, 
std::integral_constant >(unsigned int)':
sharedstringpool.cxx:(.text+0x14ec): undefined reference to `__atomic_load'
/usr/lib/gcc/i586-suse-linux/11/../../../../i586-suse-linux/bin/ld: 
sharedstringpool.cxx:(.text+0x17f6): undefined reference to `__atomic_load'
clang-12: error: linker command failed with exit code 1 (use -v to see 
invocation)
make[1]: *** [/core/svl/Library_svl.mk:20: /core/instdir/program/libsvllo.so] 
Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:288: build] Error 2

Re: freetype2 2.11.0-1.1 Update Breaks on OpenSUSE Tumbleweed

[Luke Benes]

The issue was fixed by 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a0edcc68f94915a78fcc08e70d2cdd752abd9ebb

Thanks Luboš!

Re: freetype2 2.11.0-1.1 Update Breaks on OpenSUSE Tumbleweed

[Luke Benes]

This also breaks the built on Gentoo and has been reported there too(see 
below). Should we patch our tarball or just update it? 

Luboš,
You've been the most active maintainer. Any thoughts? 

-Luke

From: bugzilla_nore...@suse.com 
Sent: Sunday, August 22, 2021 2:06 PM
Subject: [Bug 1189444] freetype2 2.11.0-1.1 Update Breaks LibreOffice Build

Comment#2  on bug 
1189444 from Markéta Machová

I am aware of this. See https://bugs.gentoo.org/803467 for more info, newer
skia needs to be bundled with LO (you can find some patches there). But...
well, I can take skia tarball, patch it and just hardcode it there (without the
download link), but I find it a bit dirty.

freetype2 2.11.0-1.1 Update Breaks on OpenSUSE Tumbleweed

[Luke Benes]

After updating openSUSE Tumbleweed  20210726-0 -> 20210810-0,
I can not longer build LibreOffice. The issue is most likely the update of to 
freetype2-devel-2.10 -> 2.11

I filed a bug report at:
https://bugzilla.opensuse.org/show_bug.cgi?id=1189444

freetype2 2.11 is still in testing on arch:
https://archlinux.org/packages/extra/x86_64/freetype2/

The error from the build log is below. Anything else I should do here? Look 
like a freetype2 issue or do we just need to update to use the new name?

-Luke



[CXX] workdir/UnpackedTarball/skia/src/ports/SkFontHost_FreeType_common.cpp
/core/workdir/UnpackedTarball/skia/src/ports/SkFontHost_FreeType_common.cpp:668:14:
 error: use of undeclared identifier 'FT_COLR_PAINTFORMAT_TRANSFORMED'; did you 
mean 'FT_COLR_PAINTFORMAT_TRANSFORM'?
case FT_COLR_PAINTFORMAT_TRANSFORMED: {
 ^~~
 FT_COLR_PAINTFORMAT_TRANSFORM
/usr/include/freetype2/freetype/ftcolor.h:505:5: note: 
'FT_COLR_PAINTFORMAT_TRANSFORM' declared here
FT_COLR_PAINTFORMAT_TRANSFORM   = 12,
^
/core/workdir/UnpackedTarball/skia/src/ports/SkFontHost_FreeType_common.cpp:669:60:
 error: no member named 'transformed' in 'FT_COLR_Paint_::(unnamed union at 
/usr/include/freetype2/freetype/ftcolor.h:1327:5)'; did you mean 'transform'?
SkMatrix transform = ToSkMatrix(colrv1_paint.u.transformed.affine);
   ^~~
   transform
/usr/include/freetype2/freetype/ftcolor.h:1335:31: note: 'transform' declared 
here
  FT_PaintTransform   transform;
  ^
/core/workdir/UnpackedTarball/skia/src/ports/SkFontHost_FreeType_common.cpp:763:14:
 error: use of undeclared identifier 'FT_COLR_PAINTFORMAT_TRANSFORMED'; did you 
mean 'FT_COLR_PAINTFORMAT_TRANSFORM'?
case FT_COLR_PAINTFORMAT_TRANSFORMED:
 ^~~
 FT_COLR_PAINTFORMAT_TRANSFORM
/usr/include/freetype2/freetype/ftcolor.h:505:5: note: 
'FT_COLR_PAINTFORMAT_TRANSFORM' declared here
FT_COLR_PAINTFORMAT_TRANSFORM   = 12,
^
/core/workdir/UnpackedTarball/skia/src/ports/SkFontHost_FreeType_common.cpp:768:74:
 error: no member named 'transformed' in 'FT_COLR_Paint_::(unnamed union at 
/usr/include/freetype2/freetype/ftcolor.h:1327:5)'; did you mean 'transform'?
colrv1_traverse_paint(canvas, palette, face, 
paint.u.transformed.paint);
 
^~~
 
transform
/usr/include/freetype2/freetype/ftcolor.h:1335:31: note: 'transform' declared 
here
  FT_PaintTransform   transform;
  ^
[CXX] workdir/UnpackedTarball/skia/src/ports/SkFontMgr_fontconfig_factory.cpp
4 errors generated.
make[1]: *** [/core/solenv/gbuild/LinkTarget.mk:357: 
/core/workdir/GenCxxObject/UnpackedTarball/skia/src/ports/SkFontHost_FreeType_common.o]
 Error 1

JunitTest_ucb_complex test hangs after 739aaf02db335 on Linux x86

[Luke Benes]

After https://cgit.freedesktop.org/libreoffice/core/commit/?id=739aaf02db33
osl::Mutex->std::mutex in bridges/except

On both Arch Linux 32 and OpenSUSE Tumbleweed i686, 'make check' now hangs on 
JunitTest_ucb_complex. I can consistently reproduce this failure with both 
clang 13 and gcc 11.  Below is the log. 

Noel, 
Any idea why this might cause a deadlock or infinite loop? What further 
debugging or system info do you need?   

-Luke


[JUT] ucb_complex
JUnit version 4.13
setUpConnection()
.ftp://noname:nopasswd@*nohost.invalid
now executing open
to rerun just this failed test without all others, run:

make JunitTest_ucb_complex

cd into the module dir to run the tests faster
Or to do interactive debugging, run two shells with:

make debugrun
make gb_JunitTest_DEBUGRUN=T JunitTest_ucb_complex

make[1]: *** [/core/solenv/gbuild/JunitTest.mk:40: 
/core/workdir/JunitTest/ucb_complex/done] Error 1
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word_prepostdash.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/edit_word.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/line.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/sent.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/edit_word_hu.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word_hu.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word_he.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/edit_word_he.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/count_word.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word_hu.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word_nodash.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/count_word.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word_prepostdash.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word_he.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/line.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/edit_word.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/edit_word_hu.brk'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/dict_word_nodash.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/sent.txt'
make[1]: *** Deleting intermediate file 
'/core/workdir/CustomTarget/i18npool/breakiterator/edit_word_he.txt'
make: *** [Makefile:169: JunitTest_ucb_complex] Interrupt

> uname -a
Linux linux-645r 5.13.4-1-pae #1 SMP Thu Jul 22 15:55:06 UTC 2021 (91a0cca) 
i686 i686 i386 GNU/Linux
> lsb_release -a
Description:openSUSE Tumbleweed
Release:20210726
> clang --version
clang version 13.0.0 (https://github.com/llvm/llvm-project.git 
eacbd7d25ae08465bcef4fb6d3b86c7dddb2d64f)
Target: i686-pc-linux-gnu
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

[Luke Benes]

This was resolved after a distro update of openSUSE Tumbleweed
20210709-0 -> 20210725-0
which updated:
mozilla-nss-3.64 -> mozilla-nss-3.66

I no longer need "--with-system-nss"

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure, Error: no matching function for call on x86 Linux

[Luke Benes]

Yes, a 'make check' passes with "stack_guard_gap=1" kernel parameter for the 
java bug and clang 12.

I also see the off-by-one gcc test failures. I think these started with gcc 8 
or 9. We probably have to turn off some floating point math optimization for 
gcc i686.

-Luke






From: Rene Engelhard 
Sent: Friday, July 16, 2021 1:20 AM
To: Luke Benes; Libreoffice Dev List
Subject: Re: Build failure, Error: no matching function for call on x86 Linux

Hi,

Am 15.07.21 um 15:10 schrieb Luke Benes:
> Build succeeds now and tests pass on Arch 32. Thanks!

Tests pass?

uicheck does with two patches not upstream[1], but junit crashes with
segfault and then other mosly off-by one cppunit test failures here
which are i386 only.

Regards,


Rene


[1]
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/debian-experimental-7.2/patches/fix-uicheck-tests-on-i386.patch

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure, Error: no matching function for call on x86 Linux

[Luke Benes]

Rene fixed this issue with:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=51754ca5349d

Build succeeds now and tests pass on Arch 32. Thanks!
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

[Luke Benes]

Builds are now failing on the rolling distro OpenSUSE Tumbleweed After the 
latest update, both gcc and clang builds and both both x86-64 and i686 
architectures fail.  

Seems to be caused by caused by:
 java.io.IOException: /core/instdir/program/libnssutil3.so: version 
`NSSUTIL_3.59' not found (required by /usr/lib64/libnss3.so)

mozilla-nss should provide  libnss3.so(NSS_3.59)
https://opensuse.pkgs.org/tumbleweed/mozilla-x86_64/mozilla-nss-32bit-3.64-1.6.x86_64.rpm.html

Here is my upgrade log: https://controlc.com/79ec2502
Below is my build log.

If I add, "--with-system-nss" to my autogen.input file, the build succeeds 
without any issue.

Any thoughts has to how to fix this or ideas on the root cause? 

-Luke

[CUT] sd_uimpress
[DEP] LNK:CppunitTest/libtest_sd_import_tests.so
[LNK] CppunitTest/libtest_sd_import_tests.so
...
[_RUN_] SdImportTest::testDocumentLayout
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.base/java.util.UUID.randomUUID(UUID.java:147)
at 
org.probatron.officeotron.sessionstorage.Store.putZippedResource(Unknown Source)
at org.probatron.officeotron.CommandLineSubmission.(Unknown 
Source)
at org.probatron.officeotron.Driver.main(Unknown Source)
Caused by: java.security.ProviderException: Could not initialize NSS
at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:228)
at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:112)
at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:109)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:109)
at 
java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:251)
at 
java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:242)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:242)
at 
java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:222)
at 
java.base/sun.security.jca.ProviderList.getProvider(ProviderList.java:266)
at java.base/sun.security.jca.ProviderList$3.get(ProviderList.java:156)
at java.base/sun.security.jca.ProviderList$3.get(ProviderList.java:151)
at java.base/java.util.AbstractList$Itr.next(AbstractList.java:371)
at 
java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:264)
at java.base/java.security.SecureRandom.(SecureRandom.java:219)
at java.base/java.util.UUID$Holder.(UUID.java:101)
... 4 more
Caused by: java.io.IOException: /core/instdir/program/libnssutil3.so: version 
`NSSUTIL_3.59' not found (required by /usr/lib64/libnss3.so)
at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.nssLoadLibrary(Native 
Method)
at 
jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:220)
at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:223)
... 20 more
/core/test/source/bootstrapfixture.cxx:232:SdImportTest::testDocumentLayout
equality assertion failed
- Expected: 0
- Actual  : 256
- failed to execute: sh /core/bin/officeotron.sh /tmp/lu29374sgbpuh.tmp > 
/tmp/lu29374sgbpuj.tmp


SdImportTest::testDocumentLayout finished in: 2754ms
[_RUN_] SdImportTest::testCustomSlideShow
SdImportTest::testCustomSlideShow finished in

...

[_RUN_] SdImportTest::testTdf103347
SdImportTest::testTdf103347 finished in: 68ms
bootstrapfixture.cxx:232:Assertion
Test name: SdImportTest::testDocumentLayout
equality assertion failed
- Expected: 0
- Actual  : 256
- failed to execute: sh /core/bin/officeotron.sh /tmp/lu29374sgbpuh.tmp > 
/tmp/lu29374sgbpuj.tmp


Failures !!!
Run: 108   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:

make CppunitTest_sd_import_tests CPPUNITTRACE="gdb --args"
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Build failure, Error: no matching function for call on x86 Linux

[Luke Benes]

Mert,
After commit 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=67277595902d
Unit tests for .uno:MoveShapeHandle command

Fails with the error below on both Arch 32 and OpenSUSE i686. Any idea why this 
would fail on 32-bit linux? 

-Luke


[CXX] sd/qa/unit/tiledrendering/tiledrendering.cxx
In file included from /core/sd/qa/unit/tiledrendering/tiledrendering.cxx:10:
In file included from /core/sd/qa/unit/tiledrendering/../sdmodeltestbase.hxx:15:
In file included from /core/include/test/bootstrapfixture.hxx:15:
In file included from /core/include/vcl/salctype.hxx:25:
In file included from /core/include/vcl/graph.hxx:26:
In file included from /core/include/vcl/bitmapex.hxx:26:
In file included from /core/include/tools/color.hxx:24:
In file included from /core/include/com/sun/star/uno/Any.hxx:35:
In file included from /core/include/com/sun/star/uno/Any.h:33:
/core/include/cppu/unotype.hxx:300:16: error: no matching function for call to 
'cppu_detail_getUnoType'
return cppu_detail_getUnoType(static_cast< T1 * >(0));
   ^~
/core/include/cppu/unotype.hxx:325:34: note: in instantiation of member 
function 'cppu::UnoType::get' requested here
return ::cppu::UnoType< T >::get();
 ^
/core/include/com/sun/star/uno/Any.hxx:70:17: note: in instantiation of 
function template specialization 'cppu::getTypeFavourUnsigned' requested 
here
::cppu::getTypeFavourUnsigned().getTypeLibType(),
^
/core/include/com/sun/star/uno/Any.hxx:234:12: note: in instantiation of 
function template specialization 'com::sun::star::uno::Any::Any' requested 
here
return Any(value);
   ^
/core/sd/qa/unit/tiledrendering/tiledrendering.cxx:2643:32: note: in 
instantiation of function template specialization 
'com::sun::star::uno::makeAny' requested here
{"HandleNum", uno::makeAny(id)},
   ^
/core/include/cppu/unotype.hxx:124:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const ::cppu::UnoVoidType *' for 
1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::cppu::UnoVoidType const *) {
^
/core/include/cppu/unotype.hxx:129:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const bool *' for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER bool const *) {
^
/core/include/cppu/unotype.hxx:134:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const sal_Bool *' (aka 'const 
unsigned char *') for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER sal_Bool const *) {
^
/core/include/cppu/unotype.hxx:139:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const ::sal_Int8 *' (aka 'const 
signed char *') for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::sal_Int8 const *) {
^
/core/include/cppu/unotype.hxx:144:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const ::sal_Int16 *' (aka 'const 
short *') for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::sal_Int16 const *) {
^
/core/include/cppu/unotype.hxx:149:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const 
::cppu::UnoUnsignedShortType *' for 1st argument
cppu_detail_getUnoType(
^
/core/include/cppu/unotype.hxx:159:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const sal_uInt16 *' (aka 'const 
unsigned short *') for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER sal_uInt16 const *) {
^
/core/include/cppu/unotype.hxx:165:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const ::sal_Int32 *' (aka 'const 
long *') for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::sal_Int32 const *) {
^
/core/include/cppu/unotype.hxx:170:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const ::sal_uInt32 *' (aka 
'const unsigned long *') for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::sal_uInt32 const *) {
^
/core/include/cppu/unotype.hxx:176:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const ::sal_Int64 *' (aka 'const 
long long *') for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::sal_Int64 const *) {
^
/core/include/cppu/unotype.hxx:181:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const ::sal_uInt64 *' (aka 
'const unsigned long long *') for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::sal_uInt64 const *) {
^
/core/include/cppu/unotype.hxx:187:1: note: candidate function not viable: no 
known conversion from 'T1 *' (aka 'int *') to 'const float *' for 1st argument
cppu_detail_getUnoType(SAL_UNUSED_PARAMETER float const *) {
^
/core/include/cppu/unotype.hxx:192:1: note: candidate function 

Re: CppCheck Report on vm140 Not Running

[Luke Benes]

Whether Maaten misremembered, there was a net spit, or
problem with your search, he did reach out to the dev list: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Automated-cppcheck-reports-not-running-tt4290186.html
 
 
> I'm very much against re-hooking a box 
 
A box that ran for years without any issues. When Maartin informed
us that he lost his vm140 ssh-key in his very first email weeks ago, you said 
all you could do is reboot it from the hypervisor. Why that was fix acceptable 
at the time?  How is having a vm with a lost ssh key preferable to resetting 
it?  

I was told to file a Redmond ticket, where again, no one from infra mentioned 
this, only the issue with credentials.   
https://redmine.documentfoundation.org/issues/3520#change-21592 
 
It’s strange that all these emails and 2 weeks later, this
new excuse comes out of nowhere. We are volunteers. Poor communication and 
artificial roadblocks only discourages outside help.  
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppCheck Report on vm140 Not Running

[Luke Benes]

Cloph,

> But given that the job had stopped so many months ago without anyone 
> complaining

At the time, Maarten reported this on the dev IRC, infra IRC, and the mailing 
list.  At the time, I assumed someone from infra would take care of it. 

> Recreating it is always an option 

Why can't you reset the user's password? In the time, it took you to write that 
email, I could have rebooted into recovery mode, dropped to root shell, and 
reset the root password on the boxes I manage. This is a 30-second procedure.  
Every hypervisor has some method to allow admins to boot guests into single 
user.



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppCheck Report on vm140 Not Running

[Luke Benes]

> Yes, at least that's how I use these linters.

How common is this? A check of  
> git rev-list --all --grep='cppcheck' -i   --count
1847

Grepping shows a good mix of usual suspects and many GSoC students looking for 
easy hacks. More importantly there were almost none since the CppCheck script 
stopped working. 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppCheck Report on vm140 Not Running

[Luke Benes]

> I'm more interested in running such tools locally

Depending on the configuration, cppcheck scans can take 8+ hours to run. This 
can be greatly reduce with parallel checks at the cost of several checks being 
disabled. 

> The other problem with cppcheck is that it doesn't build on an existing
c++ parser from a compiler

https://www.kickstarter.com/projects/3300446/cppcheck-clang-import

They are working on a clang AST importer. Experimental support has already 
landed. 

> its signal/noise ratio is lower than e.g. coverity or clang-tidy.

A couple of years ago, I investigated this issue and found that cppcheck is 
missing include locations. When I provided those, the number of errors reported 
dropped from 9000+ to several hundred. 

https://wiki.documentfoundation.org/Development/Cppcheck

At the time I manually generated include paths. Another option would be to use 
the ide-integration scripts to generate these. 
 
-Luke

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppCheck Report on vm140 Not Running

[Luke Benes]

I spoke to the author of the cppcheck script, Maarten Hoes, about this issue. 
We would like to know why no one has responded to our emails about the cppcheck 
service being down. Are devs not interested in cppcheck's results, is it the 
high false positives, or is it that no one knows how to help get it back online?

Maarten has lost his ssh-key to vm140 and needs support from the tdf 
infrastructure team to get back in. IF there is sufficient developer 
interest,he has generously offered to setup a new vm for the script. I too 
would be willing, if I could get a tdf infra team commitment to provide minimal 
support. (Hours of volunteered time were wasted on a ESC approved 32-bit linux 
tinderbox, because I could not get my quested answered on registering a lode 
tinderbox after I got the manual builds working)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppCheck Report on vm140 Not Running

[Luke Benes]

I dug a little deeper and the last error report has an "unexpected end of file" 
when I tried to decompress it.[1]   Is vm140 out of free space? 

-Luke

[1] https://dev-builds.libreoffice.org/cppcheck_reports/cppcheck_reports.tar.bz2
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppCheck Report on vm140 Not Running

[Luke Benes]

The script to email the dev list with the updated CppCheck Report at has 
stopped running. 

Could we get this restarted? While it was not perfect, a quick grep of the 
commit log shows hundred of fixed bugs that it helped highlight. 

The script was running on host vm140 as 
/home/buildslave/source/dev-tools/cppcheck/cppcheck-report.sh  And found at 
https://gerrit.libreoffice.org/plugins/gitiles/dev-tools/+/master/cppcheck/cppcheck-report.sh


Thanks,

-Luke


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Unit Tests failing when built with clang 12

[Luke Benes]

The UITest_calc_tests9 failure with clang 12/13  was fixed by 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9ccbf716ba16
Fix null-pointer-use

Thanks Stephan!


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Unit Tests failing when built with clang 12

[Luke Benes]

Sounds like there is a headless or distro dependent aspect of this bug too. I 
can reproduce this on both my i686 openSUSE Tumbleweed (32-bit) laptop and on 
my x86-64 openSUSE Tumbleweed desktop. This issue has not been fixed in clang 
13 as today's build 402f2cae7dcab also fails. I also was able to reproduce the 
failures with this autogen.input: 

--enable-optimized
--disable-debug
--disable-dbgutil
CC=clang
CXX=clang++

What distro is this working on? I can try that in a VM.

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Unit Tests failing when built with clang 12

[Luke Benes]

The  recently added Unit Test test_tdf131000
https://cgit.freedesktop.org/libreoffice/core/commit/?id=df33714f0eca
fails with clang 12 but not with gcc 10 or clang 11. I bisected this regression 
to this change in clang:

https://github.com/llvm/llvm-project/commit/69cd776e1ee79e72ccbdad30749eac04579715ee
[CodeGen] Apply 'nonnull' and 'dereferenceable(N)' to 'this' pointer


Does this look like undefined behavior on our end or a bug in clang? The build 
log is below:

-Luke


[UIT] calc_tests9
False
test_tdf131000 (forms.Forms) ...

Fatal exception: Signal 11
Stack:
/core/instdir/program/libuno_sal.so.3(+0x37ac1)[0xb7f5fac1]
/core/instdir/program/libuno_sal.so.3(+0x379b3)[0xb7f5f9b3]
linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xb7f8c560]
/core/instdir/program/libfwklo.so(+0x17e32a)[0xb6b3a32a]
/core/instdir/program/libfwklo.so(+0x182e5a)[0xb6b3ee5a]
/core/instdir/program/libsvxlo.so(+0x280df4)[0xb604ddf4]
/core/instdir/program/libsvxlo.so(+0x281082)[0xb604e082]
/core/instdir/program/libsvxlo.so(+0x28120f)[0xb604e20f]
/core/instdir/program/libsfxlo.so(+0x1738b4)[0xb64208b4]
/core/instdir/program/libsfxlo.so(+0x17385b)[0xb642085b]
/core/instdir/program/libsfxlo.so(+0x1525bb)[0xb63ff5bb]
/core/instdir/program/libsfxlo.so(+0x152161)[0xb63ff161]
/core/instdir/program/libsfxlo.so(_ZN11SfxBindings6UpdateEt+0x10e)[0xb63ff8fa]
/core/instdir/program/libsfxlo.so(+0x1582e2)[0xb64052e2]
/core/instdir/program/libsfxlo.so(_ZN13SfxDispatcher8Execute_ER8SfxShellRK7SfxSlotR10SfxRequest11SfxCallMode+0x8c)[0xb64067c0]
/core/instdir/program/libsfxlo.so(+0x154227)[0xb6401227]
/core/instdir/program/libsfxlo.so(+0x197f7e)[0xb6444f7e]
/core/instdir/program/libsfxlo.so(+0x196baf)[0xb6443baf]
/core/instdir/program/libsfxlo.so(+0x198644)[0xb6445644]
/core/instdir/program/libcomphelper.so(_ZN10comphelper15dispatchCommandERKN3rtl8OUStringERKN3com3sun4star3uno9ReferenceINS6_5frame6XFrameEEERKNS7_8SequenceINS6_5beans13PropertyValueEEERKNS8_INS9_23XDispatchResultListenerEEE+0x2e3)[0xb71307b7]
/core/instdir/program/libcomphelper.so(_ZN10comphelper15dispatchCommandERKN3rtl8OUStringERKN3com3sun4star3uno8SequenceINS6_5beans13PropertyValueEEERKNS7_9ReferenceINS6_5frame23XDispatchResultListenerEEE+0xb0)[0xb71309f0]
/core/instdir/program/libvcllo.so(+0x656b7e)[0xb494db7e]
/core/instdir/program/libvcllo.so(+0x6596e3)[0xb49506e3]
/core/instdir/program/libvcllo.so(+0x659c56)[0xb4950c56]
/core/instdir/program/libgcc3_uno.so(+0x7e35)[0xb7e38e35]
/core/instdir/program/libgcc3_uno.so(+0x77c8)[0xb7e387c8]
/core/instdir/program/libgcc3_uno.so(+0x7419)[0xb7e38419]
/core/instdir/program/libbinaryurplo.so(+0x11de7)[0xae00fde7]
/core/instdir/program/libbinaryurplo.so(+0x115f8)[0xae00f5f8]
/core/instdir/program/libbinaryurplo.so(+0x163c8)[0xae0143c8]
/core/instdir/program/libuno_cppu.so.3(+0x564b)[0xb706964b]
/core/instdir/program/libuno_cppu.so.3(+0x6913)[0xb706a913]
/core/instdir/program/libuno_cppu.so.3(+0x6a49)[0xb706aa49]
/core/instdir/program/libuno_cppu.so.3(+0x6e7e)[0xb706ae7e]
/core/instdir/program/libuno_sal.so.3(+0x3a686)[0xb7f62686]
/lib/libpthread.so.0(+0x7e77)[0xb78bce77]
/lib/libc.so.6(clone+0x66)[0xb7d3c4d6]
OfficeConnection: connecting to: 
uno:pipe,name=pytest1bf07fa8-791f-11eb-8141-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
NoConnectException: sleeping...
['OnLoad']
OnLoadFinished
['OnLoad']
OnTitleChanged
['OnLoad']
OnFocus
['OnLoad']
OnViewCreated
['ModelessDialogVisible']
DialogExecute
Execution time for forms.Forms.test_tdf131000: 2.707
Binary URP bridge already disposed /core/binaryurp/source/bridge.cxx:1045
ERROR
ERROR
test_cancelButton (pivotTable.pivotTable) ... OfficeConnection: connecting to: 
uno:pipe,name=pytest1ec37366-791f-11eb-8141-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
['OnLoad']
OnLoadFinished
['OnLoad']
OnTitleChanged
['OnLoad']
OnFocus
['OnLoad']
OnViewCreated
['DialogExecute']
ModelessDialogVisible
['OnLoad', 'DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['OnLoad', 'DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['OnLoad', 'DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['OnLoad', 'DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['OnLoad', 'DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['OnLoad', 'DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['OnLoad', 'DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
Execution time for pivotTable.pivotTable.test_cancelButton: 2.904
tearDown: calling terminate()...
...done
ok
test_tdf121949_copy_block_with_single_cell_not_included (tdf121949.tdf121949) 
... OfficeConnection: connecting to: 
uno:pipe,name=pytest212b6d0c-791f-11eb-8141-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
['OnNew']
OnCreate
['OnNew']
OnStorageChanged
['OnNew']
OnTitleChanged
['OnNew']

CppunitTest_sc_shapetest failing after cd966aac6e

[Luke Benes]

After https://cgit.freedesktop.org/libreoffice/core/commit/?id=cd966aac6e
tdf#137033 improve save of cell anchored shapes

CppunitTest_sc_shapetest fails with the errors below.  I can reliable reproduce 
the failure and the verified the bisect with a 'make clean' between builds. 

Let me know if you need any additional information about my system or debug 
info. I'm seeing this failure on both x86/x86_64, release/debug builds, and on 
2 different PCs. Also setting scaling to 100% does not fix this.

I am surprised that the build bots missed this. Are all windows bots doing a 
'make check' now that it is required?

-Luke  


[_RUN_] sc_apitest::ScShapeTest::testTdf137033_FlipHori_Resize
sc_apitest::ScShapeTest::testTdf137033_FlipHori_Resize finished in: 5081ms
[_RUN_] sc_apitest::ScShapeTest::testTdf137033_RotShear_ResizeHide
sc_apitest::ScShapeTest::testTdf137033_RotShear_ResizeHide finished in: 3500ms
[_RUN_] sc_apitest::ScShapeTest::testTdf137033_RotShear_Hide
sc_apitest::ScShapeTest::testTdf137033_RotShear_Hide finished in: 4512ms
[_RUN_] sc_apitest::ScShapeTest::testTdf137576_LogicRectInDefaultMeasureline
D:/core/sc/qa/unit/scshapetest.cxx:145:sc_apitest::ScShapeTest::testTdf137576_LogicRectInDefaultMeasureline
assertion failed
- Expression: std::abs(rExpected.Y() - rActual.Y()) <= nTolerance
- after reload Y expected 6163 actual 8385 Tolerance 1

sc_apitest::ScShapeTest::testTdf137576_LogicRectInDefaultMeasureline finished 
in: 3299ms
[_RUN_] sc_apitest::ScShapeTest::testTdf137576_LogicRectInNewMeasureline
sc_apitest::ScShapeTest::testTdf137576_LogicRectInNewMeasureline finished in: 
883ms
[_RUN_] sc_apitest::ScShapeTest::testMeasurelineHideColSave
sc_apitest::ScShapeTest::testMeasurelineHideColSave finished in: 3002ms
[_RUN_] sc_apitest::ScShapeTest::testHideColsShow
sc_apitest::ScShapeTest::testHideColsShow finished in: 1166ms
[_RUN_] sc_apitest::ScShapeTest::testTdf138138_MoveCellWithRotatedShape
sc_apitest::ScShapeTest::testTdf138138_MoveCellWithRotatedShape finished in: 
2437ms
[_RUN_] sc_apitest::ScShapeTest::testLoadVerticalFlip
sc_apitest::ScShapeTest::testLoadVerticalFlip finished in: 979ms
[_RUN_] sc_apitest::ScShapeTest::testTdf117948_CollapseBeforeShape
sc_apitest::ScShapeTest::testTdf117948_CollapseBeforeShape finished in: 1963ms
[_RUN_] sc_apitest::ScShapeTest::testTdf137355_UndoHideRows
sc_apitest::ScShapeTest::testTdf137355_UndoHideRows finished in: 1396ms
[_RUN_] sc_apitest::ScShapeTest::testTdf115655_HideDetail
sc_apitest::ScShapeTest::testTdf115655_HideDetail finished in: 2745ms
[_RUN_] sc_apitest::ScShapeTest::testFitToCellSize
sc_apitest::ScShapeTest::testFitToCellSize finished in: 840ms
[_RUN_] sc_apitest::ScShapeTest::testCustomShapeCellAnchoredRotatedShape
sc_apitest::ScShapeTest::testCustomShapeCellAnchoredRotatedShape finished in: 
848ms
D:/core/sc/qa/unit/scshapetest.cxx(145) : error : Assertion
Test name: sc_apitest::ScShapeTest::testTdf137576_LogicRectInDefaultMeasureline
assertion failed
- Expression: std::abs(rExpected.Y() - rActual.Y()) <= nTolerance
- after reload Y expected 6163 actual 8385 Tolerance 1

Failures !!!
Run: 14   Failure total: 1   Failures: 1   Errors: 0
[build CUT] svgio

Error: a unit test failed, please do one of:
make CppunitTest_sc_shapetest CPPUNITTRACE=TRUE # which is a shortcut for the 
following line
make CppunitTest_sc_shapetest CPPUNITTRACE="'C:/Program Files (x86)/Microsoft 
Visual Studio/2019/Community/Common7/IDE/devenv.exe' /debugexe" # for 
interactive debugging in Visual Studio
make CppunitTest_sc_shapetest CPPUNITTRACE="drmemory -free_max_frames 20" # for 
memory checking (install Dr.Memory first, and put it to your PATH)

You can limit the execution to just one particular test by:

make CppunitTest_sc_shapetest


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

JunitTest_sfx2_complex failing on Windows after f5ab8bcbfd20

[Luke Benes]

After https://cgit.freedesktop.org/libreoffice/core/commit/?id=f5ab8bcbfd20
WIN don't notify clipboard change with SolarMutex

I'm seeing the failure below on Windows 10 x86. Any idea why this would cause 
this failure? Let me know if you need any additional debugging info.

-Luke


[build JUT] sfx2_complex
JUnit version 4.10

starting class: complex.sfx2.DocumentProperties

.tempdir: 
file:///D:/lode/dev/core/workdir/JunitTest/sfx2_complex/user/user/test-temp/
Creating service DocumentProperties...
...done
Checking initialize ...
...done
Checking storing default-initialized meta data ...
...done
Checking loading default-initialized meta data ...
...done
Checking loading from test document...
...done
Checking meta-data import...
...done
Checking meta-data updates...
...done
Checking user-defined meta-data updates...
...done
Checking storing meta-data to file...
...done
Checking loading meta-data from stored file...
...done
Checking user-defined meta-data from stored file...
...done
Checking notification listener interface...
...done

finishing class: complex.sfx2.DocumentProperties


starting class: complex.sfx2.DocumentMetadataAccess

.tempdir: 
file:///D:/lode/dev/core/workdir/JunitTest/sfx2_complex/user/user/test-temp/
Creating document with Repository...
...done
Checking that new repository is initialized...
...done
Checking some invalid args...
...done
Checking file addition/removal...
...done
Checking mapping...
...done
Checking storing and loading...
...done
Checking storing and loading via model...
...done
.tempdir: 
file:///D:/lode/dev/core/workdir/JunitTest/sfx2_complex/user/user/test-temp/
Loading test document...
...done
Checking RDFa in loaded test document...
...done
Storing test document...
...done
Loading test document...
...done
Checking RDFa in loaded test document...
...done
.tempdir: 
file:///D:/lode/dev/core/workdir/JunitTest/sfx2_complex/user/user/test-temp/

finishing class: complex.sfx2.DocumentMetadataAccess

E.
starting class: complex.sfx2.UndoManager
connecting ...
.testing: text document
.testing: request serialization
.testing: drawing document
.testing: broken scripts
.testing: chart document
.testing: presentation document

tearing down connection
finished class: complex.sfx2.UndoManager


Time: 69.994
There was 1 failure:
1) complex.sfx2.DocumentMetadataAccess
java.lang.AssertionError: expected:<0> but was:<-1073741819>
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.openoffice.test.OfficeConnection.tearDown(OfficeConnection.java:150)
at 
complex.sfx2.DocumentMetadataAccess.tearDownConnection(DocumentMetadataAccess.java:1222)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at 

Re: build failure on ubuntu 18.04

[Luke Benes]

Try: sudo apt-get install  libx11-xcb-dev

For some reason, the wiki was just massively paired down with stuff like this 
removed. 
https://wiki.documentfoundation.org/index.php?title=Development/Linux_Build_Dependencies

In the case of dependencies, less is not more. 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Bridgetest Failing on RPI4 armhf

[Luke Benes]

On Raspberry Pi OS with both gcc-8 and clang 12, the build is failing with the 
following error:

### float does not match! failed
struct comparison test failed
### float does not match! failed
recursive test results failed
standard test failed
exception occurred: error: test failed! 
/core/testtools/source/bridgetest/bridgetest.cxx:1175

> error: error: test failed! 
> /core/testtools/source/bridgetest/bridgetest.cxx:1175
> dying...make[1]: *** [/core/testtools/CustomTarget_uno_test.mk:25: 
> /core/workdir/CustomTarget/testtools/uno_test.done] Error 1

Stephan fixed a very similar issue for aarch64 here:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=7b0ab85b4042cb38221ca5c9794b70c87443181f

Any ideas what's wrong here? Or how to get additional debug information? 

-Luke

$ lsb_release -a
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
$ uname -a
Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l 
GNU/Linux
$ dpkg --print-architecture
armhf
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: UITest_writer_tests failing on KDE Neon

[Luke Benes]

Correct URL:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a658ece9f9fa308084c3e0f4662dda7afb9a0879


From: Luke Benes 
Sent: Sunday, September 20, 2020 9:25 PM
To: Caolán McNamara; libreoffice@lists.freedesktop.org; Xisco Fauli; Miklos 
Vajna
Subject: Re: UITest_writer_tests failing on KDE Neon

I can confirm that 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=d3c870fcbfed4bbbcbc5d943c2526b353ad396c6
fixes the build for me. No errors after a full 'make check'.

Miklos or Xisco,
I think Caolán's fix may resolve your issue too. Would it serve any purpose to 
revert 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a658ece9f9fa308084c3e0f4662dda7afb9a0879/
 now?

Thanks everyone!

From: Caolán McNamara 
Sent: Sunday, September 20, 2020 2:56 PM
To: Luke Benes; libreoffice@lists.freedesktop.org; Xisco Fauli; Miklos Vajna
Subject: Re: UITest_writer_tests failing on KDE Neon

On Sun, 2020-09-20 at 17:41 +, Luke Benes wrote:
> After
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=b6ab2330d97672936edc56de8d6f5b6f772908ff
>
> ...
> =
> FAIL: test_tdf135018 (trackedChanges.trackedchanges)
> -

> Any ideas on how to fix the font issue or should the text be
> relaxes/removed?


That test references document
sw/qa/uitest/writer_tests/data/tdf135018.odt
and opening that gives me some pages of text with font
"Bahnschrift Light" whose name is italicized in my UI indicating it's
not an installed font and is substituted. I imagine if it was something
like "DejaVu Sans" which we bundle by default that might resolve the
issue: https://gerrit.libreoffice.org/c/core/+/103076


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: UITest_writer_tests failing on KDE Neon

[Luke Benes]

I can confirm that 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=d3c870fcbfed4bbbcbc5d943c2526b353ad396c6
fixes the build for me. No errors after a full 'make check'. 

Miklos or Xisco,
I think Caolán's fix may resolve your issue too. Would it serve any purpose to 
revert 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a658ece9f9fa308084c3e0f4662dda7afb9a0879/
 now? 

Thanks everyone!

From: Caolán McNamara 
Sent: Sunday, September 20, 2020 2:56 PM
To: Luke Benes; libreoffice@lists.freedesktop.org; Xisco Fauli; Miklos Vajna
Subject: Re: UITest_writer_tests failing on KDE Neon

On Sun, 2020-09-20 at 17:41 +, Luke Benes wrote:
> After
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=b6ab2330d97672936edc56de8d6f5b6f772908ff
>
> ...
> =
> FAIL: test_tdf135018 (trackedChanges.trackedchanges)
> -

> Any ideas on how to fix the font issue or should the text be
> relaxes/removed?


That test references document
sw/qa/uitest/writer_tests/data/tdf135018.odt
and opening that gives me some pages of text with font
"Bahnschrift Light" whose name is italicized in my UI indicating it's
not an installed font and is substituted. I imagine if it was something
like "DejaVu Sans" which we bundle by default that might resolve the
issue: https://gerrit.libreoffice.org/c/core/+/103076


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

UITest_writer_tests failing on KDE Neon

[Luke Benes]

After 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=b6ab2330d97672936edc56de8d6f5b6f772908ff

On KDE Neon, I'm seeing the following failure:

[UIT] writer_tests
...
==
FAIL: test_tdf135018 (trackedChanges.trackedchanges)
--
Traceback (most recent call last):
  File "/core/sw/qa/uitest/writer_tests/trackedChanges.py", line 236, in 
test_tdf135018
self.assertEqual(5, document.CurrentController.PageCount)
AssertionError: 5 != 6

--
Ran 26 tests in 55.792s

FAILED (failures=1)
Tests run: 26
Tests failed: 1
Tests errors: 0
Tests skipped: 0

Error: a unit test failed:

To rerun just this failed test without all others, use:
make UITest_writer_tests

$ lsb_release -a
Description:KDE neon User Edition 5.19
Release:20.04

I have scaling set to 100%, so this is likely a font issue like Miklos saw 
here: 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a658ece9f9fa308084c3e0f4662dda7afb9a0879

Any ideas on how to fix the font issue or should the text be relaxes/removed? 

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

New Unit Test for tdf#130960 causing Build Failure on i686

[Luke Benes]

After https://cgit.freedesktop.org/libreoffice/core/commit/?id=4a581f12e0d0
tdf#130960: Add UItest

The UI test is failing on test_tdf131907 (trackedChanges.CalcTrackedChanges)

Xisco,
Do you need any additional debugging info? Any idea why this would fail on 
i686? 

Thanks

-Luke

build log below:

[UIT] calc_tests4
test_tdf89907_text_to_columns (tdf89907.tdf89907) ... OfficeConnection: 
connecting to: 
uno:pipe,name=pytest756e7152-9243-11ea-b707-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
['OnNew']
OnCreate
['OnNew']
OnStorageChanged
['OnNew']
OnTitleChanged
['OnNew']
OnFocus
['OnNew']
OnViewCreated
1
['DialogExecute']
OnModeChanged
['DialogClosed']
OnModeChanged
Execution time for tdf89907.tdf89907.test_tdf89907_text_to_columns: 2.518
tearDown: calling terminate()...
...done
ok
test_td99386_undo_merged_cell_needs_hard_recalculate (tdf99386.tdf99386) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytest78d9a834-9243-11ea-b707-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
['OnLoad']
OnLoadFinished
['OnLoad']
OnTitleChanged
['OnLoad']
OnFocus
['OnLoad']
OnViewCreated
Execution time for 
tdf99386.tdf99386.test_td99386_undo_merged_cell_needs_hard_recalculate: 3.474
tearDown: calling terminate()...
...done
ok
test_td99627_natural_sort (tdf99627.tdf99627) ... OfficeConnection: connecting 
to: 
uno:pipe,name=pytest7ba415ae-9243-11ea-b707-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
['OnLoad']
OnLoadFinished
['OnLoad']
OnTitleChanged
['OnLoad']
OnFocus
['OnLoad']
OnViewCreated
['DialogExecute']
OnModeChanged
['DialogClosed']
OnModeChanged
['DialogClosed']
OnTitleChanged
['DialogClosed']
OnModifyChanged
Execution time for tdf99627.tdf99627.test_td99627_natural_sort: 3.954
tearDown: calling terminate()...
...done
ok
test_text_to_columns_comma (textToColumns.CalcTextToColumns) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytest7eb8df5e-9243-11ea-b707-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
NoConnectException: sleeping...
['OnLoad']
OnLoadFinished
['OnLoad']
OnTitleChanged
['OnLoad']
OnFocus
['OnLoad']
OnViewCreated
['DialogExecute']
DialogClosed
['DialogExecute']
OnModeChanged
true
true
['DialogClosed']
OnModeChanged
['DialogExecute']
OnModeChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnModeChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnModeChanged
['DialogClosed']
OnModeChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnModeChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['DialogClosed']
OnTitleChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnTitleChanged
['DialogClosed']
OnModifyChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnModifyChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
Execution time for textToColumns.CalcTextToColumns.test_text_to_columns_comma: 
4.087
tearDown: calling terminate()...
...done
ok
test_text_to_columns_dot (textToColumns.CalcTextToColumns) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytest827bcaac-9243-11ea-b707-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
['OnLoad']
OnLoadFinished
['OnLoad']
OnTitleChanged
['OnLoad']
OnFocus
['OnLoad']
OnViewCreated
['DialogExecute']
DialogClosed
['DialogExecute']
OnModeChanged
true
true
['DialogClosed']
OnModeChanged
['DialogExecute']
OnModeChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnModeChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnModeChanged
['DialogClosed']
OnModeChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnModeChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['DialogClosed']
OnTitleChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnTitleChanged
['DialogClosed']
OnModifyChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
OnModifyChanged
['DialogExecute', 'ModelessDialogExecute', 'ModelessDialogVisible']
DialogClosed
['DialogExecute']
DialogClosed
['DialogExecute']
OnModeChanged
['DialogClosed']
OnModeChanged
Execution time for textToColumns.CalcTextToColumns.test_text_to_columns_dot: 
4.737
tearDown: calling terminate()...
...done
ok
test_text_to_columns_pipe (textToColumns.CalcTextToColumns) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytest860b65a6-9243-11ea-b707-2c56dc06c1e5;urp;StarOffice.ComponentContext
NoConnectException: sleeping...
['OnLoad']
OnLoadFinished
['OnLoad']
OnTitleChanged
['OnLoad']
OnFocus
['OnLoad']
OnViewCreated
['DialogExecute']
DialogClosed
['DialogExecute']
OnModeChanged
['DialogClosed']
OnModeChanged
['DialogExecute']
OnModeChanged

i686 Linux build failure error: no viable conversion from 'xmlDocUniquePtr'

[Luke Benes]

On Arch linux 32, I'm seeing the following build failure

[CXX] sd/qa/unit/export-tests.cxx
/core/sd/qa/unit/export-tests.cxx:1284:15: error: no viable conversion from 
'xmlDocUniquePtr' (aka 'unique_ptr<_xmlDoc, xmlDocDeleter>') to 'xmlDocPtr' 
(aka '_xmlDoc *')
xmlDocPtr pXmlDoc = parseExport(tempFile, "content.xml");
  ^ 
[CXX] sd/qa/unit/HtmlExportTest.cxx
1 error generated.
make[1]: *** [/core/solenv/gbuild/LinkTarget.mk:306: 
/core/workdir/CxxObject/sd/qa/unit/export-tests.o] Error 1
make[1]: *** Waiting for unfinished jobs

Mike,

This seems to have begun after
https://cgit.freedesktop.org/libreoffice/core/commit/?id=5ac2075d56cff

Any idea how to fix?

Thanks

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

32-bit Linux build error: no matching function for call to 'assertEquals'

[Luke Benes]

[CXX] toolkit/qa/cppunit/EventContainer.cxx
/core/toolkit/qa/cppunit/EventContainer.cxx:73:5: error: no matching function 
for call to 'assertEquals'
CPPUNIT_ASSERT_EQUAL(4, nEventCount);
^~~~
/core/workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:333:5: note: 
expanded from macro 'CPPUNIT_ASSERT_EQUAL'
  ( CPPUNIT_NS::assertEquals( (expected),  \
^~~~
/core/workdir/UnpackedTarball/cppunit/include/cppunit/Portability.h:107:21: 
note: expanded from macro 'CPPUNIT_NS'
# define CPPUNIT_NS CppUnit
^
/core/workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:161:6: note: 
candidate template ignored: deduced conflicting types for parameter 'T' ('int' 
vs. 'long')
void assertEquals( const T& expected,
 ^
1 error generated.
make[1]: *** [/core/solenv/gbuild/LinkTarget.mk:306: 
/core/workdir/CxxObject/toolkit/qa/cppunit/EventContainer.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:282: build] Error 2

This looks to have begun after:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=4021fedf758b

Samuel,
Any idea what's wrong?

-Luke

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOffice and old Microsoft Binary file formats.

[Luke Benes]

> MS Word in the web (via onedrive)

You are comparing apples to oranges. The onedrive version is the free, 
crippleware version. The paid version that companies use does include the 
functionality to save as with the older binary formats. [1]

Until recently, my company had a group policy to save as in these MSO binary 
formats. LibreOffice had then and continues to have much better compatibility 
with these binary formats than the newer OOXML versions.

[1] 
https://support.office.com/en-us/article/use-compatibility-mode-to-work-with-different-versions-of-powerpoint-bc87ca23-4208-4d58-9c01-3a38a84c16e0
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Planned Gerrit upgrade on Wed, Dec 25 from 00:00 to 04:00 UTC

[Luke Benes]

What is the URL to change that? Some people might not want their email name to 
be changed to their SSO login IDs.

From: Guilhem Moulin
Sent: Friday, December 27, 2019 11:34 AM
To: Luke Benes
Cc: Libreoffice Dev List
Subject: Re: Planned Gerrit upgrade on Wed, Dec 25 from 00:00 to 04:00 UTC

On Fri, 27 Dec 2019 at 14:56:28 +, Luke Benes wrote:
> Where is the new username being pulled from?

I suppose that's the username you chose when you created your account on
our Single Sign On system.

--
Guilhem.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Planned Gerrit upgrade on Wed, Dec 25 from 00:00 to 04:00 UTC

[Luke Benes]

Guilhem,
With the new Gerrit, I have noticed that people's usernames have changed on the 
commit messages. For example:

Ayhan Yalçınsoy --> ayhanyalcinsoy
https://cgit.freedesktop.org/libreoffice/core/log/?qt=author=ayhanyalcinsoy%40pisilinux.org

Mine has also changed.  The username gerrit picked in nowhere in my gerrit 
profile. Where is the new username being pulled from?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: chart2.check fails in testAxisTitlePositionDOCX

[Luke Benes]

I bisected this regression to 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=d10db7846602c16701dde019f12f61fd536e9ae4

tdf#128133 WIN don't exit after link-output filter

Jan-Marek,
Could you please take a look at this? You can reproduce it by setting your 
scale factor to something other than 100%.

Thanks,
-Luke




From: Luke Benes

Sent: Saturday, December 7, 2019 12:47 PM

To: Regina Henschel ; Regina Henschel 
; Libreoffice Dev List 
; Balazs Varga 

Subject: Re: chart2.check fails in testAxisTitlePositionDOCX
 

Regina,


This is not an intermittent failure and not the same error as your gerrit 
failures. Rather it is a yet another Windows HiDPI bug and a recent regression. 
Possibly when these tests were added a month ago:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=9ff954d5f780

 tdf#127908 tdf#128193 Chart OOXML: Fix Custom Y axis title position



You can make the build complete successfully by:

Display Settings -> Scale and Layout -> 100%


This is a recent regression, that I will try to bisect. 


Other examples of HiDPI Windows failures include:

CppunitTest_sw_layoutwriter failing on Windows with HiDPI

http://document-foundation-mail-archive.969070.n3.nabble.com/CppunitTest-sw-layoutwriter-failing-on-Windows-with-HiDPI-tp4266491.html


CppunitTest_starmath_qa_cppunit Failing on Windows with HiDPI

http://document-foundation-mail-archive.969070.n3.nabble.com/CppunitTest-starmath-qa-cppunit-Failing-on-Windows-with-HiDPI-screens-tp4261772.html


-Luke



Build log  with Scale = 125%:


[build CUT] chart2_export

Chart2ImportTest::testAxisTitleRotationXLSX finished in: 536ms

D:/core/chart2/qa/extras/chart2import.cxx:1577:Chart2ImportTest::testAxisTitlePositionDOCX

equality assertion failed

- Expected: 6378

- Actual  : 6571


Chart2ImportTest::testTdf122765 finished in: 647ms

D:/core/chart2/qa/extras/chart2import.cxx(1577) : error : Assertion

Test name: Chart2ImportTest::testAxisTitlePositionDOCX

equality assertion failed

- Expected: 6378

- Actual  : 6571


Failures !!!

Run: 88   Failure total: 1   Failures: 1   Errors: 0



Chart2ExportTest::testAxisTitleRotationXLSX finished in: 560ms

D:/core/chart2/qa/extras/chart2export.cxx:2037:Chart2ExportTest::testAxisTitlePositionDOCX

assertion failed

- Expression: nY > 0.384407 && nY < 0.384408



D:/core/chart2/qa/extras/chart2export.cxx(2037) : error : Assertion

Test name: Chart2ExportTest::testAxisTitlePositionDOCX

assertion failed

- Expression: nY > 0.384407 && nY < 0.384408


Failures !!!

Run: 110   Failure total: 1   Failures: 1   Errors: 0


Error: a unit test failed, please do one of:

make CppunitTest_chart2_export



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: chart2.check fails in testAxisTitlePositionDOCX

[Luke Benes]

Regina,

This is not an intermittent failure and not the same error as your gerrit 
failures. Rather it is a yet another Windows HiDPI bug and a recent regression. 
Possibly when these tests were added a month ago:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9ff954d5f780
 tdf#127908 tdf#128193 Chart OOXML: Fix Custom Y axis title position


You can make the build complete successfully by:
Display Settings -> Scale and Layout -> 100%

This is a recent regression, that I will try to bisect. 

Other examples of HiDPI Windows failures include:
CppunitTest_sw_layoutwriter failing on Windows with HiDPI
http://document-foundation-mail-archive.969070.n3.nabble.com/CppunitTest-sw-layoutwriter-failing-on-Windows-with-HiDPI-tp4266491.html

CppunitTest_starmath_qa_cppunit Failing on Windows with HiDPI
http://document-foundation-mail-archive.969070.n3.nabble.com/CppunitTest-starmath-qa-cppunit-Failing-on-Windows-with-HiDPI-screens-tp4261772.html

-Luke


Build log  with Scale = 125%:

[build CUT] chart2_export
Chart2ImportTest::testAxisTitleRotationXLSX finished in: 536ms
D:/core/chart2/qa/extras/chart2import.cxx:1577:Chart2ImportTest::testAxisTitlePositionDOCX
equality assertion failed
- Expected: 6378
- Actual  : 6571

Chart2ImportTest::testTdf122765 finished in: 647ms
D:/core/chart2/qa/extras/chart2import.cxx(1577) : error : Assertion
Test name: Chart2ImportTest::testAxisTitlePositionDOCX
equality assertion failed
- Expected: 6378
- Actual  : 6571

Failures !!!
Run: 88   Failure total: 1   Failures: 1   Errors: 0


Chart2ExportTest::testAxisTitleRotationXLSX finished in: 560ms
D:/core/chart2/qa/extras/chart2export.cxx:2037:Chart2ExportTest::testAxisTitlePositionDOCX
assertion failed
- Expression: nY > 0.384407 && nY < 0.384408


D:/core/chart2/qa/extras/chart2export.cxx(2037) : error : Assertion
Test name: Chart2ExportTest::testAxisTitlePositionDOCX
assertion failed
- Expression: nY > 0.384407 && nY < 0.384408

Failures !!!
Run: 110   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_chart2_export



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: build failure on i686: error: invalid conversion and no matching function

[Luke Benes]

Stephan's patch, https://gerrit.libreoffice.org/#/c/83912/ fixes the build.

Christian,
Issues like this, are a reminder that we still need to get an  x86 Jenkin's Bot 
setup. The latency in our previous communications was discouraging and then 
life took over. I'll have some free time over the holiday season to dedicate to 
this project. Will you be available and do you still have a VM dedicated for 
this per the ESC decision?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

build failure on i686: error: invalid conversion and no matching function

[Luke Benes]

Caolán,
https://cgit.freedesktop.org/libreoffice/core/commit/?id=278a365c68e0
Related: tdf#126043 use fastest png compression ratio

Does actually hurt:) It's causing the following error on x86 builds:

[CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
/core/include/cppu/unotype.hxx: In instantiation of ‘static const 
com::sun::star::uno::Type& cppu::UnoType<  >::get() 
[with T = int]’:
/core/include/cppu/unotype.hxx:321:37:   required from ‘const 
com::sun::star::uno::Type& cppu::getTypeFavourUnsigned(const T*) [with T = int]’
/core/include/com/sun/star/uno/Any.hxx:276:55:   required from ‘void 
com::sun::star::uno::operator<<=(com::sun::star::uno::Any&, const C&) [with C = 
int]’
/core/vcl/unx/gtk3/gtk3gtkinst.cxx:2934:34:   required from here
/core/include/cppu/unotype.hxx:296:38: error: no matching function for call to 
‘cppu_detail_getUnoType(T1*)’
  296 | return cppu_detail_getUnoType(static_cast< T1 * >(0));
  |~~^~~~
/core/include/cppu/unotype.hxx:161:1: note: candidate: ‘const 
com::sun::star::uno::Type& cppu::detail::cppu_detail_getUnoType(const 
sal_Int32*)’ 
  161 | cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::sal_Int32 const *) {
  | ^~
/core/include/cppu/unotype.hxx:161:1: note:   conversion of argument 1 would be 
ill-formed:
/core/include/cppu/unotype.hxx:296:38: error: invalid conversion from ‘T1*’ 
{aka ‘int*’} to ‘const sal_Int32*’ {aka ‘const long int*’} [-fpermissive]
  296 | return cppu_detail_getUnoType(static_cast< T1 * >(0));
  |~~^~~~
  |  |
  |  T1* {aka int*}


full build log: https://pastebin.com/KibAVVeH

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with clang on older CPU :Illegal instruction

[Luke Benes]

I confirmed that git bisect identified the wrong commit, probably because I 
didn't run a `make clean` between builds. Also confirmed that Tomaž's patch 
https://gerrit.libreoffice.org/#/c/82422/
allows a successful build on older CPUs.

Superb job tracking down and fixing this issue despite my bad bisect. Thanks 
Tomaž and Luboš!

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Build failure with clang on older CPU :Illegal instruction

[Luke Benes]

Noel,

After 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=09f77e8ed51fc64fccc6a14e87eed48b2f15a28d
    loplugin:unusedmethods

Clang 7 on KDE Neon x86-64, and clang 10-git on openSUSE Tumbleweed i686 is 
failing with 

[CUT] tools_test
Illegal instruction (core dumped)

It looks like /core/workdir/LinkTarget/Executable/cppunittester generated 
/core/workdir/CppunitTest/tools_test.test.core/core
Backtraces:
[New LWP 8225]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/core/workdir/Link'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x7f90e824f538 in CppUnit::TestSuiteFactory<(anonymous 
namespace)::CpuInstructionSetSupport>::makeTest() () from 
/core/workdir/LinkTarget/CppunitTest/libtest_tools_test.so
warning: File "/core/instdir/program/libuno_sal.so.3-gdb.py" auto-loading has 
been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /core/instdir/program/libuno_sal.so.3-gdb.py
line to your configuration file "/home/luke/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/luke/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: File "/core/instdir/program/libbasegfxlo.so-gdb.py" auto-loading has 
been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".
warning: File "/core/instdir/program/libtllo.so-gdb.py" auto-loading has been 
declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: File "/core/instdir/program/libuno_cppu.so.3-gdb.py" auto-loading has 
been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".
warning: File "/core/instdir/program/libvcllo.so-gdb.py" auto-loading has been 
declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: File "/core/instdir/program/libsvllo.so-gdb.py" auto-loading has been 
declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
rax0x7f90e9fa06f8   140260377495288
rbx0x8e8c90 9342096
rcx0x7ffdd580c570   140728185439600
rdx0x7f90e8463a48   140260348934728
rsi0x952a10 9775632
rdi0x7ffdd580c570   140728185439600
rbp0x7ffdd580c6a0   0x7ffdd580c6a0
rsp0x7ffdd580c550   0x7ffdd580c550
r8 0x952da0 9776544
r9 0x952dd0 9776592
r100x0  0
r110x0  0
r120x7ffdd580cc10   140728185441296
r130x7  7
r140x952a10 9775632
r150x7ffdd580c978   140728185440632
rip0x7f90e824f538   0x7f90e824f538 
::makeTest()+168>
eflags 0x10202  [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0

Thread 1 (Thread 0x7f90ea199740 (LWP 8225)):
#0  0x7f90e824f538 in CppUnit::TestSuiteFactory<(anonymous 
namespace)::CpuInstructionSetSupport>::makeTest() () at 
/core/workdir/LinkTarget/CppunitTest/libtest_tools_test.so
#1  0x7f90e9d66f3b in 
CppUnit::TestFactoryRegistry::addTestToSuite(CppUnit::TestSuite*) () at 
/core/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0
#2  0x7f90e9d66e67 in CppUnit::TestFactoryRegistry::makeTest() () at 
/core/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0
#3  0x004042a9 in (anonymous namespace)::ProtectedFixtureFunctor::run() 
const ()
#4  0x004035be in main ()


Error: a unit test failed, please do one of:

make CppunitTest_tools_test CPPUNITTRACE="gdb --args"
...
$ cat /proc/cpuinfo 
model name  : Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz

Newer CPU's like my Broadwell Core i3 Processors have no issue with the same 
distros. 

What additional debugging info would you like? 

-Luke




___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

clang 10 error: use of overloaded operator '!=' is ambiguous

[Luke Benes]

clang version 10.0.0 (https://github.com/llvm/llvm-project.git 
8e050e41a4b1193592f9b4298f14935f5878ae5f / r375496)

 is failing with the following new errors:

[CXX] vcl/unx/generic/gdi/salgdi.cxx
/core/vcl/unx/generic/gdi/salgdi.cxx:138:18: error: use of overloaded operator 
'!=' is ambiguous (with operand types 'SalX11Screen' and 'SalX11Screen')
if( nXScreen != m_nXScreen )
 ^  ~~
/core/vcl/inc/unx/saltype.h:22:10: note: candidate function
bool operator!=(const SalX11Screen ) { return rOther.mnXScreen != 
mnXScreen; }
 ^
/core/vcl/inc/unx/saltype.h:21:10: note: candidate function
bool operator==(const SalX11Screen ) { return rOther.mnXScreen == 
mnXScreen; }
 ^
/core/vcl/inc/unx/saltype.h:21:10: note: candidate function (with reversed 
parameter order)
1 error generated.
/core/solenv/gbuild/LinkTarget.mk:294: recipe for target 
'/core/workdir/CxxObject/vcl/unx/generic/gdi/salgdi.o' failed
make[1]: *** [/core/workdir/CxxObject/vcl/unx/generic/gdi/salgdi.o] Error 1
make[1]: *** Waiting for unfinished jobs
/core/vcl/unx/generic/window/salframe.cxx:2377:34: error: use of overloaded 
operator '!=' is ambiguous (with operand types 'SalX11Screen' and 
'SalX11Screen')
if( mpParent->m_nXScreen != m_nXScreen )
 ^  ~~
/core/vcl/inc/unx/saltype.h:22:10: note: candidate function
bool operator!=(const SalX11Screen ) { return rOther.mnXScreen != 
mnXScreen; }
 ^
/core/vcl/inc/unx/saltype.h:21:10: note: candidate function
bool operator==(const SalX11Screen ) { return rOther.mnXScreen == 
mnXScreen; }
 ^
/core/vcl/inc/unx/saltype.h:21:10: note: candidate function (with reversed 
parameter order)
/core/vcl/unx/generic/window/salframe.cxx:2452:34: error: use of overloaded 
operator '!=' is ambiguous (with operand types 'SalX11Screen' and 
'SalX11Screen')
if( mpParent->m_nXScreen != m_nXScreen )
 ^  ~~
/core/vcl/inc/unx/saltype.h:22:10: note: candidate function
bool operator!=(const SalX11Screen ) { return rOther.mnXScreen != 
mnXScreen; }
 ^
/core/vcl/inc/unx/saltype.h:21:10: note: candidate function
bool operator==(const SalX11Screen ) { return rOther.mnXScreen == 
mnXScreen; }
 ^
/core/vcl/inc/unx/saltype.h:21:10: note: candidate function (with reversed 
parameter order)
2 errors generated.
/core/solenv/gbuild/LinkTarget.mk:294: recipe for target 
'/core/workdir/CxxObject/vcl/unx/generic/window/salframe.o' failed
make[1]: *** [/core/workdir/CxxObject/vcl/unx/generic/window/salframe.o] Error 1
Makefile:282: recipe for target 'build' failed
make: *** [build] Error 2

False positive, suppress, or something that needs fixing?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Unit Test: CppunitTest_sc_opencl_test failing on Windows

[Luke Benes]

After https://cgit.freedesktop.org/libreoffice/core/commit/?id=4ee424b3ddc6
Pre-allocate an ScInterpreter object for each thread...

Both 32 and 64-bit windows builds are failing with the following error:
D:/lode/dev/core/sc/qa/unit/opencl-test.cxx(573) : error : Assertion
Test name: ScOpenCLTest::testCompilerNested
double equality assertion failed
- Expected: 629
- Actual  : 609
- Delta   : 0.0629

D:/lode/dev/core/sc/qa/unit/opencl-test.cxx(590) : error : Assertion
Test name: ScOpenCLTest::testCompilerString
double equality assertion failed
- Expected: 2
- Actual  : 1
- Delta   : 0.0002

D:/lode/dev/core/sc/qa/unit/opencl-test.cxx(611) : error : Assertion
Test name: ScOpenCLTest::testCompilerInEq
double equality assertion failed
- Expected: 2
- Actual  : 4
- Delta   : 0.0002

Failures !!!
Run: 223   Failure total: 3   Failures: 3   Errors: 0


You can limit the execution to just one particular test by:

make CppunitTest_sc_opencl_test CPPUNIT_TEST_NAME="testXYZ"


Dennis, Could you take a look at this?

Thanks!
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppunitTest_sw_layoutwriter failing on Windows with HiDPI

[Luke Benes]

After Stephan and Balazs' patches, I can now build on windows with HiDPI.  
Thanks guys!

Does it really make sense for all of these unit tests to be DPI dependent?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sw_layoutwriter failing on Windows with HiDPI

[Luke Benes]

Miklos,
The Unit Test in 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=c56bf1479cc71d1a2b0639f6383e90c1f7e3655b

Is failing on Windows with 125% scale factor. The build fails with the 
following error:

C:/core/sw/qa/extras/uiwriter/uiwriter2.cxx(2253) : error : Assertion
Test name: testTdf105330::TestBody
equality assertion failed
- Expected: 276
- Actual  : 271

Failures !!!
Run: 248   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_sw_uiwriter 


Should our Unit Test results be DPI dependent? Here are just a few recent 
examples of ones that I have reported:
http://document-foundation-mail-archive.969070.n3.nabble.com/CppunitTest-chart2-xshape-Failure-with-Display-Scaling-on-Windows-tp4254666.html
http://document-foundation-mail-archive.969070.n3.nabble.com/CppUnit-SdMiscTest-testTdf119956-Failing-on-Windows-with-150-scale-factor-tp4261841.html
http://document-foundation-mail-archive.969070.n3.nabble.com/CppunitTest-sw-layoutwriter-failing-on-Windows-with-HiDPI-tp4266491.html

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppunitTest_sw_layoutwriter failing on Windows with HiDPI

[Luke Benes]

Sorry. I copy/pasted the wrong commit id. The build started failing after the 
Unit Test added in
https://cgit.freedesktop.org/libreoffice/core/commit/?id=55136439e71b7adc62a46a3d3dc8de26d54d989d

tdf127448 Chart: Avoid distortion of charts with multilevel axis labels

Should the assert be relaxed a bit?

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sw_layoutwriter failing on Windows with HiDPI

[Luke Benes]

The Unit Test added in 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=4ac31078b9c46231f8ecf0409a1724749ac8c5a4

Is causing the core Unit Test CppunitTest_sw_layoutwriter to fail when you set, 
 Settings->Display->Scale=125% in Windows 10.



horizontal_multilevel.odt:
C:/lode/dev/core/test/source/xmltesttools.cxx(168) : error : Assertion
Test name: testHorizontal_multilevel::TestBody
equality assertion failed
- Expected: 7945
- Actual  : 7946
- In <>, attribute 'y' of 
'/metafile/push[1]/push[1]/push[1]/push[3]/push[1]/textarray[7]' incorrect 
value.

Failures !!!
Run: 56   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_sw_layoutwriter CPPUNITTRACE=TRUE # which is a shortcut for 
the following line
make CppunitTest_sw_layoutwriter CPPUNITTRACE="'C:/Program Files 
(x86)/Microsoft Visual Studio/2017/Community/Common7/IDE/devenv.exe' /debugexe" 
# for interactive debugging in Visual Studio
make CppunitTest_sw_layoutwriter CPPUNITTRACE="drmemory -free_max_frames 20" # 
for memory checking (install Dr.Memory first, and put it to your PATH)

You can limit the execution to just one particular test by:

make CppunitTest_sw_layoutwriter CPPUNIT_TEST_NAME="testXYZ" ...above mentioned 
params...

make[1]: *** [C:/lode/dev/core/solenv/gbuild/CppunitTest.mk:114: 
C:/lode/dev/core/workdir/CppunitTest/sw_layoutwriter.test] Error 1
make: *** [Makefile:167: CppunitTest_sw_layoutwriter] Error 2




___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Fwd: [global-libreoffice-ci] lo_daily_update_gandalf - Build # 666 - Still Failing!

[Luke Benes]

https://cgit.freedesktop.org/libreoffice/core/commit/?id=14087d3e5fed9b56384432d9aeac608a5e8d86cf


        tdf#121670 ooxmlimport: no columns in page styles, only sections

was the cause of this failure
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Fwd: [global-libreoffice-ci] lo_daily_update_gandalf - Build # 666 - Still Failing!

[Luke Benes]

A clean install of KDE Neon is failing with the same error that Stephan 
reported:
https://ci.libreoffice.org/job/lo_daily_update_gandalf/lastBuild/console

ooxmlexport4.cxx:1209:Assertion
Test name: testTdf81345_045Original::Import_Export_Import
assertion failed
- Expression: pageStyleName != "Standard"

I bisected this regression to:

tdf#121670 ooxmlimport: no columns in page styles, only sections

Where can I find Gandalf's configuration? Was kde base install on it?

Justin,
Could you look into why your patch is failing on Gandalf and KDE Neon?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sw_ooxmllinks failing on Windows

[Luke Benes]

After https://cgit.freedesktop.org/libreoffice/core/commit/?id=217a80fd205c

Some windows boxes like @42 are failing.
https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1563378001.26689


24716
 [build CUT] sw_ooxmlw14export
24717
 File tested,Execution Time (ms)
24718
 absolute-link.docx:
24719
 577
24720
 testAbsoluteToRelativeImport::Import finished in: 639ms
24721
 File tested,Execution Time (ms)
24722
 absolute-link.docx:
24723
 265
24724
 testAbsoluteToAbsoluteImport::Import finished in: 297ms
24725
 File tested,Execution Time (ms)
24726
 absolute-link.docx:
24727
 764
24728
 testAbsoluteToAbsoluteExport::Import_Export_Import finished in: 780ms
24729
 File tested,Execution Time (ms)
24730
 relative-link.docx:
24731
 
D:/lode/dev/core/sw/qa/extras/ooxmlexport/ooxmllinks.cxx:185:testRelativeToRelativeExport::Import_Export_Import
24732
 
NEXT
assertion failed
24733
 - Expression: sTarget.startsWith("../")
24734
24735
 testRelativeToRelativeExport::Import_Export_Import finished in: 358ms
24736
 File tested,Execution Time (ms)
24737
 relative-link.docx:
24738
 172
24739
 testRelativeToRelativeImport::Import finished in: 188ms
24740
 File tested,Execution Time (ms)
24741
 relative-link.docx:
24742
 171
24743
 testRelativeToAbsoluteImport::Import finished in: 187ms
24744
 File tested,Execution Time (ms)
24745
 absolute-link.docx:
24746
 437
24747
 testAbsoluteToRelativeExport::Import_Export_Import finished in: 452ms
24748
 File tested,Execution Time (ms)
24749
 relative-link.docx:
24750
 

CppunitTest testFlipAndRotateCustomShape failing on certain setups

[Luke Benes]

My desktop and @39 have been failing ever since the additional Unit Tests were 
enabled with
https://cgit.freedesktop.org/libreoffice/core/commit/?id=3f7e8ddea89f6340cd18b5b34f5a7c5f503962be

Here is a sample of @39 failure:
https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1562722611.14107

I'm seeing the same on my desktop:

H:/cygwin/home/Luke/lode/dev/core/test/source/xmltesttools.cxx(168) : error : 
Assertion
Test name: testFlipAndRotateCustomShape::Import_Export_Import
equality assertion failed
- Expected: 2351
- Actual  : 2352
- In , attribute 'x' of 
'//a:custGeom/a:pathLst/a:path/a:lnTo[1]/a:pt' incorrect value.

Failures !!!
Run: 112   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_sw_ooxmlexport7 CPPUNITTRACE=TRUE # which is a shortcut for 
the following line

Oddly my laptop with the same configuration (no configure options) passes this 
test. 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sw_ooxmlexport3 broken on HiDPI setup

[Luke Benes]

Ever since the additional unit tests were enabled with
https://cgit.freedesktop.org/libreoffice/core/commit/?id=3f7e8ddea89f6340cd18b5b34f5a7c5f503962be

The CppunitTest_sw_ooxmlexport3 unit test is failing when display scaling does 
not equal 100%


For 125% the test is failing with the following errors:



[build CUT] sw_ooxmlexport3
test_GIF_ImageCrop.docx:
D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx:704:testGIFImageCrop::Import
equality assertion failed
- Expected: 1085
- Actual  : 868

testGIFImageCrop::Import finished in: 689ms
File tested,Execution Time (ms)
test_GIF_ImageCrop.docx:
D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx:704:testGIFImageCrop::Import_Export_Import
equality assertion failed
- Expected: 1085
- Actual  : 868

File tested,Execution Time (ms)
E:  file lt-string.c: line 189: assertion `string != ((void *)0)' failed
E:  sfile lt-string.c: line 189: assertion `string != ((void *)0)' failed
E:  sfile lt-string.c: line 189: assertion `string != ((void *)0)' failed
E:  l)file lt-string.c: line 189: assertion `string != ((void *)0)' failed
mce.docx:
420
testMce::Import finished in: 440ms
test_PNG_ImageCrop.docx:
D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx:722:testPNGImageCrop::Import
equality assertion failed
- Expected: 1058
- Actual  : 847

testPNGImageCrop::Import finished in: 385ms
File tested,Execution Time (ms)
test_PNG_ImageCrop.docx:
D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx:722:testPNGImageCrop::Import_Export_Import
equality assertion failed
- Expected: 1058
- Actual  : 847

tdf106974_int32Crop.docx:
D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx:578:testTdf106974_int32Crop::Import
assertion failed
- Expression: sal_Int32( 40470 ) < aGraphicCropStruct.Right
- 37107

testTdf106974_int32Crop::Import finished in: 454ms
File tested,Execution Time (ms)
tdf106974_int32Crop.docx:
D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx:578:testTdf106974_int32Crop::Import_Export_Import
assertion failed
- Expression: sal_Int32( 40470 ) < aGraphicCropStruct.Right
- 37110

testTdf106974_int32Crop::Import_Export_Import finished in: 2363ms

floatingtbl_with_formula.docx:
1856
testFileOpenInputOutputError::Import_Export_Import finished in: 1881ms
D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx(704) : error : Assertion
Test name: testGIFImageCrop::Import
equality assertion failed
- Expected: 1085
- Actual  : 868

D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx(704) : error : Assertion
Test name: testGIFImageCrop::Import_Export_Import
equality assertion failed
- Expected: 1085
- Actual  : 868

D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx(722) : error : Assertion
Test name: testPNGImageCrop::Import
equality assertion failed
- Expected: 1058
- Actual  : 847

D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx(722) : error : Assertion
Test name: testPNGImageCrop::Import_Export_Import
equality assertion failed
- Expected: 1058
- Actual  : 847

D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx(578) : error : Assertion
Test name: testTdf106974_int32Crop::Import
assertion failed
- Expression: sal_Int32( 40470 ) < aGraphicCropStruct.Right
- 37107

D:/core/sw/qa/extras/ooxmlexport/ooxmlexport3.cxx(578) : error : Assertion
Test name: testTdf106974_int32Crop::Import_Export_Import
assertion failed
- Expression: sal_Int32( 40470 ) < aGraphicCropStruct.Right
- 37110

Failures !!!
Run: 90   Failure total: 6   Failures: 6   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_sw_ooxmlexport3 CPPUNITTRACE=TRUE # which is a shortcut for 
the following line
make CppunitTest_sw_ooxmlexport3 CPPUNITTRACE="'C:/Program Files 
(x86)/Microsoft Visual Studio/2017/Community/Common7/IDE/devenv.exe' /debugexe" 
# for interactive debugging in Visual Studio
make CppunitTest_sw_ooxmlexport3 CPPUNITTRACE="drmemory -free_max_frames 20" # 
for memory checking (install Dr.Memory first, and put it to your PATH)

You can limit the execution to just one particular test by:

make CppunitTest_sw_ooxmlexport3 CPPUNIT_TEST_NAME="testXYZ" ...above mentioned 
params...

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Jenkins_Callgrind broken after: Drop extra define ENABLE_GTKSINK

[Luke Benes]

Michael,

https://cgit.freedesktop.org/libreoffice/core/commit/?id=34bbf192a7753205bb64d14e4eec4ce303317396

broke Jenkins_Callgrind 
https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1559555453.4509

https://ci.libreoffice.org/computer/vm139/builds

with this error:
avmedia/source/gstreamer/gstplayer.hxx:33:14: fatal error: gtk/gtk.h: No such 
file or directory


Does Jenkins_Callgrind need to be upgraded?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Need for new x86 Jenkin's Bot

[Luke Benes]

Christian,

Our concern is that by scuttling @87, we will lose important diversity in TDF's 
testing infrastructure. While upgrading @87 does address this, it is not what 
we are asking for.

Why have you chosen to not upgrade @87 like you have the others? Master will 
build on x86 Fedora 30, Cent OS 7, and should on Cent OS 6 with the 
devtoolset-7 found here: 
https://copr-be.cloud.fedoraproject.org/results/mlampe/devtoolset-7/epel-6-i386/


I can help you with this or setting up a new Jenkins bot. However, I cannot 
provide the hardware nor network resources for this purpose. Providing 
resources to keep our codebase healthy is at the heart of TDF’s mission.  If 
@87 can not longer be used for baseline binaries, it should be used for this 
purpose.

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Need for new x86 Jenkin's Bot

[Luke Benes]

Christian,


The decision was to demote release builds, but NOT to remove x86 compatibility. 
If you take this as an excuse to also end x86 CI testing bots, you are 
effectively killing x86 through bit rot. This is not a hypothetical. As you 
know, @87 just recently caught a regression introduced by an easyHack to 
convert use of sal_uLong to better integer types. Without CI testing, these 
bugs will pile up effectively removing x86 compatibility.


In a past job, I have seen how building code against multiple architectures 
uncovers latent bugs and code portability. This philosophy made ARM and RISC 
ports much easier along with higher quality software.


If we chose to go down the path of killing x86, we should discuss it. While I 
agree that overhead of x86 release build may not be worth it, the advantages of 
maintaining a working x86 build are clear.  My suggestion would be to upgrade 
@87 to CentOS 7 or Debian 9.0 before bit rot makes this a difficult task. 
Currently master has no problem building on 32-bit Fedora 30.


-Luke


From: Christian Lohmaier 
Sent: Tuesday, June 4, 2019 6:17 AM
To: Luke Benes
Subject: Re: @87 reboot?

Hi Luke,

On Sun, Apr 14, 2019 at 6:40 PM Luke Benes  wrote:
>
> Christian,
> No rush, just a polite ping. Looks like @87 is stuck.

It's not really stuck per se, it is just that the old baseline is no
longer suitable for master/libreoffice-6-3 (glib2 requirement not
fullfilled) - with 6.2 we demoted 32bit linux builds provided by TDF
(they for example already don't include all vclplugins, most notably
gtk3) and stated that 6.2 will be last line with 32bit builds provided
by TDF (of course distros continue to provide buidls, and 32bit
support in sourcecode is not removed).

So unless there's an outcry of users there won't be master buidls by
that box anymore - (well even if there is there won't be, but rather
32bit version then would be cross-compiled from a 64bit host)

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [ABANDONED] Re: Build fail on Libgpg-error on Windows with gawk 5.0

[Luke Benes]

This long weekend, I attempted to update the patch for libgpg-error-1.36. This 
went well until I hit a new file in 1.36, sysutils.c, which makes use of  a 
UNIX header .  Thorsten converted this to a win32's  in other 
files,[1] but following his example didn't work for me here.

We really need to get libgpg-error updated so that anyone upgrading LODE or 
doing a new install can have a working Windows build.  Unfortunately, I'm out 
of time for this week, so someone else is going to have to take over from here. 
I'd be glad to share my patch if you want to save a few min. 

-Luke

[1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=4be15fdd7974
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [ABANDONED] Re: Build fail on Libgpg-error on Windows with gawk 5.0

[Luke Benes]

Thorsten fixed it. It's working now for me. Thanks!
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [ABANDONED] Re: Build fail on Libgpg-error on Windows with gawk 5.0

[Luke Benes]

https://dev-www.libreoffice.org/src/libgpg-error-1.36.tar.bz2

I'm getting:  403 Forbidden Error

https://dev-www.libreoffice.org/src/libgpg-error-1.27.tar.bz2

Correctly downloads the tarball

After the 403 issue with 1.36 is fixed, I'll be happy to create a patch to 
update download.lst and attempt to fix any resulting issues.

However, this is an urgent issue. LODE is a key component of LO's developer 
infrastructure. It's what new users are directed to use, and existing users 
like myself are forced to update it when component levels are bumped. (I was 
forced to update as gperf-3.0.4-2 is no longer sufficient to build master.) If 
we can't get LODE working soon, we should ask the ESC for assistance. 

-Luke











From: Thorsten Behrens 
Sent: Wednesday, May 22, 2019 12:42 AM
To: slacka
Cc: libreoffice@lists.freedesktop.org
Subject: Re: [ABANDONED] Re: Build fail on Libgpg-error on Windows with gawk 5.0
  

Hi Luke,

slacka wrote:
> Can we update this tarball so that new LODE installs can work again?
>
I've uploaded the tarball to
https://dev-www.libreoffice.org/src/libgpg-error-1.36.tar.bz2 - want
to have a go at updating the reference in download.lst (and
potentially tweaking a few patches)?

Cheers,

-- Thorsten

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppUnit SdMiscTest::testTdf119956 Failing on Windows with 150% scale factor

[Luke Benes]

While testing various scaling factors for the starmath issue,
http://document-foundation-mail-archive.969070.n3.nabble.com/CppunitTest-starmath-qa-cppunit-Failing-on-Windows-with-HiDPI-screens-tp4261772.html

I discovered that  SdMiscTest::testTdf119956 is also failing. 

Any ideas why this test would also be dpi dependent? 

The build log is below. Would you like any additional debugging info?


-Luke

[build CUT] sd_misc_tests
SdMiscTest::testTdf67248 finished in: 1086ms
D:/core/sd/qa/unit/misc-tests.cxx:777:SdMiscTest::testTdf119956
equality assertion failed
- Expected: 3
- Actual  : 0

SdMiscTest::testTdf119956 finished in: 1851ms
SdMiscTest::testTdf120527 finished in: 500ms
D:/core/sd/qa/unit/misc-tests.cxx(777) : error : Assertion
Test name: SdMiscTest::testTdf119956
equality assertion failed
- Expected: 3
- Actual  : 0

Failures !!!
Run: 15   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_sd_misc_tests CPPUNITTRACE=TRUE # which is a shortcut for the 
following line

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppunitTest_starmath_qa_cppunit Failing on Windows with HiDPI screens

[Luke Benes]

Thanks Noel! Yes, that fixed it. I tested with 125, 150, 175, and 200% scale 
factors. At 175%, nWidthA = .28 was the highest value I recorded.

Does this issue look like a rounding problem in the tests or are they showing a 
problem with LO's HiDPI implementation?


-Luke


From: Noel Grandin 
Sent: Sunday, May 19, 2019 6:22 AM
To: Luke Benes
Cc: noel.gran...@collabora.co.uk; Libreoffice Dev List
Subject: Re: CppunitTest_starmath_qa_cppunit Failing on Windows with HiDPI 
screens


should be fixed with
https://cgit.freedesktop.org/libreoffice/core/commit/?id=8265e36cdcaa475282344c2e01bee5e323d0f0a0


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_starmath_qa_cppunit Failing on Windows with HiDPI screens

[Luke Benes]

After commit: 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=13894996601d
handle empty Rectangle better in starmath

Windows builds on machines with display scaling enabled are failing. In my 
testing only a 100% scale factor is working. 

Here is a sample build log with Display Scale = 125%

[build CUT] starmath_qa_cppunit
C:/core/starmath/qa/cppunit/test_node.cxx:88:`anonymous 
namespace'::NodeTest::testTdf47813
double equality assertion failed
- Expected: 1
- Actual  : 1.02524038461538
- Delta   : 0.02


`anonymous namespace'::Test::viewZoom finished in: 30ms
C:/core/starmath/qa/cppunit/test_node.cxx(88) : error : Assertion
Test name: `anonymous namespace'::NodeTest::testTdf47813
double equality assertion failed
- Expected: 1
- Actual  : 1.02524038461538
- Delta   : 0.02

Failures !!!
Run: 44   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_starmath_qa_cppunit CPPUNITTRACE=TRUE # which is a 

Would you like any additional debugging info to track down this problem?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Clang trunk build failure in external/librevenge

[Luke Benes]

Stephan,
Comparing to a good workdir/UnpackedTarball/librevenge/config.log,
This seems to be the problem:

In file included from 
/core/workdir/UnpackedTarball/boost/boost/spirit/home/classic/attribute/closure.hpp:24:
/core/workdir/UnpackedTarball/boost/boost/spirit/home/classic/phoenix/operators.hpp:404:19:
 error: use 'template' keyword to treat 'value' as a dependent template name
rank::value < rank::value,
  ^
  template 
/core/workdir/UnpackedTarball/boost/boost/spirit/home/classic/phoenix/operators.hpp:404:9:
 error: missing 'typename' prior to dependent type name 
'rank::rank::value::value, T1, T0>::type'
rank::value < rank::value,
^~
typename 
/core/workdir/UnpackedTarball/boost/boost/spirit/home/classic/phoenix/operators.hpp:405:23:
 error: expected '>'
T1, T0>::type type;
  ^
The full log can be found here: https://pastebin.com/ES3BG9DA

Any ideas what's going wrong? 

-Luke

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Jenkins_Callgrind failing with error: use of deleted function

[Luke Benes]

After commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a361231b1363

fix wrong SET/QUERY flags passed to uno::Reference

Jenkins_Callgrind is failing with the following error:

/lo_callgrind_linux/sc/qa/perf/scperfobj.cxx:623:87: error: use of deleted 
function ‘com::sun::star::uno::Reference<  
>::Reference(const com::sun::star::uno::Reference<  >&, 
com::sun::star::uno::UnoReference_QueryThrow) 

For detailed log:
https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1557756030.19348
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Clang trunk build failure in external/librevenge

[Luke Benes]

After commit: http://llvm.org/viewvc/llvm-project?view=revision=360308

Clang builds are failing on both Arch and Ubuntu with the following error:

checking for boost/spirit/include/classic.hpp... no
configure: error: Required boost headers not found.
make[1]: *** [/core/external/librevenge/ExternalProject_librevenge.mk:23:  
/core/workdir/ExternalProject/librevenge/build] Error 1
make[1]: *** Waiting for unfinished jobs
32 warnings generated.
114 warnings generated.
40 warnings generated.
make: *** [Makefile:282: build] Error 2

Does this look like a compiler bug or issue with our build system?


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Luke Benes]

Guilthem,
Why have you not answered my question about returning the Commit Bot back to 
cgit? 

Gitiles is wasting our time. For example, just now I followed the commit bot 
link on tdf#42949 to 

https://gerrit.libreoffice.org/plugins/gitiles/core/+log/63a25b79f18fda29cd744add813ce9508c69b996/sw/source/core/inc/dflyobj.hxx

In North America the paged timed out while trying to load. So I had to stop 
open cgit, and manually construct this link:

https://cgit.freedesktop.org/libreoffice/core/log/sw/source/core/inc/dflyobj.hxx

Which surprise, surprise loaded instantly. Why must we use inferior tools that 
slow down our workflow for QA and developers? At least in QA, most of us are 
volunteers that would rather not spend our time copy and pasting to use the 
tools that we all prefer. Please return the bot to cgit. 

Follow the links below and you will see that both developers and QA are 
currently pasting cgit links into our bug tracker.

Xisco: https://bugs.documentfoundation.org/show_bug.cgi?id=124410
Gabor: https://bugs.documentfoundation.org/show_bug.cgi?id=124319
Julien: https://bugs.documentfoundation.org/show_bug.cgi?id=122821
Chih-Hsuan: https://bugs.documentfoundation.org/show_bug.cgi?id=123595
Aron: https://bugs.documentfoundation.org/show_bug.cgi?id=122509

From a QA workflow perfective, Gitiles is inferior in every way. On IRC -dev no 
devs spoke out in favor of Gitiles over cgit, and here the best defence from a 
developer here has been "it doesn't hurt". Please put back cgit to allow us to 
work more efficiently. 

Thanks

-Luke


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Luke Benes]

It is telling that when I asked what you prefer, you answered that the 
extraneous information “doesn't hurt “. Your tolerance to noise may be higher 
than many, but it’s a well-established fact the less clutter in the UI, the 
faster it is for humans to use.  Gitiles is fails here, takes longer to load, 
requires additional clicks, and is missing search tools and branch tags.

-Luke


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Luke Benes]

Mike,
That is not an apples to apples comparison. In your browser open and compare 
side-by-side:

https://git.libreoffice.org/core/+/6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
and
https://cgit.freedesktop.org/libreoffice/core/commit/?id=6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a

Do you really like all of the extraneous information? Do you like the missing 
search bar? Do you like having to scroll down several pages to see the relevant 
information? Do you like the lack of a search bar? 

Besides the fact, these are not what the commits look like on our bug trackers. 
From 

https://git.libreoffice.org/core/+/bf2f0c913774c90e4c9a65119d0219187bb4498c%5E%21
while the old cgit would be 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=bf2f0c913774c90e4c9a65119d0219187bb4498c

Now try to copy the commit ID from the gitiles and do the same for the cgit 
URL. Do you really prefer the random symbols appended to the end? I can tell 
you git does not and will puke if you accidentally include any of them. 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Luke Benes]

Guilhem,

There is something wrong with your benchmark methodology.

This cgit page loads in under 1 second:

https://cgit.freedesktop.org/libreoffice/core/log/sw/source/filter/ww8/docxattributeoutput.cxx?ofs=50

While
https://gerrit.libreoffice.org/plugins/gitiles/core/+log/2d6f8c36126effc66ea35af2e65da6609fcfe013/sw/source/filter/ww8/docxattributeoutput.cxx?s=be8c414567f49242164b1fdfb12764b16be355c1

takes almost 20 seconds to load in North America. If you are not seeing these 
results, press next to see the older commits to avoid caching masking gitiles 
slowness.

No one in QA and no developers have voiced a preference for gitiles. Because 
it's slower, it's UI and UX is harder to read, it lacks useful tools like 
search,  and the URLs are a pain to work with. It's inferior in every way.

So please change the Commit Bot back to cgit.

Thanks

-Luke



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

[Luke Benes]

Switching to hub redirection solves the annoying symbols that Gitiles appends 
to URLs leading to copy and paste errors and the timestamp issue. But it does 
not address:

* Lack of Built-in, easy to use search functionality
* Lack of branch tags, allowing you to see what release you are on when going 
through the master log
*cgit is a cleaner, easier to read interface

I have noticed that both QA and Developers continue to post cgit links on the 
bug tracker. When I have asked on IRC, no developers or QA members voiced 
support for using Gitiles. 

So unless someone has some compelling reasons to keep it, I respectfully ask 
that the Commit Notification Bot be switch back to cgit. We have tried to use 
it, and as far as I can tell, universally dislike it.

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Japanese and Korean Fonts Requirements for building on Arch

[Luke Benes]

On a fresh install of Arch, I installed the 
https://wiki.documentfoundation.org/Development/Linux_Build_Dependencies  
requirements. During the build I get the following notification:

Additional Fonts Required
An application is requesting additional fonts. 

Clicking on the notification, the Software center says, "Japanese and Korean 
you were searching for could not be found"

What fonts do I need?


The message pops up during this part of the build:

[SCK] smoketest
[PYT] solenv_python
[SCK] sot
[SCK] starmath
[JUT] svl_complex
[SCK] svtools
[SCK] svx
[SCK] sw
[SCK] toolkit
[SCK] ucb
[SCK] unotools
[SCK] unoxml
[SCK] xmloff
[UIT] cui
[UIT] sc
[UIT] sd
[UIT] sw






___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

[Luke Benes]

Could you please change the Commit Notification bot back to cgit? 

In the 6 months, that I have been testing gitiles, I have found no advantages 
and many disadvantages over cgit. In general, it presents information in an 
inferior way and it’s URL’s have led to multiple copy  and paste errors, 
causing delays in work when the errors were missed.

In his last email, Mike explains how the gitiles timestamps lead to confusion. 
This is a serious problem for my use case. The other major problem, are the 
random symbols like “^!” appended to the ends of commit IDs in URLs. I’ve been 
copy and pasting commit IDs from cgit for years and never once had a problem. 
With gitiles, it happens regularly despite me being aware.

When I asked for feedback on the IRC dev channel, no one voiced preference for 
gitiles. I only heard agreement that the URLs and log format are inferior to 
cgit's.  

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_chart2_dump Unit Test Failure

[Luke Benes]

Hey Mike,
After 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=166a4989a0d1e5a6271c66bceb73a27970afc882

tdf#123504: 0 and 360 are different angles in charts

My 32-bit Windows  box is failing with the following error:

ChartDataTest::verify finished in: 2796ms
PivotChartDataButtonTest::verify finished in: 962ms
PointLineChartTest::verify finished in: 15087ms
GridTest::verify finished in: 5035ms
AxisLabelTest::verify finished in: 3948ms
AxisGeometryTest::verify finished in: 8078ms
D:/core/chart2/qa/extras/chart2dump/chart2dump.cxx:902:PieChartTest::verify
double equality assertion failed
- Expected: 3210
- Actual  : 3207
- Delta   : 0.1
- Failing test file is: pie_chart_100_and_0.ods

PieChartTest::verify finished in: 8407ms
ColumnBarChartTest::verify finished in: 10112ms
D:/core/chart2/qa/extras/chart2dump/chart2dump.cxx(902) : error : Assertion
Test name: PieChartTest::verify
double equality assertion failed
- Expected: 3210
- Actual  : 3207
- Delta   : 0.1
- Failing test file is: pie_chart_100_and_0.ods

Failures !!!
Run: 11   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_chart2_dump CPPUNITTRACE=TRUE # which is a shortcut for the 
following line
make CppunitTest_chart2_dump CPPUNITTRACE="'C:/Program Files (x86)/Microsoft 
Visual Studio/2017/Community/Common7/IDE/devenv.exe' /debugexe" # for 
interactive debugging in Visual Studio
make CppunitTest_chart2_dump CPPUNITTRACE="drmemory -free_max_frames 20" # for 
memory checking (install Dr.Memory first, and put it to your PATH)

You can limit the execution to just one particular test by:

make CppunitTest_chart2_dump CPPUNIT_TEST_NAME="testXYZ" ...above mentioned 
params...

make[1]: *** [D:/core/solenv/gbuild/CppunitTest.mk:114: 
D:/core/workdir/CppunitTest/chart2_dump.test] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:282: build] Error 2

Would you like any more debug info or info about my system?

Thanks

-Luke


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Cygwin 3.0.0-1 Released

[Luke Benes via LibreOffice]

Info on this major release can be found here:
https://cygwin.com/ml/cygwin/2019-02/msg00229.html

Do any of these improvements look beneficial to LibreOffice? 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Windows Unit TestSwLayoutWriter::testBtlrCell Failing

[Luke Benes via LibreOffice]

Ever since:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a0bb480364c80192111ecab3501d63584e651ea3
or 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=bef3818dbedba467a257e2573e298d98062be37b

The build is failing with:

C:/core/test/source/xmltesttools.cxx:139:SwLayoutWriter::testBtlrCell
equality assertion failed
- Expected: 2707
- Actual  : 2710
- In <>, attribute 'y' of '//textarray[1]' incorrect value.

SwLayoutWriter::testBtlrCell finished in: 132ms
C:/core/test/source/xmltesttools.cxx(139) : error : Assertion
Test name: SwLayoutWriter::testBtlrCell
equality assertion failed
- Expected: 2707
- Actual  : 2710
- In <>, attribute 'y' of '//textarray[1]' incorrect value.

Failures !!!
Run: 39   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_sw_layoutwriter CPPUNITTRACE=TRUE # which is a shortcut for 
the following line
make CppunitTest_sw_layoutwriter CPPUNITTRACE="'C:/Program Files 
(x86)/Microsoft Visual Studio/2017/Community/Common7/IDE/devenv.exe' /debugexe" 
# for interactive debugging in Visual Studio
make CppunitTest_sw_layoutwriter CPPUNITTRACE="drmemory -free_max_frames 20" # 
for memory checking (install Dr.Memory first, and put it to your PATH)

You can limit the execution to just one particular test by:

make CppunitTest_sw_layoutwriter CPPUNIT_TEST_NAME="testXYZ" ...above mentioned 
params...

make[1]: *** [C:/core/solenv/gbuild/CppunitTest.mk:114: 
C:/core/workdir/CppunitTest/sw_layoutwriter.test] Error 1
make: *** [Makefile:167: CppunitTest_sw_layoutwriter] Error 2


64-bit build 
CPU threads: 4; OS: Windows 10.0; UI render: default; 
GPU Intel HD 4000

Would you like any more debug info?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Bug around legend of a pie chart

[Luke Benes]

There are many legend/title overlapping import issues on the bug tracker. The 
only universal solution will be to teach the chart engine the concept of not 
allowing overlapping legend/title and allow the importers to use this.

Awhile back Markus made some progress in this area. The basic work has already 
been done, but it has to be flushed out and extended with UNO API etc.

See:
https://bugs.documentfoundation.org/show_bug.cgi?id=90730

and
https://bugs.documentfoundation.org/show_bug.cgi?id=75330





___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_chart2_xshape Failure with Display Scaling on Windows

[Luke Benes]

Mike,
The fix for Bug 
121685, 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=7263d223ddf4
​
Is causing the core Unit Test CppunitTest_chart2_xshape to fail when you set,  
Settings->Display->Scale=125%​
​
Setting Scale=100% allows the build to pass with no errors. ​
​
Build log:​
https://pastebin.com/SpSiCm6u

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Subsequent Unit Test CppunitTest_sc_ddelinkobj Failing Under Windows

[Luke Benes]

'make check' builds are failing on both of my Windows 10 boxes are failing 
after:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=63ff8602c16b
tdf#45904 Move XRefreshable Java tests to C++

With this failure:
https://pastebin.com/bvafeEUv

[build CUT] sc_ddelinkobj
D:/core/test/source/util/xrefreshable.cxx:61:sc_apitest::ScDDELinkObj::testRefresh
assertion failed
- Expression: xListener->m_bListenerCalled

D:/core/test/source/util/xrefreshable.cxx:72:sc_apitest::ScDDELinkObj::testRemoveRefreshListener
assertion failed
- Expression: xListener->m_bListenerCalled

com::sun::star::script::XLibraryContainer> &,const class 
com::sun::star::uno::Reference &)
type: com.sun.star.lang.IllegalArgumentException

sc_apitest::ScDDELinkObj::testRemoveRefreshListener finished in: 10836ms
D:/core/test/source/util/xrefreshable.cxx(61) : error : Assertion
Test name: sc_apitest::ScDDELinkObj::testRefresh
assertion failed
- Expression: xListener->m_bListenerCalled

D:/core/test/source/util/xrefreshable.cxx(72) : error : Assertion
Test name: sc_apitest::ScDDELinkObj::testRemoveRefreshListener
assertion failed
- Expression: xListener->m_bListenerCalled

Failures !!!
Run: 8   Failure total: 2   Failures: 2   Errors: 0
Error: a unit test failed, please do one of:
make CppunitTest_sc_ddelinkobj

Would you like any additional debugging info? 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Windows build failure - C2131: expression did not evaluate to a constant

[Luke Benes]

After commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=644188bf7f3a

Compute (un-)premultiply_table at compile time

I'm seeing the following build failure on Windows 32-bit release build:
D:/core/vcl/source/bitmap/BitmapTools.cxx(1078): error C2131: expression did 
not evaluate to a constant
D:/core/vcl/source/bitmap/BitmapTools.cxx(1097): error C2131: expression did 
not evaluate to a constant
make[1]: *** [D:/core/solenv/gbuild/LinkTarget.mk:293: 
D:/core/workdir/CxxObject/vcl/source/bitmap/BitmapTools.o] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:283: build] Error 2


Do I need to upgrade MSVC again? 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Tinberbox MacOSX-x86_64_49-TDF failure - ld: file not found

[Luke Benes]

In this range: 
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range=313a0efb1d703a36030a7e5e55bd308c7e4650f3..ae3309c908311248f1580a894f197732964bfac2

@49 started failing with: 

https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1543237201.21995

  [build LOC] vcl
  [build SED] CustomTarget/wizards/share/dialog.xlc
  [build SED] CustomTarget/wizards/share/script.xlc
  [build PKG] wizards_properties
  [build LOC] wizards
  [build LOC] writerperfect
  [build LOC] xmlsecurity
  [build CUS] instsetoo_native/setup
  [build LOC] external
  [build CHK] external
  [build SLC] external
  [build UPK] boost_1_66_0.tar.bz2
  [build LNK] Library/libuno_sal.dylib.3
  [build UPK] icu4c-63_1-src.tgz
  [build UPK] nss-3.38-with-nspr-4.19.tar.gz
  NEXTld: file not found: 
/Users/cloph/tb/workdir/CObject/sal/osl/unx/backtrace.o/Users/cloph/tb/workdir/CxxObject/sal/osl/all/compat.o/Users/cloph/tb/workdir/CxxObject/sal/osl/all/debugbase.o/Users/cloph/tb/workdir/CxxObject/sal/osl/all/filepath.o/Users/cloph/tb/workdir/CxxObject/sal/osl/all/loadmodulerelative.o/Users/cloph/tb/workdir/CxxObject/sal/osl/all/log.o/Users/cloph/tb/workdir/CxxObject/sal/osl/all/signalshared.o/Users/cloph/tb/workdir/CxxObject/sal/osl/all/utility.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/alloc_arena.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/alloc_cache.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/alloc_fini.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/alloc_global.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/bootstrap.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/byteseq.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/cipher.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/cmdargs.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/crc.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/digest.o/Users/cloph/tb/workdir/CxxObject/sal/rtl/hash.
7157  NEXTclang: error: linker command failed with exit code 1 (use -v to 
see invocation)
7158  NEXTmake[1]: *** 
[/Users/cloph/tb/instdir/LibreOfficeDev.app/Contents/Frameworks/libuno_sal.dylib.3]
 Error 1
7159  make[1]: *** Waiting for unfinished jobs
7160  NEXTmake: *** [build] Error 2


possibility caused by this commit?
https://cgit.freedesktop.org/libreoffice/core/commit/?id=ab9d95e6073d

Use -filelist with macOS linker


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: JunitTest_forms_unoapi_3 failing on Windows

[Luke Benes]

Unfortunately, the patch did not work. On both my win10 laptop and desktop, I'm 
still seeing a JunitTest_forms_unoapi_3 failure with a 'make check' on master. 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

JunitTest_forms_unoapi_3 failing on Windows

[Luke Benes]

Stephan,
After commit: 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=d5ed903618f2

Set CppunitTest-related env vars only during CppunitTest

I'm seeing Windows 'make check' fail with:
There were 2 failures:
1) test(org.openoffice.test.UnoApiTest)
com.sun.star.lang.DisposedException
at 
com.sun.star.lib.uno.environments.remote.JobQueue.removeJob(JobQueue.java:201)
at 
com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:308)
at 
com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:281)
at 
com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:81)
at 
com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:618)
at 
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:145)
at 
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:129)
at com.sun.proxy.$Proxy8.loadComponentFromURL(Unknown Source)
at util.SOfficeFactory.openDoc(SOfficeFactory.java:435)
at util.SOfficeFactory.createDrawDoc(SOfficeFactory.java:126)
at mod._forms.OHiddenModel.initialize(OHiddenModel.java:97)
at lib.TestCase.initializeTestCase(TestCase.java:67)
at base.java_fat.getEnv(java_fat.java:361)
at base.java_fat.executeTest(java_fat.java:174)
at org.openoffice.Runner.run(Runner.java:175)
at org.openoffice.test.UnoApiTest.test(UnoApiTest.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.junit.runner.JUnitCore.run(JUnitCore.java:117)
at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98)
at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53)
at org.junit.runner.JUnitCore.main(JUnitCore.java:45)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:392)
at com.sun.star.lib.uno.protocols.urp.urp.readBlock(urp.java:364)
at com.sun.star.lib.uno.protocols.urp.urp.readMessage(urp.java:96)
at 
com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.run(java_remote_bridge.java:92)
2) test(org.openoffice.test.UnoApiTest)
java.lang.AssertionError: expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.openoffice.test.OfficeConnection.tearDown(OfficeConnection.java:150)
at org.openoffice.test.UnoApiTest.tearDown(UnoApiTest.java:33)
at 

Seg fault on Windows in xmlsecurity_signing Unit Test

[Luke Benes]

Both my Windows box and @42 and @62 are failing with the following error:
[build CUT] xmlsecurity_pdfsigning
/usr/bin/sh: line 1:  8100 Segmentation fault  ( 
PATH="C:\core\instdir\program;C:\core\instdir\program;C:\core\workdir\LinkTarget\Library;C:\core\workdir\UnpackedTarball\cppunit\src\cppunit\ReleaseDll;$PATH"
 $W/LinkTarget/Executable/cppunittester.exe 
$W/LinkTarget/CppunitTest/test_xmlsecurity_signing.dll --headless 
"-env:BRAND_BASE_DIR=file:///$S/instdir" "-env:BRAND_SHARE_SUBDIR=share" 
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource" 
"-env:UserInstallation=file:///$W/CppunitTest/xmlsecurity_signing.test.user" 
"-env:CONFIGURATION_LAYERS=xcsxcu:file:///$I/share/registry 
xcsxcu:file:///$W/unittest/registry" 
"-env:UNO_TYPES=file:///$I/program/types.rdb 
file:///$I/program/types/offapi.rdb" 
"-env:UNO_SERVICES=file:///$W/Rdb/ure/services.rdb file:///$W/Rdb/services.rdb" 
-env:URE_INTERNAL_LIB_DIR=file:///$I/program -env:LO_LIB_DIR=file:///$I/program 
-env:LO_JAVA_DIR=file:///$I/program/classes --protector 
$W/LinkTarget/Library/unoexceptionprotector.dll unoexceptionprotector 
--protector $W/LinkTarget/Library/unobootstrapprotector.dll 
unobootstrapprotector --protector 
$W/LinkTarget/Library/vclbootstrapprotector.dll vclbootstrapprotector 
"-env:CPPUNITTESTTARGET=$W/CppunitTest/xmlsecurity_signing.test" ) > 
$W/CppunitTest/xmlsecurity_signing.test.log 2>&1
SigningTest::testDescription finished in: 1816ms

Error: a unit test failed, please do one of:
make CppunitTest_xmlsecurity_signing CPPUNITTRACE=TRUE 

https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1540911001.21480


The failure started in this range: 
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range=9ebcc7c9a21f33cf42146786e4463856d373f114..7b0f2ee441b0cbcb88f3020df40c49e7cd6f9fb1

Most likely this commit: 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9630a2dfc79b
external: upgrade libxmlsec to 1.2.27

Miklos,
Could you take a look at this?

-Luke





___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

[Luke Benes]

Now that gitiles is linked to bugzilla instead of cgit, I'm giving it a good 
workout. From a QA perspective, it's missing 2 key features that interfere with 
my workflow. 

The date gitiles displays in the log is the author date, rather than the much 
more useful commit date. When trying to track down regressions, you care about 
the order of commits, not when they were authored. 

Also, how do you search a range and author? I used both of these searches very 
often. Without them, gitiles shouldn't be the default. I keep finding myself 
manually switching back to cgit to access these. 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cppcheck: Reduction of False Positives: Manual Approach

[Luke Benes]

> It was mentioned that the correct way is to generate the proper project
> structure for cppcheck using our existing tools that generate IDE
> integrations (and they have correct include correct includes, deps and all).

Mike, 
Yes, agreed. But AFAIK, no one other than me is looking into this. Quite a few 
issues with the GbuildToIDE approach need to be solved.

In the meantime, our current cppcheck script generates tens of thousands of 
config errors (if run with check-config or verbose),reports hundred or possibly 
thousands of false positives, and is being called with depreciated parameters. 
These issues can be fixed now.

I am in the process of going through past cppcheck related commits to verify 
how many, if any at all, would be missed had we been using the '-I include/' 
parameter.  So far, I have not identified any. If the consensus is that you do 
want to improve the script with the manual approach, I will not continue 
testing. Please advise.

However, keep in mind that from the GbuildToJson output, any framework that is 
built in the future will also call cppcheck with the '-I include/' parameter. 
Therefore, if there is a bug with cppcheck not reporting valid errors when 
called this way, then that approach too will suffer too.

 



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cppcheck: Reduction of False Positives: Manual Approach

[Luke Benes]

> Was it not you how came up with the idea to reduce the false positives with 
> specifying the includes?



No, it was not my idea. On #cppcheck, I was told by danmar, the primary 
developer of cppcheck, that our script is using cppcheck incorrectly. Without 
being passed the same include locations as we pass the compiler, we should 
expect a large amount of garbage.



In fact, according to the developer, we should not get any False Postives if we 
call cppcheck correctly. He encouraged me to file bug reports for any FP that 
remain, once cppcheck is being run properly.



> The main point that this change seems to simply reduce the scope of cppcheck. 
> If this is the purpose then we can just run cppcheck on an empty file and so 
> we won't see any issue (all false positives will disappear).



Again, No my goal is to improve the Signal-to-noise. FPs can be dangerous as in 
tdf#96089 and make it much harder to spot real issues.



Currently, I am in the process of comparing old cppcheck fixes with and without 
the '-Iinclude' option.  So far, the three that I have checked would not be 
filtered out. In other words, had we been calling cppcheck the way I propose, 
these issues would have been much easier for developers to spot(4000 vs 500).


-Luke







___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cppcheck: Reduction of False Positives: Manual Approach

[Luke Benes]

In my first attempt to improve the quality of the cppcheck reports,  Tamás 
Zolnai pointed out that including every possible header resulted in some valid 
warnings not being reported.

Instead, how about just including only our primary include folder of ./include 
with the '-Iinclude' parameter? This reduced the warnings from 4005 to 523. 

You can see and compare the results by opening the 'index.html' file at 
https://drive.google.com/open?id=1HaCVA_udd044uwRNn3RiyGJ01pQdYjwn

It seems many valid variableScope warnings are still being omitted. I'm still 
looking into that. Are there any other categories of valid errors that are 
missing? Specific examples would be helpful. 

Overall, does this report have a higher signal-to-noise ratio than our current 
weekly report? 


The full command to generate the report was:
../cppcheck/cppcheck -D__GNUC__ -DBOOST_ERROR_CODE_HEADER_ONLY 
-DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DLINUX -DNDEBUG 
-DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -j4 -i 
external/ -i workdir/ -Iinclude --xml --suppressions-list=cppcheck_supp.txt 
--enable=all --max-configs=100  ./  2> ./err.xml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

After loplugin:staticvar in various, Jenkins_MacOSX failing

[Luke Benes]

After https://cgit.freedesktop.org/libreoffice/core/commit/?id=76dd28afc9c0
loplugin:staticvar in various

Jenkins_MacOSX is failing with:

toolkit/source/awt/vclxtoolkit.cxx:764:6: error: unused function 
´ComponentInfoCompare´ [-Werror,-Wunused-function]
895   bool ComponentInfoCompare( const ComponentInfo & lhs, const 
ComponentInfo & rhs)

https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1540205763.9476
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

After loplugin:staticvar in sw, Jenkins_Windows_Dbg failing

[Luke Benes]

After 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=4ba5b003b594f9eb6c9b185208bdb72aef8273d0
loplugin:staticvar in sw

 Jenkins_Windows_Dbg failing with

9  NEXT
C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win_dbg/sw/source/filter/html/svxcss1.cxx(3166):
 error C2065: ´CSS1PropEntryCompare´: undeclared identifier
7049  NEXTmake: *** [Makefile:286: build] Error 2

https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1540039069.23076
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Tinderbox @71 now failing with undefined reference to `SvMemoryStream::remainingSize()´

[Luke Benes]

After 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=b2cefc2e36925b4384eb0aea54aa2c6bcfb018a8
Most of the Linux tinderboxes went red.

This was fixed by 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=49c87270f7176312806d1759967c247a312f0acf

But @71 is still to failing with:

https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1539640808.27465

28887 
/tinderbox/buildslave/build/workdir/CxxObject/emfio/source/reader/mtftools.o: 
In function `SvStream::TellEnd()´:
2 
/tinderbox/buildslave/source/libo-master/include/tools/stream.hxx:276: 
undefined reference to `SvMemoryStream::remainingSize()´
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: how to set JAVA_HOME

[Luke Benes]

I first noticed this same error in Arch after a Java version upgrade. Then 
again after I upgraded Ubuntu from 16.04 to 180.4. 

My guess is that either this is an error in our autogen.sh Java detection logic 
or there was a change in the Java installer between Java 8 and Java 10.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sc_filters_test now failing on Jenkins_MacOSX

[Luke Benes]

It appears that a commit in this range:
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range=f6eee4f7966e09be82b51554ead4c4aac8c47457..9388d9b5d3bdbd649d164deb97cae756bb1d3de3
is causing:  Jenkins_MacOSX to fail with
 
1030  NEXTError: a unit test failed, please do one of:
1035  
1036  make CppunitTest_sc_filters_test CPPUNIT_TEST_NAME="testXYZ"1037  

1038  NEXT/solenv/gbuild/CppunitTest.mk:120: recipe for target 
´/workdir/CppunitTest/sc_filters_test.test´ failed
1039  NEXTmake[1]: *** [/workdir/CppunitTest/sc_filters_test.test] Error 1
1040  make[1]: *** Waiting for unfinished jobs
1041  NEXTMakefile:286: recipe for target ´build´ failed
1042  NEXTmake: *** [build] Error 2

https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERbrief-log=1538747835.14104

Any idea which commit might be the cause? All previous builds visible on the 
tinderbox master status page were successful for Jenkins_MacOSX. 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cppcheck: Reduction of False Positives: Manual Approach

[Luke Benes]

Maarten,
Thanks for your suggestion here and your earlier contributions to the Cppcheck 
Report. I agree that we should create the include file dynamically. However the 
approach used by your script seems like overkill. Cppcheck already finds that 
quoted includes like
#include "GraphicExportFilter.hxx"
.
Also when there seems to have been a coding style that all <> includes outside 
of /inc folders should be defined by their relative path. Cppcheck only 
complains about 4 missing includes that do not follow this pattern.(see my 
earlier email on oddball includes).

Unless, I'm missing something, I still prefer this approach:
$ find . -type d \( -name "inc" -o -name "include" \) |sort > inc.txt

inc.txt only has ~200 entries, where as  /tmp/tmpfile.txt has ~1,800 after 
sorting it.

-Luke

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Intermittent Unit Test Failure: VclComplexTextTest::testArabic

[Luke Benes]

Over the years, I've probably done several hundred windows builds. Until now I 
have never been bitten an intermittent Unit Test failures. This month, I have 
started to see fairly regular failure of VclComplexTextTest::testArabic 3 out 
of ~15 builds.

Here are 2 separate examples of the Jenkins_Windows Tinderbox seeing the same 
failure in the past 2 days:

https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1537871271.4910

https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1537949563.7757

Has anyone investigated this? Is there any way to search Jenkins logs to see 
when this failure first occurred? 

-Luke


[build CUT] drawinglayer_border
`anonymous namespace'::CanvasBitmapTest::runTest finished in: 841ms
C:/core/vcl/qa/cppunit/complextext.cxx:98:VclComplexTextTest::testArabic
equality assertion failed
- Expected: 72
- Actual  : 75

VclComplexTextTest::testArabic finished in: 971ms
VclComplexTextTest::testTdf95650 finished in: 527ms
C:/core/vcl/qa/cppunit/complextext.cxx(98) : error : Assertion
Test name: VclComplexTextTest::testArabic
equality assertion failed
- Expected: 72
- Actual  : 75

Failures !!!
Run: 3   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_vcl_complextext CPPUNITTRACE=TRUE # which is a shortcut for 
the following line
make CppunitTest_vcl_complextext CPPUNITTRACE="'C:/Program Files 
(x86)/Microsoft Visual Studio/2017/Community/Common7/IDE/devenv.exe' /debugexe" 
# for interactive debugging in Visual Studio
make CppunitTest_vcl_complextext CPPUNITTRACE="drmemory -free_max_frames 20" # 
for memory checking (install Dr.Memory first, and put it to your PATH)

You can limit the execution to just one particular test by:

[build DEP] LNK:CppunitTest/test_writerperfect_calc.dll
make CppunitTest_vcl_complextext CPPUNIT_TEST_NAME="testXYZ" ...above mentioned 
params...

[build LNK] CppunitTest/test_writerperfect_calc.dll
make[1]: *** [C:/core/solenv/gbuild/CppunitTest.mk:120: 
C:/core/workdir/CppunitTest/vcl_complextext.test] Error 1
make[1]: *** Waiting for unfinished jobs
   Creating library 
C:/core/workdir/LinkTarget/CppunitTest/itest_xmloff_uxmloff.lib and object 
C:/core/workdir/LinkTarget/CppunitTest/itest_xmloff_uxmloff.exp
make: *** [Makefile:286: build] Error 2

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cppcheck: Reduction of False Positives: Manual Approach

[Luke Benes]

As I mentioned before, by manually specifying  includes and preprocessor 
configurations, I was able to reduce the number of warning from ~9000 to 30.

https://drive.google.com/file/d/1Ai_Zcj18cdQxVIQESb4lJr5K9LnzjnpW/view?usp=sharing

You can view it by unzipping and opening 'index.html'.

Caolán or Stephan,
Could either one of you take a quick pass at this to see if my improvements are 
useful? 

If this is useful, I could modify the weekly Cppcheck Report script to include 
these improvements. Who could set me up with permissions?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Hello, I am Interested in Helping Libre Office

[Luke Benes]

Thanks for your offer to  help with LibreOffice. Based on your experience you 
could help us with QA and documentation.


First, I would recommend you create an account in Bugzilla [1], where all bugs 
are reported and triaged.


Then, depending on your interests, you can either start helping with any of the 
tasks listed in the getInvolved page [2], or do manual tests using testlink [3]


You could also just want to do ad hoc testing, download the latest daily build 
for your platform from here [5] and install it.

You can find more information about the QA Team in our wiki page[6], and if you 
need any help doing QA, don't hesitate to contact the team via IRC [7], 
Telegram [8] or the mailing list [9].


[1] https://bugs.documentfoundation.org/

[2] https://wiki.documentfoundation.org/QA/GetInvolved

[3] https://wiki.documentfoundation.org/TestLink

[5] http://dev-builds.libreoffice.org/daily/master/

[6] https://wiki.documentfoundation.org/QA

[7]. https://wiki.documentfoundation.org/QA/IRC

[8]. https://t.me/LibreOffice_QA

[9]. https://wiki.documentfoundation.org/QA/Mailing_List

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: clang-8: error: unknown argument: '-flto-partition=none' when building lxml

[Luke Benes]

> uses $$CFLAGS (i.e., whathever the CFLAGS env var is set to
in the shell run by `make`) 

It's not coming from shell CFLAGS. I have searched all shell and environment 
variables with:
$( set -o posix ; set ) | less
And nothing has a '-flto-partition=none'  

Any other ideas on where to find this or how to override it?

This is definitely distro specific, as Ubuntu still works fine. Also, it was a 
fairly recent change in Arch. Could it have happened when I upgraded gcc, or if 
not what might it be?

Thanks,

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Jenkins_Callgrind failing on CppunitTest_sw_layoutwriter and CppunitTest_sw_uiwriter

[Luke Benes]

Some commit in this range:
https://cgit.freedesktop.org/libreoffice/core/log/?id=e625c64575216f787d7f534b90b6a7e7f981849f=range=761308edb65a6cf44ef84cebc387e77af8b70f83..e625c64575216f787d7f534b90b6a7e7f981849f

Has caused all recent Callgrind builds to fail with this error:
https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER=1536947713.2429


Noel,
Looks like your code clean up is responsible. Could you take a look?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Cppcheck: Reduction of False Positives: Manual Approach

[Luke Benes]

By manually specifying  includes and preprocessor configurations, I was able to 
reduce the number of warning from ~9000 to 30.

https://drive.google.com/file/d/1Ai_Zcj18cdQxVIQESb4lJr5K9LnzjnpW/view?usp=sharing

You can view it by unzipping and opening 'index.html'.Did this uncover any 
valid issues?

The command line used to scan our code base was:

$ cppcheck -j4 -DLINUX -D__GNUC__ -DUNX -DNDEBUG -DCORE_LITTLE_ENDIAN 
-D__LITTLE_ENDIAN__ -D__x86_64__ -UMACOSX -UFREEBSD -U_WIN32 -i external/ -i 
workdir/ --includes-file=inc.txt --xml --suppressions-list=cppcheck_supp.txt 
--enable=all --max-configs=100  ./  2 ./err.xml

inc.txt was generated with:
$ find . -type d \( -name "inc" -o -name "include" \) |sort  inc.txt

If this is useful, I could modify the weekly Cppcheck Report script to include 
these improvements. Who could set me up with permissions?

Ideally, the next step would be to extract the "DEFS": and "INCLUDE": from 
gbuild-to-ide and pass that to cppcheck. But that's for another time. 

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Best way to handle oddball header #includes for Cppcheck Report?

[Luke Benes]

I am in the process of  teaching cppcheck about our source tree. So far I have 
reduced the number of warnings from ~9000 to ~100. In order for our weekly 
Cppcheck Report to benefit from these, I need to automate the process. Here is 
the command I used to list all of our include directories:

$ find . -type d \( -name "inc" -o -name "include" \) |sort > inc.txt

This cuts the warning from 9000 to 300, but there are some oddball #includes 
that this misses. Here is an example from 'vcl/qt5/Qt5Bitmap.cxx':

#include <--- Include file:  not found.

The complete path of this file is: ./vcl/inc/qt5/Qt5Bitmap.hxx
And my script already taught cppcheck about: ./vcl/inc

So I need to manually add: vcl/inc/qt5

So my question is how should this be remedied? 

A) Change the include path to follow all 99% of the other include
like this: 
#include 

B) Move the include file to an include folder

C) Or Keep a list of these oddballs and append them the results of my find 
command?

D) Write a smarter find command. Ideas?

Is there a guideline on include naming?  Many of these oddballs seem to be in 
folders that have been recently moved around the source tree. (vcl/inc/qt5 was 
just moved a few months ago)

So far, here is a list of the oddball include locations needed outside of those 
my find command located:

#include  :  vcl/inc/qt5
#include  : chart2/qa/extras
#include  : avmedia/source/gstreamer
#include <: I forget :(> : include/rtl 

-Luke






___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice