[QA AUTOMATION] Standalone Tests now available in standalone-test branch

[Carl Marcum]

Hi All,

cc: dev@

Just an FYI on the status of my work on allowing the automated test 
suites to compile and run tests without a working AOO build environment.
I've started a new branch standalone-test [1] with a README file 
explaining the usage.


So far I've been able to run tests on CentOS 7 and Windows 10.
It would be great if others could try other platforms as well.

All that's required is Ant and Java.
I should probably add that to the README somewhere :)

I'd also like feedback on if this causes any unintended consequences for 
those that may use the tests as they are today.


Again, the big difference is current trunk, AOO41X, AOO42X, etc tests 
require having first ran a build and the test compile had dependencies 
on the Java UNO jars and tools like javamaker, regmerge, and idlc where 
I've changed this branch to use the office to be tested for the 
dependencies.
This also means it requires a SDK be installed in the office under 
test's root directory.
I think this is a good trade off that allows more people to run tests 
and work on them also.


This and more is in the test/README.

Please let me know if you have any questions or trouble testing.

[1] https://github.com/cbmarcum/openoffice/tree/standalone-test/test

Thanks,
Carl


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

[GitHub] [openoffice] cbmarcum merged pull request #137: Add README for using standalone automated tests

[GitBox]

cbmarcum merged pull request #137:
URL: https://github.com/apache/openoffice/pull/137


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Future - Digital Signatures

[Dave Fisher]

Sent from my iPhone

> On Sep 29, 2021, at 4:42 PM, Regina Henschel  wrote:
> 
> Hi Dave,
> 
> Dave Fisher schrieb am 30.09.2021 um 00:11:
>> This document was not signed using the ODF 1.2 or 1.3 specification. Instead 
>> LO implements its own extension.
>> PGPData 
>> xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0”
> 
> Which version of LibreOffice? For ODF 1.3 you need LibreOffice 7.0, some 
> additions are in 7.1 and 7.2.

Pedro used LO 6.4.7.

I need to inspect an LO 7.2 PGP signed odt.
> 
>> This replaces X509Data when PGP signing is done in LO. I wonder if we can 
>> implement this without looking at their code.
> 
> I don't know whether signatures use the same as OpenPGP encryption. But 
> Thorsten Behrens told me, that LibreOffice uses the gpgme library and that it 
> needs to be included in the distribution at least on Windows and Mac. But 
> gpgme has LGPLv2+ license. So I think, use of LibreOffice's solution is not 
> possible for Apache OpenOffice.

That approach would require an extension provided by a 3rd party or an 
exception to Apache Release Policy.

BouncyCastle/Java could be an alternative as well.

Regards,
Dave


> 
> Kind regards
> Regina
> 
> -
> 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: Future - Digital Signatures

[Regina Henschel]

Hi Dave,

Dave Fisher schrieb am 30.09.2021 um 00:11:

This document was not signed using the ODF 1.2 or 1.3 specification. Instead LO 
implements its own extension.

PGPData 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0”


Which version of LibreOffice? For ODF 1.3 you need LibreOffice 7.0, some 
additions are in 7.1 and 7.2.




This replaces X509Data when PGP signing is done in LO. I wonder if we can 
implement this without looking at their code.


I don't know whether signatures use the same as OpenPGP encryption. But 
Thorsten Behrens told me, that LibreOffice uses the gpgme library and 
that it needs to be included in the distribution at least on Windows and 
Mac. But gpgme has LGPLv2+ license. So I think, use of LibreOffice's 
solution is not possible for Apache OpenOffice.


Kind regards
Regina

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

Re: Future - Digital Signatures

[Dave Fisher]

