Re: Java 12 not recognized by AOO

[Damjan Jovanovic]

Hi Mechtilde

No idea. I'll try AdoptOpenJDK 11 now.

Regards
Damjan


On Sat, Jul 27, 2019 at 7:22 PM Mechtilde  wrote:

> Hello,
>
> @ Damjan
>
> I see your fix to Issue #128157.
>
> Does ist also works with Openjdk 11?
>
> Is it possible to extend it to OpenJKD because this is standard in the
> Linux distributions
>
> Kind regards
>
> Mechtide
>
> Am 10.05.19 um 08:42 schrieb Damjan Jovanovic:
> > On Fri, May 10, 2019 at 8:35 AM FR web forum  wrote:
> >
> >> @Larry,
> >> Strange, the xml has kept many path locations.
> >> Could you rename this file (quit AOO before)?
> >> Run AOO that re-create a new javasettings file.
> >> Go back in Tools > Options > AOO > Java to see if jre 12 is here.
> >>
> >>> 
> >>>
> >>
> file:///Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre
> >>>
> >>
> file:///Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
> >>>
> >>
> file:///Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home
> >>>
> >>
> file:///Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> >>> 
> >>
> >>
> > The only way I solved a Java detection issue before is to step through
> the
> > code with a debugger, and carefully check values at every step.
> >
> > See commit 1829211 for an example.
> >
> > We really need to beef up Java detection urgently, as Oracle has started
> to
> > limit its Java to non-commercial use, and people are migrating to
> > AdoptOpenJDK which we don't detect properly, even for Java 8.
> >
>
> --
> Mechtilde Stehmann
> ## Apache OpenOffice
> ## Freie Office Suite für Linux, MacOSX, Windows
> ## Debian Developer
> ## PGP encryption welcome
> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
>
>

Re: Java 12 not recognized by AOO

[Damjan Jovanovic]

The problem with AdoptOpenJDK 11 is that it has a:
lib/server/libjvm.so
instead of the expected:
lib/amd64/server/libjvm.so

Patching AOO to search the new path fixes the detection problem.

Does OpenJDK 11 / Oracle JDK 11 have the same change in path? Those require
a different patch.

Regards
Damjan

On Sat, Jul 27, 2019 at 7:48 PM Damjan Jovanovic  wrote:

> AdoptOpenJDK 11 isn't detected.
>
> I am investigating.
>
>
>
> On Sat, Jul 27, 2019 at 7:41 PM Damjan Jovanovic 
> wrote:
>
>> Hi Mechtilde
>>
>> No idea. I'll try AdoptOpenJDK 11 now.
>>
>> Regards
>> Damjan
>>
>>
>> On Sat, Jul 27, 2019 at 7:22 PM Mechtilde  wrote:
>>
>>> Hello,
>>>
>>> @ Damjan
>>>
>>> I see your fix to Issue #128157.
>>>
>>> Does ist also works with Openjdk 11?
>>>
>>> Is it possible to extend it to OpenJKD because this is standard in the
>>> Linux distributions
>>>
>>> Kind regards
>>>
>>> Mechtide
>>>
>>> Am 10.05.19 um 08:42 schrieb Damjan Jovanovic:
>>> > On Fri, May 10, 2019 at 8:35 AM FR web forum  wrote:
>>> >
>>> >> @Larry,
>>> >> Strange, the xml has kept many path locations.
>>> >> Could you rename this file (quit AOO before)?
>>> >> Run AOO that re-create a new javasettings file.
>>> >> Go back in Tools > Options > AOO > Java to see if jre 12 is here.
>>> >>
>>> >>> 
>>> >>>
>>> >>
>>> file:///Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre
>>> >>>
>>> >>
>>> file:///Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
>>> >>>
>>> >>
>>> file:///Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home
>>> >>>
>>> >>
>>> file:///Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
>>> >>> 
>>> >>
>>> >>
>>> > The only way I solved a Java detection issue before is to step through
>>> the
>>> > code with a debugger, and carefully check values at every step.
>>> >
>>> > See commit 1829211 for an example.
>>> >
>>> > We really need to beef up Java detection urgently, as Oracle has
>>> started to
>>> > limit its Java to non-commercial use, and people are migrating to
>>> > AdoptOpenJDK which we don't detect properly, even for Java 8.
>>> >
>>>
>>> --
>>> Mechtilde Stehmann
>>> ## Apache OpenOffice
>>> ## Freie Office Suite für Linux, MacOSX, Windows
>>> ## Debian Developer
>>> ## PGP encryption welcome
>>> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
>>>
>>>

Re: Java 12 not recognized by AOO

[Damjan Jovanovic]

AdoptOpenJDK 11 isn't detected.

I am investigating.



On Sat, Jul 27, 2019 at 7:41 PM Damjan Jovanovic  wrote:

> Hi Mechtilde
>
> No idea. I'll try AdoptOpenJDK 11 now.
>
> Regards
> Damjan
>
>
> On Sat, Jul 27, 2019 at 7:22 PM Mechtilde  wrote:
>
>> Hello,
>>
>> @ Damjan
>>
>> I see your fix to Issue #128157.
>>
>> Does ist also works with Openjdk 11?
>>
>> Is it possible to extend it to OpenJKD because this is standard in the
>> Linux distributions
>>
>> Kind regards
>>
>> Mechtide
>>
>> Am 10.05.19 um 08:42 schrieb Damjan Jovanovic:
>> > On Fri, May 10, 2019 at 8:35 AM FR web forum  wrote:
>> >
>> >> @Larry,
>> >> Strange, the xml has kept many path locations.
>> >> Could you rename this file (quit AOO before)?
>> >> Run AOO that re-create a new javasettings file.
>> >> Go back in Tools > Options > AOO > Java to see if jre 12 is here.
>> >>
>> >>> 
>> >>>
>> >>
>> file:///Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre
>> >>>
>> >>
>> file:///Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
>> >>>
>> >>
>> file:///Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home
>> >>>
>> >>
>> file:///Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
>> >>> 
>> >>
>> >>
>> > The only way I solved a Java detection issue before is to step through
>> the
>> > code with a debugger, and carefully check values at every step.
>> >
>> > See commit 1829211 for an example.
>> >
>> > We really need to beef up Java detection urgently, as Oracle has
>> started to
>> > limit its Java to non-commercial use, and people are migrating to
>> > AdoptOpenJDK which we don't detect properly, even for Java 8.
>> >
>>
>> --
>> Mechtilde Stehmann
>> ## Apache OpenOffice
>> ## Freie Office Suite für Linux, MacOSX, Windows
>> ## Debian Developer
>> ## PGP encryption welcome
>> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
>>
>>

Re: Java 12 not recognized by AOO

[Damjan Jovanovic]

Thank you.

I've added the new paths in commit 1863883.

Regards
Damjan


On Sat, Jul 27, 2019 at 8:39 PM Mechtilde  wrote:

> Hello Damjan,
>
> here you can see the paths of the different Java versions fpr libjvm.so
> under Debian:
>
> /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so
> /usr/lib/jvm/java-12-openjdk-amd64/lib/server/libjvm.so
> /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so
>
> Kind regards
>
>
> Am 27.07.19 um 20:18 schrieb Damjan Jovanovic:
> > The problem with AdoptOpenJDK 11 is that it has a:
> > lib/server/libjvm.so
> > instead of the expected:
> > lib/amd64/server/libjvm.so
> >
> > Patching AOO to search the new path fixes the detection problem.
> >
> > Does OpenJDK 11 / Oracle JDK 11 have the same change in path? Those
> require
> > a different patch.
> >
> > Regards
> > Damjan
> >
>
> --
> Mechtilde Stehmann
> ## Apache OpenOffice
> ## Freie Office Suite für Linux, MacOSX, Windows
> ## Debian Developer
> ## PGP encryption welcome
> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
>
>

Re: [discussion] svn migration plan

[Damjan Jovanovic]

That's a great idea, thank you!

1.1 - 1.5: test/ requires main/ to build, for Ant scripts. main/ requires
ext_libraries/ if not more.
Why can't we use one repository for everything, like the Github mirror
already does?

Regards
Damjan

On Sat, Jul 20, 2019 at 2:16 PM Peter Kovacs  wrote:

> Hello all,
>
>
> I had a talk with Gavin today, informing myself about the migration from
> SVN to Git. Since we have already a github mirror process we can not use
> the self service.
>
> I copied the chat to Cwiki, in order everyone can review what have been
> spoken about. [0]
>
> Summary:
>
> We have to open a ticket at infra and order the migration. The migration
> in general will consist of the following steps (taken from slack, chat
> protocol):
>
> The Infra steps in short
>
> 1. Verify Github repos is upto date and correct
> 2. we mark SVN read only
> 3. we clone the Github repos into Gitbox
> 4. we make them both writable
>
> # We can have multiple Repositories.
>
> # Gavin also whish that the depreciated CMS can be shut down in 3 month.
> I promised we look into it and try to accomplish in the time. There are
> no deadlines yet.
>
>
> I suggest the following migration Approach:
>
> 1) We migrate OpenOffice Code to git
>
> 1.1.) OpenOffice main will move into one repository
>
> 1.2)  OpenOffice ext_source and ext_libraries will be split, and each
> dependency gets its own repository.
>
> 1.3) extras/l10n will become an own repositry
>
> 1.4) test will become an own repository.
>
> 1.5) we adjust our build environment to reflect the new structure. I.e.
> You need only checkout core and bootstrap can download everything else.
> unzip step can be skipped.
>
> 2) We migrate CMS to a new solution. We have the option to go for the
> alterantive, honestly I would like to migrate to a easy to use sollution
> like neo CMS and migrate the mwiki too.
>
> We need to be able to lower the barrier for non tech work where ever we
> can.
>
> 3) PMC folder should be migrated into CWiki.
>
>
>
> All the Best
>
> Peter
>
> Older Discussions on the migration on [1],[2]
>
> [0]
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/Git+Migration+-+Chat+Protocol+with+Gavin
>
> [1]
>
> https://lists.apache.org/thread.html/c972affc61caf4844e7c82f7be9edf10fcd50753884cbaa739d1@%3Cdev.openoffice.apache.org%3E
>
> [2]
>
> https://lists.apache.org/thread.html/4db20d193cc30850e63dc03378a20462d1e5c113e566fffd6c776d1c@%3Cdev.openoffice.apache.org%3E
>
>
>
>
>

Re: Top 3 of urgent issues

[Damjan Jovanovic]

On Tue, Jul 23, 2019 at 9:20 PM Bidouille  wrote:

> Maybe for AOO v5.0...
>
> 1) AOO do not recognize JRE beyond v.8 and alternative
> https://bz.apache.org/ooo/show_bug.cgi?id=128074
>
>
The bug for AdoptOpenJDK is https://bz.apache.org/ooo/show_bug.cgi?id=128157
and I think it should be << v5.0

Regards
Damjan

Re: leftover debug?

[Damjan Jovanovic]

Please delete it.

Thank you
Damjan


On Wed, Oct 2, 2019 at 2:33 AM Don Lewis  wrote:

> It looks like there is some leftover debug code in trunk commit
> 5168e59c15cb9af435bdca9b78b99d1abe16c58e.
>
> main/scripting/source/protocolhandler/scripthandler.cxx:
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 147) void SAL_CALL
> ScriptProtocolHandler::dispatchWithNotification(
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 148) const URL&
> aURL, const Sequence < PropertyValue >& lArgs,
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 149) const
> Reference< XDispatchResultListener >& xListener )
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 150) throw (
> RuntimeException )
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 151) {
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 152)
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 153) sal_Bool
> bSuccess = sal_False;
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 154) Any
> invokeResult;
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 155) bool
> bCaughtException = sal_False;
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 156) Any
> aException;
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 157)
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 158) if (
> m_bInitialised )
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 159) {
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 160) try
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 161) {
> 5168e59c (mseidel2019-08-19 18:28:35 +0200 162)
> printf("ScriptProtocolHandler::dispatchWithNotification()\n");
> 5168e59c (mseidel2019-08-19 18:28:35 +0200 163)
>  ::rtl::OUString xStringUri = ::rtl::Uri::decode( aURL.Complete,
> 5168e59c (mseidel2019-08-19 18:28:35 +0200 164)
>  rtl_UriDecodeWithCharset, RTL_TEXTENCODING_UTF8 );
> 5168e59c (mseidel2019-08-19 18:28:35 +0200 165) bool
> bIsDocumentScript = ( xStringUri.indexOfAsciiL( RTL_CONSTASCII_STRINGPARAM(
> "document" ) ) !=-1 );
> 5168e59c (mseidel2019-08-19 18:28:35 +0200 166) printf("URI is
> %s\n", ::rtl::OUStringToOString (xStringUri,
> RTL_TEXTENCODING_UTF8).pData->buffer);
> cdf0e10c (rcweir 2011-08-16 17:05:51 + 167)
>
> I found it because printf was not declared when attempting to build on
> CentOS 6.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [DISCUSSION] Build environment future

[Damjan Jovanovic]

Hi

Ant already works for some Java modules, though at a module-only level. I
did get gbuild to extract dependency information from Ant, and build Ant
modules in the right order. For C++ though, I don't see how Ant is
possible. Even if we do get it to call the C++ compiler, it doesn't support
parallel builds. Also Ant is quite old, its build.xml file format wasn't
designed to be verifiable by an XML schema.

I should have some time for more AOO development in a week or so. I've been
stuck on porting the "config" build API to gbuild (which seems to be some
sort of API for XML configuration of UNO components, and schemas and XSLT
code to verify them at build time - main/solenv/inc/tg_config.mk); once
that's ported, 9 more modules should be portable to gbuild. That has been
particularly difficult, and it seems to affect post-build packaging too.

Another 8 modules relate to Windows. I'll have to setup up a fuller Windows
build environment for those, and I wonder if they need updating - several
of them use .NET 2.

It was quite encouraging to see that on Win64, several modules that didn't
build in dmake, started building once they were converted to gbuild.

