Any ideas why lock files do not work in Chrome OS’ Linux VM?

[Paul Menzel]

Dear LibreOffice folks,


Wanting to run LibreOffice on a Google Chromebook with Chrome OS 
117.0.5938.157, one can enable the Linux development environment, a VM 
running Debian 11 (bullseye/oldstable), and install LibreOffice 7.0.4 
into it:


$ sudo apt update
$ sudo apt install libreoffice # 1:7.0.4-4+deb11u7

The German tutorial *LibreOffice unter Google Chrome OS auf einem 
Chromebook nutzen* [1] says to disable create of lock files by editing 
`/usr/lib/libreoffice/program/soffice` and commenting out the lines below:


SAL_ENABLE_FILE_LOCKING=1 export
SAL_ENABLE_FILE_LOCKING

Then, under expert settings `useLocking` and `UseDocumentOOoLockfile` 
need to be set to `false`.


Does somebody know, why this is needed? Could LibreOffice be improved to 
enable/disable file locking at runtime depending on the environment?



Kind regards,

Paul


[1]: 
https://linux-in-der-schule.de/2021/05/03/libreoffice-unter-google-chrome-os-auf-einem-chromebook-nutzen/

Cursor invisible or only half visible

[Paul Menzel]

Dear LibreOffice folks,


Just a quick note, that a user reported on an AMD Ryzen 3 2200G with 
Radeon Vega Graphics (family: 0x17, model: 0x11, stepping: 0x0) system 
using Debian sid/unstable with *libreoffice* 4:7.5.5-4 and GNOME Wayland 
session (*gnome-shell* 44.3-5 and *mutter* 44.3-7), around ten days ago 
the cursor was not visible anymore or only half visible in Libreoffice 
Writer and Calc. *libreoffice* in Debian sid/unstable was last updated 
on August 4th, so some other component must have introduced the regression.


But updating to *libreoffice* 4:7.6.1~rc1-1 from the Debian suite 
*experimental* fixed the issue.



Kind regards,

Paul

[Libreoffice-commits] core.git: external/nss

[Paul Menzel (via logerrit)]

 external/nss/ExternalProject_nss.mk |1 +
 1 file changed, 1 insertion(+)

New commits:
commit 33c96dcef9a729625d091d28db493318b7e21590
Author: Paul Menzel 
AuthorDate: Thu Aug 12 11:59:17 2021 +0200
Commit: Michael Stahl 
CommitDate: Fri Aug 13 13:20:23 2021 +0200

nss: fix build on ppc64le Linux

Change-Id: Id67afe505e97a4e2ac8502d32d9cdda475234b64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120386
Reviewed-by: Michael Stahl 
Tested-by: Jenkins

diff --git a/external/nss/ExternalProject_nss.mk 
b/external/nss/ExternalProject_nss.mk
index 81e5dfb45d3e..b0c4ae9f7c97 100644
--- a/external/nss/ExternalProject_nss.mk
+++ b/external/nss/ExternalProject_nss.mk
@@ -52,6 +52,7 @@ $(call gb_ExternalProject_get_state_target,nss,build): \
$(call gb_ExternalProject_run,build,\
$(if $(filter ANDROID FREEBSD LINUX MACOSX,$(OS)),$(if $(filter 
X86_64,$(CPUNAME)),USE_64=1)) \
$(if $(filter AARCH64,$(CPUNAME)),USE_64=1 CPU_ARCH=aarch64) \
+   $(if $(filter POWERPC64,$(CPUNAME)),USE_64=1 CPU_ARCH=ppc64le) \
$(if $(filter MACOSX,$(OS)),\
MACOS_SDK_DIR=$(MACOSX_SDK_PATH) \
NSS_USE_SYSTEM_SQLITE=1) \

Re: Build error with freebl: prtypes.h:556:38: error: size of array ‘arg’ is negative

[Paul Menzel]

Dear Michael,


Thank you for your reply.


Am 21.07.21 um 14:45 schrieb Michael Stahl:

On 20/07/2021 22.48, Paul Menzel wrote:

$ make
[…]
In file included from ../../../dist/out/include/prerror.h:9,
  from drbg.c:9:
drbg.c: In function ‘RNG_RandomUpdate’:
../../../dist/out/include/prtypes.h:556:38: error: size of array ‘arg’  is 
negative
   556 | extern void pr_static_assert(int arg[(condition) ? 1 : -1])
   |  ^~~ drbg.c:609:5: note: in 
expansion of macro ‘PR_STATIC_ASSERT’
   609 | PR_STATIC_ASSERT(sizeof(size_t) <= 4);
   | ^~~~


this is using the wrong branch...

in external/nss/ExternalProject_nss.mk there are these lines:

    $(if $(filter ANDROID FREEBSD LINUX MACOSX,$(OS)),$(if 
$(filter X86_64,$(CPUNAME)),USE_64=1)) \

    $(if $(filter AARCH64,$(CPUNAME)),USE_64=1 CPU_ARCH=aarch64) \


you probably need to add your CPU to the 1st one, or possibly even add 
one similar to the 2nd one, although it's not clear to me why setting 
CPU_ARCH is necessary in that case.


That did the trick.

diff --git a/external/nss/ExternalProject_nss.mk 
b/external/nss/ExternalProject_nss.mk

index 81e5dfb45d3e..b0c4ae9f7c97 100644
--- a/external/nss/ExternalProject_nss.mk
+++ b/external/nss/ExternalProject_nss.mk
@@ -52,6 +52,7 @@ $(call gb_ExternalProject_get_state_target,nss,build): \
$(call gb_ExternalProject_run,build,\
$(if $(filter ANDROID FREEBSD LINUX MACOSX,$(OS)),$(if 
$(filter X86_64,$(CPUNAME)),USE_64=1)) \
$(if $(filter AARCH64,$(CPUNAME)),USE_64=1 
CPU_ARCH=aarch64) \
+   $(if $(filter POWERPC64,$(CPUNAME)),USE_64=1 
CPU_ARCH=ppc64le) \

$(if $(filter MACOSX,$(OS)),\
MACOS_SDK_DIR=$(MACOSX_SDK_PATH) \
NSS_USE_SYSTEM_SQLITE=1) \

As I am not crosscompiling I am wondering, why this needs to be done.

Is LibreOffice using it’s own build script? I built upstream NSS with 
NSPR – I think all the components – with `make nss_build_all` without 
any problems.



Kind regards,

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

Build error with freebl: prtypes.h:556:38: error: size of array ‘arg’ is negative

[Paul Menzel]

Dear LibreOffice folks,


Building current master on Ubuntu 21.04 (ppc64le) fails:

```
$ gcc --version
gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
[…]
$ git describe --dirty
libreoffice-7-2-branch-point-1293-g1738f106bd73
$ make
[…]
In file included from ../../../dist/out/include/prerror.h:9,
 from drbg.c:9:
drbg.c: In function ‘RNG_RandomUpdate’:
../../../dist/out/include/prtypes.h:556:38: error: size of array ‘arg’ 
is negative

  556 | extern void pr_static_assert(int arg[(condition) ? 1 : -1])
  |  ^~~
drbg.c:609:5: note: in expansion of macro ‘PR_STATIC_ASSERT’
  609 | PR_STATIC_ASSERT(sizeof(size_t) <= 4);
  | ^~~~
make[7]: *** [../../coreconf/rules.mk:279: 
out/Linux_SINGLE_SHLIB/drbg.o] Error 1

make[6]: *** [Makefile:680: freebl_FREEBL_BUILD_SINGLE_SHLIB] Error 2
make[5]: *** [../coreconf/rules.mk:37: freebl] Error 2
[…]
```


Kind regards,

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

How to debug slow startup times?

[Paul Menzel]

Dear LibreOffice folks,


My parents, the most important users, noted slow startup times of 
LibreOffice. It turns out, that lots of installed fonts slow it down 
considerably [1].


Unrelated from this concrete issue, do you have tools to debug the 
startup time? I tried `strace -ff -ttt -o …`, but it turned out to be 
quite convoluted, but also pointed to some six seconds gap. Do you have 
tools or scripts to start LibreOffice with the right switches or 
programs, and print out the greatest offenders?


The current startup time is around four seconds now, which is still 
quite long compared to the OS starting up in less time.



Kind regards,

Paul


[1]: https://bugs.documentfoundation.org/show_bug.cgi?id=138831
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: I have wrote for a couple of hours something like 56 pages after that I have save it pressing the button Save many times and I the end I have discovered that my document had lost 50 + pages ,

[Paul Menzel]

Dear g adi,


Am 23.07.20 um 15:39 schrieb g adi:

[…]


Yesterday I have said that Lets create a Docx File using Libre so that It
will be compatible for my friends But It was a bad Idea to save it Docx
instead of Odt . It cost me a couple of hours of work .

I have wrote for a couple of hours something like 56 pages after that I
have save it  pressing the button Save many times and I the end I have
discovered that my document had lost 50 + pages ,
they were pics for my anatomy Notes , all my pics were gone just a little
Text had been save it .
very frustrating to lose my work for couple of hours .


[…]


if It Is causing Losing Pages 98 % of my pages mayne , 50 + pages with
pictures for Anatomy .


[…]


I have created an Index and the Text part remain and All The Anatomical
Pictures were Gone for Good unfortunately as you can see bellow.


I am sorry to hear about the incident. Can you please tell us the 
operating system and LibreOffice version, you are using?


Additionally, are only the pictures missing, or also text?


Kind regards,

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

Re: ppc64le: Build fails with `pngrutil.c:(.text+0x6658): undefined reference to `png_init_filter_functions_vsx'`

[Paul Menzel]

Dear Rene,


Am 20.07.20 um 22:05 schrieb Rene Engelhard:


Am 20.07.20 um 19:38 schrieb Rene Engelhard:



/home/pmenzel/src/core/workdir/LinkTarget/StaticLibrary/liblibpng.a(pngrutil.o):
in function `png_read_filter_row':
pngrutil.c:(.text+0x6658): undefined reference to
`png_init_filter_functions_vsx'
collect2: error: ld returned 1 exit status
make[1]: ***
[/home/pmenzel/src/core/desktop/Executable_oosplash.mk:10:
/home/pmenzel/src/core/instdir/program/oosplash] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:282: build] Error 2
```


Looks like it misses the VSX file for ppc64el. Similar case like
https://cgit.freedesktop.org/libreoffice/core/commit/?id=4855b5771f35ef354fbb5fb00a8cf690d5427c69


Untested patch:


diff --git a/external/libpng/StaticLibrary_libpng.mk
b/external/libpng/StaticLibrary_libpng.mk
index fe2364141b3b..2d56a276f6a7 100644
--- a/external/libpng/StaticLibrary_libpng.mk
+++ b/external/libpng/StaticLibrary_libpng.mk
@@ -38,6 +38,10 @@ $(eval $(call
gb_StaticLibrary_add_generated_cobjects,libpng,\
     UnpackedTarball/libpng/arm/filter_neon_intrinsics \
     UnpackedTarball/libpng/arm/palette_neon_intrinsics \
     ) \
+   $(if $(filter POWERPC POWERPC64,$(CPUNAME)), \
+   UnpackedTarball/libpng/powerpc/powerpc_init \
+   UnpackedTarball/libpng/powerpc/filter_vsx_intrinsics \
+   ) \
  ))
  
  # vim: set noet sw=4 ts=4:


Thank you very much.

Tested-by: Paul Menzel 


Kind regards,

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

ppc64le: Build fails with `pngrutil.c:(.text+0x6658): undefined reference to `png_init_filter_functions_vsx'`

[Paul Menzel]

Dear LibreOffice folks,


On ppc64le with Ubuntu 20.04 and latest LibreOffice from master, the 
build fails with the error below.


```
$ uname -m
ppc64le
$ git describe --dirty
libreoffice-7-0-branch-point-1865-g69a33480fe59
$ git log --oneline -1
69a33480fe59 (HEAD -> master) sw: silence 'not all control paths return 
a value'

$ ./autogen.sh
$ make -j100
[…]
[LNK] Executable/bestreversemap
[DEP] LNK:Executable/oosplash
[LNK] Executable/oosplash
[DEP] LNK:Executable/gendict
[LNK] Executable/gendict
[DEP] LNK:Executable/genconv_dict
[LNK] Executable/genconv_dict
[DEP] LNK:Library/libjpipe.so
[LNK] Library/libjpipe.so
[DEP] LNK:Executable/opencltest
[LNK] Executable/opencltest
[DEP] LNK:Executable/osl_process_child
[LNK] Executable/osl_process_child
[PAT] nss
[BIN] salhelper
/usr/bin/ld: 
/home/pmenzel/src/core/workdir/LinkTarget/StaticLibrary/liblibpng.a(pngrutil.o): 
in function `png_read_filter_row':
pngrutil.c:(.text+0x6658): undefined reference to 
`png_init_filter_functions_vsx'

collect2: error: ld returned 1 exit status
make[1]: *** [/home/pmenzel/src/core/desktop/Executable_oosplash.mk:10: 
/home/pmenzel/src/core/instdir/program/oosplash] Error 1

make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:282: build] Error 2
```


Kind regards,

Paul

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

Print dialog window too big with 6.4.0~rc1

[Paul Menzel]

Dear LibreOffice folks,


LibreOffice 6.4.0.1 40(Build:1) seems to have redesigned the print 
dialog. The window is too big now, causing the buttons in the bottom not 
to be seen on a laptop with 1366x768 resolution and GNOME Shell, which 
does not allow you to move the window outside the screen. If the window 
is supposed to stay that big, a scrollbar needs to be added so all parts 
of the dialog can be seen.



Kind regards,

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

Bug 128032 - Multiple copies not printed

[Paul Menzel]

Dear LibreOffice folks,


Bug report #128032 [1] seems to have been overlooked. Can you reproduce
that issue?


Kind regards,

Paul


[1]: https://bugs.documentfoundation.org/show_bug.cgi?id=128032



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 6.3.0.4: SdImportTest::testDocumentLayout fails

[Paul Menzel]

Dear Michael,


On 12.08.19 17:55, Michael Stahl wrote:
> On 12.08.19 17:50, Paul Menzel wrote:
>> On 12.08.19 11:07, Michael Stahl wrote:
> 
>> The file is indeed not there.
>>
>> ```
>> $ find . -name "*.rng"
>> ./build/workdir/UnpackedTarball/liborcus/misc/OpenDocument-v1.2-os-schema.rng
>> ./build/workdir/UnpackedTarball/raptor/tests/feeds/atom.rng
>> ./build/workdir/UnpackedTarball/beanshell/docs/manual/foo.rng
>> ./source/writerfilter/documentation/ooxml/model.rng
>> ./source/xmloff/dtd/openoffice-2.0-schema.rng
>> ```
> 
> are you using tarballs to build?

Yes, of course. ;-)