> On Sep 29, 2021, at 9:10 AM, Dave Fisher  wrote:
> 
> 
> 
>> On Sep 29, 2021, at 8:59 AM, Pedro Lino  
>> wrote:
>> 
>> Hi Dave
>> 
>>> On 09/28/2021 11:35 PM Dave Fisher  wrote:
>> 
>>> I think that AOO42X and Trunk need to improve in three ways.
>>> 
>>> (1) We need to make sure that we hook to the systems native key store 
>>> and/or a Mozilla keystone.
>>> Setup may need to be improved.
>>> (2) We need to allow a PGP and EU card key to be selected and converted to 
>>> X509 internally while signing.
>>> It looks like ODF 1.3 spec makes no changes to ODF 1.2 in terms of 
>>> digital signatures.
>>> (3) We need to properly display whatever signatures are on the document.
>> 
>> I agree. It is good news that ODF 1.2 supports signatures (although it would 
>> be ideal for AOO to move on to ODF 1.3)
> 
> To be clear ODF 1.3 has the same spec as 1.2 for digital signatures.
> 
>> 
>>> What happens when you inspect the digital signatures of a file signed in LO 
>>> with PGP and EU card in AOO 4.1.11 RC?
>> 
>> Document signed with OpenPGP using LO 6.4.7 in Ubuntu 18.04 x64
>> - opening with AOO 4.1.11 on the same Ubuntu 18.04 x64 the message is 
>> "Digital Signature: The document signature does not match the document 
>> content. We strongly recommend you to not trust this document."
>> - opening with 4.1.11 on Windows 7 Pro x64 the message is the same but there 
>> is a popup window when the document is opened with a serious warning
>> https://i.imgur.com/8CloLVl.png

Thanks for sharing the files.

This document was not signed using the ODF 1.2 or 1.3 specification. Instead LO 
implements its own extension.

PGPData 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0”

This replaces X509Data when PGP signing is done in LO. I wonder if we can 
implement this without looking at their code.

Regards,
Dave

>> 
>> Document signed with OpenPGP using AOO 4.1.11 in Win7 Pro x64
>> - opening with AOO 4.1.11 on Ubuntu 18.04 x64 the message is "Digital 
>> Signature: The document signature is OK, but the certificates could not be 
>> validated."
>> 
>> Document signed with EU card
>> - opening with AOO 4.1.11 on Ubuntu 18.04 x64 the message is "Digital 
>> Signature: The document signature is OK, but the certificates could not be 
>> validated."
>> - opening with AOO 4.1.11 on Windows 7 Pro x64 (where I have installed the 
>> Root certificate for my ID card), the message is "The document signature is 
>> OK". If another ID card is used to sign (and the Root certificate for that 
>> card is not imported) then the message is the same as under Ubuntu.
>> 
>> I can share the documents with you by personal email if that helps.
> 
> Sure, I’d like to unzip them and inspect the signature xml.
> 
> Regards,
> Dave
> 
>> 
>> Regards,
>> 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
> 


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

Re: Future - Digital Signatures

[Dave Fisher]

> On Sep 29, 2021, at 1:05 PM, Arrigo Marchiori  wrote:
> 
> Hello Dave, All,
> 
> On Tue, Sep 28, 2021 at 03:35:30PM -0700, Dave Fisher wrote:
> 
>> Hi Pedro,
>> 
>> I think that AOO42X and Trunk need to improve in three ways.
>> 
>> (1) We need to make sure that we hook to the systems native key store and/or 
>> a Mozilla keystone.
>>  Setup may need to be improved.
>> (2) We need to allow a PGP and EU card key to be selected and converted to 
>> X509 internally while signing.
>>  It looks like ODF 1.3 spec makes no changes to ODF 1.2 in terms of 
>> digital signatures.
>> (3) We need to properly display whatever signatures are on the document.
>> 
>> What happens when you inspect the digital signatures of a file signed in LO 
>> with PGP and EU card in AOO 4.1.11 RC?
> 
> Please let us bear in mind that we have an open pull request [1] about
> upgrading the nss library. It is currently waiting for review, and it
> is stuck on macOS.

We need to know from Jim how a build goes with the PR incorporated in AOO42X.

> 
> Before we begin editing our code, I suggest we merge that pull request
> first.
> 
> 1: https://github.com/apache/openoffice/pull/100

Maybe merge there and see how the next dev build goes?

Regards,
Dave

> 
> Best regards,
> -- 
> Arrigo
> 
> -
> 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: Future - Digital Signatures

[Arrigo Marchiori]

Hello Dave, All,

On Tue, Sep 28, 2021 at 03:35:30PM -0700, Dave Fisher wrote:

