Re: Dynamic OpenSSL causes Curl regression on *nix

[Damjan Jovanovic]

On Tue, Apr 23, 2024 at 11:27 AM Pedro Lino 
wrote:

> Hi Damjan
>
> > On 04/22/2024 6:21 PM WEST Damjan Jovanovic  wrote:
>
> > Now what would you guys prefer:
> > - Should I do more testing, on Windows and Linux, and push my changes in
> a
> > few days?
> > - Should I push my changes now, and let you guys test too, and fix any
> > problems as we discover them?
>
> I prefer B. More people testing in different scenarios is probably better.
>
> Best,
> Pedro
>
>
I've now verified it works on Windows too, and have pushed the commits to
trunk.

Here they are, in case you want to cherry-pick:

commit f7b97bf7d9139c8b602d3da3aadbeef0631e39c1 (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: Damjan Jovanovic 
Date:   Sun Apr 21 17:07:24 2024 +0200

Override OpenSSL's certificate verification with our own, instead of
using its verification and selectively overriding the result.
- A nonsense self-signed expired certificate is fed into Curl to get it
  to initialize even when the certificates in its expected system path
  are missing or elsewhere.
- In Curl's CURLOPT_SSL_CTX_FUNCTION, our Curl_SSLContextCallback, we
  then completely override OpenSSL's verification process with ours,
  using SSL_CTX_set_cert_verify_callback() (instead of the previous
  SSL_CTX_set_verify() which just allows us to override OpenSSL's
  verification result).
- The verification is largely the same as before, we just have to call
  slightly different functions to retrieve the certificate to verify and
  the untrusted chain.
- Create components using the component context, not the legacy multi
  service factory.
- Various other cleanups, better logging, etc. were made in the process.

    Patch by: me

commit e469ab6aed23a1b38f105a944997af16e61071d0
Author: Damjan Jovanovic 
Date:   Mon Apr 22 19:23:06 2024 +0200

Upgrade Curl to version 8.7.1.

Patch by: me


Regards
Damjan

Re: Dynamic OpenSSL causes Curl regression on *nix

[Damjan Jovanovic]

On Tue, Apr 9, 2024 at 9:21 PM Arrigo Marchiori  wrote:

>
>
> > > I think this thread excerpt explains it:
> > > https://lists.apache.org/thread/3rvvgxnws9867krk75rw6bvhmds1t2co
> > >
> > >
> > Is that horrible bug fixed now, or does Curl/OpenSSL still crash AOO in
> > certain setups?
>
> Now when I check for update I see a dialog box with the following
> error message:
>
> Status
>   Checking for an update failed.
> Description
>   Error reading data from the Internet.
>   Server error message: Problem with the SSL CA cert (path? access
> rights?).
>
> I think that on trunk we had solved the crash, but automatic updates
> were just failing silently.
>
> I need to build ``untouched'' trunk and try again the above.
>
>
In curl lib/strerror.c, function curl_easy_strerror(), that message comes
from:

---snip---
  case CURLE_SSL_CACERT_BADFILE:
return "Problem with the SSL CA cert (path? access rights?)";
---snip---

Searching for where CURLE_SSL_CACERT_BADFILE appears then takes us to
lib/vtls/openssl.c (since we use OpenSSL).

In that file, it's only set in one region of the lengthy
ossl_connect_step1() function, when ssl_cafile or ssl_capath are set,
verifypeer is set, and calling SSL_CTX_load_verify_file() or
SSL_CTX_load_verify_dir() on them fails.

The ssl_cafile and ssl_capath come from options to ./configure, but those
are impossible to change, read acinclude.m4 around CURL_CHECK_CA_BUNDLE,
where if neither --with-ca-bundle nor --with-ca-path are given (or both are
given but disabled), it auto-detects the local location of the bundle. Even
a wrong path is overridden by the auto-detected one. And this auto-detected
one won't work on other Linux distributions.

So one way to fix the error would be to patch Curl's configure and/or code.

But there is another way, and that is to always call:
curl_easy_setopt( m_pCurl, CURLOPT_CAINFO, "/path/to/certificates" );
at run-time, so that the compile-time path is overridden by the one we
specify there.

Curl version 7.77.0 also added the even better option CURLOPT_CAINFO_BLOB,
which can use an in-memory PEM list, instead of a file.

But here we face a problem.

Our ::com::sun::star::xml::crypto::XSecurityEnvironment is intended to own
the certificate verification process. We just ask it whether a certificate
chain is valid, using the verifyCertificate() method. But no method exists,
to tell us what certificates are trusted.

Thus we cannot populate our trusted certificates from Mozilla/Windows, into
Curl/OpenSSL.

There are 2 ways to get it working:
1. Patch XSecurityEnvironment to add further methods to retrieve the
trusted CA root certificates from Mozilla/Windows, and use these to build
the initial certificate list to pass to Curl/OpenSSL. Then use OpenSSL to
do verification, but on certificates that fail OpenSSL's verification, use
our own verification process instead, like we do now.
2. Specify an initial nonsense certificate to Curl and OpenSSL, just to get
them to initialize, then completely override the certificate verification
with our own using the XSecurityEnvironment, before that nonsense
certificate can be used.

Option 1 seems counter-productive: why do certificate verification twice,
first in OpenSSL, and then again in XSecurityEnvironment (via NSS or
Windows's mscrypt)? Also it's quite a pain to develop, UNO interfaces are
immutable so we'd need new interfaces, new services, and many code changes.

Instead, I have successfully developed option 2:
- Curl has been upgraded to the latest version, 8.7.1.
- A nonsense self-signed expired certificate is fed into Curl to get it to
initialize.
- In Curl's CURLOPT_SSL_CTX_FUNCTION, our Curl_SSLContextCallback, we then
completely override OpenSSL's verification process with ours, using
SSL_CTX_set_cert_verify_callback() (instead of the previous
SSL_CTX_set_verify() which just allows us to override OpenSSL's
verification result).
- The verification is largely the same as before, we just have to call
slightly different functions to retrieve the certificate to verify and the
untrusted chain.
- Various other cleanups, better logging, etc. were made in the process.

And it's working! We should now be able to use HTTPS and WebDAV on any
Linux distribution, including those whose system trusted CA certificates
are in a different location or missing entirely, as long as they have the
Mozilla certificates.

Now what would you guys prefer:
- Should I do more testing, on Windows and Linux, and push my changes in a
few days?
- Should I push my changes now, and let you guys test too, and fix any
problems as we discover them?

Regards
Damjan

Re: Dynamic OpenSSL causes Curl regression on *nix

[Damjan Jovanovic]

On Wed, Apr 17, 2024 at 7:13 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> I just tried to build trunk on Windows and it stops in "curl":
>
> ...
>
> LINK : fatal error LNK1181: cannot open input file 'libeay32.lib'
> NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\link.exe' :
> return code '0x49d'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\bin\nmake.exe"' : return code '0x2'
> Stop.
> dmake:  Error code 2, while making
> './wntmsci12.pro/misc/build/so_built_so_curl'
>
> 1 module(s):
>  curl
> need(s) to be rebuilt
>
> Regards,
>
> Matthias
>
>
Hi Matthias

Please try again now, this might fix it:

commit 9b51720274ee0b7c1ade0e9b4cd4b8417efd1b6c (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: Damjan Jovanovic 
Date:   Thu Apr 18 03:38:14 2024 +0200

Fix a regression in 8eb9a7e66a3128669216ddb884f844d50ac59fb9, which
broke
delivering libcrypto.lib and libssl.lib on Windows.


Regards
Damjan

Re: Dynamic OpenSSL causes Curl regression on *nix

[Damjan Jovanovic]

On Tue, Apr 9, 2024 at 9:21 PM Arrigo Marchiori  wrote:

>
> > > I think this thread excerpt explains it:
> > > https://lists.apache.org/thread/3rvvgxnws9867krk75rw6bvhmds1t2co
> > >
> > >
> > Is that horrible bug fixed now, or does Curl/OpenSSL still crash AOO in
> > certain setups?
>
> Now when I check for update I see a dialog box with the following
> error message:
>
> Status
>   Checking for an update failed.
> Description
>   Error reading data from the Internet.
>   Server error message: Problem with the SSL CA cert (path? access
> rights?).
>
> I think that on trunk we had solved the crash, but automatic updates
> were just failing silently.
>

Thank you, I know how to reproduce this issue even on FreeBSD, which should
make testing easier.

The problem is that when building Curl, it detects one path to the system
certificate store, but at runtime, when it can't find it there, it fails
with that error.

I am investigating.

Regards
Damjan

Re: Dynamic OpenSSL causes Curl regression on *nix

[Damjan Jovanovic]

On Tue, Apr 9, 2024 at 10:14 PM Arrigo Marchiori  wrote:

> Hello Damjan, All,
>
> replying to this other message.
>
> On Mon, Apr 08, 2024 at 02:42:01PM +, Damjan Jovanovic wrote:
>
> [...]
> > Here's how you set RPATH in Curl:
> >
> > ---snip---
> > diff --git a/main/curl/makefile.mk b/main/curl/makefile.mk
> > index 044bf4d8c9..ecef11820a 100644
> > --- a/main/curl/makefile.mk
> > +++ b/main/curl/makefile.mk
> > @@ -59,6 +59,7 @@ curl_LDFLAGS+:=$(ARCH_FLAGS)
> >  ssl_param=--with-ssl
> >  .ELSE
> >  ssl_param=--with-ssl=$(OUTDIR)
> > +curl_LDFLAGS+=-Wl,-z,origin -Wl,-rpath,\\\$$\$$ORIGIN
> >  PATCH_FILES+= curl-bundled_openssl.patch
> >  .ENDIF
> >
> > ---snip---
> >
> > which gets libcurl.so to search for the OpenSSL dynamic libraries in its
> > own directory before the system directories:
> >
> > $ ldd solver/450/unxfbsdx.pro/lib/libcurl.so
> > ...
> > libssl.so.3 => /path/to/openoffice-git/main/solver/450/
> > unxfbsdx.pro/lib/libssl.so.3 (0x299f766bc000)
> > libcrypto.so.3 => /path/to/openoffice/openoffice-git/main/solver/450/
> > unxfbsdx.pro/lib/libcrypto.so.3 (0x299f77747000)
>
> It works under Linux too!
>

Great, thank you for testing.


> If we want to use the dynamically linked OpenSSL, then, we have to
> amend 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3 and have
> main/scp2/source/ooo/file_library_ooo.scp include "libssl.so.3" and
> "libcrypto.so.3" instead of "libssl.so" and "libcrypto.so".
>
> I think the same should happen under FreeBSD, so you may want to
> commit all these edits together after testing them?
>

Here is my change:

commit 8eb9a7e66a3128669216ddb884f844d50ac59fb9 (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: Damjan Jovanovic 
Date:   Sun Apr 7 10:41:42 2024 +0200

Build OpenSSL as a dynamic link library, instead of a static library.
Patch its users to use an RPATH of $ORIGIN, so they use the correct
copy.
This reduces the size of the build by about 4615 KiB, or 3.78%.


>
> Next step will be asking p11-kit for the CA certificates, as you
> proposed here:
> https://lists.apache.org/thread/3rb1t9jf5fnp4nfxr2z9dxmzt9l61tjq
> otherwise Linux builds may be unable to validate certificate chains,
> unfortunately.
>

No, that was a separate issue. I wanted to make a new xmlsecurity provider
that could be used on Linux instead of Mozilla (which requires category B
nss) and mscrypto for Windows. As currently, --disable-category-b badly
breaks AOO: the macro security dialog won't open, the document signatures
dialog won't open, and a few other features probably break.

We'd need to provide at least the following:
- Cryptographic functions. We could do that with OpenSSL.
- The read-only trusted system certificate store. We could do that with
p11-kit's trust policy module.
- The writable user certificate store, with client certificates. There is
currently no way to do that on the Linux desktop. See my detailed
investigation on https://gitlab.gnome.org/GNOME/seahorse/-/issues/205 for
details, which found several bugs and even design defects that stop it from
working.

However what I am now thinking, is that we could make a partially working
provider, with just the cryptographic functions and system certificate
store, and add the user certificates later. It should only break document
signatures, rather than the macro dialog.

As for Linux validating certificate chains, I'll cover that in another
email.


>
> Best regards,
> --
> Arrigo
>
>
Regards
Damjan

Re: Dynamic OpenSSL causes Curl regression on *nix

[Damjan Jovanovic]

On Sun, Apr 7, 2024 at 5:22 PM Damjan Jovanovic  wrote:

>
>
> On Sun, Apr 7, 2024 at 2:26 PM Arrigo Marchiori  wrote:
>
> Honestly, I don't know in detail what RPATH is and how to change it,
>> and I would like to adopt the simplest approach to the problem.
>>
>
> It is a ":"-separated list of paths where the binary's dependencies are
> searched for, before trying the system paths. If it contains $ORIGIN at the
> beginning, then in the case of executables, it is the directory containing
> the executable, and in the case of libraries, it is the directory of the
> executable that loaded them. You can see how this is useful: it allows
> OpenOffice to be installed anywhere in the filesystem, and binaries can
> still find their internal dependencies, because their paths are relative to
> wherever the executable is, instead of some hardcoded location.
>
> In theory, you pass these options to the compiler when linking:
> -Wl,-z,origin -Wl,-rpath,$ORIGIN
> where -Wl,-z,origin enables the use of $ORIGIN in the path, and
> -Wl,-rpath,$ORIGIN specifies the path, in this case being the directory
> containing the executable.
> In practice, however, getting that "$" past dmake and 3 layers of shell
> quoting and escaping, is impossibly difficult.
>

Here's how you set RPATH in Curl:

---snip---
diff --git a/main/curl/makefile.mk b/main/curl/makefile.mk
index 044bf4d8c9..ecef11820a 100644
--- a/main/curl/makefile.mk
+++ b/main/curl/makefile.mk
@@ -59,6 +59,7 @@ curl_LDFLAGS+:=$(ARCH_FLAGS)
 ssl_param=--with-ssl
 .ELSE
 ssl_param=--with-ssl=$(OUTDIR)
+curl_LDFLAGS+=-Wl,-z,origin -Wl,-rpath,\\\$$\$$ORIGIN
 PATCH_FILES+= curl-bundled_openssl.patch
 .ENDIF

---snip---

which gets libcurl.so to search for the OpenSSL dynamic libraries in its
own directory before the system directories:

$ ldd solver/450/unxfbsdx.pro/lib/libcurl.so
...
libssl.so.3 => /path/to/openoffice-git/main/solver/450/
unxfbsdx.pro/lib/libssl.so.3 (0x299f766bc000)
libcrypto.so.3 => /path/to/openoffice/openoffice-git/main/solver/450/
unxfbsdx.pro/lib/libcrypto.so.3 (0x299f77747000)

Regards
Damjan

Re: Dynamic OpenSSL causes Curl regression on *nix

[Damjan Jovanovic]

On Sun, Apr 7, 2024 at 2:26 PM Arrigo Marchiori  wrote:

> Hello Damjan, All,
>
> On Sun, Apr 07, 2024 at 01:53:08PM +0000, Damjan Jovanovic wrote:
>
> > Hi
> >
> > With Pedro Lino's help, I've discovered a serious regression, where Curl
> > (and libraries that use Curl) can fail to load, because they've been
> > dynamically linked to OpenSSL but cannot find the copy of OpenSSL shipped
> > with OpenOffice.
>
> [big snip]
>
> [...]
>
> > When main/oox linked to internal OpenSSL, it did dynamically on Windows,
> > and on *nix, dynamically to system OpenSSL, and statically to internal
> > OpenSSL.
>
> I might have missed the end of this sentence: "statically to internal
> OpenSSL".
>
> >
> ---
> > 2022-05-06, commit 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3
> >
> ---
> > "Fix including OpenSSL dynamic libraries on Unix (#147)" by Arrigo.
> >
> > OpenSSL, on *nix, now starts delivering static and dynamic libraries, and
> > packaging dynamic libraries at the end of the build.
> > Curl continues using OpenSSL, but now since both static and dynamic
> OpenSSL
> > libraries are available, it favours the dynamic.
> > main/oox still links to OpenSSL statically outside Windows.
> > main/ucb still links to OpenSSL statically outside Windows.
>
> [...]
>
> > 
> > CURL LOADS WRONG OPENSSL
> > 
> >
> > Now the combination of these last 2 commits broke Curl (and possibly
> python
> > and redland as well) as follows:
> > - Internal modules have their RPATH set to $ORIGIN (among others), and
> thus
> > always search for dependencies in the same directory as themselves at
> > runtime.
> > - Third-party modules usually do not set their RPATH. In libcurl.so, it's
> > unset.
> > - When only static libraries are present at link-time, the binary being
> > linked, is linked to them statically. So before
> > 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3, Curl was linking statically to
> > OpenSSL.
>
> Apparently not. My purpose, with that commit, was to include the
> OpenSSL libraries _linked by the AOO executable_, that were: dynamic.
>
> In other words, the SSL libraries were not linked statically when
> building on my system. They were linked dynamically instead.
>
>
What happens currently, with OpenSSL 3, if you revert most of
0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3 (I think the makefile.mk change is
still correct)? Does Curl still link to OpenSSL dynamically, or does it
start linking statically? For me, on FreeBSD, it links statically.


> I think this thread excerpt explains it:
> https://lists.apache.org/thread/3rvvgxnws9867krk75rw6bvhmds1t2co
>
>
Is that horrible bug fixed now, or does Curl/OpenSSL still crash AOO in
certain setups?


> [...]
>
> > ==
> > LINK STATICALLY OR SET RPATH?
> > ==
> >
> > There are 2 ways to fix this:
> > 1. Provide only static OpenSSL libraries at build and run time, to force
> > Curl to link to OpenSSL statically.
> > 2. Provide OpenSSL dynamically, but set RPATH to $ORIGIN in all binaries
> > that use it (including Curl), so they can find the local OpenSSL copy
> that
> > ships with OpenOffice.
> >
> > Arrigo: why did you ever make OpenSSL deliver dynamic libraries? Were you
> > planning to implement option 2?
>
> Not at all. I just wanted to fix the problem of the (required) OpenSSL
> libraries missing from the AOO distribution.
>
> I now agree that 1. is the best solution, and that my commit including
> the .so files was sort of a wrong solution to the problem.
>
> Honestly, I don't know in detail what RPATH is and how to change it,
> and I would like to adopt the simplest approach to the problem.
>

It is a ":"-separated list of paths where the binary's dependencies are
searched for, before trying the system paths. If it contains $ORIGIN at the
beginning, then in the case of executables, it is the directory containing
the executable, and in the case of libraries, it is the directory of the
executable that loaded them. You can see how this is useful: it allows
OpenOffice to be installed anywhere in the filesystem, and binaries can
still find their internal dependencies, because their paths are relative to
wherever the executable is, instead of some hardcoded location.

In theory, you pass these options to the compiler when linking:
-Wl,-z,origin -Wl,-rpath

Dynamic OpenSSL causes Curl regression on *nix

[Damjan Jovanovic]

Hi

With Pedro Lino's help, I've discovered a serious regression, where Curl
(and libraries that use Curl) can fail to load, because they've been
dynamically linked to OpenSSL but cannot find the copy of OpenSSL shipped
with OpenOffice.

==
TIMELINE
==


2011, commit 72ebe82f8122a4cf6f6f9eea0178f07d12863421

Initial import from Oracle.

Curl was built with --without-ssl (no OpenSSL support).
OpenSSL, on *nix, delivered static libraries only. On Windows, it delivered
both static and dynamic.
As per main/solenv/inc/libs.mk, dmake could link to OpenSSL statically
(OPENSSL_ST) or dynamically (OPENSSL).
When main/oox linked to internal OpenSSL, it did dynamically on Windows,
and on *nix, dynamically to system OpenSSL, and statically to internal
OpenSSL.

-
2016, commit b63233d868a9af170b0457a7aa0c5809011cc2c1
-
gbuid-reintegration branch, based on Oracle's gbuild branch, is merged to
trunk.
gbuild gains the ability to link to OpenSSL.

OpenSSL, on *nix, still delivers only static libraries.
Curl still doesn't use OpenSSL.
main/oox still links to OpenSSL statically outside Windows, despite now
doing it through gbuild.

-
2022-04-04, commit 51ba086bf122dbb5b50fd813e5b9a81c051aa16b
-
"Port our WebDAV content provider from serf/apr/apr-util, to curl."

OpenSSL, on *nix, still delivers only static libraries.
Curl now begins using OpenSSL.
main/oox still links to OpenSSL statically outside Windows.
main/ucb links to OpenSSL statically outside Windows.

---
2022-05-06, commit 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3
---
"Fix including OpenSSL dynamic libraries on Unix (#147)" by Arrigo.

OpenSSL, on *nix, now starts delivering static and dynamic libraries, and
packaging dynamic libraries at the end of the build.
Curl continues using OpenSSL, but now since both static and dynamic OpenSSL
libraries are available, it favours the dynamic.
main/oox still links to OpenSSL statically outside Windows.
main/ucb still links to OpenSSL statically outside Windows.

---
2024-03-18, commit 4c5b548fb6ece87dd30bbf720aca0d994a749167
---
"Upgrade OpenSSL to version 3.0.13."

OpenSSL, on *nix, continues delivering static and dynamic libraries, and
packaging dynamic libraries at the end of the build. These libraries
however have a different name on OpenSSL 3.
Curl continues using OpenSSL, but now since both static and dynamic OpenSSL
libraries are available, it favours the dynamic.
main/oox still links to OpenSSL statically outside Windows.
main/ucb still links to OpenSSL statically outside Windows.


CURL LOADS WRONG OPENSSL


Now the combination of these last 2 commits broke Curl (and possibly python
and redland as well) as follows:
- Internal modules have their RPATH set to $ORIGIN (among others), and thus
always search for dependencies in the same directory as themselves at
runtime.
- Third-party modules usually do not set their RPATH. In libcurl.so, it's
unset.
- When only static libraries are present at link-time, the binary being
linked, is linked to them statically. So before
0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3, Curl was linking statically to
OpenSSL.
- When dynamic libraries for OpenSSL became present in
0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3, Curl began linking to OpenSSL
dynamically.
- Curl thus began using the Linux distribution's OpenSSL, despite us
shipping our own, because libcurl.so's RPATH isn't set, so it doesn't
search its own directory for OpenSSL.
- Many operating systems still have OpenSSL 1 installed, so the fact Curl
gained a hidden runtime dependency on system OpenSSL wasn't immediately
apparent...
- When we upgraded to OpenSSL 3, Curl began linking to OpenSSL 3, and thus
needing the Linux distribution to have OpenSSL 3.
- Older Linux distributions, like Ubuntu 20.04, don't have OpenSSL 3 yet.
So Curl refuses to load. Anything needing Curl (WebDAV, automatic updates)
also refuses to load.

==
LINK STATICALLY OR SET RPATH?
==

There are 2 ways to fix this:
1. Provide only static OpenSSL 

Re: OpenSSL upgraded to 3.0.13

[Damjan Jovanovic]

On Sun, Apr 7, 2024 at 3:52 AM Damjan Jovanovic  wrote:

>
>
> On Sat, Apr 6, 2024 at 9:30 PM Pedro Lino 
> wrote:
>
>> Hi Damjan
>>
>> > On 04/06/2024 4:08 PM WEST Damjan Jovanovic  wrote:
>>
>> > openoffice-maps.txt was for the shell script that launches AOO, and
>> > openoffice-maps2.txt was for AOO itself.
>>
>> I'm glad I sent both :)
>>
>> > In openoffice-maps2.txt I don't see libucpdav1.so (the WebDAV
>> component) in
>> > memory at all, which is highly unusual.
>> >
>> > Please find libucpdav1.so in your AOO installation, probably under
>> > /opt/openoffice4/programs, and then run these:
>> > ldd libucpdav1.so
>> > readelf -d libucpdav1.so
>> > and post the output.
>>
>> Thank you again for your patience and instructions!
>> Please find two files attached
>>
>>
> This:
> libssl.so.3 => not found
> libcrypto.so.3 => not found
> is a serious problem.
>
> Something has managed to link to OpenSSL dynamically instead of
> statically, causing a hard dependency on the underlying Linux distro to
> have OpenSSL 3.
>
> Since your older Linux doesn't have OpenSSL 3 yet, modules that need it,
> can't even load.
>
> And having installed that Linux nightly build myself, here is the culprit:
>
> ---snip---
> $ readelf -d libcurl.so.4
>
> Dynamic section at offset 0x72d40 contains 30 entries:
>   TagType Name/Value
>  0x0001 (NEEDED) Shared library: [libidn2.so.0]
>
>
> * 0x0001 (NEEDED) Shared library:
> [libssl.so.3] 0x0001 (NEEDED) Shared library:
> [libcrypto.so.3]* 0x0001 (NEEDED) Shared library:
> [libz.so.1]
>  0x0001 (NEEDED) Shared library: [libpthread.so.0]
>  0x0001 (NEEDED) Shared library: [libc.so.6]
>  0x000e (SONAME) Library soname: [libcurl.so.4]
> ---snip---
>
> Curl has started linking to OpenSSL dynamically instead of statically,
> probably a result of our recent OpenSSL upgrade, and thus became dependent
> on the Linux distribution having OpenSSL 3.
>
> Let me investigate where Curl goes wrong...
>

I'll be starting a separate thread to discuss the problem with Curl that I
found.

Regards
Damjan

Re: OpenSSL upgraded to 3.0.13

[Damjan Jovanovic]

On Sat, Apr 6, 2024 at 9:30 PM Pedro Lino 
wrote:

> Hi Damjan
>
> > On 04/06/2024 4:08 PM WEST Damjan Jovanovic  wrote:
>
> > openoffice-maps.txt was for the shell script that launches AOO, and
> > openoffice-maps2.txt was for AOO itself.
>
> I'm glad I sent both :)
>
> > In openoffice-maps2.txt I don't see libucpdav1.so (the WebDAV component)
> in
> > memory at all, which is highly unusual.
> >
> > Please find libucpdav1.so in your AOO installation, probably under
> > /opt/openoffice4/programs, and then run these:
> > ldd libucpdav1.so
> > readelf -d libucpdav1.so
> > and post the output.
>
> Thank you again for your patience and instructions!
> Please find two files attached
>
>
This:
libssl.so.3 => not found
libcrypto.so.3 => not found
is a serious problem.

Something has managed to link to OpenSSL dynamically instead of statically,
causing a hard dependency on the underlying Linux distro to have OpenSSL 3.

Since your older Linux doesn't have OpenSSL 3 yet, modules that need it,
can't even load.

And having installed that Linux nightly build myself, here is the culprit:

---snip---
$ readelf -d libcurl.so.4

Dynamic section at offset 0x72d40 contains 30 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library: [libidn2.so.0]


* 0x0001 (NEEDED) Shared library:
[libssl.so.3] 0x0001 (NEEDED) Shared library:
[libcrypto.so.3]* 0x0001 (NEEDED) Shared library:
[libz.so.1]
 0x0001 (NEEDED) Shared library: [libpthread.so.0]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x000e (SONAME) Library soname: [libcurl.so.4]
---snip---

Curl has started linking to OpenSSL dynamically instead of statically,
probably a result of our recent OpenSSL upgrade, and thus became dependent
on the Linux distribution having OpenSSL 3.

Let me investigate where Curl goes wrong...

Regards
Damjan

Re: OpenSSL upgraded to 3.0.13

[Damjan Jovanovic]

On Sat, Apr 6, 2024 at 2:30 PM Pedro Lino 
wrote:

> Hi Damjan
>
> > After trying a WebDav connection, find the process ID (PID) of
> OpenOffice,
> > copy /proc/PID/maps somewhere (eg. for PID 1234, run "cp /proc/1234/maps
> > ~/openoffice-maps.txt") and attach that copy, so we can see what
> libraries
> > are loaded.
>
> Two files attached: maps.txt is the map for soffice and maps2.txt is the
> map for soffice.bin
>
>
Thank you.

openoffice-maps.txt was for the shell script that launches AOO, and
openoffice-maps2.txt was for AOO itself.

In openoffice-maps2.txt I don't see libucpdav1.so (the WebDAV component) in
memory at all, which is highly unusual.

Please find libucpdav1.so in your AOO installation, probably under
/opt/openoffice4/programs, and then run these:
ldd libucpdav1.so
readelf -d libucpdav1.so
and post the output.

Regards
Damjan

Re: OpenSSL upgraded to 3.0.13

[Damjan Jovanovic]

On Thu, Apr 4, 2024 at 9:52 PM Pedro Lino 
wrote:

> Hi Damjan
>
> Thank you for the reply, the macro and detailed instructions!
>
>
> > On 04/04/2024 5:37 PM WEST Damjan Jovanovic  wrote:
> >
> > To get further details:
> >
> > Open the attached "Logging macros" file (we allow attachments on this
> list, right?).
> > Allow macros when prompted.
> > Tools -> Macros -> Run macro, under "Logging macros.ods" expand
> "Standard", select "logging", on the right side select
> "LogWebDavToConsole", and click "Run".
> > Exit OpenOffice.
> > Start OpenOffice from the command line, with output redirected to a
> file, eg:
> > soffice 2>&1 | tee ~/webdav-log.txt
> > Make your WebDav connection. If you used the above command, the command
> line window can be placed side-by-side with OpenOffice, and you can watch
> the logging interactively.
> > When it fails, exit OpenOffice, and attach ~/webdav-log.txt to your
> reply email, after removing any sensitive info (eg. passwords) from the log.
> >
>
> After installing canberra-gtk-module the only line I get in the log is
>
> ** (soffice:12094): WARNING **: 22:36:39.392: Unknown type: GailWindow
>
> which apparently is a long know message, and nothing else.
> The message "Nonexistent object. Nonexistent file" pops up but it is not
> registered in the log.
>
>
OpenOffice has several logging methods, and third-party libraries can also
log. That message apparently came from another logging method, not our one,
because our one has a different format.


> Any ideas? Could this simply be a kernel issue since it works correctly in
> Ubuntu 22.04?
>

- Make sure you run "LogWebDavToConsole" and not one of the other macros.
- You need to test a recent version of trunk, not an older version of
OpenOffice, because we only added that logging method to trunk in May 2022.
- When you run "soffice" from the command line, are you sure the right
version of OpenOffice is being run, the same version you ran that macro in?

On *nix, "internal" OpenSSL is linked statically, and it shouldn't matter
whether it is installed by your distribution or what version is installed.
"System" OpenSSL (configure --with-system-openssl) is linked dynamically. I
think we use "internal" OpenSSL for the Linux binaries.

After trying a WebDav connection, find the process ID (PID) of OpenOffice,
copy /proc/PID/maps somewhere (eg. for PID 1234, run "cp /proc/1234/maps
~/openoffice-maps.txt") and attach that copy, so we can see what libraries
are loaded.


>
> Thanks!
>
> Best,
> Pedro
>

Good luck
Damjan

Re: OpenSSL upgraded to 3.0.13

[Damjan Jovanovic]

To get further details:

Open the attached "Logging macros" file (we allow attachments on this list,
right?).
Allow macros when prompted.
Tools -> Macros -> Run macro, under "Logging macros.ods" expand "Standard",
select "logging", on the right side select "LogWebDavToConsole", and click
"Run".
Exit OpenOffice.
Start OpenOffice from the command line, with output redirected to a file,
eg:
soffice 2>&1 | tee ~/webdav-log.txt
Make your WebDav connection. If you used the above command, the command
line window can be placed side-by-side with OpenOffice, and you can watch
the logging interactively.
When it fails, exit OpenOffice, and attach ~/webdav-log.txt to your reply
email, after removing any sensitive info (eg. passwords) from the log.

Regards
Damjan

On Wed, Apr 3, 2024 at 4:31 PM Pedro Lino 
wrote:

> Hi All
>
> I installed the 2024-04-02 trunk Nightly (Thank you Matthias!)
> WebDAV does not seem to be working (at least under Ubuntu 20.04 x64)
>
> Opening an https link to a Webdav folder returns "Nonexistent object.
> Nonexistent file"
>
> Opening the same link in 4.1.15 in the same PC opens the "Authentication
> Required" dialog
>
> Please let me know what I can do to get further details but please
> remember I am not a programmer.
>
> Best,
> Pedro
>
> ~
> > On 04/02/2024 4:38 PM WEST Matthias Seidel 
> wrote:
> >
> >
> > Hi All,
> >
> > Am 01.04.24 um 18:31 schrieb Matthias Seidel:
> > > Hi Pedro,
> > >
> > > Am 01.04.24 um 18:18 schrieb Pedro Lino:
> > >> Hi Matthias
> > >>
> > >>> On 04/01/2024 10:33 AM WEST Matthias Seidel
> > >>>  wrote:
> > >>> And you are right, the buildbot workers are offline for 9 days now...
> > >> Maybe the Bots were celebrating Electric Easter or Digital Fools Day
> ;)
> > >>
> > >>> Somehow this isn't monitored and/or nobody cares. ;-)
> > >> If a message is received when it is successful, then it would require
> > >> a second script to warn when it fails? Is this how it works? Who
> > >> takes of this?
> > >
> > > If there is someone from our project interested in our buildbots
> > > he/she can always look here:
> > >
> > > https://www.openoffice.org/download/devbuilds.html
> > >
> > > And follow the "Summary" link.
> > >
> > > BTW: This "Worker" isn't exclusive for OpenOffice, it builds a lot of
> > > other projects.
> >
> > Correction: Apart from the OpenOffice tasks only one JMeter task is
> > running on that machine and that fails every time.
> >
> > JIRA ticket is now here:
> >
> > https://issues.apache.org/jira/browse/INFRA-25677
> >
> > Regards,
> >
> > Matthias
> >
> > >
> > > Regards,
> > >
> > >Matthias
> > >
> > >>
> > >> Best,
> > >> Pedro
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Logging macros.ods
Description: application/vnd.oasis.opendocument.spreadsheet

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: OpenSSL upgraded to 3.0.13

[Damjan Jovanovic]

On Sun, Mar 31, 2024 at 1:27 PM Matthias Seidel 
wrote:

> Hi Damjan, All,
>
> Am 29.03.24 um 15:32 schrieb Matthias Seidel:
> > Hi Damjan,
> >
> > Am 29.03.24 um 10:33 schrieb Damjan Jovanovic:
> >> Hi
> >>
> >> I've now pushed commit 4c5b548fb6ece87dd30bbf720aca0d994a749167 into
> >> trunk,
> >> upgrading our OpenSSL version from 1.0.2u to 3.0.13.
> >
> > Great!
> >
> > I am just doing a build on Windows.
>
> Builds fine for me!
>
> But I am not sure how to test OpenSSL functionality?
>
>
OpenSSL is used for:
* opening encrypted OOXML files.
* WebDAV connections to https:// servers.
* Python scripting, for hashing, SSL, possibly others.
* possibly Curl, during automatic updates.

Regards
Damjan

Re: MS Office 2010+ "Agile" encrypted OOXML documents are working now!

[Damjan Jovanovic]

On Sun, Mar 17, 2024 at 5:46 PM Matthias Seidel 
wrote:

> Hi Dave,
>
> Am 17.03.24 um 18:01 schrieb Dave Fisher:
> > Hi Damjan,
> >
> > I know it “opens a big can of worms” and is another issue, but upgrading
> to a newer OpenSSL for Trunk and maybe 4.2 would be a very good thing,
>
> We need to update a lot of things, including openSSL and MSVC...
>
> But we should first try to get a working build system for AOO42X, so we
> are able to do a release after all these years.
>
> My PRs are on hold until then. Even my work on the Help files has
> stopped because of the old SDF files.
>
>
What is wrong with the build system for AOO42X?

Regards
Damjan

OpenSSL upgraded to 3.0.13

[Damjan Jovanovic]

Hi

I've now pushed commit 4c5b548fb6ece87dd30bbf720aca0d994a749167 into trunk,
upgrading our OpenSSL version from 1.0.2u to 3.0.13.

Some issues to consider:

-
PLATFORMS
-
It works on FreeBSD 14, both with system OpenSSL linked dynamically and
internal OpenSSL linked statically.

Linux hasn't been tested but is so similar to FreeBSD that it really should
work.

It works on Windows, with the following changes:
- OpenSSL requires Perl to build, but doesn't like Cygwin's Perl.
Previously, OpenSSL 1.0.2u was patched to use Cygwin's Perl, but OpenSSL 3
completely changed the build system, and I couldn't port the old patches.
Now note how traditionally our build tools (eg. make, Apache Ant, awk, sed,
etc.) were all installed prior to building OpenOffice, detected by
./configure, and then used during the build. I've done something different:
during ./bootstrap it will now download the Win32 Strawberry Perl portable
binaries as a dependency, and while building OpenSSL, it will unzip these
and temporarily use them as the Perl for building OpenSSL. This works, and
should reliably continue to work, but is a bit unusual, uses close to 800
MB extra disk space, and cannot use a system-wide Strawberry Perl instead
of the portable binaries, so it is something we may want to change going
forward. On the plus side, this new approach neither requires any
additional options to ./configure, nor babysitting any more build
dependencies, nor dragging around long patches to change OpenSSL to use
Cygwin's Perl. If anybody objects, speak up.
- Some defines were missing from MSVC's header files, for the ancient
version of the MSVC compiler we use, so I had to add them as command line
parameters to the compiler instead, eg.
"-DINT64_MAX=9223372036854775807i64".
- OpenSSL normally requires fairly recent versions of Windows, but also
supports the more minimal Windows CE, and so has fallback paths that can be
used for older versions of Windows. I've configured it to target Windows 95
and NT 4.0, and added a small number of patches that fix the build issues,
mostly by using the Windows CE fallback code.
- NASM is handled better: before, when NASM was already in the $PATH
instead of --with-nasm-path being passed to ./configure, building openssl
would break. It now works.
- Python needed a lot of patching to use OpenSSL 3, and the Win64 build of
python is probably broken and will need further work.
- It takes really long to build. We could disable unit tests to speed it up
(by passing "no-tests" to Configure), but I am not sure I like skipping
tests. We should be testing more, not less.

macOS? Who knows. It looks like on macOS, our main/openssl module links
statically, and doesn't apply any patches, so it might already work.

-
LICENSING
-
Licensing has changed, as OpenSSL 3 is under the Apache Software License v2
like ourselves, and our LICENSE and NOTICE files have been greatly
simplified.

-
CODE CHANGES
-
Remarkably, no changes to our C/C++ code were required. Some code changes
were required in the past, eg. f884850fece86ece56c7194bb1e746641f77c0a0 to
deal with EVP_CIPHER_CTX_init() -> EVP_CIPHER_CTX_new() between OpenSSL
1.0.x and 1.1.x. However, nothing needed changing between 1.1.x and 3.0.13,
OpenSSL was sufficiently backward compatible.

--
OTHER BRANCHES
--
While those 1.0.x -> 1.1.x code changes are in trunk, they may be absent
from other branches, so cherry picking this commit to other branches may
require more commits to be cherry picked.

-
FUTURE
-
OpenSSL 3.0.x is the LTS release series, and will be supported until
2026-09-07.

Regards
Damjan

Re: MS Office 2010+ "Agile" encrypted OOXML documents are working now!

[Damjan Jovanovic]

That's great. Thank you for testing.

My own tests also show it no longer crashes, both the Standard and Agile
encryption are working now :).

On Sun, Mar 17, 2024 at 7:59 PM Matthias Seidel 
wrote:

> Hi Damjan, All,
>
> That seems to have fixed the crashes on Windows...
>
> Regards,
>
> Matthias
>
> Am 17.03.24 um 16:56 schrieb Matthias Seidel:
> > I am already doing a full build,but hopefully I could pull your last
> > commit soon enough.
> >
> > Regards,
> >
> >    Matthias
> >
> > Am 17.03.24 um 15:20 schrieb Damjan Jovanovic:
> >> If you haven't done "dmake clean" yet like me, try to "git pull" my
> >> latest
> >> commit, and then in main/instsetoo_native "build --from oox -P2 -- -P2".
> >>
> >> This commit fixes at least one more issue:
> >>
> >> commit 244f2bcc921bc5dc45e6c1970e27ac2409c44e17 (HEAD -> trunk,
> >> origin/trunk, origin/HEAD)
> >> Author: Damjan Jovanovic 
> >> Date:   Sun Mar 17 15:56:38 2024 +0200
> >>
> >>  Don't allow calls to OpenSSLCipher::blockSize() before the cipher
> >>  is initialized.
> >>
> >> On Sun, Mar 17, 2024 at 1:24 PM Matthias Seidel
> >> 
> >> wrote:
> >>
> >>> WTH, shortly after I sent this mail I could open the files...
> >>>
> >>> Matthias
> >>>
> >>> Am 17.03.24 um 14:22 schrieb Matthias Seidel:
> >>>> Hi Damjan,
> >>>>
> >>>> That was fast! ;-)
> >>>>
> >>>> I can confirm that it builds now on Windows.
> >>>>
> >>>> When I try to open password protected MS Office 2020+ files (xlsx,
> >>>> docx) I now get the password dialog
> >>>>
> >>>> But when I enter the correct password AOO crashes.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Matthias
> >>>>
> >>>> P.S.: This was a partial build, I will try a complete build now.
> >>>>
> >>>> Am 17.03.24 um 12:23 schrieb Damjan Jovanovic:
> >>>>> I've fixed this now and it seems to build on Windows too. The fixes
> >>>>> are in
> >>>>> these commits, and if they work, should be cherry-picked in the given
> >>>>> order:
> >>>>>
> >>>>> f65b4e326d91bfe900dc1dd22ece69e3ddd8444a
> >>>>> f3025b08c40161265442c34e2b50bc05aa5388c6
> >>>>> 42c0a318a970f6f7f43d26a8397448d5d5b8bd36
> >>>>>
> >>>>> There were several problems on Windows. The Visual Studio 2008
> >>>>> compiler
> >>>>> doesn't have the ::std::vector::data() method (even though it
> >>>>> should, it
> >>>>> was part of the C++98/03 standard), I had to use [0] instead.
> >>>>> Also
> >>>>> that ancient OpenSSL version we use internally, 1.0.x, uses
> >>>>> EVP_MD_CTX_create()/destroy() instead of EVP_MD_CTX_new()/free().
> >>>>> Finally
> >>>>> some template function was unhappy about parameter type ambiguity
> >>>>> (even
> >>>>> though superior compilers like Clang are perfectly happy), and I had
> >>>>> to add
> >>>>> casts.
> >>>>>
> >>>>>
> >>>>> On Sun, Mar 17, 2024 at 11:15 AM Matthias Seidel
> >>>>> 
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Damjan,
> >>>>>>
> >>>>>> You are right, the interesting part is at the beginning:
> >>>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> =
> >>>>>> Building module oox
> >>>>>> =
> >>>>>>
> >>>>>> Entering /cygdrive/c/Source/openoffice/main/oox/prj
> >>>>>>
> >>>>>> cd .. && make -s -r -j1   && make -s -r deliverlog
> >>>>>> [ build CXX ] oox/source/core/encryption
> >>>>>> encryption.cxx
> >>>>>>
> c:/Source/openoffice/main/oox/inc\oox/helper/openssl_wrapper.hxx(44)
> >>>>>> :
> >>>>>> error C3861: 'EVP_MD_CTX_new': identifier not found
> >>>>>>
> c:/Source/openoffice/main/oox/inc\oox/helper/open

OpenSSL upgrade?

[Damjan Jovanovic]

Hi

Is there some reason we are still using such an old version of OpenSSL?

>From what I see, these are the modules that depend on OpenSSL:
$ grep -l openssl */prj/build.lst
curl/prj/build.lst
oox/prj/build.lst
openssl/prj/build.lst
python/prj/build.lst
redland/prj/build.lst
ucb/prj/build.lst

curl: is a heavy user of OpenSSL and really should support new versions.
oox: only used by the Standard/Agile encryption, which I successfully
tested against OpenSSL 3 recently.
python: compiles and links against OpenSSL 3.
redland: unknown
ucb: used only by the WebDAV content provider, which I added it to, and
compiles and links against OpenSSL 3, probably already works too.

It seems like an upgrade will be easy?

Regards
Damjan

On Sun, Mar 17, 2024 at 5:03 PM Dave Fisher  wrote:

> Hi Damjan,
>
> I know it “opens a big can of worms” and is another issue, but upgrading
> to a newer OpenSSL for Trunk and maybe 4.2 would be a very good thing,
>
> Best,
> Dave
>
> > On Mar 17, 2024, at 4:23 AM, Damjan Jovanovic  wrote:
> >
> > Also
> > that ancient OpenSSL version we use internally, 1.0.x, uses
> > EVP_MD_CTX_create()/destroy() instead of EVP_MD_CTX_new()/free(). Finally
> > some template function was unhappy about parameter type ambiguity (even
> > though superior compilers like Clang are perfectly happy), and I had to
> add
> > casts.
>
>

Re: MS Office 2010+ "Agile" encrypted OOXML documents are working now!

[Damjan Jovanovic]

If you haven't done "dmake clean" yet like me, try to "git pull" my latest
commit, and then in main/instsetoo_native "build --from oox -P2 -- -P2".

This commit fixes at least one more issue:

commit 244f2bcc921bc5dc45e6c1970e27ac2409c44e17 (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: Damjan Jovanovic 
Date:   Sun Mar 17 15:56:38 2024 +0200

Don't allow calls to OpenSSLCipher::blockSize() before the cipher
is initialized.

On Sun, Mar 17, 2024 at 1:24 PM Matthias Seidel 
wrote:

> WTH, shortly after I sent this mail I could open the files...
>
> Matthias
>
> Am 17.03.24 um 14:22 schrieb Matthias Seidel:
> > Hi Damjan,
> >
> > That was fast! ;-)
> >
> > I can confirm that it builds now on Windows.
> >
> > When I try to open password protected MS Office 2020+ files (xlsx,
> > docx) I now get the password dialog
> >
> > But when I enter the correct password AOO crashes.
> >
> > Regards,
> >
> >Matthias
> >
> > P.S.: This was a partial build, I will try a complete build now.
> >
> > Am 17.03.24 um 12:23 schrieb Damjan Jovanovic:
> >> I've fixed this now and it seems to build on Windows too. The fixes
> >> are in
> >> these commits, and if they work, should be cherry-picked in the given
> >> order:
> >>
> >> f65b4e326d91bfe900dc1dd22ece69e3ddd8444a
> >> f3025b08c40161265442c34e2b50bc05aa5388c6
> >> 42c0a318a970f6f7f43d26a8397448d5d5b8bd36
> >>
> >> There were several problems on Windows. The Visual Studio 2008 compiler
> >> doesn't have the ::std::vector::data() method (even though it should, it
> >> was part of the C++98/03 standard), I had to use [0] instead.
> >> Also
> >> that ancient OpenSSL version we use internally, 1.0.x, uses
> >> EVP_MD_CTX_create()/destroy() instead of EVP_MD_CTX_new()/free().
> >> Finally
> >> some template function was unhappy about parameter type ambiguity (even
> >> though superior compilers like Clang are perfectly happy), and I had
> >> to add
> >> casts.
> >>
> >>
> >> On Sun, Mar 17, 2024 at 11:15 AM Matthias Seidel
> >> 
> >> wrote:
> >>
> >>> Hi Damjan,
> >>>
> >>> You are right, the interesting part is at the beginning:
> >>>
> >>> ---
> >>>
> >>> =
> >>> Building module oox
> >>> =
> >>>
> >>> Entering /cygdrive/c/Source/openoffice/main/oox/prj
> >>>
> >>> cd .. && make -s -r -j1   && make -s -r deliverlog
> >>> [ build CXX ] oox/source/core/encryption
> >>> encryption.cxx
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/openssl_wrapper.hxx(44) :
> >>> error C3861: 'EVP_MD_CTX_new': identifier not found
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/openssl_wrapper.hxx(51) :
> >>> error C3861: 'EVP_MD_CTX_free': identifier not found
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(100) : error
> >>> C2782: 'bool oox::getFlag(Type,Type)' : template parameter 'Type' is
> >>> ambiguous
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/helper.hxx(141) : see
> >>> declaration of 'oox::getFlag'
> >>>   could be 'unsigned int'
> >>>   or   'sal_uInt32'
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(133) : error
> >>> C2782: 'bool oox::getFlag(Type,Type)' : template parameter 'Type' is
> >>> ambiguous
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/helper.hxx(141) : see
> >>> declaration of 'oox::getFlag'
> >>>   could be 'unsigned int'
> >>>   or   'sal_uInt32'
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(134) : error
> >>> C2782: 'bool oox::getFlag(Type,Type)' : template parameter 'Type' is
> >>> ambiguous
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/helper.hxx(141) : see
> >>> declaration of 'oox::getFlag'
> >>>   could be 'unsigned int'
> >>>   or   'sal_uInt32'
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(210) : error
> >>> C2039: 'data' : is not a member of 'std::vector<_Ty>'
> >>>   with
> >>>   [
> >>>   _Ty=sal_uInt8
> >>>   ]
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(21

Re: MS Office 2010+ "Agile" encrypted OOXML documents are working now!

[Damjan Jovanovic]

I've also noticed sporadic crashes. I am going to try rebuild it from
scratch to see if old files were causing a problem. If not, debug further.

On Sun, Mar 17, 2024 at 1:24 PM Matthias Seidel 
wrote:

> WTH, shortly after I sent this mail I could open the files...
>
> Matthias
>
> Am 17.03.24 um 14:22 schrieb Matthias Seidel:
> > Hi Damjan,
> >
> > That was fast! ;-)
> >
> > I can confirm that it builds now on Windows.
> >
> > When I try to open password protected MS Office 2020+ files (xlsx,
> > docx) I now get the password dialog
> >
> > But when I enter the correct password AOO crashes.
> >
> > Regards,
> >
> >Matthias
> >
> > P.S.: This was a partial build, I will try a complete build now.
> >
> > Am 17.03.24 um 12:23 schrieb Damjan Jovanovic:
> >> I've fixed this now and it seems to build on Windows too. The fixes
> >> are in
> >> these commits, and if they work, should be cherry-picked in the given
> >> order:
> >>
> >> f65b4e326d91bfe900dc1dd22ece69e3ddd8444a
> >> f3025b08c40161265442c34e2b50bc05aa5388c6
> >> 42c0a318a970f6f7f43d26a8397448d5d5b8bd36
> >>
> >> There were several problems on Windows. The Visual Studio 2008 compiler
> >> doesn't have the ::std::vector::data() method (even though it should, it
> >> was part of the C++98/03 standard), I had to use [0] instead.
> >> Also
> >> that ancient OpenSSL version we use internally, 1.0.x, uses
> >> EVP_MD_CTX_create()/destroy() instead of EVP_MD_CTX_new()/free().
> >> Finally
> >> some template function was unhappy about parameter type ambiguity (even
> >> though superior compilers like Clang are perfectly happy), and I had
> >> to add
> >> casts.
> >>
> >>
> >> On Sun, Mar 17, 2024 at 11:15 AM Matthias Seidel
> >> 
> >> wrote:
> >>
> >>> Hi Damjan,
> >>>
> >>> You are right, the interesting part is at the beginning:
> >>>
> >>> ---
> >>>
> >>> =
> >>> Building module oox
> >>> =
> >>>
> >>> Entering /cygdrive/c/Source/openoffice/main/oox/prj
> >>>
> >>> cd .. && make -s -r -j1   && make -s -r deliverlog
> >>> [ build CXX ] oox/source/core/encryption
> >>> encryption.cxx
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/openssl_wrapper.hxx(44) :
> >>> error C3861: 'EVP_MD_CTX_new': identifier not found
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/openssl_wrapper.hxx(51) :
> >>> error C3861: 'EVP_MD_CTX_free': identifier not found
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(100) : error
> >>> C2782: 'bool oox::getFlag(Type,Type)' : template parameter 'Type' is
> >>> ambiguous
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/helper.hxx(141) : see
> >>> declaration of 'oox::getFlag'
> >>>   could be 'unsigned int'
> >>>   or   'sal_uInt32'
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(133) : error
> >>> C2782: 'bool oox::getFlag(Type,Type)' : template parameter 'Type' is
> >>> ambiguous
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/helper.hxx(141) : see
> >>> declaration of 'oox::getFlag'
> >>>   could be 'unsigned int'
> >>>   or   'sal_uInt32'
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(134) : error
> >>> C2782: 'bool oox::getFlag(Type,Type)' : template parameter 'Type' is
> >>> ambiguous
> >>> c:/Source/openoffice/main/oox/inc\oox/helper/helper.hxx(141) : see
> >>> declaration of 'oox::getFlag'
> >>>   could be 'unsigned int'
> >>>   or   'sal_uInt32'
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(210) : error
> >>> C2039: 'data' : is not a member of 'std::vector<_Ty>'
> >>>   with
> >>>   [
> >>>   _Ty=sal_uInt8
> >>>   ]
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(214) : error
> >>> C2039: 'data' : is not a member of 'std::vector<_Ty>'
> >>>   with
> >>>   [
> >>>   _Ty=sal_uInt8
> >>>   ]
> >>> c:/Source/openoffice/main/oox/source/core/encryption.cxx(217) : error
> >