> i believe the schema files are not in the tarballs, intentionally,
> because they are not available with a FLOSS license.
> 
> so you can either disable the validation, build from a git clone, or
> copy the schema directory manually...

Since when is that the case? At least until LibreOffice 6.1.5.2 it worked.

So, tarball users should not run `make check`?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 6.3.0.4: SdImportTest::testDocumentLayout fails

[Paul Menzel]

Dear Michael,


On 12.08.19 11:07, Michael Stahl wrote:

> On 12.08.19 02:01, Paul Menzel wrote:
>> On 12.08.19 00:05, Thorsten Behrens wrote:
>>
>>> Paul Menzel wrote:
>>>> Building LibreOffice 6.3.0.4 with `DISPLAY=` (unset) the test below fails.
>>>>
>>>> ```
>>>
>>> Can you run bin/odfvalidator.sh successfully from the shell? Possibly
>>> it does not find the right JRE (>=1.8).
>>
>>  $ chmod +x bin/odfvalidator.sh
>>  $ ./bin/odfvalidator.sh -V
>>  odfvalidator v1.1.4
> 
> 
> libreoffice-6-3 branch contains the following commit, but it is
> missing in the 6.3.0.4 release. please apply it, it should give a
> better error message; if you still don't see any reason why the
> validator fails it's probably because the JVM doesn't even start.
> 
> commit 53ca96a5e0a77cd077f9b5690302d10faf8c5247
> Author: Michael Stahl 
> AuthorDate: Fri Jul 19 18:12:23 2019 +0200
> 
>     test: check validator exit code *after* checking validator output
> 
>     ODF validator may now actually exit with non-0 since commit
>     b14e2f6c63c18894286c99ee8dde9070e24b41c2 - look for validation errors in
>     this case too.

After applying the patch, I see the results below.

```
$ make -j1 # still uses all threads though :(
[…]

make[1]: *** 
[/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/solenv/gbuild/CppunitTest.mk:113:
 
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/build/workdir/CppunitTest/sc_filters_test.test]
 Error 1

Exception in thread "main" java.lang.NullPointerException
at 
org.odftoolkit.odfvalidator.ODFValidator.getValidatorForSchema(ODFValidator.java:286)
at 
org.odftoolkit.odfvalidator.ODFValidator.getManifestValidator(ODFValidator.java:186)
at 
org.odftoolkit.odfvalidator.ODFRootPackageValidator.validateManifest(ODFRootPackageValidator.java:170)
at 
org.odftoolkit.odfvalidator.ODFRootPackageValidator.validatePre(ODFRootPackageValidator.java:93)
at 
org.odftoolkit.odfvalidator.ODFPackageValidator._validate(ODFPackageValidator.java:111)
at 
org.odftoolkit.odfvalidator.ODFPackageValidator.validate(ODFPackageValidator.java:81)
at 
org.odftoolkit.odfvalidator.ODFValidator.validateFile(ODFValidator.java:163)
at 
org.odftoolkit.odfvalidator.ODFValidator.validate(ODFValidator.java:125)
at org.odftoolkit.odfvalidator.Main.main(Main.java:314)
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/test/source/bootstrapfixture.cxx:233:SdImportTest::testDocumentLayout
equality assertion failed
- Expected: 0
- Actual  : 256
- failed to execute: sh 
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/build/bin/odfvalidator.sh 
-M 
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/libreoffice/OpenDocument-manifest-schema-v1.3+libreoffice.rng
 -D 
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/libreoffice/OpenDocument-dsig-schema-v1.3+libreoffice.rng
 -O 
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/libreoffice/OpenDocument-schema-v1.3+libreoffice.rng
 -m 
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/mathml2/mathml2.xsd
 /tmp/lu167058k4jf7.tmp > /tmp/lu167058k4jfc.tmp
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/libreoffice/OpenDocument-manifest-schema-v1.3+libreoffice.rng:
  Fatal: 
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/libreoffice/OpenDocument-manifest-schema-v1.3+libreoffice.rng:
 file does not exist


SdImportTest::testDocumentLayout finished in: 19355ms

[…]

[CHK] sfx2
Exception in thread "main" java.lang.NullPointerException
at 
org.odftoolkit.odfvalidator.ODFValidator.getValidatorForSchema(ODFValidator.java:286)
at 
org.odftoolkit.odfvalidator.ODFValidator.getManifestValidator(ODFValidator.java:186)
at 
org.odftoolkit.odfvalidator.ODFRootPackageValidator.validateManifest(ODFRootPackageValidator.java:170)
at 
org.odftoolkit.odfvalidator.ODFRootPackageValidator.validatePre(ODFRootPackageValidator.java:93)
at 
org.odftoolkit.odfvalidator.ODFPackageValidator._validate(ODFPackageValidator.java:111)
at 
org.odftoolkit.odfvalidator.ODFPackageValidator.validate(ODFPackageValidator.java:81)
at 
org.odftoolkit.odfvalidator.ODFValidator.validateFile(ODFValidator.java:163)
at 
org.odftoolkit.odfvalidator.ODFValidator.validate(ODFValidator.java:125)
at org.odftoolkit.odfvalidator.Main.main(Main.java:314)
file:///tmp/lu165138k4jdt.tmp/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/test/source/bootstrapfixture.cxx:233:PivotChartTest::testRoundtrip
equality assertion failed
- Expected: 0
- Actual  : 256
- failed to execute: sh 
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/build/bin/odfvalidator.sh 
-M 
/dev/shm/bee-root/libreof

Re: 6.3.0.4: SdImportTest::testDocumentLayout fails

[Paul Menzel]

Dear Thorsten,


On 12.08.19 00:05, Thorsten Behrens wrote:


Paul Menzel wrote:

Building LibreOffice 6.3.0.4 with `DISPLAY=` (unset) the test below fails.

```


Can you run bin/odfvalidator.sh successfully from the shell? Possibly
it does not find the right JRE (>=1.8).


$ chmod +x bin/odfvalidator.sh
$ ./bin/odfvalidator.sh -V
odfvalidator v1.1.4


Kind regards,

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

6.3.0.4: SdImportTest::testDocumentLayout fails

[Paul Menzel]

Dear LibreOffice folks,


Building LibreOffice 6.3.0.4 with `DISPLAY=` (unset) the test below fails.

```
bootstrapfixture.cxx:199:Assertion
Test name: SdImportTest::testDocumentLayout
equality assertion failed
- Expected: 0
- Actual  : 256
- failed to execute: sh
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/build/bin/odfvalidator.sh
-M
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/libreoffice/OpenDocument-manifest-schema-v1.3+libreoffice.rng
-D
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/libreoffice/OpenDocument-dsig-schema-v1.3+libreoffice.rng
-O
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/libreoffice/OpenDocument-schema-v1.3+libreoffice.rng
-m
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/schema/mathml2/mathml2.xsd
/tmp/lu933312w9ae3.tmp > /tmp/lu933312w9ae8.tmp

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

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

make CppunitTest_sd_import_tests CPPUNITTRACE="gdb --args"
# for interactive debugging on Linux
make CppunitTest_sd_import_tests VALGRIND=memcheck
# for memory checking
make CppunitTest_sd_import_tests DEBUGCPPUNIT=TRUE
# for exception catching

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

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