> Hi Pedro,
> 
> I think that AOO42X and Trunk need to improve in three ways.
> 
> (1) We need to make sure that we hook to the systems native key store and/or 
> a Mozilla keystone.
>   Setup may need to be improved.
> (2) We need to allow a PGP and EU card key to be selected and converted to 
> X509 internally while signing.
>   It looks like ODF 1.3 spec makes no changes to ODF 1.2 in terms of 
> digital signatures.
> (3) We need to properly display whatever signatures are on the document.
> 
> What happens when you inspect the digital signatures of a file signed in LO 
> with PGP and EU card in AOO 4.1.11 RC?

Please let us bear in mind that we have an open pull request [1] about
upgrading the nss library. It is currently waiting for review, and it
is stuck on macOS.

Before we begin editing our code, I suggest we merge that pull request
first.

1: https://github.com/apache/openoffice/pull/100

Best regards,
-- 
Arrigo

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

Ad runtime jar files (unoinfo java)

[Rony G. Flatscher]

The CLASSPATH environment variable or -cp switch needs to contain the output of 
"unoinfo java" which
usually consists of  the following fully qualified directories to point to the 
following files: 
unoil.jar, ridl.jar, jurt.jar and juh.jar.

LibreOffice combines these four jar files into a single jar file (I think 
libreoffice.jar) which
simplifies/shortens the CLASSPATH string considerably. Would this be something 
to be considered for
AOO as well (e.g. combining the four jar files into a single openoffice.jar)?

---rony



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

Re: AOO41X: Time for RC1?

[Rony G. Flatscher]

On 29.09.2021 17:16, Dave Fisher wrote:
> Does the behavior change if you use the Terminal window to explicitly set the 
> environment and then `open -a OpenOffice`?

What environment variables should I change how to which value(s) (it seems that 
DYLD_ environment
variables seem to get purged [1]) ?

> I had to do that in Catalina to access a Mozzila keystore.

---rony

[1] "Runtime Protections":



> On Sep 29, 2021, at 8:03 AM, Rony G. Flatscher  
> wrote:
>> On 28.09.2021 22:25, Jim Jagielski wrote:
>>> Is this a regression?
>> Not really sure, it used to work on AOO 4.1.10 AFAICR, but now, testing 
>> against 4.1.10 the same
>> problem occurs, although java.library.path has a different value compared to 
>> 4.1.11:
>>
>>
>> java.library.path=[.:/Users/rony/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
>>
>>java.runtime.version=[9.0.4+11]
>>
>> However, I did update the operating system in between which now is macOS Big 
>> Sur 11.6.
>>
>> My (pure!) speculation is, that dlopen() on BigSur does not honor 
>> DYLD_FALLBACK_LIBRARY_PATH which
>> includes ~/lib:/usr/local/lib:/usr/lib, cf. [1], [2].
>>
>> However, "man dlopen" would document that if DYLD_FALLBACK_LIBRARY_PATH was 
>> not set, then dlopen
>> operates as if this environment variable was set to 
>> $HOME/lib:/usr/local/lib:/usr/lib. If that was
>> the case then libBSF4ooRexx.dylib would be found as it is in /usr/local/lib, 
>> but it is not (hence
>> speculating).
>>
>> So maybe these libraries should be explicitly added to the java.library.path 
>> on Darwin to have
>> System.loadLibrary(name) look through them.
>>
>> ---rony
>>
>> [1]  "Using Dynamic Libraries":
>> 
>>
>> [2] Manpage for dlopen(3):
>> 
>>
>>
 On Sep 28, 2021, at 1:36 PM, Rony G. Flatscher  
 wrote:

 Tested the MacOS version and ran into a problem: AOO does not consult 
 "/usr/local/lib" on MacOS when
 loading a native library.  Also, on "java.library.path" there seems to be 
 a wrong directory
 ("/Applications/OpenOffice.app/Contents").

 The setting of "java.library.path" in effect:

   
 java.library.path=[/Applications/OpenOffice.app/Contents:/Users/rony/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]

   java.runtime.version=[9.0.4+11]

 Placing a symbolic link into "/Applications/OpenOffice.app/Contents" 
 allows the library
 "libBSF4ooRexx.dylib" to be found in this version (and everything then 
 works as expected), however
 that directory should probably not be defined as it is does not contain 
 any native libraries (rather
 its subdirectory MacOS does).

 So, this version does not consult "/usr/local/lib" to find and load 
 "libBSF4ooRexx.dylib".

 ---rony

 P.S.: Here the relevant stack trace (when attempting to load the scripting 
 engine for ooRexx to run
 an AOO macro via the Tools -> Macros menu):

   Caused by: java.lang.UnsatisfiedLinkError: no BSF4ooRexx in 
 java.library.path
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2541)
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
at java.base/java.lang.System.loadLibrary(System.java:1857)
at 
 org.rexxla.bsf.engines.rexx.RexxAndJava.(RexxAndJava.java:880)