In other news, I've been playing around with Wine, to try and cross-compile
the Windows version of AOO without Windows. I helped fix a Wine bug that
was crashing Cygwin scripts during installation and making the install take
hours (
https://source.winehq.org/git/wine.git/commit/2e53f8bccb65d112e5e341586c730094950fe6c3).
Cygwin installed nicely on Wine, bash builtin commands started working.
Then I ran into a bug where Cygwin expects user APCs to be called during
DLL loading, and Wine's DLL loading doesn't call any wait functions that
would trigger calling APCs, so a thread that would be created by an APC
doesn't get created, so fork() hangs waiting for that thread to suspend all
other threads and copy their memory to the child process (which is the only
way to fork() properly on Windows). Patching Cygwin to create that thread
directly (without using APCs) gets it further, fork() creates the child
process, but then fails an assertion and aborts because some data structure
in the child process is not at the expected address. If we can get a
working Windows build environment set up in Wine, we should hopefully
reduce build times for the Windows build from the current 5-8 hours, closer
to the 90 minutes it takes for the *nix build. AOO itself installed and
worked in Wine since OpenOffice.org version 1, so we should be able to both
build and test in Wine.

Of course, there is also the question of how well the Platform SDK and
other dependencies work on Wine. But I am quite optimistic. Cygwin is
unique in messing around with low-level operating system implementation
details. It even binary-patches some functions in NTDLL.DLL to speed up
getting the current working directory (which is apparently slow on Windows).



On Wed, Oct 30, 2019 at 7:25 AM Peter Kovacs  wrote:

> Hello Damjan and all
>
>
> I would like to re-discuss our current plan. Hoping to gain a common view.
>
> Current state is mostly we use gmake, there are still some difficult to
> migrate dmake projects. And we use Ant for java.
>
> The plan is not to stop at the dmake -> gmake conversion but to move on
> to scons, removing as much dependencies as we can. Right?
>
> I would like to set the target to build everything to Ant, removing as
> much dependencies we can.
>
>
> My arguments are mostly that Ant is supported by most when not all IDEs
> and I would really like to have an IDE as working environment, and my
> hope is that it is easier maybe to integrate an Ant build environment
> then a scons or gmake environment.
>
>  I think this would give us a better base then the plan above. So what
> was the arguments against Ant again?
>
>
> All the Best
>
> Peter
>
>

Re: C++ standard when building OpenOffice

[Damjan Jovanovic]

Thank you for the info. I haven't had good experiences with Boost in my
Win64 attempts either...

Don, how feasible do you think Go or Rust are, to start using in place of
C++?

On Mon, Nov 4, 2019 at 1:08 AM Don Lewis  wrote:

> On  3 Nov, Don Lewis wrote:
> > For much of our history, until fairly recently, the versions of gcc that
> > we used defaulted to -std=gnu++98 when compiiling C++ code.
> >
> > When FreeBSD on i386 and amd64 switched from gcc to clang, it also
> > defaulted to -std=gnu++98.  Clang has been C++11 compliant from version
> > 3.3 onwards.  Around the time of the switch, I added the
> > -DHAVE_STL_INCLUDE_PATH compiler flag so that clang would use it's own
> > STL include files instead of the boost TR1 includes.  Clang was
> > perfectly happy using its own STL include files even though they were
> > not part of C++98, only C++11.
> >
> > Later on, when clang 6 changed the default to gnu++14, the build
> > generated tons warning and some number of errors.  To work around this,
> > I added the -std=gnu++98 compiler flag to force the old mode.
> >
> > FreeBSD on powerpc still uses gcc and it recently came to my attention
> > that the build was broken there.  The FreeBSD port of AOO to powerpc
> > does not use -DHAVE_STL_INCLUDE_PATH, so it was falling back to the
> > boost TR1 headers.  The FreeBSD port uses the system boost, and recent
> > versions of boost have dropped TR1 support.  To work around that, I
> > tried enabling -DHAVE_STL_INCLUDE_PATH to use the gcc C++ headers.  This
> > failed badly because the gcc STL headers check to see if the compilation
> > mode is C++11 or better and immediately error out of this is not the
> > case.  Switching the compilation mode to c++11 results in the warning
> > and error spew mentioned above.  I tried modifying the stlport headers
> > to include the gcc TR1 headers in gnu++98 mode.  That worked better, but
> > I still got some mysterious C++ errors that I was not able to figure
> > out.  My next attempt will be to try the boost non-TR1 headers.
>
> That was a dead end. Recent boost appears to assume that the STL headers
> are provided by the system.  I'll probably have to switch back to
> bundled boost and use its TR1 headers.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: C++ standard when building OpenOffice

[Damjan Jovanovic]

On Tue, Nov 5, 2019 at 10:05 PM Don Lewis  wrote:

>
> I thought that Damjan implemenented that.
>
>
I have a patch that does gstreamer-1.0 access through run-time dynamic
linking, so we should in theory just need the gstreamer source for its
header files at compile time. It hasn't been tested or committed, and it's
pretty ugly code: gstreamer really wasn't designed to be used through
run-time dynamic linking.

Re: New computer

[Damjan Jovanovic]

What do you already know? SVN?

I personally did:
git clone https://gitbox.apache.org/repos/asf/openoffice.git
(ie. not GitHub)
which I think used my Apache credentials. If you prefer to clone from
GitHub, and want to link your Apache and GitHub credentials, you can
apparently do it on:
https://gitbox.apache.org/

As for how you use Git, if you are interested, I can give you some links,
and my own "Git for SVN users" crash course.


On Wed, Oct 30, 2019 at 2:00 PM Patricia Shanahan  wrote:

> I detangled the cables the hard way - shut everything down, unplugged,
> detangled, and put it back together with only the cables that are
> currently being used.
>
> Now I do need some advice. What is the best starting point for learning
> Git-for-AOO? I do have a GitHub account, with my personal e-mail address
> not my apache.org address.
>
> On 10/28/2019 11:33 AM, Patricia Shanahan wrote:
> > Thanks, but what I need is a magic wand of cable untangling I don't
> > suppose you have one handy.
> >
> > In installing my new computer I found that the cables connecting various
> > computers, displays, router, and printer are a mess.
> >
> > On 10/28/2019 9:51 AM, Matthias Seidel wrote:
> >> Hi Patricia,
> >>
> >> How are things going?
> >> If you are in need of something just let me know...
> >>
> >> Regards,
> >>
> >> Matthias
> >>
> >> Am 26.10.19 um 06:24 schrieb Patricia Shanahan:
> >>> Any opinions on which I should do?
> >>>
> >>>
> >>> On 10/25/2019 1:27 PM, Matthias Seidel wrote:
>  Hi Patricia,
> 
>  If you want to build 4.1.x have a look at:
>  https://home.apache.org/~mseidel/AOO-builds/AOO-418-Test/ReadMe.txt
> 
>  For 4.2.x (and trunk) see:
>  https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/ReadMe.txt
> 
>  This is how I do my test builds.
> 
>  Regards,
> 
>   Matthias
> 
>  Am 24.10.19 um 22:09 schrieb Patricia Shanahan:
> > Are the Windows 10 instructions up-to-date?
> >
> > I have just got a shiny new Windows 10 Pro computer, and am planning
> a
> > clean start on AOO building. It will take a day or so for me to
> > install and set up basic stuff, and then I'll need to install
> whatever
> > I need for AOO building.
> >
> > -
> > 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
> >>>
> >>>
> >>
> >
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: New computer

[Damjan Jovanovic]

On Wed, Oct 30, 2019 at 6:16 PM Patricia Shanahan  wrote:

> On 10/30/2019 8:13 AM, Damjan Jovanovic wrote:
> > What do you already know? SVN?
>
> RCS, SCCS, and SVN.
>
> >
> > I personally did:
> > git clone https://gitbox.apache.org/repos/asf/openoffice.git
> > (ie. not GitHub)
> > which I think used my Apache credentials. If you prefer to clone from
> > GitHub, and want to link your Apache and GitHub credentials, you can
> > apparently do it on:
> > https://gitbox.apache.org/
>
> Any guidance on how to decide which I am likely to prefer?
>
>
It doesn't really matter which you start with, because they're each other's
mirrors, and in Git you can always change your local repository's "remote".
For example if you cloned GitHub, and want to switch to GitBox, you don't
need to clone the GitBox link, you can simply do:
git remote set-url origin https://gitbox.apache.org/repos/asf/openoffice.git

With GitHub, you can accept GitHub pull requests from other contributors,
even in your web browser, so it might be a better choice in that regard. I
can't say I personally approve of the GitHub lock-in for that feature
though.


> >
> > As for how you use Git, if you are interested, I can give you some links,
> > and my own "Git for SVN users" crash course.
>
> Links would be useful. For me when learning programming languages, "for
> dummies" courses work better than conversion courses. The "for dummies"
> type of course helps me get into the right mindset for the language. I
> don't know whether SVN to Git will be different.
>
>
Ok sure:

Graph theory explanations of how branches and Git operations work:
https://eagain.net/articles/git-for-computer-scientists/

The free online book, "Pro Git":
https://git-scm.com/book/en/v2

A detailed guide to various Git options, written for the Wine project but
generally useful:
https://wiki.winehq.org/Git_Wine_Tutorial

I'll try sum it up for you. For SVN users, Git's terminology is straight
from hell. "svn checkout X" checks out a working copy from repository X,
but "git checkout X" switches the current branch to X (among other things).
Git's equivalent is "git clone" (except that the entire repository with
full history and all branches is cloned, not just a working copy.) An SVN
revision is a commit in Git.

Everything you commit is only committed locally, and can be undone. You
have to "git push" to send your commits upstream.

The main branch of a project is usually called "master", but in AOO ours is
called "trunk" since we imported from SVN. The branch you are on at the
moment is given by "git branch", which lists all the local branches and
stars the current one. "git status" also shows your current branch and
files changed.

Remote branches can be shown with "git remote show origin". If you "git
checkout" with their name, eg. "git checkout AOO418", it will make a local
branch by that name and switch to it. You can also make a local branch
remote (somehow).

You make new local branches with "git branch ", eg. "git branch
temp". (It's instantaneous: it doesn't have to copy history or anything
like that). You can "git checkout temp" to switch to it, "git branch -D
temp" to delete it. A "detached head" is when you "git checkout" something
that's not a branch (as you can "git checkout" any commit or tag, not just
a branch). If you are just looking around, that's not a problem, but if you
"git commit" on a detached head, that commit isn't referenced from
anywhere, and if you checkout anything else, you will lose that work. If
you don't want to lose it, you can "git branch myWork" to attach a branch
to that new commit, so you can get back to it later (with "git checkout
myWork").

There are 2 important ways of working with branches, merging and rebasing.
Both are only local, until you "git push". Merging in Git is similar to
merging in SVN, changes in one branch get merged into another, but rebasing
is amazing. With rebasing you can rearrange commits and branches to your
liking, split commits, merge commits, reorder commits, delete commits,
change commit messages, reposition an old branch so it starts at a newer
commit (and deal with outdated code locally in that branch before merging
or pushing it), etc. "git rebase -i HEAD~3" opens a text editor with the
last 3 commits, one per line, describing changes you can make by placing a
keyword at the beginning of its line. If you commit by mistake, do that and
you can drop the bad commit. Of course with great power comes great
responsibility, and rebasing should only really be done locally before you
push, as rebasing commits that were

Re: C++ standard when building OpenOffice

[Damjan Jovanovic]

On Mon, Nov 4, 2019 at 3:49 AM Branko Čibej  wrote:

> On 04.11.2019 02:14, Damjan Jovanovic wrote:
> > Thank you for the info. I haven't had good experiences with Boost in my
> > Win64 attempts either...
> >
> > Don, how feasible do you think Go or Rust are, to start using in place of
> > C++?
>
> Really? You'd rewrite code in a completely different language because
> you can't figure out a way to select std::auto_ptr or std::unique_ptr
> depending on your build environment?
>

I said "start using" (for new development), not "rewrite". The Mozilla
project did something similar, they used Rust to develop their new Servo
layout engine, not rewrite the whole of Firefox in it.


>
> FWIW, both Go and Rust are far more moving targets than C++, but sure,
> that's not going to be a problem, eh.
>

Yeah, it has compiler bugs, undocumented linker issues, crashes when built
with Clang due to lack of -fno-enforce-eh-specs support, crash-on-startup
on some Windows installations, porting to new platforms is hard, there are
incompatibilities with Microsoft Visual C++
static/multithreaded/debug/release library options, it's difficult using
new C++ versions, it has ridiculous build times (7+ hours on Windows),
patches often break the build on some platforms, has all kinds of
platform-specific limitations (eg. no throwing exceptions or passing STL
structures across DLL boundaries), and it's Swiss cheese in terms of
security holes, but C++ is just perfect right?

The reason we haven't made more progress in AOO and added more features, is
because we're too busy babysitting C++.

If AOO was to be redeveloped, I would use C, and supplement it with
higher-level memory-safe languages (NEVER C++).

Re: 4.2.0-dev next?

[Damjan Jovanovic]

On Fri, Oct 25, 2019 at 1:00 AM Marcus  wrote:

> Am 24.10.19 um 14:04 schrieb Mechtilde:
> > First we should try to fix the release blocker
> >
> > https://bz.apache.org/ooo/show_bug.cgi?id=125129
> > https://bz.apache.org/ooo/show_bug.cgi?id=127731
> > https://bz.apache.org/ooo/show_bug.cgi?id=128094
> > https://bz.apache.org/ooo/show_bug.cgi?id=127783
> > https://bz.apache.org/ooo/show_bug.cgi?id=127774
> >
> > We think Issue 127731 and 128094 have a similar reason.
>
> I also think that we should fix these blockers and check for others,
> before doing a test build for a wider audience. It would increase the
> quality and therefore also the public acceptance.
>
> +1

Re: OpenGrok

[Damjan Jovanovic]

Thank you so much!

It works well.


On Sat, Oct 19, 2019 at 1:26 AM Ariel Constenla-Haile <
ariel.constenla.ha...@gmail.com> wrote:

> Hi *,
>
> On Thu, Oct 17, 2019 at 3:15 AM Peter Kovacs  wrote:
> > Server is openoffice-vm1-he-de.Apache. Org
>
> A first attempt is now live at http://openoffice-vm1-he-de.apache.org
>
> It has trunk/master and AOO42X and AOO418 branches indexed.
> Tomcat is behind mod_proxy_ajp, I've seen that http://androidxref.com/
> uses Apache Coyote, which is said to be a better configuration, but
> I've no idea how to use it, if someone is in the know, just comment.
>
> Try it and comment if you find errors, and think of a subdomain name,
> for example source.openoffice.org, opengrok.openoffice.org,
> xref.openoffice.org, etc.
> I'll try to puppetize as much as I can, but opengrok needs manual
> intervention.
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Buenos Aires
> Argentina
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: code comments and doxygen

[Damjan Jovanovic]

On Mon, Nov 18, 2019 at 10:58 PM Peter Kovacs 
wrote:

> anyone minds if i add or modify existing code comments to fit to a
> doxygen generated output?
>
> I am using it at the moment to build a better understanding.
>
>
Don't we have an internal documentation system used in place of doxygen,
and able to generate documentation for IDL and other languages?

main/autodoc and so on?

Damjan

Re: [openoffice] branch trunk updated: Fix incorrect gbuild usage that can cause intermittent parallel build failures.

[Damjan Jovanovic]

On Fri, Oct 4, 2019 at 6:47 PM Don Lewis  wrote:

> On  4 Oct, truck...@apache.org wrote:
>
> > diff --git a/main/codemaker/Executable_cppumaker.mk
> b/main/codemaker/Executable_cppumaker.mk
> > index b876b68..63c9bc2 100644
> > --- a/main/codemaker/Executable_cppumaker.mk
> > +++ b/main/codemaker/Executable_cppumaker.mk
> > @@ -25,9 +25,9 @@ $(eval $(call gb_Executable_Executable,cppumaker))
> >
> >  $(eval $(call gb_Executable_set_targettype_gui,cppumaker,NO))
> >
> > -$(eval $(call
> gb_StaticLibrary_add_package_headers,cppumaker,codemaker_inc))
> > +$(eval $(call
> gb_Executable_add_package_headers,cppumaker,codemaker_inc))
>
> Does anyone know why we call add_package_headers when building
> executables?  When building libraries, we need to deliver the headers
> for the library API, but I don't know why we would do this for an
> executable.
>
>
If you look at 529d6db8d002a57de885f2a2dfd65c2a89b9309e the old prj/d.lst
was delivering headers too, so I just did the same in gbuild.

Some other downstream module probably needs them.

Re: gotoSCons: automated gbuild to SCons conversion

[Damjan Jovanovic]

On Sun, Feb 9, 2020 at 11:47 AM Peter Kovacs  wrote:

> Sounds nice.
>
> Thank you.

It would be great to have a debug output that can be checked to check which
> dependencies have been pulled. For me a declarative output would be cool to
> understand some code.
>
>
You can see within-module dependencies with "scons -u --tree=all" run in a
module:

+-fileaccess
  +-fileaccess/SConscript
  +-fileaccess/inc
  | +-fileaccess/inc/fileaccess
  |   +-fileaccess/inc/fileaccess/dllapi.h
  +-fileaccess/source
  | +-fileaccess/source/FileAccess.cxx
  | +-fileaccess/source/fileacc.xml
  +-fileaccess/util
+-fileaccess/util/fileacc.component

Dependencies between modules can be seen in main/ with "scons
--tree=prune", which autodetects tons of headers, libraries, xml, etc. in
solver/, with transitive dependencies.

There are others, see
https://scons.org/doc/production/HTML/scons-user.html#chap-troubleshooting


>
> Also do you have an idea how to handle IDLs with scon? That would be
> awesome.
>
>
You mean the idlc + regmerge + cppmaker/javamaker toolchain? It should be
fairly easy, given I already ported part of it to Ant before
(main/solenv/ant/idl.xml), although that didn't do header dependencies in
.idl files.


> All the best
> Peter
>
>
Damjan

Re: gotoSCons: automated gbuild to SCons conversion

[Damjan Jovanovic]

I've implemented static libraries, added linker version scripts, and made
some cleanups, and 22 modules can now be converted to SCons (up from 19 a
week ago).

AllLangResTarget is the next big target, and it seems exceptionally
complicated, with 3 layers of intermediate targets: .src --(transex3)-->
.src --(rsc)--> .src --(cat)--> .srs --(rsc)--> .res per language in
AllLangResTarget, with transex3 being skipped when not building
translations. Since the .src can #include C headers, they will need a
custom dependency scanner, in addition to the custom builder that all
custom targets need, plus of course delivery rules. Fortunately, as it's
Python, we have some flexibility as to how to implement it.

On Sun, Feb 2, 2020 at 2:31 AM Damjan Jovanovic  wrote:

> Hi
>
> I've just pushed a "scons-build" branch.
>
> The build infrastructure is in main/scons. Python and SCons have to be
> installed system-wide and available in $PATH. Currently we require Python
> 3, but that's easy to change.
>
> So far main/fileaccess has been converted to SCons as a test. Its gbuild
> files are still there; prj/makefile.mk determines whether to use gbuild
> or scons. SCons is only used at a module level, build.pl is still the
> launcher. You can build main/fileaccess in isolation by running "scons"
> inside main/, or "scons -u" inside main/fileaccess, and clean by adding
> "-c" (or "--clean") to those flags. It will correctly build the .cxx file,
> link it into a library, install the library, run xsltproc on the .component
> file, install the transformed .component file, and install the .xml file.
> Everything can also be successfully cleaned.
>
> At present FreeBSD has been tested, and I will test Windows soon. Other
> platforms don't exist, and still have to be added in
> main/site_scons/platform.
>
> The converter is in gotoGBuild/, at the same level as main/ and test/. You
> build it with Maven by running "mvn package". Then:
>
> java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter
> parsingAnalysis ../main
> Attempts to parse each gbuild module, printing out errors for those that
> couldn't be, and a summary of which could be parsed.
> What is also useful is:
> java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter
> parsingAnalysis ../main 2>&1 | grep java.lang.Exception >
> /tmp/errorsByModule.csv
> Then open /tmp/errorsByModule.csv in AOO, use # as the field separator,
> and you get a table of modules that failed and a reason for each one. Sort
> by column B, and you can see how often a reason occurs, for example 21
> modules need AllLangResTarget implemented. That can inform further
> development.
>
> To actually convert a module to SCons, use one of the modules that
> previous results said could be parsed, eg. io, and run:
> java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter
> parseModule ../main/io/Module_io.mk
> It will print the converted SCons file to standard output.
>
> Converting library names is currently broken. In main/fileaccess and
> main/site_scons I've begun with dmake's way of naming libraries, like in
> main/solenv/inc/libs.mk. GBuild re-did library naming by using 10
> layer-specific rules, and then having tons of exceptions in
> main/RepositoryFixes.mk; I am not sure which is worse. Maybe we should give
> up the pretense, and just have a table in a CSV file, with platforms as
> column headers, and library names as row headers, with the
> platform-specific name in each field, and parse it with Python's built-in
> CSV package on build startup?
>
>
>
> On Sat, Feb 1, 2020 at 8:10 PM Peter Kovacs  wrote:
>
>> Hi Damjan,
>>
>> Let's try it. But I suggest to push to an own branch. There is no worth
>> in trying and getting stuck in the same spot.
>>
>> Merge is done quickly. And it is great if others can have a look, too.
>>
>> All the best
>> Peter
>>
>>
>> Am 1. Februar 2020 13:36:42 MEZ schrieb Damjan Jovanovic <
>> dam...@apache.org>:
>> >Hi
>> >
>> >gbuild has become an unmaintainable nightmare. While there are only 37
>> >internal dmake modules left (+ another 37 external modules), I cannot
>> >motivate myself to convert even 1 more. At my development speed of
>> >about 2
>> >lines of code every 8 hours, gbuild is a disaster that wastes
>> >unbelievable
>> >amounts of time, and it's really not a development I can say I am proud
>> >of.
>> >It has the ugliest syntax ever, it can only be debugged through
>> >experimentation, and nobody really understands it. Also, it doesn't
>> >fully
>> &

Re: setting scons up for linux

[Damjan Jovanovic]

That's really great :).

I am very busy for the next few weeks and can't contribute much. I was
trying to port AllLangResTarget.mk to SCons but it's really hard, it needs
advanced features like custom builders, custom scanners, up to 10 new
target types, etc. When I have more time, I need to find a small
AllLangResTarget module to experiment with.

The next big thing we probably need to deal with is the library naming
(main/Repository.mk vs main/solenv/inc/libs.mk).

On Fri, Feb 28, 2020 at 11:13 PM Peter Kovacs  wrote:

> Okay, after moving to python3 and installing latest scon the fileaccess
> build for Linux.
>
> I can push on Sunday the OS setup to gitbox.
>
> What are the next steps from here?
>
> I try to deliver a Mac and OS/2 profile.
>
> And I will have a look at the converter, too.
>
>
> All the Best
>
> Peter
>
> Am 27.02.20 um 18:27 schrieb Damjan Jovanovic:
> > You need a recent Python 3:
> > ImportError: cannot import name ABC:
> >
> > On Thu, Feb 27, 2020 at 7:14 PM Peter Kovacs  wrote:
> >
> >> Hello Damjan,
> >>
> >>
> >> I did try to setup scons for Linux.
> >>
> >> I copied the
> >>
> >> 1) FreeBSD file to Linux File.
> >>
> >> 2) replaced FreeBSD to Linux
> >>
> >> 3) added a entry to main/site_scons/globals.py
> >>
> >> I do now get following Error Message:
> >>
> >> ~/workspace/AOO/gitbox/main$ scons
> >> *** Error loading site_init file './site_scons/site_init.py':
> >> *** cannot import site init file './site_scons/site_init.py':
> >> ImportError: cannot import name ABC:
> >> File "/usr/lib/scons/SCons/Script/Main.py", line 1389:
> >>   _exec_main(parser, values)
> >> File "/usr/lib/scons/SCons/Script/Main.py", line 1352:
> >>   _main(parser)
> >> File "/usr/lib/scons/SCons/Script/Main.py", line 954:
> >>   _load_all_site_scons_dirs(d.get_internal_path())
> >> File "/usr/lib/scons/SCons/Script/Main.py", line 807:
> >>   _load_site_scons_dir(d)
> >> File "/usr/lib/scons/SCons/Script/Main.py", line 741:
> >>   exec fp in site_m
> >> File "./site_scons/site_init.py", line 26:
> >>   from globals import *
> >> File "/home/legine/workspace/AOO/gitbox/main/site_scons/globals.py",
> >> line 39:
> >>   from linux import *
> >> File
> >> "/home/legine/workspace/AOO/gitbox/main/site_scons/platform/linux.py",
> >> line 23:
> >>   import aooplatform
> >> File
> >>
> "/home/legine/workspace/AOO/gitbox/main/site_scons/platform/aooplatform.py",
> >>
> >> line 22:
> >>   from abc import ABC, abstractmethod
> >>
> >>
> >> Do you have an Idea what needs to be done?
> >>
> >> Thanks
> >>
> >> All the Best
> >>
> >> Peter
> >>
> >>
> >> -
> >> 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: setting scons up for linux