Re: MS Office 2010+ "Agile" encrypted OOXML documents are working now!

[Damjan Jovanovic]

n/oox/source/core/encryption.cxx(754) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(756) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(780) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(781) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(783) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(809) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(833) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(833) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(833) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(852) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(854) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(882) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(882) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(882) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(888) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(888) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(888) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(930) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(932) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(932) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(938) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>      _Ty=sal_uInt8
>  ]
> c:/Source/openoffice/main/oox/source/core/encryption.cxx(946) : error
> C2039: 'data' : is not a member of 'std::vector<_Ty>'
>  with
>  [
>  _Ty=sal_uInt8
>  ]
> make: *** No rule to make target
> '/cygdrive/c/Source/openoffice/main/solver/450/
> wntmsci12.pro/workdir/CxxObje

Re: MS Office 2010+ "Agile" encrypted OOXML documents are working now!

[Damjan Jovanovic]

Please check further up in the log, or run "build" in main/oox again.

That "No rule to make target" happens after other errors break compilation.

On Sat, Mar 16, 2024 at 8:38 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Tried to build trunk on Windows but it stops here:
>
> make: *** No rule to make target
> '/cygdrive/c/Source/openoffice/main/solver/450/
> wntmsci12.pro/workdir/CxxObject/oox/source/core/encryption.o',
> needed by
> '/cygdrive/c/Source/openoffice/main/solver/450/
> wntmsci12.pro/workdir/LinkTarget/Library/ioox.lib'.
> Stop.
> dmake:  Error code 2, while making 'all'
>
> 1 module(s):
>  oox
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /cygdrive/c/Source/openoffice/main/oox/prj
>
> When you have fixed the errors in that module you can resume the build
> by running:
>
>  build --from oox
>
> Am 16.03.24 um 04:49 schrieb Damjan Jovanovic:
> > Hi
> >
> > Bug 118236 with 7 votes, the inability to open password-protected
> > (encrypted) OOXML files from MS Office 2010+, is now fixed in trunk :-)
> >
> > ---snip---
> > commit 506fa58b1970084a0caacb50b3a805e469be4756 (HEAD -> trunk,
> > origin/trunk, origin/HEAD)
> > Author: Damjan Jovanovic 
> > Date:   Sat Mar 2 18:47:05 2024 +0200
> >
> >  Implement the (MS Office 2010+) OOXML "Agile encryption" support, so
> > that we
> >  can open such password-protected OOXML files.
> >
> >  Adds all the Agile encryption XML tokens and namespaces, and parses
> the
> > XML
> >  from EncryptionInfo stream, gets OpenOffice to recognize the file is
> > encrypted
> >  and ask for a password, and successfully decrypts the file if
> password
> > is
> >  correct.
> >
> >  Also a number of other fixes and improvements:
> >  - Sorted main/oox/source/token/tokens.txt so it's in alphabetical
> order
> >(wrong order might have broken certain tokens?).
> >  - Refactored how OOXML encryption is generally handled. It's now in
> its
> >own file.
> >  - Added logging to the FilterDetect class. It logs to the
> office-wide
> > default
> >logger.
> >  - Added a flush() method to the BinaryXOutputStream class.
> >  - Changed FilterDetect to use XMultiComponentFactory and
> > XComponentContext
> >instead of the deprecated XMultiServiceFactory.
> >  - Error handling was generally improved.
> >  - Exception safety and some memory safety (::std::vector instead of
> > new[])
> >in all the new code. Memory leaks should not be possible.
> >
> >  Much of the code involved in the decryption was ported from the
> > excellent
> >  Apache POI project, so it's been credited in our NOTICE file.
> >
> >  Patch by: me
> > ---snip---
> >
> >
> > It took much longer than I expected:
> >
> > The MS-OFFCRYPTO specification was unclear, and plain wrong in some
> parts,
> > eg. "SHA-1" in the spec but "SHA1" in actual OOXML documents; I've made
> our
> > code support both.
> >
> > The "Standard" encryption from MS Office 2007 that we already supported
> was
> > itself a mess, and much work was needed to refactor and clean up that
> code
> > before the "Agile" encryption could also be added.
> >
> > Then XML parsing had to be added, since Agile encryption specifies
> settings
> > in XML instead of binary like Standard encryption did. XML handling in
> > OpenOffice is pretty outdated, with no support for namespaces, but at
> least
> > the newer "FastParser" does support namespaces and is in fact very fast
> > because it converts strings to unique integers, and packs namespaces into
> > bit fields, for faster comparisons. I ended up updating the main/oox
> > FastParser to support the new Agile encryption namespaces and elements.
> >
> > MS-OFFCRYPTO also only describes encryption, not decryption, and since we
> > can only read OOXML, only decryption matters.
> >
> > Apache POI code was tremendously helpful in figuring out the decryption
> > process. Most of the decryption code I added was just ported directly
> from
> > theirs, and thus I've added Apache POI to our NOTICE file (please check
> > that I've done it correctly). Also several bugs were figured out by
> > simultaneously stepping through our code in gdb and their code in
> NetBeans,
> > and comparing respective values. A big thank you