at 
 org.rexxla.bsf.engines.rexx.RexxEngine.initialize(RexxEngine.java:291)
at org.apache.bsf.BSFManager$8.run(BSFManager.java:854)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.apache.bsf.BSFManager.loadScriptingEngine(BSFManager.java:852)
... 40 more


 On 27.09.2021 21:21, Jim Jagielski wrote:
> The macOS, Linux64 and Linux32 builds are also there!
>
>> On Sep 23, 2021, at 9:48 AM, Matthias Seidel 
>>  wrote:
>>
>> Hi all,
>>
>> I have uploaded all Windows binaries to:
>>
>> https://dist.apache.org/repos/dist/dev/openoffice/4.1.11-RC1/binaries/
>>
>> Although we have not yet announced AOO 4.1.11-RC1 officially please feel
>> free to download and test them!
>>
>> Regards,
>>
>>  Matthias
>>
>> P.S.: Linux/macOS builds will be uploaded next week
>>
>> Am 22.09.21 um 17:33 schrieb Matthias Seidel:
>>> Hi all,
>>>
>>> I would be ready to upload the Windows binaries if we want to announce 
>>> 

Re: Future - Digital Signatures

[Dave Fisher]

> On Sep 29, 2021, at 8:59 AM, Pedro Lino  
> wrote:
> 
> Hi Dave
> 
>> On 09/28/2021 11:35 PM Dave Fisher  wrote:
> 
>> I think that AOO42X and Trunk need to improve in three ways.
>> 
>> (1) We need to make sure that we hook to the systems native key store and/or 
>> a Mozilla keystone.
>>  Setup may need to be improved.
>> (2) We need to allow a PGP and EU card key to be selected and converted to 
>> X509 internally while signing.
>>  It looks like ODF 1.3 spec makes no changes to ODF 1.2 in terms of 
>> digital signatures.
>> (3) We need to properly display whatever signatures are on the document.
> 
> I agree. It is good news that ODF 1.2 supports signatures (although it would 
> be ideal for AOO to move on to ODF 1.3)

To be clear ODF 1.3 has the same spec as 1.2 for digital signatures.

> 
>> What happens when you inspect the digital signatures of a file signed in LO 
>> with PGP and EU card in AOO 4.1.11 RC?
> 
> Document signed with OpenPGP using LO 6.4.7 in Ubuntu 18.04 x64
> - opening with AOO 4.1.11 on the same Ubuntu 18.04 x64 the message is 
> "Digital Signature: The document signature does not match the document 
> content. We strongly recommend you to not trust this document."
> - opening with 4.1.11 on Windows 7 Pro x64 the message is the same but there 
> is a popup window when the document is opened with a serious warning
> https://i.imgur.com/8CloLVl.png
> 
> Document signed with OpenPGP using AOO 4.1.11 in Win7 Pro x64
> - opening with AOO 4.1.11 on Ubuntu 18.04 x64 the message is "Digital 
> Signature: The document signature is OK, but the certificates could not be 
> validated."
> 
> Document signed with EU card
> - opening with AOO 4.1.11 on Ubuntu 18.04 x64 the message is "Digital 
> Signature: The document signature is OK, but the certificates could not be 
> validated."
> - opening with AOO 4.1.11 on Windows 7 Pro x64 (where I have installed the 
> Root certificate for my ID card), the message is "The document signature is 
> OK". If another ID card is used to sign (and the Root certificate for that 
> card is not imported) then the message is the same as under Ubuntu.
> 
> I can share the documents with you by personal email if that helps.