make[1]: ***
[/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/source/solenv/gbuild/CppunitTest.mk:113:
/dev/shm/bee-root/libreoffice/libreoffice-6.3.0.4-0/build/workdir/CppunitTest/sd_import_tests.test]
Error 1
```

Kind regards,

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

[Libreoffice-commits] core.git: external/libatomic_ops

[Paul Menzel]

 external/libatomic_ops/UnpackedTarball_libatomic_ops.mk |2 ++
 1 file changed, 2 insertions(+)

New commits:
commit e3658c5d6c50216a313beeda26b0d57b81d41dd8
Author: Paul Menzel 
Date:   Tue Jun 12 11:05:14 2018 +0200

libatomic_ops: Use newer `config.guess` and `config.sub`

On ppc64le with Ubuntu 18.04 and latest LibreOffice from master, the
build fails with the error below.

```
$ uname -m
ppc64le
$ git describe --dirty
libreoffice-6-1-branch-point-897-gd776263a9968
$ git log --oneline -1
d776263a9968 (HEAD -> master, origin/master, origin/HEAD) uitest 
Calc-Statistics- Descriptive statistics
$ ./configure
[…]
$ make
[…]
checking build system type... ./config.guess: unable to guess system type

This script, last modified 2011-05-11, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to  in order to provide the needed
information to handle your system.

config.guess timestamp = 2011-05-11

uname -m = ppc64le
uname -r = 4.17.0-rc6+
uname -s = Linux
uname -v = #1 SMP Sun May 27 18:16:57 CEST 2018

/usr/bin/uname -p =
/bin/uname -X =

hostinfo   =
/bin/universe  =
/usr/bin/arch -k   =
/bin/arch  =
/usr/bin/oslevel   =
/usr/convex/getsysinfo =

UNAME_MACHINE = ppc64le
UNAME_RELEASE = 4.17.0-rc6+
UNAME_SYSTEM  = Linux
UNAME_VERSION = #1 SMP Sun May 27 18:16:57 CEST 2018
configure: error: cannot guess build type; you must specify one

/dev/shm/libreoffice-core/external/libatomic_ops/ExternalProject_libatomic_ops.mk:19:
 recipe for target 
'/dev/shm/libreoffice-core/workdir/ExternalProject/libatomic_ops/build' failed
make[1]: *** 
[/dev/shm/libreoffice-core/workdir/ExternalProject/libatomic_ops/build] Error 1
make[1]: *** Waiting for unfinished jobs
[…]
```

So, replace the library's config.sub and config.guess by the internal,
more up-to-date copies.

Change-Id: Ib92489943517a4204528f1039f6fba26363b33ee
Solution-by: David Tardon 
Signed-off-by: Paul Menzel 
Reviewed-on: https://gerrit.libreoffice.org/56054
Reviewed-by: Stephan Bergmann 
Tested-by: Stephan Bergmann 

diff --git a/external/libatomic_ops/UnpackedTarball_libatomic_ops.mk 
b/external/libatomic_ops/UnpackedTarball_libatomic_ops.mk
index 602c483f3efc..652b8381a508 100644
--- a/external/libatomic_ops/UnpackedTarball_libatomic_ops.mk
+++ b/external/libatomic_ops/UnpackedTarball_libatomic_ops.mk
@@ -11,4 +11,6 @@ $(eval $(call 
gb_UnpackedTarball_UnpackedTarball,libatomic_ops))
 
 $(eval $(call 
gb_UnpackedTarball_set_tarball,libatomic_ops,$(LIBATOMIC_OPS_TARBALL)))
 
+$(eval $(call gb_UnpackedTarball_update_autoconf_configs,libatomic_ops))
+
 # vim: set noet sw=4 ts=4:
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

How to update external module?

[Paul Menzel]

Dear LibreOffice folks,


As the external modules seem to be stored on LibreOffice servers [1], how 
should those be updated? Do I just update the version in `download.lst`, and
the rest is done automatically?

The motivation for the question is, that I’d like to update libatomic_ops
from 7.2d to 7.6.4 [2], as that has the fixes for the Power architecture.


Kind regards,

Paul


[1]: https://dev-www.libreoffice.org/src/
[2]: https://github.com/ivmai/libatomic_ops/releases



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Test::testLineSpacing equality assertion failed

[Paul Menzel]

Dear LibreOffice folks,


On ppc64le with Ubuntu 18.04 and latest LibreOffice from master one test 
fails.


```
$ uname -m
ppc64le
$ git describe --dirty
libreoffice-6-1-branch-point-989-g23fa8a6ed053
$ git log --oneline -1
23fa8a6ed053 (HEAD -> master) weld SvxCharPositionPage
$ ./autogen.sh \
--with-system-libatomic_ops \
--with-system-libpng \
--with-boost-system \
--with-system-nss \
--with-system-postgresql
[…]
$ make
[…]
$ make check
[…]
[SCK] hyphen
/dev/shm/libreoffice-core/editeng/qa/unit/core-test.cxx:202:(anonymous 
namespace)::Test::testLineSpacing

equality assertion failed
- Expected: 122
- Actual  : 108

(anonymous namespace)::Test::testLineSpacing finished in: 214ms
(anonymous namespace)::Test::testConstruction finished in: 1ms
(anonymous namespace)::Test::testUnoTextFields finished in: 1ms
text is 201d
(anonymous namespace)::Test::testAutocorrect finished in: 5ms
(anonymous namespace)::Test::testHyperlinkCopyPaste finished in: 20ms
(anonymous namespace)::Test::testCopyPaste finished in: 9ms
(anonymous namespace)::Test::testMultiParaSelCopyPaste finished in: 9ms
(anonymous namespace)::Test::testTabsCopyPaste finished in: 12ms
(anonymous namespace)::Test::testHyperlinkSearch finished in: 6ms
(anonymous namespace)::Test::testBoldItalicCopyPaste finished in: 17ms
(anonymous namespace)::Test::testUnderlineCopyPaste finished in: 11ms
(anonymous namespace)::Test::testMultiParaCopyPaste finished in: 10ms
(anonymous namespace)::Test::testParaBoldItalicCopyPaste finished in: 12ms
(anonymous namespace)::Test::testParaStartCopyPaste finished in: 8ms
(anonymous namespace)::Test::testSectionAttributes finished in: 1ms
(anonymous namespace)::Test::testLargeParaCopyPaste finished in: 11ms
(anonymous namespace)::Test::testTransliterate finished in: 1ms
(anonymous namespace)::Test::testHoriAlignIgnoreTrailingWhitespace 
finished in: 0ms

core-test.cxx:202:Assertion
Test name: (anonymous namespace)::Test::testLineSpacing
equality assertion failed
- Expected: 122
- Actual  : 108

Failures !!!
Run: 18   Failure total: 1   Failures: 1   Errors: 0
[…]
```


Kind regards,

Paul

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

Re: Build fails with `../../../dist/out/include/prtypes.h:593:38: error: size of array ‘arg’ is negative`

[Paul Menzel]

Dear Stephan,


Am 13.06.2018 um 09:16 schrieb Stephan Bergmann:

On 13/06/18 09:07, Paul Menzel wrote:

$ make PARALLELISM=1
[…]
cd lib; make libs
cd util; make libs
cd freebl; make libs
Makefile:636: warning: overriding recipe for target 
'out/Linux_SINGLE_SHLIB'
Makefile:623: warning: ignoring old recipe for target 
'out/Linux_SINGLE_SHLIB'

In file included from ../../../dist/out/include/prerror.h:9:0,
  from drbg.c:9:
drbg.c: In function ‘RNG_RandomUpdate’:
../../../dist/out/include/prtypes.h:593:38: error: size of array ‘arg’ 
is negative

  extern void pr_static_assert(int arg[(condition) ? 1 : -1])
   ^
drbg.c:541:5: note: in expansion of macro ‘PR_STATIC_ASSERT’
  PR_STATIC_ASSERT(sizeof(size_t) <= 4);
  ^~~~
../../coreconf/rules.mk:392: recipe for target 
'out/Linux_SINGLE_SHLIB/drbg.o' failed

make[5]: *** [out/Linux_SINGLE_SHLIB/drbg.o] Error 1
Makefile:626: recipe for target 'libs' failed
make[4]: *** [libs] Error 2
../coreconf/rules.mk:101: recipe for target 'libs' failed
make[3]: *** [libs] Error 2
coreconf/rules.mk:101: recipe for target 'libs' failed
make[2]: *** [libs] Error 2
/dev/shm/libreoffice-core/external/nss/ExternalProject_nss.mk:34: 
recipe for target 
'/dev/shm/libreoffice-core/workdir/ExternalProject/nss/build' failed


^ so it's external/nss that's causing you trouble


Indeed. I worked around it by using the system library with 
`--with-system-nss`. On Ubuntu 18.04, a build configured with the 
options below succeeds for ppc64le.


$ autogen.sh \
--with-system-libatomic_ops
--with-system-libpng
--with-boost-system
--with-system-nss
--with-system-postgresql


Kind regards,

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

Re: Build fails with `../../../dist/out/include/prtypes.h:593:38: error: size of array ‘arg’ is negative`

[Paul Menzel]

Dear Stephan,


Am 13.06.2018 um 08:44 schrieb Stephan Bergmann:

On 12/06/18 18:36, Paul Menzel wrote:

On ppc64le with Ubuntu 18.04 and latest LibreOffice from master with the
libatomic_ops build fix, the build fails with the error below.

```
$ uname -m
ppc64le
$ git describe --dirty
libreoffice-6-1-branch-point-918-g647d6a2c4fba
$ git log --oneline -1
647d6a2c4fba (HEAD -> master, origin/master, origin/HEAD) 
libatomic_ops: Evaluate newer files

$ ./autogen.sh --with-system-libpng --with-boost-system
[…]
$ make
[…]
Makefile:636: warning: overriding recipe for target 
'out/Linux_SINGLE_SHLIB'
Makefile:623: warning: ignoring old recipe for target 
'out/Linux_SINGLE_SHLIB'

In file included from ../../../dist/out/include/prerror.h:9:0,
  from drbg.c:9:
drbg.c: In function ‘RNG_RandomUpdate’:
../../../dist/out/include/prtypes.h:593:38: error: size of array ‘arg’ 
is negative

  extern void pr_static_assert(int arg[(condition) ? 1 : -1])
   ^
drbg.c:541:5: note: in expansion of macro ‘PR_STATIC_ASSERT’
  PR_STATIC_ASSERT(sizeof(size_t) <= 4);
  ^~~~
../../coreconf/rules.mk:392: recipe for target 
'out/Linux_SINGLE_SHLIB/drbg.o' failed

make[5]: *** [out/Linux_SINGLE_SHLIB/drbg.o] Error 1
[…]
```


Apparently, one of the external/* modules gets misconfigured in some way 
so that it checks an assumption that would be appropriate for a 32-bit 
build (sizeof(size_t) <= 4) but not for a 64-bit build.  But from your 
snippet one can't even tell which external module that would be.


Where could I get the corresponding information? In this failure setting 
I tried building with only one thread and got the output below.


```
$ make PARALLELISM=1
[…]
cd lib; make libs
cd util; make libs
cd freebl; make libs
Makefile:636: warning: overriding recipe for target 'out/Linux_SINGLE_SHLIB'
Makefile:623: warning: ignoring old recipe for target 
'out/Linux_SINGLE_SHLIB'