MS Office 2010+ "Agile" encrypted OOXML documents are working now!

[Damjan Jovanovic]

Hi

Bug 118236 with 7 votes, the inability to open password-protected
(encrypted) OOXML files from MS Office 2010+, is now fixed in trunk :-)

---snip---
commit 506fa58b1970084a0caacb50b3a805e469be4756 (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: Damjan Jovanovic 
Date:   Sat Mar 2 18:47:05 2024 +0200

Implement the (MS Office 2010+) OOXML "Agile encryption" support, so
that we
can open such password-protected OOXML files.

Adds all the Agile encryption XML tokens and namespaces, and parses the
XML
from EncryptionInfo stream, gets OpenOffice to recognize the file is
encrypted
and ask for a password, and successfully decrypts the file if password
is
correct.

Also a number of other fixes and improvements:
- Sorted main/oox/source/token/tokens.txt so it's in alphabetical order
  (wrong order might have broken certain tokens?).
- Refactored how OOXML encryption is generally handled. It's now in its
  own file.
- Added logging to the FilterDetect class. It logs to the office-wide
default
  logger.
- Added a flush() method to the BinaryXOutputStream class.
- Changed FilterDetect to use XMultiComponentFactory and
XComponentContext
  instead of the deprecated XMultiServiceFactory.
- Error handling was generally improved.
- Exception safety and some memory safety (::std::vector instead of
new[])
  in all the new code. Memory leaks should not be possible.

Much of the code involved in the decryption was ported from the
excellent
Apache POI project, so it's been credited in our NOTICE file.

Patch by: me
---snip---


It took much longer than I expected:

The MS-OFFCRYPTO specification was unclear, and plain wrong in some parts,
eg. "SHA-1" in the spec but "SHA1" in actual OOXML documents; I've made our
code support both.

The "Standard" encryption from MS Office 2007 that we already supported was
itself a mess, and much work was needed to refactor and clean up that code
before the "Agile" encryption could also be added.

Then XML parsing had to be added, since Agile encryption specifies settings
in XML instead of binary like Standard encryption did. XML handling in
OpenOffice is pretty outdated, with no support for namespaces, but at least
the newer "FastParser" does support namespaces and is in fact very fast
because it converts strings to unique integers, and packs namespaces into
bit fields, for faster comparisons. I ended up updating the main/oox
FastParser to support the new Agile encryption namespaces and elements.

MS-OFFCRYPTO also only describes encryption, not decryption, and since we
can only read OOXML, only decryption matters.

Apache POI code was tremendously helpful in figuring out the decryption
process. Most of the decryption code I added was just ported directly from
theirs, and thus I've added Apache POI to our NOTICE file (please check
that I've done it correctly). Also several bugs were figured out by
simultaneously stepping through our code in gdb and their code in NetBeans,
and comparing respective values. A big thank you to the Apache POI
developers, whose OOXML support is still better than ours in many ways!

I used OpenSSL for all the message digest and encryption stuff, both
because our MD5 and SHA1 algorithms are broken (bug 127661), and because
Agile encryption requires many digests and ciphers that OpenSSL supports
but we don't.

Anyway, it works now. All encrypted OOXML files should work, eg. text
documents, spreadsheets, presentations, etc.

Other issues I am aware of:
- We only support password encrypted documents. Certificate encrypted
documents: not yet. ODF 1.3 also added certificate encryption, so maybe
that's something we should develop together.
- There are other variations of encryption we still don't support, eg. the
"Extensible" encryption, the "RC4 CryptoAPI" encryption, "XOR obfuscation",
etc. Apache POI would be a good source for those too. It's unclear to me
how widely those are used, and whether they are worth implementing.
- It may need to be rearchitected when we add OOXML writing.
- A lot of other required cleanups to our code were discovered, will
discuss those separately.

I've squashed all my work into a single commit, so it can be easily
cherry-picked to AOO42X and maybe even AOO41X when people are happy with it.

Regards
Damjan

Re: Problem in installing "libgnomevfs2-dev" for building OpenOffice on Debian 12.5.

[Damjan Jovanovic]

GnomeVFS was discontinued a long time ago, and replaced by GIO (and GVFS)
instead.

Luckily we support both. Pass --enable-gio and --disable-gnome-vfs to
./configure. And you can build OpenOffice without either of them, but it
would probably limit access to files on filesystems that those provide (eg.
on remote servers).

Regards
Damjan

On Tue, Feb 27, 2024 at 11:49 AM General Email <
general.email.12341...@gmail.com> wrote:

> Hi,
>
> I was planning to compile OpenOffice on debian 12.5.
>
> So, I started to install all the required packages.
>
> I am following instructions given on these pages:
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO and
>
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Building_on_Linux
>
> But when I tried to install libgnomevfs2-dev, it gave me an error: "E:
> Unable to locate package libgnomevfs2-dev".
>
> The output from command line is below:
>
> 
> sudo apt-get install libgnomevfs2-dev
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package libgnomevfs2-dev
> 
>
> Can anyone please suggest how to resolve this?
>
> Regards,
> GE
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: MacOS testing for bug 112829 (SVG clipboard format)

[Damjan Jovanovic]

What I meant is, test trunk or AOO42X, whichever is more convenient. If it
doesn't show image/svg+xml on the clipboard, apply that patch and test
again.

There is no branch which has that patch I sent, because I am not sure it
works yet.

On Sun, Feb 25, 2024 at 8:07 PM Jim Jagielski  wrote:

> I mean, is there a branch with this already folded in?
>
> > On Feb 22, 2024, at 2:27 PM, Damjan Jovanovic  wrote:
> >
> > Either trunk or AOO42X.
> >
> > On Thu, Feb 22, 2024 at 7:11 PM Jim Jagielski  wrote:
> >
> >> Which branch?
> >>
> >>> On Feb 22, 2024, at 10:54 AM, Damjan Jovanovic 
> >> wrote:
> >>>
> >>> Hi
> >>>
> >>> For bug 112829, I got graphics and charts to copy out of AOO in SVG
> >> format
> >>> on FreeBSD and Windows (and probably Linux), but I wasn't able to test
> >>> macOS. A quick look at the code shows we might need another patch to
> get
> >> it
> >>> working there, possibly the one below.
> >>>
> >>> Can someone please test it and report back? Don't only verify you can
> >>> paste, examine the clipboard formats after copying a chart, and make
> sure
> >>> it contains "image/svg+xml".
> >>>
> >>> Thank you
> >>> Damjan
> >>>
> >>> ---snip---
> >>> diff --git a/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
> >>> b/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
> >>> index d5e2b6f371..d8f67c 100644
> >>> --- a/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
> >>> +++ b/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
> >>> @@ -94,6 +94,7 @@ namespace // private
> >>>  const NSString* PBTYPE_GDIMF = @"application/x-openoffice-gdimetafile
> >>> ;windows_formatname=\"GDIMetaFile\"";
> >>>  const NSString* PBTYPE_WMF =
> >>> @"application/x-openoffice-wmf;windows_formatname=\"Image
> >>> WMF\"";
> >>>  const NSString* PBTYPE_EMF =
> >>> @"application/x-openoffice-emf;windows_formatname=\"Image
> >>> EMF\"";
> >>> +  const NSString* PBTYPE_SVG = @"image/svg+xml;windows_
> >>> formatname=\"image/svg+xml\"";
> >>>
> >>>  const NSString* PBTYPE_DUMMY_INTERNAL = @"application/x-openoffice-
> >>> internal";
> >>>
> >>> @@ -107,6 +108,7 @@ namespace // private
> >>>  const char* FLAVOR_GDIMF =
> >> "application/x-openoffice-gdimetafile;windows_
> >>> formatname=\"GDIMetaFile\"";
> >>>  const char* FLAVOR_WMF =
> >>> "application/x-openoffice-wmf;windows_formatname=\"Image
> >>> WMF\"";
> >>>  const char* FLAVOR_EMF =
> >>> "application/x-openoffice-emf;windows_formatname=\"Image
> >>> EMF\"";
> >>> +  const char* FLAVOR_SVG = "image/svg+xml;windows_
> >>> formatname=\"image/svg+xml\"";
> >>>
> >>>  const char* FLAVOR_DUMMY_INTERNAL =
> >> "application/x-openoffice-internal";
> >>>
> >>> @@ -138,6 +140,7 @@ namespace // private
> >>> { PBTYPE_GDIMF, FLAVOR_GDIMF, "GDIMetaFile", CPPUTYPE_SEQINT8
> },
> >>> { PBTYPE_WMF, FLAVOR_WMF, "Windows MetaFile", CPPUTYPE_SEQINT8
> >> },
> >>> { PBTYPE_EMF, FLAVOR_EMF, "Windows Enhanced MetaFile",
> >>> CPPUTYPE_SEQINT8 },
> >>> + { PBTYPE_SVG, FLAVOR_SVG, "Scalable Vector Graphics",
> >>> CPPUTYPE_SEQINT8 },
> >>> { PBTYPE_SODX, FLAVOR_SODX, "Star Object Descriptor (XML)",
> >>> CPPUTYPE_SEQINT8 },
> >>>  { PBTYPE_DUMMY_INTERNAL, FLAVOR_DUMMY_INTERNAL, "internal
> >>> data",CPPUTYPE_SEQINT8 }
> >>>   };
> >>> ---snip---
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [Issue 101010] Direct svg or eps export from calc

[Damjan Jovanovic]

On Thu, Feb 22, 2024 at 3:50 PM Damjan Jovanovic  wrote:

>
> - SVG can be copied out of OpenOffice, but cannot be pasted into
> OpenOffice yet.
>

This is now fixed by dbea4404ca2c86a3a74294e262e6584c3e450818 in trunk and
8809675e418555082e24d8d46f876db1e912250e in AOO42X, you can paste but
unfortunately due to some existing bug, any vector graphics format somehow
becomes rasterized during the paste, and ends up as bitmap that can't be
resized nicely. I'll open a bug report for this.

Damjan

Re: MacOS testing for bug 112829 (SVG clipboard format)

[Damjan Jovanovic]

Either trunk or AOO42X.

On Thu, Feb 22, 2024 at 7:11 PM Jim Jagielski  wrote:

> Which branch?
>
> > On Feb 22, 2024, at 10:54 AM, Damjan Jovanovic 
> wrote:
> >
> > Hi
> >
> > For bug 112829, I got graphics and charts to copy out of AOO in SVG
> format
> > on FreeBSD and Windows (and probably Linux), but I wasn't able to test
> > macOS. A quick look at the code shows we might need another patch to get
> it
> > working there, possibly the one below.
> >
> > Can someone please test it and report back? Don't only verify you can
> > paste, examine the clipboard formats after copying a chart, and make sure
> > it contains "image/svg+xml".
> >
> > Thank you
> > Damjan
> >
> > ---snip---
> > diff --git a/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
> > b/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
> > index d5e2b6f371..d8f67c 100644
> > --- a/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
> > +++ b/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
> > @@ -94,6 +94,7 @@ namespace // private
> >   const NSString* PBTYPE_GDIMF = @"application/x-openoffice-gdimetafile
> > ;windows_formatname=\"GDIMetaFile\"";
> >   const NSString* PBTYPE_WMF =
> > @"application/x-openoffice-wmf;windows_formatname=\"Image
> > WMF\"";
> >   const NSString* PBTYPE_EMF =
> > @"application/x-openoffice-emf;windows_formatname=\"Image
> > EMF\"";
> > +  const NSString* PBTYPE_SVG = @"image/svg+xml;windows_
> > formatname=\"image/svg+xml\"";
> >
> >   const NSString* PBTYPE_DUMMY_INTERNAL = @"application/x-openoffice-
> > internal";
> >
> > @@ -107,6 +108,7 @@ namespace // private
> >   const char* FLAVOR_GDIMF =
> "application/x-openoffice-gdimetafile;windows_
> > formatname=\"GDIMetaFile\"";
> >   const char* FLAVOR_WMF =
> > "application/x-openoffice-wmf;windows_formatname=\"Image
> > WMF\"";
> >   const char* FLAVOR_EMF =
> > "application/x-openoffice-emf;windows_formatname=\"Image
> > EMF\"";
> > +  const char* FLAVOR_SVG = "image/svg+xml;windows_
> > formatname=\"image/svg+xml\"";
> >
> >   const char* FLAVOR_DUMMY_INTERNAL =
> "application/x-openoffice-internal";
> >
> > @@ -138,6 +140,7 @@ namespace // private
> >  { PBTYPE_GDIMF, FLAVOR_GDIMF, "GDIMetaFile", CPPUTYPE_SEQINT8 },
> >  { PBTYPE_WMF, FLAVOR_WMF, "Windows MetaFile", CPPUTYPE_SEQINT8
> },
> >  { PBTYPE_EMF, FLAVOR_EMF, "Windows Enhanced MetaFile",
> > CPPUTYPE_SEQINT8 },
> > + { PBTYPE_SVG, FLAVOR_SVG, "Scalable Vector Graphics",
> > CPPUTYPE_SEQINT8 },
> >  { PBTYPE_SODX, FLAVOR_SODX, "Star Object Descriptor (XML)",
> > CPPUTYPE_SEQINT8 },
> >   { PBTYPE_DUMMY_INTERNAL, FLAVOR_DUMMY_INTERNAL, "internal
> > data",CPPUTYPE_SEQINT8 }
> >};
> > ---snip---
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

MIME types for WMF/EMF

[Damjan Jovanovic]

Hi

While developing the patch for bug 112829, I saw that our clipboard formats
for WMF and EMF are
"application/x-openoffice-wmf;windows_formatname=\"Image WMF\"" and
"application/x-openoffice-emf;windows_formatname=\"Image EMF\"". This leads
to other applications being able to paste WMF and EMF from OpenOffice on
Windows, where the clipboard format is generated from the "Image WMF" or
"Image EMF" parameter, but being unable to paste on Linux/FreeBSD and
probably macOS, where the clipboard format is that whole unusual string.

In 2016, RFC 7093 (https://datatracker.ietf.org/doc/html/rfc7903)
standardized WMF and EMF as image/wmf and image/emf, and these appear on
IANA's list of official MIME types. Should we change our MIME types to
those? Ideally we would use the MIME types supported by other applications.
But at least "image/wmf" and "image/emf" have a chance of working on some
of them, while the application-specific "application/x-openoffice-wmf" and
""application/x-openoffice-emf" never will.

Should we change the MIME types to "image/wmf" and "image/emf"? We would
presumably also keep aliases like "image/x-wmf" and "image/x-emf". Inkscape
can paste "image/x-emf". Should we keep the existing MIME types as aliases
too, so we can copy and paste to and from LibreOffice?

Regards
Damjan

MacOS testing for bug 112829 (SVG clipboard format)

[Damjan Jovanovic]

Hi

For bug 112829, I got graphics and charts to copy out of AOO in SVG format
on FreeBSD and Windows (and probably Linux), but I wasn't able to test
macOS. A quick look at the code shows we might need another patch to get it
working there, possibly the one below.

Can someone please test it and report back? Don't only verify you can
paste, examine the clipboard formats after copying a chart, and make sure
it contains "image/svg+xml".

Thank you
Damjan

---snip---
diff --git a/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
b/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
index d5e2b6f371..d8f67c 100644
--- a/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
+++ b/main/vcl/aqua/source/dtrans/DataFlavorMapping.cxx
@@ -94,6 +94,7 @@ namespace // private
   const NSString* PBTYPE_GDIMF = @"application/x-openoffice-gdimetafile
;windows_formatname=\"GDIMetaFile\"";
   const NSString* PBTYPE_WMF =
@"application/x-openoffice-wmf;windows_formatname=\"Image
WMF\"";
   const NSString* PBTYPE_EMF =
@"application/x-openoffice-emf;windows_formatname=\"Image
EMF\"";
+  const NSString* PBTYPE_SVG = @"image/svg+xml;windows_
formatname=\"image/svg+xml\"";

   const NSString* PBTYPE_DUMMY_INTERNAL = @"application/x-openoffice-
internal";

@@ -107,6 +108,7 @@ namespace // private
   const char* FLAVOR_GDIMF = "application/x-openoffice-gdimetafile;windows_
formatname=\"GDIMetaFile\"";
   const char* FLAVOR_WMF =
"application/x-openoffice-wmf;windows_formatname=\"Image
WMF\"";
   const char* FLAVOR_EMF =
"application/x-openoffice-emf;windows_formatname=\"Image
EMF\"";
+  const char* FLAVOR_SVG = "image/svg+xml;windows_
formatname=\"image/svg+xml\"";

   const char* FLAVOR_DUMMY_INTERNAL = "application/x-openoffice-internal";

@@ -138,6 +140,7 @@ namespace // private
  { PBTYPE_GDIMF, FLAVOR_GDIMF, "GDIMetaFile", CPPUTYPE_SEQINT8 },
  { PBTYPE_WMF, FLAVOR_WMF, "Windows MetaFile", CPPUTYPE_SEQINT8 },
  { PBTYPE_EMF, FLAVOR_EMF, "Windows Enhanced MetaFile",
CPPUTYPE_SEQINT8 },
+ { PBTYPE_SVG, FLAVOR_SVG, "Scalable Vector Graphics",
CPPUTYPE_SEQINT8 },
  { PBTYPE_SODX, FLAVOR_SODX, "Star Object Descriptor (XML)",
CPPUTYPE_SEQINT8 },
   { PBTYPE_DUMMY_INTERNAL, FLAVOR_DUMMY_INTERNAL, "internal
data",CPPUTYPE_SEQINT8 }
};
---snip---

Re: [Issue 101010] Direct svg or eps export from calc

[Damjan Jovanovic]

Thank you everyone.

There are still a few further clipboard improvements I have planned, which
I'll elaborate on separately, but briefly:
- it might not work on macOS, and probably needs another patch.
- SVG can be copied out of OpenOffice, but cannot be pasted into OpenOffice
yet.
- Neither can we paste any other vector graphics format from Inkscape. We
might need to change our MIME types for WMF and EMF to image/wmf and
image/emf, also known as image/x-wmf and image/x-emf (which Inkscape uses).
- Only on Windows, can WMF and EMF be copied out of OpenOffice. On other
platforms it uses the wrong MIME types, application/x-openoffice-wmf and
application/x-openoffice-emf, which nothing else supports, so you can't
paste.
- Inkscape doesn't sort its clipboard formats in descending order of
quality (vector graphics formats before raster graphics formats), which is
a bug in Inkscape. But we should handle such buggy apps by looking for
vector graphics formats first, then falling back to raster formats if none
are found. At present PNG is offered before SVG, so we could paste the
worse format first!
- There are probably all kinds of other clipboard improvements I haven't
even thought of yet :-).

Oh and I really like the fact we only offer vector image formats for charts
and drawing on our clipboard at the moment. LO also offers image/png, which
can probably be pasted in a wider number of applications, but will waste
space, and be blurry when zoomed.

Damjan

On Thu, Feb 22, 2024 at 12:36 AM Marcus  wrote:

> I hope my commendation is not coming too late. ;-)
>
> I also think that this is a great extension of he clipboard formats.
> One reason more to work more on the way forward to AOO 4.2.0.
>
> Marcus
>
>
>
> Am 14.02.24 um 16:48 schrieb Dave Fisher:
> > CC to dev@ for exposure.
> >
> > I think that this fix is absolutely cool!
> >
> > Best,
> > Dave
> >
> >> On Feb 13, 2024, at 8:46 PM, bugzi...@apache.org wrote:
> >>
> >> https://bz.apache.org/ooo/show_bug.cgi?id=101010
> >>
> >> dam...@apache.org changed:
> >>
> >>What|Removed |Added
> >>
> 
> >>  CC||dam...@apache.org
> >>
> >> --- Comment #2 from dam...@apache.org ---
> >> With bug 112829 fixed, you can directly copy charts from Calc in SVG
> format,
> >> but you still need to paste and save them somewhere else.
> >>
> >> Is that an acceptable solution?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Problem With Open Office and Windows 11 /11 Pro.

[Damjan Jovanovic]

On Tue, Feb 13, 2024 at 3:12 PM Matthias Seidel 
wrote:

> Hi Francis, All,
>
> Am 12.02.24 um 17:00 schrieb F Campos Costero:
> > Hi Don,
> > There are several posts on the user forum about similar problems. For
> > example
> https://forum.openoffice.org/en/forum/viewtopic.php?p=536089#p536089
> > The suggested solution is:
> > " Windows 11 has a new Clipboard Manager - go to Start > Settings, Click
> > Clipboard on the System tab and turn off *Suggested Actions*; if that
> > doesn't help, try turning off *Clipboard History"*
> > Please let us know if that works.
>
> Yes, this seems to be a common problem on Windows, we have a lot of
> complaints in the Microsoft Store about Calc being unstable.
>
> @All: Anyone who has an idea how to fix this problem?
>
>
I think Firefox was also experiencing this and they fixed it:
https://support.mozilla.org/en-US/kb/firefox-hangs-when-copying-suggested-actions-windows-11

Unfortunately their bug report is very long:
https://bugzilla.mozilla.org/show_bug.cgi?id=1774285

Possibly this was the fix, which calls OleFlushClipboard() after setting
the clipboard contents:
https://phabricator.services.mozilla.com/D160646

Regards
Damjan

main/cosv and main/udm are now merged into main/autodoc

[Damjan Jovanovic]

Hi