Sure, I’d like to unzip them and inspect the signature xml.

Regards,
Dave

> 
> Regards,
> 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

Re: Future - Digital Signatures

[Pedro Lino]

Hi Dave

> On 09/28/2021 11:35 PM Dave Fisher  wrote:

> I think that AOO42X and Trunk need to improve in three ways.
> 
> (1) We need to make sure that we hook to the systems native key store and/or 
> a Mozilla keystone.
>   Setup may need to be improved.
> (2) We need to allow a PGP and EU card key to be selected and converted to 
> X509 internally while signing.
>   It looks like ODF 1.3 spec makes no changes to ODF 1.2 in terms of 
> digital signatures.
> (3) We need to properly display whatever signatures are on the document.

I agree. It is good news that ODF 1.2 supports signatures (although it would be 
ideal for AOO to move on to ODF 1.3)
 
> What happens when you inspect the digital signatures of a file signed in LO 
> with PGP and EU card in AOO 4.1.11 RC?

Document signed with OpenPGP using LO 6.4.7 in Ubuntu 18.04 x64
- opening with AOO 4.1.11 on the same Ubuntu 18.04 x64 the message is "Digital 
Signature: The document signature does not match the document content. We 
strongly recommend you to not trust this document."
- opening with 4.1.11 on Windows 7 Pro x64 the message is the same but there is 
a popup window when the document is opened with a serious warning
https://i.imgur.com/8CloLVl.png

Document signed with OpenPGP using AOO 4.1.11 in Win7 Pro x64
- opening with AOO 4.1.11 on Ubuntu 18.04 x64 the message is "Digital 
Signature: The document signature is OK, but the certificates could not be 
validated."

Document signed with EU card
- opening with AOO 4.1.11 on Ubuntu 18.04 x64 the message is "Digital 
Signature: The document signature is OK, but the certificates could not be 
validated."
- opening with AOO 4.1.11 on Windows 7 Pro x64 (where I have installed the Root 
certificate for my ID card), the message is "The document signature is OK". If 
another ID card is used to sign (and the Root certificate for that card is not 
imported) then the message is the same as under Ubuntu.

I can share the documents with you by personal email if that helps.

Regards,
Pedro

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

Re: AOO41X: Time for RC1?

[Dave Fisher]

Does the behavior change if you use the Terminal window to explicitly set the 
environment and then `open -a OpenOffice`?

I had to do that in Catalina to access a Mozzila keystore.