In file included from ../../../dist/out/include/prerror.h:9:0,
 from drbg.c:9:
drbg.c: In function ‘RNG_RandomUpdate’:
../../../dist/out/include/prtypes.h:593:38: error: size of array ‘arg’ 
is negative

 extern void pr_static_assert(int arg[(condition) ? 1 : -1])
  ^
drbg.c:541:5: note: in expansion of macro ‘PR_STATIC_ASSERT’
 PR_STATIC_ASSERT(sizeof(size_t) <= 4);
 ^~~~
../../coreconf/rules.mk:392: recipe for target 
'out/Linux_SINGLE_SHLIB/drbg.o' failed

make[5]: *** [out/Linux_SINGLE_SHLIB/drbg.o] Error 1
Makefile:626: recipe for target 'libs' failed
make[4]: *** [libs] Error 2
../coreconf/rules.mk:101: recipe for target 'libs' failed
make[3]: *** [libs] Error 2
coreconf/rules.mk:101: recipe for target 'libs' failed
make[2]: *** [libs] Error 2
/dev/shm/libreoffice-core/external/nss/ExternalProject_nss.mk:34: recipe 
for target '/dev/shm/libreoffice-core/workdir/ExternalProject/nss/build' 
failed
make[1]: *** 
[/dev/shm/libreoffice-core/workdir/ExternalProject/nss/build] Error 1

Makefile:286: recipe for target 'build' failed
make: *** [build] Error 2
```


Kind regards,

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

Build fails with `../../../dist/out/include/prtypes.h:593:38: error: size of array ‘arg’ is negative`

[Paul Menzel]

Dear LibreOffice,


On ppc64le with Ubuntu 18.04 and latest LibreOffice from master with the
libatomic_ops build fix, the build fails with the error below.

```
$ uname -m
ppc64le
$ git describe --dirty
libreoffice-6-1-branch-point-918-g647d6a2c4fba
$ git log --oneline -1 
647d6a2c4fba (HEAD -> master, origin/master, origin/HEAD) libatomic_ops: 
Evaluate newer files
$ ./autogen.sh --with-system-libpng --with-boost-system
[…]
$ make
[…]
Makefile:636: warning: overriding recipe for target 'out/Linux_SINGLE_SHLIB'
Makefile:623: warning: ignoring old recipe for target 'out/Linux_SINGLE_SHLIB'
In file included from ../../../dist/out/include/prerror.h:9:0,
 from drbg.c:9:
drbg.c: In function ‘RNG_RandomUpdate’:
../../../dist/out/include/prtypes.h:593:38: error: size of array ‘arg’ is 
negative
 extern void pr_static_assert(int arg[(condition) ? 1 : -1])
  ^
drbg.c:541:5: note: in expansion of macro ‘PR_STATIC_ASSERT’
 PR_STATIC_ASSERT(sizeof(size_t) <= 4);
 ^~~~
../../coreconf/rules.mk:392: recipe for target 'out/Linux_SINGLE_SHLIB/drbg.o' 
failed
make[5]: *** [out/Linux_SINGLE_SHLIB/drbg.o] Error 1
[…]
```


Kind regards,

Paul


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


smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: workdir/ExternalProject/libatomic_ops/build: checking build system type... ./config.guess: unable to guess system type

[Paul Menzel]

Dear David,


On 06/12/18 10:52, David Tardon wrote:

> On Mon, 2018-06-11 at 19:44 +0200, Paul Menzel wrote:
>> configure: error: cannot guess build type; you must specify one
>> /dev/shm/libreoffice-
>> core/external/libatomic_ops/ExternalProject_libatomic_ops.mk:19:
>> recipe for target '/dev/shm/libreoffice-
>> core/workdir/ExternalProject/libatomic_ops/build' failed
>> make[1]: *** [/dev/shm/libreoffice-
>> core/workdir/ExternalProject/libatomic_ops/build] Error 1
>> make[1]: *** Waiting for unfinished jobs
> 
> Add
> 
> $(eval $(call gb_UnpackedTarball_update_autoconf_configs,libatomic_ops))
> 
> to external/libatomic_ops/UnpackedTarball_libatomic_ops.mk . This will
> replace the library's config.sub and config.guess by our internal--more
> up-to-date--copies.

Thank you, that fixed it. I can submit a patch.

In the future, I should just use the system libraries.


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

workdir/ExternalProject/libatomic_ops/build: checking build system type... ./config.guess: unable to guess system type

[Paul Menzel]

Dear LibreOffice,


On ppc64le with Ubuntu 18.04 and latest LibreOffice from master, the build
fails with the error below.

```
$ uname -m
ppc64le
$ git describe --dirty 
libreoffice-6-1-branch-point-897-gd776263a9968
$ git log --oneline -1 
d776263a9968 (HEAD -> master, origin/master, origin/HEAD) uitest 
Calc-Statistics- Descriptive statistics
$ ./configure
[…]
$ make
[…]
checking build system type... ./config.guess: unable to guess system type

This script, last modified 2011-05-11, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to  in order to provide the needed
information to handle your system.

config.guess timestamp = 2011-05-11

uname -m = ppc64le
uname -r = 4.17.0-rc6+
uname -s = Linux
uname -v = #1 SMP Sun May 27 18:16:57 CEST 2018

/usr/bin/uname -p =
/bin/uname -X =

hostinfo   =
/bin/universe  =
/usr/bin/arch -k   =
/bin/arch  =
/usr/bin/oslevel   =
/usr/convex/getsysinfo =

UNAME_MACHINE = ppc64le
UNAME_RELEASE = 4.17.0-rc6+
UNAME_SYSTEM  = Linux
UNAME_VERSION = #1 SMP Sun May 27 18:16:57 CEST 2018
configure: error: cannot guess build type; you must specify one
/dev/shm/libreoffice-core/external/libatomic_ops/ExternalProject_libatomic_ops.mk:19:
 recipe for target 
'/dev/shm/libreoffice-core/workdir/ExternalProject/libatomic_ops/build' failed
make[1]: *** 
[/dev/shm/libreoffice-core/workdir/ExternalProject/libatomic_ops/build] Error 1
make[1]: *** Waiting for unfinished jobs
[…]
```


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[solved] Re: Build fails with `/usr/bin/powerpc64le-linux-gnu-ld: cannot find -ljawt`

[Paul Menzel]

Dear LibreOffice folks,


On 06/11/18 19:04, Paul Menzel wrote:

> On ppc64le with Ubuntu 18.04 and latest LibreOffice from master, the build
> fails with the error below.
> 
> ```
> $ uname -m
> ppc64le
> $ git describe --dirtylibreoffice-5-4-branch-point-1380-gc2ce3a2dbebd
> $ git log --oneline -1c2ce3a2dbebd (HEAD -> master, origin/master, 
> origin/HEAD)
> sw: prefix members of SwTOXInternational
> ```

That is from 2017 and not 2018, so I used outdated code. Sorry for the noise. It
now fails at a different location. ;-)

[…]

Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Build fails with `/usr/bin/powerpc64le-linux-gnu-ld: cannot find -ljawt`

[Paul Menzel]

Dear LibreOffice folks,


On ppc64le with Ubuntu 18.04 and latest LibreOffice from master, the build
fails with the error below.

```
$ uname -m
ppc64le
$ git describe --dirtylibreoffice-5-4-branch-point-1380-gc2ce3a2dbebd
$ git log --oneline -1c2ce3a2dbebd (HEAD -> master, origin/master, origin/HEAD)
sw: prefix members of SwTOXInternational
$ ./configure --with-jdk-home=/usr/lib/jvm/default-java/
$ make
[…]
/usr/bin/powerpc64le-linux-gnu-ld: cannot find -ljawt
collect2: error: ld returned 1 exit status
/dev/shm/libreoffice-core/bean/Library_officebean.mk:12: recipe for target 
'/dev/shm/libreoffice-core/instdir/program/libofficebean.so' failed
make[1]: *** [/dev/shm/libreoffice-core/instdir/program/libofficebean.so] Error 
1
make[1]: *** Waiting for unfinished jobs
Makefile:264: recipe for target 'build' failed
make: *** [build] Error 2
$ /usr/lib/jvm/default-java/bin/java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)
$ dpkg -S jawt
openjdk-8-jre-headless:ppc64el: 
/usr/lib/jvm/java-8-openjdk-ppc64el/jre/lib/ppc64le/libjawt.so
openjdk-11-jre-headless:ppc64el: 
/usr/lib/jvm/java-11-openjdk-ppc64el/lib/libjawt.so
openjdk-11-jdk:ppc64el: 
/usr/lib/jvm/java-11-openjdk-ppc64el/include/linux/jawt_md.h
openjdk-11-jdk:ppc64el: /usr/lib/jvm/java-11-openjdk-ppc64el/include/jawt.h
$ ls -l /usr/lib/jvm/total 192
lrwxrwxrwx 1 root root 27 Apr  8 15:16 default-java -> 
java-1.11.0-openjdk-ppc64el
lrwxrwxrwx 1 root root 23 Apr 21 15:41 java-1.11.0-openjdk-ppc64el -> 
java-11-openjdk-ppc64el
drwxr-xr-x 1 root root 82 May 22 18:50 java-11-openjdk-ppc64el
lrwxrwxrwx 1 root root 22 May  6  2017 java-1.8.0-openjdk-ppc64el -> 
java-8-openjdk-ppc64el
drwxr-xr-x 1 root root 26 May 23 14:50 java-8-openjdk-ppc64el
```


Kind regardsm,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Impress: Stuttering transition under GNU/Linux

[Paul Menzel]

Dear LibreOffice,


With LibreOffice 5.2, 5.4 and 6.0.1.1, doing transitions in LibreOffice 
Impress, like wipe, the transition is not smooth but stutters(?) [1].


I first thought it’s HiDPI related, but it’s not.

Is that expected under GNU/Linux, or do I have something incorrectly 
configured? Any suggestions, how to debug this?



Kind regards,

Paul


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=115650
"Stuttering transitions in GNU/Linux"



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

How to check that CVE-2018-6871 is fixed?

[Paul Menzel]

Dear LibreOffice folks,


So according to CVE-2018-6871, “LibreOffice through 6.0.1 allows remote
attackers to read arbitrary files via =WEBSERVICE calls in a document,
which use the COM.MICROSOFT.WEBSERVICE function.”.

Maybe it’s my English, but “through 6.0.1” sounds to me like, that
version is affected. The vulnerability description page [2] says, that 
LibreOffice 6.0.1 is not affected.



100% success rate, absolutely silent, affect LibreOffice prior to
5.4.5/6.0.1 in all operation systems (GNU/Linux, MS Windows, macOS
etc.) and may be embedded in almost all formats supporting by LO.


I was searching the bug tracker [3] for *CVE-2018-6871* and got no 
result, and the git commit log also doesn’t mention it. Neither do the 
release notes [4][5].


So, how can I find out, in what version that vulnerability was fixed?


Kind regards,

Paul


[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6871
[2] https://github.com/jollheef/libreoffice-remote-arbitrary-file-disclosure
[3] https://bugs.documentfoundation.org/
[4] 
https://blog.documentfoundation.org/blog/2018/02/09/early-availability-libreoffice-5-4-5-libreoffice-6-0-1/

[5] https://wiki.documentfoundation.org/Releases/6.0.1/RC1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Blurry icons on HiDPI display (GNU/Linux)

[Paul Menzel]

Dear Caolán,


On 12/17/17 15:33, Caolán McNamara wrote:

On Fri, 2017-12-15 at 17:44 +0100, Paul Menzel wrote:



Running LibreOffice 5.4.4.1 with GTK+ 3.22.26 on the HiDPI/4K
monitor Dell U2718Q the icons in the toolbar are blurry as can be
seen on the attached image.

Is that expected?


Probably, because these icons are pngs without higher res versions that
could be used under hidpi. Unless we move over to using SVG icons I
guess that's as good as it gets for now. We have svg versions of
breeze, elementary and sifr sets I believe, and I think I see the svg
tango source files for the tango pngs in icon-themes source dir. So we
may have some capacity to do something nicer eventually via svg.


Is the icon handling documented somewhere?

Let’s take the icon *lc_autosum* as an example.

```
$ find . -name '*lc_autosum*'
./icon-themes/breeze/cmd/lc_autosum.png
./icon-themes/crystal/cmd/lc_autosum.png
./icon-themes/elementary/cmd/lc_autosum.png
./icon-themes/galaxy/cmd/lc_autosum.png
./icon-themes/hicontrast/cmd/lc_autosum.png
./icon-themes/oxygen/cmd/lc_autosum.png
./icon-themes/sifr/cmd/lc_autosum.png
./icon-themes/tango/cmd/lc_autosum.png
./icon-themes/tango/cmd/lc_autosum.svg
./icon-themes/breeze_dark/cmd/lc_autosum.png
./icon-themes/breeze_svg/cmd/lc_autosum.svg
./icon-themes/sifr_dark/cmd/lc_autosum.png
./icon-themes/elementary_svg/cmd/lc_autosum.svg
$ identify ./icon-themes/tango/cmd/lc_autosum.png
./icon-themes/tango/cmd/lc_autosum.png PNG 24x24 24x24+0+0 8-bit sRGB 
1.08KB 0.000u 0:00.000