2 small modules, main/cosv and main/udm, were found unused by the rest of
the build and have now been merged into main/autodoc, in trunk and AOO42X.

main/autodoc depends on main/cosv and main/udm.
main/udm depends on main/cosv.
No other module depends on main/cosv or main/udm.
The only deliverable from main/autodoc is the autodoc executable - there
are no libraries, and all headers remain private and undelivered.

We might even be able to use some third-party documentation generator
instead of autodoc, perhaps Doxygen. Whether we should go that way is
debatable, but there is no point in littering main/ with 2 modules and
littering solver/ with many headers and 2 static libraries just so autodoc
can consume them. They are also ancient modules with no value to new code.
Rather make their code internal to autodoc.

Buildable modules have now been reduced from 185 to 183.

Regards
Damjan

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

On Sat, May 28, 2022 at 7:20 AM Arrigo Marchiori 
wrote:

>
> Apparently, we are not. If we force CURLOPT_CAINFO and CURLOPT_CAPATH
> to be NULL, we get a bit further but eventually Curl aborts because
> validateServerX509Certificate fails.
>
>
Sorry to resurrect an old thread, but I think I now understand how this
crash happens.

So I always thought it was OpenSSL doing something wrong with the
certificates, but then in Curl's configure.ac, close to the end of the
file, there is the following:
---snip---
  ca cert bundle:   ${ca}${ca_warning}
  ca cert path: ${capath}${capath_warning}
  ca fallback:  ${with_ca_fallback}
---snip---

which apparently comes from:

---snip---
dnl **
dnl Check for the CA bundle
dnl **

if test -n "$check_for_ca_bundle"; then
  CURL_CHECK_CA_BUNDLE
fi
---snip---

and in Curl's acinclude.m4 we see that the CURL_CHECK_CA_BUNDLE function
uses a number of options, distro-specific search paths, etc.

This would also explain why system Curl always worked perfectly for me on
FreeBSD - the Port already built it with
--with-ca-bundle="${LOCALBASE}/share/certs/ca-root-nss.crt".

Now presumably things go wrong when Curl is using a bad path to the CA
bundle, because either it detected the path wrong during ./configure, or
it's running on a different distro.

So we should either build our Curl with the --without-ca-bundle
--without-ca-path --without-ca-fallback options, or disable use of those
settings at runtime. I prefer doing it at runtime, to be on the safe side.

I have a patch ready, but I am now unsure about other issues. If we are
going to use our own certificate validation instead of OpenSSL's, shouldn't
we use SSL_CTX_set_cert_verify_callback() which completely replaces
OpenSSL's verification, instead of  SSL_CTX_set_verify() which just allows
us to override its result on each certificate? Also what steps does OpenSSL
follow? We have a page on our Wiki (
https://wiki.openoffice.org/wiki/Certificate_Path_Validation) with proposed
certificate validation requirements, and also need to confirm what OpenSSL
does, and whether it does the more elaborate checks like connecting to OCSP
and CRL servers to verify revocation status. If not, we'd have to develop
that ourselves.

Regards
Damjan

Re: Aufnahme Referenzkundenliste

[Damjan Jovanovic]

Do they want this page updated:
http://www.openoffice.org/bizdev/consultants.html

How do we do that?

And let's keep it please.

Regards
Damjan

On Wed, Jan 31, 2024 at 4:26 PM Matthias Seidel 
wrote:

> Has anyone worked on this?
>
> Or should we remove this list at all?
>
> Regards,
>
>Matthias
> Am 14.11.23 um 19:16 schrieb Florian Dederichs:
>
> Hallo Apache Team,
>
>
>
> Wir würden gerne in die Referenzkundenliste aufgenommen werden
>
>
>
> Kunde: Operations & Consulting Munich GmbH
>
> Adresse: Baaderstrasse 27a, 80469 München
>
> Kontakt: Florian Dederichs
>
> Bemerkung: Wir benutzen seit unserer Gründung 2017 OpenOffice und sind
> extrem zufrieden was den Support und die Leistungen angeht. OpenOffice
> beweist dass Open Source Projekte Sinn haben. Homepage:
> https://www.ocmconsulting.de/
>
>
>
> Herzlichen Dank und weiter so!
>
>
>
> Florian Dederichs
>
>
>
> *[image: OCM_Logo_FD small]*
> 
>
> FLORIAN DEDERICHS
>
> GESCHÄFTSFÜHRER
>
> *M.*   +49 160 93882573
>
> *T.*   +49 89 23711368
>
> *E. *florian.dederi...@ocmconsulting.de
> *W.*   www.ocmconsulting.de
> 
>
>
>
>
>
> Operations & Consulting Munich GmbH | HRB 235494 Amtsgericht München |
> Sitz: München | Geschäftsführer: Florian Dederichs | USt-IdNr: DE313665900
>
>
>
>
>
> Diese Nachricht und alle Anlagen sind vertraulich und ausschließlich für
> den im Adressfeld genannten Adressaten bestimmt. Bitte informieren Sie uns,
> wenn Sie nicht der vorgesehene Empfänger sein sollten und löschen Sie diese
> Nachricht und alle Anlagen in Ihrem System. Jede unbefugte Nutzung,
> Weiterleitung, Veränderung, Offenlegung gegenüber Dritten oder Fertigung
> einer Kopie ist unzulässig. Da wir nicht die Echtheit oder Vollständigkeit
> der in dieser Nachricht enthaltenen Informationen garantieren können,
> schließen wir jede rechtliche Verbindlichkeit der vorstehenden Erklärungen
> und Äußerungen aus.
>
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. It is intended solely for the
> mentioned person in the address field. Please inform us, if you are not the
> intended recipient and delete the message and any attachment from your
> system. Any use, modification, unauthorised dissemination, distribution or
> copying hereof is prohibited. As we cannot guarantee the genuineness or
> completeness of the information in the message, the statements set forth
> above are not legally binding.
>
>
>
>

Re: ODF 1.3 ForceArray attribute?

[Damjan Jovanovic]

On Sat, Jan 27, 2024 at 5:02 PM Czesław Wolański  wrote:

> Hi Damjan,
>
> On 2024/01/23 16:42:52 Damjan Jovanovic wrote:
> > Hi
> >
> > Can someone please explain to me what the "ForceArray" attribute is
> > supposed to do?
> >
>
> Just my two cents. I'll be happy to be proven wrong.
>
> >
> > To quote from
> >
> https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part4-formula/OpenDocument-v1.3-os-part4-formula.html#__RefHeading__1017986_715980110
> >
> > ---snip---
> > 6.3.4 Force to array context (ForceArray)
> >
> > A ForceArray attribute forces calculation of the argument's expression
> into
> > non-scalar array mode. This means that no implied intersection is
> > performed, instead where a reference to a single cell is expected and
> > multiple cells are provided, iteration over the multiple cells is
> performed
> > and results are stored in an array that is passed on.
> > ---snip---
> >
> > In ODF 1.3, the HLOOKUP, LOGEST, LINEST, MATCH, and VLOOKUP functions are
> > adding ForceArray to some of their parameters.
> >
> > For example VLOOKUP, is supposed to change from ODF 1.2's:
> >
> > VLOOKUP( Any Lookup ; Reference|Array DataSource ; Integer Column [ ;
> > Logical RangeLookup = TRUE() ] )
> >
> > to ODF 1.3's:
> >
> > VLOOKUP( Any Lookup ; *ForceArray* Reference|Array DataSource ; Integer
> > Column [ ; Logical RangeLookup = TRUE() ] )
> >
> > Now yes, already the "Lookup" parameter can be an array, or a range of
> > cells, and if you enter it as an array formula, it will correctly
> populate
> > each cell with a VLOOKUP of each element.
> >
>
> That's right.
>
> >
> >And if you try to enter a column
> > label as the "Lookup", VLOOKUP will fail because it doesn't do "implied
> > intersection".
> >
>
> Please give an example of a non-functioning intersection.
> AFAICT it works as per specification
> (in short: return the value from the cell on the same row or column as the
> formula;
> otherwise, return an Error).
>
>
If you fill A1-A5 with:
Letters
a
b
c
d

then go to C3, and type =VLOOKUP('Letters', 'Letters', 1, 0)
you'll get an error.

If on another page or another spreadsheet you fill A1-A5 with:
Numbers
15
16
17
18

then go to C3 and type =VLOOKUP('Numbers', 'Numbers', 1, 0)
you'll get 16.

Why? Apparently because (at least in AOO) intersection only works correctly
for numerical values, not strings.
Even in C4 if you just do ='Numbers' you'll get 17, but if you do
='Letters' on the other page/spreadsheet's C4 you'll get a 0 instead of "c".
Is that a bug?


> >
> > So why is the ForceArray attribute on the "DataSource" parameter instead
> of
> > the "Lookup" parameter?
> >
> > Or is ForceArray supposed to do something else?
> >
>
> IMHO the ForceArray works as one could expect based on specification:
>
> "(..) no implied intersection is performed, instead where a reference to a
> single cell is expected and multiple cells are provided, iteration over the
> multiple cells is performed and results are
> stored in an array that is passed on."
>
> For example the formula with MODE:
>
> 6.18.50 MODE
> Syntax: MODE( { ForceArray NumberSequence N }+ )
>
> MODE(ABS(A1:A4)) - in normal mode - forces ABS(A1:A4) to be evaluated as
> an array formula.
> ABS() returns an array of the absolute values of A1:A4 from which MODE()
> selects
> the most common value to be returned.
>

Oh so "ForceArray" just changes how the nested function works, forcing eg.
ABS to work on each cell and return an array, instead of working on the
single cell obtained by automatic intersection and returning a single value.


>
> The .ods file available at the link below
>
> https://drive.google.com/file/d/1r0Q5Y1Di6blgirdbul4v-l3S3KEySh0U/view?usp=sharing
>
> contains a few more examples of "ForceArray" in action,
> including LOOKUP vs HLOOKUP / VLOOKUP.
> (The second parameter of the LOOKUP function, unlike HLOOKUP and VLOOKUP,
> is in ODF 1.2 declared as ForceArray).
> Examples with HLOOKUP and VLOOKUP return the #VALUE! error in AOO,
> but yield a value in LibreOffice releases that support ODF 1.3.
>
> I hope you find this useful.
>
>
Yes it's very helpful, thank you!


>
> Best regards,
>   Czesław
>
>
Regards
Damjan

ODF 1.3 ForceArray attribute?

[Damjan Jovanovic]

Hi

Can someone please explain to me what the "ForceArray" attribute is
supposed to do? To quote from
https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part4-formula/OpenDocument-v1.3-os-part4-formula.html#__RefHeading__1017986_715980110

---snip---
6.3.4 Force to array context (ForceArray)

A ForceArray attribute forces calculation of the argument's expression into
non-scalar array mode. This means that no implied intersection is
performed, instead where a reference to a single cell is expected and
multiple cells are provided, iteration over the multiple cells is performed
and results are stored in an array that is passed on.
---snip---

In ODF 1.3, the HLOOKUP, LOGEST, LINEST, MATCH, and VLOOKUP functions are
adding ForceArray to some of their parameters.

For example VLOOKUP, is supposed to change from ODF 1.2's:

VLOOKUP( Any Lookup ; Reference|Array DataSource ; Integer Column [ ;
Logical RangeLookup = TRUE() ] )

to ODF 1.3's:

VLOOKUP( Any Lookup ; *ForceArray* Reference|Array DataSource ; Integer
Column [ ; Logical RangeLookup = TRUE() ] )

Now yes, already the "Lookup" parameter can be an array, or a range of
cells, and if you enter it as an array formula, it will correctly populate
each cell with a VLOOKUP of each element. And if you try to enter a column
label as the "Lookup", VLOOKUP will fail because it doesn't do "implied
intersection".

So why is the ForceArray attribute on the "DataSource" parameter instead of
the "Lookup" parameter?

Or is ForceArray supposed to do something else?

Thank you
Damjan

Re: odf-1.3 branch pushed, progress update

[Damjan Jovanovic]

On Tue, Jan 16, 2024 at 7:10 PM Marcus  wrote:

> Am 16.01.24 um 17:50 schrieb Damjan Jovanovic:
> > I've now pushed my "odf-1.3" branch upstream, which has some initial ODF
> > 1.3 compatibility patches, a patch adding a new constraint for the
> RECEIVED
> > function, and another to only make the upgrade dialog appear when
> version >
> > 1.3.
> >
> > There are 3 useful parts to the ODF 1.3 specification, part 2 dealing
> with
> > packaging, part 3 with the OpenDocument schema, and part 4 with
> > OpenFormula. So far I've mostly been developing part 4. Of the 34 issues
> > under part 4, 20 are now complete, which means part 4 development is
> > already 59% complete.
>
> from zero to 59% in a few days. That's great.! :-)
>

:-)


> > Would anyone like to help?
>
> If you mean coding, then you have to teach me C++ first. ;-P
> Honestly, here I won't be of any help. Other things depend.
>

For my latest change, which added support for weekday types 11-17 to the
WEEKDAY function, those new types should probably be documented in the
"OpenOffice Help" page for WEEKDAY. Can someone update those?


>
> Before we bring this into a release, we should discuss and define how we
> want or should offer the ODF 1.3 support.
>
> My suggestion:
>
> Instead of putting this as a selectable option in the Save dialog, we
> should add this to the other ODF version parts (see menu "Tools -
> Options - Load/Save - General - Default file format and ODF settings").
>

Yes, I still need to add that.


> I don't know how loading is working. But I would expect that the header
> data is read and the ODF version is recognized with some magic numbers.
>

If you unzip an OpenDocument file, there are office:version="1.3"
attributes on at least content.xml, meta.xml, settings.xml, and styles.xml.

Damjan

odf-1.3 branch pushed, progress update

[Damjan Jovanovic]

Hi

I've now pushed my "odf-1.3" branch upstream, which has some initial ODF
1.3 compatibility patches, a patch adding a new constraint for the RECEIVED
function, and another to only make the upgrade dialog appear when version >
1.3.

There are 3 useful parts to the ODF 1.3 specification, part 2 dealing with
packaging, part 3 with the OpenDocument schema, and part 4 with
OpenFormula. So far I've mostly been developing part 4. Of the 34 issues
under part 4, 20 are now complete, which means part 4 development is
already 59% complete.

So far only 1 issue needed a code change, and at least 1 more also will,
but the impression I get is that the vast majority of changes were made not
because ODF 1.3 is hugely different from ODF 1.2, but because parts of ODF
1.2 were wrong or ambiguous and they wanted to fix the specification for
the sake of better interoperability with other implementations (probably
Microsoft Office). A lot of the design decisions seem to have been made in
favour of AOO/LO, standardizing on how we already work, leaving us with
little or nothing to change :-).

Of course there is still the lengthy ODF 1.3 part 3 to go through, and ODF
1.3 part 2 will also require some development to add OpenGPG encryption
support.

Ideally we should also add some unit tests for the new development, but I
am not yet sure how best to implement those.

Confluence has been working surprisingly well.

Would anyone like to help?

Regards
Damjan

Re: ODF 1.3 development

[Damjan Jovanovic]

On Fri, Jan 12, 2024 at 7:23 PM Marcus  wrote:

> Am 12.01.24 um 19:19 schrieb Marcus:
> > Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:
> >> [...]
> >>
> >> Can someone please create such a Wiki page, or give me access to do so?
> >>
> >> [...]
> >
> > that's a good idea. I'll create a new page in our Confluence Wiki.
>
> please have look here:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes
>
> You should have access to the page, so you can finish the first items
> yourself.
>
>
Thank you. I was hoping to use Mediawiki. I don't know why anyone uses
Confluence. It's terrible, bloated, slow, expensive, messy, proprietary and
closed source. The ASF is probably only getting it for free as a form of
marketing.

Anyway since so much was added to Confluence already, I've decided to
continue there, and have added the part 2 and part 4 tasks as well now, and
updated the items I already looked at.

Thank you
Damjan

Re: Can't create pages in the Wiki

[Damjan Jovanovic]

On Thu, Jan 11, 2024 at 12:27 PM Andrea Pescetti 
wrote:

> On 09/01/24 Damjan Jovanovic wrote:
> > I don't seem to have permission to create new pages in the Wiki (
> > wiki.openoffice.org).
> > Can someone please give me access?
>
> I've given additional permissions to user "Damjan"; you should now be
> able to create pages.
>
>
>
Thank you Andrea, it works now. You're the best!
Damjan

ODF 1.3 development

[Damjan Jovanovic]

Hi

I've started looking at how to add ODF 1.3 support to OpenOffice.

If you scroll to the end of the monstrously long part 3 of the ODF 1.3
specification at
https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html
where you'll see "Appendix G: Changes From ODF 1.2 (Non Normative)".
Then examine:

"Document Fields – General 7.3.1 Office-3783"

and you follow that link to "Office-3783" and have a read, you'll see that
all it does is *fix a typo*:
Section 7.3.1 used to contain "OpenDocument fields display information
about the current document or about a specific part of the current
document.," - note the superfluous comma at the end - and now ends without
that comma!

So that item can immediately be ticked off as completed, because there is
nothing we have to do.

The same is also true for at least:
"table:table-background 19.733 Office-3954"

And:
"Normative References 1.3 Office-3868"
updates the  tag to refer to RFC6838 instead of the
older RFC4288, which also might require no work to implement.