> On Sep 29, 2021, at 8:03 AM, Rony G. Flatscher  
> wrote:
> 
> On 28.09.2021 22:25, Jim Jagielski wrote:
>> Is this a regression?
> 
> Not really sure, it used to work on AOO 4.1.10 AFAICR, but now, testing 
> against 4.1.10 the same
> problem occurs, although java.library.path has a different value compared to 
> 4.1.11:
> 
>
> java.library.path=[.:/Users/rony/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
> 
>java.runtime.version=[9.0.4+11]
> 
> However, I did update the operating system in between which now is macOS Big 
> Sur 11.6.
> 
> My (pure!) speculation is, that dlopen() on BigSur does not honor 
> DYLD_FALLBACK_LIBRARY_PATH which
> includes ~/lib:/usr/local/lib:/usr/lib, cf. [1], [2].
> 
> However, "man dlopen" would document that if DYLD_FALLBACK_LIBRARY_PATH was 
> not set, then dlopen
> operates as if this environment variable was set to 
> $HOME/lib:/usr/local/lib:/usr/lib. If that was
> the case then libBSF4ooRexx.dylib would be found as it is in /usr/local/lib, 
> but it is not (hence
> speculating).
> 
> So maybe these libraries should be explicitly added to the java.library.path 
> on Darwin to have
> System.loadLibrary(name) look through them.
> 
> ---rony
> 
> [1]  "Using Dynamic Libraries":
> 
> 
> [2] Manpage for dlopen(3):
> 
> 
> 
>> 
>>> On Sep 28, 2021, at 1:36 PM, Rony G. Flatscher  
>>> wrote:
>>> 
>>> Tested the MacOS version and ran into a problem: AOO does not consult 
>>> "/usr/local/lib" on MacOS when
>>> loading a native library.  Also, on "java.library.path" there seems to be a 
>>> wrong directory
>>> ("/Applications/OpenOffice.app/Contents").
>>> 
>>> The setting of "java.library.path" in effect:
>>> 
>>>   
>>> java.library.path=[/Applications/OpenOffice.app/Contents:/Users/rony/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
>>> 
>>>   java.runtime.version=[9.0.4+11]
>>> 
>>> Placing a symbolic link into "/Applications/OpenOffice.app/Contents" allows 
>>> the library
>>> "libBSF4ooRexx.dylib" to be found in this version (and everything then 
>>> works as expected), however
>>> that directory should probably not be defined as it is does not contain any 
>>> native libraries (rather
>>> its subdirectory MacOS does).
>>> 
>>> So, this version does not consult "/usr/local/lib" to find and load 
>>> "libBSF4ooRexx.dylib".
>>> 
>>> ---rony
>>> 
>>> P.S.: Here the relevant stack trace (when attempting to load the scripting 
>>> engine for ooRexx to run
>>> an AOO macro via the Tools -> Macros menu):
>>> 
>>>   Caused by: java.lang.UnsatisfiedLinkError: no BSF4ooRexx in 
>>> java.library.path
>>> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2541)
>>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
>>> at java.base/java.lang.System.loadLibrary(System.java:1857)
>>> at 
>>> org.rexxla.bsf.engines.rexx.RexxAndJava.(RexxAndJava.java:880)
>>> at 
>>> org.rexxla.bsf.engines.rexx.RexxEngine.initialize(RexxEngine.java:291)
>>> at org.apache.bsf.BSFManager$8.run(BSFManager.java:854)
>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>> at org.apache.bsf.BSFManager.loadScriptingEngine(BSFManager.java:852)
>>> ... 40 more
>>> 
>>> 
>>> On 27.09.2021 21:21, Jim Jagielski wrote:
 The macOS, Linux64 and Linux32 builds are also there!
 
> On Sep 23, 2021, at 9:48 AM, Matthias Seidel  
> wrote:
> 
> Hi all,
> 
> I have uploaded all Windows binaries to:
> 
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.11-RC1/binaries/
> 
> Although we have not yet announced AOO 4.1.11-RC1 officially please feel
> free to download and test them!
> 
> Regards,
> 
>  Matthias
> 
> P.S.: Linux/macOS builds will be uploaded next week
> 
> Am 22.09.21 um 17:33 schrieb Matthias Seidel:
>> Hi all,
>> 
>> I would be ready to upload the Windows binaries if we want to announce 
>> RC1?
>> 
>> Regards,
>> 
>>  Matthias
>> 
>> Am 21.09.21 um 23:15 schrieb Matthias Seidel:
>>> Hi all,
>>> 
>>> Am 21.09.21 um 22:42 schrieb Pedro Lino:
 Hi Dave, all
 
 
> On 09/21/2021 9:07 PM Dave Fisher  wrote:
> windows - thanks Matthias
> https://www.dropbox.com/s/912galt8kr7wiem/Apache_OpenOffice_4.1.11_Win_x86_install_en-US.exe?dl=0
 

Re: AOO41X: Time for RC1?

[Rony G. Flatscher]

On 28.09.2021 22:25, Jim Jagielski wrote:
> Is this a regression?

Not really sure, it used to work on AOO 4.1.10 AFAICR, but now, testing against 
4.1.10 the same
problem occurs, although java.library.path has a different value compared to 
4.1.11:


java.library.path=[.:/Users/rony/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]

java.runtime.version=[9.0.4+11]

However, I did update the operating system in between which now is macOS Big 
Sur 11.6.

My (pure!) speculation is, that dlopen() on BigSur does not honor 
DYLD_FALLBACK_LIBRARY_PATH which
includes ~/lib:/usr/local/lib:/usr/lib, cf. [1], [2].

However, "man dlopen" would document that if DYLD_FALLBACK_LIBRARY_PATH was not 
set, then dlopen
operates as if this environment variable was set to 
$HOME/lib:/usr/local/lib:/usr/lib. If that was
the case then libBSF4ooRexx.dylib would be found as it is in /usr/local/lib, 
but it is not (hence
speculating).

So maybe these libraries should be explicitly added to the java.library.path on 
Darwin to have
System.loadLibrary(name) look through them.

---rony

[1]  "Using Dynamic Libraries":


[2] Manpage for dlopen(3):



>
>> On Sep 28, 2021, at 1:36 PM, Rony G. Flatscher  
>> wrote:
>>
>> Tested the MacOS version and ran into a problem: AOO does not consult 
>> "/usr/local/lib" on MacOS when
>> loading a native library.  Also, on "java.library.path" there seems to be a 
>> wrong directory
>> ("/Applications/OpenOffice.app/Contents").
>>
>> The setting of "java.library.path" in effect:
>>
>>
>> java.library.path=[/Applications/OpenOffice.app/Contents:/Users/rony/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
>>
>>java.runtime.version=[9.0.4+11]
>>
>> Placing a symbolic link into "/Applications/OpenOffice.app/Contents" allows 
>> the library
>> "libBSF4ooRexx.dylib" to be found in this version (and everything then works 
>> as expected), however
>> that directory should probably not be defined as it is does not contain any 
>> native libraries (rather
>> its subdirectory MacOS does).
>>
>> So, this version does not consult "/usr/local/lib" to find and load 
>> "libBSF4ooRexx.dylib".
>>
>> ---rony
>>
>> P.S.: Here the relevant stack trace (when attempting to load the scripting 
>> engine for ooRexx to run
>> an AOO macro via the Tools -> Macros menu):
>>
>>Caused by: java.lang.UnsatisfiedLinkError: no BSF4ooRexx in 
>> java.library.path
>>  at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2541)
>>  at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
>>  at java.base/java.lang.System.loadLibrary(System.java:1857)
>>  at 
>> org.rexxla.bsf.engines.rexx.RexxAndJava.(RexxAndJava.java:880)
>>  at 
>> org.rexxla.bsf.engines.rexx.RexxEngine.initialize(RexxEngine.java:291)
>>  at org.apache.bsf.BSFManager$8.run(BSFManager.java:854)
>>  at java.base/java.security.AccessController.doPrivileged(Native Method)
>>  at org.apache.bsf.BSFManager.loadScriptingEngine(BSFManager.java:852)
>>  ... 40 more
>>
>>
>> On 27.09.2021 21:21, Jim Jagielski wrote:
>>> The macOS, Linux64 and Linux32 builds are also there!
>>>
 On Sep 23, 2021, at 9:48 AM, Matthias Seidel  
 wrote:

 Hi all,

 I have uploaded all Windows binaries to:

 https://dist.apache.org/repos/dist/dev/openoffice/4.1.11-RC1/binaries/

 Although we have not yet announced AOO 4.1.11-RC1 officially please feel
 free to download and test them!

 Regards,

   Matthias

 P.S.: Linux/macOS builds will be uploaded next week

 Am 22.09.21 um 17:33 schrieb Matthias Seidel:
> Hi all,
>
> I would be ready to upload the Windows binaries if we want to announce 
> RC1?
>
> Regards,
>
>   Matthias
>
> Am 21.09.21 um 23:15 schrieb Matthias Seidel:
>> Hi all,
>>
>> Am 21.09.21 um 22:42 schrieb Pedro Lino:
>>> Hi Dave, all
>>>
>>>
 On 09/21/2021 9:07 PM Dave Fisher  wrote:
 windows - thanks Matthias
 https://www.dropbox.com/s/912galt8kr7wiem/Apache_OpenOffice_4.1.11_Win_x86_install_en-US.exe?dl=0
>>> Installed and tested signing a document. Works as expected
>>>
 linux
 We are waiting for someone to do a build.
>>> Can sign on Ubuntu 18.04 x64 using my PGP certificate
>>>
>>> Unless there is a problem on Mac, seems like ready to go?
>> It looks good for me!
>>
>> Regards,
>>
>>   Matthias
>>
>>> Regards,
>>> Pedro