```

But I do not find any file with *autosum* in its name on the file system.


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Blurry icons on HiDPI display (GNU/Linux)

[Paul Menzel]

Dear LibreOffice folks,


Running LibreOffice 5.4.4.1 with GTK+ 3.22.26 on the HiDPI/4K monitor 
Dell U2718Q the icons in the toolbar are blurry as can be seen on the 
attached image.


```
$ libreoffice --version
LibreOffice 5.4.4.1 40m0(Build:1)

$ env | grep GDK
GDK_SCALE=2
GDK_DPI_SCALE=-1
```

Is that expected?


Kind regards,

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

Re: Lost images in documents (was: Lost images in Impress)

[Paul Menzel]

Dear LibreOffice folks,


On 08/07/17 15:16, Paul Menzel wrote:


On 08/07/17 13:54, Miklos Vajna wrote:


I believe <https://bugs.documentfoundation.org/show_bug.cgi?id=47148> is
the tracker of those bugs.


Somebody else privately pointed me to #104998 [1].

This seems to be new code, or should it be linked to #47148 [2]?

Any suggestions on what to do regarding #104998 is welcome. I tried to 
reproduce it with LibreOffice 5.4.0.3 by changing the memory settings, 
but in contrast to the problem reports and the problem of the scientist, 
I get *Read Error* written in the image frame. Saving the file, and 
opening it again, the image frames seem to be gone too.


The affected user now came to use, and asked to use the Microsoft Office 
program.


Is there a way to contract somebody to fix this issue?


Kind regards,

Paul



[1] https://bugs.documentfoundation.org/show_bug.cgi?id=104998
     PDF images disappear after a while in LO 5.3
[2] https://bugs.documentfoundation.org/show_bug.cgi?id=47148
     (Image-Caching) - [meta] image caching / management is utterly shambolic

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

[Libreoffice-commits] core.git: dictionaries

[Paul Menzel]

 dictionaries |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit c9f765c4de58bd9b79c52b1b536c19c2abd06b0c
Author: Paul Menzel <pmen...@molgen.mpg.de>
Date:   Tue Sep 19 17:52:46 2017 +0200

Updated core
Project: dictionaries  7250202493f1d91c5568db3363a268f7e5dcac42

de: Strip trailing spaces from README files

Change-Id: Ie07d9c56d0e17612c1b1baaa2c0e29df4c3ad3cb
Reviewed-on: https://gerrit.libreoffice.org/42484
Reviewed-by: Michael Stahl <mst...@redhat.com>
Tested-by: Michael Stahl <mst...@redhat.com>

diff --git a/dictionaries b/dictionaries
index 8b73c571cb27..7250202493f1 16
--- a/dictionaries
+++ b/dictionaries
@@ -1 +1 @@
-Subproject commit 8b73c571cb27bb29d26f3e218dedee2b680c3a04
+Subproject commit 7250202493f1d91c5568db3363a268f7e5dcac42
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] dictionaries.git: de/README_extension_owner.txt de/README_hyph_de.txt

[Paul Menzel]

 de/README_extension_owner.txt |2 +-
 de/README_hyph_de.txt |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 7250202493f1d91c5568db3363a268f7e5dcac42
Author: Paul Menzel <pmen...@molgen.mpg.de>
Date:   Tue Sep 19 17:52:46 2017 +0200

de: Strip trailing spaces from README files

Change-Id: Ie07d9c56d0e17612c1b1baaa2c0e29df4c3ad3cb
Reviewed-on: https://gerrit.libreoffice.org/42484
Reviewed-by: Michael Stahl <mst...@redhat.com>
Tested-by: Michael Stahl <mst...@redhat.com>

diff --git a/de/README_extension_owner.txt b/de/README_extension_owner.txt
index 24f8d5f..822409c 100644
--- a/de/README_extension_owner.txt
+++ b/de/README_extension_owner.txt
@@ -20,7 +20,7 @@ Author:  Bj
  Download: https://www.j3e.de/ispell/igerman98/dict/
 License: GNU GPL Version 2 or GPL Version 3 or OASIS 0.1
 
-The frami dictionary contains the complete word list of igerman98 
+The frami dictionary contains the complete word list of igerman98
 and in addition numerous supplements by Franz Michael Baumann according to
 the reform of 2006-08-01.
 
diff --git a/de/README_hyph_de.txt b/de/README_hyph_de.txt
index 35194e2..8921cae 100644
--- a/de/README_hyph_de.txt
+++ b/de/README_hyph_de.txt
@@ -14,7 +14,7 @@ Origin:   Based on the TeX hyphenation tables "dehyphn.tex", 
revision level 31.
  Public License (LPPL)
 
 License:  OpenOffice.org Adaptions of this package are licensed under the
-  GNU Lesser General Public License (LGPL 2 or later) and are under 
+  GNU Lesser General Public License (LGPL 2 or later) and are under
  Copyright by
 
 Author:   conversion author: Marco Huggenberger <ma...@by-night.ch>
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] dictionaries.git: de/README_de_DE_frami.txt de/README_extension_owner.txt de/README_hyph_de.txt

[Paul Menzel]

 de/README_de_DE_frami.txt |4 ++--
 de/README_extension_owner.txt |4 ++--
 de/README_hyph_de.txt |6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

New commits:
commit 8b73c571cb27bb29d26f3e218dedee2b680c3a04
Author: Paul Menzel <pmen...@molgen.mpg.de>
Date:   Tue Sep 19 17:52:10 2017 +0200

de: Use more secure HTTPS URLs

Change-Id: Iff2c6eddd7a0211b85f884d9e2601529daa3bab2
Reviewed-on: https://gerrit.libreoffice.org/42483
Reviewed-by: Michael Stahl <mst...@redhat.com>
Tested-by: Michael Stahl <mst...@redhat.com>

diff --git a/de/README_de_DE_frami.txt b/de/README_de_DE_frami.txt
index 9f300f9..43d6c6c 100644
--- a/de/README_de_DE_frami.txt
+++ b/de/README_de_DE_frami.txt
@@ -3,7 +3,7 @@ alle W
 im Basiswörterbuch noch fehlen oder die nicht unbedingt zum Kernwortschatz
 des Deutschen gehören. Die zusätzlichen Aufnahmen sind ungeprüft.
 Dieses Wörterbuch basiert auf dem igerman98 Ispell-Wörterbuch, zu finden
-unter http://www.j3e.de/ispell/igerman98/ .
+unter https://www.j3e.de/ispell/igerman98/ .
 
 Das Wörterbuch und alle enthaltenen Wortlisten sind lizenziert unter der
 GNU GPL, Version 2 oder 3.
@@ -14,4 +14,4 @@ Autor des Grundw
 Bjoern Jacke <bjo...@j3e.de>
 
 Autor der Erweiterung
-Franz Michael Baumann <fm.baum...@uni-muenster.de>
\ No newline at end of file
+Franz Michael Baumann <fm.baum...@uni-muenster.de>
diff --git a/de/README_extension_owner.txt b/de/README_extension_owner.txt
index 2e70797..24f8d5f 100644
--- a/de/README_extension_owner.txt
+++ b/de/README_extension_owner.txt
@@ -17,7 +17,7 @@ Author:  Franz Michael Baumann <fm.baum...@uni-muenster.de>
 Based on igerman98 dictionary:
 Version: 2016-12-07
 Author:  Björn Jacke <bjo...@j3e.de>
- Download: http://www.j3e.de/ispell/igerman98/dict/
+ Download: https://www.j3e.de/ispell/igerman98/dict/
 License: GNU GPL Version 2 or GPL Version 3 or OASIS 0.1
 
 The frami dictionary contains the complete word list of igerman98 
@@ -39,7 +39,7 @@ Thesaurus
 OpenThesaurus - Deutscher Thesaurus - Synonyme und Assoziationen
 Version: 2017-01-06 DE
 License: GNU LGPL Version 2.1 or later
-http://www.openthesaurus.de
+https://www.openthesaurus.de/
 
 Please note
 ===
diff --git a/de/README_hyph_de.txt b/de/README_hyph_de.txt
index c18c8c4..35194e2 100644
--- a/de/README_hyph_de.txt
+++ b/de/README_hyph_de.txt
@@ -35,8 +35,8 @@ Die Trennmuster (hyph_de_DE.dic) basieren auf den TeX 
Trennmustern
 Lizenz der Trennmuster: LPPL. Die Anpassung der Trennmuster an
 den in OpenOffice.org benutzten "ALTLinux LibHnj Hyphenator" wurde
 mit dem Script substrings.pl durchgeführt, das unter
-http://lingucomponent.openoffice.org/hyphenator.html als Teil der
-Datei altlinux_Hyph.zip heruntergeladen werden kann.
+https://www.openoffice.org/lingucomponent/hyphenator.html als Teil
+der Datei altlinux_Hyph.zip heruntergeladen werden kann.
 Die Original-Trennmuster können hier heruntergeladen werden:
-http://www.ctan.org/tex-archive/language/hyphenation/dehyphn.tex
+https://www.ctan.org/tex-archive/language/hyphenation/dehyphn.tex
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: dictionaries

[Paul Menzel]

 dictionaries |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit ee0147f4918cbf209b5b859c8f2c8616d6f7a47c
Author: Paul Menzel <pmen...@molgen.mpg.de>
Date:   Tue Sep 19 17:52:10 2017 +0200

Updated core
Project: dictionaries  8b73c571cb27bb29d26f3e218dedee2b680c3a04

de: Use more secure HTTPS URLs

Change-Id: Iff2c6eddd7a0211b85f884d9e2601529daa3bab2
Reviewed-on: https://gerrit.libreoffice.org/42483
Reviewed-by: Michael Stahl <mst...@redhat.com>
Tested-by: Michael Stahl <mst...@redhat.com>

diff --git a/dictionaries b/dictionaries
index b47ce35a6acd..8b73c571cb27 16
--- a/dictionaries
+++ b/dictionaries
@@ -1 +1 @@
-Subproject commit b47ce35a6acd746b539143949b677c554812c415
+Subproject commit 8b73c571cb27bb29d26f3e218dedee2b680c3a04
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: Filesystem Hierarchy Standards (FHS) and certain file locations

[Paul Menzel]

Dear Michael,


On 09/06/17 16:26, Michael Stahl wrote:

On 06.09.2017 15:55, Paul Menzel wrote:

Following up on bug report #100724 [1], I have two question about the
location of some files.


TDF binary packages (rpm and deb) don't install in /usr but in /opt.


I don’t know. We don’t use binary packages.


apparently you are trying to use "make install", which probably is
unused and unmaintained; maybe we should remove it.


No, we use `start_cmd make -j distro-pack-install DESTDIR=/some/where`. 
What do you recommend?


I don’t see a good reason to divert from standards like `./configure && 
make && make install && make check # or test`. That way, it’s one more 
barrier to integrate it in continuous integration systems like Travis CI 
or similar.