So what we need is a table in our Wiki, with all "Changes From ODF 1.2"
items from all the 1.3 documents (there's several), and then to read over
them and mark off the ones that are irrelevant or complete, and track
progress on the other items where we do have some development to do on our
side.

Can someone please create such a Wiki page, or give me access to do so?

And out of interest, how do you find how and where we use an XML element or
attribute? For example let's examine:
 10.4.7 Office-2044
which is deprecated by ODF 1.3.
First remember our XML parsing doesn't work on strings, that would be too
slow. Rather strings are converted to unique integers, and then we do fast
integer comparisons.
So if you go to main/xmloff and "grep applet * -R" you'll see:
source/core/xmltoken.cxx:TOKEN( "applet",
 XML_APPLET ),
where XML_APPLET is an integer constant (from an enum) that the "applet"
element will be converted to.
Then go to OpenGrok and do a "Full Search" for "XML_APPLET", and you can
see where that's used.

I've also created a local odf-1.3 Git branch for any development, but at
present it only has 1 small patch to stop the version upgrade warning:

---snip---
diff --git a/main/sfx2/source/doc/objstor.cxx
b/main/sfx2/source/doc/objstor.cxx
index d794747b60..89ab8e1ca3 100644
--- a/main/sfx2/source/doc/objstor.cxx
+++ b/main/sfx2/source/doc/objstor.cxx
@@ -856,8 +856,8 @@ sal_Bool SfxObjectShell::DoLoad( SfxMedium *pMed )
 if ( sVersion.getLength() )
 {
 double nVersion = sVersion.toDouble();
-if ( nVersion > 1.20001  &&
SfxObjectShell_Impl::NeedsOfficeUpdateDialog() )
-// ODF version greater than 1.2 - added some
decimal places to be safe against floating point conversion errors (hack)
+if ( nVersion > 1.30001  &&
SfxObjectShell_Impl::NeedsOfficeUpdateDialog() )
+// ODF version greater than 1.3 - added some
decimal places to be safe against floating point conversion errors (hack)
 {
 ::rtl::OUString sDocumentURL(
pMedium->GetOrigURL() );
 ::rtl::OUString aSystemFileURL;
---snip---

If others want to help, I'd rather push that branch upstream soon, so we
can work on it together?

Regards
Damjan

Can't create pages in the Wiki

[Damjan Jovanovic]

Hi

I don't seem to have permission to create new pages in the Wiki (
wiki.openoffice.org).

Can someone please give me access?

Thank you
Damjan (also my Wiki username)

Re: is it possible to build trunk with system OpenSSL?

[Damjan Jovanovic]

On Sun, Dec 10, 2023 at 8:25 AM Yury Tarasievich 
wrote:

> ...in followup to my previous post:
>
> So sources for xmlsec1 library which is used in
> the 'xmlsecurity' module are NOT downloaded when
> this condition (in external_deps.lst) is false?
>
> if (ENABLE_NSS_MODULE!=NO && SYSTEM_NSS!=YES)
>
> And I have both ENABLE_NSS_MODULE and SYSTEM_NSS
> set to YES after configuration.
>
> So can't I use the system libnss3 for my AOO
> build, or what?
>
> -Yury
>
>
libxmlsec uses NSS, or at least it does so in our case (it can use OpenSSL
instead).

I think that condition is wrong, SYSTEM_NSS shouldn't stop libxmlsec from
being downloaded.

-Damjan

Re: is it possible to build trunk with system OpenSSL?

[Damjan Jovanovic]

On Sat, Dec 9, 2023 at 6:56 AM Yury Tarasievich 
wrote:

> Hi,
>
> Thank you, Damjan, for the prompt looking into
> the problem.
>
>
It's a pleasure, let's try fix it so nobody else suffers.


> Regarding the matters you address:
>
> If I understand correctly, the configure code
> allows for a separate inclusion of nss (more on
> that at the very end of this message):
>
>--with-system-nss
>
> ...which brings us to the original issue.
>
> I've just rebuilt from start with
> --with-system-ssl and with --with-system-nss
>

It's --with-system-openssl, NOT --with-system-ssl.


> options, but for a while I couldn't even check
> if it actually worked.
>
> Because, when making the final target, i.e.
> instsetoo_native, the 'packaging' script in
> solenv/bin/make_installer.pl, which uses this list:
>
> ... analyzing script:
> /home/me/c/+ooo/aoo45/main/solver/450/unxlngx6.pro/bin/setup_osl.ins
>
> which is dated 2023-08-28 on my system and
> includes, e.g., this:
>
> File gid_File_Lib_Openssl
> Dir = gid_Brand_Dir_Program;
> Name = "libssl.so";
> Styles = (PACKED);
> UnixRights = 444;
> End
>
> ...fails (i.e. the 'packaging' script fails),
> saying this:
>
> ERROR: The following files could not be found:
> ERROR: File not found: libcrypto.so
> ERROR: File not found: libssl.so
>
> ...which obviously wouldn't even be there.
>
> Just for the kicks, I removed those two entries
> (on libcrypt and libssl) from setup_osl.ins (in
> solver, not touching its original in scp2/), and
> the packaging script completed successfully.
>
> Any idea how such things could be fixed? Should
> be fixed? Would be fixed?
>

In main/scp2/source/ooo/makefile.mk, we have this:

---snip---
# if yes or unset (neon not used) -> do not install openssl library!
.IF "$(SYSTEM_OPENSSL)" != "YES"
SCPDEFS+=-DOPENSSL
.ENDIF
---snip---

That determines whether "OPENSSL" is defined.

Then in main/scp2/source/ooo/file_library_ooo.scp we have:

---snip---
#ifdef OPENSSL
File gid_File_Lib_Openssl
TXT_FILE_BODY;
Styles = (PACKED);
Dir = SCP2_OOO_BIN_DIR;
  #ifdef WNT
Name = "ssleay32.dll";
  #else
Name = "libssl.so";
  #endif
End
#endif

#ifdef OPENSSL
File gid_File_Lib_Crypto
TXT_FILE_BODY;
Styles = (PACKED);
Dir = SCP2_OOO_BIN_DIR;
  #ifdef WNT
Name = "libeay32.dll";
  #else
Name = "libcrypto.so";
  #endif
End
#endif
---snip---

So it should look something like this:
1. If you passed --with-system-openssl to ./configure, then SYSTEM_OPENSSL
should be set, you can check that your config.log contains
SYSTEM_OPENSSL='YES'.
2. When you run "source LinuxX86_64.sh" (or whatever that file is) before
building, it populates SYSTEM_OPENSSL into your shell's environment
variables, so you can even run "echo $SYSTEM_OPENSSL" to check.
3. When scp2 is built, it uses the presence of that environment variable to
not populate the preprocessor's OPENSSL define, then since it's not defined
when building main/scp2/source/ooo/file_library_ooo.scp, it should skip
packaging those files.

If it is trying to package them and failing, like in your case, then it
went wrong in at least one of those steps. Please check?



> However, while 'Online Update - Check Now'
> stopped crashing the AOO (i.e. with system SSL
> loaded), the 'Macro Security' stil does nothing,
> so it seems just using --with-system-nss isn't
> enough.
>

Online Update shouldn't be crashing, thank you for reporting that.

Without --enable-category-b, you probably need both --enable-nss-module and
--with-system-nss, but I doubt even that will work. Unless category B is
enabled, all category B modules are apparently disabled, overwriting your
--enable-nss-module. You probably have to --enable-category-b
--with-system-nss --disable-hunspell --disable-hyphen --disable-saxon
--disable-javascript --disable-graphite --disable-coinmp
--disable-category-b-fonts.


> That brings us to the configure script
> functionality. I've heard before that w/r to at
> least category-b, there are to be NO changes. So
> I shouldn't expect the possibility of, like,
> including/enabling category-b stuff piecemeal?
>
> (For myself I'm using such piece-wise inclusion
> for years (as you could glean from my options)
> with no ill effects)
>

Where did you hear this?


>
>
> Thank you for your time anyway, again.
>
> -Yury
>
>
Pleasure Yury.
Damjan

Re: is it possible to build trunk with system OpenSSL?

[Damjan Jovanovic]

On Fri, Dec 8, 2023 at 7:40 AM Yury Tarasievich 
wrote:

> Hi,
>
> Thanks for answering. What fails in
>IMPL_LINK( SvxSecurityTabPage, MacroSecPBHdl,
> void*, EMPTYARG )
> is that check:
>if ( xD.is() )
> And the xD object is non-null at that.
>
> Somehow I can't set a breakpoint to that
> IMPL_LINK call. Neither variants with
> SvxSecurityTabPage:: nor name-mangled version
> taken out of object file work.
>
> I don't have a specific file with macros, it's
> my StarBasic macros that are failing to run from
> their keyboard shortcuts. Running those from
> 'Run macro' works (I changed MacroLevel in my
> registry to 0 by xml editor). If called by their
> keyboard shortcut, those macros show a msgbox
> with 'This document contains macros ...may
> contain viruses..'.
>
> My build options are now without system openssl,
> didn't retain the previous set. But IIRC, for
> the attempts with system openssl I had these
>--with-system-openssl=yes --with-system-curl=yes
>
> changed in the following options set:
>
>$ ./configure
> '--with-build-version=2023-12-04 22:37 - Linux
> x86_64' --enable-verbose --enable-crashdump=yes
> --enable-opengl --enable-dbus
> --with-package-format=installed
> --with-dmake-url=
> https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
> --with-epm-url=
> https://github.com/jimjag/epm/archive/v5.0.0/epm-5.0.0.tar.gz
> --without-junit --without-stlport --disable-kde
> --disable-kde4 --disable-randr-link
> --disable-gconf --disable-gnome-vfs
> --disable-gstreamer --with-ppds
> --disable-wiki-publisher --disable-category-b
> --disable-saxon --disable-pam --disable-odk
> --with-jdk-home=/usr/lib64/java
> --with-system-stdlibs --with-system-libs=yes
> --with-system-jars=no
> --disable-bundled-dictionaries --enable-hyphen
> --enable-hunspell --with-fonts
> --with-system-python=no --with-system-lucene=no
> --with-system-hsqldb=no
> --with-system-beanshell=no
> --with-system-redland=no --with-system-mythes=no
> --with-system-icu=no --with-system-openssl=no
> --with-system-curl=no --with-system-libxml=no
> --with-system-libxslt=no --with-system-expat=no
> --with-system-jpeg=no
>
>
The cause of your problem is "--disable-category-b". With this option, my
"Macro Security" button also does nothing. I think it's because NSS is
category B, and without it, we don't build xmlsecurity module which is
needed for the permissions to work properly.

OpenSSL has nothing to do with it. The xmlsecurity module uses only 2
providers at the moment, Microsoft's mscrypt on Windows, and Mozilla's NSS
library elsewhere. On Linux, without NSS, it cannot work at all, and isn't
even compiled from what I see.

We should consider developing an OpenSSL-based  xmlsecurity provider which
not be category B, and which would fetch certificates from eg. the system
certificates on Linux.

Damjan

Re: is it possible to build trunk with system OpenSSL?

[Damjan Jovanovic]

On Thu, Dec 7, 2023 at 6:53 AM Yury Tarasievich 
wrote:

> Hi all,
>
> Regarding the matter in the Subject, I've found
> I can just build with internal OpenSSL (which's
> rather old, btw), then rename libcrypto.so and
> libssl.so, and so actually use the system libraries.
>
> But as to why I needed that - it *looks* like at
> some point in the 4.5 branch development (maybe
> other branches, too, didn't check) macros got
> switched off in the program code somewhere
> -- and there's no standard means to turn them
> back on, because 'Macro Security' button
> (Options-OpenOffice-Security dialog) doesn't do
> anything.
>
> Which, in its turn, looks like it's caused by
>
> IMPL_LINK( SvxSecurityTabPage, MacroSecPBHdl,
> void*, EMPTYARG )
>
> in
>
> cui/source/options/optinet2.cxx
>
> failing to create that:
> Reference xD
>
> What might be causing that, any advice?
>
> NB: That button also fails to do anything in my
> 2 years old trunk build, but there macros are
> NOT disabled by the program code. I've checked
> that by starting the old and the new builds off
> my working configuration. In the new build some
> macros do not run, showing me a msgbox telling
> me about macros being disabled and pointing me
> to the mentioned dialog and button.
>
> -Yury
>
>
For me the build succeeds and works with --with-system-openssl, and opens
documents with macros.

Please share all your build options, and a sample document?

As for:
cui/source/options/optinet2.cxx
Reference< security::XDocumentDigitalSignatures > xD(
comphelper::getProcessServiceFactory()->createInstance(
rtl::OUString( RTL_CONSTASCII_USTRINGPARAM (
"com.sun.star.security.DocumentDigitalSignatures" ) ) ), UNO_QUERY );

that's implemented in
xmlsecurity/source/component/documentdigitalsignatures.cxx.

I need to know where it fails for you to debug further.

Damjan

Re: is it possible to build trunk with system OpenSSL?

[Damjan Jovanovic]

On Thu, Dec 7, 2023 at 6:52 PM Yury Tarasievich 
wrote:

> Hi,
>
> Yeah, the linux build. AFAIU the build process
> is a bit wilful, maybe it's fluking again.
>
>
I am pretty sure I've always used --with-system-openssl on FreeBSD
successfully, but I am retrying from a clean build now.

And it's --with-system-openssl or --without-system-openssl, there is no
--with-system-openssl=yes like you had.


> Anyway, I sort of went around the issue, but
> what about macros security button (see my
> neighbouring post)??
> What does it want, a new set of certificates, or
> what?
> I literally lose half of my macros (starbasic
> ones) when trying to use the fresh trunk build
>
>
That's new, I'll test when my build is finished. Your
cui/source/options/optinet2.cxx isn't likely to be the source of the
problem, as it was last changed in 2012.

Damjan

Re: (openoffice) branch trunk updated: The HTML tag ended with HTML 4, and newer versions of javadoc (Java 17's at least) support HTML 5 tags only. Use instead.

[Damjan Jovanovic]

I've now pushed commit 61a74f2854935294cdc5bceabf0de6a4347799ae which
changes that file to use  instead of , which should work far
better, as it's already used in other javadoc comments.

Regards
Damjan



On Sat, Nov 4, 2023 at 10:06 AM Matthias Seidel 
wrote:

> Hi All,
>
> Of course, I could disable building of the SDK to get builds of trunk
> again, but this does not solve the problem.
>
> What do we want to do?!
>
> Regards,
>
> Matthias
>
> Am 31.10.23 um 22:25 schrieb Matthias Seidel:
> > Hi Damjan,
> >
> > Am 29.10.23 um 16:44 schrieb dam...@apache.org:
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> damjan pushed a commit to branch trunk
> >> in repository https://gitbox.apache.org/repos/asf/openoffice.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/trunk by this push:
> >>   new 872b251390 The  HTML tag ended with HTML 4, and newer
> >> versions of javadoc (Java 17's at least) support HTML 5 tags only.
> >> Use  instead.
> >
> > This seems to break our buildbot (with Java 8) in module ODK:
> >
> > https://ci2.apache.org/#/builders/58/builds/689
> >
> > Regards,
> >
> >Matthias
> >
> >> 872b251390 is described below
> >>
> >> commit 872b2513907e4389be70e2d9b563f47e0d2c5a9f
> >> Author: Damjan Jovanovic 
> >> AuthorDate: Sun Oct 29 17:42:38 2023 +0200
> >>
> >>  The  HTML tag ended with HTML 4, and newer versions of javadoc
> >>  (Java 17's at least) support HTML 5 tags only. Use  instead.
> >>   Patch by: me
> >> ---
> >>   .../star/lib/uno/helper/InterfaceContainer.java| 46
> >> +++---
> >>   1 file changed, 23 insertions(+), 23 deletions(-)
> >>
> >> diff --git
> >>
> a/main/javaunohelper/com/sun/star/lib/uno/helper/InterfaceContainer.java
> >> b/main/javaunohelper/com/sun/star/lib/uno/helper/InterfaceContainer.java
> >> index 1fe5cb..9f362fb013 100644
> >> ---
> >> a/main/javaunohelper/com/sun/star/lib/uno/helper/InterfaceContainer.java
> >> +++
> >> b/main/javaunohelper/com/sun/star/lib/uno/helper/InterfaceContainer.java
> >> @@ -127,9 +127,9 @@ public class InterfaceContainer implements Cloneable
> >>   }
> >> /**
> >> - * Trims the capacity of this ArrayList instance to be the
> >> + * Trims the capacity of this ArrayList instance to
> >> be the
> >>* list's current size.  An application can use this operation
> >> to minimize
> >> - * the storage of an ArrayList instance.
> >> + * the storage of an ArrayList instance.
> >>*/
> >>   synchronized public void trimToSize()
> >>   {
> >> @@ -143,7 +143,7 @@ public class InterfaceContainer implements Cloneable
> >>   }
> >> /**
> >> - * Increases the capacity of this ArrayList instance, if
> >> + * Increases the capacity of this ArrayList instance, if
> >>* necessary, to ensure  that it can hold at least the number
> >> of elements
> >>* specified by the minimum capacity argument.
> >>*
> >> @@ -167,7 +167,7 @@ public class InterfaceContainer implements Cloneable
> >>* Appends the specified element to the end of this list.
> >>*
> >>* @param o element to be appended to this list.
> >> - * @return true (as per the general contract of
> >> Collection.add).
> >> + * @return true (as per the general contract of
> >> Collection.add).
> >>*/
> >>   synchronized public boolean add(Object o)
> >>   {
> >> @@ -189,7 +189,7 @@ public class InterfaceContainer implements Cloneable
> >>* @param index index at which the specified element is to be
> >> inserted.
> >>* @param element element to be inserted.
> >>* @throwsIndexOutOfBoundsException if index is out of range
> >> - *  (index  0 || index  size()).
> >> + *  (index  0 || index  size()).
> >>*/
> >>   synchronized public void add(int index, Object element)
> >>   {
> >> @@ -218,8 +218,8 @@ public class InterfaceContainer implements Cloneable
> >>* list is nonempty.)
> >>*
> >>* @param c the elements to be inserted into this list.
> >> - *

Re: Ugly UI [Was: "Roadmap"]

[Damjan Jovanovic]

On Fri, Oct 6, 2023 at 10:57 AM Pedro Lino 
wrote:

> Hi Arrigo, all
>
> This does solve the UI problem.
>
> Does it mean we need to include this library in the installer?
>
>
The licence is LGPL-2+, so we can't ship it, right?

Regards
Damjan

Binaries for old A00420/AOO450 Windows versions?

[Damjan Jovanovic]

Hi

Do we have very old versions of the Windows binaries for AOO420/AOO450
somewhere, for use in bisection testing? Like from 2014-2018?

Thank you
Damjan

Re: "Roadmap"

[Damjan Jovanovic]

On Thu, Oct 5, 2023 at 9:49 PM Matthias Seidel 
wrote:

> Am 05.10.23 um 23:25 schrieb Matthias Seidel:
> > Hi Marcus,
> >
> > Am 05.10.23 um 23:17 schrieb Marcus:
> >> Am 05.10.23 um 21:25 schrieb Matthias Seidel:
> >>> Am 05.10.23 um 21:06 schrieb Marcus:
>  Am 05.10.23 um 15:23 schrieb Matthias Seidel:
> > I would like to collect ideas for some kind of roadmap for AOO:
> >
> >   - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in
> > good condition, but personally I would like to have the "ugly UI"
> > fixed on some Linux distribution.
> 
>  I've no discussions about this in mind. Do you have the BZ issue(s)
>  at hand?
> >>>
> >>> No, I think it was discussed on a user list but more or less ignored.
> >>>
> >>> I only recently moved from Ubuntu 16.04 to 22.04 and discovered the
> >>> "ugly UI". But everyone using a newer distribution with Gnome should
> >>> probably see it.
> >>
> >> I've Fedora 36 with Gnome 43.1.
> >> How / where can I see what you mean?
>
> Found a screenshot...
>
> https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png
>
> Matthias
>
>
Actually as per main/vcl/unx/generic/desktopdetect/desktopdetector.cxx:
Try setting the OOO_FORCE_DESKTOP environment variable to "gnome", eg.
OOO_FORCE_DESKTOP=gnome ./soffice
Also, what does this return:
$ echo $GNOME_DESKTOP_SESSION_ID
and does this:
$ xprop -root
return a value for GNOME_SM_PROXY or NAUTILUS_DESKTOP_WINDOW_ID?

Re: "Roadmap"

[Damjan Jovanovic]

On Thu, Oct 5, 2023 at 9:49 PM Matthias Seidel 
wrote:

> Am 05.10.23 um 23:25 schrieb Matthias Seidel:
> > Hi Marcus,
> >
> > Am 05.10.23 um 23:17 schrieb Marcus:
> >> Am 05.10.23 um 21:25 schrieb Matthias Seidel:
> >>> Am 05.10.23 um 21:06 schrieb Marcus:
>  Am 05.10.23 um 15:23 schrieb Matthias Seidel:
> > I would like to collect ideas for some kind of roadmap for AOO:
> >
> >   - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in
> > good condition, but personally I would like to have the "ugly UI"
> > fixed on some Linux distribution.
> 
>  I've no discussions about this in mind. Do you have the BZ issue(s)
>  at hand?
> >>>
> >>> No, I think it was discussed on a user list but more or less ignored.
> >>>
> >>> I only recently moved from Ubuntu 16.04 to 22.04 and discovered the
> >>> "ugly UI". But everyone using a newer distribution with Gnome should
> >>> probably see it.
> >>
> >> I've Fedora 36 with Gnome 43.1.
> >> How / where can I see what you mean?
>
> Found a screenshot...
>
> https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png
>
>
Ubuntu 22.04 and Fedora 36 both use Wayland, which may be breaking our GTK+
v2 backend somehow and falling back to the "generic" UI.

A debug build should log relevant info to stdout, if you start it from the
command line.

Re: "Roadmap"

[Damjan Jovanovic]

On Thu, Oct 5, 2023 at 1:24 PM Matthias Seidel 
wrote:

> Hi All,
>
> I would like to collect ideas for some kind of roadmap for AOO:
>
>   - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good
> condition, but personally I would like to have the "ugly UI" fixed on
> some Linux distribution.
>
>   - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already
> fixed two with one commit) with a release date 2024 in mind.
> Maybe we could release AOO420-dev5 to the public in early 2024?
>
>
Unfortunately I found a new regression we'll have to fix for 4.2.0:
https://bz.apache.org/ooo/show_bug.cgi?id=128579

Regards
Damjan

Re: 4.2.0 release blockers

[Damjan Jovanovic]

On Wed, Oct 4, 2023 at 4:52 PM Jim Jagielski  wrote:

>
>
> > On Oct 1, 2023, at 7:44 AM, Damjan Jovanovic  wrote:
> >
> > 127154 and 127966 need to be looked at by a Mac developer.
> >
>
> Those look pretty old. I should create a quick macOS 4.2.0 dev build for
> testing
>
>
Thank you Jim. While you are here, can you please look at bug
https://bz.apache.org/ooo/show_bug.cgi?id=127861 where one of your commits
created a regression?

Regards
Damjan

4.2.0 release blockers

[Damjan Jovanovic]

Hi

So for 4.2.0, presumably we need to fix the bugs with 4.2.0_release_blocker
flags:
https://bz.apache.org/ooo/buglist.cgi?f1=flagtypes.name_id=251353=substring_format=advanced=---=4.2.0_release_blocker
of which there is 6:

For 127731, I found the problem yesterday (Microsoft's damned side-by-side
assemblies), and am building AOO with my fix now, if all goes well it
should be committed later today or tomorrow.
127783 needs testing on several platforms to isolate the bug, now that
Arrigo's ppt branch was merged.
127861 will probably need bisecting.
128094 is probably a packaging bug and needs testing and might need
bisecting.
127154 and 127966 need to be looked at by a Mac developer.

Regards
Damjan

Re: Flat ODF

[Damjan Jovanovic]

On Mon, Jun 12, 2023 at 5:05 PM Matthias Seidel 
wrote:

> Hi All,
>
> What do you think about these filters:
>
> https://forum.openoffice.org/en/forum/viewtopic.php?f=47=44216
>
> Would it be possible to add Flat ODF to AOO?
>
> While I can import and use them in my Windows build the import crashes
> on every GNOME based Linux I tried.
>
> But it works e.g. in Xubuntu. So there is another Linux bug to be fixed...
>
> Regards,
>
>Matthias
>
>
>
>
The flat XML file form of ODF is something discussed in this bug report:
https://bz.apache.org/ooo/show_bug.cgi?id=126270

This is possibly relevant too:
https://bz.apache.org/ooo/show_bug.cgi?id=62475

Regards
Damjan

Re: Buildbot config - svn or git?

[Damjan Jovanovic]

On Thu, Jun 15, 2023 at 8:30 AM Matthias Seidel 
wrote:

> Hi All,
>
> bumping this up again.
>
> Thanks to Peter our Linux buildbots are functional again.
>
> But the buildbot configuration is still on SVN.
>
> I would prefer it on Git. Opinions?
>
> Regards,
>
>Matthias
>
>
Git, absolutely.

Regards
Damjan

Re: Buildbot problems

[Damjan Jovanovic]

Unfortunately that's not our only problem.

Even before the MozillaBuild update, every "build --all" got "cancelled"
after about 37 minutes. For example see
https://ci2.apache.org/#/builders/67/builds/628

Regards
Damjan

On Sun, Mar 5, 2023 at 10:16 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Thank you for all the work on the buildbots!
>
> Looking at the Windows bot now:
>
> checking whether to build LDAP configuration backend... checking whether to 
> build the internal NSS module... yes
> configure: error: Mozilla build tooling incomplete!
>
> It seems like MozillaBuild was updated to 4.x, which we do not support yet.
>
> Regards,
>
>Matthias
>
> Am 02.03.23 um 05:46 schrieb Damjan Jovanovic:
>
> On Sun, Jan 22, 2023 at 1:33 PM Matthias Seidel  
> 
> wrote:
>
>
> Now regarding Awk, instead of doing:
> rm /bin/awk
> mv /bin/gawk.exe /bin/awk.exe
> can't we prepend PATH with a directory containing an "awk" script that
>
> just
>
> calls gawk.exe?
>
> It would be great if there is a better way to do it. I just followed our
> Windows building guide all these years.
>
> But this is beyond my capabilities and one of the reasons why I cannot
> maintain our buildbots anymore.
>
>
> This approach did eventually work. I eventually succeeded in creating an
> "awk" script that calls "gawk" and setting PATH to its directory within
> Cygwin, and ./configure now gets further.
>
> Now the next problem is that Cygwin doesn't have gcc and g++ 
> (https://ci2.apache.org/#/builders/67/builds/516/steps/9/logs/stdio):
>
> which: no gcc in
>
>
> (/cygdrive/e/buildbot/openoffice-win10/utils:/usr/local/bin:/usr/bin:/cygdrive/e/Python39/Scripts:/cygdrive/e/Python39:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Windows/System32/OpenSSH:/cygdrive/c/Program
>
> Files/Puppet Labs/Puppet/bin:/cygdrive/c/Program Files
> (x86)/Subversion/bin:/cygdrive/c/Program
> Files/Git/cmd:/cygdrive/e/buildbot/tools/Windows Kits/10/Windows
> Performance
> Toolkit:/cygdrive/c/Users/buildbot/AppData/Local/Microsoft/WindowsApps)
> configure: error: cygwin gcc and g++ are needed, please install them.
>
> How can we install them?
>
> That's an Infra job. ;-)
>
>
>
> Weeks ago, on the openoffice-win10 buildbot, many Cygwin dependencies
> somehow got deleted, and days of battling Buildbot and working with Infra
> on https://issues.apache.org/jira/browse/INFRA-24114 were needed to install
> them again.
>
> The git crlf problem on Cygwin was another major issue that needed fixing.
>
> Awk was another, my idea for an "awk" script that calls gawk didn't work, I
> ended up copying /usr/bin/gawk.exe to awk.exe in a directory that is then
> prepended to the PATH environment variable passed to "configure" and
> "build", which worked in my own build and should work on the buildbot too.
> Since this copies gawk on every build, this approach won't be broken by
> future Cygwin upgrades like our previous renaming of gawk to awk by Infra
> was.
>
> I also changed haltOnFailure to False for the "build" step, so that the
> logs are uploaded even when the build fails, like the Linux buildbots do.
> Haven't checked whether that works yet.
>
> It eventually got through configure and started building, but every time
> that happened, the build was cancelled somehow.
>
> Then Java 8 changed somehow (upgrade or whatever), and Java detection
> broke. That has taken several more weeks to fix, and a command I was trying
> to run to log Java's files wasn't working due to a missing bracket which I
> eventually found and fixed.
>
> A further Java problem is that oowintool fails to detect Java, as it's
> looking for the 32 bit Java registry key, while we only have a 64 bit Java
> installed. I had to dig through the buildbot script's history to find a
> working 32 bit Java directory to specify (which oowintool can't detect
> because it's just unzipped, not installed and added to the registry).
>
> With those endless problems fixed, the build is now progressing 
> nicely:https://ci2.apache.org/#/builders/67/builds/625
>
>
> Regards,
>
>Matthias
>
>
>
> Regards
> Damjan
>
>
>

Re: Buildbot problems

[Damjan Jovanovic]

On Sun, Jan 22, 2023 at 1:33 PM Matthias Seidel 
wrote:

>
> >
> >
> >>> Now regarding Awk, instead of doing:
> >>> rm /bin/awk
> >>> mv /bin/gawk.exe /bin/awk.exe
> >>> can't we prepend PATH with a directory containing an "awk" script that
> >> just
> >>> calls gawk.exe?
> >> It would be great if there is a better way to do it. I just followed our
> >> Windows building guide all these years.
> >>
> >> But this is beyond my capabilities and one of the reasons why I cannot
> >> maintain our buildbots anymore.
> >>
> > This approach did eventually work. I eventually succeeded in creating an
> > "awk" script that calls "gawk" and setting PATH to its directory within
> > Cygwin, and ./configure now gets further.
> >
> > Now the next problem is that Cygwin doesn't have gcc and g++ (
> > https://ci2.apache.org/#/builders/67/builds/516/steps/9/logs/stdio):
> >
> > which: no gcc in
> >
> (/cygdrive/e/buildbot/openoffice-win10/utils:/usr/local/bin:/usr/bin:/cygdrive/e/Python39/Scripts:/cygdrive/e/Python39:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Windows/System32/OpenSSH:/cygdrive/c/Program
> > Files/Puppet Labs/Puppet/bin:/cygdrive/c/Program Files
> > (x86)/Subversion/bin:/cygdrive/c/Program
> > Files/Git/cmd:/cygdrive/e/buildbot/tools/Windows Kits/10/Windows
> > Performance
> > Toolkit:/cygdrive/c/Users/buildbot/AppData/Local/Microsoft/WindowsApps)
> > configure: error: cygwin gcc and g++ are needed, please install them.
> >
> > How can we install them?
>
> That's an Infra job. ;-)
>
>

Weeks ago, on the openoffice-win10 buildbot, many Cygwin dependencies
somehow got deleted, and days of battling Buildbot and working with Infra
on https://issues.apache.org/jira/browse/INFRA-24114 were needed to install
them again.

The git crlf problem on Cygwin was another major issue that needed fixing.

Awk was another, my idea for an "awk" script that calls gawk didn't work, I
ended up copying /usr/bin/gawk.exe to awk.exe in a directory that is then
prepended to the PATH environment variable passed to "configure" and
"build", which worked in my own build and should work on the buildbot too.
Since this copies gawk on every build, this approach won't be broken by
future Cygwin upgrades like our previous renaming of gawk to awk by Infra
was.

I also changed haltOnFailure to False for the "build" step, so that the
logs are uploaded even when the build fails, like the Linux buildbots do.
Haven't checked whether that works yet.

It eventually got through configure and started building, but every time
that happened, the build was cancelled somehow.

Then Java 8 changed somehow (upgrade or whatever), and Java detection
broke. That has taken several more weeks to fix, and a command I was trying
to run to log Java's files wasn't working due to a missing bracket which I
eventually found and fixed.

A further Java problem is that oowintool fails to detect Java, as it's
looking for the 32 bit Java registry key, while we only have a 64 bit Java
installed. I had to dig through the buildbot script's history to find a
working 32 bit Java directory to specify (which oowintool can't detect
because it's just unzipped, not installed and added to the registry).

With those endless problems fixed, the build is now progressing nicely:
https://ci2.apache.org/#/builders/67/builds/625


Regards,
>
>Matthias
>
>
Regards
Damjan

Re: User Installation Process Feedback

[Damjan Jovanovic]

On Wed, Feb 15, 2023 at 2:52 PM  wrote:

> Hello GB Mac,
>
> Le 2023-02-15 06:36, GB Mac a écrit :
> > OpenOffice remains a perpetual
> > developer project in Linux.
> It's a problem to do with your Linux distribution (which you don't
> specify).
> See with them so that the DEB or RPM package is set online in their
> repositories.
>
>
Both the technical and political reality of software installation on Linux,
is that Linux distribution repositories never could have been, and never
will be, the one and only source of software to install. Repositories
legally cannot package commercial software for example, and as the (now
obsolete) Autopackage project quite correctly noticed around 2005, and its
founder Mike Hearn gave a talk about to Gentoo developers at some
conference in those days, the Linux distributions' repository has a
monopoly on easy software installation, which distributions use as a
political weapon against software that they don't like, whether it isn't
UNIX-y enough, or has a strange licence, or isn't popular enough, or they
just don't like for some personal reason.

And there is trouble in paradise even for packages that make it into a
distro repository. Distributions often ship old versions, and update on an
awkward schedule. Inkscape used to have a release schedule where new
releases would come out shortly after Ubuntu releases. As a result they had
to deal with endless duplicate bug reports, from Ubuntu users installing
the old version, and reporting bugs that were already fixed, but with no
easy way to install the new version. Eventually Inkscape changed its
release schedule to allow Ubuntu to package its latest version, but you can
see the problem with this: should tens of thousands of packages really be
forced to release in lock-step with Ubuntu?

So the problem of 3rd party software installation has plagued Linux since
inception: I documented 8 projects that tried to achieve that and compared
them in the attached spreadsheet, and there are more. In bug 46333 users
wanted an Autopackage of OpenOffice.

Luckily in recent years the Linux distributions seem to have finally woken
up, and begun officially supporting installation of 3rd party software,
Ubuntu with Snap, and Red Hat with Flatpak.

LibreOffice already offers Snap, Flatpak and AppImage, although I've found
them to be of poor quality.

Flatpak can work on Ubuntu too. AppImage isn't sandboxed at all. Snap is a
disaster and will probably fail like most Canonical technologies.

I definitely think Flatpak is the way to go. However it will require some
development. We don't (only) use the standard GTK file dialogs, which
automatically go through a "Portal" to allow us out of the sandbox, so we
have to use the Portal API to gain permission to read the selected document
somehow.

Regards
Damjan


3rd party software installation.ods
Description: application/vnd.oasis.opendocument.spreadsheet

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Pull Request 164

[Damjan Jovanovic]

It's in AOO42X too now.

Damjan

On Sun, Feb 12, 2023 at 3:10 PM Damjan Jovanovic  wrote:

> Hi
>
> I've now merged it.
>
> Should we also cherry-pick it into AOO42X? I am currently testing it there.
>
> Regards
> Damjan
>
> On Sat, Feb 11, 2023 at 1:14 PM Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
>
>> So at least 3 people are interested in this big enhancement...
>>
>> @Damjan: I would say, merge it! We need to move forward.
>>
>> Regards,
>>
>>Matthias
>>
>> Am 10.02.23 um 17:00 schrieb Matthias Seidel:
>> > Hi Carl,
>> >
>> > Am 07.02.23 um 15:10 schrieb Carl Marcum:
>> >> Hi All,
>> >>
>> >> On 2/7/23 5:46 AM, Matthias Seidel wrote:
>> >>> Hi all,
>> >>>
>> >>> PR #164 [1] is a huge one.
>> >>>
>> >>> It would be great if there was additional feedback...
>> >>>
>> >>> Regards,
>> >>>
>> >>> Matthias
>> >>>
>> >>> [1] https://github.com/apache/openoffice/pull/164
>> >>>
>> >>>
>> >> A good test for this is to open this test file [1] in a browser and
>> >> copy/paste into calc.
>> >>
>> >> You should get all 20,000 rows.
>> > Did that and it works. Great!
>> >
>> > Regards,
>> >
>> >Matthias
>> >
>> >> [1]
>> https://home.apache.org/~cmarcum/test-files/2-row-html-table.html
>> >>
>> >> Best regards,
>> >> Carl
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >>
>>
>>

Re: Pull Request 164

[Damjan Jovanovic]

Hi

I've now merged it.

Should we also cherry-pick it into AOO42X? I am currently testing it there.

Regards
Damjan

On Sat, Feb 11, 2023 at 1:14 PM Matthias Seidel 
wrote:

> So at least 3 people are interested in this big enhancement...
>
> @Damjan: I would say, merge it! We need to move forward.
>
> Regards,
>
>Matthias
>
> Am 10.02.23 um 17:00 schrieb Matthias Seidel:
> > Hi Carl,
> >
> > Am 07.02.23 um 15:10 schrieb Carl Marcum:
> >> Hi All,
> >>
> >> On 2/7/23 5:46 AM, Matthias Seidel wrote:
> >>> Hi all,
> >>>
> >>> PR #164 [1] is a huge one.
> >>>
> >>> It would be great if there was additional feedback...
> >>>
> >>> Regards,
> >>>
> >>> Matthias
> >>>
> >>> [1] https://github.com/apache/openoffice/pull/164
> >>>
> >>>
> >> A good test for this is to open this test file [1] in a browser and
> >> copy/paste into calc.
> >>
> >> You should get all 20,000 rows.
> > Did that and it works. Great!
> >
> > Regards,
> >
> >Matthias
> >
> >> [1]
> https://home.apache.org/~cmarcum/test-files/2-row-html-table.html
> >>
> >> Best regards,
> >> Carl
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
>
>

Re: AOO 4.1.14

[Damjan Jovanovic]

On Tue, Feb 7, 2023 at 4:09 PM Matthias Seidel 
wrote:

> Hi Carl,
>
> Am 07.02.23 um 14:52 schrieb Carl Marcum:
> > Hi All,
> >
> > On 2/7/23 4:48 AM, Matthias Seidel wrote:
> >> Hi all,
> >>
> >> I think it is time for the next release.
> >>
> >> I have created the Release Schedule [1] for AOO 4.1.14 now. Please join!
> >>
> >> Regards,
> >>
> >>  Matthias
> >>
> >> [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.14
> >>
> >>
> > I volunteered for QA and announcements.
>
> Thanks!
>
> After all the time avoiding it I am now Corona positive...
>
>
Take care and get better soon Matthias.

Re: Nightly Builds

[Damjan Jovanovic]

On Sat, Jan 21, 2023 at 3:14 PM Matthias Seidel 
wrote:

>
> Four weeks are a good period to have archived if a regression occurs.
>
>
No. For old regressions, or to discover old fixes, we ideally want a build
from every month in AOO's history.

Re: 41X fails to build in Ubuntu 18.04 (was Re: Fails to build on Pop!_OS 18.04)

[Damjan Jovanovic]

On Tue, Jan 24, 2023 at 7:21 PM Pedro Lino 
wrote:

> Hi Damjan
>
> > On 01/24/2023 1:23 AM WET Damjan Jovanovic  wrote:
>
> > In your --with-jdk-home directory, do you have these files:
> >
> > include/jawt.h
> > include/linux/jawt_md.h
>
> No, those 2 files are not there. Maybe it is not included in build 352 of
> Java 8?
>
>
Can you please run:
find /usr/lib/jvm/java-8-openjdk-amd64 | grep jawt


> > And what is your SOLARINC environment variable set to? After "source
> > LinuxX86-64Env.Set.sh", run "echo $SOLARINC" and post the results. It
> > should contain the directory that the above include/linux/jawt_md.h is
> in.
>
> It does contain the directory -I/usr/lib/jvm/java-8-openjdk-amd64/include
>
>
Let's see all of it, eg. is
-I/usr/lib/jvm/java-8-openjdk-amd64/include/linux there?


> > SOLARINC is set within set_soenv.in, and might need adjustment for
> Pop!_OS.
> > It depends on what config.guess gave, so it would also help to see the
> > output of ./config.guess (under main/)
>
> x86_64-unknown-linux-gnu
>
> Maybe the solution is to install a previous version of Java 8?
>
>
Unlikely, we even support Java 9.


> Thanks!
> Pedro
>
>
Damjan

Re: Fails to build on Pop!_OS 18.04

[Damjan Jovanovic]

On Mon, Jan 23, 2023 at 11:48 PM Pedro Lino 
wrote:

> Hi Peter, all
>
> > On 01/23/2023 11:33 AM WET Peter Kovacs  wrote:
>
> > yes, but it looks on disk like the following?
> >
> > ls /usr/lib/jvm/java-8-openjdk-amd64
> > ASSEMBLY_EXCEPTION  bin  docs  include  jre  lib  man  src.zip
> > THIRD_PARTY_README
>
> Yes
> ls /usr/lib/jvm/java-8-openjdk-amd64
> ASSEMBLY_EXCEPTION  docs jre  man  THIRD_PARTY_README
> bin include  lib  src.zip
>
> Any ideas?
>
>
In your --with-jdk-home directory, do you have these files:

include/jawt.h
include/linux/jawt_md.h

And what is your SOLARINC environment variable set to? After "source
LinuxX86-64Env.Set.sh", run "echo $SOLARINC" and post the results. It
should contain the directory that the above include/linux/jawt_md.h is in.

SOLARINC is set within set_soenv.in, and might need adjustment for Pop!_OS.
It depends on what config.guess gave, so it would also help to see the
output of ./config.guess (under main/).

Re: Buildbot problems

[Damjan Jovanovic]

On Wed, Jan 18, 2023 at 8:26 PM Matthias Seidel 
wrote:

> Hi,
>
> Am 16.01.23 um 03:47 schrieb Damjan Jovanovic:
> > Hi
> >
> > That's progress, because if you compare it to the previous build's
> > ./configure:
> > https://ci2.apache.org/#/builders/67/builds/509/steps/8/logs/stdio
> > it no longer stops on the error:
> > "configure: error: cannot run /bin/sh ./config.sub",
> > we got further to reach the awk error.
> >
> > So the automatic changing of line endings by git really was a problem,
> and:
> > git clone -c core.autocrlf=false ...
> > really did fix it :-).
>
> Yes, it looks better!
>
> Is this a native Windows git or the one inside Cygwin?
>

It's called from within Cygwin, but it could be the Windows one, I am not
sure.


>
> >
> > Now regarding Awk, instead of doing:
> > rm /bin/awk
> > mv /bin/gawk.exe /bin/awk.exe
> > can't we prepend PATH with a directory containing an "awk" script that
> just
> > calls gawk.exe?
>
> It would be great if there is a better way to do it. I just followed our
> Windows building guide all these years.
>
> But this is beyond my capabilities and one of the reasons why I cannot
> maintain our buildbots anymore.
>

This approach did eventually work. I eventually succeeded in creating an
"awk" script that calls "gawk" and setting PATH to its directory within
Cygwin, and ./configure now gets further.

Now the next problem is that Cygwin doesn't have gcc and g++ (
https://ci2.apache.org/#/builders/67/builds/516/steps/9/logs/stdio):

which: no gcc in
(/cygdrive/e/buildbot/openoffice-win10/utils:/usr/local/bin:/usr/bin:/cygdrive/e/Python39/Scripts:/cygdrive/e/Python39:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Windows/System32/OpenSSH:/cygdrive/c/Program
Files/Puppet Labs/Puppet/bin:/cygdrive/c/Program Files
(x86)/Subversion/bin:/cygdrive/c/Program
Files/Git/cmd:/cygdrive/e/buildbot/tools/Windows Kits/10/Windows
Performance
Toolkit:/cygdrive/c/Users/buildbot/AppData/Local/Microsoft/WindowsApps)
configure: error: cygwin gcc and g++ are needed, please install them.

How can we install them?


> Regards,
>
>Matthias
>
>
Regards
Damjan

Re: Please update boost (1.79.0 would be just great)

[Damjan Jovanovic]

For Clang, c++14 is the default, see https://clang.llvm.org/cxx_status.html
where it says "By default, Clang builds C++ code according to the C++14
standard".

On Sat, Jan 21, 2023 at 8:45 AM Yury Tarasievich 
wrote:

> Apologies if I'm being dense here, but is this
> indeed compiling to c++14? Won't you need
> explicit -std=c++14 option for that?
>
> To compile 'just' to c++11 (on linux) a patch of
> about 19 parts is needed, although admittedly it
> consists mostly of these guys:
>
> +#define BOOST_NO_CXX11_RVALUE_REFERENCES 1
> +#define BOOST_NO_CXX11_DELETED_FUNCTIONS 1
> +#include 
>
> On 20/01/2023 21:52, Damjan Jovanovic wrote:
> > So I eventually succeeded in getting OpenOffice
> > to compile against the "c++14" standard now, and
> > to use a newer Boost.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Please update boost (1.79.0 would be just great)

[Damjan Jovanovic]

On Thu, Jan 19, 2023 at 1:58 AM Damjan Jovanovic  wrote:

>
>
> On Sat, Jan 14, 2023 at 8:25 PM Pedro Giffuni  wrote:
>
>> Helo guys;
>> I don't currently have all the time I'd wish for AOO development so I
>> thought I'd suggest this task for some volunteer.
>> The Apache OpenOffice FreeBSD port has been broken for awhile and getting
>> boost updated would be of great help. Boost would also be useful to add
>> some functionality like support for more complex trigonometric functions.
>> I looked at the different verions and 1.79 seems to hit the right spot by
>> adding the right level of new functionality without causing trouble on old
>> compilers. So I just went ahead and uploaded boost_1_79_0.tar.bz2 to the
>> OOO extras repo on sourceforge.
>>
>> The process should be the regular update tarball, cleanup the patch, and
>> test on Windows/linux, however that is done with gbuild nowadays.
>>
>
> No, external dependencies still only build with dmake.
>
>
>> Of course in the case of boost it is easier said than done so .. good
>> luck! :-P
>> Pedro.
>
>
> Recent boost versions, 1.79.0 for example, require variadic templates and
> use a new and incompatible syntax for templates, which don't go with our
> "-std=gnu++98", eg:
> inc/boost/math/tools/mp.hpp:291:53: error: a space is required between
> consecutive right angle brackets (use '> >')
> struct mp_append_impl, L2, L3>
>
> We get far fewer errors when "-std=gnu++98" is removed, but since C++ 2011
> is stricter, then there are other issues in our code to fix.
>
>
So I eventually succeeded in getting OpenOffice to compile against the
"c++14" standard now, and to use a newer Boost.

The latest trunk should build successfully on FreeBSD using either:
- Clang, internal boost 1.55.0, internal vigra.
- Clang, system boost 1.80.0, system vigra, and the small patch I am
attaching to remove "-std=gnu++98" from the compiler flags (which uses
Clang's default instead, c++14).

I doubt we can use newer Boost versions on Windows, with the old compiler
we use there. Also what compiler do we use on OS/2?

Building against c++14 is full of warnings, and ::std::auto_ptr is obsolete
as of c++17 but we use it in 797 places...

Regards
Damjan
commit 4b9171ad362c8ba1283a0224d77740950773abc4
Author: Damjan Jovanovic 
Date:   Thu Jan 19 09:32:00 2023 +0200

FreeBSD C++ 2014 support.

diff --git a/main/solenv/gbuild/platform/freebsd.mk b/main/solenv/gbuild/platform/freebsd.mk
index 6fa486e0e2..587a5bde13 100644
--- a/main/solenv/gbuild/platform/freebsd.mk
+++ b/main/solenv/gbuild/platform/freebsd.mk
@@ -92,7 +92,6 @@ gb_CXXFLAGS := \
 	-fno-use-cxa-atexit \
 	-fvisibility-inlines-hidden \
 	-fvisibility=hidden \
-	-std=gnu++98 \
 	-pipe
 ifeq ($(COM),CLANG)
 gb_CXXFLAGS += -DHAVE_STL_INCLUDE_PATH
diff --git a/main/solenv/inc/unxfbsd.mk b/main/solenv/inc/unxfbsd.mk
index 92db30a813..246768c3ea 100644
--- a/main/solenv/inc/unxfbsd.mk
+++ b/main/solenv/inc/unxfbsd.mk
@@ -105,7 +105,7 @@ CFLAGSEXCEPTIONS=-fexceptions -fno-enforce-eh-specs
 CFLAGS_NO_EXCEPTIONS=-fno-exceptions
 
 # -fpermissive should be removed as soon as possible
-CFLAGSCXX= -pipe $(ARCH_FLAGS) -std=gnu++98
+CFLAGSCXX= -pipe $(ARCH_FLAGS)
 .IF "$(HAVE_GCC_VISIBILITY_FEATURE)" == "TRUE"
 CFLAGSCXX += -fvisibility-inlines-hidden
 .ENDIF # "$(HAVE_GCC_VISIBILITY_FEATURE)" == "TRUE"

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Please update boost (1.79.0 would be just great)

[Damjan Jovanovic]

On Sat, Jan 14, 2023 at 8:25 PM Pedro Giffuni  wrote:

> Helo guys;
> I don't currently have all the time I'd wish for AOO development so I
> thought I'd suggest this task for some volunteer.
> The Apache OpenOffice FreeBSD port has been broken for awhile and getting
> boost updated would be of great help. Boost would also be useful to add
> some functionality like support for more complex trigonometric functions.
> I looked at the different verions and 1.79 seems to hit the right spot by
> adding the right level of new functionality without causing trouble on old
> compilers. So I just went ahead and uploaded boost_1_79_0.tar.bz2 to the
> OOO extras repo on sourceforge.
>
> The process should be the regular update tarball, cleanup the patch, and
> test on Windows/linux, however that is done with gbuild nowadays.
>

No, external dependencies still only build with dmake.


> Of course in the case of boost it is easier said than done so .. good
> luck! :-P
> Pedro.


Recent boost versions, 1.79.0 for example, require variadic templates and
use a new and incompatible syntax for templates, which don't go with our
"-std=gnu++98", eg:
inc/boost/math/tools/mp.hpp:291:53: error: a space is required between
consecutive right angle brackets (use '> >')
struct mp_append_impl, L2, L3>

We get far fewer errors when "-std=gnu++98" is removed, but since C++ 2011
is stricter, then there are other issues in our code to fix.

I hate C++ and I hate boost. It would be best to reduce our use of both,
develop new components in Rust or something.

Regards
Damjan

Re: Buildbot problems

[Damjan Jovanovic]

Hi

That's progress, because if you compare it to the previous build's
./configure:
https://ci2.apache.org/#/builders/67/builds/509/steps/8/logs/stdio
it no longer stops on the error:
"configure: error: cannot run /bin/sh ./config.sub",
we got further to reach the awk error.

So the automatic changing of line endings by git really was a problem, and:
git clone -c core.autocrlf=false ...
really did fix it :-).

Now regarding Awk, instead of doing:
rm /bin/awk
mv /bin/gawk.exe /bin/awk.exe
can't we prepend PATH with a directory containing an "awk" script that just
calls gawk.exe?

Regards
Damjan

On Mon, Jan 16, 2023 at 12:54 AM Matthias Seidel 
wrote:

> Hi all,
>
> Looking at:
>
> https://ci2.apache.org/#/builders/67/builds/510/steps/8/logs/stdio
>
> the problem is definitely awk/gawk.
>
> Cygwin is at 3.3.3 and could be updated to 3.4.3. But remember to
> downgrade make then...
>
> Regards,
>
>Matthias
>
> Am 15.01.23 um 12:25 schrieb Matthias Seidel:
> > Hi Damjan, Peter,
> >
> > Am 15.01.23 um 09:58 schrieb Damjan Jovanovic:
> >> On Sun, Jan 15, 2023 at 10:11 AM Peter Kovacs  wrote:
> >>
> >>> Am 15.01.23 um 07:12 schrieb Damjan Jovanovic:
> >>>> Hi
> >>>>
> >>>> I am trying to get all the buildbots working again, but there are many
> >>>> problems...
> >>>>
> >>>> 1. All the Windows buildbots are failing in "./configure" with:
> >>>> configure: error: cannot run /bin/sh ./config.sub
> >>>>
> >>>> This could be due to \r\n line endings or a BOM on main/config.sub,
> but
> >>>> I've checked and it uses neither in Git, so I have no idea what's
> wrong.
> >>>> How do we retrieve config.log from the buildbot?
> >>> maybe autoconf is missing? the win bots will fail anyways because of
> >>> wrong awk.
> >>>
> >>>
> >> autoconf is there.
> >>
> >> I've now added "-c core.autocrlf=false" to "git clone" for the nightly
> >> build, in case git is converting line endings during checkout. Let's
> hope
> >> it works.
> > I don't think that this is necessary, the buildbots did work before with
> > the old configuration.
> >
> > But every time gawk/awk is updated in Cygwin we need to run manual steps
> > inside Cygwin:
> >
> > rm /bin/awk
> > mv /bin/gawk.exe /bin/awk.exe
> >
> > (I hope I got it right, the instructions in Wiki were wrong before)
> >
> > This can be done by Infra.
> >
> > I already did the changes for Cygwin64, so Cygwin32 can now be removed
> > from the machine.
> >
> >>
> >>>> 2. Git-based projects are supposed to use
> >>>> https://github.com/apache/infrastructure-bb2 instead of the SVN-based
> >>>> https://svn.apache.org/repos/infra/infrastructure/buildbot2 that we
> use.
> >>>> They're different repositories, not different links to the same
> > Gavin wanted to move our config location at some time. There are still
> > other projects in SVN, though.
> >
> > Regards,
> >
> >Matthias
> >
> >>> repository.
> >>>
> >>> I have updated the links in build column.
> >>>
> >> Thank you :).
> >>
> >>
> >>>> 3. The "puppet" links on
> >>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Buildbot+info
> are
> >>>> dead. In the table on that page, all the "Build", "Host VM", and
> "Logs"
> >>>> links are dead.
> >>>>
> >>>> It turns out that for "Logs", the link should be, for instance:
> >>>> https://nightlies.apache.org/openoffice/buildlogs/linux64*/log/log/*
> >>>> unxlngx6.pro.build.html
> >>>> instead of:
> >>>> https://nightlies.apache.org/openoffice/buildlogs/linux64*/log/*
> >>>> unxlngx6.pro.build.html
> >>>> probably because the buildbot's openoffice.py file does:
> >>>> 'mkdir' , '-p' , 'log/logarch/log'
> >>>> 'cp -fv log/*.html log/logarch/log'
> >>>> mkdir -p buildlogs/linux64/log && cp -rp log/logarch/*
> >>> buildlogs/linux64/log
> >>>> so that's why we end up with the .../log/log/... in the path.
> >>>> Ideas?
> >>> no idea.
> >>>> 4. On https://wiki.openoffice.org/wiki/Buildbot, the "Buildbot
> >>>> Configuration File" link was dead, but I was able to fix it to use the
> >>> new
> >>>> link. The link to the "overview" probably goes to the wrong page
> >>> (shouldn't
> >>>> it be the "Waterfall View" page on ci2.apache.org?).
> >>>>
> >>>> 5. On https://nightlies.apache.org/openoffice/ all the "Build Logs"
> >>> links
> >>>> are dead. Many/all of the SDK links are dead.
> >>> I am not sure but i think the sdks were deactivated.
> >>>
> >>> we can add them anytime if needed.
> >>>
> >>>
> >> We need SDKs to build the test/ directory, though I am working towards
> >> changing that.
> >>
> >> Thank you
> >> Damjan
> >>
>
>

Re: Buildbot problems

[Damjan Jovanovic]

On Sun, Jan 15, 2023 at 10:11 AM Peter Kovacs  wrote:

>
> Am 15.01.23 um 07:12 schrieb Damjan Jovanovic:
> > Hi
> >
> > I am trying to get all the buildbots working again, but there are many
> > problems...
> >
> > 1. All the Windows buildbots are failing in "./configure" with:
> > configure: error: cannot run /bin/sh ./config.sub
> >
> > This could be due to \r\n line endings or a BOM on main/config.sub, but
> > I've checked and it uses neither in Git, so I have no idea what's wrong.
> > How do we retrieve config.log from the buildbot?
>
> maybe autoconf is missing? the win bots will fail anyways because of
> wrong awk.
>
>
autoconf is there.

I've now added "-c core.autocrlf=false" to "git clone" for the nightly
build, in case git is converting line endings during checkout. Let's hope
it works.


> >
> > 2. Git-based projects are supposed to use
> > https://github.com/apache/infrastructure-bb2 instead of the SVN-based
> > https://svn.apache.org/repos/infra/infrastructure/buildbot2 that we use.
> > They're different repositories, not different links to the same
> repository.
>
> I have updated the links in build column.
>

Thank you :).


>
> > 3. The "puppet" links on
> > https://cwiki.apache.org/confluence/display/OOOUSERS/Buildbot+info are
> > dead. In the table on that page, all the "Build", "Host VM", and "Logs"
> > links are dead.
> >
> > It turns out that for "Logs", the link should be, for instance:
> > https://nightlies.apache.org/openoffice/buildlogs/linux64*/log/log/*
> > unxlngx6.pro.build.html
> > instead of:
> > https://nightlies.apache.org/openoffice/buildlogs/linux64*/log/*
> > unxlngx6.pro.build.html
> > probably because the buildbot's openoffice.py file does:
> > 'mkdir' , '-p' , 'log/logarch/log'
> > 'cp -fv log/*.html log/logarch/log'
> > mkdir -p buildlogs/linux64/log && cp -rp log/logarch/*
> buildlogs/linux64/log
> > so that's why we end up with the .../log/log/... in the path.
> > Ideas?
> no idea.
> >
> > 4. On https://wiki.openoffice.org/wiki/Buildbot, the "Buildbot
> > Configuration File" link was dead, but I was able to fix it to use the
> new
> > link. The link to the "overview" probably goes to the wrong page
> (shouldn't
> > it be the "Waterfall View" page on ci2.apache.org?).
> >
> > 5. On https://nightlies.apache.org/openoffice/ all the "Build Logs"
> links
> > are dead. Many/all of the SDK links are dead.
>
> I am not sure but i think the sdks were deactivated.
>
> we can add them anytime if needed.
>
>
We need SDKs to build the test/ directory, though I am working towards
changing that.

Thank you
Damjan

Buildbot problems

[Damjan Jovanovic]

Hi

I am trying to get all the buildbots working again, but there are many
problems...

1. All the Windows buildbots are failing in "./configure" with:
configure: error: cannot run /bin/sh ./config.sub

This could be due to \r\n line endings or a BOM on main/config.sub, but
I've checked and it uses neither in Git, so I have no idea what's wrong.
How do we retrieve config.log from the buildbot?

2. Git-based projects are supposed to use
https://github.com/apache/infrastructure-bb2 instead of the SVN-based
https://svn.apache.org/repos/infra/infrastructure/buildbot2 that we use.
They're different repositories, not different links to the same repository.

3. The "puppet" links on
https://cwiki.apache.org/confluence/display/OOOUSERS/Buildbot+info are
dead. In the table on that page, all the "Build", "Host VM", and "Logs"
links are dead.

It turns out that for "Logs", the link should be, for instance:
https://nightlies.apache.org/openoffice/buildlogs/linux64*/log/log/*
unxlngx6.pro.build.html
instead of:
https://nightlies.apache.org/openoffice/buildlogs/linux64*/log/*
unxlngx6.pro.build.html
probably because the buildbot's openoffice.py file does:
'mkdir' , '-p' , 'log/logarch/log'
'cp -fv log/*.html log/logarch/log'
mkdir -p buildlogs/linux64/log && cp -rp log/logarch/* buildlogs/linux64/log
so that's why we end up with the .../log/log/... in the path.
Ideas?

4. On https://wiki.openoffice.org/wiki/Buildbot, the "Buildbot
Configuration File" link was dead, but I was able to fix it to use the new
link. The link to the "overview" probably goes to the wrong page (shouldn't
it be the "Waterfall View" page on ci2.apache.org?).

5. On https://nightlies.apache.org/openoffice/ all the "Build Logs" links
are dead. Many/all of the SDK links are dead.

Please help?

Thank you
Damjan

Re: T-DOSE 2023

[Damjan Jovanovic]

On Sat, Jan 7, 2023 at 4:18 PM Dr. Michael Stehmann <
anw...@rechtsanwalt-stehmann.de> wrote:

> Hello,
>
> T-DOSE 2023 will be held on the 22nd and 23rd of April 2023, at a new
> location the Weeffabriek in Geldrop (near Eindhoven).
>
> T-DOSE is a free and yearly event held in The Netherlands to promote use
> and development of Free Software. During this event, Free Software
> projects, developers and visitors can exchange ideas and knowledge.
>
> https://t-dose.org/



OpenOffice is Open-Source Software, not Free Software. There is a
difference.

Regards
Damjan

Re: ByteString vs Strbuf vs OString

[Damjan Jovanovic]

On Sat, Jan 7, 2023 at 9:51 AM Peter Kovacs  wrote:

> Hi all,
>
>
> I have an emotional issue and I need some help.
>
> I think the classes mentioned in subject are all crap. They are all ugly
> and I do not want to use any of them.
>
> I would like to remove them. And replace them with
>
>
>   std::basic_stringstream
>
>
>   std::string
>
>
> But this is a huge and fundamental change. What I would like to do is to
> hollow out the classes we use, one by one, until everything is using std
> classes or can cast to. Then remove the now obsolete classes within the
> code.
>
> any objections?
>
>
Hi

Please leave them alone. They all have their purpose, and they work in very
specific ways to accomplish their tasks.

The main/tools String with its 16 bit length, saves space for the large
number of strings in Calc cells.

The main/sal OString and OUString are 32 bit and copy-on-write, like Java's
java.lang.String. Also UNO serializes to and from OUString for C++.

I do agree that string type changes will be necessary in some cases. For
example if we want to increase our 16 bit limit on maximum paragraph size
to 32 bits, we will probably have to change the tools String to a longer
string type.

The real crap classes that should be replaced ASAP are the 16 bit main/svl
PTRARR, which I replaced in 2 places in
https://github.com/apache/openoffice/pull/164, but which is used in another
53 places (
http://opengrok.openoffice.org/search?project=trunk=SV_DECL_PTRARR==full).
Many 16 bit limits come from that class. And I now discovered another 22
usages of SV_DECL_PTRARR_SORT. The problem is, that has many knock-on
effects, as is clear from the size of my PR.

We also have a bunch of primitive pre-STL main/tools classes like Container
and List, written around 1994 and generally not very good at anything,
including performance.

Yes, the way C++ is used in OpenOffice is unusual and foreign to everyone.
But eventually it makes sense. Start with one of the more recently
developed modules, like the OOXML filter in main/oox, or the Base
application in main/dbaccess, which were written closer to 2010 and are
much cleaner, easier to read and understand, use STL containers, etc. I've
been improving that OOXML filter lately and could help you get started.

Regards
Damjan

Re: Fails to build on Pop!_OS 18.04

[Damjan Jovanovic]

On Wed, Jan 4, 2023 at 1:47 PM Pedro Lino 
wrote:

> Hi all
>
> I'm testing a UEFI compatible Linux OS named Pop!_OS
> Compiling 41X fails on bean with messages
>
> WARNING(S):
> Some modules contain old output trees! Please check: bean
>
> =
> Building module bean
> =
>
> Entering /source/openoffice/main/bean/com/sun/star/comp/beans
>
>
> Entering /source/openoffice/main/bean/native/unix
>
> Compiling: beans/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c
> com_sun_star_comp_beans_LocalOfficeWindow.c:35:10: fatal error: jawt_md.h:
> No such file or directory
>  #include "jawt_md.h"
>   ^~~
> compilation terminated.
> dmake:  Error code 1, while making '../../
> unxlngx6.pro/slo/com_sun_star_comp_beans_LocalOfficeWindow.obj'
>
>
> Any tips/instructions that a non-dev can follow?
>
> Thanks!
>
> Pedro
>
>
Hi Pedro

What Java version do you have installed?

Regard
Damjan

Re: Happy...

[Damjan Jovanovic]

On Sun, Jan 1, 2023 at 8:40 PM Matthias Seidel 
wrote:

> ...new year! ;-)
>
> Matthias
>
>
Happy New Year everyone!

Damjan

[Wiki] Access to update the main wiki page?

[Damjan Jovanovic]

Hi

I have access to edit our wiki, but while trying to update our main main
wiki page at https://wiki.openoffice.org/wiki/Main_Page I saw it's been
locked against changes.

Can I please get access?

For starters, I'd like to add a link to
https://wiki.openoffice.org/wiki/Source_code_directories under
Documentation -> For Developers.

Thank you
Damjan

Re: Profile Backup/Restore

[Damjan Jovanovic]

Hi all

On Wed, Dec 28, 2022 at 4:55 PM Matthias Seidel 
wrote:

> Hi Pedro,
>
> Am 19.12.22 um 13:39 schrieb Pedro Lino:
> > Hi all
> >
> > Is there any extension to Backup/Restore the contents of the User
> Profile?
> >
> > I don't mean copy files but actually exporting and importing the
> contents?
> >
> > If there isn't, is any of the developers on this mailing list interested
> in creating one?
> >
> > I believe this would be a great contribution to all OpenOffice users...
> >
> > I volunteer to do any testing required!
>
> I think this has been discussed several times in the last years, but
> nothing ever happened.
>
> I am a bit concerned that this time you didn't even get a reaction...
>

It's the festive season, many people aren't reading emails.


>
> Personally, I would prefer an extension (OS independent), but I could
> imagine problems with copying/restoring the profile while AOO is still
> active.
>
>
If profile corruption is such a problem, why don't we fix it?

Where are the bug reports?


> Regards,
>
>Matthias
>
> >
> > Thank you advance!
> >
> > Best,
> > Pedro
> >
>
>
Regards
Damjan

Re: Support for maven

[Damjan Jovanovic]

On Fri, Dec 2, 2022 at 9:10 PM Jim Jagielski  wrote:

> There are some java apps that no longer support ant and
> instead rely on maven. Last I checked, I don't think we
> support that, do we?
>
>
>
But why are we compiling Java projects?

We compile C/C++ projects because (1) upstream often doesn't provide
binaries, and/or (2) we need to patch the source.

For Java projects, (1) is almost universally false, and (2) is often false.

Why can't we just download and use the upstream .jar files in those cases,
instead of needing Maven to build the source ourselves?

Regards
Damjan

Re: building 4.2.X and trunk on ARM64 platforms

[Damjan Jovanovic]

Yes, and bridges are specific to CPU, OS compiler version, and compiler
settings. Eg. Even on Win32, the legacy mingw compiler uses sjlj exception
handling, which is completely incompatible with MSVC's exception handling,
so a separate bridge is needed for each. We would likely need a
gcc_linux_arm64 bridge for the Pinebooks and Raspberry Pis,
msvc_win64_arm64 for Windows on ARM64,  and s5abi_macosx_arm64 for the new
Macs.

LLVM is permissively licensed and highly compatible with MSVC's exception
handling, and someone told me AOO successfully builds and runs with
LLVM-based mingw using our MSVC bridge, so the LLVM code could help us
complete our Win64 bridge.

What's your idea to get rid of the assembler code?

On Sat, Dec 24, 2022 at 12:06 PM Peter kovacs 
wrote:

> The blocker is more ore less the bridge.
> There we have Assembler code which helps bridging binaries through the JDI
> into Java.
> You need to write the same for Arm64.
> At least it looks for me like that.
>
> (The same is true imho for Win64 builds. So maybe if you check for the
> Windows 64 mails from Damjan, you will find some info.)
>
> I think in addition for Mac you need to update to the latest SDK in order
> to get something that natively works.
>
> Imho it would be cool to build on Mac as is and fix the 4.2. blockers
> first.
>
> In the long run I would like to get rid of the assembler code. I have an
> idea how to do this, but I am not sure if the idea is viable.
>
> Am 23. Dezember 2022 16:29:00 MEZ schrieb Matthias Seidel <
> matthias.sei...@hamburg.de>:
> >Hi Carl,
> >
> >Am 23.12.22 um 16:19 schrieb Carl Marcum:
> >> Hi Matthias,
> >>
> >>
> >> On 12/23/22 10:12 AM, Matthias Seidel wrote:
> >>> Hi Carl,
> >>>
> >>> Am 23.12.22 um 15:21 schrieb Carl Marcum:
>  Hi All,
> 
>  I'm working on setting up a MacBook Pro M2 with Ventura and was
>  wondering on the current state of building AOO 4.2+ or trunk on ARM64
>  for macOS or Linux. It seems pretty good at virtualization with ARM64
>  OS's.
> 
>  I seem to remember patches being submitted for ARM but I don't find
>  much about building.
> >>> Yes, it would be great if we had a native ARM build... ;-)
> >>>
>  Otherwise I'll have to try emulation for x64 and would probably be
>  much less performant.
> >>> macOS on M1/M2 runs the Intel binaries automatically via "Rosetta 2"
> >>> [1]. I haven't heard of performance issues.
> >>
> >> Yes I'm running AOO on macOS fine.  This is about the ARM64 platform
> >> building it ;)
> >
> >I think the patches you remember were for ARM32. To my knowledge we
> >never got a build for that out officially...
> >
> >ARM64 is definitely worth it, but I also would like to run AOO on my
> >Raspberry Pi! ;-)
> >
> >Regards,
> >
> >   Matthias
> >
> >>
> >> Best regards,
> >> Carl
> >>
> >>>
> >>> Regards,
> >>>
> >>> Matthias
> >>>
> >>> [1]https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta_2
> >>>
>  Thanks,
> 
>  Carl
> 
> 
> 
>  -
>  To unsubscribe, e-mail:dev-unsubscr...@openoffice.apache.org
>  For additional commands, e-mail:dev-h...@openoffice.apache.org
> 
> >
>

Re: nss has included sqlite instance

[Damjan Jovanovic]

On Wed, Dec 21, 2022 at 7:51 PM Peter Kovacs  wrote:

>
> Am 21.12.22 um 18:22 schrieb Damjan Jovanovic:
> > On Wed, Dec 21, 2022 at 3:37 PM Peter Kovacs  wrote:
> >
> >> Are we aware on this dependency?
> >>
> >> I am running into compiler issues using gcc 11.3 from ubuntu 22.04 LTS.
> >>
> >>
> > I am aware. I discovered, and might even have proposed on this list, that
> > we use that sqlite database ourselves, to import its CA root
> certificates,
> > without needing to build and ship NSS as a dependency.
>
> I remember we discussed sqlite in the topic "[discussion] future
> embedded DB in AOO".
>
> Maybe I missed the point. Or do you refer to the attempt to replace nss
> with openssl?
>
>
>
Yes, a possible replacement was intended. It was a 22 May 2022 email about
the new WebDAV module and CA certificate use by Curl and OpenSSL where I
said:

---quote---
With the CURLOPT_CAINFO_BLOB option it might even be possible to skip the
custom certificate verification we do later, and pre-populate Curl/OpenSSL
with NSS certificates from the beginning, I just don't know enough about NSS
to rely on that (eg. if you are using a cryptographic device or smart card
in NSS, how does that work?). If that option is ok, then we might not even
need the NSS libraries: recent versions of NSS store all the certificates
in an SQLite database, which can be accessed with SQLite APIs directly, no
need to build with or ship the NSS libraries at all.
---quote---

More recently I discovered p11-kit / p11-glue has the "trust" CLI tool (if
not something better) which can also provide those certificates on
Linux/BSD, so we wouldn't even need to ship SQLite.

Re: nss has included sqlite instance

[Damjan Jovanovic]

On Wed, Dec 21, 2022 at 3:37 PM Peter Kovacs  wrote:

> Are we aware on this dependency?
>
> I am running into compiler issues using gcc 11.3 from ubuntu 22.04 LTS.
>
>
I am aware. I discovered, and might even have proposed on this list, that
we use that sqlite database ourselves, to import its CA root certificates,
without needing to build and ship NSS as a dependency.

Damjan

Re: AOO as built from source fails in libcurl

[Damjan Jovanovic]

On Sat, Nov 26, 2022 at 5:13 PM Matthias Seidel 
wrote:

> Hi,
>
> That looks a bit like this issue on macOS:
>
> https://bz.apache.org/ooo/show_bug.cgi?id=128535
>
> Can you try to disable the automatic update check?
>
> Regards,
>
>Matthias
>
> Am 26.11.22 um 16:08 schrieb Yury Tarasievich:
> > Hello all,
> >
> > I've built an instance of AOO 4.5 from couple of days old git
> > checkout. (fresh-ish Linux, gcc 12.2.0) After launching the binary and
> > letting it sit there, it reliably fails after a minute or so, always
> > with the same kind of stack trace, which follows after my text.
> >
> > I have beginner's skills with GDB. What should I look for?
> >
> > #0  0x0001 in  ()
> > #1  0x7fffd7a13d38 in  () at /lib64/libssl.so.1.1
> > #2  0x7fffd7a142b1 in  () at /lib64/libssl.so.1.1
> > #3  0x7fffd7a48437 in  () at /lib64/libssl.so.1.1
> > #4  0x7fffd7a3f8d6 in  () at /lib64/libssl.so.1.1
> > #5  0x7fffd7be5206 in  () at /usr/lib64/libcurl.so.4
> > #6  0x7fffd7be9bda in  () at /usr/lib64/libcurl.so.4
> > #7  0x7fffd7beace5 in  () at /usr/lib64/libcurl.so.4
> > #8  0x7fffd7ba4396 in  () at /usr/lib64/libcurl.so.4
> > #9  0x7fffd7bbbcec in  () at /usr/lib64/libcurl.so.4
> > #10 0x7fffd7bbcd3e in curl_multi_perform () at
> > /usr/lib64/libcurl.so.4
> > #11 0x7fffd7b9515b in curl_easy_perform () at /usr/lib64/libcurl.so.4
> > #12 0x7fffd5c9ef92 in http_dav_ucp::CurlRequest::perform()
> > (this=this@entry=0x7fffed7d3610)
> > at
> > /d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/CurlRequest.cxx:266
> > #13 0x7fffd5c9f222 in
> > http_dav_ucp::CurlRequest::get(http_dav_ucp::CurlUri, rtl::OUString)
> > (this=this@entry=0x7fffed7d3610, uri=..., path=...) at
> > /d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/CurlRequest.cxx:189
> > #14 0x7fffd5c9c2db in http_dav_ucp::CurlSession::GET(rtl::OUString
> > const&, std::vector >
> > const&, http_dav_ucp::DAVResource&,
> > http_dav_ucp::DAVRequestEnvironment const&)
> > (this=this@entry=0x7fffd7e505b0, inPath=,
> > inHeaderNames=std::vector of length 0, capacity 0, ioResource=...,
> > rEnv=...) at
> > /d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/CurlSession.cxx:1128
> > #15 0x7fffd5c8a608 in
> > http_dav_ucp::DAVResourceAccess::GET(std::vector > std::allocator > const&, http_dav_ucp::DAVResource&,
> > com::sun::star::uno::Reference
> > const&)
> > (this=0x7fffd5fa2ec0, rHeaderNames=std::vector of length 0,
> > capacity 0, rResource=..., xEnv=...)
> > at
> >
> /d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/DAVResourceAccess.cxx:443
> > #16 0x7fffd5c76358 in
> > http_dav_ucp::Content::open(com::sun::star::ucb::OpenCommandArgument2
> > const&,
> > com::sun::star::uno::Reference
> > const&) (this=this@entry=0x7fffd7e504b0, rArg=..., xEnv=...)
> > at
> > /d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/webdavcontent.cxx:2282
> > #17 0x7fffd5c7950d in
> > http_dav_ucp::Content::execute(com::sun::star::ucb::Command const&,
> > int,
> > com::sun::star::uno::Reference
> > const&) (this=0x7fffd7e504b0, aCommand=, Environment=...)
> > at
> > /d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/webdavcontent.cxx:621
> > #18 0x7fffd5f547d0 in (anonymous
> > namespace)::UpdateInformationProvider::load(rtl::OUString const&)
> > (this=0x7fffd5f8ce50, rURL=) at
> >
> /d/home/ty/c/+ooo/aoo45/main/extensions/source/update/feed/updatefeed.cxx:516
> > #19 0x7fffd5f553e4 in (anonymous
> >
> namespace)::UpdateInformationProvider::getUpdateInformationEnumeration(com::sun::star::uno::Sequence
> > const&, rtl::OUString const&) (this=0x7fffd5f8ce50,
> > repositories=, extensionId=...)
> > at
> >
> /d/home/ty/c/+ooo/aoo45/main/extensions/source/update/feed/updatefeed.cxx:616
> > #20 0x7fffd7cb9c4c in checkForUpdates(UpdateInfo&,
> > com::sun::star::uno::Reference
> > const&,
> > com::sun::star::uno::Reference
> > const&,
> >
> com::sun::star::uno::Reference
> > const&) (o_rUpdateInfo=..., rxContext=..., rxInteractionHandler=...,
> > rUpdateInfoProvider=...)
> > at
> >
> /d/home/ty/c/+ooo/aoo45/main/extensions/source/update/check/updateprotocol.cxx:130
> > #21 0x7fffd7cb0128 in (anonymous
> > namespace)::UpdateCheckThread::runCheck(bool&)
> > (this=0x7fffd6010a60, rbExtensionsChecked=@0x7fffed7d3d4f: false)
> > at
> >
> /d/home/ty/c/+ooo/aoo45/main/extensions/source/update/check/updatecheck.cxx:458
> > #22 0x7fffd7cb05c5 in (anonymous
> > namespace)::UpdateCheckThread::run() (this=0x7fffd6010a60)
> > at
> >
> /d/home/ty/c/+ooo/aoo45/main/extensions/source/update/check/updatecheck.cxx:566
> > #23 0x7fffd7cb098a in osl::threadFunc(void*) (param=0x7fffd6010a60)
> > at
> > /d/home/ty/c/+ooo/aoo45/main/solver/450/
> unxlngx6.pro/inc/osl/thread.hxx:184
> > #24 0x77df7219 in osl_thread_start_Impl (pData=0x7fffd0005d10)
> > at thread.c:266
> > #25 0x77715fea in start_thread () at /lib64/libc.so.6
> > #26 

Re: [Action required] Cygwin x86 end-of-life

[Damjan Jovanovic]

On Sat, Nov 26, 2022 at 2:42 PM Matthias Seidel 
wrote:

> Hi Pedro,
>
> Am 26.11.22 um 12:26 schrieb Pedro Lino:
> > Hi Matthias, all
> >
> >> On 11/25/2022 7:16 PM WET Matthias Seidel 
> wrote:
> >> Damjan posted the needed patches to build AOO41X with Cygwin64, if
> >> anyone wants to commit them...
> > If this exists and works, it should be committed ASAP.
> We discussed that already a year (!) ago. Unfortunately I can't find the
> list in my archive, but I am sure Damjan posted it.
>

The required patches are also listed on the Wiki:
https://wiki.openoffice.org/wiki/Building_old_versions

Regards
Damjan

Let's replace expat with libxml2?

[Damjan Jovanovic]

Hi

We currently use 2 XML libraries in our C/C++ code, expat and libxml2.
This is unnecessary, one of them can be removed, and I propose we
remove expat.

expat is a small library that only does SAX parsing, and lacks DOM,
lacks XSLT, lacks schema validation or any more advanced features we
use. By comparison, libxml2 is probably the most complete open-source
XML library in the world for C, with endless features, many users,
stable API, no mandatory dependencies, portable, highly standards
compliant and compatible with other XML libraries, performs well
(https://xmlbench.sourceforge.net/results/benchmark200910/index.html),
is a requirement for libxslt, is permissively licensed, takes security
seriously (the maintainer made money by fixing its security bugs in
Google's bug bounties), actively developed, documented, nice readable
source code, and it's generally of very high quality.

We generally don't like unnecessary dependencies, and expat has been
difficult to upgrade to newer versions due to compiler issues. Since
expat only implements a small subset of libxml2's features, could we
replace it with libxml2?

Where is expat used? The output of "grep expat */prj/build.lst" gives
us these modules:
lucene
openssl
sax
shell
tools

lucene and openssl don't really require expat. Removing expat from
their build.lst and stopping the expat/ module from building still
gets lucene and openssl to build successfully, so clearly their
dependency on expat was always unnecessary. As of commit
461facd3d94599cc708db50510b7e42483407720 they no longer depend on
expat.

tools probably also has an unnecessary dependency on expat, but this
is harder to prove as tools -> i18pool -> sax -> expat, so let's
revisit this later.

Only the sax and shell modules really use expat.

In sax, it is used to implement the com.sun.star.xml.sax.Parser UNO
service (com.sun.star.comp.extensions.xml.sax.ParserExpat
implementation name), which is used fairly widely throughout AOO,
including for loading OpenDocument files (sax -> svx -> xmloff), but
all the expat usage is contained in a single file:
sax/source/expatwrap/sax_expat.cxx.

In shell, it is used to implement a SAX parser internal to that
module, which is then consumed by several libraries, including
source/unix/sysshell which deals with the recently used file list in
$HOME/.recently-used.


Porting sax to libxml2


Patching the sax module to use libxml2 instead of expat was successful
enough to get AOO to build, run and load documents, even though it's
still incomplete.

Most of the SAX callbacks are compatible between expat and libxml2,
and converting those was easy. String types had to be changed, and
sometimes the parameter list has to be reordered, or expat-only
parameters removed. CDATA is reported with a single event in libxml2,
which needed conversion to startCDATA + characters + endCDATA events
on our UNO callbacks.

Unfortunately expat's XML_SetExternalEntityRefHandler() works quite
differently on libxml2, and has been commented out for now while I try
to understand what external entities are and how you generally load
them. Also expat's XML_SetDefaultHandlerExpand() is not yet
implemented and I am not sure what to do there.

One gotcha was that when there are no attributes on an element,
libxml2 calls the startElement() callback with NULL attributes, while
expat called it with attributes to a 1 element char** array containing
NULL. This was crashing i18npool's saxparser during the build, in
SaxExpatParser_Impl::callbackStartElement() during the conversion of
attributes to its attribute list. Luckily it was easy to fix.

The code for sax_expat.cxx has become quite a bit shorter, because
libxml2 always uses UTF-8 unlike expat which can be built with UTF-16
or UTF-8, so the XmlNChar2OUString() and XmlChar2OUString() functions
have been removed. Also the getErrorMessage() function no longer has
to have a list of hardcoded error codes with our error message for
each, as libxml2's xmlCtxtGetLastError() returns the official error
message.

Also the sax module uses the SAX1 API. libxml2 supports both SAX1 and
SAX2, but SAX1 is optional, and will be disabled if
LIBXML_SAX1_ENABLED is undefined in libxml2's
include/libxml/xmlversion.h. Currently it's hardcoded to 1, so it
should always be defined, but when we use the system libxml2, we don't
know that for sure. For now, I've added a check for
LIBXML_SAX1_ENABLED and preprocessor #error if missing. It's also
possible for the sax module to convert SAX2 callbacks to SAX1 on the
UNO side, but that's inefficient (eg. we'd have to concatenate
namespace + ":" + localname, which the consuming code will later just
split up again). Ideally we would make a XDocumentHandler2 UNO
interface based on SAX2, and upstream UNO consumers would use that, so
we could use SAX2 throughout AOO. This is more of a long-term plan
though, for now SAX1 should be fine.

Even with these issues, it works 

Re: Monteray MacOS build and Python

[Damjan Jovanovic]

On Mon, Sep 5, 2022 at 10:36 AM Bidouille  wrote:

> Hello,
>
> Since MacOS 12.3, Apple don't provide Python 2.7
>
> https://developer.apple.com/documentation/macos-release-notes/macos-12_3-release-notes#Python
>
> So, you can not run any Python scripts anyway.
>
> Annoying...
>
>
We have had Python 3 working on Linux/FreeBSD for a while now, in (at
least) trunk, with system-provided Python, see
https://bz.apache.org/ooo/show_bug.cgi?id=123975#c27.

We just can't build and ship an internal Python 3, like we do for Python 2
on Windows.

Shouldn't using the system-provided Python 3 be possible on MacOS too?

Re: The issue of bad allocation in Calc

[Damjan Jovanovic]

On Mon, Sep 5, 2022 at 3:34 PM Aivaras Stepukonis 
wrote:

> Hi,
>
> Does anyone have the time and expertise to solve the issue of bad
> allocation afflicting Calc as per Issue
> 125006 - Calc
> Consistently crashing, usually with "Fatal Error - Bad Allocation"
> ? I've experienced
> many of these crashes personally in the past few years. They severely
> undermine one‘s productivity.
>
> --
> Pagarbiai / Sincerely,
>  Aivaras Stepukonis 


Hi

I am sorry to hear that. I'll see what I can do.

Regards
Damjan

Re: Any news from x64 port?

[Damjan Jovanovic]

On Wed, Aug 31, 2022 at 3:50 PM Bidouille  wrote:

> Seems to be paused since 2018:
> https://wiki.openoffice.org/wiki/Win64_port
>
>
So I've been playing around lately, and thinking how to do the Win64 port,
a newer MSVC compiler, and to finish the port to gbuild or a better build
system, all at the same time.

First I tried out the Meson build system (https://mesonbuild.com), which is
getting popular. I can see the attraction, it's elegant, well designed, and
the documentation is good. It's easy to start with. The language is similar
to Python, but not Turing complete to prevent build scripts from getting
too complex. The lack of any functions means that there's only one way to
script the build, and all meson.build files end up looking the same. I got
several modules to build: solenv, soltools, xml2cmp, and began sal. I got
my hopes up, and then hit a fatal flaw: custom targets don't allow
specifying the output directory, meaning that custom targets which output
files to many directories (like our idl files) need many many meson.build
files, one in every possible output directory. This isn't getting fixed
upstream (https://github.com/mesonbuild/meson/issues/2320), and since we
use custom targets extensively, Meson is useless to us. So I gave up on
that attempt but still have that branch around, if anyone wants to have a
look.

Currently I am experimenting with the SCons build system again, but using a
very different approach.

I want to isolate a small number of modules, and get them building with
SCons, in isolation from the rest of OpenOffice. Once this exists, it can
be ported to Win64. It can be ported to newer MSVC. It can be ported
wherever and changed however we need. Then, the rest of OpenOffice can be
ported to it.

Possibly, this could be just the UNO framework, which is critical to the
Win64 port, as the "bridges" component is involved with custom assembly
language calls to and from C++.

It is just too difficult to port the whole of OpenOffice to Win64, or to
newer MSVC, or to a newer build system. At least, broken up, it should be
more manageable.

I'll keep you updated regarding my progress.

Damjan

Re: --with-system-boost breaks build in vcl, --without in configmgr

[Damjan Jovanovic]

Hi

Linux and FreeBSD have always used the "gnu++98" standard:

openoffice-git/main]$ grep '\-std' solenv -R
solenv/inc/unxfbsd.mk:CFLAGSCXX= -pipe $(ARCH_FLAGS) -std=gnu++98
solenv/inc/unxlng.mk:CFLAGSCXX= -pipe $(ARCH_FLAGS) -std=gnu++98
solenv/gbuild/platform/freebsd.mk: -std=gnu++98 \
solenv/gbuild/platform/linux.mk: -std=gnu++98 \

Regards
Damjan

On Tue, Aug 23, 2022 at 10:46 PM Peter Kovacs  wrote:

> Hi Damjan,
>
> First with what C++ Standard do you build?
>
> I have seen strange errors if you build with the wrong standard.
>
> All the best
>
> Peter
>

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

On Sat, May 28, 2022 at 6:54 PM Arrigo Marchiori 
wrote:

> Hello Damjan, All,
>
> On Sat, May 28, 2022 at 03:22:53PM +0200, Damjan Jovanovic wrote:
>
> > On Sat, May 28, 2022 at 11:48 AM Arrigo Marchiori
> 
> > wrote:
> >
> > > Hello Damjan,
> > >
> > > On Sat, May 28, 2022 at 11:12:45AM +0200, Damjan Jovanovic wrote:
> > >
> > > > On Sat, May 28, 2022 at 9:20 AM Arrigo Marchiori
>  > > >
> > > > wrote:
> > > >
> > > > > Hello Damjan, all,
> > > > >
> > > > > On Fri, May 27, 2022 at 11:27:11PM +0200, Arrigo Marchiori wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > On Fri, May 27, 2022 at 09:46:51PM +0200, Arrigo Marchiori wrote:
> > > > > >
> > > > > > > Hello Damjan,
> > > > > > >
> > > > > > > On Sun, May 22, 2022 at 06:10:46PM +0200, Damjan Jovanovic
> wrote:
> > > > > > >
> > > > > > > > On Sun, May 22, 2022 at 2:43 PM Arrigo Marchiori
> > > > > 
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello Damjan, all,
> > > > > > > > >
> > > > > > > > > On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic
> > > wrote:
> > > > > > > > >
> > > > > > > > > > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski <
> > > j...@jagunet.com>
> > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I'm gonna look into the serf->(lib)curl option...
> Since we
> > > > > don't use
> > > > > > > > > any
> > > > > > > > > > > of the fancy features of serf, I'm thinking that the
> easy
> > > > > option might
> > > > > > > > > be
> > > > > > > > > > > best
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi
> > > > > > > > > >
> > > > > > > > > > I've ported our WebDAV content provider module from Serf
> to
> > > Curl.
> > > > > > > > >
> > > > > > > > > I just enhanced the error reporting a bit; I am finding a
> > > problem
> > > > > > > > > under Linux and I do not really know how to assess it.
> > > > > > > > >
> > > > > > > > > The problem: if we build AOO on CentOS (that is our
> reference
> > > > > > > > > platform) then Curl will look for CA certificates in
> > > > > > > > > /etc/pki/tls/certs/ca-bundle.crt
> > > > > > > > >
> > > > > > > > > This will fail on openSUSE and probably on Ubuntu as well.
> > > > > > > > >
> > > > > > > > > It seems that the above path is set at configure time and
> > > embedded
> > > > > > > > > into Curl's code as #define macros.
> > > > > > > > >
> > > > > > > > > Is there an ``official'' way to assess this? Like, can we
> > > depend on
> > > > > > > > > NSS' certificate store as you wrote (quoted below)?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Curl/OpenSSL have an enormous number of options and I am
> pretty
> > > sure
> > > > > it can
> > > > > > > > be fixed, but first I need to understand where and how it's
> > > failing.
> > > > > > > >
> > > > > > > > We currently allow it to run with the default CA certificate
> > > path, do
> > > > > > > > pre-verification on the server's certificate using those CA
> > > > > certificates,
> > > > > > > > then call our SSL_VERIFY_PEER function where we override the
> > > > > verification
> > > > > > > > result with the certificates from NSS.
> > > > > > >
> > > > > > > Apparently, it is failing before calling our SSL_VER

--with-system-boost breaks build in vcl, --without in configmgr

[Damjan Jovanovic]

loating_point::value)
 ^
/usr/local/include/boost/math/tools/config.hpp:428:67: note: to match this
'('
/usr/local/include/boost/math/tools/config.hpp:320:40: note: expanded from
macro 'BOOST_MATH_NOEXCEPT'
#define BOOST_MATH_NOEXCEPT(T) noexcept(std::is_floating_point::value)
   ^
/usr/local/include/boost/math/tools/config.hpp:436:48: error: expected ';'
at end of declaration
void suppress_unused_variable_warning(const T&) BOOST_MATH_NOEXCEPT(T)
   ^
   ;
/usr/local/include/boost/math/tools/config.hpp:436:69: error: use of
undeclared identifier 'T'
void suppress_unused_variable_warning(const T&) BOOST_MATH_NOEXCEPT(T)
^
/usr/local/include/boost/math/tools/config.hpp:436:49: error: unknown type
name 'noexcept'
void suppress_unused_variable_warning(const T&) BOOST_MATH_NOEXCEPT(T)
^
/usr/local/include/boost/math/tools/config.hpp:320:32: note: expanded from
macro 'BOOST_MATH_NOEXCEPT'
#define BOOST_MATH_NOEXCEPT(T) noexcept(std::is_floating_point::value)
   ^
/usr/local/include/boost/math/tools/config.hpp:436:69: error: use of
undeclared identifier 'T'
void suppress_unused_variable_warning(const T&) BOOST_MATH_NOEXCEPT(T)
^
error: expected unqualified-id
/usr/local/include/boost/math/tools/config.hpp:436:49: error: expected ')'
void suppress_unused_variable_warning(const T&) BOOST_MATH_NOEXCEPT(T)
^
/usr/local/include/boost/math/tools/config.hpp:320:66: note: expanded from
macro 'BOOST_MATH_NOEXCEPT'
#define BOOST_MATH_NOEXCEPT(T) noexcept(std::is_floating_point::value)
 ^
/usr/local/include/boost/math/tools/config.hpp:436:49: note: to match this
'('
/usr/local/include/boost/math/tools/config.hpp:320:40: note: expanded from
macro 'BOOST_MATH_NOEXCEPT'
#define BOOST_MATH_NOEXCEPT(T) noexcept(std::is_floating_point::value)
   ^
/usr/local/include/boost/math/tools/config.hpp:445:11: error: unknown type
name 'constexpr'
   static constexpr bool value = std::is_integral::value ||
(std::numeric_limits::is_specialized &&
std::numeric_limits::is_integer);
  ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
commit 7ea3dd96c0cddf821d2f83199ef817a4fa174040
Author: Damjan Jovanovic 
Date:   Tue Aug 23 02:46:53 2022 +0200

--without-system-boost apparently needs BOOST_NO_CXX11_HDR_TUPLE defined
to compile with Clang, at least on FreeBSD.

Patch by: me

diff --git a/main/boost/boost-clang.patch b/main/boost/boost-clang.patch
new file mode 100644
index 00..564976f690
--- /dev/null
+++ b/main/boost/boost-clang.patch
@@ -0,0 +1,11 @@
+--- misc/build/boost_1_55_0/boost/config/compiler/clang.hpp	2022-08-22 19:00:17.163863000 +0200
 misc/build/boost_1_55_0/boost/config/compiler/clang.hpp	2022-08-22 19:01:04.842941000 +0200
+@@ -168,6 +168,8 @@
+ #  define BOOST_NO_CXX11_INLINE_NAMESPACES
+ #endif
+ 
++#define BOOST_NO_CXX11_HDR_TUPLE
++
+ // Clang always supports variadic macros
+ // Clang always supports extern templates
+ 
diff --git a/main/boost/makefile.mk b/main/boost/makefile.mk
index ae402c982a..89eb6140f3 100644
--- a/main/boost/makefile.mk
+++ b/main/boost/makefile.mk
@@ -50,6 +50,7 @@ PATCH_FILES= $(TARFILE_NAME).patch
 .IF "$(GUI)"=="OS2"
 PATCH_FILES+=boost-os2.patch
 .ENDIF
+PATCH_FILES+=boost-clang.patch
 
 CONFIGURE_DIR=
 CONFIGURE_ACTION=

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

glib >= 2.71.0 breaks the build in the avmedia module (FreeBSD / Linux)

[Damjan Jovanovic]

Hi

Apparently in some recent glib commit, probably
f304df34c7335526ef08701dc0b4a35f03299249 first released in 2.71.0, they
changed a macro in a way that fixes warnings with C, but fails to compile
with stricter C++ compilers (Clang 8, 9, 10, 12 and 13 on FreeBSD, but
probably GCC+Linux too).

This regression causes our build to fails in the "avmedia" module, with
errors of the form:

---snip---
/path/to/openoffice/main/avmedia/source/gstreamer/gstplayer.cxx:417:9:
error: cannot initialize a parameter of type 'gint *' (aka 'int *') with an
rvalue of type 'void *'
g_atomic_int_compare_and_exchange(, 0, 1);
^~~
/usr/local/include/glib-2.0/glib/gatomic.h:171:44: note: expanded from
macro 'g_atomic_int_compare_and_exchange'
__atomic_compare_exchange_n ((atomic), (void *) (&(gaicae_oldval)),
(newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
---snip---


This was semi-fixed in glib by commit
ad23894c1595482cdc10c17a4070a977e396ca4a which was first released in glib
2.73.0. However that doesn't fix the problem for us, as they require:
#if defined(glib_typeof) && defined(__cplusplus) && __cplusplus >= 201103L
while we pass "-std=gnu++98" to the compiler, so the fix is skipped.

An additional problem for Clang is that glib-typeof.h doesn't define
glib_typeof when __cplusplus is defined and the C++ standard isn't
__cplusplus >= 201103L.

I fixed both issues and sent a merge request to glib:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2864

The patch is small and only requires changes to 2 header files, and
applying it to your current system glib header files is enough to fix the
build in avmedia.

Unfortunately at least 2-3 other build breaking bugs still exist :(. The
worst is this boost bug I am still figuring out...

Damjan

Re: [DISCUSS] Fixes for Basic lang in 4.1 line

[Damjan Jovanovic]

On Thu, Jun 9, 2022 at 5:46 PM Carl Marcum  wrote:

> For discussion:
> Should we included these fixes in 4.1.x?
>

The only reason I didn't include them myself, is that back then I expected
4.2.0 to be out soon, and didn't want to waste time backporting to 4.1.x
which was about to be EOL.

Regards
Damjan

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

On Sat, May 28, 2022 at 11:48 AM Arrigo Marchiori 
wrote:

> Hello Damjan,
>
> On Sat, May 28, 2022 at 11:12:45AM +0200, Damjan Jovanovic wrote:
>
> > On Sat, May 28, 2022 at 9:20 AM Arrigo Marchiori  >
> > wrote:
> >
> > > Hello Damjan, all,
> > >
> > > On Fri, May 27, 2022 at 11:27:11PM +0200, Arrigo Marchiori wrote:
> > >
> > > > Hello,
> > > >
> > > > On Fri, May 27, 2022 at 09:46:51PM +0200, Arrigo Marchiori wrote:
> > > >
> > > > > Hello Damjan,
> > > > >
> > > > > On Sun, May 22, 2022 at 06:10:46PM +0200, Damjan Jovanovic wrote:
> > > > >
> > > > > > On Sun, May 22, 2022 at 2:43 PM Arrigo Marchiori
> > > 
> > > > > > wrote:
> > > > > >
> > > > > > > Hello Damjan, all,
> > > > > > >
> > > > > > > On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic
> wrote:
> > > > > > >
> > > > > > > > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski <
> j...@jagunet.com>
> > > wrote:
> > > > > > > >
> > > > > > > > > I'm gonna look into the serf->(lib)curl option... Since we
> > > don't use
> > > > > > > any
> > > > > > > > > of the fancy features of serf, I'm thinking that the easy
> > > option might
> > > > > > > be
> > > > > > > > > best
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > I've ported our WebDAV content provider module from Serf to
> Curl.
> > > > > > >
> > > > > > > I just enhanced the error reporting a bit; I am finding a
> problem
> > > > > > > under Linux and I do not really know how to assess it.
> > > > > > >
> > > > > > > The problem: if we build AOO on CentOS (that is our reference
> > > > > > > platform) then Curl will look for CA certificates in
> > > > > > > /etc/pki/tls/certs/ca-bundle.crt
> > > > > > >
> > > > > > > This will fail on openSUSE and probably on Ubuntu as well.
> > > > > > >
> > > > > > > It seems that the above path is set at configure time and
> embedded
> > > > > > > into Curl's code as #define macros.
> > > > > > >
> > > > > > > Is there an ``official'' way to assess this? Like, can we
> depend on
> > > > > > > NSS' certificate store as you wrote (quoted below)?
> > > > > > >
> > > > > >
> > > > > > Curl/OpenSSL have an enormous number of options and I am pretty
> sure
> > > it can
> > > > > > be fixed, but first I need to understand where and how it's
> failing.
> > > > > >
> > > > > > We currently allow it to run with the default CA certificate
> path, do
> > > > > > pre-verification on the server's certificate using those CA
> > > certificates,
> > > > > > then call our SSL_VERIFY_PEER function where we override the
> > > verification
> > > > > > result with the certificates from NSS.
> > > > >
> > > > > Apparently, it is failing before calling our SSL_VERIFY_PEER
> function.
> > > > >
> > > > > > If it's failing before reaching our SSL_VERIFY_PEER function, we
> > > should be
> > > > > > able to use Curl's CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB
> functions
> > > to set a
> > > > > > custom CA certificate path (or in-memory buffer), maybe even an
> empty
> > > > > > buffer, so that it proceeds further. ("man CURLOPT_CAINFO", "man
> > > > > > CURLOPT_CAINFO_BLOB", or "man curl_easy_setopt" and read under
> the
> > > "SSL and
> > > > > > SECURITY OPTIONS" section.)
> > > > >
> > > > > So we would need to hard-code and try all possible paths to the CA
> > > > > bundle on Unix systems?
> > > > >
> > > > > > With the CURLOPT_CAINFO_BLOB option it might even be possible to
> > > skip the
> > > > > > custo

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

On Sat, May 28, 2022 at 9:20 AM Arrigo Marchiori 
wrote:

> Hello Damjan, all,
>
> On Fri, May 27, 2022 at 11:27:11PM +0200, Arrigo Marchiori wrote:
>
> > Hello,
> >
> > On Fri, May 27, 2022 at 09:46:51PM +0200, Arrigo Marchiori wrote:
> >
> > > Hello Damjan,
> > >
> > > On Sun, May 22, 2022 at 06:10:46PM +0200, Damjan Jovanovic wrote:
> > >
> > > > On Sun, May 22, 2022 at 2:43 PM Arrigo Marchiori
> 
> > > > wrote:
> > > >
> > > > > Hello Damjan, all,
> > > > >
> > > > > On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic wrote:
> > > > >
> > > > > > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski 
> wrote:
> > > > > >
> > > > > > > I'm gonna look into the serf->(lib)curl option... Since we
> don't use
> > > > > any
> > > > > > > of the fancy features of serf, I'm thinking that the easy
> option might
> > > > > be
> > > > > > > best
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > I've ported our WebDAV content provider module from Serf to Curl.
> > > > >
> > > > > I just enhanced the error reporting a bit; I am finding a problem
> > > > > under Linux and I do not really know how to assess it.
> > > > >
> > > > > The problem: if we build AOO on CentOS (that is our reference
> > > > > platform) then Curl will look for CA certificates in
> > > > > /etc/pki/tls/certs/ca-bundle.crt
> > > > >
> > > > > This will fail on openSUSE and probably on Ubuntu as well.
> > > > >
> > > > > It seems that the above path is set at configure time and embedded
> > > > > into Curl's code as #define macros.
> > > > >
> > > > > Is there an ``official'' way to assess this? Like, can we depend on
> > > > > NSS' certificate store as you wrote (quoted below)?
> > > > >
> > > >
> > > > Curl/OpenSSL have an enormous number of options and I am pretty sure
> it can
> > > > be fixed, but first I need to understand where and how it's failing.
> > > >
> > > > We currently allow it to run with the default CA certificate path, do
> > > > pre-verification on the server's certificate using those CA
> certificates,
> > > > then call our SSL_VERIFY_PEER function where we override the
> verification
> > > > result with the certificates from NSS.
> > >
> > > Apparently, it is failing before calling our SSL_VERIFY_PEER function.
> > >
> > > > If it's failing before reaching our SSL_VERIFY_PEER function, we
> should be
> > > > able to use Curl's CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB functions
> to set a
> > > > custom CA certificate path (or in-memory buffer), maybe even an empty
> > > > buffer, so that it proceeds further. ("man CURLOPT_CAINFO", "man
> > > > CURLOPT_CAINFO_BLOB", or "man curl_easy_setopt" and read under the
> "SSL and
> > > > SECURITY OPTIONS" section.)
> > >
> > > So we would need to hard-code and try all possible paths to the CA
> > > bundle on Unix systems?
> > >
> > > > With the CURLOPT_CAINFO_BLOB option it might even be possible to
> skip the
> > > > custom certificate verification we do later, and pre-populate
> Curl/OpenSSL
> > > > with NSS certificates from the beginning, I just don't know enough
> about
> > > > NSS to rely on that (eg. if you are using a cryptographic device or
> smart
> > > > card in NSS, how does that work?). If that option is ok, then we
> might not
> > > > even need the NSS libraries: recent versions of NSS store all the
> > > > certificates in an SQLite database, which can be accessed with
> SQLite APIs
> > > > directly, no need to build with or ship the NSS libraries at all.
> > >
> > > If I understood correctly [1], a NSS-linked Curl would query NSS by
> > > itself... are we not in this condition?
> [...]
> >   1: https://curl.se/libcurl/c/CURLOPT_CAINFO.html
>
> Apparently, we are not. If we force CURLOPT_CAINFO and CURLOPT_CAPATH
> to be NULL, we get a bit further but eventually Curl aborts because
> validateServerX509Certificate fails.
>
> Here is the log for check

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

On Fri, May 27, 2022 at 9:47 PM Arrigo Marchiori 
wrote:

> Hello Damjan,
>
> On Sun, May 22, 2022 at 06:10:46PM +0200, Damjan Jovanovic wrote:
>
> > On Sun, May 22, 2022 at 2:43 PM Arrigo Marchiori  >
> > wrote:
> >
> > > Hello Damjan, all,
> > >
> > > On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic wrote:
> > >
> > > > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski 
> wrote:
> > > >
> > > > > I'm gonna look into the serf->(lib)curl option... Since we don't
> use
> > > any
> > > > > of the fancy features of serf, I'm thinking that the easy option
> might
> > > be
> > > > > best
> > > >
> > > >
> > > >
> > > > Hi
> > > >
> > > > I've ported our WebDAV content provider module from Serf to Curl.
> > >
> > > I just enhanced the error reporting a bit; I am finding a problem
> > > under Linux and I do not really know how to assess it.
> > >
> > > The problem: if we build AOO on CentOS (that is our reference
> > > platform) then Curl will look for CA certificates in
> > > /etc/pki/tls/certs/ca-bundle.crt
> > >
> > > This will fail on openSUSE and probably on Ubuntu as well.
> > >
> > > It seems that the above path is set at configure time and embedded
> > > into Curl's code as #define macros.
> > >
> > > Is there an ``official'' way to assess this? Like, can we depend on
> > > NSS' certificate store as you wrote (quoted below)?
> > >
> >
> > Curl/OpenSSL have an enormous number of options and I am pretty sure it
> can
> > be fixed, but first I need to understand where and how it's failing.
> >
> > We currently allow it to run with the default CA certificate path, do
> > pre-verification on the server's certificate using those CA certificates,
> > then call our SSL_VERIFY_PEER function where we override the verification
> > result with the certificates from NSS.
>
> Apparently, it is failing before calling our SSL_VERIFY_PEER function.
>
> > If it's failing before reaching our SSL_VERIFY_PEER function, we should
> be
> > able to use Curl's CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB functions to
> set a
> > custom CA certificate path (or in-memory buffer), maybe even an empty
> > buffer, so that it proceeds further. ("man CURLOPT_CAINFO", "man
> > CURLOPT_CAINFO_BLOB", or "man curl_easy_setopt" and read under the "SSL
> and
> > SECURITY OPTIONS" section.)
>
> So we would need to hard-code and try all possible paths to the CA
> bundle on Unix systems?
>
> > With the CURLOPT_CAINFO_BLOB option it might even be possible to skip the
> > custom certificate verification we do later, and pre-populate
> Curl/OpenSSL
> > with NSS certificates from the beginning, I just don't know enough about
> > NSS to rely on that (eg. if you are using a cryptographic device or smart
> > card in NSS, how does that work?). If that option is ok, then we might
> not
> > even need the NSS libraries: recent versions of NSS store all the
> > certificates in an SQLite database, which can be accessed with SQLite
> APIs
> > directly, no need to build with or ship the NSS libraries at all.
>
> If I understood correctly [1], a NSS-linked Curl would query NSS by
> itself... are we not in this condition?
>

Yes but NSS is category B, shouldn't we be avoiding it?

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

On Sun, May 22, 2022 at 2:43 PM Arrigo Marchiori 
wrote:

> Hello Damjan, all,
>
> On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic wrote:
>
> > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski  wrote:
> >
> > > I'm gonna look into the serf->(lib)curl option... Since we don't use
> any
> > > of the fancy features of serf, I'm thinking that the easy option might
> be
> > > best
> >
> >
> >
> > Hi
> >
> > I've ported our WebDAV content provider module from Serf to Curl.
>
> I just enhanced the error reporting a bit; I am finding a problem
> under Linux and I do not really know how to assess it.
>
> The problem: if we build AOO on CentOS (that is our reference
> platform) then Curl will look for CA certificates in
> /etc/pki/tls/certs/ca-bundle.crt
>
> This will fail on openSUSE and probably on Ubuntu as well.
>
> It seems that the above path is set at configure time and embedded
> into Curl's code as #define macros.
>
> Is there an ``official'' way to assess this? Like, can we depend on
> NSS' certificate store as you wrote (quoted below)?
>

Curl/OpenSSL have an enormous number of options and I am pretty sure it can
be fixed, but first I need to understand where and how it's failing.

We currently allow it to run with the default CA certificate path, do
pre-verification on the server's certificate using those CA certificates,
then call our SSL_VERIFY_PEER function where we override the verification
result with the certificates from NSS.

If it's failing before reaching our SSL_VERIFY_PEER function, we should be
able to use Curl's CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB functions to set a
custom CA certificate path (or in-memory buffer), maybe even an empty
buffer, so that it proceeds further. ("man CURLOPT_CAINFO", "man
CURLOPT_CAINFO_BLOB", or "man curl_easy_setopt" and read under the "SSL and
SECURITY OPTIONS" section.)

With the CURLOPT_CAINFO_BLOB option it might even be possible to skip the
custom certificate verification we do later, and pre-populate Curl/OpenSSL
with NSS certificates from the beginning, I just don't know enough about
NSS to rely on that (eg. if you are using a cryptographic device or smart
card in NSS, how does that work?). If that option is ok, then we might not
even need the NSS libraries: recent versions of NSS store all the
certificates in an SQLite database, which can be accessed with SQLite APIs
directly, no need to build with or ship the NSS libraries at all.

I am planning to write a separate email, when I get a chance, about the
cryptography libraries and certificates story.

Regards
Damjan

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

On Sun, May 15, 2022 at 3:57 PM Arrigo Marchiori 
wrote:

> Dear All,
>
> On Thu, May 12, 2022 at 07:36:49PM +0200, Arrigo Marchiori wrote:
>
> > Dear all,
> >
> > if nobody objects, I will merge this PR during the week-end.
> >
> > Reference: https://github.com/apache/openoffice/pull/146
>
> Done.
>
> Thank you again, Damjan!
>

It's a pleasure :).

The next library to update could be zlib, because this version of curl
> does _not_ compile with the bundled zlib.
>

I distinctly recall that zlib and curl compiled for me on Windows. Where
and how is it failing for you?

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

On Thu, Apr 28, 2022 at 8:46 PM Arrigo Marchiori 
wrote:

> Hello Damjan,
>
> On Thu, Apr 28, 2022 at 06:53:43PM +0200, Damjan Jovanovic wrote:
>
> > On Thu, Apr 28, 2022 at 6:12 PM Arrigo Marchiori  >
> > wrote:
> >
> > > Dear Damjan, All,
> > >
> > > On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic wrote:
> > >
> > > > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski 
> wrote:
> > > >
> > > > > I'm gonna look into the serf->(lib)curl option... Since we don't
> use
> > > any
> > > > > of the fancy features of serf, I'm thinking that the easy option
> might
> > > be
> > > > > best
> > > >
> > > >
> > > >
> > > > Hi
> > > >
> > > > I've ported our WebDAV content provider module from Serf to Curl.
> > >
> > > Binary for Linux available here for download:
> > >
> > >
> https://home.apache.org/~ardovm/openoffice/linux/openoffice4-serf2curl-2022-04-28-installed.tar.bz2
> > >
> > > I understand from your previous message that you don't really like
> > > GitHub, so I am writing here.
> > >
> > > [...]
> > > > STATUS
> > > >
> > > > It builds and works well on FreeBSD and Windows.
> > > >
> > > > Most of the code was reused, and all the operations and semantics
> > > > previously present with Serf, should have been preserved.
> > > >
> > > > Browsing WebDAV files and directories, loading files, overwriting
> them
> > > > ("Save"), creating them ("Save As"), renaming and deleting them, all
> > > works.
> > >
> > > I am testing the binary for Linux linked above.
> > >
> > > I tried "Open" and entered a https address, that I know is password
> > > protected.
> > >
> > > The current trunk would ask for the password. I got an error message
> > > instead:
> > >
> > > > > Nonexistent object.
> > > > > Nonexistent file.
> > >
> > > The address I tried to open is in the form https://host.domain:port/
> > >
> > > I tried to substitute "https" with "davs" and I got the same error.
> > >
> > > Maybe something is going wrong in the Linux build?
> > >
> > > I will now begin recompiling with debugging symbols enabled. Please
> > > let me know how I can help.
> > >
> >
> > That's not good :(.
> >
> > Set your macro security to "Medium", open the spreadsheet I've attached,
> > and run the "RunMe" Basic macro. That should enable logging to the
> console
> > at the finest level of detail. Then exit and re-run AOO like this:
> > soffice 2>&1 | tee /tmp/log.txt
> > and examine the console output interactively as you use AOO, and/or check
> > the log file afterwards. It should have everything, our logging, HTTP
> > request and response headers and bodies, Curl's internal logging.
>
> I can't get to that point.
>
> I fired gdb and it seems that I end up into the blind
>   catch (Exception const &)
> block in file ucb/source/core/provprox.cxx:361
>
> Method UcbContentProviderProxy::getContentProvider() in fact is called
> many times, but it only fails when I enter the https url in the "Open"
> dialog box and press ENTER.
>
> Sorry this is all the debugging I can do for today. I hope it helps.
>
>
When I run your Linux binaries, I also get that error.

One problem is libcurl -> openssl.

"ldd ./libcurl.so" shows:
libssl.so.10 => not found
libcrypto.so.10 => not found

When I rename AOO's libcurl.so so that it's forced to use my system libcurl
instead, it proceeds further, but runs into another problem:

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x0001 in ?? ()
(gdb) bt
#0  0x0001 in ?? ()
#1  0x7fffd6d52a76 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#2  0x7fffd6d52f75 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#3  0x7fffd6d8505d in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#4  0x7fffd6d7c37e in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#5  0x7fffd6d67d98 in SSL_do_handshake () from
/lib/x86_64-linux-gnu/libssl.so.1.1
#6  0x7fffe4154e40 in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4
#7  0x7fffe41571a2 in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4
#8  0x7fffe415814f in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4
#9  0x7fffe4103296 in ?? () from /lib/x86