[Damjan Jovanovic]

You need a recent Python 3:
ImportError: cannot import name ABC:

On Thu, Feb 27, 2020 at 7:14 PM Peter Kovacs  wrote:

> Hello Damjan,
>
>
> I did try to setup scons for Linux.
>
> I copied the
>
> 1) FreeBSD file to Linux File.
>
> 2) replaced FreeBSD to Linux
>
> 3) added a entry to main/site_scons/globals.py
>
> I do now get following Error Message:
>
> ~/workspace/AOO/gitbox/main$ scons
> *** Error loading site_init file './site_scons/site_init.py':
> *** cannot import site init file './site_scons/site_init.py':
> ImportError: cannot import name ABC:
>File "/usr/lib/scons/SCons/Script/Main.py", line 1389:
>  _exec_main(parser, values)
>File "/usr/lib/scons/SCons/Script/Main.py", line 1352:
>  _main(parser)
>File "/usr/lib/scons/SCons/Script/Main.py", line 954:
>  _load_all_site_scons_dirs(d.get_internal_path())
>File "/usr/lib/scons/SCons/Script/Main.py", line 807:
>  _load_site_scons_dir(d)
>File "/usr/lib/scons/SCons/Script/Main.py", line 741:
>  exec fp in site_m
>File "./site_scons/site_init.py", line 26:
>  from globals import *
>File "/home/legine/workspace/AOO/gitbox/main/site_scons/globals.py",
> line 39:
>  from linux import *
>File
> "/home/legine/workspace/AOO/gitbox/main/site_scons/platform/linux.py",
> line 23:
>  import aooplatform
>File
> "/home/legine/workspace/AOO/gitbox/main/site_scons/platform/aooplatform.py",
>
> line 22:
>  from abc import ABC, abstractmethod
>
>
> Do you have an Idea what needs to be done?
>
> Thanks
>
> All the Best
>
> Peter
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: gotoSCons: automated gbuild to SCons conversion

[Damjan Jovanovic]

Hi

I've just pushed a "scons-build" branch.

The build infrastructure is in main/scons. Python and SCons have to be
installed system-wide and available in $PATH. Currently we require Python
3, but that's easy to change.

So far main/fileaccess has been converted to SCons as a test. Its gbuild
files are still there; prj/makefile.mk determines whether to use gbuild or
scons. SCons is only used at a module level, build.pl is still the
launcher. You can build main/fileaccess in isolation by running "scons"
inside main/, or "scons -u" inside main/fileaccess, and clean by adding
"-c" (or "--clean") to those flags. It will correctly build the .cxx file,
link it into a library, install the library, run xsltproc on the .component
file, install the transformed .component file, and install the .xml file.
Everything can also be successfully cleaned.

At present FreeBSD has been tested, and I will test Windows soon. Other
platforms don't exist, and still have to be added in
main/site_scons/platform.

The converter is in gotoGBuild/, at the same level as main/ and test/. You
build it with Maven by running "mvn package". Then:

java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter
parsingAnalysis ../main
Attempts to parse each gbuild module, printing out errors for those that
couldn't be, and a summary of which could be parsed.
What is also useful is:
java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter
parsingAnalysis ../main 2>&1 | grep java.lang.Exception >
/tmp/errorsByModule.csv
Then open /tmp/errorsByModule.csv in AOO, use # as the field separator, and
you get a table of modules that failed and a reason for each one. Sort by
column B, and you can see how often a reason occurs, for example 21 modules
need AllLangResTarget implemented. That can inform further development.

To actually convert a module to SCons, use one of the modules that previous
results said could be parsed, eg. io, and run:
java -cp target/classes org.apache.openoffice.gotoSCons.GBuildConverter
parseModule ../main/io/Module_io.mk
It will print the converted SCons file to standard output.

Converting library names is currently broken. In main/fileaccess and
main/site_scons I've begun with dmake's way of naming libraries, like in
main/solenv/inc/libs.mk. GBuild re-did library naming by using 10
layer-specific rules, and then having tons of exceptions in
main/RepositoryFixes.mk; I am not sure which is worse. Maybe we should give
up the pretense, and just have a table in a CSV file, with platforms as
column headers, and library names as row headers, with the
platform-specific name in each field, and parse it with Python's built-in
CSV package on build startup?



On Sat, Feb 1, 2020 at 8:10 PM Peter Kovacs  wrote:

> Hi Damjan,
>
> Let's try it. But I suggest to push to an own branch. There is no worth in
> trying and getting stuck in the same spot.
>
> Merge is done quickly. And it is great if others can have a look, too.
>
> All the best
> Peter
>
>
> Am 1. Februar 2020 13:36:42 MEZ schrieb Damjan Jovanovic <
> dam...@apache.org>:
> >Hi
> >
> >gbuild has become an unmaintainable nightmare. While there are only 37
> >internal dmake modules left (+ another 37 external modules), I cannot
> >motivate myself to convert even 1 more. At my development speed of
> >about 2
> >lines of code every 8 hours, gbuild is a disaster that wastes
> >unbelievable
> >amounts of time, and it's really not a development I can say I am proud
> >of.
> >It has the ugliest syntax ever, it can only be debugged through
> >experimentation, and nobody really understands it. Also, it doesn't
> >fully
> >work, eg. a lot of the newer targets I've added don't get cleaned on
> >"make
> >clean", CustomTarget fails to deliver files sometimes, etc.
> >
> >To that end, I've restarting playing with an old idea: to switch to the
> >SCons build system, using a tool to automatically convert build files
> >from
> >gbuild to SCons.
> >
> >I got my previous scons build (of 1 module) up and running very
> >quickly,
> >and it still works. Then I continued development of my gbuild parser
> >and
> >automated converter, which I've called gotoSCons, and got it to parse
> >most
> >of the build instructions in Module_xxx.mk, Library_xxx.mk,
> >Executable_xxx.mk and Package_xxx.mk and convert them to a SCons build
> >file
> >(SConscript).
> >
> >gotoSCons is relatively simple, about 1200 lines of Java, and I can
> >provide
> >it to interested parties, or put it in a Git branch. It already found 3
> >bugs in these gbuild files:
> >1. main/xmloff/Package_inc.mk duplicates this line:
> >$(eval $(call
>
> >gb_

Re: Audience for AOO (Was: Re: Apache OpenOffice 4.1.7 for OS/2 (and OS/2 based systems like ArcaOS))

[Damjan Jovanovic]

On Fri, Jan 31, 2020 at 6:00 PM Pedro Lino  wrote:

> Hi Jim
>
> > Now sure, if you are running the latest version of Linux, on a high-end
> machine, and needs lots of bells and
> > whistles, then other Office suites are likely more tailored for your
> setup.
>
> Actually I'm running a high-end machine with Ubuntu 18.04 LTS (soon to be
> updated to 20.04 LTS) and I prefer OpenOffice because of the stability.
>
>
The stability cannot be overstated. I have to use a related office suite as
well, but despite some improvements, it has endless, ongoing regressions.
Every release manages to break something new.

Damjan

Re: System-provided Python 3 support now committed

[Damjan Jovanovic]

On Sat, Jan 25, 2020 at 1:38 PM Matthias Seidel 
wrote:

> Hi Damjan, Hi Pedro,
>
> Thank you for your work and the helpful explanation.
>
>
Pleasure :)


> BTW: I could make the "edit" button clickable for Python scripts by
> setting ENABLE_EDIT_DIALOG to TRUE in [1], but it never brought up an
> editor or something similar.
>
>
Yes I saw that too.

If I wrap the contents of ScriptBrowseNode.invoke() in a try/except, and
log the contents, I get:

:

/openoffice-git/main/instsetoo_native/unxfbsdx/Apache_OpenOffice/installed/install/en-US/openoffice4/program/pythonscript.py:520
in function invoke() ["vnd.sun.star.script:" +]

with the code involved being:

519self.editor = dlgprov.createDialog(
520"vnd.sun.star.script:" +
521"ScriptBindingLibrary.MacroEditor?location=application")

and I am not sure what's making it unhappy there.




> Regards,
>
>Matthias
>
> [1]
>
> https://github.com/apache/openoffice/blob/trunk/main/scripting/source/pyprov/pythonscript.py
>
> Am 25.01.20 um 10:56 schrieb Damjan Jovanovic:
> > Hi
> >
> > With Python 2 EOL as of 1 January 2020, we have little choice but to move
> > to Python 3.
> >
> > After a lot of hard work by me and Pedro, both of us relatively
> unfamiliar
> > with Python, I am happy to report that using a system-provided Python 3
> in
> > Apache OpenOffice now works.
> >
> > The UNO/Python bridge and the Python script provider have been patched to
> > support both Python 2 and 3, and all 3 sample Python macros that ship
> with
> > AOO work with Python 3 too. More extensive testing (eg. main/pyuno/demo)
> > has not been performed, but isn't in the build anyway and might be broken
> > with Python 2 as well.
> >
> > It certainly works on FreeBSD and probably on Linux, please test other
> > platforms.
> >
> > As I said only system-provided Python 3 works as this stage. Building an
> > internal Python 3, as is required on Windows, does not work yet, and is
> > extremely difficult to implement, as Python 3 requires a new Windows
> > Platform SDK with MSVC >= 14 in order to build, which will probably lead
> to
> > numerous build-related changes to all modules. This does need to happen
> at
> > some stage anyway though.
> >
> > Also as per https://bz.apache.org/ooo/show_bug.cgi?id=123975#c9
> > we also need to release AOO 5.0 (a new major release) for an incompatible
> > change of this nature.
> >
> > Along the way, I also looked at what it would take to improve the Python
> > macro dialog, which never allowed creating, renaming, deleting or editing
> > Python scripts, only running them (and to add them to an .odt file, you
> > have to edit the ZIP file and add them manually). There are at least 3
> > separate implementations of scripting providers: the StarBasic one, the
> > Java one (used for Java, BeanShell and Rhino (Javascript)), and the
> Python
> > one. It's the Python one in main/scripting/source/pyprov/pythonscript.py
> > that is missing features. By comparing it against the Java provider I
> > managed to patch DirBrowseNode to implement XPropertySet and add a
> > getPropertyValue() method which checks for the "Creatable" property and
> > returns true, and this enables the (otherwise grayed out) "Create" button
> > in the dialog, but then to implement the "Creatable" action in invoke()
> > when the button is clicked seems rather difficult, and requires a
> low-level
> > understanding of script URLs and content brokers and various other
> > infrastructure.
> >
> > Damjan
> >
>
>

gotoSCons: automated gbuild to SCons conversion

[Damjan Jovanovic]

Hi

gbuild has become an unmaintainable nightmare. While there are only 37
internal dmake modules left (+ another 37 external modules), I cannot
motivate myself to convert even 1 more. At my development speed of about 2
lines of code every 8 hours, gbuild is a disaster that wastes unbelievable
amounts of time, and it's really not a development I can say I am proud of.
It has the ugliest syntax ever, it can only be debugged through
experimentation, and nobody really understands it. Also, it doesn't fully
work, eg. a lot of the newer targets I've added don't get cleaned on "make
clean", CustomTarget fails to deliver files sometimes, etc.

To that end, I've restarting playing with an old idea: to switch to the
SCons build system, using a tool to automatically convert build files from
gbuild to SCons.

I got my previous scons build (of 1 module) up and running very quickly,
and it still works. Then I continued development of my gbuild parser and
automated converter, which I've called gotoSCons, and got it to parse most
of the build instructions in Module_xxx.mk, Library_xxx.mk,
Executable_xxx.mk and Package_xxx.mk and convert them to a SCons build file
(SConscript).

gotoSCons is relatively simple, about 1200 lines of Java, and I can provide
it to interested parties, or put it in a Git branch. It already found 3
bugs in these gbuild files:
1. main/xmloff/Package_inc.mk duplicates this line:
$(eval $(call
gb_Package_add_file,xmloff_inc,inc/xmloff/XMLTextShapeImportHelper.hxx,xmloff/XMLTextShapeImportHelper.hxx))
I've committed a fix in 85bfc14eebba4af4847075b1cf1eaecfa87bcfc4
2. main/bean/Module_bean.mk adds no targets.
3. main/testgraphical/Module_testgraphical.mk does nothing.

The gotoSCons parser is very strict, it tries hard to guarantee a correct
conversion, and will immediately fail on non-deterministic sections, such
as "ifeq ($(OS),WNT)". It will also immediately fail on deliverable types
that I haven't implemented yet, such as AllLangResTarget_, StaticLibrary_
etc., and commands within targets that I haven't implemented yet such as
gb_Executable_set_targettype_gui and gb_Library_use_externals. Out of our
total of 105 gbuild modules, 53 use non-deterministic sections, and will
require some degree of manual conversion, but the converter should
eventually be able to handle the other 52 modules. Even with the limited
deliverable/command support at present, it can successfully convert 19
modules. The conversion would be straightforward even if done manually, as
both gbuild and SCons are high level build systems with similar concepts:
includes, defines, cflags, libraries to link to, and so on (dmake is the
difficult low-level tool).

I love SCons. It's been easy integrating it into our build. It just works.
It has beautiful clear syntax. It's understandable and debuggable. It makes
development fun again. It's a well established build system, with a 20 year
history, supporting Python 2 and 3, supporting almost every platform out
there including OS/2, supporting every version of MSVC including Visual
Studio 2019, supporting advanced features like ELF sonames, library version
symlinks and library name prefixes and suffixes, flex and bison targets
(which we all need), automatically generating cleaning targets for every
build target, can use checksums instead of timestamps to avoid unnecessary
rebuilds, automatic header dependency extraction, can build a module by
itself instead of the whole project, parallelizes building at a file level
(across module boundaries). It can build at least some AOO modules without
Cygwin. It is easy to add custom targets, unlike gbuild where it's almost
impossible. It is equal to or better than gbuild in just about everything,
and we don't have to maintain it going forward like we do with gbuild: its
developers develop it, and we just use it.

If someone would like to get involved, please let me know soon, so we can
decide on an API, file layout, etc. before I've begun committing any
changes (and relax, they would be committed to a separate branch until we
are convinced it works well).

I was the major force that led us into more gbuild, but now I think it's
time to leave it. It's already coming apart at the seams, and I don't see
it being developed further. It's based on ($eval), an optional extra added
quite late, as an afterthought for special cases, probably not how GNU make
was intended to be used at scale, and a feature absent in other "make"s.
The only other project in the world that uses gbuild is LO, and I recall
reading how it took them an enormous amount of work to migrate to it fully.
Let's learn from their mistake?

Regards
Damjan

Re: Building On CentOS 8 Dependency Help

[Damjan Jovanovic]

On Sat, Feb 15, 2020 at 4:14 PM Carl Marcum  wrote:

> Hi All,
>
> Not sure if anyone has went down this road yet but I've installed CentOS
> 8 with a Gnome desktop env, on a server of mine and would like to build
> AOO 4.2 on it  or even 4.1.x if needed.
> My starting point was the Building Guide section for Centos 7 for AOO
> 4.2.  [1]
>
> I have the following repos enabled:
> CentOS-8 - AppStream9.1 kB/s | 4.3 kB 00:00
> CentOS-8 - Base 8.0 kB/s | 3.8 kB 00:00
> CentOS-8 - Extras   1.2 kB/s | 1.5 kB 00:01
> CentOS-8 - PowerTools   8.5 kB/s | 4.3 kB 00:00
> Extra Packages for Enterprise Linux Modular 8 -  27 kB/s |  12 kB 00:00
> Extra Packages for Enterprise Linux 8 - x86_64   32 kB/s |  17 kB 00:00
>
> But I'm not finding a few of the listed dependencies:
>
> No match for argument: gnome-vfs2-devel
> No match for argument: gstreamer-devel
> No match for argument: gstreamer-plugins-base-devel
> No match for argument: ORBit2-devel
> Error: Unable to find a match: gnome-vfs2-devel gstreamer-devel
> gstreamer-plugins-base-devel ORBit2-devel
>
> I found that gstreamer 0.1 is no longer maintained and they suggest 1.0
> series. [2]
> Do we still need 0.1 for building.
>

We moved to 1.0 a year ago:

commit b6e71573e19c0b24193aa83c913ad163e3fbb449
Author: Damjan Jovanovic 
Date:   Fri Mar 2 06:14:01 2018 +

Use gstreamer 1.0 instead of the long obsolete
version 0.1.