Kind regards,

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

Filesystem Hierarchy Standards (FHS) and certain file locations

[Paul Menzel]

Dear LibreOffice folks,


Following up on bug report #100724 [1], I have two question about the 
location of some files.


First, the license and README files.

```
/usr/lib/libreoffice/NOTICE
/usr/lib/libreoffice/LICENSE.html
/usr/lib/libreoffice/LICENSE.fodt
/usr/lib/libreoffice/LICENSE
/usr/lib/libreoffice/CREDITS.fodt
/usr/lib/libreoffice/readmes
/usr/lib/libreoffice/readmes/README_en-US
/usr/lib/libreoffice/readmes/README_de
```

Shouldn’t those be put under `/usr/share/doc/libreoffice/`?

Second, I wonder why the “real” binaries are put under `/usr/lib` and 
not `/usr/bin/`? `/usr/lib/libreoffice/program` is normally not in a path.


```
$ ls -l /usr/bin/libreoffice
lrwxrwxrwx 1 root system 36 Sep  4 12:55 /usr/bin/libreoffice -> 
/usr/lib/libreoffice/program/soffice

$ ls -l /usr/lib/libreoffice/program/
[…]
-rw-r--r-- 1 root system50 Sep  4 12:54 redirectrc
-rwxr-xr-x 1 root system 24984 Sep  4 12:36 regmerge
-rwxr-xr-x 1 root system 13616 Sep  4 12:36 regview
drwxr-xr-x 2 root system  4096 Sep  4 12:54 resource
-rwxr-xr-x 1 root system63 Aug 24 23:39 sbase
-rwxr-xr-x 1 root system63 Aug 24 23:39 scalc
-rwxr-xr-x 1 root system63 Aug 24 23:39 sdraw
-rwxr-xr-x 1 root system 13150 Aug 24 23:39 senddoc
drwxr-xr-x 2 root system  4096 Sep  4 12:55 services
-rw-r--r-- 1 root system  8690 Sep  4 12:38 services.rdb
-rw-r--r-- 1 root system34 Sep  4 12:54 setuprc
drwxr-xr-x 2 root system22 Sep  4 12:54 shell
-rwxr-xr-x 1 root system66 Aug 24 23:39 simpress
-rwxr-xr-x 1 root system63 Aug 24 23:39 smath
-rwxr-xr-x 1 root system  6051 Sep  4 12:34 soffice
-rwxr-xr-x 1 root system  7408 Sep  4 12:48 soffice.bin
-rw-r--r-- 1 root system   453 Sep  4 12:54 sofficerc
-rwxr-xr-x 1 root system65 Aug 24 23:39 swriter
drwxr-xr-x 2 root system42 Sep  4 12:54 types
-rw-r--r-- 1 root system 57362 Sep  4 12:36 types.rdb
-rwxr-xr-x 1 root system 41024 Sep  4 12:48 ui-previewer
-rwxr-xr-x 1 root system  1508 Aug 24 23:39 uno
-rwxr-xr-x 1 root system 99120 Sep  4 12:37 uno.bin
-rw-r--r-- 1 root system 17092 Aug 24 23:39 uno.py
-rw-r--r-- 1 root system 10956 Aug 24 23:39 unohelper.py
-rwxr-xr-x 1 root system  1390 Aug 24 23:39 unoinfo
-rwxr-xr-x 1 root system  3039 Aug 24 23:39 unopkg
-rwxr-xr-x 1 root system  7456 Sep  4 12:48 unopkg.bin
-rw-r--r-- 1 root system   239 Sep  4 12:35 unorc
-rwxr-xr-x 1 root system  7736 Sep  4 12:35 uri-encode
-rw-r--r-- 1 root system   319 Sep  4 12:54 versionrc
drwxr-xr-x 9 root system   108 Sep  4 12:54 wizards
-rwxr-xr-x 1 root system  7800 Sep  4 12:35 
xid-fullscreen-on-all-monitors

-rwxr-xr-x 1 root system 60048 Sep  4 12:36 xpdfimport
```

The FHS Wikipedia article describes `/usr/lib` as below [2].

> /usr/lib – libraries for the binaries in /usr/bin/ and /usr/sbin/.


Kind regards,

Paul


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=100724
[2] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Use HTTPS URLs in announcements and blog posts

[Paul Menzel]

Dear LibreOffice,


The article *The Document Foundation announces LibreOffice 5.4.1 “fresh” 
and LibreOffice 5.3.6 “still”* [1] uses insecure HTTP URLs instead of 
the more secure HTTPS URLs. Could the article and the templates please 
be updated?


If this is the wrong forum, please tell me where to report such issues.


Kind regards,

Paul


[1] 
https://blog.documentfoundation.org/blog/2017/08/31/document-foundation-announces-libreoffice-5-4-1-fresh-libreoffice-5-3-6-still/

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

Re: [solved] For what versions get source archives created?

[Paul Menzel]

Dear Michael,


On 08/22/17 16:00, Michael Stahl wrote:

On 22.08.2017 15:36, Paul Menzel wrote:

It’d be awesome, if we could take 5.4.1.1 as an example.

The tag was added over a week ago on August 11th.

```
commit a5be49f0c45fe24a575c7f41559aa8fc79a781a2 (tag: libreoffice-5.4.1.1)
Author: Christian Lohmaier <lohmaier+libreoff...@googlemail.com>
Date:   Fri Aug 11 20:16:14 2017 +0200

  Version 5.4.1.1, tag libreoffice-5.4.1.1
```

But even now it’s not available.

[...]

It’s available as a pre-release [1]. So I am wondering, what is holding
this up? Surely, doing the release doesn’t take more than a few days.
How can I find out the reason?


doing a release is scheduled to take 3 weeks, as always, since there are
2 RCs planned, and you're looking at the 1st one.

see:

https://wiki.documentfoundation.org/ReleasePlan/5.4

RC1 Week 32 , Aug 7, 2017 - Aug 13, 2017
RC2 Week 34 , Aug 21, 2017 - Aug 27, 2017
Release 5.4.1   Week 35 , Aug 28, 2017 - Sep 3, 2017


Thank you for pointing this out. That was the missing piece of 
information to understand what is going on.



Kind regards,

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

Re: For what versions get source archives created?

[Paul Menzel]

Dear LibreOffice folks,


Thank you for your replies.

On 08/05/17 00:34, Thorsten Behrens wrote:

Christian Lohmaier wrote:

On Tue, Jul 25, 2017 at 12:59 PM, Paul Menzel <pmen...@molgen.mpg.de> wrote:

So does it take over a week to get the archives published, or does
the directory need to be manually created on the server, and was
just forgotten?


Sources are made available on the mirrors the same moment when the
binaries are.


One of the reasons: it's extremely rare, but it happens at times that
full release builds on one platform show errors, or subsequent
smoketesting shows errors. In that case, a hotfix tag is pushed.

So a release is only really done, once both tag and binaries are
ready.


It’d be awesome, if we could take 5.4.1.1 as an example.

The tag was added over a week ago on August 11th.

```
commit a5be49f0c45fe24a575c7f41559aa8fc79a781a2 (tag: libreoffice-5.4.1.1)
Author: Christian Lohmaier <lohmaier+libreoff...@googlemail.com>
Date:   Fri Aug 11 20:16:14 2017 +0200

Version 5.4.1.1, tag libreoffice-5.4.1.1
```

But even now it’s not available.

```
$ curl -I https://download.documentfoundation.org/libreoffice/src/5.4.1/
HTTP/1.1 404 Not Found
Date: Tue, 22 Aug 2017 13:32:58 GMT
Server: Apache
X-Prefix: 141.14.0.0/16
X-AS: 680
Content-Type: text/html; charset=iso-8859-1
```

It’s available as a pre-release [1]. So I am wondering, what is holding 
this up? Surely, doing the release doesn’t take more than a few days. 
How can I find out the reason?



Kind regards,

Paul


[1] http://dev-builds.libreoffice.org/pre-releases/src/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Temporary files written to predetermined location during build

[Paul Menzel]

Dear Jean-Baptiste,


On 08/10/17 10:47, Jean-Baptiste Faure wrote:

Le 10/08/2017 à 09:13, Rene Engelhard a écrit :



On Wed, Aug 09, 2017 at 08:23:42PM +0200, Jean-Baptiste Faure wrote:
What is surprising me is that : "Building LibreOffice 5.4.0.3 with 
one user,
and then building it with another user...". Does that mean that the 
local

repository is shared between several users ?


How does the local repository matter is this is about /tmp? /tmp of 
course is shared between users.


I don't know but I am trying to understand how users are working on this 
machine. And I see this error message :