> It looks like gnome-vfs2 is superseded by GVfs [3] .
> I have a number of gvfs-* packages installed already so I added gvfs-devel.
> Would this work ?
>

gvfs was superseded by gio long ago, and we've supported gio since 2011.
The default should now be --enable-gio --disable-gnome-vfs


>
> I see ORBit2 is used for CORBA.   I'm coming up blank on any CentOS 8
> package.
>
> Also, what minimum or better yet latest Java could I build 4.2 with?
>

Java 7 onwards should work. If one doesn't, please report, I'll fix it.
However we really should ensure that for release builds we build with 7;
newer .class file formats may be incompatible with older JREs if we didn't
pass -source and -target flags to javac, etc.

Damjan

Re: Updated 4.2.0 build?

[Damjan Jovanovic]

On Mon, Feb 17, 2020 at 1:59 AM Andrea Pescetti  wrote:

>
> I think I saw, ages ago, a graphical installer for Linux, written in
> Java; none of our current builds uses that approach (and honestly this
> seems a bit out of place in the Linux world) but the code might still be
> there. We are surely talking about OpenOffice 3.x if not even 2.x.
>
>
It's in main/javainstaller2

Re: about build environment development (was: declaring gbuild target dependencies)

[Damjan Jovanovic]

On Wed, Apr 15, 2020 at 6:46 AM Peter Kovacs  wrote:

> If one wants to tap in our build system he needs to understand Perl,
> shell, make, ant, XML, configure, ...
>
> This is just way to complicated, especially if you want to bring in an
> IDE to ease code development.
>
>
> Damjan is not very happy with the features gmake offers. I am not sure
> where exactly the Issue is.
>
> He is opting for SCONs, with the option to extend the build system with
> python. And IMHO on Damjan
>
> Side he is quite serious about it.
>
>
> Everyone else has not expressed any opinion on this development, so I am
> not sure everyone is aware. The last discussion on this topic,
>
> consent has been strongly to make gmake work.
>

We already took that approach to its limit, and I don't believe we can go
much further. Most of gmake works by luck. The simplest things break, make
no sense, and cannot be debugged, eg. sometimes *_add_files breaks, but
*_add_file works, despite the fact the former just calls the latter. There
are already some hacks in modules to work around gmake's brokenness...


>
> Another objection is that we got some heavy negative experience report
> from the serf community about SCONS.
>
>
It wasn't the entire "serf community", just brane@ on 30 Oct 2019:
---snip---
As a far-too-long-time user of Scons (in Serf), let me just add a
caution: Scons is very, very broken and not at all well maintained.
Writing a truly cross-platform, cross-toolchain SConstruct file for
anything other than really trivial cases amounts to writing a *lot* of
platform-specific Python code to make the builds work.

If you're already moving to gmake (without autotools, and I expect using
Cygwin on Windows), then I suggest you finish the transition, then leave
well enough alone.
---snip---

My experience so far has been exactly the opposite: it is far easier to get
scons building cross-platform, than GNU make + countless shell tools which
also drag in the whole of Cygwin.

To summarize quickly:
I tried to avoid scons before and use gmake, and we already got as far as
we could.
scons is not a decision I made lightly, it's a decision I made because it's
that good.
Python isn't my favorite language, but what we gain from scons is
significant enough for me to want to learn more Python.
By using scons, Cygwin left the building without me even trying.
scons has a 20 year history, supports OS/2 and numerous other platforms,
supports Python 2 and 3, supports more MSVC versions than we do (including
Visual Studio 2019), would allow us to build almost anywhere.
It is packed full of many advanced features we need, like symlinking
libX.so -> libX.so.2, automated header dependency scanning, flex, yacc,
Java, Objective C, precompiled headers on MSVC, fully parallelizes builds
across module boundaries, can work out minimal rebuilds using checksums of
file contents instead of inode timestamps, is extensible by design, has
readable source code, can be debugged, and is under a liberal license
(MIT). I've looked, and nothing else really comes close; every other build
tool would require considerable further development (AOO has already tried
building big build systems around both dmake and GNU make; my better
experience with Ant/Maven makes me more hopeful about a richer higher-level
build tool that automates more of the work internally).
The conversion from gbuild to scons would largely be automated, fast and
correct. (We could also keep the scons files in a format that would allow
easier automated conversion to something else later.)


> Which are switching from, SCONS to cmake.
>
>
> So in the end we do not have Consent where we want to go. And currently
> it is heavily influenced by Damjan. And this is imho very thin.
>
>
Then we were always very thin on gbuild too.

You've also done some scons development.

We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.


> I am still like the Idea most to go in the direction of ant / maven,
> despite its flaws. But I am not negative on SCONS either. My main point
> is we need something that
>
> offers a better architecture and is easier to handled and maintained.
>
>
> Also what we could try is making use of something like portage. Portage
> is pretty easy to use repostory manager used by gentoo, whioch also had
> a community prior to homebrew on mac. It is not very difficult to
> setup.  But it is build to make different build system work together. So
> we could have a build repository, that builds our dependencies. We
> reconstruct our monolith in smaller build libraries, like UNOcore,
> OOFrame, UNOGUI, OOapp, OOpython, StarBasic, OOwizards, extentionXYZ
> (Just saying something), and pick the best build system (cmake, gmake,
> ant, maven, SCONS) for each library. Also we could think on incubating
> Starbasic or UNO, as own Project if they become more interesting. Since
> Portage is made for source build, but can also handle binaries, maybe we

Re: Version Numbers in source code

[Damjan Jovanovic]

Hi

I don't think we ever convert 450 to 4.5.0. Where do you see that?

Damjan


On Sun, Mar 15, 2020 at 3:40 PM Carl Marcum  wrote:

> Hi All,
>
> I'm working on using Ant to build javadocs and package Java sources of
> some of the UNO libs.
> I need to include a version number in the name of the jar file like
> "jurt-4.5.0-javadoc.jar"
> so I'd like to set a version property in main/ant.properties to use.
>
> I haven't been able to find where the 4.5.0 version string is obtained
> that is used throughout the build.
> Is it derived from the UPD=450 environment variable or another way?
>
>  From what I can tell:
>
> 1. RSCVERSION=450 is originally set in main/solenv/inc/minor.mk
> 2. main/configure.ac sets UPD from main/solenv/inc/minor.mk
> 3. ant.properties is created by main/set_soenv (set_soenv.in) that uses
> the UPD var.
>
> But I'm at a dead end on the conversion of 4.5.0 from 450 if that's
> where it comes from.
>
> I don't want to make an assumption of single digits for
> major.minor.maintenance unless that's the case.
>
> Thanks,
> Carl
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: harmful code??

[Damjan Jovanovic]

On Sat, Apr 25, 2020 at 2:11 PM Peter Kovacs  wrote:

> Hello all,
>
> I hunt some Warnings and Errors that get logged during build.
>
> I stumbled over this code here in file_misc.cxx [1]:
>
> 684
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#684>*static*
>
> oslFileError
> <
> http://opengrok.openoffice.org/openoffice/s?defs=oslFileError=trunk>
>
> oslDoMoveFile
> <
> http://opengrok.openoffice.org/openoffice/s?refs=oslDoMoveFile=trunk>(
>
> *const* sal_Char
> *
>
> pszPath
> ,
> *const* sal_Char
> *
>
> pszDestPath
> <
> http://opengrok.openoffice.org/openoffice/s?refs=pszDestPath=trunk>)
>
> 685
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#685>{
>
> 686
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#686>oslFileError
>
> <
> http://opengrok.openoffice.org/openoffice/s?defs=oslFileError=trunk>
>
> tErr
> =osl_File_E_invalidError
>
> <
> http://opengrok.openoffice.org/openoffice/s?defs=osl_File_E_invalidError=trunk>;
>
> 687
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#687>688
>
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#688>tErr
>
>  =
> osl_psz_moveFile
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#osl_psz_moveFile>(pszPath
>
> ,pszDestPath
>
> <
> http://opengrok.openoffice.org/openoffice/s?defs=pszDestPath=trunk>);
>
> 689
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#689>*if*
>
> ( tErr
>  ==
> osl_File_E_None
> <
> http://opengrok.openoffice.org/openoffice/s?defs=osl_File_E_None=trunk>
>
> ) 690
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#690>{
>
> 691
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#691>*return*
>
> tErr
> ;
> 692
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#692>}
>
> 693
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#693>694
>
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#694>*if*
>
> ( tErr
>  !=
> osl_File_E_XDEV
> <
> http://opengrok.openoffice.org/openoffice/s?defs=osl_File_E_XDEV=trunk>
>
> ) 695
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#695>{
>
> 696
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#696>*return*
>
> tErr
> ;
> 697
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#697>}
>
> 698
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#698>699
>
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#699>tErr
>
> =osl_psz_copyFile
>
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#osl_psz_copyFile>(pszPath
>
> ,pszDestPath
>
> <
> http://opengrok.openoffice.org/openoffice/s?defs=pszDestPath=trunk>);
>
> 700
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#700>701
>
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#701>*if*
>
> ( tErr
>  !=
> osl_File_E_None
> <
> http://opengrok.openoffice.org/openoffice/s?defs=osl_File_E_None=trunk>
>
> ) 702
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#702>{
>
> 703
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#703>oslFileError
>
> <
> http://opengrok.openoffice.org/openoffice/s?defs=oslFileError=trunk>
>
> tErrRemove
> ;
>
> 704
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#704>tErrRemove
>
> <
> http://opengrok.openoffice.org/xref/trunk/main/sal/osl/unx/file_misc.cxx?r=3f12a67e#tErrRemove>=osl_psz_removeFile
>
> <
> 

Re: Issue in vbahelper

[Damjan Jovanovic]

On Fri, Apr 24, 2020 at 5:18 AM Peter Kovacs  wrote:

> Hello all,
>
> Build broke again, this time with Following Output:
>
> =
> Building module vbahelper
> =
>
> Entering /home/legine/workspace/AOO/gitbox/main/vbahelper/prj
>
> cd .. && make -s -r -j1   && make -s -r deliverlog
> [ info  ALL ] LinkTarget Library/libmsfilter.so not defined:
> Assuming headers to be there!
> [ build PKG ] vbahelper_inc
> [ build CXX ] vbahelper/source/msforms/service
> [ build CXX ] vbahelper/source/msforms/vbabutton
> [ build CXX ] vbahelper/source/msforms/vbacheckbox
> [ build CXX ] vbahelper/source/msforms/vbacombobox
> [ build CXX ] vbahelper/source/msforms/vbacontrol
> [ build CXX ] vbahelper/source/msforms/vbacontrols
> [ build CXX ] vbahelper/source/msforms/vbaframe
> [ build CXX ] vbahelper/source/msforms/vbaimage
> [ build CXX ] vbahelper/source/msforms/vbalabel
> [ build CXX ] vbahelper/source/msforms/vbalistbox
> [ build CXX ] vbahelper/source/msforms/vbalistcontrolhelper
> [ build CXX ] vbahelper/source/msforms/vbamultipage
> [ build CXX ] vbahelper/source/msforms/vbanewfont
> [ build CXX ] vbahelper/source/msforms/vbapages
> [ build CXX ] vbahelper/source/msforms/vbaprogressbar
> [ build CXX ] vbahelper/source/msforms/vbaradiobutton
> [ build CXX ] vbahelper/source/msforms/vbascrollbar
> [ build CXX ] vbahelper/source/msforms/vbaspinbutton
> [ build CXX ] vbahelper/source/msforms/vbasystemaxcontrol
> [ build CXX ] vbahelper/source/msforms/vbatextbox
> [ build CXX ] vbahelper/source/msforms/vbatogglebutton
> [ build CXX ] vbahelper/source/msforms/vbauserform
> [ build DEP ] LNK:Library/msforms.uno.so
> [ build CXX ] vbahelper/source/vbahelper/collectionbase
> [ build CXX ] vbahelper/source/vbahelper/vbaapplicationbase
>
> /home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
> fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
> compilation terminated.
> [ build CXX ] vbahelper/source/vbahelper/vbaapplicationbase
>
> /home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
> fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
> compilation terminated.
> /home/legine/workspace/AOO/gitbox/main/solenv/gbuild/Library.mk:48:
> *** gb_Deliver_deliver: file does not exist in solver, and cannot be
> delivered:
> /home/legine/workspace/AOO/gitbox/main/solver/450/
> unxlngx6.pro/lib/libmsfilter.so.
> Stop.
> dmake:  Error code 2, while making 'all'
>
> I guess this is a dependency Issue?
>
> [ info  ALL ] LinkTarget Library/libmsfilter.so not defined: Assuming
> headers to be there!
>
> And
>
> /home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
>
> fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
>
> and
>
> /home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
>
> fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
>
> sounds like some idl has not been executed. I guess if someone is lucky
> then some other build module does this.
>
>
> I try to just do a rerun, and cross fingers it will pass. Inn the
> meantime How do I check dependencies?
>
> Thanks
>
>
> All the Best
>
> Peter
>
>
main/vbahelper/prj/build.lst already lists filter as a dependency. It
sounds like the filter module failed to build?

Damjan

Re: Remove of STAX and SAXON

[Damjan Jovanovic]

On Sun, Apr 26, 2020 at 7:30 AM Peter Kovacs  wrote:

> Hello everyone,
>
> Pedro hinted STAX can be dropped, and STAX reference is only in the
> dependency of SAXON.
>
> I would like to add SAXON to the removal list. Since to my research no
> other module references SAXON as a dependency, and we have LIBXSLT in
> the stomach.
>
> So I think Saxon is obsolete.
>
>
main/filter also uses saxon:

$ grep saxon */prj/build.lst
filter/prj/build.lst:fl  filter  :L10N:l10n svtools unotools xmloff
cppu tools cppuhelper sal svx javaunohelper jvmaccess canvas SAXON:saxon
LIBXSLT:libxslt basegfx NULL
saxon/prj/build.lst:xx saxon : solenv stax NULL
saxon/prj/build.lst:xx saxon nmake - all xx_saxon NULL

Re: drop ressources (stlport, maybe beanshell)

[Damjan Jovanovic]

On Sat, Apr 25, 2020 at 3:50 AM Peter Kovacs  wrote:

>
> Another potential candidate to get Rid of is beanshell. I am looking
> into it, the project moved to Apache Commons. I hope that it is still
> there under a different name (beanUtil?)
>
>
See https://github.com/beanshell/beanshell#history
BeanShell was apparently only proposed as an incubator project, it never
entered incubation. Its current home is that GitHub project.

Re: about build environment development (was: declaring gbuild target dependencies)

[Damjan Jovanovic]

On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:

>
>
> > On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:
> >
> >
> > We are also thin on new contributors, and I recall you saying they're
> > largely scared off by the current build system.
> >
>
> Two points:
>
>   1. I doubt that by the time we finish porting to a whole new build
> system, we will even have anyone *wanting* to contribute. With each delay
> and push-out on releases, and more time spent working on the build system
> instead of AOO itself, we become less and less relevant. Is that really a
> priority we should be focusing on? Are the number of people knowledgeable
> around scons really greater than what we have now? But I could be wrong,
> which leads me to #2...
>
>
What would you recommend we focus on instead then?

Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.


>   2. "The conversion from gbuild to scons would largely be automated, fast
> and correct." If that is the case, let's test that theory right now.
>

This has been possible for some time. In the scons-build branch, you can do
the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic conversion:
understanding and converting specific gbuild commands, converting paths to
scons format, etc. but even so, we're on just 1913 lines of code in total
for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for which
this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):

#  AllLangResTarget(name)
#  (meta-target; delivers an empty timestamp file)
#^ ^
#   /   \
#  / \
# /   \
#  ResTarget(nameen-US,name,en-US)
ResTarget(nameen-GB,name,en-GB)
#  $(WORKDIR)/ResTarget/$(resName).res
$(WORKDIR)/ResTarget/$(resName).res
#  $(WORKDIR)/ResTarget/nameen-US.res
 $(WORKDIR)/ResTarget/nameen-GB.res
#^   ^^
#| rsc   ||
#|   ||
#  SrsTarget   SrsTarget
SrsTarget
#  $(WORKDIR)/SrsTarget/$(srsName).srs
#  $(WORKDIR)/SrsTarget/uui/res.srs
#^
#| concatenate
#+--+
#|   \
#|\
#  SrcPartTarget   SrcPartTarget
#  $(WORKDIR)/SrsPartTarget/$(srsPartName)
#  $(WORKDIR)/SrsPartTarget/uui/source/ids.src
#^   ^
#| rsc   | rsc
#|   |
# (when not translating) |   | (when translating)
#|   |
#|SrcPartMergeTarget
#|$(WORKDIR)/SrsPartMergeTarget/$(1)
#|
 $(WORKDIR)/SrsPartMergeTarget/uui/source/ids.src
#| ^
#|/
#|   / transex3
#|  / (when translating)
#  $(srsPartName)  /
#  uuid/source/ids.src
#

Damjan

Re: Small regression in trunk

[Damjan Jovanovic]

On Mon, May 18, 2020 at 9:41 AM Matthias Seidel 
wrote:

> Hi Damjan, all,
>
> Am 11.05.20 um 17:54 schrieb Matthias Seidel:
> > Hi Damjan,
> >
> > Am 11.05.20 um 17:48 schrieb Damjan Jovanovic:
> >> On Mon, May 11, 2020 at 5:25 PM Matthias Seidel <
> matthias.sei...@hamburg.de>
> >> wrote:
> >>
> >>> Hi Damjan,
> >>>
> >>> Is there a specific reason why you moved "sd/res/imagelst" to
> >>> "sd/imagelst" in this commit:
> >>>
> >>>
> >>>
> https://github.com/apache/openoffice/commit/b63233d868a9af170b0457a7aa0c5809011cc2c1
> >>>
> >>> The reason why I ask is that it breaks some icons in Draw/Impress
> >>> (Classic and Industrial icon set) and in help.
> >>>
> >>> If the change is mandatory, I would fix the location for the icon sets
> >>> and the paths in Help.
> >>>
> >>>
> >> Hi
> >>
> >> I can't remember, but looking through the git log, I see this which
> might
> >> explain it:
> >>
> >> commit c11f6e41367333ceec3dd9cdcb59a80bff914618
> >> Author: damjan 
> >> Date:   Wed Mar 16 03:50:45 2016 +
> >>
> >> Merge from branches/gbuild:
> >> * r1409617: sd2gbuild: removed unneeded Package_misc.mk
> >> * r1409614: sd2gbuild: removed not needed effects.xsl
> >> * r1409613: sd2gbuild: cleanup after migration to gbuild
> >> * r1409612: sd2gbuild: migrated sd to gbuild
> >> * r1409611: sd2gbuild: migrated sd to gbuild
> >> * r1409608: sd2gbuild: migrated module sd to gbuild
> >>
> >> Also updated lists of files (deleted and added by eg. sidebar)
> >> and had to rename
> >> main/default_images/sd/res/imagelst
> >> to
> >> main/default_images/sd/imglst
> >> to get it to build with gbuild (sw did the same).
> >>
> >> BUILDS
> >>
> >> Build updates by: me
> > OK, thanks!
> >
> > Then I will do some small fixes in "/ooo_custom_images" and help.
> >
> > That said, of course I will wait until Jim has branched off Dev2. ;-)
> >
> > Regards,
> >
> >Matthias
>
> This should be fixed now in trunk and AOO42X...
>
> In Draw/Impress, when using Navigator, all icons are now according to
> the chosen icon set again.
>
> Regards,
>
>Matthias
>
>
Great :)

Damjan

Re: Small regression in trunk

[Damjan Jovanovic]

On Mon, May 11, 2020 at 5:25 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Is there a specific reason why you moved "sd/res/imagelst" to
> "sd/imagelst" in this commit:
>
>
> https://github.com/apache/openoffice/commit/b63233d868a9af170b0457a7aa0c5809011cc2c1
>
> The reason why I ask is that it breaks some icons in Draw/Impress
> (Classic and Industrial icon set) and in help.
>
> If the change is mandatory, I would fix the location for the icon sets
> and the paths in Help.
>
>
Hi

I can't remember, but looking through the git log, I see this which might
explain it:

commit c11f6e41367333ceec3dd9cdcb59a80bff914618
Author: damjan 
Date:   Wed Mar 16 03:50:45 2016 +

Merge from branches/gbuild:
* r1409617: sd2gbuild: removed unneeded Package_misc.mk
* r1409614: sd2gbuild: removed not needed effects.xsl
* r1409613: sd2gbuild: cleanup after migration to gbuild
* r1409612: sd2gbuild: migrated sd to gbuild
* r1409611: sd2gbuild: migrated sd to gbuild
* r1409608: sd2gbuild: migrated module sd to gbuild

Also updated lists of files (deleted and added by eg. sidebar)
and had to rename
main/default_images/sd/res/imagelst
to
main/default_images/sd/imglst
to get it to build with gbuild (sw did the same).

BUILDS

Build updates by: me

Re: UNO knowledge

[Damjan Jovanovic]

Hi Patricia

Please elaborate?

Which bug?


On Sat, Sep 12, 2020 at 6:49 PM Patricia Shanahan  wrote:

> I have been working on a bug, and have reached the conclusion that a fix
> will require changes to the parsing of XML and recording of event
> actions. I am seriously handicapped in making progress on this because
> that happens in the depths of UNO, and I have zero UNO knowledge.
>
> Can anyone help?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Writer and .docx

[Damjan Jovanovic]

On Fri, Oct 16, 2020 at 4:24 PM Carl Marcum  wrote:

> Hi Damjan,
>
> On 10/16/20 9:23 AM, Damjan Jovanovic wrote:
> > On Fri, Oct 16, 2020 at 2:05 PM Dave Fisher 
> wrote:
> >
> >> Hi -
> >>
> >> Sent from my iPhone
> >>
> >>> On Oct 16, 2020, at 4:04 AM, Mechtilde  wrote:
> >>>
> >>> Hello Joost,
> >>>
> >>> I'm very happy to read from you.
> >>>
> >>>> Am 16.10.20 um 12:50 schrieb Joost Andrae:
> >>>> Hi Simon,
> >>>>
> >>>> it's an honor to me to see a sign of life of you here. Welcome !
> >>>>
> >>>> Instead of user picking here to get users leave from AOO to LO a
> >>>> developer could create a Java based OOo/LO extension that uses Apache
> >>>> POI to export OpenDocument type documents to MSXML formats by using
> the
> >>>> binary MSO export to export those documents to the MSXML format in
> >>>> between. Or maybe it's possible to XSL this document format by using
> >>>> OpenOffice together with Apache POI. Using XSL scripts (in AOO menu
> item
> >>>> XML filter settings) to make document conversions is possible within
> >> OOo.
> >>> I offer my help to test the implementation. sorry but I'm not a
> >>> programmer. So we as the project need help from Java programmers to
> work
> >>> on it and contribute it.
> >> I’m a PMC Member of Apache POI for over 12 years. My team donated the
> >> initial PowerPoint support and were involved in the initial support for
> >> OOXML.
> >>
> >> POI is embedded into Apache SOLr and Tika along with commercial
> products.
> >> The project took over the dormant XMLBeans project and is releasing a
> 4.0
> >> that supports modern Java.
> >>
> >> An OSGi bundle of POI will be available in the next release if you build
> >> from source.
> >>
> >> The Tika, POI, and PDFBox projects maintain a large regression corpus
> >> scraped from the internet using CommonCrawl. I’m sure that this could be
> >> shared in one way or another.
> >>
> >> Regards,
> >> Dave
> >>
> >>
> > Hi
> >
> > I did start writing a POI-based OOXML export filter for AOO some years
> ago
> > (search the dev mailing list), and got it to the point of being able to
> > save very basic spreadsheets (no formulas, no formatting, just text and
> > numbers).
> >
> > There were several major problems with using POI.
> >
> > Firstly the code in POI is at various stages of completeness. The legacy
> > XLS filter is very good, supports SAX parsing, etc. The DOC filter is
> > minimal and unmaintained. What we would need, the OOXML filter for at
> least
> > XLSX, is somewhere in between. AFAIK it only supports DOM parsing,
> meaning
> > everything needs to be in memory before it can be written to disk, so a
> big
> > spreadsheet could consume gigabytes of RAM during saving, and if you
> don't
> > have enough memory free, you can't save!
> >
> > Also I do use POI at work, and it's outstanding for parsing spreadsheets
> > (it can even parse some that AOO can't), but it's very memory hungry. A
> > spreadsheet with 10 rows consumed 6 GB of RAM, compared to 200 MB in
> LO
> > (30 times less). That isn't really POI's fault, Java has too much
> > per-object overhead and there are a great many objects in a spreadsheet
> > that big. So DOM + Java really do not add up to efficient memory usage.
> By
> > comparison, our current OOXML reading is not only SAX-based, but converts
> > XML tags to integers for faster comparisons and lower memory usage.
> >
> > Finally AOO itself had limitations that made developing a filter in Java
> > difficult. Each sheet in a spreadsheet has 1 billion cells. Obviously
> only
> > a minority of these contain data - most are empty. In C++ there are
> special
> > iterators that can be used to access only the non-empty cells, but these
> > are not exposed to UNO, or through it, to Java. The only way to tell
> which
> > cells are in use is to iterate over all 1 billion cells (per sheet),
> which
> > is hopelessly slow.
> >
> > Some of these problems can be solved. We can expose the cell iterators
> over
> > UNO. The memory usage might not matter that much in practice, and we
> could
> > patch POI to do SAX parsing/saving at a later stage. But users expect
> > fonts, styles, charts, images, custom formats, 

Re: Writer and .docx

[Damjan Jovanovic]

On Fri, Oct 16, 2020 at 2:05 PM Dave Fisher  wrote:

> Hi -
>
> Sent from my iPhone
>
> > On Oct 16, 2020, at 4:04 AM, Mechtilde  wrote:
> >
> > Hello Joost,
> >
> > I'm very happy to read from you.
> >
> >> Am 16.10.20 um 12:50 schrieb Joost Andrae:
> >> Hi Simon,
> >>
> >> it's an honor to me to see a sign of life of you here. Welcome !
> >>
> >> Instead of user picking here to get users leave from AOO to LO a
> >> developer could create a Java based OOo/LO extension that uses Apache
> >> POI to export OpenDocument type documents to MSXML formats by using the
> >> binary MSO export to export those documents to the MSXML format in
> >> between. Or maybe it's possible to XSL this document format by using
> >> OpenOffice together with Apache POI. Using XSL scripts (in AOO menu item
> >> XML filter settings) to make document conversions is possible within
> OOo.
> >
> > I offer my help to test the implementation. sorry but I'm not a
> > programmer. So we as the project need help from Java programmers to work
> > on it and contribute it.
>
> I’m a PMC Member of Apache POI for over 12 years. My team donated the
> initial PowerPoint support and were involved in the initial support for
> OOXML.
>
> POI is embedded into Apache SOLr and Tika along with commercial products.
> The project took over the dormant XMLBeans project and is releasing a 4.0
> that supports modern Java.
>
> An OSGi bundle of POI will be available in the next release if you build
> from source.
>
> The Tika, POI, and PDFBox projects maintain a large regression corpus
> scraped from the internet using CommonCrawl. I’m sure that this could be
> shared in one way or another.
>
> Regards,
> Dave
>
>
Hi

I did start writing a POI-based OOXML export filter for AOO some years ago
(search the dev mailing list), and got it to the point of being able to
save very basic spreadsheets (no formulas, no formatting, just text and
numbers).

There were several major problems with using POI.

Firstly the code in POI is at various stages of completeness. The legacy
XLS filter is very good, supports SAX parsing, etc. The DOC filter is
minimal and unmaintained. What we would need, the OOXML filter for at least
XLSX, is somewhere in between. AFAIK it only supports DOM parsing, meaning
everything needs to be in memory before it can be written to disk, so a big
spreadsheet could consume gigabytes of RAM during saving, and if you don't
have enough memory free, you can't save!

Also I do use POI at work, and it's outstanding for parsing spreadsheets
(it can even parse some that AOO can't), but it's very memory hungry. A
spreadsheet with 10 rows consumed 6 GB of RAM, compared to 200 MB in LO
(30 times less). That isn't really POI's fault, Java has too much
per-object overhead and there are a great many objects in a spreadsheet
that big. So DOM + Java really do not add up to efficient memory usage. By
comparison, our current OOXML reading is not only SAX-based, but converts
XML tags to integers for faster comparisons and lower memory usage.

Finally AOO itself had limitations that made developing a filter in Java
difficult. Each sheet in a spreadsheet has 1 billion cells. Obviously only
a minority of these contain data - most are empty. In C++ there are special
iterators that can be used to access only the non-empty cells, but these
are not exposed to UNO, or through it, to Java. The only way to tell which
cells are in use is to iterate over all 1 billion cells (per sheet), which
is hopelessly slow.

Some of these problems can be solved. We can expose the cell iterators over
UNO. The memory usage might not matter that much in practice, and we could
patch POI to do SAX parsing/saving at a later stage. But users expect
fonts, styles, charts, images, custom formats, OLE, pivot tables, VBA
macros, form controls, mathematical formulas, change tracking, etc. all
saved losslessly and 100% compatible with Excel, which doesn't only require
work in the filter, but in the rest of AOO too, and POI probably doesn't
support all of those features either.

I might get back into this next month, especially if others want to
collaborate, but don't expect something generally usable, let alone
Excel-quality XSLX saving, any time soon.

Regards
Damjan

poi-filter branch with initial OOXML/.xlsx export filter

[Damjan Jovanovic]

Hi

I've put together my previous work on an OOXML export filter for
spreadsheets, and pushed it into a branch called poi-filter.

So far it builds successfully, gets packaged, appears in the "Save" dialog,
loads, has all the right methods called, and gets to traversing and saving
the document, but fails with an exception because java.net.URLClassLoader
can't find the POI jars I jerryrigged.

To test:
1. Download poi-4.1.2.zip and extract it.
2. Copy all its jar files into $JAVA_HOME/jre/lib/ext as one flat directory
structure, eg. the jars in lib/ go into $JAVA_HOME/jre/lib/ext not
$JAVA_HOME/jre/lib/ext/lib. However, DON'T copy the junit jar, as it breaks
the build due to missing hamcrest. (Yes this is bad, but it's only
temporary.)
3. Build AOO as usual.
4. You should see a poi-filter.jar in
main/instsetoo_native/unxfbsdx/Apache_OpenOffice/installed/install/en-US/openoffice4/program/classes
:).
5. Start AOO.
6. Make a spreadsheet.
7. Type text and numbers.
8. Save, and choose "Microsoft Excel 2007 XML (.xlsx)"  :) :).
9. Click "Save" and confirm you don't want ODF.
10. It will error out but print log message to the console showing POI
wasn't found:

Asked to create org.apache.openoffice.poi.filter.ExcelFilter
Returning com.sun.star.lib.uno.helper.Factory@2b8a87fc
setSourceDocument()
filter!!!
Starting
java.lang.NoClassDefFoundError: org/apache/poi/xssf/streaming/SXSSFWorkbook
at org.apache.openoffice.poi.filter.ExcelFilter.filter(ExcelFilter.java:123)
Caused by: java.lang.ClassNotFoundException:
org.apache.poi.xssf.streaming.SXSSFWorkbook
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
at
java.base/java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:899)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 1 more

Once we correctly integrate POI into the build instead of using
$JAVA_HOME/jre/lib/ext, and it can be found, it should start writing
successfully (it did before). I tried making a fat jar with all the POI
jars and poi-filter.jar combined into one file, but that failed even
earlier.

How we integrate it into the build is an interesting question. All our
current external dependencies are downloaded as source, possibly patched,
and built ourselves. Building POI requires the whole of Gradle, which
usually needs Internet access to run. If we make an exception to that rule
and use the binaries directly, there are still 19 of them to deal with.
Maybe those who know POI better can help with this.

The code is in main/poi-filter. It's only a few hundred lines of Java at
this stage. It uses SXSSF already, and saves cells with strings and
numbers. I've cleaned it up to use the newer ComponentContext APIs instead
of ServiceManager, to use the new Java APIs for component registration,
etc. It's not clear to me whether we are integrating correctly, eg. I lie
we are also an import filter because otherwise we don't appear in the
"Save" dialog - write-only filters go to the File -> Export dialog instead.

A new filter, integrated overnight. Claims of our demise were greatly
exaggerated ;).
Damjan

Re: Writer and .docx

[Damjan Jovanovic]

On Fri, Oct 16, 2020 at 11:50 AM Bidouille  wrote:

> > OpenOffice users can open documents in .docx format, but they cannot
> > save in that format.
> Well, remember that last version of Microsoft Office (since 2016) can open
> ODT format.
>
>
Unfortunately not all MS Office editions have ODT support, and many people
I sent ODT to complained they can't open it.

Re: Writer and .docx

[Damjan Jovanovic]

On Sun, Oct 18, 2020 at 4:13 AM Dave Fisher  wrote:

> Hi -
>
> Top posting as well. I think we should consider our goals as a project. If
> one of those goals is support for ODF as a theory of everything office that
> you can trust and know will remain parsable a century from now then what
> does that mean for OOXML?
>
>
Saving to OOXML is probably our most requested feature, so users definitely
want it. Office suites are all about being broadly general and
interoperable, there is a reason why we have the longest and most complex
clipboard handling code I've ever seen, support for many raster and vector
image formats, allow scripting and component development in many languages,
and why we import and export documents in many formats from many vendors
spanning many decades. 80% of the time users use 20% of the features, but
there are many different groups of users each using a different 20% of the
features. Many here sound like they don't need saving to OOXML, but the
user groups that do (for whatever reason) will be negatively affected if we
don't support it.

As for ODF, LO is publishing ODF 1.3, so unless we keep up, we won't be
able to read all ODF soon either, let alone a century from now.


> I think it means that OpenOffice could be the arbiter of converting OOXML
> into ODF. As such I’m more interested of using tools like POI to drive that
> conversion into ODF and leave the other direction to the commercial vendors.
>
>
We should certainly collaborate more with POI. I have OOXML documents which
open in POI but have data missing when opened in AOO. We could compare what
POI does vs what AOO does to improve our OOXML filter. There are probably
similar cases where AOO is better and we could improve POI from it.


> There is a similar but more complex semantically conversion of PDF into
> ODF.
>
> Alternatively, maybe there is a way to enhance plug-ability of filters
> with more modern methods like OSGi.
>
>
I haven't had good experiences with OSGi, it breaks JDBC, breaks RMI, and
has problems with other cases where classes are dynamically loaded at
runtime without using OSGi's own APIs to do it. AOO's UNO can only load
classes at runtime and use custom classloaders.



> Regards,
> Dave
>
>
Regards
Damjan

Re: [openoffice] branch trunk updated: It seems we need YYDEBUG to compile main/connectivity now.

[Damjan Jovanovic]

On Mon, Oct 5, 2020 at 8:08 AM Don Lewis  wrote:

> On  5 Oct, dam...@apache.org wrote:
> > 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 9b7130f  It seems we need YYDEBUG to compile main/connectivity
> now.
> > 9b7130f is described below
>
> I haven't seen that here on either Linux or Windows.
>
>
>
Possibly only happens with my --enable-dbgutil --enable-symbols or other
flags.

Re: Apache Python Project

[Damjan Jovanovic]

Hi Kent

Welcome to Apache OpenOffice.

One of the major tasks we need Python development for at the moment is to
upgrade OpenOffice from Python 2 to 3. This is unfortunately quite
difficult, as we not only have to port Python code, but possibly C code
too, deal with patching, testing and packaging the module, and it has to
work on different platforms. It should however look really good on your
resume right now, as with Python 2 having recently become EOL, there should
be many companies looking to port code to Python 3. This task is tracked in
https://bz.apache.org/ooo/show_bug.cgi?id=123975 and we already got Python
3 working somewhat with system-provided Python on *nix, but not with
internally provided Python we typically use on eg. Windows.

Otherwise I see 33 other bugs with "python" in their summary at
https://bz.apache.org/ooo/buglist.cgi?query_format=advanced=---_desc=python_desc_type=allwordssubstr

It's pretty difficult to get started with OpenOffice development, so shout
if you need any help.

Regards
Damjan


On Mon, Oct 26, 2020 at 8:50 PM Kent Olson  wrote:

> Dear Apache Projects,
>
> I was interested in a project involved with Apache - Python programming. I
> went to UAT in 2017 and I need some practice because I have been out of the
> loop for awhile. I was wondering if I do a project, I could put you down on
> my resume?  I also need more info on how to get started.
>
> Sincerely,
>
> Kent Olson
> --
> [image: photo]
> *Kent Olson*
> Web Host, Global Virtual Opportunities
>
> (612) 391-8302 | varnau...@gmail.com
>
> https://olso1304.hostthenprofit.com/
> 616 Washington Ave SE Mpls, MN 55414
> Create your own email signature
> <
> https://www.wisestamp.com/create-own-signature/?utm_source=promotion_medium=signature_campaign=create_your_own=6184721375690752
> >
>