"fatal: Not a git repository (or any parent up to mount point /dev) "


The tar archive [1] is used.


Kind regards,

Paul


[1] 
https://download.documentfoundation.org/libreoffice/src/5.4.0/libreoffice-5.4.0.3.tar.xz

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

Re: Temporary files written to predetermined location during build

[Paul Menzel]

Dear Jean-Baptiste, dear Rene,


On 08/10/17 09:13, Rene Engelhard wrote:


On Wed, Aug 09, 2017 at 08:23:42PM +0200, Jean-Baptiste Faure wrote:

What is surprising me is that : "Building LibreOffice 5.4.0.3 with one user,
and then building it with another user...". Does that mean that the local
repository is shared between several users ?


How does the local repository matter is this is about /tmp? /tmp of course
is shared between users.


Indeed, the machine is used by several users. (And for some reason they 
all build LibreOffice. ;-))



Kind regards,

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

Temporary files written to predetermined location during build

[Paul Menzel]

Dear LibreOffice folks,


I was asked in #111553 (Temporary files written to predetermined 
location) [1] to contact the mailing list.



Building LibreOffice 5.4.0.3 with one user, and then building it with another
user shows that it tries to write to the same paths in the temporary directory,
which of course fails.

```
[…]

... languages de_en-US ...
... analyzing files ...
... analyzing files with flag FILELIST ...
filelist
/dev/shm/bee-root/libreoffice/libreoffice-5.4.0.3-0/build/workdir/Package/xmlsec.filelist
is empty
... analyzing files with flag SCPZIP_REPLACE ...
... analyzing all directories for this product ...
... analyzing links ...
... analyzing unix links ...
... creating profiles ...
fatal: Not a git repository (or any parent up to mount point /dev)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
ERROR: Failure in installer.pm
ERROR: ERROR: Cannot open file
/tmp/LibreOffice//profiles/de_en-US/gid_Brand_Profile_Bootstrap_Ini/bootstraprc
for writing at
/dev/shm/bee-root/libreoffice/libreoffice-5.4.0.3-0/source/solenv/bin/modules/installer/files.pm
line 85.

... cleaning the output tree ...
... removing directory /tmp/ooopackaging6idOna/i_647771502279265 ...

*
ERROR: Cannot write log file
/tmp/LibreOffice//logging/de_en-US/log_540_de_en-US.log, Permission denied
*
Failed to install: No such file or directory at
/dev/shm/bee-root/libreoffice/libreoffice-5.4.0.3-0/source/solenv/bin/ooinstall
line 92.
Makefile:311: recipe for target 'install' failed
make: *** [install] Error 2
```

At least the two directories below contain conflicting files.

1.  `/tmp/LibreOffice/profiles/de_en-US/`
2.  `/tmp/LibreOffice/logging/de_en-US/`



Kind regards,

Paul


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=111553
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Lost images in Impress

[Paul Menzel]

Dear Miklos, and dear private responders,


On 08/07/17 13:54, Miklos Vajna wrote:


I believe  is
the tracker of those bugs.


Somebody else privately pointed me to #104998 [1].

This seems to be new code, or should it be linked to #47148 [2]?

Any suggestions on what to do regarding #104998 is welcome. I tried to 
reproduce it with LibreOffice 5.4.0.3 by changing the memory settings, 
but in contrast to the problem reports and the problem of the scientist, 
I get *Read Error* written in the image frame. Saving the file, and 
opening it again, the image frames seem to be gone too.



Kind regards,

Paul


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=104998
PDF images disappear after a while in LO 5.3
[2] https://bugs.documentfoundation.org/show_bug.cgi?id=47148
(Image-Caching) - [meta] image caching / management is utterly 
shambolic

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

Lost images in Impress

[Paul Menzel]

Dear LibreOffice folks,


One of our scientists reported that images get randomly lost in a 
presentation.


This did not happen in version 5.1.3.2, but is present in at least 
5.3.4.1, 5.3.5.1, and 5.4.0.3.


The included images are PDF files, and it happens randomly, and, 
therefore, no steps can be provided to reproduce the issue.


The image suddenly disappears. The frame for the image is still there 
though, and the handles appear, if you click on the white area, where is 
the image is supposed to be.


Before creating an issue in the bug tracker [1], could you please 
suggest, what debugging options can be turned on, to create a more 
meaningful bug report? Maybe you already know of such an issue. 
Unfortunately, I couldn’t find one.



Kind regards,

Paul


[1] https://bugs.documentfoundation.org/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: For what versions get source archives created?

[Paul Menzel]

Dear Christian,


Thank you for your response.


On 07/25/17 12:37, Christian Lohmaier wrote:


On Mon, Jul 24, 2017 at 11:18 AM, Paul Menzel <pmen...@molgen.mpg.de> wrote:


I noticed, that in the Git repository, the tag *libreoffice-5.3.5.1* was
added on July 12th, 2017 [1]. (Unfortunately the Change-Id cannot be found
in Gerrit. [2])


It is not a change request, and not part of any (named) bracnh, but
you can find it in gerrit's gitweb (or on the various mirrors like
anongit.freedesktop.org, github, launchpad,..)

https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=020db1aa8142e57290f8a21e4df31185392d0e38


So the Change-Id is added to all commits, even if not pushed for Gerrit 
for review? I guess, for example, to better track cherry-picks in other 
branches?



Again, I am unable to find the source archive on the download server [3].


What do you mean with "again"?


I had the same problem with 5.3.4.2 [4], though the lag wasn’t that big 
then.



The directory 5.3.5 doesn’t even exist.


It only exists on mirrors once the stuff is pushed to mirrors.
Before that the builds are assembled on pre-release server:
http://dev-builds.libreoffice.org/pre-releases/src/


I guess that download.documentfoundation.org is the *master* though, 
that means, all mirrors mirror from that server?



Could you please explain to, what versions source archives are created for?


Source archives are created for all tags, but only the last version
will be kept on mirror, i.e. for 5.3.5 release, the 5.3.5 rc1 sources
will be removed/the ones for rc2 will be on download mirror.


[3] https://download.documentfoundation.org/libreoffice/src/5.3.5/


That's were they are. and when you compare with 5.3.4 for example:
https://download.documentfoundation.org/libreoffice/src/5.3.4/ → there
are the ones for rc2 only.


Yes, *today* they are there. Yesterday, that directory was *not* there, 
or wasn’t accessible. I checked with GNU Wget and a browser.


So does it take over a week to get the archives published, or does the 
directory need to be manually created on the server, and was just forgotten?



Why are you looking for the source archives in the first place?
For most usecases using the repositories directly is more convenient...


I know, but our internal package build system was written for source 
archives, so that’s what we prefer.



Kind regards,

Paul


[4] https://lists.freedesktop.org/archives/libreoffice/2017-June/077929.html
"LibreOffice 5.3.4.2 archive missing, 06/19/17 11:56"
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

For what versions get source archives created?

[Paul Menzel]

Dear LibreOffice folks,


I noticed, that in the Git repository, the tag *libreoffice-5.3.5.1* was 
added on July 12th, 2017 [1]. (Unfortunately the Change-Id cannot be 
found in Gerrit. [2])


Again, I am unable to find the source archive on the download server 
[3]. The directory 5.3.5 doesn’t even exist.


Could you please explain to, what versions source archives are created for?


Kind regards,

Paul


[1] commit 020db1aa8142e57290f8a21e4df31185392d0e38
Author: Christian Lohmaier 
Date:   Wed Jul 12 20:38:04 2017 +0200

Version 5.3.5.1, tag libreoffice-5.3.5.1

Change-Id: If292c9a8fffd1a3a9071192bc1e6969059ec55b6
[2] 
https://gerrit.libreoffice.org/#/q/If292c9a8fffd1a3a9071192bc1e6969059ec55b6

[3] https://download.documentfoundation.org/libreoffice/src/5.3.5/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOffice 5.3.4.2 archive missing

[Paul Menzel]

Dear LibreOffice folks,


On 06/19/17 11:56, Paul Menzel wrote:

I noticed, that in the Git repository, the tag *libreoffice-5.3.4.2* was 
added. But the source archive is missing [1]. How long is delay between 
tagging a version, and getting the source archives published?


The source archives are now available.


Kind regards,

Paul



[1] https://download.documentfoundation.org/libreoffice/src/5.3.4/

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

LibreOffice 5.3.4.2 archive missing

[Paul Menzel]

Dear LibreOffice folks,


I noticed, that in the Git repository, the tag *libreoffice-5.3.4.2* was 
added. But the source archive is missing [1]. How long is delay between 
tagging a version, and getting the source archives published?



Kind regards,

Paul


[1] https://download.documentfoundation.org/libreoffice/src/5.3.4/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Regression in cppcanvas/qa/extras/emfplus/emfplus.cxx:89:Test::testFdo77229

[Paul Menzel]

Dear LibreOffice folks,


On 06/11/17 11:16, Paul Menzel wrote:


Building LibreOffice 5.3.4.1 the test suite fails with the error below.

```
[CUT] cppcanvas_emfplus 
/dev/shm/bee-root/libreoffice/libreoffice-5.3.4.1-0/source/cppcanvas/qa/extras/emfplus/emfplus.cxx:89:Test::testFdo77229
equality assertion failed
- Expected: 65024
- Actual  : 16777215

Test::testFdo77229 finished in: 381ms
emfplus.cxx:89:Assertion
Test name: Test::testFdo77229
equality assertion failed
- Expected: 65024
- Actual  : 16777215

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

With LibreOffice 5.3.3.2 the test suite passed.


I am also able to reproduce this with the master branch with 1cb3100 
(Revert "tdf#55631: DBASE import with CP850 encoding").


```
/dev/shm/libreoffice-core/cppcanvas/qa/extras/emfplus/emfplus.cxx:88:Test::testFdo77229
equality assertion failed
- Expected:
- Actual  : �

Test::testFdo77229 finished in: 443ms
emfplus.cxx:88:Assertion
Test name: Test::testFdo77229
equality assertion failed
- Expected:
- Actual  : �

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

I am building LibreOffice in a GNU Screen session on a server.


Kind regards,

Paul



[1] https://bugs.documentfoundation.org/show_bug.cgi?id=108431

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

[5.3.4.1] Regression in cppcanvas/qa/extras/emfplus/emfplus.cxx:89:Test::testFdo77229

[Paul Menzel]

Dear LibreOffice folks,


Building LibreOffice 5.3.4.1 the test suite fails with the error below.