Re: QA Automated Test coverage

[Damjan Jovanovic]

On Sat, Oct 24, 2020 at 8:14 PM Carl Marcum  wrote:

> Hi All,
>
> I've been testing builds with the automated BVT and FVT tests lately.
> I have a few questions:
>
> 1. Is there anything documented about how much coverage these tests
> provide vs.functionality?
>
> 2. Is there yet a place to list new cases it would good to add test for?
>
> I think there is a lot that could be done in this area to attract new
> contributors if we had a place to work from.
> Both in documenting and work on some flaky tests that I've run into.
>
> I'm willing to put some effort into this, both organizing and developing.
>
>
Hi Carl

Thank you for helping with the tests.

I wrote a good email summarizing the different tests we have some years
ago, please see
https://lists.apache.org/thread.html/bb1851b82ba009d2cefdf5af9997099b6fdfb04bddac3753172f2698%401459253891%40%3Cdev.openoffice.apache.org%3E
Some things changed since then, eg. the smoketest location moved. There are
a few other emails too, search for them.

I also did some test fixes to bvt/fvt and others at various times. This
year I learned quite a lot about them. For example many tests fail because
they expect features that the .DOC file format cannot provide (such as
strikeout styles unique to .ODT), there were timeouts, registry
modifications had to be enabled to fix a test, confirmation dialogs that
hang the tests, a 2048 byte limit in FreeBSD's "ps" was causing a pid
lookup to fail, java.util.Calendar was being used incorrectly, etc. I fixed
some of these, but others remain. Understanding why the .DOC tests fail
requires understanding the .DOC file format, so fixing those tests isn't
easy. Look through the Git log, I wrote pretty descriptive commit messages.

One thing I didn't mention in that email is the thousands of unused tests
we have in main/qadevOOo, but they seem difficult to set up, and use a
custom test framework, not JUnit. They have a complex architecture, with
some code implementing UNO components and some code testing them. There
might even be code missing for some of them. There's a mixture of Java and
StarBasic tests there, with much duplication - were they first written in
one language then semi-ported to another?

Anyway I can't help much at the moment, but good luck and let us know how
it goes.

Damjan

Re: file serialization entry point

[Damjan Jovanovic]

On Thu, Jul 30, 2020 at 2:30 AM Kira Tsu  wrote:

> Hi,
>
> I'm completely new to OpenOffice and was grok'ing around to find the code
> that serializes spreadsheet files.  Can someone point me in the right
> direction, please?  Where in the codebase does it parse into memory and
> save out XLSX files?
>
> Thanks!
>

Hi

Apache OpenOffice never saves XLSX because its XLSX filter doesn't
implement saving. The reading-only filter is largely in main/oox.

Other spreadsheet filters, eg. for the legacy XLS format which can save,
are in main/sc/source/filter.

Some information on filter architecture and development can be found at:
https://wiki.openoffice.org/wiki/OpenOffice_filters_using_the_XML_based_file_format
https://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Integrating_Import_and_Export_Filters

Other Apache projects that may be of interest are http://poi.apache.org/
which reads and writes many Microsoft document file formats in Java.

All the best
Damjan

Automated gbuild -> SCons convertibility now at 88.57%

[Damjan Jovanovic]

Hi

In the scons-build branch, I've just pushed a set of 11 commits that
theoretically get 93 out of 105 gbuild modules (88.57%) automatically
converting to gbuild.

The "gotoSCons" converter and the SCons infrastructure in that branch have
now been developed to such a level that a module can be automatically
converted from gbuild to SCons, from where it can use SCons for all of the
following:
Building C/C++ objects
Linking shared libraries, static libraries, and executables
Building JUnit tests and running them
Building Google Tests and running them
Building .component files with XSLT
Running Ant sub-builds
Delivering "package" files such as headers
Even doing the impossibly difficult 5 step "AllLangResTarget" (.src ->
merged .src -> .srs -> .res for each language).

I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, but
I think only Jar and Zip are worth implementing automatic conversion for,
as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget in
only 2 places, which makes manual conversion for them easier. The hardest
conversions are already done.

Where does this leave us?

The gotoSCons converter can't support a number of features, like
non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, etc. A
module can only be automatically converted if it doesn't use the
unsupported features. Currently, 35 modules use only supported features,
and can be converted automatically (this should increase to 39 modules when
I add Jar and Zip conversion).

Another 58 modules use non-deterministic constructs or custom make rules.
Converting those 58 could be done through a semi-automated process, which
involves editing the gbuild files to remove the unsupported features,
running the automated conversion on what is left, then manually patching
what was removed into the conversion results. Sometimes this is quick and
easy, at other times probably not.

The final 12 modules use unsupported targets requiring a longer and mostly
manual conversion to SCons, though even there the supported targets could
be converted automatically.

The SCons infrastructure does require some cleanup, as I was learning while
developing, and we still need library naming conversions, tests on
Linux/WIndows/Mac, etc.

The more I've used SCons, the more I've liked it. I've even started using
it in my own projects at work now. I've found a way to solve every problem
I've encountered, and the SCons developers have been helpful when I asked
them questions. Complex functionality like header dependency scanning,
automatic directory creation for output files, using @responsefile for long
command lines when necessary, and other features gbuild implements
manually, all work in SCons automatically. In 1816 lines of code, our SCons
infrastructure implements what took gbuild 9418 lines, and SCons is far
more readable and maintainable (even in its current messy state).

The plan isn't to merge this to trunk any time soon. Rather the idea is to
develop the converter even further, then when it's complete enough, convert
as many gbuild modules to SCons. Then measure performance of building those
modules en-masse with SCons alone - if there are performance problems at
that stage, they are only going to get worse with more modules.

The real test however is converting the other 78 dmake modules to SCons. 37
of them are 3rd party "externals" like jpeg and zlib, which have their own
build systems that we just call, so conversion is relatively easy. The
other 41 modules are hard to convert, but gbuild is one of the reasons that
they were hard, and where SCons is expected to make the greatest
difference. Only once we are building without dmake, without gbuild,
without build.pl, without Cygwin, on all platforms, then it would be the
right time to merge to trunk.

If at some stage in this process we are unhappy with SCons, and some better
build system can be found, it shouldn't be difficult to change to it. The
converter could output files for that other build system instead; at
present it's only 498 lines of code in 1 file, that are involved in writing
SCons build files, all we would need is a similar file for that other build
system.

Build systems are not the most exciting part of development, but bad build
systems make development painful, and as a large multi-platform project, we
build a lot. We answer build-related questions on the mailing lists too
often, and new contributors are put off by the current build system. A lot
of what we want to do with AOO, such as ports to Win64, AArch64, newer MSVC
versions, and so on, also involve build-related changes.

Damjan

Re: Automated gbuild -> SCons convertibility now at 88.57%

[Damjan Jovanovic]

scripting is a dmake module with no symbols
package is a gbuild module with symbols

So yes, as we move off dmake, more and more modules should have working
debug symbols.

This is the case on *nix too, where dmake doesn't provide full paths to
filenames, breaking debugging.

On Sat, Jul 4, 2020 at 9:35 PM Patricia Shanahan  wrote:

> On 7/4/2020 12:24 PM, Damjan Jovanovic wrote:
> > Given how I've only developed on FreeBSD so far, anything Windows is
> > probably at negative infinity :) >
> > Do you have some example modules with that symbols problem, or at least
> > know whether they are gbuild or dmake modules?
>
> c:\OpenOfficeDev\openoffice\main\scripting\source\protocolhandler\scripthandler.cxx
>
> does not have symbols.
>
> c:\OpenOfficeDev\openoffice\main\package\source\xstor\xstorage.cxx does
> have symbols generated.
>
>
> > On Sat, Jul 4, 2020 at 9:13 PM Patricia Shanahan  wrote:
> >
> >> In the new build system, what is the status of automatic symbol
> >> generation, needed for easy debug.
> >>
> >> It is badly broken in 4.1.7, with most modules not getting symbols
> >> generated despite --enable-symbols in the configure parameters. This has
> >> cost me weeks of work on a debug project.
> >>
> >> On 7/4/2020 11:44 AM, Damjan Jovanovic wrote:
> >>> Hi
> >>>
> >>> In the scons-build branch, I've just pushed a set of 11 commits that
> >>> theoretically get 93 out of 105 gbuild modules (88.57%) automatically
> >>> converting to gbuild.
> >>>
> >>> The "gotoSCons" converter and the SCons infrastructure in that branch
> >> have
> >>> now been developed to such a level that a module can be automatically
> >>> converted from gbuild to SCons, from where it can use SCons for all of
> >> the
> >>> following:
> >>> Building C/C++ objects
> >>> Linking shared libraries, static libraries, and executables
> >>> Building JUnit tests and running them
> >>> Building Google Tests and running them
> >>> Building .component files with XSLT
> >>> Running Ant sub-builds
> >>> Delivering "package" files such as headers
> >>> Even doing the impossibly difficult 5 step "AllLangResTarget" (.src ->
> >>> merged .src -> .srs -> .res for each language).
> >>>
> >>> I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget,
> >> but
> >>> I think only Jar and Zip are worth implementing automatic conversion
> for,
> >>> as SdiTarget and UnoApi are only used in 5 places each, and
> WinResTarget
> >> in
> >>> only 2 places, which makes manual conversion for them easier. The
> hardest
> >>> conversions are already done.
> >>>
> >>> Where does this leave us?
> >>>
> >>> The gotoSCons converter can't support a number of features, like
> >>> non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules,
> >> etc. A
> >>> module can only be automatically converted if it doesn't use the
> >>> unsupported features. Currently, 35 modules use only supported
> features,
> >>> and can be converted automatically (this should increase to 39 modules
> >> when
> >>> I add Jar and Zip conversion).
> >>>
> >>> Another 58 modules use non-deterministic constructs or custom make
> rules.
> >>> Converting those 58 could be done through a semi-automated process,
> which
> >>> involves editing the gbuild files to remove the unsupported features,
> >>> running the automated conversion on what is left, then manually
> patching
> >>> what was removed into the conversion results. Sometimes this is quick
> and
> >>> easy, at other times probably not.
> >>>
> >>> The final 12 modules use unsupported targets requiring a longer and
> >> mostly
> >>> manual conversion to SCons, though even there the supported targets
> could
> >>> be converted automatically.
> >>>
> >>> The SCons infrastructure does require some cleanup, as I was learning
> >> while
> >>> developing, and we still need library naming conversions, tests on
> >>> Linux/WIndows/Mac, etc.
> >>>
> >>> The more I've used SCons, the more I've liked it. I've even started
> using
> >>> it in my own projects at work now. I've found a way to solve every
> >> problem
> >>> I

Re: Automated gbuild -> SCons convertibility now at 88.57%

[Damjan Jovanovic]

Given how I've only developed on FreeBSD so far, anything Windows is
probably at negative infinity :).

Do you have some example modules with that symbols problem, or at least
know whether they are gbuild or dmake modules?

On Sat, Jul 4, 2020 at 9:13 PM Patricia Shanahan  wrote:

> In the new build system, what is the status of automatic symbol
> generation, needed for easy debug.
>
> It is badly broken in 4.1.7, with most modules not getting symbols
> generated despite --enable-symbols in the configure parameters. This has
> cost me weeks of work on a debug project.
>
> On 7/4/2020 11:44 AM, Damjan Jovanovic wrote:
> > Hi
> >
> > In the scons-build branch, I've just pushed a set of 11 commits that
> > theoretically get 93 out of 105 gbuild modules (88.57%) automatically
> > converting to gbuild.
> >
> > The "gotoSCons" converter and the SCons infrastructure in that branch
> have
> > now been developed to such a level that a module can be automatically
> > converted from gbuild to SCons, from where it can use SCons for all of
> the
> > following:
> > Building C/C++ objects
> > Linking shared libraries, static libraries, and executables
> > Building JUnit tests and running them
> > Building Google Tests and running them
> > Building .component files with XSLT
> > Running Ant sub-builds
> > Delivering "package" files such as headers
> > Even doing the impossibly difficult 5 step "AllLangResTarget" (.src ->
> > merged .src -> .srs -> .res for each language).
> >
> > I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget,
> but
> > I think only Jar and Zip are worth implementing automatic conversion for,
> > as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget
> in
> > only 2 places, which makes manual conversion for them easier. The hardest
> > conversions are already done.
> >
> > Where does this leave us?
> >
> > The gotoSCons converter can't support a number of features, like
> > non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules,
> etc. A
> > module can only be automatically converted if it doesn't use the
> > unsupported features. Currently, 35 modules use only supported features,
> > and can be converted automatically (this should increase to 39 modules
> when
> > I add Jar and Zip conversion).
> >
> > Another 58 modules use non-deterministic constructs or custom make rules.
> > Converting those 58 could be done through a semi-automated process, which
> > involves editing the gbuild files to remove the unsupported features,
> > running the automated conversion on what is left, then manually patching
> > what was removed into the conversion results. Sometimes this is quick and
> > easy, at other times probably not.
> >
> > The final 12 modules use unsupported targets requiring a longer and
> mostly
> > manual conversion to SCons, though even there the supported targets could
> > be converted automatically.
> >
> > The SCons infrastructure does require some cleanup, as I was learning
> while
> > developing, and we still need library naming conversions, tests on
> > Linux/WIndows/Mac, etc.
> >
> > The more I've used SCons, the more I've liked it. I've even started using
> > it in my own projects at work now. I've found a way to solve every
> problem
> > I've encountered, and the SCons developers have been helpful when I asked
> > them questions. Complex functionality like header dependency scanning,
> > automatic directory creation for output files, using @responsefile for
> long
> > command lines when necessary, and other features gbuild implements
> > manually, all work in SCons automatically. In 1816 lines of code, our
> SCons
> > infrastructure implements what took gbuild 9418 lines, and SCons is far
> > more readable and maintainable (even in its current messy state).
> >
> > The plan isn't to merge this to trunk any time soon. Rather the idea is
> to
> > develop the converter even further, then when it's complete enough,
> convert
> > as many gbuild modules to SCons. Then measure performance of building
> those
> > modules en-masse with SCons alone - if there are performance problems at
> > that stage, they are only going to get worse with more modules.
> >
> > The real test however is converting the other 78 dmake modules to SCons.
> 37
> > of them are 3rd party "externals" like jpeg and zlib, which have their
> own
> > build systems that we just call, so conversion is relatively easy. The
> > other 41 modul

Re: Automated gbuild -> SCons convertibility now at 88.57%

[Damjan Jovanovic]

On Sun, Jul 5, 2020 at 7:27 AM Peter  wrote:

> Awesome Damjan,
>
>
Thank you :)


> I had a talk with SCons on freenode IRC. they liked the plan to move to
> SCons a lot.
>
> And did support us right a way. :) So I am poretty confidant that SCons
> will do the trick.
>
> How did you talk to SCon people?
>
>
That's great.

We talked on the scons-us...@scons.org mailing list.



>
> I think there is are some more tools that we need to examine before we
> can drop Cygwin.
>
> http://www.openoffice.org/tools/build_env_tools.html
>
>
That list is missing idlc, if not others. And what does that mean? Those
tools are built by the "Executable" targets which we already support.

With the changes I just pushed, AllLangResTarget from main/uui built fine
in "cmd" on my first try (with Python and SCons installed outside Cygwin),
though I do want to check that the paths passed to rsc.exe are correct. My
MSVC is broken, so I can't test the binary targets.


>
> I have to look at the SCons. I plan to build GSICheck also with SCons,
> even if it is a total simple tool.
>
>
Ok great.


>
> All the best.
>
> Peter
>
>
You too
Damjan


>
> Am 04.07.20 um 20:44 schrieb Damjan Jovanovic:
> > Hi
> >
> > In the scons-build branch, I've just pushed a set of 11 commits that
> > theoretically get 93 out of 105 gbuild modules (88.57%) automatically
> > converting to gbuild.
> >
> > The "gotoSCons" converter and the SCons infrastructure in that branch
> have
> > now been developed to such a level that a module can be automatically
> > converted from gbuild to SCons, from where it can use SCons for all of
> the
> > following:
> > Building C/C++ objects
> > Linking shared libraries, static libraries, and executables
> > Building JUnit tests and running them
> > Building Google Tests and running them
> > Building .component files with XSLT
> > Running Ant sub-builds
> > Delivering "package" files such as headers
> > Even doing the impossibly difficult 5 step "AllLangResTarget" (.src ->
> > merged .src -> .srs -> .res for each language).
> >
> > I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget,
> but
> > I think only Jar and Zip are worth implementing automatic conversion for,
> > as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget
> in
> > only 2 places, which makes manual conversion for them easier. The hardest
> > conversions are already done.
> >
> > Where does this leave us?
> >
> > The gotoSCons converter can't support a number of features, like
> > non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules,
> etc. A
> > module can only be automatically converted if it doesn't use the
> > unsupported features. Currently, 35 modules use only supported features,
> > and can be converted automatically (this should increase to 39 modules
> when
> > I add Jar and Zip conversion).
> >
> > Another 58 modules use non-deterministic constructs or custom make rules.
> > Converting those 58 could be done through a semi-automated process, which
> > involves editing the gbuild files to remove the unsupported features,
> > running the automated conversion on what is left, then manually patching
> > what was removed into the conversion results. Sometimes this is quick and
> > easy, at other times probably not.
> >
> > The final 12 modules use unsupported targets requiring a longer and
> mostly
> > manual conversion to SCons, though even there the supported targets could
> > be converted automatically.
> >
> > The SCons infrastructure does require some cleanup, as I was learning
> while
> > developing, and we still need library naming conversions, tests on
> > Linux/WIndows/Mac, etc.
> >
> > The more I've used SCons, the more I've liked it. I've even started using
> > it in my own projects at work now. I've found a way to solve every
> problem
> > I've encountered, and the SCons developers have been helpful when I asked
> > them questions. Complex functionality like header dependency scanning,
> > automatic directory creation for output files, using @responsefile for
> long
> > command lines when necessary, and other features gbuild implements
> > manually, all work in SCons automatically. In 1816 lines of code, our
> SCons
> > infrastructure implements what took gbuild 9418 lines, and SCons is far
> > more readable and maintainable (even in its current messy state).
> >
> > The plan isn't to merge this to trunk any time soon. Rather the idea

Re: Our OpenGrok server

[Damjan Jovanovic]

Can you please also see if we can set tab size to 4 spaces?

On Sat, Jul 18, 2020 at 10:08 AM Peter Kovacs  wrote:

> I have admin access. I will look into it asap.
>
>
> Am 16.07.20 um 11:42 schrieb Matthias Seidel:
> > Hi all,
> >
> > Our OpenGrok server needs some attention:
> > http://openoffice-vm1-he-de.apache.org/
> >
> > The index was last updated on Wednesday June 10.
> >
> > I would also like to have it available under something like:
> > https://opengrok.openoffice.org.
> >
> > Does anyone have administrative access?
> >
> > Subdomain/certificate would be a task for Infra?
> >
> > Regards,
> >
> > Matthias
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [openoffice] branch trunk updated (053307f -> 15daf39)

[Damjan Jovanovic]

Hi

Thank you.

I've been testing them, they work.

Regards
Damjan


On Sun, Jul 26, 2020 at 5:54 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> The Windows buildbot for trunk did succeed and I don't see any problems.
> But is there any way to test your changes?
>
> I would like to cherry-pick these commits for AOO42X.
>
> Regards,
>
>Matthias
>
> Am 25.07.20 um 17:28 schrieb dam...@apache.org:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > damjan pushed a change to branch trunk
> > in repository https://gitbox.apache.org/repos/asf/openoffice.git.
> >
> >
> > from 053307f  Updated link in SDK
> >  new 02463ba  Update com.sun.star.comp.ScriptProtocolHandler to use
> XComponentContext.
> >  new 15daf39  Improve parsing of script URLs and detection of
> in-document macros therein, as per the excellent sample code in
> main/dbaccess/source/ext/macromigration/migrationengine.cxx method
> MigrationEngine_Impl::impl_adjustScriptLibrary_nothrow().
> >
> > The 2 revisions listed above as "new" are entirely new to this
> > repository and will be described in separate emails.  The revisions
> > listed as "add" were already present in the repository and have only
> > been added to this reference.
> >
> >
> > Summary of changes:
> >  .../source/protocolhandler/scripthandler.cxx   | 93
> +++---
> >  .../source/protocolhandler/scripthandler.hxx   |  9 +--
> >  main/sfx2/source/doc/objmisc.cxx   | 19 +++--
> >  3 files changed, 45 insertions(+), 76 deletions(-)
> >
>
>

Re: Help w/ bt

[Damjan Jovanovic]

Well done!

On Thu, Dec 3, 2020 at 7:09 PM Jim Jagielski  wrote:

> fixed: it was a strcpy overflow.
>
> > On Dec 2, 2020, at 9:02 PM, Damjan Jovanovic  wrote:
> >
> > That's in main/soltools.
> >
> > Try isolate the exact command used, and try run that problematic
> > makedeepend binary in a debugger with the same args. 4 = SIGILL, a bad
> > sign, possibly a buffer overflow because the absolute filesystem path to
> > AOO is too long, or other such.
> >
> > On Wed, Dec 2, 2020 at 9:31 PM Jim Jagielski  j...@jagunet.com>> wrote:
> >
> >> Building --enable-debug is causing a weird issue...
> >>
> >> ../unxmaccx.pro/bin/makedepend: error:  got signal 4
> >> dmake:  Error code 1, while making '../unxmaccx.pro/obj/checkdll.obj'
> >> dmake:  '../unxmaccx.pro/obj/checkdll.obj' removed.
> >>
> >> I'm not sure if this is macOS specific or whether or not doing so breaks
> >> on other platforms as well... anyone know before I spin up another VM
> and
> >> test?
> >>
> >>> On Dec 2, 2020, at 10:25 AM, Damjan Jovanovic 
> wrote:
> >>>
> >>> On Wed, Dec 2, 2020 at 3:35 PM Jim Jagielski  j...@jagunet.com>  >> j...@jagunet.com>> wrote:
> >>>
> >>>> So I've been working on some of the macOS bugz and am looking at the
> UNO
> >>>> bridge as a likely subject, hence the various changes to the macOS
> code
> >>>> there. I'm hoping someone can help me with this crash.
> >>>>
> >>>> I open up Extension Manager, hit check for updates and AOO immediately
> >>>> dies, with the following bt. Any ideas?
> >>>>
> >>>> Thread 5 Crashed:
> >>>> 0   libobjc.A.dylib 0x7fff6d7c381d
> objc_msgSend
> >> +
> >>>> 29
> >>>> 1   libvcl.dylib0x0001046a400f
> >>>>
> >>
> DragSource::initialize(com::sun::star::uno::Sequence
> >>>> const&) + 175
> >>>> 2   libuno_cppuhelpers5abi.dylib0x00010308b1a0
> >>>>
> >>
> cppu::OSingleFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >>>> const&,
> >>>> com::sun::star::uno::Reference
> >>>> const&) + 128
> >>>> 3   libuno_cppuhelpers5abi.dylib0x00010308bffd
> >>>>
> >>
> cppu::OFactoryComponentHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >>>> const&,
> >>>> com::sun::star::uno::Reference
> >>>> const&) + 77
> >>>> 4   libuno_cppuhelpers5abi.dylib0x00010308c102 non-virtual
> >>>> thunk to
> >>>>
> >>
> cppu::OFactoryComponentHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >>>> const&,
> >>>> com::sun::star::uno::Reference
> >>>> const&) + 18
> >>>> 5   libuno_cppuhelpers5abi.dylib0x00010308da68
> >>>>
> >>
> cppu::ORegistryFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >>>> const&,
> >>>> com::sun::star::uno::Reference
> >>>> const&) + 56
> >>>> 6   libuno_cppuhelpers5abi.dylib0x00010308dc62 non-virtual
> >>>> thunk to
> >>>>
> >>
> cppu::ORegistryFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >>>> const&,
> >>>> com::sun::star::uno::Reference
> >>>> const&) + 18
> >>>> 7   bootstrap.uno.dylib 0x00010b9e7c8c
> >>>>
> >>
> stoc_smgr::OServiceManager::createInstanceWithArgumentsAndContext(rtl::OUString
> >>>> const&, com::sun::star::uno::Sequence
> const&,
> >>>> com::sun::star::uno::Reference
> >>>> const&) + 236
> >>>> 8   bootstrap.uno.dylib 0x00010b9e807f non-virtual
> >>>> thunk to
> >>>> stoc_smgr::OServiceManager::createInstanceWithArguments(rtl::OUString
> >>>> const&, com::sun::star::uno::Sequence
> const&)
> >> + 31
> >>>> 9   libvcl.dylib0x00010495b4fd
> >>>> Window::GetDragSource() + 813
> >>>> 10  libvcl.dylib0x00010495adf4
> >>>> 

Re: [discussion] future embedded DB in AOO

[Damjan Jovanovic]

On Mon, Dec 7, 2020 at 8:38 PM Peter Kovacs  wrote:

> Hi all,
>
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).
>
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
>
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
>
> What are your thoughts?
>
>
Whatever we do, we have to provide backward compatibility for HSQLDB.

I am more interested in something like Apache Calcite, which would let us
do SQL queries spanning multiple database backends, than in yet another
database backend.

SQLite is interesting because it's very widely used, runs on iPhone and
Android, is a single file, performs well, and is lightweight.

The hard part is getting the database to write into .ODB files instead of
what it natively uses?

Damjan

Re: Help w/ bt

[Damjan Jovanovic]

That's in main/soltools.

Try isolate the exact command used, and try run that problematic
makedeepend binary in a debugger with the same args. 4 = SIGILL, a bad
sign, possibly a buffer overflow because the absolute filesystem path to
AOO is too long, or other such.

On Wed, Dec 2, 2020 at 9:31 PM Jim Jagielski  wrote:

> Building --enable-debug is causing a weird issue...
>
> ../unxmaccx.pro/bin/makedepend: error:  got signal 4
> dmake:  Error code 1, while making '../unxmaccx.pro/obj/checkdll.obj'
> dmake:  '../unxmaccx.pro/obj/checkdll.obj' removed.
>
> I'm not sure if this is macOS specific or whether or not doing so breaks
> on other platforms as well... anyone know before I spin up another VM and
> test?
>
> > On Dec 2, 2020, at 10:25 AM, Damjan Jovanovic  wrote:
> >
> > On Wed, Dec 2, 2020 at 3:35 PM Jim Jagielski  j...@jagunet.com>> wrote:
> >
> >> So I've been working on some of the macOS bugz and am looking at the UNO
> >> bridge as a likely subject, hence the various changes to the macOS code
> >> there. I'm hoping someone can help me with this crash.
> >>
> >> I open up Extension Manager, hit check for updates and AOO immediately
> >> dies, with the following bt. Any ideas?
> >>
> >> Thread 5 Crashed:
> >> 0   libobjc.A.dylib 0x7fff6d7c381d objc_msgSend
> +
> >> 29
> >> 1   libvcl.dylib0x0001046a400f
> >>
> DragSource::initialize(com::sun::star::uno::Sequence
> >> const&) + 175
> >> 2   libuno_cppuhelpers5abi.dylib0x00010308b1a0
> >>
> cppu::OSingleFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >> const&,
> >> com::sun::star::uno::Reference
> >> const&) + 128
> >> 3   libuno_cppuhelpers5abi.dylib0x00010308bffd
> >>
> cppu::OFactoryComponentHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >> const&,
> >> com::sun::star::uno::Reference
> >> const&) + 77
> >> 4   libuno_cppuhelpers5abi.dylib0x00010308c102 non-virtual
> >> thunk to
> >>
> cppu::OFactoryComponentHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >> const&,
> >> com::sun::star::uno::Reference
> >> const&) + 18
> >> 5   libuno_cppuhelpers5abi.dylib0x00010308da68
> >>
> cppu::ORegistryFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >> const&,
> >> com::sun::star::uno::Reference
> >> const&) + 56
> >> 6   libuno_cppuhelpers5abi.dylib0x00010308dc62 non-virtual
> >> thunk to
> >>
> cppu::ORegistryFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> >> const&,
> >> com::sun::star::uno::Reference
> >> const&) + 18
> >> 7   bootstrap.uno.dylib 0x00010b9e7c8c
> >>
> stoc_smgr::OServiceManager::createInstanceWithArgumentsAndContext(rtl::OUString
> >> const&, com::sun::star::uno::Sequence const&,
> >> com::sun::star::uno::Reference
> >> const&) + 236
> >> 8   bootstrap.uno.dylib 0x00010b9e807f non-virtual
> >> thunk to
> >> stoc_smgr::OServiceManager::createInstanceWithArguments(rtl::OUString
> >> const&, com::sun::star::uno::Sequence const&)
> + 31
> >> 9   libvcl.dylib0x00010495b4fd
> >> Window::GetDragSource() + 813
> >> 10  libvcl.dylib0x00010495adf4
> >> Window::GetDropTarget() + 84
> >> 11  libsvt.dylib0x000103adb2cf
> >> DropTargetHelper::DropTargetHelper(Window*) + 63
> >> 12  libsvt.dylib0x000103992f2b
> >> SvLBox::SvLBox(Window*, ResId const&) + 139
> >> 13  libsvt.dylib0x00010399b6f9
> >> SvTreeListBox::SvTreeListBox(Window*, ResId const&) + 25
> >> 14  libsvxcore.dylib0x0001052392d5
> >> SvxCheckListBox::SvxCheckListBox(Window*, ResId const&, Image const&,
> Image
> >> const&) + 21
> >> 15  libdeploymentgui.uno.dylib  0x00010320672a
> >> dp_gui::UpdateDialog::CheckListBox::CheckListBox(dp_gui::UpdateDialog&,
> >> ResId const&, Image const&, Image const&) + 26
> >> 16  libdeploymentgui.uno.dylib  0x0001032035f5
> >>
> dp_gui::UpdateDialog::UpdateDialog(com

Re: Help w/ bt

[Damjan Jovanovic]

On Wed, Dec 2, 2020 at 3:35 PM Jim Jagielski  wrote:

> So I've been working on some of the macOS bugz and am looking at the UNO
> bridge as a likely subject, hence the various changes to the macOS code
> there. I'm hoping someone can help me with this crash.
>
> I open up Extension Manager, hit check for updates and AOO immediately
> dies, with the following bt. Any ideas?
>
> Thread 5 Crashed:
> 0   libobjc.A.dylib 0x7fff6d7c381d objc_msgSend +
> 29
> 1   libvcl.dylib0x0001046a400f
> DragSource::initialize(com::sun::star::uno::Sequence
> const&) + 175
> 2   libuno_cppuhelpers5abi.dylib0x00010308b1a0
> cppu::OSingleFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> const&,
> com::sun::star::uno::Reference
> const&) + 128
> 3   libuno_cppuhelpers5abi.dylib0x00010308bffd
> cppu::OFactoryComponentHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> const&,
> com::sun::star::uno::Reference
> const&) + 77
> 4   libuno_cppuhelpers5abi.dylib0x00010308c102 non-virtual
> thunk to
> cppu::OFactoryComponentHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> const&,
> com::sun::star::uno::Reference
> const&) + 18
> 5   libuno_cppuhelpers5abi.dylib0x00010308da68
> cppu::ORegistryFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> const&,
> com::sun::star::uno::Reference
> const&) + 56
> 6   libuno_cppuhelpers5abi.dylib0x00010308dc62 non-virtual
> thunk to
> cppu::ORegistryFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence
> const&,
> com::sun::star::uno::Reference
> const&) + 18
> 7   bootstrap.uno.dylib 0x00010b9e7c8c
> stoc_smgr::OServiceManager::createInstanceWithArgumentsAndContext(rtl::OUString
> const&, com::sun::star::uno::Sequence const&,
> com::sun::star::uno::Reference
> const&) + 236
> 8   bootstrap.uno.dylib 0x00010b9e807f non-virtual
> thunk to
> stoc_smgr::OServiceManager::createInstanceWithArguments(rtl::OUString
> const&, com::sun::star::uno::Sequence const&) + 31
> 9   libvcl.dylib0x00010495b4fd
> Window::GetDragSource() + 813
> 10  libvcl.dylib0x00010495adf4
> Window::GetDropTarget() + 84
> 11  libsvt.dylib0x000103adb2cf
> DropTargetHelper::DropTargetHelper(Window*) + 63
> 12  libsvt.dylib0x000103992f2b
> SvLBox::SvLBox(Window*, ResId const&) + 139
> 13  libsvt.dylib0x00010399b6f9
> SvTreeListBox::SvTreeListBox(Window*, ResId const&) + 25
> 14  libsvxcore.dylib0x0001052392d5
> SvxCheckListBox::SvxCheckListBox(Window*, ResId const&, Image const&, Image
> const&) + 21
> 15  libdeploymentgui.uno.dylib  0x00010320672a
> dp_gui::UpdateDialog::CheckListBox::CheckListBox(dp_gui::UpdateDialog&,
> ResId const&, Image const&, Image const&) + 26
> 16  libdeploymentgui.uno.dylib  0x0001032035f5
> dp_gui::UpdateDialog::UpdateDialog(com::sun::star::uno::Reference
> const&, Window*,
> std::__1::vector,
> std::__1::allocator
> > > const&, std::__1::vector std::__1::allocator >*) + 565
> 17  libdeploymentgui.uno.dylib  0x000103215991
> dp_gui::ExtensionCmdQueue::Thread::_checkForUpdates(std::__1::vector,
> std::__1::allocator
> > > const&) + 113
> 18  libdeploymentgui.uno.dylib  0x0001032145da
> dp_gui::ExtensionCmdQueue::Thread::execute() + 906
> 19  libdeploymentgui.uno.dylib  0x0001031fffa7 non-virtual
> thunk to dp_gui::Thread::run() + 23
> 20  libsofficeapp.dylib 0x000102e4ee9f threadFunc + 15
> 21  libuno_sal.dylib0x000102c22cf9 0x102c1b000 +
> 31993
> 22  libsystem_pthread.dylib 0x7fff6eb7d109 _pthread_start
> + 148
> 23  libsystem_pthread.dylib 0x7fff6eb78b8b thread_start +
> 15
>
>
>
Looks like the update dialog contains a "treelistbox" which attempts to
initialize drag-and-drop, and DragSource::initialize() in frame 1 then does
something to cause the crash.

Can you drag-and-drop within AOO generally, eg. drag a file from your file
manager into Writer?

The code seems to be in
http://opengrok.openoffice.org/xref/trunk/main/vcl/aqua/source/dtrans/DragSource.cxx?r=9f62ea84#183

Make a debug build (which should have line numbers), and show us the stack
trace from that?

Alternatively, if you know a recent version in which the update dialog
didn't crash, "git bisect" to find the offending commit.

Damjan

Re: [OPINION VOTE] CentOS7 or Ubuntu 14.04

[Damjan Jovanovic]

On Tue, Nov 10, 2020 at 7:58 PM Jim Jagielski  wrote:

> History: For previous AOO releases (up to 4.1.8), we have used
>  CentOS5 as our build environ for our community builds.
>  As of 4.2.x, this is no longer an option. Instead, we
>  baselined CentOS7 (mainly due to gstreamer 1.0).
>
> Discussion: The issue w/ CentOS7 is that the 32bit version is
> not officially supported. This means that for our
> 32bit builds we are using an unsupported platform.
> Instead of using CentOS7, we could instead baseline
> Ubuntu 14.04, which is both 64 and 32bit as well as
> both under LTS.
>
> So the question is: CentOS7 or Ubuntu 14.04?
>
> Cast your vote:
>
>   [ ]   CentOS7
>   [ ]   Ubuntu 14.04
>   [X]   Something else:

Debian if it has to be a distro.
AppImage and Snap packages would be the best, as those are multi-distro,
portable apps, do desktop integration, user friendly, standard
uninstallation, etc.

Damjan

Re: svn commit: r1890844 - /openoffice/devtools/build-scripts/4.1.10/wntmsci/build_aoo32bit_on_mingw. sh

[Damjan Jovanovic]

On Thu, Jun 17, 2021 at 1:34 AM Don Lewis  wrote:

> On 16 Jun, ard...@apache.org wrote:
> > Author: ardovm
> > Date: Wed Jun 16 19:07:44 2021
> > New Revision: 1890844
> >
> > URL: http://svn.apache.org/viewvc?rev=1890844=rev
> > Log:
> > Build script for AOO 4.1.10 under Mingw
> >
> > Better late than never... could be used as a template for the future
>
> I thought our Mingw support had rotted.  It hasn't been used in ages.
>
>
While never tested, every change I made for the modules I ported to gbuild,
and gbuild itself, had mingw support preserved as much as I could.

epm 5 not compiling on FreeBSD 13

[Damjan Jovanovic]

Hi

On FreeBSD 13.0 the epm module doesn't compile:

=
Building module epm
=

Entering /store0/Projects/Apache/Public/openoffice/openoffice-git/main/epm

mkdir ./unxfbsdx/misc/build/epm-5.0.0/
mkdir: ./unxfbsdx/misc/build/epm-5.0.0/: File exists
cd ./unxfbsdx/misc/build/epm-5.0.0/ && make  && touch
/path/to/openoffice-git/main/epm/./unxfbsdx/misc/build/so_built_epm
Compiling bsd.c...
bsd.c:203:27: error: no member named 'relnumber' in 'dist_t'; did you mean
'vernumber'?
if (dist->relnumber) {
  ^
  vernumber
./epm.h:220:9: note: 'vernumber' declared here
int vernumber,   /* Version number */
^
bsd.c:205:35: error: no member named 'relnumber' in 'dist_t'; did you mean
'vernumber'?
dist->relnumber, platname);
  ^
  vernumber
./epm.h:220:9: note: 'vernumber' declared here
int vernumber,   /* Version number */
^
2 errors generated.
*** Error code 1

Stop.





There is no "relnumber" in epm.h:

typedef struct / Distribution Structure /
{
char product[256],   /* Product name */
version[256],/* Product version string */
release[256],/* Product release string */
copyright[256],  /* Product copyright */
vendor[256], /* Vendor name */
packager[256],   /* Packager name */
license[256],/* License file to copy */
readme[256]; /* README file to copy */
int num_subpackages; /* Number of subpackages */
char **subpackages;  /* Subpackage names */
int num_descriptions;/* Number of description strings */
description_t *descriptions; /* Description strings */
int vernumber,   /* Version number */
epoch;   /* Epoch number */
int num_commands;/* Number of commands */
command_t *commands; /* Commands */
int num_depends; /* Number of dependencies */
depend_t *depends;   /* Dependencies */
int num_files;   /* Number of files */
file_t *files;   /* Files */
} dist_t;


Any ideas?
Damjan

Re: OpenOffice for Amazon Linux in aarch64 architecture

[Damjan Jovanovic]

On Wed, Feb 17, 2021 at 4:49 PM Jesús Alberto Cantú Peña <
jca...@ecaresoft.com> wrote:

> Hello:
> I started using AWS g4 generation machines and i need an open office
> software for that kind of architecture: (Linux machine aarch64)
> Do you know if exist an Open Office versión to be installed on that
> architecture machines?
>
> Thanks
> Jesús
>
>
Hi

With OpenOffice it's not just a matter of recompiling for a new
architecture. Each architecture needs its own bridge to be developed, to
support low-level interoperability between UNO programming languages, such
as calling C++ methods from Java, converting Java exceptions to C++, etc.
This is extremely difficult, requiring not only assembly language, but even
machine code in some cases.

While we do have support for the 32 bit ARM ABI in our gcc3_freebsd_arm and
gcc3_linux_arm bridges, the Aarch64 architecture requires a new bridge to
be developed.

Wikipedia claims Aarch64 is compatible with 32 bit ARM, so maybe you could
run the 32 bit ARM build of OpenOffice instead?

Some old notes on how to build OpenOffice for ARM:
https://wiki.openoffice.org/wiki/ARM


Damjan

Re: Branch scons-build and PR #82

[Damjan Jovanovic]

Hi Arrigo

You can. Peter's patches didn't fully convert the logic from
main/solenv/gbuild/platform/linux.mk into SCons, they only did the minimum
to catch up with FreeBSD.

I haven't developed on that branch in some time, and can't help right now.

There's a lot we could do in a SCons build though, with its ability to run
arbitrary Python code during the build: replace all the Perl files in
main/solenv/bin, replace calls to all the little command line tools like
awk/sed/zip, build without Cygwin some day, etc.

Damjan

On Wed, Sep 8, 2021 at 8:55 PM Arrigo Marchiori 
wrote:

> Dear All,
>
> I wanted to peek a little bit into the scons-build branch but I see
> there is an open pull request:
> https://github.com/apache/openoffice/pull/82
>
> It would introduce Linux support, that would be very interesting for
> me ;-)
>
> Can I clean it up by force-pushing away all non-related commits? I
> would only keep Peter's ones. Then it would be ready for merging,
> would it not?
>
> Thank you in advance and best regards,
> --
> Arrigo
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [OS/2 and macOS] saving ODS with chart

[Damjan Jovanovic]

On Tue, Jul 27, 2021 at 10:21 PM Arrigo Marchiori 
wrote:

> But that property _was_ set as a bool by method
> XMLFilter::impl_Export(), in file
> main/chart2/source/model/filter/XMLFilter.cxx, at the beginning of
> this explanation:
>
> 691:  xInfoSet->setPropertyValue( sUsePrettyPrinting, uno::makeAny(
> bUsePrettyPrinting ) );
>
> Immediately after that runs, add a watchpoint to that expression, then
resume. The debugger should be able to catch changes to that region of
memory, and stop execution when it changes, at which point you can examine
where the misbehaving code is. If it doesn't, then the problem is
elsewhere, eg. the Any being written to and the Any being read are
different objects.

See https://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.html

Good luck
Damjan

Re: [DISCUSS] [QA AUTOMATION] merging standalone-test branch into trunk

[Damjan Jovanovic]

On Sun, Mar 27, 2022 at 9:44 PM Carl Marcum  wrote:

> Hi All,
>

Hi

I want to get some opinions on whether to merge my work on standalone
> test automation into trunk and possibly AOO42X and AOO41X or leave it in
> a branch and use it from there.
> Six months ago I posted this [1] on qa@ and cc'd this list about the
> work and haven't got any negative feedback so far.
>
> Since this is a larger architectural issue that may affect someone who
> runs the test suites after a build with some sort of scripts I wanted to
> discuss it.
> As I don't know if or how everyone uses them I wanted to give everyone
> an opportunity to comment.
>
> For those not familiar, this change allows anyone with Ant and Java to
> compile and run the automated test suites without having first needed to
> build the complete office from source as long as they have an office
> with an sdk installed. This can be a conventional installation or by
> having built the "installed" package from source and copied it to a
> folder and the sdk into it.
> For instance, this allows me to run tests on Windows and CentOS 8 even
> though I don't have a build environments for them like I do for multiple
> Linux versions.
>
> Basically this change is in where the Java UNO jars and other
> dependencies like javamaker, remerge, and idlc tools are found for test
> compilation . I've changed it from the build output directories to the
> target office and sdk instead.
>

Yes, that's a great idea.


> Since they are standalone from the build, the test directory can be
> copied separately and used from another location so it's not dependent
> on which branch it's used from unless a test is added that is branch
> specific like testing something that only exists in AOO42X or trunk.
> Technically it could be in another Git repo even.
>
> I'd like to propose some options in the order I prefer and get some
> opinions.
>
> 1. Merge standalone-test branch into trunk and cherry-pick it into
> AOO41X and AOO42X.  After that, any new tests that don't apply to AOO41X
> stay in trunk and AOO42X as appropriate but as of now all tests apply.
> This option seems to require the least maintenance after the merge and
> allows you to use from which ever branch is checked out to align with
> what you want to test.
>
> 2. Merge standalone-test branch into trunk only.  Any test work after
> that wouldn't be affected by whether they are standalone or not. As
> mentioned before the test directory is not dependent on the build
> version (yet anyway) but this could change if tests are added that don't
> apply to AOO41X for instance. At that point some tests not intended for
> AOO41X would cause problems.
>
> 3. Leave standalone-test in it's own branch. This is more of a
> maintenance issue as work done here needs picked into more branches but
> it is an option.
>

I think (2) is best. Tests sensitive to the AOO version can check the
version themselves.


>
> [1] https://lists.apache.org/thread/v6bnty1qxho4o5hmt4pg0rw00yxzrhx8
>
> Please let me know if you have any questions.
>
> Thanks,
> Carl
>
>
Damjan

Re: Help building in Ubuntu 20.04.4?

[Damjan Jovanovic]

On Sun, Mar 20, 2022 at 3:18 PM Pedro Lino 
wrote:

> Hi all
>
> Installing needed libraries fails with
>
> E: Unable to locate package libgnomevfs2-dev
> E: Unable to locate package liborbit2-dev
>
> Help?
>
> Pedro


Backport these commits from trunk:

commit ca91c47212927702e72149e398fae850402fa54c
Author: Damjan Jovanovic 
Date:   Thu Oct 19 16:35:49 2017 +

GnomeVFS was deprecated 9 years ago. Make GIO, its replacement,
the default searched by configure.ac instead.


commit 6b1c0a07ced87c91d0adf8f59096a87e364647c0
Author: Damjan Jovanovic 
Date:   Sat Oct 21 06:15:07 2017 +

Don't require ORbit to compile. We never really needed it:
GConf makes its own CORBA connection if it needs to, and
the only reason we included orbit.h is to check whether
the problematic version < 2.8 was present, as it deadlocks
the GTK VCL plugin.

But ORbit 2.8 was released in 2003, and GConf doesn't
even use CORBA connections any more. So drop the check
and stop needing ORBit altogether.


Regards
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.
> >> - *

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: 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

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

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: "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 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?

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: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Damjan Jovanovic]

Hi Pedro

That's great.

I think all you need to do to test on Windows is replace libcurl.dll and
ucpdav1.dll with the copies in the ZIP file you download from here:
https://drive.google.com/file/d/1YnpCr4woe8laah4nxtgzGfuEfGpVrf9L/view?usp=sharing

Regards
Damjan


On Tue, Apr 26, 2022 at 8:20 PM Pedro Lino 
wrote:

>
> Hi Damian
>
>
>
> I use Webdav almost on a daily basis.
> Looking forward to testing a new build under Linux as soon as you push it
> to 42X
>
> Can you share your working binaries for Windows?
>
>
>
> Thanks!
>
> Pedro
> > On 04/26/2022 6:56 PM 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.
> > >
> > > While it ended well, and several other bugs were found and fixed, it
> definitely wasn't the "easy option" Jim ;). Starting with conservative
> changes, it ended up needing total restructuring, and became more of a
> rewrite. The crashes were frequent and hung connections many, and I had to
> read up on the HTTP protocol, and read Curl and Serf's source code, but
> eventually I prevailed, and a clean elegant stable Curl WebDAV module
> emerged.
> > >
> > > The huge patch is attached for anyone wishing to review and test.
> Unless there are major objections, I'll push it in a couple of days.
> > >
> > > 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.
> > >
> > > HTTP and HTTPS proxies work. Unlike Serf, Curl could also support
> SOCKS proxies (with minimal further changes), but AOO lacks that setting in
> the proxy UI and configuration.
> > >
> > > Authentication works, both to the destination server and to the proxy
> server. I've successfully tested Basic and Digest authentication. Curl
> supports every authentication method Serf does and more.
> > >
> > > HTTPS works, with a custom certificate verification function, using
> our own certificate store from NSS and its API (like the Serf code used). A
> bug was discovered (which is in the Serf implementation too) where
> self-signed certificates were being unconditionally rejected; apparently
> NSS wants to see that a copy of that certificate  in its certificate chain
> parameter too. Now they work, and the user gets prompted to allow access.
> > >
> > >
> > > HTTPS and authentication can be used together on the same connection
> and work well, both bringing up their UI dialogs as needed.
> > >
> > > A bug was fixed where when username and password were both present in
> the URL (dav://user:pass@host/path), the code was trying to split them at
> the "@" instead of ":".
> > >
> > > Unnecessary base64 encoding and decoding was removed, when importing
> the TLS connection's certificates into our XSecurityEnvironment. They now
> come in directly as ASN.1 DER, and still work.
> > >
> > > The code was greatly restructured and cleaned up, as Curl's API is
> synchronous and blocking, with parameters set in advance instead of through
> many callbacks, which has allowed using short clear methods, and clean
> separation between the session and request classes. The WebDAV content
> provider has shrunk from 35 to 21 C++ files, 43 to 29 header files, and
> 19129 to 15991 lines of code. With WebDAV methods centralized and
> refactored into only 10-20 lines of code each, instead of scattered across
> 4 files, it is much more understandable and maintainable now.
> > >
> > > Curl is vastly more portable than Serf. We should build easily now
> even on OS/2. We can remain with existing build tools instead of needing
> scons or cmake just to build Serf.
> > >
> > > 3 now unused dependencies were removed: apr, apr-util, and serf. Serf
> isn't so bad. APR's pool idea is an ingenious way of doing resource
> management in C. However Curl has excellent documentation, guides,
> examples, and detailed explanations and even e

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 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 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 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: [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 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

New UNO service for logging to syslog

[Damjan Jovanovic]

Hi

I've committed a new UNO service, com.sun.star.logging.SyslogHandler, which
logs to a syslog server.

Updated documentation on how you use it is at:
https://wiki.openoffice.org/wiki/Category:Logging

This only applies to code using the com.sun.star.logging framework, which
is currently only the SDBC database drivers in main/connectivity and my new
WebDAV module.

Regards
Damjan

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 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.

If you can't see anything obviously wrong, send me that log file, but audit
it carefully first, it will probably contain your password in plaintext!


>
> [...]
> > P.S. APACHE 2.4 SETUP FOR TESTING
> [...]
>
> I still have to try this. Thank you for this tutorial!!
>
>
Pleasure :).


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: 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

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

[Damjan Jovanovic]

Thank you Matthias.

Not too happy to use Github, but here is the pull request:
https://github.com/apache/openoffice/pull/146



On Wed, Apr 27, 2022 at 5:44 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Sounds great!
>
> Can we have that as a Pull Request?
>
> Regards,
>
>Matthias
> Am 26.04.22 um 19:56 schrieb Damjan Jovanovic:
>
> 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.
>
> While it ended well, and several other bugs were found and fixed, it
> definitely wasn't the "easy option" Jim ;). Starting with conservative
> changes, it ended up needing total restructuring, and became more of a
> rewrite. The crashes were frequent and hung connections many, and I had to
> read up on the HTTP protocol, and read Curl and Serf's source code, but
> eventually I prevailed, and a clean elegant stable Curl WebDAV module
> emerged.
>
> The huge patch is attached for anyone wishing to review and test. Unless
> there are major objections, I'll push it in a couple of days.
>
> 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.
>
> HTTP and HTTPS proxies work. Unlike Serf, Curl could also support SOCKS
> proxies (with minimal further changes), but AOO lacks that setting in the
> proxy UI and configuration.
>
> Authentication works, both to the destination server and to the proxy
> server. I've successfully tested Basic and Digest authentication. Curl
> supports every authentication method Serf does and more.
>
> HTTPS works, with a custom certificate verification function, using our
> own certificate store from NSS and its API (like the Serf code used). A bug
> was discovered (which is in the Serf implementation too) where self-signed
> certificates were being unconditionally rejected; apparently NSS wants to
> see that a copy of that certificate  in its certificate chain parameter
> too. Now they work, and the user gets prompted to allow access.
>
> HTTPS and authentication can be used together on the same connection and
> work well, both bringing up their UI dialogs as needed.
>
> A bug was fixed where when username and password were both present in the
> URL (dav://user:pass@host/path), the code was trying to split them at the
> "@" instead of ":".
>
> Unnecessary base64 encoding and decoding was removed, when importing the
> TLS connection's certificates into our XSecurityEnvironment. They now come
> in directly as ASN.1 DER, and still work.
>
> The code was greatly restructured and cleaned up, as Curl's API is
> synchronous and blocking, with parameters set in advance instead of through
> many callbacks, which has allowed using short clear methods, and clean
> separation between the session and request classes. The WebDAV content
> provider has shrunk from 35 to 21 C++ files, 43 to 29 header files, and
> 19129 to 15991 lines of code. With WebDAV methods centralized and
> refactored into only 10-20 lines of code each, instead of scattered across
> 4 files, it is much more understandable and maintainable now.
>
> Curl is vastly more portable than Serf. We should build easily now even on
> OS/2. We can remain with existing build tools instead of needing scons or
> cmake just to build Serf.
>
> 3 now unused dependencies were removed: apr, apr-util, and serf. Serf
> isn't so bad. APR's pool idea is an ingenious way of doing resource
> management in C. However Curl has excellent documentation, guides,
> examples, and detailed explanations and even example code for each setting,
> while Serf has no documentation. Serf might be worth it in a project that
> already uses APR a lot, but we don't.
>
> Instead of the historical, crippled forms of logging like OSL_TRACE(),
> which don't appear in release builds, I've made it use the newer
> com.sun.star.logging UNO component (wrapped in comphelper::EventLogger),
> which was inspired by java.util.logging, with configurable verbosity
> levels, handlers (file and console) and output formats (plain, csv), and
> importantly, which produces output in release builds too. I've also made it
> so that on LogLevel::FINEST, Curl's verbose mode is enabled and Curl's
> debug output is also logged t

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

[Damjan Jovanovic]

On Wed, Apr 27, 2022 at 8:07 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Am 27.04.22 um 19:11 schrieb Damjan Jovanovic:
> > Thank you Matthias.
> >
> > Not too happy to use Github, but here is the pull request:
> > https://github.com/apache/openoffice/pull/146
>
> Thanks, Git makes it a lot easier for me to build...
>
> BTW: Is it OK when I cherry-pick your other two commits to AOO42X?
>
>
Which ones? The Python 3.8 and the syslog commits?

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

[Damjan Jovanovic]

On Wed, Apr 27, 2022 at 9:22 PM Matthias Seidel 
wrote:

> Hi,
>
> Am 27.04.22 um 21:09 schrieb Damjan Jovanovic:
> > On Wed, Apr 27, 2022 at 8:07 PM Matthias Seidel <
> matthias.sei...@hamburg.de>
> > wrote:
> >
> >> Hi Damjan,
> >>
> >> Am 27.04.22 um 19:11 schrieb Damjan Jovanovic:
> >>> Thank you Matthias.
> >>>
> >>> Not too happy to use Github, but here is the pull request:
> >>> https://github.com/apache/openoffice/pull/146
> >> Thanks, Git makes it a lot easier for me to build...
> >>
> >> BTW: Is it OK when I cherry-pick your other two commits to AOO42X?
> >>
> >>
> > Which ones? The Python 3.8 and the syslog commits?
> Yes
> >
>
>
Sure, cherry-pick them. The IDL file for the syslog patch needs to be
changed to say "since 4.2" though, instead of the current 4.5.

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
>

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: 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: 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: 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

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

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

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: 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: 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

[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: 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: Happy...

[Damjan Jovanovic]

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

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

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: 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
> 
> >
>