```
[CUT] cppcanvas_emfplus 
/dev/shm/bee-root/libreoffice/libreoffice-5.3.4.1-0/source/cppcanvas/qa/extras/emfplus/emfplus.cxx:89:Test::testFdo77229
equality assertion failed
- Expected: 65024
- Actual  : 16777215

Test::testFdo77229 finished in: 381ms
emfplus.cxx:89:Assertion
Test name: Test::testFdo77229
equality assertion failed
- Expected: 65024
- Actual  : 16777215

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

With LibreOffice 5.3.3.2 the test suite passed.


Kind regards,

Paul


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=108431

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

[Libreoffice-commits] core.git: configure.ac README.cross sw/qa

[Paul Menzel]

 README.cross|4 ++--
 configure.ac|4 ++--
 sw/qa/extras/README |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

New commits:
commit e8918c464c7be09823bc8f5179080d7da0060de7
Author: Paul Menzel <pmen...@molgen.mpg.de>
Date:   Wed May 17 11:55:46 2017 +0200

Use more secure HTTPS URL for dev-www.libreoffice.org

Run the command below to convert all URLs for *dev-www.libreoffice.org*
to use the more secure HTTPS URL.

```
git grep -l 'http://dev-www' | xargs sed -i 
's,http://dev-www.libreoffice.org,https://dev-www.libreoffice.org,g'
```

If a redirect is implemented for the insecure HTTP requests, also one
request would be saved.

```
$ curl -I http://dev-www.libreoffice.org
HTTP/1.1 200 OK
Date: Wed, 17 May 2017 10:00:52 GMT
Server: Apache/2.2.12 (Linux/SUSE)
Content-Type: text/html;charset=ISO-8859-1

$ curl -I https://dev-www.libreoffice.org
HTTP/1.1 200 OK
Date: Wed, 17 May 2017 10:00:57 GMT
Server: Apache/2.2.12 (Linux/SUSE)
Content-Type: text/html;charset=ISO-8859-1

```

Change-Id: I99626ded90f72239f98ce76fd1b2760c31c34408
Reviewed-on: https://gerrit.libreoffice.org/37703
Tested-by: Jenkins <c...@libreoffice.org>
Reviewed-by: Miklos Vajna <vmik...@collabora.co.uk>

diff --git a/README.cross b/README.cross
index e391e9f7d8de..0b1b74701289 100644
--- a/README.cross
+++ b/README.cross
@@ -189,10 +189,10 @@ But this cross-compilation work is tested from Debian and 
openSUSE to Raspbian.
 
 You will need headers, pkg-config files and libraries from a Raspbian
 system to build against. Available at
-http://dev-www.libreoffice.org/extern/ . Look for the latest
+https://dev-www.libreoffice.org/extern/ . Look for the latest
 raspbian-root-*.tar.gz . For instance:
 
-$ wget http://dev-www.libreoffice.org/extern/raspbian-root-20140120.tar.gz
+$ wget https://dev-www.libreoffice.org/extern/raspbian-root-20140120.tar.gz
 $ mkdir raspbian-root
 $ cd raspbian-root
 $ tar -xf raspbian-root-20140120.tar.gz
diff --git a/configure.ac b/configure.ac
index 6bf2fa6f339a..ecfbab754ed4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7770,7 +7770,7 @@ install a pre-compiled binary for Win32
 
 mkdir -p /opt/lo/bin
 cd /opt/lo/bin
-wget http://dev-www.libreoffice.org/bin/cygwin/nasm.exe
+wget https://dev-www.libreoffice.org/bin/cygwin/nasm.exe
 chmod +x nasm
 
 or get and install one from http://www.nasm.us/
@@ -12730,7 +12730,7 @@ to install a pre-compiled binary make for Win32
 
  mkdir -p /opt/lo/bin
  cd /opt/lo/bin
- wget http://dev-www.libreoffice.org/bin/cygwin/make-85047eb-msvc.exe
+ wget https://dev-www.libreoffice.org/bin/cygwin/make-85047eb-msvc.exe
  cp make-85047eb-msvc.exe make
  chmod +x make
 
diff --git a/sw/qa/extras/README b/sw/qa/extras/README
index c77ded05ddcb..ff6425a8eb43 100644
--- a/sw/qa/extras/README
+++ b/sw/qa/extras/README
@@ -76,7 +76,7 @@ enough if you want to test a paragraph or character property.
 Figuring out the UNO API just by reading the idl files under `offapi/` is not
 that productive. Xray can help in this case. Download it from:
 
-http://dev-www.libreoffice.org/extern/XrayTool52_en.sxw
+https://dev-www.libreoffice.org/extern/XrayTool52_en.sxw
 
 It's a document file, start Writer, Tools -> Options -> LibreOffice -> 
Security,
 Macro Security, and there choose Low. Then open the document, and click 
`Install
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Paul Menzel license statement

[Paul Menzel]

All of my past & future contributions to LibreOffice may be licensed 
under the MPLv2/LGPLv3+ dual license.

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

Re: Gerrit prevents upstreaming patches from others

[Paul Menzel]

Dear Christian,


On 02/06/17 12:17, Christian Lohmaier wrote:


On Mon, Feb 6, 2017 at 11:08 AM, Paul Menzel
<pmenzel+libreoff...@molgen.mpg.de> wrote:

On 02/06/17 10:55, Christian Lohmaier wrote:

On Thu, Feb 2, 2017 at 1:05 PM, Paul Menzel wrote:

It is to prevent people from impersonating somebody else.

Think about someone trying your email to introduce a backdoor ...


In my opinion that’s highly hypothetical.


It is exaggerating to illustrate the point. It doesn't matter what
actual impact that change has.


And if that happens, it’ll be
figured out in no time from the Gerrit log, that it wasn’t really the
impersonated person.


How would you be able to tell?
You might be able to tell that the email address is not matching what
the user has configured. But you cannot tell whether the user he was
claiming to be actually was involved.

Let's say there was no such limitation, and I'd commit something as
"Donald J Trump <po...@whitehouse.gov>" and claim "I talked to him, he
did that patch" - how would you know that'd be the case? And how would
you know he'd be fine with our licencing requirements?
Again exaggerated example.


The coreboot project doesn’t have these restrictions, and in the past there
hasn’t been any problems.


So far nobody stole anything from my car, but I still lock it up.


Sorry, car theft is a reality.

Somebody could shoot me on the street, so I shoot them first? Preventive 
strikes …?



If there were a way to impersonate as somebody else, then checking for
the licence agreements and other stuff just becomes too hard/you'll
run into the problem of deniability.


Sorry, using the email address as verification is fundamentally flawed. 
That’s why GPG exists.


I just register `chris.lohmaier` at any free provider, and send in 
commits for you, without any error from Gerrit.


So, to close my participation in this thread, the current restriction 
make it hard for people wanting to upstream patches from colleagues.


The LibreOffice people should really think about it again, as from the 
current arguments, the restriction *cannot by design* enforce the policy 
it was made for.



Kind regards,

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

Re: Gerrit prevents upstreaming patches from others

[Paul Menzel]

Dear Jan,


On 02/06/17 12:00, jan iversen wrote:


Sorry, I still don’t see where the additional step is?


you submit the patch to gerrit, that does not put it into our core repo, but 
only to the gerrit review repo. In order to merge the patch into our core 
repo(typically master) a committer, needs to hit merge in gerrit, then will 
mark the patch as merged in gerrit, and commit it to the master repo.

the committer that does the merge becomes the committer in git, the author in 
our core repo becomes:

>

1) gerrit author, if gerrit committer == committer who does the merge


Sorry, what is the “gerrit author”? Do you mean the owner?


2) else gerrit committer.


Do you have an example commit, where that happened? I think, then I 
would understand it better.


I still don’t understand, why the author metadata should be changed in 
the first place.



Kind regards,

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

Re: Gerrit prevents upstreaming patches from others

[Paul Menzel]

Dear Christian,


On 02/06/17 10:55, Christian Lohmaier wrote:


On Thu, Feb 2, 2017 at 1:05 PM, Paul Menzel wrote:


I was asked to push a commit for review to the LO Gerrit instance [1].

The patch is from a colleague, who is denoted as the commit author. No
Gerrit complains, that I am not the author, and my colleagues email address
is not registered to *my* Gerrit account.


This is intentional.


Could you please change that, and disable that limitation? I don’t see any
reason for it.


It is to prevent people from impersonating somebody else.

Think about someone trying your email to introduce a backdoor ...


In my opinion that’s highly hypothetical. And if that happens, it’ll be 
figured out in no time from the Gerrit log, that it wasn’t really the 
impersonated person.



as well as reducing mistakes (when you're  using different email
addresses, and didn't configure your email...


Then you would still get that warning, as your committer data is also 
not matched.


The coreboot project doesn’t have these restrictions, and in the past 
there hasn’t been any problems.


Have there been actual problems in the past?


At least the committer address should also be looked at. Or some kind of
Signed-off-by procedure.


That is already in place, as mentioned by Jan.


At least it’s not documented.


Kind regards,

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

Re: Gerrit prevents upstreaming patches from others

[Paul Menzel]

Dear Jan,


On 02/06/17 10:56, jan iversen wrote:


Sorry, I didn’t understand *you have one step more merging to git*.


Patches in Gerrit are for review, when reviewed a committer merged them to the 
git repo e.g, master, and from that time the are part of the LibreOffice code 
base.


Sorry, I still don’t see where the additional step is?


Kind regards,

Paul


PS: Sorry, but I really can’t understand your arguments. Maybe because 
of the language barrier.

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

Re: Gerrit prevents upstreaming patches from others

[Paul Menzel]

Dear Jan,


On 02/06/17 10:43, jan iversen wrote:



I don’t see how that is required. In Gerrit, it would still be clear, who 
pushed the patch (owner).

>

yes but you have one step more merging to git, and if that is done by a third 
person information would be lost.


Sorry, I didn’t understand *you have one step more merging to git*.


Please tell me how. Do you want me send the patch to the mailing list?

>

yes or not to send it to hundreds of people, mail it to 
j...@documentfoundation.org and I will submit it.

please remember to include the author details.


Will do. Thank you.


Kind regards,

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

Re: Gerrit prevents upstreaming patches from others

[Paul Menzel]

Dear Jan,


On 02/06/17 10:32, Jan Iversen wrote:


The gerrit allows people with committer status, to push patches for other 
people. In that case the email addr, from the person pushing becomes committer 
email, and the email from from patch owner becomes the author.

To do this please remember to use —author and —author-email in the commit 
statement.


Thank you, but I knew that already.

(Please note, that your mailer mangles `--` to `—`.


No-committers cannot push patches on behalf of of others, because it would 
require 3 emails addresses in git (the email who merges the patch (the 
committer), the one who submitted the patch (the committer) and the author).


I don’t see how that is required. In Gerrit, it would still be clear, 
who pushed the patch (owner).


As written, Signed-off-by lines would be a solution, if you want to 
record that information.



I am happy to help you push the patch, with the correct author.


Please tell me how. Do you want me send the patch to the mailing list?


Kind regards,

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

Gerrit prevents upstreaming patches from others

[Paul Menzel]

Dear LibreOffice folks,


I was asked to push a commit for review to the LO Gerrit instance [1].

The patch is from a colleague, who is denoted as the commit author. No 
Gerrit complains, that I am not the author, and my colleagues email 
address is not registered to *my* Gerrit account.


Could you please change that, and disable that limitation? I don’t see 
any reason for it.


At least the committer address should also be looked at. Or some kind of 
Signed-off-by procedure.



Kind regards,

Paul


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=100459
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice