Re: translated files

[Damjan Jovanovic]

If you are a committer, feel free to commit them. Comment translation
mistakes are not serious and can always be fixed later.

If not, attach the patches to the bug report. And I think we should vote
you in.

Damjan

On Wed, Sep 20, 2017 at 11:55 PM, Peter Kovacs  wrote:

> I have translated comments in the files
>
> main/sfx2/source/doc/objxtor.css
>
> main/sc/inc/dociter.hxx
> main/sc/source/core/data/dociter.cxx
>
> Can I commit those changes to SVN or does someone need to set something
> for me first before I can commit?
>
> (Will be friday till I have time again :S)
>
> All the best
> Peter
>
>

Re: translated files

[Damjan Jovanovic]

On Thu, Sep 21, 2017 at 11:51 AM, Mathias Röllig <mroellig.n...@gmx.net>
wrote:

> Am 21.09.2017 um 10:38 schrieb Damjan Jovanovic:
>
>> Requests for translation are posted to the bug:
>> https://bz.apache.org/ooo/show_bug.cgi?id=39199
>>
>
> Yes, I can look at the files via Opengrok. Is tht the way?
>

Ideally, you want to edit the latest version of a file and either commit it
if you are a committer, or generate a patch for other committers to commit.
Opengrok's file might be out of date, and can't diffed to generate a patch
as easily (well you can keep the original copy and run "diff -u original
new > patch" yourself, but it's more work). SVN is probably better.


>
> German speaking devs take the file and conduct the translation.
>>
>
> This answer helps me to help to translate – very well! <Sarcasm!>
>
> :-D


> M.
>
>
> Damjan
>>
>> On Thu, Sep 21, 2017 at 9:36 AM, Mathias Röllig <mroellig.n...@gmx.net>
>> wrote:
>>
>> Hello!
>>>
>>> I use Peter's question to ask in the same direction:
>>>
>>> How is the way to help with translation of comments?
>>> Where to get and put the files?
>>>
>>> Regards
>>> Mathias
>>>
>>>
>>>
>>> Am 20.09.2017 um 23:55 schrieb Peter Kovacs:
>>>
>>> I have translated comments in the files
>>>>
>>>> main/sfx2/source/doc/objxtor.css
>>>>
>>>> main/sc/inc/dociter.hxx
>>>> main/sc/source/core/data/dociter.cxx
>>>>
>>>> Can I commit those changes to SVN or does someone need to set something
>>>> for me first before I can commit?
>>>>
>>>> (Will be friday till I have time again :S)
>>>>
>>>> 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: [Discussion] build tool

[Damjan Jovanovic]

On Tue, Sep 5, 2017 at 4:11 PM, Peter Kovacs  wrote:

> Hello all,
>
> To be honest I am not very happy with gmake and ant. It is difficult to
> add the functionality to Eclipse. Also we stay dependant for Windows on
> Cygwin or Windows Subsystem for Linux, which feels to me awkward. Also
> if we want to have people develop on Windows. A good build environment
> is vital.
>

What do you mean by "add the functionality to Eclipse"?

On Windows, I don't think our (new) Ant projects need Cygwin or Windows
System for Linux to open in Eclipse after AOO is built. Do they?


>
> I think I have found a better replacement that supports our needs.
> Plus is IMHO realy visionary in how to develop a C++ Project.
>
> Maven with the Nar-maven-plugin
>
> Maven can
> # Manage our dependencies
> # compile Java
> # Compile C++
> # Compile JNI interfaces (I am not sure dont we use this massivly)
> # The setup works for Windows, Linux, MacOS, Solaris, ... (BSD? have to
> evaluate)
>
> It will give us
> # Integration in Eclipse
> # Internal Versioning on our own Moduls. (Resulting in an easier
> Release Process)
> # Target OS specific build recepies can be maintained.
> # prepackaged Java dependencies (I hope, havent checked)
>
> It has potential to supply
> # a direct and complete Windows build environment. (I am not sure if we
> need cygwin for providing our C++ dependencies, or what possibilities
> we have)
>
> There are some caveeats to this Approach
> # Apache Maven has not included the nar-maven-plugin
> Do not know the consequences. Maybe I think to much. Just want it to be
> transparent.
> # Plugin status
> Nar-maven-plugin is advocated as mature, but development team is
> voluntary base as we are. Only handfull of projects use this approach.
> I think they have like 3 active people.
> # Features
> I think we maven will give us only the ability to compile and tests. No
> packaging and signing as of now. At least have not seen any ressources.
> # Need of own C++ Repository
> We have to build our own Nar Maven repository for our dependencies. I
> have read it is a streight forward process. But still, work.
> # Project structure
> IMHO the biggest one. We must restructure the Project in order to
> utilize the build tool. The requirement is
> /yourproject
> /src
> /main
>  /java
>  /resources
>  /include
>  /c++
>  /c
>  /fortran
>/test
> /java
> /resources
> /include
> /c++
> /c
> /fortran
>
> Moduls are supported through maven. So we can do something like:
> /Openoffice
> /sw
> /main
> /java
> /ressources
> /include
> /c++
> /c
> /fortran
>/test
> /java
> /resources
> /include
> /c++
> /c
> /fortran
>
>
> Ressources to read for more info:
> Apache maven - https://maven.apache.org/index.html
> Nar-maven-plugin - http://maven-nar.github.io/#
> Eclipse Connector for the plugin - https://github.com/maven-nar/m2e-nar
>
> What are your thoughts? - Have not found any Discussion in the archive
> in this direction before.
>
>
In their presentation, "Unsupported" (page 29) includes showstoppers like
"binaries" and "linking with shared libraries" (!!), making it completely
unusable to 99% of our modules without major changes.

There's also no Objective C.



> If okay I would like to evaluate on the feasability. If I talk to
> people I will just say that I am evaluating. No desicion has been taken
> or requested.
> It is because I think If I start talking it is quite opvious where I
> come from. Dont do that many Public projects ;) Especially on Github.
> (I also invite you to have a look ;) )
>

If you do, please have a look at main/solenv/inc and main/solenv/gbuild for
what's involved as well. It's easy to overlook the vastness and complexity
of our existing build systems, after all we have custom toolchains doing
custom localization, custom configuration, custom testing, custom
"javadoc"-like documentation, custom everything. Porting *those* to
something else is **hard**, and even the gbuild migration didn't try to do
that. Also those custom makefiles/tools/scripts needs awk, Perl, grep, sed,
zip, and other *nix utilities themselves, hence also the need for Cygwin...


> All the best
> Peter
>
>
>
Damjan

Re: Linux32 buildbots time out (fixed)

[Damjan Jovanovic]

That's great news :)

On Tue, Sep 12, 2017 at 10:54 PM, Matthias Seidel <
matthias.sei...@hamburg.de> wrote:

> The problem is fixed!
> RPMbuild had issues and therefore the bots timed out...
>
> We now have a full set of new Linux32 builds uploaded:
>
> https://www.openoffice.org/download/devbuilds.html
>
> Regards, Matthias
>
>
> Am 09.09.2017 um 13:40 schrieb Matthias Seidel:
> > Hello all,
> >
> > Our buildbots for Linux32 time out since mid August.
> >
> > I already opened a ticket with Infra, but we do not seem to find the
> > real cause:
> > https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-14954
> > (The issue with Java 8 is fixed and all other bots are working fine)
> >
> > Maybe someone more knowledgeable than me can have a look at the logs?
> >
> > Kind regards, Matthias
> >
> >
>
>
>

Re: Error in Linux64 bot

[Damjan Jovanovic]

Nice catch. connectivity/util didn't have a dependency on
connectivity/java/sdbc_postgresql, sometimes causing it to build in the
wrong order and fail. Should be fixed in revision 1807949.

Thank you
Damjan

On Sun, Sep 10, 2017 at 3:14 PM, Matthias Seidel  wrote:

> Hi Damjan,
>
> Today our Linux64 bot shows an error:
>
> ---
>
> 1 module(s):
>   connectivity
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making 
> /home/buildslave/slave/openoffice-linux64-nightly/build/main/connectivity/util
>
> When you have fixed the errors in that module you can resume the build by 
> running:
>
>   build --from connectivity
>
> ---
>
> dmake: Executing shell macro: cd 
> $(MISC)/registry/data/org/openoffice/Office/DataAccess &&  ls *.xcu
> dmake:  Error: -- 
> `../unxlngx6.pro/misc/registry/res/en-US/org/openoffice/Office/DataAccess/sdbc_postgresql.xcu'
>  not found, and can't be made
>
> ---
>
>
> Windows bot built fine...
>
> Regards, Matthias
>

Re: Java 9 32-bit

[Damjan Jovanovic]

Go for which option?
Or do you mean option 4 with the "Go" language?

On Tue, Oct 3, 2017 at 3:20 PM, Matthias Seidel <matthias.sei...@hamburg.de>
wrote:

> Go for it! ;-)
>
>
> Am 03.10.2017 um 15:18 schrieb Damjan Jovanovic:
> > Now what:
> > 1. Ship our own builds of OpenJDK, in matching bitness. Do the licences
> > (GPL for JVM, GPL-with-classpath-exception for class library) allow us
> to?
> > 2. Drop Windows as a platform, since it's the only affected platform
> (*nix
> > users usually install distro OpenJDK packages so 32 bit OpenJDK will be
> > available for 32 bit AOO). We have no Win64 AOO.
> > 3. Drop 32 bit versions of AOO and add Win64 support.
> > 4. Or drop Java entirely and port our Java code to eg. .NET core, which
> is
> > liberally licensed and private copies of it can be shipped?
> >
> > Damjan
> >
> > On Tue, Oct 3, 2017 at 2:51 PM, Matthias Seidel <
> matthias.sei...@hamburg.de>
> > wrote:
> >
> >> Hello all,
> >>
> >> It seems that Oracle pulled the 32-bit version of Java 9:
> >>
> >> https://twitter.com/mreinhold/status/912311207935090689
> >>
> >> Matthias
> >>
> >>
> >>
>
>
>

Re: Java 9 32-bit

[Damjan Jovanovic]

Now what:
1. Ship our own builds of OpenJDK, in matching bitness. Do the licences
(GPL for JVM, GPL-with-classpath-exception for class library) allow us to?
2. Drop Windows as a platform, since it's the only affected platform (*nix
users usually install distro OpenJDK packages so 32 bit OpenJDK will be
available for 32 bit AOO). We have no Win64 AOO.
3. Drop 32 bit versions of AOO and add Win64 support.
4. Or drop Java entirely and port our Java code to eg. .NET core, which is
liberally licensed and private copies of it can be shipped?

Damjan

On Tue, Oct 3, 2017 at 2:51 PM, Matthias Seidel 
wrote:

> Hello all,
>
> It seems that Oracle pulled the 32-bit version of Java 9:
>
> https://twitter.com/mreinhold/status/912311207935090689
>
> Matthias
>
>
>

Re: Java 9 32-bit

[Damjan Jovanovic]

On Tue, Oct 3, 2017 at 3:18 PM, Damjan Jovanovic <dam...@apache.org> wrote:

> Now what:
> 1. Ship our own builds of OpenJDK, in matching bitness. Do the licences
> (GPL for JVM, GPL-with-classpath-exception for class library) allow us to?
>

To answer my own question, we can't ship OpenJDK - according to
http://apache.org/legal/resolved.html#optional "Apache projects cannot
distribute any such components within their releases".

We could however download and install an OpenJDK binary distribution at
run-time, as needed and after user confirmation, from something like
https://github.com/ojdkbuild/ojdkbuild, for these cases where Oracle's JDK
is unsupported.

Re: Committed: new database driver for PostgreSQL, SDBCX API for Java

[Damjan Jovanovic]

I've patched external_deps.lst, and as of revision 1805933, AOO should
build even without --enable-wiki-publisher.

On Tue, Aug 22, 2017 at 11:04 PM, Matthias Seidel <
matthias.sei...@hamburg.de> wrote:

> Am 21.08.2017 um 19:14 schrieb Damjan Jovanovic:
> > Yes. Well done on finding it. You can make the dependency unconditional,
> > just like I've done with sdbc_postgres itself.
>
> As a workaround the Windows buildbot builds now with
> "--enable-wiki-publisher"
>
> But the Linux64 bot breaks even with that switch. Could you please have
> a look at:
> https://ci.apache.org/projects/openoffice/buildlogs/
> linux64/main/connectivity/unxlngx6.pro/misc/logs/java.sdbc_postgresql.txt
>
> > On Monday, August 21, 2017, Matthias Seidel <matthias.sei...@hamburg.de>
> > wrote:
> >
> >> Hi Damjan,
> >>
> >> I think the "problem" is in "external_deps.lst":
> >>
> >> ---
> >> if (SOLAR_JAVA==TRUE && ENABLE_MEDIAWIKI==YES)
> >> MD5 = 4c8c505cc3cba4c467c479e3e0f09ba4
> >> name = commons-lang3-3.3-src.tar.gz
> >> URL1 = http://archive.apache.org/dist/commons/lang/source/$(name)
> >> URL2 = $(OOO_EXTRAS)$(MD5)-$(name)
> >> ---
> >>
> >> The Windows build is running at the moment. Looks good so far!
> >>
> >> If it is successful Rev. 1805579 can be found here:
> >> https://www.openoffice.org/download/devbuilds.html
> >>
> >> Matthias
> >>
> >>
> >> Am 21.08.2017 um 17:09 schrieb Damjan Jovanovic:
> >>> My module uses Apache Commons Lang. Maybe I didn't patch configure.ac
> >>> properly, or maybe you have to run autoconf on that buildbot before
> >>> ./configure? I can't check for the next few days.
> >>>
> >>> On Monday, August 21, 2017, Matthias Seidel <
> matthias.sei...@hamburg.de
> >> <javascript:;>>
> >>> wrote:
> >>>
> >>>> Hi Damian,
> >>>>
> >>>> Maybe it is because we build without Wiki publisher. (What is it good
> >> for?
> >>>> I have never seen a working Wiki publisher in the past years...)
> >>>>
> >>>> I have now enabled it (--enable-wiki-publisher), let us wait for a new
> >>>> build...
> >>>>
> >>>> Regards, Matthias
> >>>>
> >>>> Am 21.08.2017 um 14:36 schrieb Matthias Seidel:
> >>>>
> >>>> Hi Damian,
> >>>>
> >>>> That sounds good!
> >>>>
> >>>> Unfortunately your commit seems to break the build on our
> buildbot(Win10
> >>>> 64bit/Java 8):
> >>>> https://ci.apache.org/projects/openoffice/buildlogs/
> >>>> win/log/wntmsci12.pro.build.html
> >>>>
> >>>> ---1 module(s):
> >>>>  apache-commons
> >>>> need(s) to be rebuilt
> >>>>
> >>>> Reason(s):
> >>>>
> >>>> ERROR: error 65280 occurred while making /cygdrive/e/slave14/aoo-win7/
> >> build/main/apache-commons/java/lang
> >>>> When you have fixed the errors in that module you can resume the build
> >> by running:
> >>>>  build --from apache-commons
> >>>>
> >>>> ---
> >>>> dmake:  Error: -- `../../wntmsci12.pro/misc/
> >> 4c8c505cc3cba4c467c479e3e0f09ba4-commons-lang3-3.3-src.unpack' not
> found,
> >> and can't be made
> >>>> ---
> >>>>
> >>>> Regards, Matthias
> >>>>
> >>>>
> >>>> Am 20.08.2017 um 21:34 schrieb Damjan Jovanovic:
> >>>>
> >>>> Hi
> >>>>
> >>>> In revision 1805579 I committed a large patch to AOO, that implements
> a
> >>>> whole new database connector, for the PostgreSQL database.
> >>>>
> >>>> It's the real deal, a new UNO component, 57 files, 9607 lines of code,
> >>>> about 4 months in the pipeline. It's 100% in Java, and while
> developing
> >> it
> >>>> I've also written a lot of SDBCX helper classes, loosely based on the
> >> C++
> >>>> ones we already have, which will make writing future Java-based
> database
> >>>> drivers much easier :).
> >>>>
> >>>> Ok so it's still in its early alpha stages, maybe 50% finished, and
> will
> >>>> need considerable 

Re: Committed: new database driver for PostgreSQL, SDBCX API for Java

[Damjan Jovanovic]

My module uses Apache Commons Lang. Maybe I didn't patch configure.ac
properly, or maybe you have to run autoconf on that buildbot before
./configure? I can't check for the next few days.

On Monday, August 21, 2017, Matthias Seidel <matthias.sei...@hamburg.de>
wrote:

> Hi Damian,
>
> Maybe it is because we build without Wiki publisher. (What is it good for?
> I have never seen a working Wiki publisher in the past years...)
>
> I have now enabled it (--enable-wiki-publisher), let us wait for a new
> build...
>
> Regards, Matthias
>
> Am 21.08.2017 um 14:36 schrieb Matthias Seidel:
>
> Hi Damian,
>
> That sounds good!
>
> Unfortunately your commit seems to break the build on our buildbot(Win10
> 64bit/Java 8):
> https://ci.apache.org/projects/openoffice/buildlogs/
> win/log/wntmsci12.pro.build.html
>
> ---1 module(s):
>   apache-commons
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making 
> /cygdrive/e/slave14/aoo-win7/build/main/apache-commons/java/lang
>
> When you have fixed the errors in that module you can resume the build by 
> running:
>
>   build --from apache-commons
>
> ---
> dmake:  Error: -- 
> `../../wntmsci12.pro/misc/4c8c505cc3cba4c467c479e3e0f09ba4-commons-lang3-3.3-src.unpack'
>  not found, and can't be made
> ---
>
> Regards, Matthias
>
>
> Am 20.08.2017 um 21:34 schrieb Damjan Jovanovic:
>
> Hi
>
> In revision 1805579 I committed a large patch to AOO, that implements a
> whole new database connector, for the PostgreSQL database.
>
> It's the real deal, a new UNO component, 57 files, 9607 lines of code,
> about 4 months in the pipeline. It's 100% in Java, and while developing it
> I've also written a lot of SDBCX helper classes, loosely based on the C++
> ones we already have, which will make writing future Java-based database
> drivers much easier :).
>
> Ok so it's still in its early alpha stages, maybe 50% finished, and will
> need considerable further development, so definitely not recommended for
> production use yet, but it already supports some things that are broken in
> LibreOffice's PostgreSQL driver ;).
>
> I would have preferred to wait until it was more complete before
> committing, but I thought now is a good time, as there is talk of project
> inactivity, help from others would be welcome, and "release early, release
> often" is the open-source way.
>
> It's already integrated into the build, but if you want to contribute to
> development, it could not be easier: the Ant project opens in Eclipse (open
> main/connectivity/java/sdbc_postgresql/build.xml using "Java Project from
> Existing Ant Buildfile"), it builds in 2 seconds, and can be easily
> debugged (in AOO, Tools -> Options, Java, Parameters, add:
> "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000"
> and attach the remote debugger from Eclipse).
>
> To use it, you need the PostgreSQL JDBC JAR file in your classpath (we
> should probably ship it to users instead of requiring them to download and
> configure it in their AOO Tools -> Options, Java, Class Path). In the
> database wizard, choose "Connect to an existing database" and select
> "PostgreSQL". At present you have to enter database URLs in the broken form
> of "://127.0.0.1/catalog". Database queries work well with a variety of
> data types, but some DDL features are missing/broken, eg. you can't rename
> tables, indexes can't be deleted, views/users/groups need implementing,
> "Refresh tables" gives you a blank screen. The code also needs to be
> audited and cleaned up a lot (locking, UNO lifecycle, null strings (which
> are banned in UNO)), and the relevant GUI dialogs and wizards need adding
> (under main/dbaccess).
>
> Note that you need Java >= 7.
>
> Anyway, development continues. We have a few more database drivers that
> need to be developed, such as the Thunderbird address book driver and the
> LDAP driver which we lost when Mozilla was removed from the build.
>
> Regards
> Damjan
>
>
>
>
>

Re: Committed: new database driver for PostgreSQL, SDBCX API for Java

[Damjan Jovanovic]

Yes. Well done on finding it. You can make the dependency unconditional,
just like I've done with sdbc_postgres itself.

On Monday, August 21, 2017, Matthias Seidel <matthias.sei...@hamburg.de>
wrote:

> Hi Damjan,
>
> I think the "problem" is in "external_deps.lst":
>
> ---
> if (SOLAR_JAVA==TRUE && ENABLE_MEDIAWIKI==YES)
> MD5 = 4c8c505cc3cba4c467c479e3e0f09ba4
> name = commons-lang3-3.3-src.tar.gz
> URL1 = http://archive.apache.org/dist/commons/lang/source/$(name)
> URL2 = $(OOO_EXTRAS)$(MD5)-$(name)
> ---
>
> The Windows build is running at the moment. Looks good so far!
>
> If it is successful Rev. 1805579 can be found here:
> https://www.openoffice.org/download/devbuilds.html
>
> Matthias
>
>
> Am 21.08.2017 um 17:09 schrieb Damjan Jovanovic:
> > My module uses Apache Commons Lang. Maybe I didn't patch configure.ac
> > properly, or maybe you have to run autoconf on that buildbot before
> > ./configure? I can't check for the next few days.
> >
> > On Monday, August 21, 2017, Matthias Seidel <matthias.sei...@hamburg.de
> <javascript:;>>
> > wrote:
> >
> >> Hi Damian,
> >>
> >> Maybe it is because we build without Wiki publisher. (What is it good
> for?
> >> I have never seen a working Wiki publisher in the past years...)
> >>
> >> I have now enabled it (--enable-wiki-publisher), let us wait for a new
> >> build...
> >>
> >> Regards, Matthias
> >>
> >> Am 21.08.2017 um 14:36 schrieb Matthias Seidel:
> >>
> >> Hi Damian,
> >>
> >> That sounds good!
> >>
> >> Unfortunately your commit seems to break the build on our buildbot(Win10
> >> 64bit/Java 8):
> >> https://ci.apache.org/projects/openoffice/buildlogs/
> >> win/log/wntmsci12.pro.build.html
> >>
> >> ---1 module(s):
> >>  apache-commons
> >> need(s) to be rebuilt
> >>
> >> Reason(s):
> >>
> >> ERROR: error 65280 occurred while making /cygdrive/e/slave14/aoo-win7/
> build/main/apache-commons/java/lang
> >>
> >> When you have fixed the errors in that module you can resume the build
> by running:
> >>
> >>  build --from apache-commons
> >>
> >> ---
> >> dmake:  Error: -- `../../wntmsci12.pro/misc/
> 4c8c505cc3cba4c467c479e3e0f09ba4-commons-lang3-3.3-src.unpack' not found,
> and can't be made
> >> ---
> >>
> >> Regards, Matthias
> >>
> >>
> >> Am 20.08.2017 um 21:34 schrieb Damjan Jovanovic:
> >>
> >> Hi
> >>
> >> In revision 1805579 I committed a large patch to AOO, that implements a
> >> whole new database connector, for the PostgreSQL database.
> >>
> >> It's the real deal, a new UNO component, 57 files, 9607 lines of code,
> >> about 4 months in the pipeline. It's 100% in Java, and while developing
> it
> >> I've also written a lot of SDBCX helper classes, loosely based on the
> C++
> >> ones we already have, which will make writing future Java-based database
> >> drivers much easier :).
> >>
> >> Ok so it's still in its early alpha stages, maybe 50% finished, and will
> >> need considerable further development, so definitely not recommended for
> >> production use yet, but it already supports some things that are broken
> in
> >> LibreOffice's PostgreSQL driver ;).
> >>
> >> I would have preferred to wait until it was more complete before
> >> committing, but I thought now is a good time, as there is talk of
> project
> >> inactivity, help from others would be welcome, and "release early,
> release
> >> often" is the open-source way.
> >>
> >> It's already integrated into the build, but if you want to contribute to
> >> development, it could not be easier: the Ant project opens in Eclipse
> (open
> >> main/connectivity/java/sdbc_postgresql/build.xml using "Java Project
> from
> >> Existing Ant Buildfile"), it builds in 2 seconds, and can be easily
> >> debugged (in AOO, Tools -> Options, Java, Parameters, add:
> >> "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000"
> >> and attach the remote debugger from Eclipse).
> >>
> >> To use it, you need the PostgreSQL JDBC JAR file in your classpath (we
> >> should probably ship it to users instead of requiring them to download
> and
> >> configure it in their AOO Tools -> Options, Java, C

Re: Dont understand Compiler message

[Damjan Jovanovic]

It's some kind of error in gbuild. It really shouldn't happen.

Can you try get the full output of "build --from basebmp" without any -P's?

Damjan

On Mon, Nov 13, 2017 at 12:39 AM, Peter Kovacs  wrote:

> I tried now
>
> build --from basebmp
>
> The error stays persistant independantly if i use a prepare step or not.
>
> if i go for
>
> build --all:basebmp it compiles other libes and gets stuck for similar
> reasons in other packages. (up to a point whhere nothing works. with no
> error messages)
>
> I can continue with build --all so it starts over with the result that I
> get stuck in the same module from the beginning.
>
>
> So thats all quite suboptimal. I am not even sure anymore if my uild is
> sane anymore.
>
> Can I force the build process into a sequence build? Maybe that helps.
> would that be -p1?
>
>
> Thanks for any ideas.
>
> all the best
>
> Peter
>
>
>
> On 12.11.2017 15:03, Patricia Shanahan wrote:
>
>> I sometimes get similar messages that go away if I just rerun the build.
>>
>> I think there may be some problem in whatever is supposed to ensure
>> dependencies are built before the things that depend on them.
>>
>> On 11/12/2017 4:24 AM, Peter Kovacs wrote:
>>
>>> |
>>> |
>>>
>>> |My Compile setup:|
>>>
>>> || ./configure   --enable-category-b --enable-bundled-dictionaries
>>> --enable-verbose  --enable-opengl --enable-dbus  --enable-gstreamer
>>> --with-dmake-url=http://sourceforge.net/projects/oooextras.
>>> mirror/files/dmake-4.12.tar.bz2 --with-epm-url=http://www.mswe
>>> et.org/files/project2/epm-3.7-source.tar.gz --without-stlport
>>>
>>>
>>> Checkout is on latest revision. I checked this morning.
>>>
>>> The Compiler says:
>>>
>>> |make: *** No rule to make target '/home/legine/workspace/Apache
>>> OpenOffice/git/main/solver/420/unxlngx6.pro/workdir/
>>> CxxObject/basebmp/source/bitmapdevice.o', needed by
>>> '/home/legine/workspace/ApacheOpenOffice/git/main/solver/420/
>>> unxlngx6.pro/workdir/LinkTarget/Library/libbasebmp.so'. Stop.|
>>>
>>> |Any Ideas Anyone?
>>> |
>>>
>>>
>>>
>>>
>>>
>> -
>> 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: Regressions and testing

[Damjan Jovanovic]

In a module:
OOO_SUBSEQUENT_TESTS=1 build
Results go to main/solver/420/.../workdir/JunitTests for gbuild at least.

There's a Perl script main/solenv/bin/subsequent_tests or something like
that which runs the tests in all modules. It's currently broken at the
first line in the file, but even when that's fixed, it complains about the
gbuild module stack being corrupt.

Subsequent tests have limits and may not help much though. The richest and
most thorough tests that can check content round tripped through saving and
reloading, with screenshots, are the bvt and fvt tests in the tests/
directory (same level as main/). Please search for my previous emails where
I explained more.

On Friday, November 10, 2017, Patricia Shanahan <p...@acm.org> wrote:

> The more automated testing we can do, the better. I have a possible patch
> for one of the regressions. What do I need to do to run the "subsequent
> tests"?
>
> On 11/9/2017 9:46 PM, Damjan Jovanovic wrote:
>
>> Hi
>>
>> It seems to me that regressions that we've had with releases recently
>> could
>> have been prevented with judicious testing.
>>
>> We do already have considerable tests in our tree, but they are never run.
>>
>> I've committed a patch that fixes use of junit with hamcrest in both
>> gbuild
>> and dmake, and should allow us to run "subsequent tests" after a build.
>>
>> Damjan
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Regressions and testing

[Damjan Jovanovic]

We already have a bvt test that writes a spreadsheet with a chart:
https://wiki.openoffice.org/wiki/QA/BVT


On Friday, November 10, 2017, Damjan Jovanovic <dam...@apache.org> wrote:

> In a module:
> OOO_SUBSEQUENT_TESTS=1 build
> Results go to main/solver/420/.../workdir/JunitTests for gbuild at least.
>
> There's a Perl script main/solenv/bin/subsequent_tests or something like
> that which runs the tests in all modules. It's currently broken at the
> first line in the file, but even when that's fixed, it complains about the
> gbuild module stack being corrupt.
>
> Subsequent tests have limits and may not help much though. The richest and
> most thorough tests that can check content round tripped through saving and
> reloading, with screenshots, are the bvt and fvt tests in the tests/
> directory (same level as main/). Please search for my previous emails where
> I explained more.
>
> On Friday, November 10, 2017, Patricia Shanahan <p...@acm.org
> <javascript:_e(%7B%7D,'cvml','p...@acm.org');>> wrote:
>
>> The more automated testing we can do, the better. I have a possible patch
>> for one of the regressions. What do I need to do to run the "subsequent
>> tests"?
>>
>> On 11/9/2017 9:46 PM, Damjan Jovanovic wrote:
>>
>>> Hi
>>>
>>> It seems to me that regressions that we've had with releases recently
>>> could
>>> have been prevented with judicious testing.
>>>
>>> We do already have considerable tests in our tree, but they are never
>>> run.
>>>
>>> I've committed a patch that fixes use of junit with hamcrest in both
>>> gbuild
>>> and dmake, and should allow us to run "subsequent tests" after a build.
>>>
>>> Damjan
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

Re: Simpler Windows builds, oowintool, and Cygwin64

[Damjan Jovanovic]

Great work Matthias :-).

Thank you and good luck.

On Wed, Nov 15, 2017 at 7:17 PM, Matthias Seidel <matthias.sei...@hamburg.de
> wrote:

> I just updated config.guess and config.sub to the latest version.
>
> See: https://www.gnu.org/software/gettext/manual/html_node/
> config_002eguess.html
>
> Regards, Matthias
>
> Am 15.11.2017 um 17:23 schrieb Matthias Seidel:
>
> Hi Damjan,
>
> Next "problem", ./bootstrap can't guess the system:
>
> ---
> entering dmake-4.12
> checking build system type... ./config.guess: unable to guess system type
>
> This script, last modified 2005-07-08, has failed to recognize
> the operating system you are using. It is advised that you
> download the most up to date version of the config scripts from
>
>   http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/
> config/config.guess
> and
>   http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/
> config/config.sub
>
> If the version you run (./config.guess) is already up to date, please
> send the following data and any information you think might be
> pertinent to <config-patc...@gnu.org> <config-patc...@gnu.org> in order
> to provide the needed
> information to handle your system.
>
> config.guess timestamp = 2005-07-08
>
> uname -m = x86_64
> uname -r = 2.9.0(0.318/5/3)
> uname -s = CYGWIN_NT-10.0
> uname -v = 2017-09-12 10:18
>
> /usr/bin/uname -p = unknown
> /bin/uname -X =
>
> hostinfo   =
> /bin/universe  =
> /usr/bin/arch -k   =
> /bin/arch  = x86_64
> /usr/bin/oslevel   =
> /usr/convex/getsysinfo =
>
> UNAME_MACHINE = x86_64
> UNAME_RELEASE = 2.9.0(0.318/5/3)
> UNAME_SYSTEM  = CYGWIN_NT-10.0
> UNAME_VERSION = 2017-09-12 10:18
> configure: error: cannot guess build type; you must specify one
> ---
>
> I am wondering about the timestamp, our config.guess is from 2009-12-30.
>
> Regards, Matthias
>
>
> Am 14.11.2017 um 03:06 schrieb Damjan Jovanovic:
>
> Please test whether the attached patch helps?
>
> Regards
> Damjan
>
> On Sat, Nov 11, 2017 at 8:02 PM, Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
>
>> Hi Damjan,
>>
>> Am 10.11.2017 um 06:27 schrieb Damjan Jovanovic:
>> > Hi
>> >
>> > I've committed a few small small fixes to oowintool, mostly for JDK 8
>> > detection and better logging, but I've confirmed that it already works
>> > well, and --with-frame-home --with-psdk-home --with-midl-path
>> > --with-jdk-home --with-csc-path and --with-cl-home options to
>> ./configure
>> > are all unnecessary.
>> >
>> > As for 64 bit Cygwin I believe the problem with oowintool is that it
>> needs
>> > to look under the Wow6432node subkey in the registry too, something that
>> > should be easy to add. Is anyone available to test 64 bit Cygwin?
>>
>> I just installed Cygwin64 on Windows 10 and ./configure stops with:
>>
>> Can't find MS Visual Studio / VC++ at ./oowintool line 236.
>> configure: error: oowintool failed to copy CRT
>>
>> Regards, Matthias
>>
>> >
>> > Damjan
>> >
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
>
>

Re: 4.2.0: Build for ARM

[Damjan Jovanovic]

What do you mean by category?

On Tue, Nov 28, 2017 at 11:21 AM, Peter kovacs <pe...@apache.org> wrote:

> What's the category for those?
>
> Am 28. November 2017 08:42:17 MEZ schrieb Damjan Jovanovic <
> dam...@apache.org>:
> >Raspberry Pis?
> >
> >On Tue, Nov 28, 2017 at 9:41 AM, Peter kovacs <pe...@apache.org> wrote:
> >
> >> Maybe the patch is interesting to AndroOffice? Anyone from them on
> >our
> >> list?
> >>
> >> In general I'd say that we need a different gui for touch screen
> >devices.
> >>
> >> The other case is I can think of ARM processors is arduino machines
> >with
> >> Linux installed. Don't know if this is a use case at all.
> >>
> >> Am 27. November 2017 23:46:27 MEZ schrieb Marcus
> ><marcus.m...@wtnet.de>:
> >> >Am 24.11.2017 um 23:16 schrieb FR web forum:
> >> >> Here: https://bz.apache.org/ooo/show_bug.cgi?id=127040
> >> >> Eric Bachard provide a patch to build AOO on Linux ARM (32 bits).
> >> >>
> >> >> Maybe a good point for next 4.2.0?
> >> >
> >> >I don't know how relevant the ARM architecture still is and if an
> >> >office
> >> >suite is useful for it. However, someone needs to take care of the
> >> >ability for building on this platform. A patch is nice but is not
> >> >enough
> >> >for future changes within the whole code base.
> >> >
> >> >My 2 ct
> >> >
> >> >Marcus
> >> >
> >> >
> >>
> >>-
> >> >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> >For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: svn commit: r1815700 - /openoffice/trunk/main/framework/Library_fwk.mk

[Damjan Jovanovic]

Who confirmed that it "also affects FreeBSD 10.3 with clang 3.4.1"?
If it was me, I was wrong, as I said later in the same email thread.

On Mon, Nov 27, 2017 at 9:34 AM, Don Lewis  wrote:

> On 26 Nov, Don Lewis wrote:
> > On 26 Nov, Don Lewis wrote:
> >> On 18 Nov, j...@apache.org wrote:
> >>> Author: jim
> >>> Date: Sat Nov 18 22:24:42 2017
> >>> New Revision: 1815700
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1815700=rev
> >>> Log:
> >>> Force compilation with -O1 flag instead of -O2
> >>>
> >>> Modified:
> >>> openoffice/trunk/main/framework/Library_fwk.mk
> >>>
> >>> Modified: openoffice/trunk/main/framework/Library_fwk.mk
> >>> URL: http://svn.apache.org/viewvc/openoffice/trunk/main/
> framework/Library_fwk.mk?rev=1815700=1815699=1815700=diff
> >>> 
> ==
> >>> --- openoffice/trunk/main/framework/Library_fwk.mk (original)
> >>> +++ openoffice/trunk/main/framework/Library_fwk.mk Sat Nov 18
> 22:24:42 2017
> >>> @@ -61,6 +61,10 @@ $(eval $(call gb_Library_add_linked_libs
> >>> $(gb_STDLIBS) \
> >>>  ))
> >>>
> >>> +ifeq ($(OS),MACOSX)
> >>> +gb_COMPILEROPTFLAGS := -O1
> >>> +endif
> >>> +
> >>>  $(eval $(call gb_Library_add_exception_objects,fwk,\
> >>> framework/source/accelerators/acceleratorcache \
> >>> framework/source/accelerators/acceleratorconfiguration \
> >>>
> >>>
> >>
> >> I'd like to propose the patch below as an alternative:
> >>  * FreeBSD 10 / amd64 also has this problem.  It just depends on the
> >>machine architecture and clang version.
> >>
> >>  * The patch below only changes the optimization for one file, not
> >>everything in this library.
> >>
> >>  * Hardwiring -O1 does the wrong thing for debug builds, which want to
> >>totally disable optimization so that the values of variables are not
> >>optimized out.
> >>
> >> Admittedly this patch is a bit ugly because gbuild doesn't currently
> >> have a way to set target-specific optimization flags.  The problem is
> >> that it passes $(gb_COMPILEROPTFLAGS) as a function call argument, which
> >> is evaluated globally and not in a target-specific context.  This should
> >> be fixable.
> >>
> >> What does 'cc --version' report on the Mac for the different releases
> >> that work / don't work properly?  I'd like to bring $(CCNUMVER) to
> >> gbuild so that these sorts of tweaks are only enabled for the compiler
> >> versions that need it.
> >>
> >> --- framework/Library_fwk.mk.orig2017-10-11 11:40:20 UTC
> >> +++ framework/Library_fwk.mk
> >> @@ -186,4 +186,11 @@ $(eval $(call gb_Library_add_exception_
> objects,fwk,\
> >>  framework/source/xml/imagesdocumenthandler \
> >>  ))
> >>
> >> +# i126622 - Base 4.1.2 does not open Tables and Queries in Mac OSX
> >> +# Also affects FreeBSD 10.3 with clang 3.4.1.
> >> +# Appears to be a clang optimization bug in versions less than 3.8.0
> >> +ifeq ($(COM)$(CPUNAME),CLANGX86_64)
> >> +$(call gb_CxxObject_get_target,framework/source/loadenv/loadenv):
>  CXXFLAGS := $(gb_LinkTarget_CXXFLAGS) $(gb_LinkTarget_EXCEPTIONFLAGS)
> $(gb_COMPILERNOOPTFLAGS)
> >> +endif
> >> +
> >>  # vim: set noet sw=4 ts=4:
> >
> > This patch is for 4.1.4.  It doesn't work on trunk, but the fix there
> > looks easier.  I'll post it once I have it tested.
>
> Here's the patch for trunk.  I turned out not to be any easier, just
> different.
>
> --- framework/Library_fwk.mk.orig   2016-08-29 00:45:25 UTC
> +++ framework/Library_fwk.mk
> @@ -190,4 +190,11 @@ $(eval $(call gb_Library_add_exception_objects,fwk,\
> framework/source/xml/imagesdocumenthandler \
>  ))
>
> +# i126622 - Base 4.1.2 does not open Tables and Queries in Mac OSX
> +# Also affects FreeBSD 10.3 with clang 3.4.1.
> +# Appears to be a clang optimization bug in versions less than 3.8.0
> +ifeq ($(COM)$(CPUNAME),CLANGX86_64)
> +$(call gb_CxxObject_get_target,framework/source/loadenv/loadenv):
>  T_CXXFLAGS := $(gb_LinkTarget_CXXFLAGS) $(gb_LinkTarget_EXCEPTIONFLAGS)
> $(gb_COMPILERNOOPTFLAGS)
> +endif
> +
>  # vim: set noet sw=4 ts=4:
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: AOO 4.2.0-dev builds

[Damjan Jovanovic]

When you get that error, before clicking "OK", please attach gdb and run
"thread apply all bt", and post the output.

Damjan

On Sun, Nov 26, 2017 at 8:30 PM, Matthias Seidel  wrote:

> Thanks, I could download and install the build now.
>
> However, the bug [1] is still present for me on Ubuntu 16.04.3 (64bit).
>
> So it is not only an issue when building on Ubuntu 14.04 (like our
> buildbots do).
>
> Regards, Matthias
>
> [1] https://bz.apache.org/ooo/show_bug.cgi?id=127315
>
>
> Am 26.11.2017 um 15:03 schrieb Jim Jagielski:
> > should be fixed now.
> >
> >> On Nov 26, 2017, at 5:54 AM, Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
> >>
> >> Am 26.11.2017 um 00:09 schrieb Jim Jagielski:
> >>> I am uploading to:
> >>>
> >>>http://home.apache.org/~jim/AOO-builds/ <
> http://home.apache.org/~jim/AOO-builds/>
> >>>
> >>> 4.2.0-dev builds for Linux64 and Windows... After that will
> >>> come Linux32 and macOS (assuming it builds... I've had
> >>> issues before).
> >>>
> >>> These are based on HEAD of trunk, ~r1816311. The Linux builds
> >>> are built on CentOS 6.9.
> >> "You don't have permission to access
> >> /~jim/AOO-builds/AOO-4.2.0-dev-r1816311/de/Apache_
> OpenOffice_4.2.0_Linux_x86-64_install-deb_de.tar.gzon
> >> this server."
> >>
> >> ;-)
> >>
> >>
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>
>
>

Re: another bug in base

[Damjan Jovanovic]

I can't reproduce it here, on trunk with:
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.3
with either our built-in HSQLDB driver or SQlite over ODBC.

What version of AOO are you using? What database driver? What build
settings?

Damjan

On Mon, Nov 27, 2017 at 1:47 AM, Don Lewis  wrote:

> I'm seeing another bug in base on all versions of FreeBSD.  To
> reproduce:
>   1. Open an existing database
>   2. Select Table in the far left pane
>   3. Select a table in the lower left pane
>   4. Select Document in the lower right pane
> At that point, my mouse cursor shows that something is busy.  I am able
> to File->Exit, but nothing happens.  If I ^c the process, it drops core
> with this backtrace:
>
> #0  0x0008051f5c9f in GraphicReader::GetPreviewSize ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libvcl.so
> #1  0x0008051f47bf in GraphicReader::GetPreviewSize ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libvcl.so
> #2  0x0008051f42c0 in GraphicReader::GetPreviewSize ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libvcl.so
> #3  0x0008051e7e43 in ImageList::~ImageList ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libvcl.so
> #4  0x0008051e8b92 in ImageList::GetImage ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libvcl.so
> #5  0x000803aaf6e3 in SvFileInformationManager::GetFolderImage ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsvt.so
> #6  0x000803aadd1d in SvFileInformationManager::GetFileImage ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsvt.so
> #7  0x000805fb38e2 in SvxXShadowPreview::Paint ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsvx.so
> #8  0x000809f23000 in component_getFactory ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libfwk.so
> #9  0x000805faf122 in SvxXShadowPreview::Paint ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsvx.so
> #10 0x000805faedfc in SvxXShadowPreview::Paint ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsvx.so
> #11 0x0008060c2c2a in SvxVertTextTbxCtrl::SvxVertTextTbxCtrl ()
> ---Type  to continue, or q  to quit---
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsvx.so
> #12 0x0008060c2a15 in SvxVertTextTbxCtrl::SvxVertTextTbxCtrl ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsvx.so
> #13 0x0008060c3148 in SvxVertTextTbxCtrl::SvxVertTextTbxCtrl ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsvx.so
> #14 0x000800c2eb6a in ?? ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsofficeapp.so
> #15 0x000800c2ef09 in ?? ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libsofficeapp.so
> #16 0x000805139ebe in VclResId ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libvcl.so
> #17 0x000800852da9 in osl_setErrorReporting ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libuno_sal.so.3
> #18 0x0008243bfc64 in os::Bsd::chained_handler ()
>from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
> #19 0x0008243c2a4f in JVM_handle_bsd_signal ()
>from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
> #20 0x0008243bfadd in signalHandler ()
>from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
> #21 0x0008017afb37 in pthread_sigmask () from /lib/libthr.so.3
> #22 0x0008017af22c in pthread_getspecific () from /lib/libthr.so.3
> #23 
> #24 0x00080085fd11 in rtl_locale_equals ()
> ---Type  to continue, or q  to quit---
>from /usr/local/openoffice-4.1.4/openoffice4/program/libuno_sal.so.3
> #25 0x00080085fbc3 in rtl_locale_equals ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libuno_sal.so.3
> #26 0x000800864437 in rtl_uString_release ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libuno_sal.so.3
> #27 0x00081bc98c85 in ?? ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/../program/
> libpackage2.so
> #28 0x00081bcc9afb in ?? ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/../program/
> libpackage2.so
> #29 0x00081bcc70ed in ?? ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/../program/
> libpackage2.so
> #30 0x00081bcc704f in ?? ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/../program/
> libpackage2.so
> #31 0x000802140e7a in cppu::OWeakObject::release ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libuno_cppuh
> elpergcc3.so.3
> #32 0x0008051f5f24 in GraphicReader::GetPreviewSize ()
>from /usr/local/openoffice-4.1.4/openoffice4/program/libvcl.so
> #33 0x0008051f404e in GraphicReader::GetPreviewSize ()
> ---Type  to continue, or q  to quit---
>from /usr/local/openoffice-4.1.4/openoffice4/program/libvcl.so
> #34 0x00080513403a in AllSettings::LocaleSettingsChanged ()
>from 

Re: AOO 4.1.5-dev builds

[Damjan Jovanovic]

Thank you, but when are these 4.1.x releases going to stop?

We have so much lined up for 4.2.0.

Damjan

On Mon, Nov 20, 2017 at 5:49 PM, Jim Jagielski  wrote:

> I have both macOS and Linux-64bit builds of 4.1.5-dev (HEAD on the
> AOO415 branch) available for fun and games (and testing) at:
>
> http://home.apache.org/~jim/AOO-builds/
>
> I've built all langs but have just uploaded: de, en-US, es, fr
> and ja (for now). Let me know if people want/need others
> uploaded.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: AOO 4.1.5-dev builds

[Damjan Jovanovic]

What's the alternative to going to 4.2.0?

I only test trunk. So it's 4.1.x that lacks testing from me.

We also really should start running the various tests and comparing results
from trunk against 4.1's.

On Wed, Nov 22, 2017 at 2:05 PM, Patricia Shanahan <p...@acm.org> wrote:

> I see 4.1.5-dev as a device for testing whether a bug is due to a specific
> problem. That change is already checked in to the trunk.
>
> We still have to decide whether to go straight to 4.2.0. The upside is, as
> Damjam points out, that we need to get the general benefits of 4.2 out in
> the field. The downside is that, because of more changes, 4.2.0 has a
> higher risk of regression. Should 4.2.0 go through field beta-testing?
>
> Going to 4.2.0 would simplify my activities. Because of better debug
> building and on general principles, I do my debug and fixing in trunk. I
> then have to back port the fixes to the 4.1.x line.
>
>
> On 11/22/2017 2:37 AM, Damjan Jovanovic wrote:
>
>> Thank you, but when are these 4.1.x releases going to stop?
>>
>> We have so much lined up for 4.2.0.
>>
>> Damjan
>>
>> On Mon, Nov 20, 2017 at 5:49 PM, Jim Jagielski <j...@jagunet.com> wrote:
>>
>> I have both macOS and Linux-64bit builds of 4.1.5-dev (HEAD on the
>>> AOO415 branch) available for fun and games (and testing) at:
>>>
>>>  http://home.apache.org/~jim/AOO-builds/
>>>
>>> I've built all langs but have just uploaded: de, en-US, es, fr
>>> and ja (for now). Let me know if people want/need others
>>> uploaded.
>>>
>>> -
>>> 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.
> http://www.avg.com
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: AOO 4.1.5-dev builds

[Damjan Jovanovic]

On Wed, Nov 22, 2017 at 6:48 PM, Dave Fisher  wrote:

>
> Regarding 4.2.0. What are the new features and is everything being worked
> into trunk complete? If we were to decide to release it “quickly” what
> needs to be done?
>

I don't recommend releasing 4.2.0 immediately; maybe in a month or 2 after
my PostgreSQL driver and several other outstanding projects are complete.

I'll give you a summary of my own changes in trunk for the past year or so;
it's been a quiet year compared to the 2 years before it, and I've made at
least 365 total commits to trunk since AOO was an incubator project. You
can see why I want the improvements to get out there and people to use them:

Database connections through ODBC don't crash on 64 bit.
oowintool detects Java 8, and finds VC++ on Cygwin64.
Fixes for several fvt tests; they now pass.
Newer versions of JUnit work with Hamcrest for subsequent tests.
Database connections using JDBC now use the new driver rewritten in Java,
with tons of bug fixes and high reliability (Java doesn't corrupt memory,
reports exceptions instead of crashing).
New driver for the PostgreSQL database, supporting the advanced features
like relationships, views, keys, constraints, etc. (Development ongoing)
Buggy DXF files no longer crash AOO.
Various dependency improvements, eg. cairo and pixman are downloaded if
enabled and and system libraries aren't used.
Drop a dependency on ORbit which was last needed in 2003.
GIO instead of GnomeVFS (deprecated 9 years ago) is now the default backend
on GTK-based desktops.
Java's ComponentBase base class for UNO components now has isDisposed() and
checkDisposed() methods.
ComponentBase locking on disposal fix.
Require Apache Commons Lang for the build.
#i32546# - Java UnoRuntime.getUniqueKey/generateOid do not work reliably
Remove some incorrect API documentation for the
com.sun.star.sdbc.SQLException ErrorCode field.
We need the system Apache Commons Lang to be version 3.x.
Write a main/ant.properties file from main/set_soenv, which can be used in
Ant projects to work out settings, locations, and paths to dependencies
without getting them from a parent build tool (dmake/gbuild), which allows
Ant projects to build by themselves,  independently of AOO, and allows them
to be cleanly opened in (at least) Eclipse.
Remove the obsolete KDE address book SDBC driver, that only worked on KDE
3.2 - 3.6, which are obsolete since 9 years ago.
Update AnyConverter.toObject() to use Java 1.5+'s generics.
If called on an empty collection, don't let
OEnumerationByIndex.nextElement() call XIndexAccess.getByIndex() with an
invalid index, just like OEnumerationByName.nextElement() doesn't.
Fix some comment typos in javaunohelper's PropertySet.java,
Update javaunohelper's MultiTypeInterfaceContainer.java to use generics,
and fix performance bugs in getContainer() where O(n) iteration over all
keys was being done instead of an O(1) map.get(), and in
getContainedTypes() where iteration over keys and then n calls to map.get()
for the value was being done instead of iteration over entries.
Java boxing optimization and cleanups for l10ntools.
Use more efficient Java boxing in main/filter.
Use more efficient Java boxing for basic types in main/bean.
Add some Java performance optimizations with boxing of basic types: instead
of using "new ()", use .valueOf(), or better yet,
rely on autoboxing.
Add initial support for building AOO with Clang on Linux.
We need to pass "-DEBUG" to the linker on Windows for debugging to work.
When debug symbols are produced for C / C++ / Objective C, produce them for
Java too.
Add debug symbols to gbuild modules when any of --enable-debug,
--enable-symbols, or --enable-crashdump are passed to ./configure (just
like it already is for dmake modules), as opposed to the previous behaviour
of only doing it on --enable-debug.
Fix a FreeBSD regression in the gbuild gb_CPUDEFS variable caused by
r1773166, where it was always set to POWERPC64 due to a swapped if-else.
Don't use the "archive" package format, which is to be extrated by
smoketest as a side effect, for the subsequent tests. The smoketest is
currently broken and won't do that, and the path is wrong anyway. Instead,
use the office instance from the "installed" package format for subsequent
tests, as it doesn't have to zipped up and unzipped, resulting in faster
building and faster testing, and doesn't require a side effect.
Pass "-encoding UTF8" to javac, as some Java sources, particularly those
used in subsequent tests, contain special characters that are encoded in
UTF-8, and fail to compile without this option.
Correlate the Perl modules tested for in bulk with the Perl modules tested
for individually to be reported as missing, so that those reported as
missing are correct.
Add a main/sd subsequent test that wasn't hooked into the build.
Fix a configure.ac problem with hamcrest detection.
Fix a main/sw subsequent test.
Add a ./configure option for Hamcrest once again, this time 

Re: 4.2.0: Build for ARM

[Damjan Jovanovic]

Raspberry Pis?

On Tue, Nov 28, 2017 at 9:41 AM, Peter kovacs  wrote:

> Maybe the patch is interesting to AndroOffice? Anyone from them on our
> list?
>
> In general I'd say that we need a different gui for touch screen devices.
>
> The other case is I can think of ARM processors is arduino machines with
> Linux installed. Don't know if this is a use case at all.
>
> Am 27. November 2017 23:46:27 MEZ schrieb Marcus :
> >Am 24.11.2017 um 23:16 schrieb FR web forum:
> >> Here: https://bz.apache.org/ooo/show_bug.cgi?id=127040
> >> Eric Bachard provide a patch to build AOO on Linux ARM (32 bits).
> >>
> >> Maybe a good point for next 4.2.0?
> >
> >I don't know how relevant the ARM architecture still is and if an
> >office
> >suite is useful for it. However, someone needs to take care of the
> >ability for building on this platform. A patch is nice but is not
> >enough
> >for future changes within the whole code base.
> >
> >My 2 ct
> >
> >Marcus
> >
> >
> >-
> >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: AOO 4.2.0-dev builds

[Damjan Jovanovic]

CentOS 5 is now EOL, even its maintenance updates ended on 31 March 2017. I
think we have to move to CentOS 6.

I made GIO the default VFS searched by configure instead of GnomeVFS, as
that's what everybody has been using for years; AOO is pretty much the only
application still pulling in that ancient package with who knows what
security issues. It was done in this commit:

r1812655 | damjan | 2017-10-19 18:35:49 +0200 (Thu, 19 Oct 2017) | 6 lines
Changed paths:
   M /openoffice/trunk/main/configure.ac

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



If we really need GnomeVFS back, we can revert that commit, or use
./configure switches to favor GnomeVFS over GIO.

Damjan



On Fri, Nov 24, 2017 at 5:46 PM, Jim Jagielski  wrote:

> True, but not ALL dependencies... for example, we require egrep :)
>
> But Zip 3.0.0 is one specifically checked for:
>
> > dnl ===
> > dnl Zip must be available or else it is an error, all platforms
> > dnl ===
> > if test -z "$ZIP" -o -z "$UNZIP"; then
> > AC_MSG_ERROR([Zip/Unzip are required to build, please install or use
> --with-zip-home],,)
> > fi
> > if "$ZIP" -FS < /dev/null 2>&1 | $EGREP "no such option: S" > /dev/null;
> then
> > AC_MSG_ERROR([Zip version 3.0 or newer is required to build, please
> install or use --with-zip-home],,)
> > fi
> >
>
> It does look like all previous builds, up to and including 4.1.4 were done
> on
> CentOS5 (for the released binaries).
>
> So the question is that w/ 4.2.0, do we no longer support CentOS 5 as a
> supported build platform. Another dependency seems to be GIO, but we
> can build w/o that. But is that really an option for our community builds??
>
>
> > On Nov 24, 2017, at 10:39 AM, Peter Kovacs  wrote:
> >
> > I thought we add all dependencies to the build process. (thats why our
> build takes ages.)
> > I thought the only distibution dependency is the build environment.
> > Maybe I am wrong. If so I do not understand how CentOS5 can be
> compatible to everything else.
> >
> > On 24.11.2017 16:23, Jim Jagielski wrote:
> >>> On Nov 23, 2017, at 12:43 PM, Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
> >>>
> >>> Hi Rory,
> >>>
> >>> Am 23.11.2017 um 18:31 schrieb Rory O'Farrell:
>  I have downloaded and install AO0 4.2.0 for linux from
>  https://ci.apache.org/projects/openoffice/install/
> linux64/Apache_OpenOffice_4.2.0_Linux_x86-64_install-deb_en-
> US_2017-11-23_04%3A16%3A31_1816101.tar.gz
> 
>  When opening a Writer file from the splash screen I get a "general
> error" message, then the file opens.  Starting AOO 4.2.0 from a terminal
> gives the message
>  ** (soffice:2353): WARNING **: Unknown type: GailWindow
>  The file then opens; it will accept a simple edit, and close
> correctly.
> >>> That sounds like this issue:
> >>> https://bz.apache.org/ooo/show_bug.cgi?id=127315
> >>>
> >>> It would be interesting if it only affects builds based on Ubuntu
> >>> (14.04). Can someone build 4.2.0 on CentOS under release conditions?
> >>>
> >> Question: Is CentOS 5 still our preferred version, or should we
> deprecate
> >> CentOS5 for CentOS 6?
> >>
> >> There are some things that 4.2.0 requires requires some updated 3rd
> party
> >> libs, like zip 3.0.0 or later, etc.
> >>
> >> If I had to vote, I'd say w/ assume (and stay w/) CentOS 5 since the
> upgrade to
> >> CentOS 6 will likely cause a lot of potential for regressions.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: 4.2.0: Build for ARM

[Damjan Jovanovic]

Not sure about the Arduino, but the Raspberry Pi is usable as a desktop
computer, with a keyboard/mouse/screen.


On Wed, Nov 29, 2017 at 12:26 AM, Peter kovacs <pe...@apache.org> wrote:

> How can anduino and rasperry machines referred to?
>
> Am 28. November 2017 10:55:21 MEZ schrieb Damjan Jovanovic <
> dam...@apache.org>:
> >What do you mean by category?
> >
> >On Tue, Nov 28, 2017 at 11:21 AM, Peter kovacs <pe...@apache.org>
> >wrote:
> >
> >> What's the category for those?
> >>
> >> Am 28. November 2017 08:42:17 MEZ schrieb Damjan Jovanovic <
> >> dam...@apache.org>:
> >> >Raspberry Pis?
> >> >
> >> >On Tue, Nov 28, 2017 at 9:41 AM, Peter kovacs <pe...@apache.org>
> >wrote:
> >> >
> >> >> Maybe the patch is interesting to AndroOffice? Anyone from them on
> >> >our
> >> >> list?
> >> >>
> >> >> In general I'd say that we need a different gui for touch screen
> >> >devices.
> >> >>
> >> >> The other case is I can think of ARM processors is arduino
> >machines
> >> >with
> >> >> Linux installed. Don't know if this is a use case at all.
> >> >>
> >> >> Am 27. November 2017 23:46:27 MEZ schrieb Marcus
> >> ><marcus.m...@wtnet.de>:
> >> >> >Am 24.11.2017 um 23:16 schrieb FR web forum:
> >> >> >> Here: https://bz.apache.org/ooo/show_bug.cgi?id=127040
> >> >> >> Eric Bachard provide a patch to build AOO on Linux ARM (32
> >bits).
> >> >> >>
> >> >> >> Maybe a good point for next 4.2.0?
> >> >> >
> >> >> >I don't know how relevant the ARM architecture still is and if an
> >> >> >office
> >> >> >suite is useful for it. However, someone needs to take care of
> >the
> >> >> >ability for building on this platform. A patch is nice but is not
> >> >> >enough
> >> >> >for future changes within the whole code base.
> >> >> >
> >> >> >My 2 ct
> >> >> >
> >> >> >Marcus
> >> >> >
> >> >> >
> >> >>
> >>
> >>>-
> >> >> >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> >> >For additional commands, e-mail: dev-h...@openoffice.apache.org
> >> >>
> >> >>
> >-
> >> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >> >>
> >> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

A more sane way to build - SCons, deCygwination and other hopes

[Damjan Jovanovic]

Hi

After days of failing to add a few new simple features to gbuild, I've now
reached my limits, and have begun experimenting with the SCons build system
instead.

It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk and
platform/freebsd.mk to SCons, as well as a module's local gbuild files, I
can now compile files and (badly) link them into libraries, and clean the
build.

SCons is an advanced next-generation build system like gbuild, with high
level declarative syntax in Python, support for multiple modules that build
in parallel, header dependencies, file change detection through MD5 sums of
contents instead of timestamps so rebuilds are faster, etc. It builds C,
C++, Objective C, Java, Fortran, D, the sorely necessary Flex and Yacc that
gbuild doesn't support. It supports tons of platforms and compilers,
including OS/2. It's maintainable and usable, can print debugging info such
as dependency trees, and is generally pleasant to work with. We've
discussed it before on this list, but I never got to trying it until now.

Virtually everything gbuild does, is already done by SCons, and often done
much better. The syntax for SCons files is similar/related to gbuild's
syntax, so an automated conversion from gbuild to SCons might even be
possible.

So far, I have defines, includes and C[XX]FLAGS working. I've structured it
a bit better, with platform-specific files in classes that only provide
variables to slot in higher up, instead of one giant set of globally
mutable global variables like in gbuild. Linking still needs a bit of work.
Windows is next on the list, as Cygwin will be the ultimate test of whether
we can use it.

I am very hopeful. SCons has a long history and is used by other projects,
while only OO.o derivatives use gbuild. It's well documented. It supports
features we need which gbuild doesn't, like library version names and
flex/yacc. It's supposed to work on Windows, both inside and outside of
Cygwin and could help us build without Cygwin some day. It supports many
versions of Visual Studio and could help us in upgrading to a new one. We
will need to add custom builders to SCons for our custom file formats like
IDL, but it's just Python, not my favorite language but infinitely better
than GNU make.

It would help if someone could review my changes, as I am not very familiar
with Python and there might be better ways to write some of the code. I'll
post a patch for review after some further development.

Thank you
Damjan

Re: 4.2.0: Baseline CentOS6 as reference build platform

[Damjan Jovanovic]

Sorry what I meant to say was, those flags to ./configure still let you
build with Gnome VFS instead of GIO.

I didn't take GIO out of the build, I just switched the default VFS
implementation from Gnome VFS to GIO.

Damjan

On Sun, Dec 3, 2017 at 4:28 PM, Jim Jagielski <j...@jagunet.com> wrote:

>
> > On Dec 3, 2017, at 1:16 AM, Damjan Jovanovic <dam...@apache.org> wrote:
> >
> > On Sun, Dec 3, 2017 at 2:25 AM, Jim Jagielski <j...@jagunet.com> wrote:
> >
> >>
> >>> On Dec 2, 2017, at 5:56 PM, Andrea Pescetti <pesce...@apache.org>
> wrote:
> >>>
> >>> On 30/11/2017 Jim Jagielski wrote:
> >>>> I think for 4.2.x and later, we have deprecated CentOS5 as a supported
> >>>> build system... I ran into a LOT of issues.
> >>>
> >>> Such as, for example?
> >>
> >> for starters:
> >>  o zip 3.0.
> >>  o GIO
> >>
> >>
> > If you *really* need GIO, try adding --disable-gio --enable-gnome-vfs to
> > ./configure.
> >
>
> The issue is that CentOS5 simply does not and can not provide GIO.
> So it is, IMO at least, unsuitable for our reference community
> build platform.
>
> This was brought up on the "AOO 4.2.0-dev builds" thread.

Re: AOO 4.2.0-dev builds

[Damjan Jovanovic]

Yes it is :)

Thank you.

On Fri, Dec 1, 2017 at 7:34 PM, Matthias Seidel <matthias.sei...@hamburg.de>
wrote:

> Am 26.11.2017 um 19:47 schrieb Damjan Jovanovic:
> > When you get that error, before clicking "OK", please attach gdb and run
> > "thread apply all bt", and post the output.
> >
> > Damjan
>
> Hi Damjan,
>
> I will do this as soon as I figured out how it works... ;-)
>
> gdb=Gnu Debugger?
>
> Regards, Matthias
>
> >
> > On Sun, Nov 26, 2017 at 8:30 PM, Matthias Seidel <
> matthias.sei...@hamburg.de
> >> wrote:
> >> Thanks, I could download and install the build now.
> >>
> >> However, the bug [1] is still present for me on Ubuntu 16.04.3 (64bit).
> >>
> >> So it is not only an issue when building on Ubuntu 14.04 (like our
> >> buildbots do).
> >>
> >> Regards, Matthias
> >>
> >> [1] https://bz.apache.org/ooo/show_bug.cgi?id=127315
> >>
> >>
> >> Am 26.11.2017 um 15:03 schrieb Jim Jagielski:
> >>> should be fixed now.
> >>>
> >>>> On Nov 26, 2017, at 5:54 AM, Matthias Seidel <
> >> matthias.sei...@hamburg.de> wrote:
> >>>> Am 26.11.2017 um 00:09 schrieb Jim Jagielski:
> >>>>> I am uploading to:
> >>>>>
> >>>>>http://home.apache.org/~jim/AOO-builds/ <
> >> http://home.apache.org/~jim/AOO-builds/>
> >>>>> 4.2.0-dev builds for Linux64 and Windows... After that will
> >>>>> come Linux32 and macOS (assuming it builds... I've had
> >>>>> issues before).
> >>>>>
> >>>>> These are based on HEAD of trunk, ~r1816311. The Linux builds
> >>>>> are built on CentOS 6.9.
> >>>> "You don't have permission to access
> >>>> /~jim/AOO-builds/AOO-4.2.0-dev-r1816311/de/Apache_
> >> OpenOffice_4.2.0_Linux_x86-64_install-deb_de.tar.gzon
> >>>> this server."
> >>>>
> >>>> ;-)
> >>>>
> >>>>
> >>>>
> >>>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>>
> >>>
> >>
> >>
>
>
>

Re: FYI: The OO 4.1.4 Mac problem

[Damjan Jovanovic]

Thank you :).

What "success code"? Which multiple implementations?

On Fri, Nov 17, 2017 at 4:41 PM, Peter kovacs <pe...@apache.org> wrote:

> Awesome thanks Damjan!
>
> Would it make sense to route the success code through the connectivity
> code for the future?
>
> I would rather like to have one time implementation instead of maintain
> redundant implementations.
> ( the drawback is that bugs have bigger impact. Ofc)
>
>
> Am 17. November 2017 15:26:57 MEZ schrieb Damjan Jovanovic <
> dam...@apache.org>:
> >Hi
> >
> >I am familiar with the database driver code in main/connectivity, but
> >much
> >less familiar with the Base code main/dbaccess where the problem is.
> >
> >On an unrelated past bug in my code in a main/connectivity driver, I
> >did
> >however briefly encounter that same problem where clicking "Create
> >table"
> >does nothing. Debugging it proved very difficult. Far too commonly,
> >Base
> >catches and silently swallows exceptions via the likes of:
> >
> >catch (Exception&) {}
> >
> >which explains why no error is reported to the user, and means that
> >even if
> >you put a breakpoint on such a line, you can't see anything about the
> >exception as there is no variable it's assigned to: not the exception's
> >particular subtype, not its message, and in the abomination that is C++
> >generally, never the most useful part: its stack trace.
> >
> >I then tried doing "catch throw" in gdb to try examine the exception
> >when
> >it's thrown instead of caught, however that took me on a wild goose
> >chase,
> >as multiple harmless exceptions get thrown during the course of that
> >dialog
> >opening.
> >
> >Eventually I gave up and fixed the bug in my main/connectivity driver.
> >I
> >can't remember which bug; probably that null strings were being
> >returned
> >from Java to UNO, and UNO strings can't ever be null (even in AOO's
> >C++,
> >the infamous OUString is always empty, never null).
> >
> >Later I can try to find and send you the beginning of that path through
> >the
> >Base code that's involved in opening the "Create table" dialog, so you
> >have
> >somewhere to start from. Since I don't have a Mac or access to one, I
> >can't
> >help debug this directly. But feel free to ask me any questions.
> >
> >Regards
> >Damjan
> >
> >
> >On Thu, Nov 16, 2017 at 10:12 PM, Dave Fisher <dave2w...@comcast.net>
> >wrote:
> >
> >> Hi Damjan,
> >>
> >> Do you have any tips or pointers regarding the Base issue we are
> >having
> >> with Builds on MacOS?
> >>
> >> I’m seeing your comments on https://bz.apache.org/ooo/
> >> show_bug.cgi?id=126655 and can’t help but wonder if the code is
> >fragile
> >> here. If nothing else some help tracing the code could help.
> >>
> >> Does the Redland configuration and the update in trunk help us here?
> >>
> >> Regards,
> >> Dave
> >>
> >> > On Nov 16, 2017, at 10:40 AM, Jim Jagielski <j...@jagunet.com>
> >wrote:
> >> >
> >> > OK, I am pretty much almost out of ideas. I've created a VM which
> >is
> >> > almost an exact match for what I could determine was the build
> >> > environ for 4.1.2. Attached is a patch file that shows the diffs
> >between
> >> > the config.out for 4.1.2 and my build of 4.1.2. My build doesn't
> >suffer
> >> > from the corrupted diagram but it DOES still suffer from the
> >> table/Database
> >> > regression. AFAIK, the official 4.1.2 build suffers from neither.
> >> >
> >> > So what is causing this weird behavior I simply don't know... As
> >> > one can see, there's nothing, at least as reported by config.log,
> >which
> >> is
> >> > different and this is straight from
> >> >
> >> >   https://svn.apache.org/repos/asf/openoffice/tags/AOO412
> >> >
> >> > 
> >> >
> >-
> >> > 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
>
>

Debugging Base's "Create Table in Design View"

[Damjan Jovanovic]

tl;dr:
Put a breakpoint on dbaui::DatabaseObjectView::doDispatch or
/full/path/to/main/dbaccess/source/ui/misc/databaseobjectview.cxx:120 just
before you click the "Create Table..." button.
Step through it in your debugger line by line and document how for you get.
Then recursively repeat and step deeper and deeper into the last statement
before the exception is thrown, until you narrow down the failure at its
source.
A debug build of main/dbaccess may also help ("build debug=true" in
main/dbaccess).
Email us back with your findings.

The long version:
--

Opening the "Create Table in Design View" dialog and attaching GDB and
running "thread apply all bt" doesn't show anything useful, so we go
through the source instead.

The text "Create Table in Design View" must come from somewhere:

[main/dbaccess]$ grep "Create Table in Design View" * -R
source/ui/app/app.src:Text [ en-US ] = "Create Table in Design View..."
;

Looking at that file we see:

String RID_STR_NEW_TABLE
{
Text [ en-US ] = "Create Table in Design View..." ;
};

Now look for RID_STR_NEW_TABLE:

[main/dbaccess]$ grep RID_STR_NEW_TABLE * -R
source/ui/app/app.src:String RID_STR_NEW_TABLE
source/ui/app/app.src:String RID_STR_NEW_TABLE_AUTO
source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE
RID_STR_APP_START + 4
source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE_AUTO
RID_STR_APP_START + 5
source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) );
source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD,
RID_STR_NEW_TABLE_AUTO ) );

Only the source/ui/app/AppDetailView.cxx is useful, as it contains actual
code. This is what it does:

switch ( _eType )
{
case E_TABLE:
rList.push_back( TaskEntry( ".uno:DBNewTable",
RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) );
rList.push_back( TaskEntry( ".uno:DBNewTableAutoPilot",
RID_STR_TABLES_HELP_TEXT_WIZARD, RID_STR_NEW_TABLE_AUTO ) );
rList.push_back( TaskEntry( ".uno:DBNewView",
RID_STR_VIEWS_HELP_TEXT_DESIGN, RID_STR_NEW_VIEW, true ) );
_rData.nTitleId = RID_STR_TABLES_CONTAINER;
break;

which doesn't help much. But it does link it to ".uno:DBNewTable". Where
else is that used?

[main/dbaccess]$ grep "\.uno:DBNewTable" * -R
source/ui/control/toolboxcontroller.cxx:
m_aStates.insert(TCommandState::value_type(::rtl::OUString(
RTL_CONSTASCII_USTRINGPARAM(".uno:DBNewTable"))  ,sal_True));
source/ui/app/AppController.cxx:implDescribeSupportedFeature(
".uno:DBNewTable", ID_NEW_TABLE_DESIGN,   CommandGroup::INSERT
);
source/ui/app/AppController.cxx:implDescribeSupportedFeature(
".uno:DBNewTableAutoPilot",ID_NEW_TABLE_DESIGN_AUTO_PILOT,
source/ui/app/app.src:Command = ".uno:DBNewTable";
source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) );
source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD,
RID_STR_NEW_TABLE_AUTO ) );
uiconfig/dbapp/menubar/menubar.xml:

Here we have a number of matches. The menubar.xml is related to the GUI
layout, we want the code. The app.src we've already looked at. That only
leaves toolboxcontroller.cxx, AppController.cxx and AppDetailView.cxx.
AppDetailView.cxx only uses ".uno:DBNewTable" for what we've already seen,
to add it to rList. toolboxcontroller.cxx also only uses that string in
some initialization code. So through a process of elimination, we're only
left with AppController.cxx.

It contains only 1 matching line:

implDescribeSupportedFeature( ".uno:DBNewTable",
ID_NEW_TABLE_DESIGN,   CommandGroup::INSERT );

We continue on with this ID_NEW_TABLE_DESIGN:

[main/dbaccess]$ grep ID_NEW_TABLE_DESIGN * -R
source/ui/app/AppController.cxx:case ID_NEW_TABLE_DESIGN:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case ID_NEW_TABLE_DESIGN:
source/ui/app/AppController.cxx: case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN:
source/ui/app/AppController.cxx:implDescribeSupportedFeature(
".uno:DBNewTable", ID_NEW_TABLE_DESIGN,   CommandGroup::INSERT
);
source/ui/app/AppController.cxx:implDescribeSupportedFeature(
".uno:DBNewTableAutoPilot",ID_NEW_TABLE_DESIGN_AUTO_PILOT,
source/ui/app/app.src:MID_NEW_TABLE_DESIGN
source/ui/inc/browserids.hxx:#define ID_NEW_TABLE_DESIGN
25
source/ui/inc/browserids.hxx:#define ID_NEW_TABLE_DESIGN_AUTO_PILOT
45
source/ui/inc/toolbox_tmpl.hrc:#define MID_NEW_TABLE_DESIGN \
source/ui/inc/toolbox_tmpl.hrc:

Re: Debugging Base's "Create Table in Design View"

[Damjan Jovanovic]

.so.0
#28 0x7fffea64ec8c in ?? () from
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#29 0x7fffeaf3e197 in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#30 0x7fffeaf3e3f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#31 0x7fffeaf3e49c in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#32 0x7fffebcf0592 in GtkXLib::Yield (this=0x77f77010,
bWait=, bHandleAllCurrentEvents=) at
/AOO/main/vcl/unx/gtk/app/gtkdata.cxx:874
#33 0x72eaa8eb in ImplYield (i_bWait=i_bWait@entry=true,
i_bAllEvents=i_bAllEvents@entry=false) at
/AOO/main/vcl/source/app/svapp.cxx:476
#34 0x72ea794c in Application::Yield
(i_bAllEvents=i_bAllEvents@entry=false) at
/AOO/main/vcl/source/app/svapp.cxx:510
#35 0x72ea7971 in Application::Execute () at
/AOO/main/vcl/source/app/svapp.cxx:453
#36 0x777140ff in desktop::Desktop::Main (this=0x7fffba40) at
/AOO/main/desktop/source/app/app.cxx:2232
#37 0x72eae952 in ImplSVMain () at
/AOO/main/vcl/source/app/svmain.cxx:196
#38 0x72eaea59 in SVMain () at
/AOO/main/vcl/source/app/svmain.cxx:237
#39 0x7774a2db in soffice_main () at
/AOO/main/desktop/source/app/sofficemain.cxx:45
#40 0x00401266 in sal_main () at main.c:31
#41 0x0040124b in main (argc=1, argv=0x7fffbbd8) at main.c:30


On Fri, Nov 17, 2017 at 8:47 PM, Damjan Jovanovic <dam...@apache.org> wrote:

> tl;dr:
> Put a breakpoint on dbaui::DatabaseObjectView::doDispatch or
> /full/path/to/main/dbaccess/source/ui/misc/databaseobjectview.cxx:120
> just before you click the "Create Table..." button.
> Step through it in your debugger line by line and document how for you get.
> Then recursively repeat and step deeper and deeper into the last statement
> before the exception is thrown, until you narrow down the failure at its
> source.
> A debug build of main/dbaccess may also help ("build debug=true" in
> main/dbaccess).
> Email us back with your findings.
>
> The long version:
> --
>
> Opening the "Create Table in Design View" dialog and attaching GDB and
> running "thread apply all bt" doesn't show anything useful, so we go
> through the source instead.
>
> The text "Create Table in Design View" must come from somewhere:
>
> [main/dbaccess]$ grep "Create Table in Design View" * -R
> source/ui/app/app.src:Text [ en-US ] = "Create Table in Design
> View..." ;
>
> Looking at that file we see:
>
> String RID_STR_NEW_TABLE
> {
> Text [ en-US ] = "Create Table in Design View..." ;
> };
>
> Now look for RID_STR_NEW_TABLE:
>
> [main/dbaccess]$ grep RID_STR_NEW_TABLE * -R
> source/ui/app/app.src:String RID_STR_NEW_TABLE
> source/ui/app/app.src:String RID_STR_NEW_TABLE_AUTO
> source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE
> RID_STR_APP_START + 4
> source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE_AUTO
> RID_STR_APP_START + 5
> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
> ".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) );
> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
> ".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD,
> RID_STR_NEW_TABLE_AUTO ) );
>
> Only the source/ui/app/AppDetailView.cxx is useful, as it contains actual
> code. This is what it does:
>
> switch ( _eType )
> {
> case E_TABLE:
> rList.push_back( TaskEntry( ".uno:DBNewTable",
> RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) );
> rList.push_back( TaskEntry( ".uno:DBNewTableAutoPilot",
> RID_STR_TABLES_HELP_TEXT_WIZARD, RID_STR_NEW_TABLE_AUTO ) );
> rList.push_back( TaskEntry( ".uno:DBNewView",
> RID_STR_VIEWS_HELP_TEXT_DESIGN, RID_STR_NEW_VIEW, true ) );
> _rData.nTitleId = RID_STR_TABLES_CONTAINER;
> break;
>
> which doesn't help much. But it does link it to ".uno:DBNewTable". Where
> else is that used?
>
> [main/dbaccess]$ grep "\.uno:DBNewTable" * -R
> source/ui/control/toolboxcontroller.cxx:
> m_aStates.insert(TCommandState::value_type(::rtl::OUString(R
> TL_CONSTASCII_USTRINGPARAM(".uno:DBNewTable"))  ,sal_True));
> source/ui/app/AppController.cxx:implDescribeSupportedFeature(
> ".uno:DBNewTable", ID_NEW_TABLE_DESIGN,   CommandGroup::INSERT
> );
> source/ui/app/AppController.cxx:implDescribeSupportedFeature(
> ".uno:DBNewTableAutoPilot",ID_NEW_TABLE_DESIGN_AUTO_PILOT,
> source/ui/app/app.src:Command = ".uno:DBNewTable";
> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
> &quo

Re: Simpler Windows builds, oowintool, and Cygwin64

[Damjan Jovanovic]

Please test whether the attached patch helps?

Regards
Damjan

On Sat, Nov 11, 2017 at 8:02 PM, Matthias Seidel <matthias.sei...@hamburg.de
> wrote:

> Hi Damjan,
>
> Am 10.11.2017 um 06:27 schrieb Damjan Jovanovic:
> > Hi
> >
> > I've committed a few small small fixes to oowintool, mostly for JDK 8
> > detection and better logging, but I've confirmed that it already works
> > well, and --with-frame-home --with-psdk-home --with-midl-path
> > --with-jdk-home --with-csc-path and --with-cl-home options to ./configure
> > are all unnecessary.
> >
> > As for 64 bit Cygwin I believe the problem with oowintool is that it
> needs
> > to look under the Wow6432node subkey in the registry too, something that
> > should be easy to add. Is anyone available to test 64 bit Cygwin?
>
> I just installed Cygwin64 on Windows 10 and ./configure stops with:
>
> Can't find MS Visual Studio / VC++ at ./oowintool line 236.
> configure: error: oowintool failed to copy CRT
>
> Regards, Matthias
>
> >
> > Damjan
> >
>
>
>
Index: oowintool
===
--- oowintool	(revision 1815058)
+++ oowintool	(working copy)
@@ -217,6 +217,11 @@
 	$ver->{'product_dir'} = $install;
 	return $ver;
 	}
+	$install = reg_get_value ("HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node" . $ver->{'key'});
+	if (defined $install && $install ne '') {
+	$ver->{'product_dir'} = $install;
+	return $ver;
+	}
 }
 die "Can't find MS Visual Studio / VC++";
 }
@@ -232,6 +237,11 @@
 	$ver->{'product_dir'} = $install;
 	return $ver;
 	}
+	$install = reg_get_value("HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node" . $ver->{'key'});
+	if (defined $install && $install ne '') {
+	$ver->{'product_dir'} = $install;
+	return $ver;
+	}
 }
 die "Can't find MS Visual Studio / VC++";
 }

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

Re: Debugging Base's "Create Table in Design View"

[Damjan Jovanovic]

Yesterday, in the email thread entitled "FYI: The OO 4.1.4 Mac problem",
Dave Fisher asked me for help with the problem where the "Create Table in
Design View" does nothing on a Mac release.

Was the problem fixed in the meanwhile? Is there another problem? What
happened? Do you still need my help?

Thank you
Damjan

On Sat, Nov 18, 2017 at 5:47 AM, Patricia Shanahan <p...@acm.org> wrote:

> Is it possible that this is another manifestation of
> https://bz.apache.org/ooo/show_bug.cgi?id=127581
>
> If so, it will not happen in the trunk.
>
>
> On 11/17/2017 10:47 AM, Damjan Jovanovic wrote:
>
>> tl;dr:
>> Put a breakpoint on dbaui::DatabaseObjectView::doDispatch or
>> /full/path/to/main/dbaccess/source/ui/misc/databaseobjectview.cxx:120
>> just
>> before you click the "Create Table..." button.
>> Step through it in your debugger line by line and document how for you
>> get.
>> Then recursively repeat and step deeper and deeper into the last statement
>> before the exception is thrown, until you narrow down the failure at its
>> source.
>> A debug build of main/dbaccess may also help ("build debug=true" in
>> main/dbaccess).
>> Email us back with your findings.
>>
>> The long version:
>> --
>>
>> Opening the "Create Table in Design View" dialog and attaching GDB and
>> running "thread apply all bt" doesn't show anything useful, so we go
>> through the source instead.
>>
>> The text "Create Table in Design View" must come from somewhere:
>>
>> [main/dbaccess]$ grep "Create Table in Design View" * -R
>> source/ui/app/app.src:Text [ en-US ] = "Create Table in Design
>> View..."
>> ;
>>
>> Looking at that file we see:
>>
>> String RID_STR_NEW_TABLE
>> {
>>  Text [ en-US ] = "Create Table in Design View..." ;
>> };
>>
>> Now look for RID_STR_NEW_TABLE:
>>
>> [main/dbaccess]$ grep RID_STR_NEW_TABLE * -R
>> source/ui/app/app.src:String RID_STR_NEW_TABLE
>> source/ui/app/app.src:String RID_STR_NEW_TABLE_AUTO
>> source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE
>> RID_STR_APP_START + 4
>> source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE_AUTO
>> RID_STR_APP_START + 5
>> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
>> ".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE )
>> );
>> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
>> ".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD,
>> RID_STR_NEW_TABLE_AUTO ) );
>>
>> Only the source/ui/app/AppDetailView.cxx is useful, as it contains actual
>> code. This is what it does:
>>
>>  switch ( _eType )
>>  {
>>  case E_TABLE:
>>  rList.push_back( TaskEntry( ".uno:DBNewTable",
>> RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) );
>>  rList.push_back( TaskEntry( ".uno:DBNewTableAutoPilot",
>> RID_STR_TABLES_HELP_TEXT_WIZARD, RID_STR_NEW_TABLE_AUTO ) );
>>  rList.push_back( TaskEntry( ".uno:DBNewView",
>> RID_STR_VIEWS_HELP_TEXT_DESIGN, RID_STR_NEW_VIEW, true ) );
>>  _rData.nTitleId = RID_STR_TABLES_CONTAINER;
>>  break;
>>
>> which doesn't help much. But it does link it to ".uno:DBNewTable". Where
>> else is that used?
>>
>> [main/dbaccess]$ grep "\.uno:DBNewTable" * -R
>> source/ui/control/toolboxcontroller.cxx:
>> m_aStates.insert(TCommandState::value_type(::rtl::OUString(
>> RTL_CONSTASCII_USTRINGPARAM(".uno:DBNewTable"))  ,sal_True));
>> source/ui/app/AppController.cxx:implDescribeSupportedFeature(
>> ".uno:DBNewTable", ID_NEW_TABLE_DESIGN,   CommandGroup::INSERT
>> );
>> source/ui/app/AppController.cxx:implDescribeSupportedFeature(
>> ".uno:DBNewTableAutoPilot",ID_NEW_TABLE_DESIGN_AUTO_PILOT,
>> source/ui/app/app.src:Command = ".uno:DBNewTable";
>> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
>> ".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE )
>> );
>> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
>> ".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD,
>> RID_STR_NEW_TABLE_AUTO ) );
>> uiconfig/dbapp/menubar/menubar.xml:> menu:id=".uno:DBNewTable"/>
>>
>> Here we have a number of mat

Re: Simpler Windows builds, oowintool, and Cygwin64

[Damjan Jovanovic]

Committed now, thank you for your help:

r1815542 | damjan | 2017-11-17 04:05:43 +0200 (Fri, 17 Nov 2017) | 6 lines
Changed paths:
   M /openoffice/trunk/main/oowintool

Allow oowintool to find 32 bit VC++ in Cygwin64.

Patch by: Damjan Jovanovic and Matthias Seidel
Tested by: Matthias Seidel


On Thu, Nov 16, 2017 at 10:02 PM, Matthias Seidel <
matthias.sei...@hamburg.de> wrote:

> Hi Damjan,
>
> Do you want to commit your patch?
>
> Actually, there are still some obstacles for building with Cygwin64, but
> oowintool doesn't seem to break anything.
>
> Regards, Matthias
>
> Am 15.11.2017 um 19:55 schrieb Damjan Jovanovic:
>
> Great work Matthias :-).
>
> Thank you and good luck.
>
> On Wed, Nov 15, 2017 at 7:17 PM, Matthias Seidel <matthias.sei...@hamburg.de
>
> wrote:
>
> I just updated config.guess and config.sub to the latest version.
>
> See: https://www.gnu.org/software/gettext/manual/html_node/
> config_002eguess.html
>
> Regards, Matthias
>
> Am 15.11.2017 um 17:23 schrieb Matthias Seidel:
>
> Hi Damjan,
>
> Next "problem", ./bootstrap can't guess the system:
>
> ---
> entering dmake-4.12
> checking build system type... ./config.guess: unable to guess system type
>
> This script, last modified 2005-07-08, has failed to recognize
> the operating system you are using. It is advised that you
> download the most up to date version of the config scripts from
>
>   http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/
> config/config.guess
> and
>   http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/
>
> config/config.sub
>
> If the version you run (./config.guess) is already up to date, please
> send the following data and any information you think might be
> pertinent to <config-patc...@gnu.org> <config-patc...@gnu.org> 
> <config-patc...@gnu.org> <config-patc...@gnu.org> in order
> to provide the needed
> information to handle your system.
>
> config.guess timestamp = 2005-07-08
>
> uname -m = x86_64
> uname -r = 2.9.0(0.318/5/3)
> uname -s = CYGWIN_NT-10.0
> uname -v = 2017-09-12 10:18
>
> /usr/bin/uname -p = unknown
> /bin/uname -X =
>
> hostinfo   =
> /bin/universe  =
> /usr/bin/arch -k   =
> /bin/arch  = x86_64
> /usr/bin/oslevel   =
> /usr/convex/getsysinfo =
>
> UNAME_MACHINE = x86_64
> UNAME_RELEASE = 2.9.0(0.318/5/3)
> UNAME_SYSTEM  = CYGWIN_NT-10.0
> UNAME_VERSION = 2017-09-12 10:18
> configure: error: cannot guess build type; you must specify one
> ---
>
> I am wondering about the timestamp, our config.guess is from 2009-12-30.
>
> Regards, Matthias
>
>
> Am 14.11.2017 um 03:06 schrieb Damjan Jovanovic:
>
> Please test whether the attached patch helps?
>
> Regards
> Damjan
>
> On Sat, Nov 11, 2017 at 8:02 PM, Matthias Seidel <matthias.sei...@hamburg.de> 
> wrote:
>
>
> Hi Damjan,
>
> Am 10.11.2017 um 06:27 schrieb Damjan Jovanovic:
>
> Hi
>
> I've committed a few small small fixes to oowintool, mostly for JDK 8
> detection and better logging, but I've confirmed that it already works
> well, and --with-frame-home --with-psdk-home --with-midl-path
> --with-jdk-home --with-csc-path and --with-cl-home options to
>
> ./configure
>
> are all unnecessary.
>
> As for 64 bit Cygwin I believe the problem with oowintool is that it
>
> needs
>
> to look under the Wow6432node subkey in the registry too, something that
> should be easy to add. Is anyone available to test 64 bit Cygwin?
>
> I just installed Cygwin64 on Windows 10 and ./configure stops with:
>
> Can't find MS Visual Studio / VC++ at ./oowintool line 236.
> configure: error: oowintool failed to copy CRT
>
> Regards, Matthias
>
>
> Damjan
>
>
>  -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
>
>
>

Re: FYI: The OO 4.1.4 Mac problem

[Damjan Jovanovic]

Hi

I am familiar with the database driver code in main/connectivity, but much
less familiar with the Base code main/dbaccess where the problem is.

On an unrelated past bug in my code in a main/connectivity driver, I did
however briefly encounter that same problem where clicking "Create table"
does nothing. Debugging it proved very difficult. Far too commonly, Base
catches and silently swallows exceptions via the likes of:

catch (Exception&) {}

which explains why no error is reported to the user, and means that even if
you put a breakpoint on such a line, you can't see anything about the
exception as there is no variable it's assigned to: not the exception's
particular subtype, not its message, and in the abomination that is C++
generally, never the most useful part: its stack trace.

I then tried doing "catch throw" in gdb to try examine the exception when
it's thrown instead of caught, however that took me on a wild goose chase,
as multiple harmless exceptions get thrown during the course of that dialog
opening.

Eventually I gave up and fixed the bug in my main/connectivity driver. I
can't remember which bug; probably that null strings were being returned
from Java to UNO, and UNO strings can't ever be null (even in AOO's C++,
the infamous OUString is always empty, never null).

Later I can try to find and send you the beginning of that path through the
Base code that's involved in opening the "Create table" dialog, so you have
somewhere to start from. Since I don't have a Mac or access to one, I can't
help debug this directly. But feel free to ask me any questions.

Regards
Damjan


On Thu, Nov 16, 2017 at 10:12 PM, Dave Fisher  wrote:

> Hi Damjan,
>
> Do you have any tips or pointers regarding the Base issue we are having
> with Builds on MacOS?
>
> I’m seeing your comments on https://bz.apache.org/ooo/
> show_bug.cgi?id=126655 and can’t help but wonder if the code is fragile
> here. If nothing else some help tracing the code could help.
>
> Does the Redland configuration and the update in trunk help us here?
>
> Regards,
> Dave
>
> > On Nov 16, 2017, at 10:40 AM, Jim Jagielski  wrote:
> >
> > OK, I am pretty much almost out of ideas. I've created a VM which is
> > almost an exact match for what I could determine was the build
> > environ for 4.1.2. Attached is a patch file that shows the diffs between
> > the config.out for 4.1.2 and my build of 4.1.2. My build doesn't suffer
> > from the corrupted diagram but it DOES still suffer from the
> table/Database
> > regression. AFAIK, the official 4.1.2 build suffers from neither.
> >
> > So what is causing this weird behavior I simply don't know... As
> > one can see, there's nothing, at least as reported by config.log, which
> is
> > different and this is straight from
> >
> >   https://svn.apache.org/repos/asf/openoffice/tags/AOO412
> >
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

The new SDBC-JDBC bridge in Java

[Damjan Jovanovic]

Hi

As of revision 1814552, I've rewritten our formerly C++ based SDBC-JDBC
bridge driver in Java. The SDBC-JDBC bridge is there to allows AOO to
access databases through Java's JDBC drivers.

This port originally aimed at fixing serious issues I discovered in the old
C++ implementation, where there is apparently memory corruption on method
IDs that causes methods to be called on wrong Java objects. In the process
of porting I've also discovered and fixed many other problems. For example:
* The C++ code was calling Java code through the Java Invocation API, so it
was using strings to look up method names. This defeats type checking, and
in some cases was looking for methods with typos in their names or that
don't even exist. My current bridge only uses Java to Java calls that are
always strongly type checked and correct.
* Conversions between bytes and chars were broken: n bytes were being
copied verbatim into memory for char arrays n chars long in Java (Java's
char is 16 bits) so the second half of the array was untouched and the
first half had wrong chars, and non-existent classes like
java.io.CharArrayInputStream were being created. Real classes that do
exist, and proper character set conversions, are now used.
* Chained Java exceptions are now converted to chained UNO exceptions via
the commonly used and clearer getCause() chaining dimension, not the
java.sql.SQLException's getNextException() chaining dimension.

The new driver is, as seen externally, completely interchangeable with the
old one. Service names are identical, implementation names are identical,
supported interfaces are identical, the configuration schema is identical,
initialization arguments are identical, even logging channels and messages
logged are identical - client code using the old driver should be able to
use the new one transparently, and not only should everything that worked
before still work now, but some things that didn't work before might also
begin to work now.

Having said that, the driver does push UNO to its limits, and might reveal
other bugs in UNO bridging, Base, other AOO components, and the C++ runtime
environment. I already discovered AOO sometimes crashes on FreeBSD due to
issues in converting exceptions from Java to C++ (missing exception RTTI
causes a segfault), but such bugs should be fixed in main/bridges and/or
the Clang project.

There are still some cleanups I want to do, like making sure nulls strings
are never passed or returned to UNO, cleaning up exception handling, doing
a comparison of every C++ method with every Java method to see if I missed
anything, and so on, which is why the old C++ code has been left in the
tree for now even though it's no longer built. In the meanwhile, please
feel free to start testing :).

Oh and my original memory-corruption-induced IllegalClassChangeError is
gone - my PostgreSQL SDBC driver already works better with the new
SDBC-JDBC bridge :).

Damjan

Re: Report of 4.1.4 table problem on BSD

[Damjan Jovanovic]

I can reproduce that database wizard problem in trunk :(, although "Create
Table in Design View" works (at least for my PostgreSQL driver). This is on
PC-BSD 10.3.

Any idea what caused it?

Damjan

On Thu, Nov 9, 2017 at 7:43 PM, Rory O'Farrell  wrote:

> A report on Forum of a 4.1.4 table problem on BSD; details at
> https://forum.openoffice.org/en/forum/viewtopic.php?f=6=91135
>
> --
> Rory O'Farrell 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Report of 4.1.4 table problem on BSD

[Damjan Jovanovic]

I was wrong, the issue on the forum is not reproducible on either the
latest trunk of 1814757, or revision 1774839 from late 2016. The sample
tables in the table wizard are supposed to be there and always were.

Now let's check 4.1.4.

On Thu, Nov 9, 2017 at 7:57 PM, Damjan Jovanovic <dam...@apache.org> wrote:

> I can reproduce that database wizard problem in trunk :(, although "Create
> Table in Design View" works (at least for my PostgreSQL driver). This is on
> PC-BSD 10.3.
>
> Any idea what caused it?
>
> Damjan
>
> On Thu, Nov 9, 2017 at 7:43 PM, Rory O'Farrell <ofarr...@iol.ie> wrote:
>
>> A report on Forum of a 4.1.4 table problem on BSD; details at
>> https://forum.openoffice.org/en/forum/viewtopic.php?f=6=91135
>>
>> --
>> Rory O'Farrell <ofarr...@iol.ie>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>

Simpler Windows builds, oowintool, and Cygwin64

[Damjan Jovanovic]

Hi

I've committed a few small small fixes to oowintool, mostly for JDK 8
detection and better logging, but I've confirmed that it already works
well, and --with-frame-home --with-psdk-home --with-midl-path
--with-jdk-home --with-csc-path and --with-cl-home options to ./configure
are all unnecessary.

As for 64 bit Cygwin I believe the problem with oowintool is that it needs
to look under the Wow6432node subkey in the registry too, something that
should be easy to add. Is anyone available to test 64 bit Cygwin?

Damjan

Re: The new SDBC-JDBC bridge in Java

[Damjan Jovanovic]

Hi Matthias

Was it a clean rebuild?

Can you post the full output of "build --from offapi"?

Maybe it needs DOS line endings in ParameterSubstitution.idl?

Damjan

On Wed, Nov 8, 2017 at 2:52 PM, Matthias Seidel <matthias.sei...@hamburg.de>
wrote:

> Hi Damjan,
>
> On my release machine (Win 10) it stops with:
>
> ---
> make: *** [C:/Source/aoo/main/solenv/gbuild/UnoApiTarget.mk:165:
> /cygdrive/c/Source/aoo/main/solver/420/wntmsci12.pro/
> workdir/UnoApiPartTarget/offapi/com/sun/star/sdb/ParameterSubstitution.urd
> ]
> Error 1
> make: *** Waiting for unfinished jobs
> dmake:  Error code 2, while making 'all'
>
> 1 module(s):
> offapi
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /cygdrive/c/Source/aoo/main/offapi/prj
>
> When you have fixed the errors in that module you can resume the build
> by running:
>
> build --from offapi
> ---
>
> I will try to force a build on our buildbot to cross check.
>
> Regards, Matthias
>
>
> Am 08.11.2017 um 05:34 schrieb Damjan Jovanovic:
> > Hi
> >
> > As of revision 1814552, I've rewritten our formerly C++ based SDBC-JDBC
> > bridge driver in Java. The SDBC-JDBC bridge is there to allows AOO to
> > access databases through Java's JDBC drivers.
> >
> > This port originally aimed at fixing serious issues I discovered in the
> old
> > C++ implementation, where there is apparently memory corruption on method
> > IDs that causes methods to be called on wrong Java objects. In the
> process
> > of porting I've also discovered and fixed many other problems. For
> example:
> > * The C++ code was calling Java code through the Java Invocation API, so
> it
> > was using strings to look up method names. This defeats type checking,
> and
> > in some cases was looking for methods with typos in their names or that
> > don't even exist. My current bridge only uses Java to Java calls that are
> > always strongly type checked and correct.
> > * Conversions between bytes and chars were broken: n bytes were being
> > copied verbatim into memory for char arrays n chars long in Java (Java's
> > char is 16 bits) so the second half of the array was untouched and the
> > first half had wrong chars, and non-existent classes like
> > java.io.CharArrayInputStream were being created. Real classes that do
> > exist, and proper character set conversions, are now used.
> > * Chained Java exceptions are now converted to chained UNO exceptions via
> > the commonly used and clearer getCause() chaining dimension, not the
> > java.sql.SQLException's getNextException() chaining dimension.
> >
> > The new driver is, as seen externally, completely interchangeable with
> the
> > old one. Service names are identical, implementation names are identical,
> > supported interfaces are identical, the configuration schema is
> identical,
> > initialization arguments are identical, even logging channels and
> messages
> > logged are identical - client code using the old driver should be able to
> > use the new one transparently, and not only should everything that worked
> > before still work now, but some things that didn't work before might also
> > begin to work now.
> >
> > Having said that, the driver does push UNO to its limits, and might
> reveal
> > other bugs in UNO bridging, Base, other AOO components, and the C++
> runtime
> > environment. I already discovered AOO sometimes crashes on FreeBSD due to
> > issues in converting exceptions from Java to C++ (missing exception RTTI
> > causes a segfault), but such bugs should be fixed in main/bridges and/or
> > the Clang project.
> >
> > There are still some cleanups I want to do, like making sure nulls
> strings
> > are never passed or returned to UNO, cleaning up exception handling,
> doing
> > a comparison of every C++ method with every Java method to see if I
> missed
> > anything, and so on, which is why the old C++ code has been left in the
> > tree for now even though it's no longer built. In the meanwhile, please
> > feel free to start testing :).
> >
> > Oh and my original memory-corruption-induced IllegalClassChangeError is
> > gone - my PostgreSQL SDBC driver already works better with the new
> > SDBC-JDBC bridge :).
> >
> > Damjan
> >
>
>
>

Re: The new SDBC-JDBC bridge in Java

[Damjan Jovanovic]

Apparently I left out that IDL file in my last commit. Sorry. The latest
SVN should build now.

On Wed, Nov 8, 2017 at 6:41 PM, Damjan Jovanovic <dam...@apache.org> wrote:

> Thank you. There is nothing in that log but "Error 1".
>
> It builds perfectly on FreeBSD. I'll try a Windows build too but it could
> take a while.
>
> The file has *nix style line endings like every other IDL file.
>
> Any other ideas?
>
> Regards
> Damjan
>
>
> On Wed, Nov 8, 2017 at 5:50 PM, Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
>
>> Hi Damjan,
>>
>> I was able to force the Windows buildbot and this is the detailed error
>> log:
>>
>> https://ci.apache.org/projects/openoffice/buildlogs/win/
>> main/offapi/wntmsci12.pro/misc/logs/prj.txt
>>
>> Regards, Matthias
>>
>>
>> Am 08.11.2017 um 14:36 schrieb Damjan Jovanovic:
>> > Hi Matthias
>> >
>> > Was it a clean rebuild?
>> >
>> > Can you post the full output of "build --from offapi"?
>> >
>> > Maybe it needs DOS line endings in ParameterSubstitution.idl?
>> >
>> > Damjan
>> >
>> > On Wed, Nov 8, 2017 at 2:52 PM, Matthias Seidel <
>> matthias.sei...@hamburg.de>
>> > wrote:
>> >
>> >> Hi Damjan,
>> >>
>> >> On my release machine (Win 10) it stops with:
>> >>
>> >> ---
>> >> make: *** [C:/Source/aoo/main/solenv/gbuild/UnoApiTarget.mk:165:
>> >> /cygdrive/c/Source/aoo/main/solver/420/wntmsci12.pro/
>> >> workdir/UnoApiPartTarget/offapi/com/sun/star/sdb/ParameterSu
>> bstitution.urd
>> >> ]
>> >> Error 1
>> >> make: *** Waiting for unfinished jobs
>> >> dmake:  Error code 2, while making 'all'
>> >>
>> >> 1 module(s):
>> >>     offapi
>> >> need(s) to be rebuilt
>> >>
>> >> Reason(s):
>> >>
>> >> ERROR: error 65280 occurred while making
>> >> /cygdrive/c/Source/aoo/main/offapi/prj
>> >>
>> >> When you have fixed the errors in that module you can resume the build
>> >> by running:
>> >>
>> >> build --from offapi
>> >> ---
>> >>
>> >> I will try to force a build on our buildbot to cross check.
>> >>
>> >> Regards, Matthias
>> >>
>> >>
>> >> Am 08.11.2017 um 05:34 schrieb Damjan Jovanovic:
>> >>> Hi
>> >>>
>> >>> As of revision 1814552, I've rewritten our formerly C++ based
>> SDBC-JDBC
>> >>> bridge driver in Java. The SDBC-JDBC bridge is there to allows AOO to
>> >>> access databases through Java's JDBC drivers.
>> >>>
>> >>> This port originally aimed at fixing serious issues I discovered in
>> the
>> >> old
>> >>> C++ implementation, where there is apparently memory corruption on
>> method
>> >>> IDs that causes methods to be called on wrong Java objects. In the
>> >> process
>> >>> of porting I've also discovered and fixed many other problems. For
>> >> example:
>> >>> * The C++ code was calling Java code through the Java Invocation API,
>> so
>> >> it
>> >>> was using strings to look up method names. This defeats type checking,
>> >> and
>> >>> in some cases was looking for methods with typos in their names or
>> that
>> >>> don't even exist. My current bridge only uses Java to Java calls that
>> are
>> >>> always strongly type checked and correct.
>> >>> * Conversions between bytes and chars were broken: n bytes were being
>> >>> copied verbatim into memory for char arrays n chars long in Java
>> (Java's
>> >>> char is 16 bits) so the second half of the array was untouched and the
>> >>> first half had wrong chars, and non-existent classes like
>> >>> java.io.CharArrayInputStream were being created. Real classes that do
>> >>> exist, and proper character set conversions, are now used.
>> >>> * Chained Java exceptions are now converted to chained UNO exceptions
>> via
>> >>> the commonly used and clearer getCause() chaining dimension, not the
>> >>> java.sql.SQLException's getNextException() chaining dimension.
>> >>>
>> >>> The new driver is, as seen externally, completely inter

Re: A more sane way to build - SCons, deCygwination and other hopes

[Damjan Jovanovic]

On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski  wrote:

> Playing devils advocate, does it make sense to introduce
> Yet Another Build System at this stage?
>
>
I anticipated this question.

Firstly, we don't only have dmake and gbuild as our build systems. We also
use Ant, meta-build tools like build.pl and co, Microsoft's nmake for
main/icu on Windows, and probably more. The existing number of tools
doesn't negatively affect development, so why should 1 more?

Secondly SCons can replace ./configure, so in all all-SCons world we would
eliminate 3 tools, not just 2.

As for "sense . .. at this stage", we've hit several walls with gbuild at
this stage:
* It can't version libraries in the form of reg3.dll vs reg.so linking to
reg.so.3 on *nix. Most of gbuild was written with the assumption libraries
on *nix always end with .so. Even when we dangerously weaken those
assumptions, and badly hack it, it doesn't deliver the link...
* It already broke certain mixtures of build settings, eg. I think you
can't both debug build and use precompiled headers on Windows, CFLAGS gets
lost somewhere...
* Nobody knows gbuild. The syntax is atrocious. It uses obscure features of
GNU make. We can't debug it. It takes days of work to investigate/fix any
problem with it, work that could be better spent on a this vast project
with few development resources.


> Also, there are a few projects that I know of that
> use SCons. In general, one of the most popular common
> threads related to them are "Why the hell are you using SCons?" :)
>
>
I'd like to see those discussions.

SCons as opposed to what?

Damjan

Re: 4.2.0: Baseline CentOS6 as reference build platform

[Damjan Jovanovic]

Why don't we post that on our www.openoffice.org blog?

On Mon, Dec 4, 2017 at 3:25 PM, Jim Jagielski  wrote:

> http://jimjag.com/imo/index.php?/archives/272-The-Path-to-
> Apache-OpenOffice-4.2.0.html  php?/archives/272-The-Path-to-Apache-OpenOffice-4.2.0.html>
>
> > On Dec 4, 2017, at 7:35 AM, Jim Jagielski  wrote:
> >
> > Sounds like a good topic for a blog post... Our current
> > discussions regarding 4.2.0 and Linux.
> >
>
>

Re: a more sane way to override optimization flags in gbuild

[Damjan Jovanovic]

On Sun, Dec 3, 2017 at 2:25 AM, Jim Jagielski  wrote:

>
> > On Dec 2, 2017, at 5:56 PM, Andrea Pescetti  wrote:
> >
> > On 30/11/2017 Jim Jagielski wrote:
> >> I think for 4.2.x and later, we have deprecated CentOS5 as a supported
> >> build system... I ran into a LOT of issues.
> >
> > Such as, for example?
>
> for starters:
>   o zip 3.0.
>   o GIO
>
>
If you *really* need GIO, try adding --disable-gio --enable-gnome-vfs to
./configure.

The check for ZIP version 3.0 was added in revision 1755455, the gbuild
branch merge into trunk. Within that branch it was added in this commit:

r1409544 | arist | 2012-11-15 01:22:40 +0200 (Thu, 15 Nov 2012) | 9 lines
Changed paths:
   M /incubator/ooo/branches/gbuild/main/configure.in

gnumake4_047_ce56f9735b9c.patch
# HG changeset patch
# User Michael Stahl 
# Date 1301690824 0
# Node ID ce56f9735b9cd04f4e2724754fe7c11d9cec1ca9
# Parent  e37d17b6d8d93e87a4886268f338a2d4ea2a6304
gnumake4: configure.in: require Info-ZIP 3.0


apparently around the time they were adding support for Java in gbuild.
Maybe gbuild uses a ZIP 3 feature for JAR files? This is all we do with zip
in gbuild:

$(gb_Zip_ZIPCOMMAND) -rX -FS $(call gb_Zip_get_target,$*) $(FILES) )

are -rX or -FS new?

But can we please use another thread for such issues?

Damjan

Re: A more sane way to build - SCons, deCygwination and other hopes

[Damjan Jovanovic]

Globally, removing SCons should only entail:
rm -rf site_scons SConstruct */SConscript

Modules that get ported from gbuild to SCons would also require replacement
of their main//prj/makefile.mk with a gbuild copy of that file
(which is the same in all gbuild modules), and if their gbuild makefiles
were deleted, they need to be restored.

Modules that get ported from dmake to SCons have extensive precompiled
header changes and symbol visibility changes in source code
(SAL_DLLPUBLIC_EXPORT), so "svn revert" is probably the only option for
them.

Be more optimistic though. SCons works better than expected. And I've even
made a preliminary parser/converter for gbuild's module makefiles, that can
convert them into SCons build files, so a fast accurate automated
conversion might be possible , as least for some modules.

On Thu, Dec 7, 2017 at 5:32 AM, Patricia Shanahan <p...@acm.org> wrote:

> If it turns out to only make things even more complicated, adding yet
> another build tool, how hard would it be to remove it from trunk?
>
> On 12/6/2017 6:10 PM, Damjan Jovanovic wrote:
> ...
>
>> Should we make a separate branch for SCons or develop in trunk? It doesn't
>> alter any existing files so it shouldn't interfere with our existing
>> build.
>>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: A more sane way to build - SCons, deCygwination and other hopes

[Damjan Jovanovic]

On Sat, Dec 2, 2017 at 10:42 AM, Peter Kovacs <pe...@apache.org> wrote:

> sounds great from what you write. Lets try SCons build system.
> Where can I find your changes so I can help? Have you checked them into
> trunk?
>
>
Please find a patch with my current SCons changes attached.

Currently only main/fileaccess builds, on Windows and FreeBSD, and doesn't
even build completely as I haven't done the "ComponentTarget" yet. You run
"scons" in main/ or "scons -u" in main/fileaccess. AOO has to already be
built.



> I have some expreience with python, which will come in handy.
>
>
That's great to hear. Please let me know what you think about the
structure, classes, should we use globals and soenv and SCon's Environment,
etc. There is no easier time to make changes than at the beginning.

Should we make a separate branch for SCons or develop in trunk? It doesn't
alter any existing files so it shouldn't interfere with our existing build.


> Meanwhile I read Scons Documentation.
>
> Am Samstag, den 02.12.2017, 10:05 +0200 schrieb Damjan Jovanovic:
> > Hi
> >
> > After days of failing to add a few new simple features to gbuild,
> > I've now
> > reached my limits, and have begun experimenting with the SCons build
> > system
> > instead.
> >
> > It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk
> > and
> > platform/freebsd.mk to SCons, as well as a module's local gbuild
> > files, I
> > can now compile files and (badly) link them into libraries, and clean
> > the
> > build.
> >
> > SCons is an advanced next-generation build system like gbuild, with
> > high
> > level declarative syntax in Python, support for multiple modules that
> > build
> > in parallel, header dependencies, file change detection through MD5
> > sums of
> > contents instead of timestamps so rebuilds are faster, etc. It builds
> > C,
> > C++, Objective C, Java, Fortran, D, the sorely necessary Flex and
> > Yacc that
> > gbuild doesn't support. It supports tons of platforms and compilers,
> > including OS/2. It's maintainable and usable, can print debugging
> > info such
> > as dependency trees, and is generally pleasant to work with. We've
> > discussed it before on this list, but I never got to trying it until
> > now.
> >
> > Virtually everything gbuild does, is already done by SCons, and often
> > done
> > much better. The syntax for SCons files is similar/related to
> > gbuild's
> > syntax, so an automated conversion from gbuild to SCons might even be
> > possible.
> >
> > So far, I have defines, includes and C[XX]FLAGS working. I've
> > structured it
> > a bit better, with platform-specific files in classes that only
> > provide
> > variables to slot in higher up, instead of one giant set of globally
> > mutable global variables like in gbuild. Linking still needs a bit of
> > work.
> > Windows is next on the list, as Cygwin will be the ultimate test of
> > whether
> > we can use it.
> >
> > I am very hopeful. SCons has a long history and is used by other
> > projects,
> > while only OO.o derivatives use gbuild. It's well documented. It
> > supports
> > features we need which gbuild doesn't, like library version names and
> > flex/yacc. It's supposed to work on Windows, both inside and outside
> > of
> > Cygwin and could help us build without Cygwin some day. It supports
> > many
> > versions of Visual Studio and could help us in upgrading to a new
> > one. We
> > will need to add custom builders to SCons for our custom file formats
> > like
> > IDL, but it's just Python, not my favorite language but infinitely
> > better
> > than GNU make.
> >
> > It would help if someone could review my changes, as I am not very
> > familiar
> > with Python and there might be better ways to write some of the code.
> > I'll
> > post a patch for review after some further development.
> >
> > Thank you
> > Damjan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
Index: SConstruct
===
--- SConstruct  (nonexistent)
+++ SConstruct  (working copy)
@@ -0,0 +1 @@
+SConscript('fileaccess/SConscript', variant_dir='fileaccess/build', 
duplicate=0)
Index: site_scons/aooplatform.py
===
--- site_scons/aooplatform.py   (nonexistent)
++

Re: A more sane way to build - SCons, deCygwination and other hopes

[Damjan Jovanovic]

On Sunday, December 3, 2017, Don Lewis <truck...@apache.org> wrote:

> On  2 Dec, Damjan Jovanovic wrote:
> > On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski <j...@jagunet.com> wrote:
> >
> >> Playing devils advocate, does it make sense to introduce
> >> Yet Another Build System at this stage?
> >>
> >>
> > I anticipated this question.
> >
> > Firstly, we don't only have dmake and gbuild as our build systems. We
> also
> > use Ant, meta-build tools like build.pl and co, Microsoft's nmake for
> > main/icu on Windows, and probably more. The existing number of tools
> > doesn't negatively affect development, so why should 1 more?
> >
> > Secondly SCons can replace ./configure, so in all all-SCons world we
> would
> > eliminate 3 tools, not just 2.
> >
> > As for "sense . .. at this stage", we've hit several walls with gbuild at
> > this stage:
> > * It can't version libraries in the form of reg3.dll vs reg.so linking to
> > reg.so.3 on *nix. Most of gbuild was written with the assumption
> libraries
> > on *nix always end with .so. Even when we dangerously weaken those
> > assumptions, and badly hack it, it doesn't deliver the link...
>
> Other than for the benefit of extensions, I don't see much point in
> versioning the libraries because they are otherwise private.  If add
> versioning so that it is more obvious that an old extension won't work
> with a new version of AOO, are we disiplined enough to do the
> appropriate version bumps?
>
> > * It already broke certain mixtures of build settings, eg. I think you
> > can't both debug build and use precompiled headers on Windows, CFLAGS
> gets
> > lost somewhere...
>
> That should be fixable, but ...
>
> > * Nobody knows gbuild. The syntax is atrocious. It uses obscure features
> of
> > GNU make. We can't debug it. It takes days of work to investigate/fix any
> > problem with it, work that could be better spent on a this vast project
> > with few development resources.
>
> Agreed 1000% here.
>
> If you are doing a build with bundled python, how do you bootstrap?  If
> you are on Windows and don't have python, how do you run the SCons
> equivalent of configure and then use SCons to build python?
>
>
I am currently doing it by installing Python natively in Windows,
installing SCons there through pip, and then calling that scons.bat from
Cygwin.

And, beyond my wildest expectations, SCons in this setup successfully
compiled and linked a module, both inside Cygwin AND OUTSIDE IT!!! :) :)


> And a more recent question near and dear to my heart, how easy is it to
> do per-target optimization flag overrides?
>
>
C[XX]FLAGS are specified to SCons like all other settings, as arrays of
strings. You can specify common settings in the environment object and can
add to those or replace them on individual SharedObjects.


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

Damjan

ORbit no longer a build dependency

[Damjan Jovanovic]

Hi

You no longer need ORbit to build the latest trunk on *nix. It was only
ever really used for a version check, which was last needed in ORBit
version < 2.8 released in 2003, and I've removed it in SVN revision 1812807.

Damjan

Re: Upstreaming FreeBSD ports patches before 4.2.0?

[Damjan Jovanovic]

Great, thank you.

No idea. Either Sun/Oracle never got around to implementing it, or they
planned on scrapping it.

On Sat, Apr 28, 2018 at 4:51 AM Don Lewis <truck...@apache.org> wrote:

> I just committed a fix for this in r1830406.
>
> Without this I get build failures due to crashes in the unit tests if
> --enable-debug is specified.  With this change I am able to get a
> working build with both the system alloc and the internal alloc.
>
> I was unaware that this was not getting used on the gbuild side of
> things.  Why not?  It seems like a useful debug feature.
>
> On 15 Apr, Damjan Jovanovic wrote:
> > Alright thank you.
> >
> > Would it be better to just scrap cpprt, like gbuild modules already do?
> >
> > On Sat, Apr 14, 2018 at 4:59 PM, Don Lewis <truck...@apache.org> wrote:
> >
> >> On 14 Apr, Damjan Jovanovic wrote:
> >> > Hi
> >> >
> >> > Can we please upstream the patches from FreeBSD ports, before the
> 4.2.0
> >> > release?
> >> >
> >> > That idlc memory alignment SIGBUS crash from
> >> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216206 is Clang
> >> specific,
> >> > not FreeBSD specific, and could happen on other operating systems.
> >>
> >> That one is a bit complicated to upstream.  In the FreeBSD port I only
> >> apply the patch conditionally when building with recent clang on amd64.
> >> I could be harmful in terms of memory consumption on 32-bit machines.
> >> The changes in the patch would need to be #ifdefed in order to import
> >> it.
> >>
> >> Also the changes for the internal allocator are lightly tested at best.
> >>
> >> https://svnweb.freebsd.org/ports/head/editors/openoffice-
> >> devel/files/extra-patch-align16?revision=432895=markup
> >>
> >>
> >> -
> >> 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: Problem using OpenOffice Base

[Damjan Jovanovic]

Hi Anuj

The OpenOffice database driver for CSV files is read-only. Data cannot be
edited or designed. There are definitely no keys or indexes, JOINs are
performed with table scans.

What you can do is create a separate database in Base and make tables in
it, then copy data from the CSV files into those tables (open CSV in Calc,
select and copy the cells with the data, then paste onto the table in
Base), and then design and edit that database in Base. I admit, it is
something we could really improve.

This is also not the right place for support questions, please use the
users mailing list or the forum.

Regards
Damjan


On Sun, Jun 17, 2018 at 9:14 PM Anuj Verma 
wrote:

> Dear sir,
> I am required to use a database software package in the manner written
> below. In my institution, I use *Microsoft Access* on *WIndows 8/8.1/10*.
> At home, I do not have the package and am using *OpenOffice* [screenshot
> of version attached] with Windows 10 and a Java package downloaded using
> the instructions from your website. I am required to carry out the steps
> below (in the same order).
>
> 1. Import existing CSV files into a database [examples attached:
> *teachers*, *cars*, *students*]: I normally click on the *Insert tab* in 
> *Access
> *and select *Import from text*. Then my file is imported as a table in a
> new database.
> 2. Edit field names and datatypes: I use the *Design view* in *Access*. I
> need to assign a primary key and change the datatypes of the fields.
> 3. Edit data: I just type data into a new row at the bottom of the *Table
> View*.
> 4. Create a form and enter data.
> 5. Create relations: I create one-to-many relations using a Primary key.
> 6. Generate reports.
>
> I am new to *OpenOffice *and am unable to do anything beyond creating a
> blank base file and importing the CSVs into it. [Refer *Window Screenshot*]
> Once I double-click on any of the tables and they open in a separate
> window, I think I should be able to edit them. However, when I try to
> double-click any cell, single-click and press *F2 *or single-click and
> press *Delete*, nothing at all happens.
>
> I tried to enter the design view by right-clicking on the table and
> selecting Edit. I do see something similar to the Design View of Access,
> but again, I cannot edit anything.
>
> As I am unable to carry out tasks 1, 2 and 3, I cannot proceed further
> with my assignments. Please help me out.
>
>
> Regards,
> Anuj Verma
>
>
>
> I request you not to use any of the files for any purpose other than
> solving my query as I am not the original author and am only licensed to
> use them. The CSV files are provided with a textbook recommended for the
> Cambridge IGCSE ICT syllabus.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: gstreamer status for 4.2.0-dev?

[Damjan Jovanovic]

As I explained in a previous mail, Windows uses DirectShow and Mac uses
QuickTime or MacAVF.

Linux's equivalent of DirectShow is gstreamer. It also builds pipelines of
filters, has codecs, supports embedding into windows, etc.

On Mon, May 28, 2018 at 7:19 PM Kay Schenk  wrote:

> On 05/28/2018 12:05 AM, Peter kovacs wrote:
> > Imho the gstreamer libs are still the method of choice for doing
> multimedia.
>
> This is ONLY for Linux. So, how is multimedia "integrated" in AOO for
> Mac and Windows? Can someone point us to the applicable code areas for
> this?
>
> I have a feeling gstreamer was integrated long ago when no other
> multi-media standard/app for Linux existed. Now it seems VLC seems to
> the standard for the most part. (This is a dated web page but I think
> it's still a good reference:
> http://www.yolinux.com/TUTORIALS/LinuxTutorialMimeTypesAndApplications.html
> ).
> Basically, we are supplying gstreamer as a multimedia app to Linux when
> maybe this isn't really needed.
>
> >
> > The current state is that trunk can utilize the gstreamer API 1.0.0
> >
> > We have the issue not resolved the issue to provide gstreamer for
> different Distributions. (Main issue: centos6 is to old to support the new
> gstreamer 1.0.0 API)
> > We have 2 suggestions to solve the issue:
> > 1) implement 0.1.0 and 1.0.0 API.
> > 2) move the implementation into an optional extention.
> >
> > Both solutions have currently not followed up.
> >
> > All the best
> > Peter
> >
> > Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk :
> >> On 05/23/2018 05:35 AM, Jim Jagielski wrote:
> >>> Subj line sez it all... where are we? There was a proposal to make it
> >> a run-time dependency but afaict there hasn't been any effort yet it
> >> doing that.
> >>> I know we have a handful of other things TODO re: 4.2.0 but this
> >> seems to be an inflection point for the Linux builds and so I really
> >> think we need to resolve this if we have any intent in getting a 4.2.0
> >> beta out in a reasonable time frame.
> >>
> >> What would happen if we simply stopped including the --with-gstreamer
> >> option in the build? Mac and Windows builds don't use it, and it only
> >> applies to Linux.
> >>
> >> I haven't investigated the code much to see how the gstreamer libraries
> >> are used. The Linux distros now mostly use Freedesktop lower level
> >> interfaces except I don't know what Unity uses. Is building with
> >> gstreamer still needed/compliant with this? In short, how are video
> >> applications determined in Linux now? Do we need a different approach
> >> for integration of video objects in Linux?
> >>
> >> If anyone knows the history of this, it would be very helpful to this
> >> discussion.
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
> --
> --
> MzK
>
> "Less is MORE."
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: gstreamer status for 4.2.0-dev?

[Damjan Jovanovic]

3. Build on a newer CentOS or other distro.
4. Link to 1.0.0 using run-time dynamic linking, using that patch I made,
and only require the gstreamer-1.0.0 tarball at compile time to find the
headers.

Damjan

On Mon, May 28, 2018 at 9:06 AM Peter kovacs  wrote:

> Imho the gstreamer libs are still the method of choice for doing
> multimedia.
>
> The current state is that trunk can utilize the gstreamer API 1.0.0
>
> We have the issue not resolved the issue to provide gstreamer for
> different Distributions. (Main issue: centos6 is to old to support the new
> gstreamer 1.0.0 API)
> We have 2 suggestions to solve the issue:
> 1) implement 0.1.0 and 1.0.0 API.
> 2) move the implementation into an optional extention.
>
> Both solutions have currently not followed up.
>
> All the best
> Peter
>
> Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk :
> >On 05/23/2018 05:35 AM, Jim Jagielski wrote:
> >> Subj line sez it all... where are we? There was a proposal to make it
> >a run-time dependency but afaict there hasn't been any effort yet it
> >doing that.
> >>
> >> I know we have a handful of other things TODO re: 4.2.0 but this
> >seems to be an inflection point for the Linux builds and so I really
> >think we need to resolve this if we have any intent in getting a 4.2.0
> >beta out in a reasonable time frame.
> >
> >What would happen if we simply stopped including the --with-gstreamer
> >option in the build? Mac and Windows builds don't use it, and it only
> >applies to Linux.
> >
> >I haven't investigated the code much to see how the gstreamer libraries
> >are used. The Linux distros now mostly use Freedesktop lower level
> >interfaces except I don't know what Unity uses. Is building with
> >gstreamer still needed/compliant with this? In short, how are video
> >applications determined in Linux now? Do we need a different approach
> >for integration of video objects in Linux?
> >
> >If anyone knows the history of this, it would be very helpful to this
> >discussion.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Damjan Jovanovic]

In main/avmedia/source/inc/mediamisc.hxx, the media player is chosen with
the following code. Note how GStreamer is only used on non-Windows non-Mac
platforms.

#ifdef WNT

#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_DirectX"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False

#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1  ""
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_False

#else
#ifdef QUARTZ

#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_QuickTime"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False

#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
"com.sun.star.comp.avmedia.Manager_MacAVF"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_False

#else

#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_GStreamer"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False

#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
"com.sun.star.comp.avmedia.Manager_Java"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_True

#endif
#endif


On Tue, May 1, 2018 at 3:01 PM Peter kovacs  wrote:

> I think we do have the pain only with Linux. Since some distributions move
> slower then others.
>
> We could bundle the only 1.0.0 with Windows and Mac I think. For Linux we
> would need some logic, that identifies the right gstreamer available on the
> distribution.
> Maybe we could even reduce the effort to one certain package.
>
> I do not know about OS/2 or BSD. Maybe the appropiate volunteers could
> answer that. But imho it should not be a problem to create an additional
> port for this on BSD and integrate the right extention on OS/2.
>
> A complete different approach could be not to bundle the extention. It
> would give us the option for Windows user to add the gstreamer into the
> extention,  providing them a simplified access.
>
> For Linux a integration into the distribution would be the way. But I do
> not know how we can do that. We need maintainers for that.
>
> Am 1. Mai 2018 13:57:50 MESZ schrieb Jim Jagielski :
> >So that would mean that our 'official' community builds would
> >not longer bundle/include it by default? Would we have 2 different
> >versions of the extension (0.10 and 1.0) or just one?
> >
> >I like the idea, btw :)
> >
> >> On Apr 26, 2018, at 1:14 AM, Peter Kovacs  wrote:
> >>
> >> Does it make sense to reorg the gstreamer module into an extention?
> >> We could then have multiple versions of it.
> >>
> >> I mean after all this is only a optional feature, thats important to
> >some not all.
> >>
> >> On 25.04.2018 16:18, Jim Jagielski wrote:
> >>> I think this shows that we need to come to *some* consensus on
> >>> how to handle the gstreamer stuff. Either we provide both CentOS6
> >>> and Ubuntu builds to our community or we fold in the proposed
> >>> gstreamer "work-around" which makes it a purely runtime
> >>> concern.
> >>>
> >>> I would love to see how far we can go with the latter, but I am
> >>> loath to volunteer someone else to "do the work" since I am
> >>> unsure what the exact status of the patch is, how to fold it
> >>> into trunk and how to handle building with the patch folded in.
> >>>
> >>> I know that there are other issues related to being at the stage
> >>> to branch AOO420 from trunk but this, to me, seems like the
> >>> priority at this point.
> >>>
> >>>
> >-
> >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >For additional commands, e-mail: dev-h...@openoffice.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

SDBC developments and the JDBC driver port

[Damjan Jovanovic]

Hi

To update you on my development efforts, the PostgreSQL driver continues to
advance. I recently added views and fixed a major problem where "Refresh
Tables" causes everything done to tables from then on to fail (as Base
keeps holding references to the old table/view/user/group containers, so
container contents may change, but containers themselves must persist for
the lifetime of the driver).

I did however run into a disturbing bug. When my SDBC driver in Java calls
XStatement.close() on our underlying SDBC to JDBC converter driver written
in C++, and it calls java.sql.Statement.close() in the PostgreSQL JDBC
driver, I get a reproducible unchecked java.lang.IllegalClassChangeError
exception. After hours of debugging I did manage to work around it, by
getting a new methodID before every JNI call to close() instead of caching
it in a static global variable, which shouldn't be required as methodIDs
are meant to persist for the lifetime of the JVM. Either it's a bug in the
JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
corruption or the like :(.

Instead of committing that senseless methodID hack, I've decided to port
the SDBC-JDBC driver to Java, which should make memory corruption
impossible and any debugging and future maintenance much easier (the JNI
code to call into Java is exceptionally complex and ugly, and compiles into
a 15 MB pig of a library in a debug build!). Nothing is lost by using Java,
as the C++ driver can't load JDBC drivers without Java either, and
performance should be identical as the slow boundary between native and
Java is crossed an equal number of times, the crossing just happens in the
JNI bridge under main/bridges instead of the SDBC-JDBC driver.

So far the reusable parts of the PostgreSQL driver have been split off into
a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is itself
currently in the painful phase of dealing with JDBC classloading and class
caching. The final architecture should be something along these lines:

The rest of AOO (mostly C++)
 |  |
 |UNO   | UNO
 |  v
 |  PostgreSQL SDBC driver (Java)
 |  | |
 |  | UNO | UNO
 v  v v
SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
 |  |  |
 | Java | Java | C
 v  v  v
other   PostgreSQL JDBC  PostgreSQL ODBC
JDBC driver (Java)driver (C)
drivers |  |
| network I/O  |
v  v
PostgreSQL server

I've also already developed considerable support code for Java (logging,
resource bundles, data structure manipulation), all ported from the support
code for C++ under main/comphelper. Since it is generally useful to other
Java UNO modules, should I move it elsewhere, such as main/javaunohelper
which already contains similar support code, or is there somewhere better?

There are also some API-changing improvements I would like to make to
main/javaunohelper and/or main/ridljar. Is it ok to do those in trunk? Are
Java APIs (as opposed to UNO APIs) allowed to change between AOO 4.1 and
4.2?

Damjan

Re: Install Notes

[Damjan Jovanovic]

Welcome to AOO.
What Twitter posting?

On Sun, Oct 22, 2017 at 11:43 PM, Kenneth Mcfarland <
kennethpaulmcfarl...@gmail.com> wrote:

> Hello OpenOffice Team
>
> Nice work! I kicked LibreOffice to the curb today after seeing the twitter
> posting. It's great to be back and use Apache being a contributor to other
> projects.
>
> Anyways, there is one small thing that could make peoples lives easier.
> Here is my use case:
>
> I run Ubuntu 16.04 which comes with Libre, a lot of other people who are
> thrifty or love linux could be in my situation. The install notes that the
> path /usr/bin/soffice needs to be removed but this is *not* enough. Even
> after removing it, there will be errors during installation the generic
> "error /usr/bin/soffice libreoffice blah blah error".
>
> One needs to sudo apt-get -f remove libreoffice-common or the install will
> fail. I know, I just finished. Here is the ubuntu board I found during my
> search. First reply.
>
> https://askubuntu.com/questions/382041/dpkg-error-
> processing-openoffice4-0-debian-menus-4-0-9714-all-deb
>
> It would simply be nice if the en_US installation directory contained a
> file called INSTALL that concisely pointed this out as I did read the
> readmes both of them. The HTML version does a lot better job pointing this
> out, but is still insufficient as described above.
>
> I would be happy to do the work of correcting this if nobody else can.
>
> Sincerely,
> Kenneth McFarland
>

Re: SDBC developments and the JDBC driver port

[Damjan Jovanovic]

Apply these commits to 4.1.x and you'll be able to build AOO with Java 8:
1697228
1697237
1697247
1697306
1697312

I don't know why they haven't been backported yet.

Damjan

On Fri, Oct 27, 2017 at 10:31 PM, Dave Fisher <dave2w...@comcast.net> wrote:

> Hi Matthias,
>
> It is no longer easy to get EOLed JDKs. You have to pay Oracle for
> support. You have to pay Apple to get the old SDKs you need for Mac
> OpenOffice. I don’t mind paying Apple as I have the goal of trying to sign
> the Application to avoid Gatekeeper. I have the Xcode stuff and I’ve found
> JDK 6s. If a friend has the the JDK7 in /Libary/Java/JavaVirtualMachines/
> and would ship it to me that would be AWESOME.
>
> In my builds with JDK6 I am now having trouble with Help.
>
> There is a lot wrong with the Building guides. Too many options - MacPort
> or Brew, etc.
>
> I’ve spent about 16 hours this week on this and … I am about done with it.
>
> Regards,
> Dave
>
> On Oct 27, 2017, at 1:22 PM, Matthias Seidel <matthias.sei...@hamburg.de>
> wrote:
>
> Am 27.10.2017 um 21:19 schrieb Dave Fisher:
>
> Hi -
>
> As an aside I am working on Mac builds for 4.1.4 and it looks like uno does 
> not like JDK 8+, something to do with javadocs, but not sure as I am looking 
> for JDK7 …
>
>
> Do you need the SDK?
>
> From our release notes (Known Issues):
>
> For developers:
>
>- The OpenOffice SDK won't build with Java 8. Either build with
>--disable-odk or see the dev list archives for possible solutions.
>
> Either go with Java 7 or use --disable-odk as configure switch.
>
> Regards, Matthias
>
> If I can get things working I will be willing to try builds for you on trunk 
> or a branch as you make changes.
>
> Regards,
> Dave
>
>
> On Oct 27, 2017, at 12:05 PM, Peter Kovacs <pe...@apache.org> 
> <pe...@apache.org> wrote:
>
> Am Freitag, den 27.10.2017, 11:18 +0200 schrieb Damjan Jovanovic:
>
> Hi
>
> *wave*
>
> To update you on my development efforts, the PostgreSQL driver
> continues to
> advance. I recently added views and fixed a major problem where
> "Refresh
> Tables" causes everything done to tables from then on to fail (as
> Base
> keeps holding references to the old table/view/user/group containers,
> so
> container contents may change, but containers themselves must persist
> for
> the lifetime of the driver).
>
> I did however run into a disturbing bug. When my SDBC driver in Java
> calls
> XStatement.close() on our underlying SDBC to JDBC converter driver
> written
> in C++, and it calls java.sql.Statement.close() in the PostgreSQL
> JDBC
> driver, I get a reproducible unchecked
> java.lang.IllegalClassChangeError
> exception. After hours of debugging I did manage to work around it,
> by
> getting a new methodID before every JNI call to close() instead of
> caching
> it in a static global variable, which shouldn't be required as
> methodIDs
> are meant to persist for the lifetime of the JVM. Either it's a bug
> in the
> JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
> corruption or the like :(.
>
> Instead of committing that senseless methodID hack, I've decided to
> port
> the SDBC-JDBC driver to Java, which should make memory corruption
> impossible and any debugging and future maintenance much easier (the
> JNI
> code to call into Java is exceptionally complex and ugly, and
> compiles into
> a 15 MB pig of a library in a debug build!). Nothing is lost by using
> Java,
> as the C++ driver can't load JDBC drivers without Java either, and
> performance should be identical as the slow boundary between native
> and
> Java is crossed an equal number of times, the crossing just happens
> in the
> JNI bridge under main/bridges instead of the SDBC-JDBC driver.
>
> WTF?!
>
> So far the reusable parts of the PostgreSQL driver have been split
> off into
> a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is
> itself
> currently in the painful phase of dealing with JDBC classloading and
> class
> caching. The final architecture should be something along these
> lines:
>
> The rest of AOO (mostly C++)
> |  |
> |UNO   | UNO
> |  v
> |  PostgreSQL SDBC driver (Java)
> |  | |
> |  | UNO | UNO
> v  v v
> SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
> |  |  |
> | Java | Java | C
> v  v  v
> other   PostgreSQL JDBC  PostgreSQL ODBC
> JDBC driver (Java)driver (C)
> drivers |  |
>| network I/O  |
>   

Re: [proposal] going Agile

[Damjan Jovanovic]

On Sat, Feb 10, 2018 at 12:05 AM, Marcus  wrote:

> Am 09.02.2018 um 01:19 schrieb Patricia Shanahan:
>
>> On February 8, 2018, at 5:51 AM, Peter Kovacs  wrote:
>>
>> # Start spreading knowledge in our development team.
>>>

 1) I would like to propose a Product Backlog / OIL (OpenIssue) List
> to priorize Issues we need to work on. The most Valueable item comes
> to the top, the least to the bottom. What Value exactly is is up to
> discussion.
>

 Theoretically, we have a list of issues in Bugzilla with target 4.2.0.
 Validating them all and/or setting targets will basically give you
 what you wish. I think Bugzilla has some concept of an issue weight
 that would more or less allow to prioritize issues with the current
 tooling, so this can be done. At least, once we agree on list on a
 series of "must-haves" for 4.2.0, these could be turned into something
 similar to your backlog.

>>> Maybe we should not discuss tooling now. I think in the end it has to
>>> work. Jira is mostly a convenient choice. But we can think of all other
>>> sort of combinations. (However we have already a lot of Tools.So I would
>>> rather try to reduce those. We can try Bugzilla, but i do not want to
>>> start modifying Bugzilla in order to get what we need.
>>>
>>
>> I would prefer to avoid the upheaval of switching to a different issue
>> tracker if at all possible.
>>
>
> +1
>
> Jira is just another tool that wouldn't bring us any nearer to closed
> issues. BTW, start new? Then you would trash all old issues which isn't a
> good thing. Move them over to Jira? Great, who is the volunteer to do the
> migration? ;-)
>
>
>
+1 to that. We have Bugzilla bug numbers in SVN and even in the code, and
links to Bugzilla URLs in places too, who is going to find and replace all
of those?

I also find Bugzilla much faster to work with and lighter on the network
(not everyone is in a 1st world country).

Damjan

Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?

[Damjan Jovanovic]

Pleasure :)

No, when got AOO from Oracle, the only documentation for gbuild was a few
short notes on wiki pages, eg.
https://wiki.openoffice.org/wiki/Build_Environment_Effort/Module_Migration
I had to figure out AUXTARGETS on my own. I did send out an email some time
ago with some of my own notes on gbuild, but they also need updating.

What build flags are you using?

On Fri, Jul 27, 2018 at 7:32 PM Jim Jagielski  wrote:

> That patch did it. Thx! That is good knowledge to know. Do we
> have a Wiki page somewhere that goes into some level of
> detail regarding the build system? That trick seems like a
> good addition to it.
>
> Now we "just" have, afaict, the issue of unpkg failures:
>
> Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/bg_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_bg/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>
> **
> ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/bg_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_bg/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
> in function: register_extensions
> **
> in function: register_extensionsstopping log at Fri Jul 27 12:32:08 2018
> ... removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/stripped/ast ...
> Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/ast_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ast/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>
> **
> ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/ast_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ast/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
> in function: register_extensions
> **
> in function: register_extensionsstopping log at Fri Jul 27 12:32:08 2018
> ... removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/stripped/en-US ...
> Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>
> **
> ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
> in function: register_extensions
> **
> in function: register_extensionsstopping log at Fri Jul 27 12:32:09 2018
> dmake:  Error code 255, while making 'openoffice_bg.dmg'
>
>

Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?

[Damjan Jovanovic]

sers/jim/src/asf/AOO420/main/solver/420/
> unxmaccx.pro/workdir/Ant/jurt.jar
> /Users/jim/src/asf/AOO420/main/solver/420/unxmaccx.pro/bin/jurt.jar
> [ build LNK ] Library/libjpipe.dylib
> R=/Users/jim/src/asf/AOO420 && S=$R/main && O=$S/solver/420/unxmaccx.pro
> && W=$O/workdir &&  mkdir -p $W/LinkTarget/Library/ &&
> DYLIB_FILE=`/usr/bin/mktemp -t gbuild.` && /Users/jim/bin/perl
> $S/solenv/bin/macosx-dylib-link-list.pl  -dynamiclib -single_module
> -install_name
> '@__URELIB/libjpipe.dylib'
> -Wl,-syslibroot,/Applications/Xcode7.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
> -L$O/lib -L/usr/lib   -luno_sal  > ${DYLIB_FILE} &&
> /Applications/Xcode7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
> -arch x86_64  -dynamiclib -single_module -install_name
> '@__URELIB/libjpipe.dylib'
> -Wl,-syslibroot,/Applications/Xcode7.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
> -L$O/lib -L/usr/lib   -std=c++11 -stdlib=libc++ -luno_sal
> $W/CObject/jurt/source/pipe/com_sun_star_lib_connections_pipe_PipeConnection.o
> -o $W/LinkTarget/Library/libjpipe.dylib `cat ${DYLIB_FILE}` &&
> /Users/jim/bin/perl $S/solenv/bin/macosx-change-install-names.pl Library
> URELIB $W/LinkTarget/Library/libjpipe.dylib && ln -shf
> $W/LinkTarget/Library/libjpipe.dylib $W/LinkTarget/Library/libjpipe.jnilib
> && rm -f ${DYLIB_FILE}
> R=/Users/jim/src/asf/AOO420 && S=$R/main && O=$S/solver/420/unxmaccx.pro
> && W=$O/workdir &&  mkdir -p $O/lib/ && rm -f $O/lib/libjpipe.dylib && cp
> -R -P -f $W/LinkTarget/Library/libjpipe.dylib $O/lib/libjpipe.dylib &&
> touch -r $W/LinkTarget/Library/libjpipe.dylib $O/lib/libjpipe.dylib
> R=/Users/jim/src/asf/AOO420 && S=$R/main && O=$S/solver/420/unxmaccx.pro
> && W=$O/workdir &&  mkdir -p $W/Zip/ && cd $S/jurt/java/jurt/src/main/java
> && zip -rX -FS $W/Zip/jurt_src.zip
> com/sun/star/comp/loader/RegistrationClassFinder.java
> com/sun/star/comp/loader/FactoryHelper.java
> com/sun/star/comp/loader/JavaLoaderFactory.java
> com/sun/star/comp/loader/JavaLoader.java
> com/sun/star/comp/bridgefactory/BridgeFactory.java
> com/sun/star/comp/connections/ConstantInstanceProvider.java
> com/sun/star/comp/connections/Implementation.java
> com/sun/star/comp/connections/PipedConnection.java
> com/sun/star/comp/connections/Connector.java
> com/sun/star/comp/connections/Acceptor.java
> com/sun/star/comp/urlresolver/UrlResolver.java
> com/sun/star/comp/servicemanager/ServiceManager.java
> com/sun/star/uno/MappingException.java com/sun/star/uno/AsciiString.java
> com/sun/star/uno/Ascii.java com/sun/star/uno/WeakReference.java
> com/sun/star/uno/AnyConverter.java
> com/sun/star/lib/util/UrlToFileMapper.java
> com/sun/star/lib/util/AsynchronousFinalizer.java
> com/sun/star/lib/util/StringHelper.java
> com/sun/star/lib/util/NativeLibraryLoader.java
> com/sun/star/lib/connections/socket/socketAcceptor.java
> com/sun/star/lib/connections/socket/SocketConnection.java
> com/sun/star/lib/connections/socket/ConnectionDescriptor.java
> com/sun/star/lib/connections/socket/socketConnector.java
> com/sun/star/lib/connections/pipe/pipeAcceptor.java
> com/sun/star/lib/connections/pipe/pipeConnector.java
> com/sun/star/lib/connections/pipe/PipeConnection.java
> com/sun/star/lib/uno/environments/remote/JavaThreadPoolFactory.java
> com/sun/star/lib/uno/environments/remote/IProtocol.java
> com/sun/star/lib/uno/environments/remote/Job.java
> com/sun/star/lib/uno/environments/remote/IReceiver.java
> com/sun/star/lib/uno/environments/remote/remote_environment.java
> com/sun/star/lib/uno/environments/remote/IThreadPool.java
> com/sun/star/lib/uno/environments/remote/Message.java
> com/sun/star/lib/uno/environments/remote/JavaThreadPool.java
> com/sun/star/lib/uno/environments/remote/JobQueue.java
> com/sun/star/lib/uno/environments/remote/ThreadId.java
> com/sun/star/lib/uno/environments/remote/ThreadPoolManager.java
> com/sun/star/lib/uno/environments/remote/NativeThreadPool.java
> com/sun/star/lib/uno/environments/java/java_environment.java
> com/sun/star/lib/uno/bridges/java_remote/XConnectionOutputStream_Adapter.java
> com/sun/star/lib/uno/bridges/java_remote/RequestHandler.java
> com/sun/star/lib/uno/bridges/java_remote/XConnectionInputStream_Adapter.java
> com/sun/star/lib/uno/bridges/java_remote/ProxyFactory.java
> com/sun/star/lib/uno/bridges/java_remote/BridgedObject.java
> com/sun/star/lib/uno/bridges/java_remote/java_remote_bridge.java
> com/s

Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?

[Damjan Jovanovic]

On Wed, Jul 25, 2018 at 6:30 PM Jim Jagielski  wrote:

> As readers no doubt recall, I'm been struggling with getting
> the latest HEAD of 4.2.0 to build on macOS... The various
> migrations of modules from the old build to gbuild, w/o
> consideration for other platforms has broken things, both
> related to required libs not being linked and/or copied
> (fallout from the UDK versioning changes) as well as other
> issues which I can't fathom.
>
> Is there anyone left who knows the build process well enough
> that when I run into dead-ends could provide some clues
> and helpful insights on at least where to look for possible
> work-arounds and fixes?
>
> For example, jurt builds libjpipe.dylib and the build
> process correctly links that to libjpipe.jnilib. However,
> during later processing, it looks like that file isn't
> copied over, and the build fails saying it cannot find
> libjpipe.jnilib. If I forcibly link it, I can continue
> the build, but then I get:
>


Let's fix that jurt problem first.

What does running "make showdeliverables" in the main/jurt directory give
you?

Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?

[Damjan Jovanovic]

On Wed, Jul 25, 2018 at 6:30 PM Jim Jagielski  wrote:

> As readers no doubt recall, I'm been struggling with getting
> the latest HEAD of 4.2.0 to build on macOS... The various
> migrations of modules from the old build to gbuild, w/o
> consideration for other platforms has broken things, both
> related to required libs not being linked and/or copied
> (fallout from the UDK versioning changes) as well as other
> issues which I can't fathom.
>
> Is there anyone left who knows the build process well enough
> that when I run into dead-ends could provide some clues
> and helpful insights on at least where to look for possible
> work-arounds and fixes?
>
> For example, jurt builds libjpipe.dylib and the build
> process correctly links that to libjpipe.jnilib. However,
> during later processing, it looks like that file isn't
> copied over, and the build fails saying it cannot find
> libjpipe.jnilib. If I forcibly link it, I can continue
> the build, but then I get:
>
>
Let's fix that jurt problem first.

What does running "make showdeliverables" in the main/jurt directory give
you?

Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?

[Damjan Jovanovic]

The file:
/Users/jim/src/asf/AOO420/main/instsetoo_native/
unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg
is a small shell script. You should be able to call it manually with the
"sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1" arguments. Edit it
and get it to log where it is and what it's doing, then narrow down where
it fails. Get it to print its parent process on startup, so we know who is
calling it (possibly by printing a process tree like "ps daxww", so we see
the full ancestry).

Otherwise, the equivalent of "git bisect", while back-porting recent
patches to get older versions to build, until you find the first patch that
caused this failure.

Also your build output suggests that this happens while building the DMG.
If you just use the simplest "--with-package-format=installed", does it
work?

And there is usually a section in the build output that says
... checking log file /log_AOO420_en-US.log
Anything revealing in there?

I am going on leave, so you might not hear from me for a while. Reply
anyway, and I'll have a look when I can.

Good luck.


On Wed, Aug 1, 2018 at 2:12 PM Jim Jagielski  wrote:

> Anyone have any ideas where to start digging around for what
> could be causing this last (hopefully!) nit on macOS:
>
> in function: register_extensions
> **
> in function: register_extensionsstopping log at Fri Jul 27 12:32:08 2018
> ... removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/stripped/en-US ...
> Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>
> **
> ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
> in function: register_extensions
> **
> in function: register_extensionsstopping log at Fri Jul 27 12:32:09 2018
>

Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?

[Damjan Jovanovic]

That looks right.

You were saying libjpipe.jnilib doesn't get copied over. If it doesn't
appear in that output, it won't be.

My Mac experience is pretty minimal, but grepping through main/solenv/inc
and reading main/solenv/macosx-create-bundle seems to say how libfoo.jnilib
is a symlink back to libfoo.dylib.

Gbuild doesn't call that macosx-create-bundle script, but does have this
comment just before gb_LinkTarget__command_dynamiclink:
# FIXME the DYLIB_FILE mess is only necessary because
# solver layout is different from installation layout

Please run "make clean" in main/jurt and then post the output of "make".

Also what libjpipe files are normally packaged in a Mac AOO installation
package? What are their exact names?



On Thu, Jul 26, 2018 at 4:20 PM Jim Jagielski  wrote:

> %# make showdeliverables
> /Users/jim/src/asf/AOO420/main/solver/420/
> unxmaccx.pro/workdir/Ant/jurt.jar
> /Users/jim/src/asf/AOO420/main/solver/420/unxmaccx.pro/bin/jurt.jar
>
> /Users/jim/src/asf/AOO420/main/solver/420/unxmaccx.pro/workdir/LinkTarget/Library/libjpipe.dylib
> <http://unxmaccx.pro/bin/jurt.jar/Users/jim/src/asf/AOO420/main/solver/420/unxmaccx.pro/workdir/LinkTarget/Library/libjpipe.dylib>
> /Users/jim/src/asf/AOO420/main/solver/420/unxmaccx.pro/lib/libjpipe.dylib
>
> /Users/jim/src/asf/AOO420/main/solver/420/unxmaccx.pro/workdir/Zip/jurt_src.zip
> <http://unxmaccx.pro/lib/libjpipe.dylib/Users/jim/src/asf/AOO420/main/solver/420/unxmaccx.pro/workdir/Zip/jurt_src.zip>
> /Users/jim/src/asf/AOO420/main/solver/420/unxmaccx.pro/pck/jurt_src.zip
> true
>
> Thx
>
> > On Jul 25, 2018, at 9:48 PM, Damjan Jovanovic 
> wrote:
> >
> > make showdeliverables
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?

[Damjan Jovanovic]

Hi

instsetoo_native is the last module that is built, since it's the one
responsible for generating installation packages.

In your error the command "unopkg sync" fails. With our opengrok gone, I
can't easily tell where register_extensions is. Also I wonder if unopkg
sync is called correctly there, there's no filename.

I am updating and rebuilding now to help you further.

Damjan



On Wed, Jul 25, 2018 at 5:49 PM Jim Jagielski  wrote:

> As readers no doubt recall, I'm been struggling with getting
> the latest HEAD of 4.2.0 to build on macOS... The various
> migrations of modules from the old build to gbuild, w/o
> consideration for other platforms has broken things, both
> related to required libs not being linked and/or copied
> (fallout from the UDK versioning changes) as well as other
> issues which I can't fathom.
>
> Is there anyone left who knows the build process well enough
> that when I run into dead-ends could provide some clues
> and helpful insights on at least where to look for possible
> work-arounds and fixes?
>
> For example, jurt builds libjpipe.dylib and the build
> process correctly links that to libjpipe.jnilib. However,
> during later processing, it looks like that file isn't
> copied over, and the build fails saying it cannot find
> libjpipe.jnilib. If I forcibly link it, I can continue
> the build, but then I get:
>
>   **
>   ERROR: ERROR:   /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/ca_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca/OpenOffice.app/Contents/program/unopkg
> sync --verbose -  env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>   in function: register_extensions
>   **
>   in function: register_extensionsstopping log at Tue Jul 24 17:29:46 2018
> .. removing directory   /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/stripped/bg ...
>
> I've no idea what that means and what could be causing that...
>
> So my question is whether there is anyone around who
> has any ideas or clues on where to start...? Considering
> that macOS is one of our largest downloads, it would be nice
> to not have to drop it from AOO 4.2.0.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

xmlhelp ported to gbuild

[Damjan Jovanovic]

Hi

After a long break, I've decided to do some more gbuild porting, for
interesting reasons I will discuss later.

main/xmlhelp has just been ported and the changes committed.

It's been tested only on FreeBSD but the changes are fairly conservative
and should work everywhere.

186 modules exist in total.
65 AOO modules using dmake still remain to be ported to gbuild.
All 37 external modules (eg. jpeg, zlib) are using dmake. How to port them
remains unclear, but they should be easy to port as they use other build
scripts that we chain-build.

Damjan

Re: Source code

[Damjan Jovanovic]

The code for the "Save As" -> "HTML document" feature seems to be in:

main/sc/source/filter/html for Calc, and
main/sw/source/filter/html for Writer.
(Not sure if there are more?)

Thank you for your contribution, and please let us know if you need any
further help.

Damjan

On Mon, Aug 20, 2018 at 11:30 PM Howard Cary Morris <
howard_cary_mor...@hotmail.com> wrote:

> Trying to use wiki – keeps referring to something else I must read first
> which refers me to something else I must read first. That includes what I
> thought ere the modules. Luckily, I can read code. If you send me a list of
> modules and where they are located. I will build my own tools to do the
> analysis and figure out what to change.
>
>
>
> If you want to try what I have built so far,
> http://www.americasfreedompressalliance.us/Howard/Open/ is the
> transaction that I change .html code generated by Open office (save as
> html) to a .htm file. If you find any bugs. Let me know. Last thing I
> worked on was showing header for document. One of the bugs, from my point
> of view is that I have no indication where the page breaks occur (so I know
> where more headers and footers go).
>
>
>
> 
> From: Peter kovacs 
> Sent: Tuesday, August 7, 2018 2:44:52 AM
> To: dev@openoffice.apache.org; howard_cary_mor...@hotmail.com
> Subject: RE: Source code
>
> Awesome. I hope you bring some endurance.
> I help you the best to my abilities.
>
> We will find a way to integrate your code, no worries.
> I can imagine to give you commiter rights or I pull your code over github
> and push it in your name to trunk.
> We will find a way together, okay?
> Let's focus on code production first. When there is something to commit we
> discuss the way.
>
> I suggest to leave existing filters intact and do an html5 one.
>
> >My code has found some errors in current generated code
> What do you mean? Can you explain one case?
> The current html4 code does not produce pure html4. It is something the
> browser can work with. There have been reports in the past about it.
> Or do you talk about bad code?
>
> Wiki stuff
> To me the wiki is a haystack.
> I think here you find some hints:
>
>
> https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide
>
> I think there is more. I hope I will find time for some research.
>
>
> Am 7. August 2018 00:26:42 MESZ schrieb Howard Cary Morris <
> howard_cary_mor...@hotmail.com>:
> >Goals are
> >
> >1) generate HTML5 code
> >
> >2) Make output same as print file (browser print gives same report)
> >
> >3) Show where page breaks are
> >
> >   (add page headers/footers for each page)
> >
> >4) Be able to embed output in an iframe
> >
> > (allowing us to compete with PDF with much smaller size files)
> >
> >
> >
> >I have written some PHP and HTML that messages the current html output.
> >
> >However, was told you wanted differences in code.
> >
> >My code has found some errors in current generated code
> >
> >
> >
> >Howard
> >
> >
> >
> >PS where on wiki?
> >
> >
> >
> >
> >From: Peter Kovacs 
> >Sent: Monday, August 6, 2018 5:15:06 PM
> >To: dev@openoffice.apache.org
> >Subject: Re: Source code
> >
> >There is no easy way to answer this.
> >Some are explained on wiki. You get clues by looking at the source
> >files
> >and code.
> >
> >In case of saving and writing specific files the module filter might be
> >a good starting point.
> >However this is from my side a shot in the blue. If you describe what
> >your goal is maybe you get a better answer.
> >
> >I heared Libre Office have established a text file in each of their
> >modules what the module is about.
> >We might want to copy the idea, even if we are not able to copy their
> >words because of license stuff.
> >
> >
> >
> >On 06.08.2018 22:25, Howard Cary Morris wrote:
> >> Some time ago I made a copy of the source code.
> >> I may be ready to do something.
> >> Need to know where I can find out what each sub-module does.
> >> I am especially interested in modules invoked with
> >> “Save as HTML document”
> >>
> >> Howard
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >For additional commands, e-mail: dev-h...@openoffice.apache.org
>

Re: xmlhelp ported to gbuild

[Damjan Jovanovic]

That's good news, thank you.

Significant further changes will be coming, with the ability to run
cppumaker-based UNO IDL generation from gbuild that I am now developing,
which was a barrier to porting at least 7 more dmake modules.

On Wed, Aug 22, 2018 at 12:02 AM Kay Schenk  wrote:

> On Wed, Aug 15, 2018 at 12:02 AM Damjan Jovanovic 
> wrote:
>
> > Hi
> >
> > After a long break, I've decided to do some more gbuild porting, for
> > interesting reasons I will discuss later.
> >
> > main/xmlhelp has just been ported and the changes committed.
> >
> > It's been tested only on FreeBSD but the changes are fairly conservative
> > and should work everywhere.
> >
> > 186 modules exist in total.
> > 65 AOO modules using dmake still remain to be ported to gbuild.
> > All 37 external modules (eg. jpeg, zlib) are using dmake. How to port
> them
> > remains unclear, but they should be easy to port as they use other build
> > scripts that we chain-build.
> >
> > Damjan
> >
>
> Hi. I built and have opened and checked out the existing AOO Help. So far,
> so good. This is on my CentOS 6.10 system with the old gstreamer so I did
> not enable that option. I need to investigate the build output and will
> report on any problems in a few days.
>
> --
> --
> MzK
>
> "Less is MORE."
>

Re: svn commit: r1839782 - in /openoffice/trunk/main: ./ rsc/ rsc/prj/ rsc/source/parser/ solenv/gbuild/

[Damjan Jovanovic]

On Tue, Sep 4, 2018 at 11:16 AM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Am 04.09.2018 um 07:43 schrieb Damjan Jovanovic:
> > I don't get it, main/sfx2 builds for me on both FreeBSD and Windows.
> >
> > main/salhelper fails to build on Windows, and it looks like a mission to
> > fix it :(.
>
> It *is* now in salhelper:
>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/salhelper/wntmsci12.pro/misc/logs/prj.txt
>
>
I just committed a patch to salhelper that should fix building on Windows.

And starting a clean rebuild to check for other errors.

Regards
Damjan

Re: svn commit: r1839782 - in /openoffice/trunk/main: ./ rsc/ rsc/prj/ rsc/source/parser/ solenv/gbuild/

[Damjan Jovanovic]

On Tue, Sep 4, 2018 at 9:27 PM Matthias Seidel 
wrote:

> Am 04.09.2018 um 18:56 schrieb Damjan Jovanovic:
> > On Tue, Sep 4, 2018 at 11:16 AM Matthias Seidel <
> matthias.sei...@hamburg.de>
> > wrote:
> >
> >> Hi Damjan,
> >>
> >> Am 04.09.2018 um 07:43 schrieb Damjan Jovanovic:
> >>> I don't get it, main/sfx2 builds for me on both FreeBSD and Windows.
> >>>
> >>> main/salhelper fails to build on Windows, and it looks like a mission
> to
> >>> fix it :(.
> >> It *is* now in salhelper:
> >>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/salhelper/wntmsci12.pro/misc/logs/prj.txt
> >>
> >>
> > I just committed a patch to salhelper that should fix building on
> Windows.
> >
> > And starting a clean rebuild to check for other errors.
>
> Hi Damjan,
>
> I also started a new Windows build...
>
> But the Linux builds still fail in sfx2:
>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/sfx2/unxlngx6.pro/misc/logs/prj.txt
>
> Looks like a syntax error in a resource file?
>
>
I had to make a few more changes in r1840081 to get Windows to build, but
it does build now.

It's possible that porting rsc (our resource compiler) to gbuild, and the
Bison support I had to add to gbuild, broke parsing some resource files.
But I don't understand how Windows and FreeBSD build, but Linux doesn't?

Re: svn commit: r1839782 - in /openoffice/trunk/main: ./ rsc/ rsc/prj/ rsc/source/parser/ solenv/gbuild/

[Damjan Jovanovic]

Elaborate please regarding jurt.

The last few remaining non-gbuild modules are extremely difficult to port
and will probably break a lot.

On Fri, Sep 7, 2018 at 5:21 PM Jim Jagielski  wrote:

> I'm having trouble w/ jurt as well...
>
> Considering that we would like to get 4.2.0 out at some point, we will
> eventually have to create a 4.2.0 branch where we can have something more
> stable to beta test. It seems like the migrations to gbuild causes
> troubles, esp w/ macOS and other non-Linux platforms.
>
> > On Sep 7, 2018, at 10:12 AM, Matthias Seidel 
> wrote:
> >
> > Hi Damjan,
> >
> > Am 05.09.2018 um 04:48 schrieb Damjan Jovanovic:
> >> On Tue, Sep 4, 2018 at 9:27 PM Matthias Seidel <
> matthias.sei...@hamburg.de>
> >> wrote:
> >>
> >>> Am 04.09.2018 um 18:56 schrieb Damjan Jovanovic:
> >>>> On Tue, Sep 4, 2018 at 11:16 AM Matthias Seidel <
> >>> matthias.sei...@hamburg.de>
> >>>> wrote:
> >>>>
> >>>>> Hi Damjan,
> >>>>>
> >>>>> Am 04.09.2018 um 07:43 schrieb Damjan Jovanovic:
> >>>>>> I don't get it, main/sfx2 builds for me on both FreeBSD and Windows.
> >>>>>>
> >>>>>> main/salhelper fails to build on Windows, and it looks like a
> mission
> >>> to
> >>>>>> fix it :(.
> >>>>> It *is* now in salhelper:
> >>>>>
> >>>>>
> >>>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/salhelper/wntmsci12.pro/misc/logs/prj.txt
> >>>>>
> >>>> I just committed a patch to salhelper that should fix building on
> >>> Windows.
> >>>> And starting a clean rebuild to check for other errors.
> >>> Hi Damjan,
> >>>
> >>> I also started a new Windows build...
> >>>
> >>> But the Linux builds still fail in sfx2:
> >>>
> >>>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/sfx2/unxlngx6.pro/misc/logs/prj.txt
> >>>
> >>> Looks like a syntax error in a resource file?
> >>>
> >>>
> >> I had to make a few more changes in r1840081 to get Windows to build,
> but
> >> it does build now.
> >>
> >> It's possible that porting rsc (our resource compiler) to gbuild, and
> the
> >> Bison support I had to add to gbuild, broke parsing some resource files.
> >> But I don't understand how Windows and FreeBSD build, but Linux doesn't?
> >
> > At least Windows doesn't build either:
> >
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/sfx2/wntmsci12.pro/misc/logs/prj.txt
> >
> > Regards,
> >Matthias
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: svn commit: r1839782 - in /openoffice/trunk/main: ./ rsc/ rsc/prj/ rsc/source/parser/ solenv/gbuild/

[Damjan Jovanovic]

My successful builds used:

configure:22632: checking which languages to be built
configure:22636: result: en-US

The Windows buildbot:

checking which languages to be built... en-US de fr it pt ja

It's probably only reproducible with a certain language selection?


On Fri, Sep 7, 2018 at 5:55 PM Matthias Seidel 
wrote:

> Nothing changed at the buildbots configuration...
>
> It began to break with r1839782:
> https://ci.apache.org/builders/aoo-win7
> https://ci.apache.org/builders/openoffice-linux64-nightly
> https://ci.apache.org/builders/openoffice-linux32-nightly
>
> Confirmed with my personal Windows builds.
>
>
> Am 07.09.2018 um 17:45 schrieb Damjan Jovanovic:
> > Windows, Linux and FreeBSD all build for me.
> >
> > Something must be different with the options to ./configure.
> >
> > On Fri, Sep 7, 2018 at 4:13 PM Matthias Seidel <
> matthias.sei...@hamburg.de>
> > wrote:
> >
> >> Hi Damjan,
> >>
> >> Am 05.09.2018 um 04:48 schrieb Damjan Jovanovic:
> >>> On Tue, Sep 4, 2018 at 9:27 PM Matthias Seidel <
> >> matthias.sei...@hamburg.de>
> >>> wrote:
> >>>
> >>>> Am 04.09.2018 um 18:56 schrieb Damjan Jovanovic:
> >>>>> On Tue, Sep 4, 2018 at 11:16 AM Matthias Seidel <
> >>>> matthias.sei...@hamburg.de>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Damjan,
> >>>>>>
> >>>>>> Am 04.09.2018 um 07:43 schrieb Damjan Jovanovic:
> >>>>>>> I don't get it, main/sfx2 builds for me on both FreeBSD and
> Windows.
> >>>>>>>
> >>>>>>> main/salhelper fails to build on Windows, and it looks like a
> mission
> >>>> to
> >>>>>>> fix it :(.
> >>>>>> It *is* now in salhelper:
> >>>>>>
> >>>>>>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/salhelper/wntmsci12.pro/misc/logs/prj.txt
> >>>>> I just committed a patch to salhelper that should fix building on
> >>>> Windows.
> >>>>> And starting a clean rebuild to check for other errors.
> >>>> Hi Damjan,
> >>>>
> >>>> I also started a new Windows build...
> >>>>
> >>>> But the Linux builds still fail in sfx2:
> >>>>
> >>>>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/sfx2/unxlngx6.pro/misc/logs/prj.txt
> >>>> Looks like a syntax error in a resource file?
> >>>>
> >>>>
> >>> I had to make a few more changes in r1840081 to get Windows to build,
> but
> >>> it does build now.
> >>>
> >>> It's possible that porting rsc (our resource compiler) to gbuild, and
> the
> >>> Bison support I had to add to gbuild, broke parsing some resource
> files.
> >>> But I don't understand how Windows and FreeBSD build, but Linux
> doesn't?
> >> At least Windows doesn't build either:
> >>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/sfx2/wntmsci12.pro/misc/logs/prj.txt
> >>
> >> Regards,
> >>Matthias
> >>
> >>
>
>
>

Re: svn commit: r1839782 - in /openoffice/trunk/main: ./ rsc/ rsc/prj/ rsc/source/parser/ solenv/gbuild/

[Damjan Jovanovic]

Windows, Linux and FreeBSD all build for me.

Something must be different with the options to ./configure.

On Fri, Sep 7, 2018 at 4:13 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Am 05.09.2018 um 04:48 schrieb Damjan Jovanovic:
> > On Tue, Sep 4, 2018 at 9:27 PM Matthias Seidel <
> matthias.sei...@hamburg.de>
> > wrote:
> >
> >> Am 04.09.2018 um 18:56 schrieb Damjan Jovanovic:
> >>> On Tue, Sep 4, 2018 at 11:16 AM Matthias Seidel <
> >> matthias.sei...@hamburg.de>
> >>> wrote:
> >>>
> >>>> Hi Damjan,
> >>>>
> >>>> Am 04.09.2018 um 07:43 schrieb Damjan Jovanovic:
> >>>>> I don't get it, main/sfx2 builds for me on both FreeBSD and Windows.
> >>>>>
> >>>>> main/salhelper fails to build on Windows, and it looks like a mission
> >> to
> >>>>> fix it :(.
> >>>> It *is* now in salhelper:
> >>>>
> >>>>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/salhelper/wntmsci12.pro/misc/logs/prj.txt
> >>>>
> >>> I just committed a patch to salhelper that should fix building on
> >> Windows.
> >>> And starting a clean rebuild to check for other errors.
> >> Hi Damjan,
> >>
> >> I also started a new Windows build...
> >>
> >> But the Linux builds still fail in sfx2:
> >>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/sfx2/unxlngx6.pro/misc/logs/prj.txt
> >>
> >> Looks like a syntax error in a resource file?
> >>
> >>
> > I had to make a few more changes in r1840081 to get Windows to build, but
> > it does build now.
> >
> > It's possible that porting rsc (our resource compiler) to gbuild, and the
> > Bison support I had to add to gbuild, broke parsing some resource files.
> > But I don't understand how Windows and FreeBSD build, but Linux doesn't?
>
> At least Windows doesn't build either:
>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/sfx2/wntmsci12.pro/misc/logs/prj.txt
>
> Regards,
>Matthias
>
>

Re: Mac buildbot available?

[Damjan Jovanovic]

Hopefully. Does Xserve provide the graphical libraries (Aqua, Quartz,
etc.)? Weren't XServes discontinued years ago?


On Wed, Aug 29, 2018 at 10:47 PM Peter kovacs  wrote:

> Hi all,
>
> I just read following on https://ci.apache.org/buildbot.html
>
> *NEW* - OSX Apple XServe Slave
>
> This sounds cool!
> Would this help us?
>
> All the best
> Peter
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: svn commit: r1839782 - in /openoffice/trunk/main: ./ rsc/ rsc/prj/ rsc/source/parser/ solenv/gbuild/

[Damjan Jovanovic]

On Sat, Sep 8, 2018 at 10:47 AM Matthias Seidel 
wrote:

> Am 08.09.2018 um 10:16 schrieb Damjan Jovanovic:
> > It should be fixed in 1840343:
> >
> > "When building other languages (--with-lang="..."), the build was
> breaking
> > because rsc couldn't compile certain resources (usually in main/sfx2).
> >
> > Apparently the RSC preprocessor, rscpp, uses very small buffers by
> default.
> > When the SOLAR preprocessor definition is defined, it uses bigger buffers
> > instead. Previously dmake was explicitly passing "-DSOLAR" to the C
> compiler
> > but I missed it when porting main/rsc to gbuild. When added back,
> > main/sfx2 builds languages successfully."
>
> Hi Damjan,
>
> Great! Building as we speak...
>
> And thanks for the explanation. It helps me to (hopefully) understand
> more and more. ;-)
>
> Regards,
>Matthias
>
>
Hi

Pleasure :)

Mine built successfully.

Regards
Damjan

Re: svn commit: r1839782 - in /openoffice/trunk/main: ./ rsc/ rsc/prj/ rsc/source/parser/ solenv/gbuild/

[Damjan Jovanovic]

It should be fixed in 1840343:

"When building other languages (--with-lang="..."), the build was breaking
because rsc couldn't compile certain resources (usually in main/sfx2).

Apparently the RSC preprocessor, rscpp, uses very small buffers by default.
When the SOLAR preprocessor definition is defined, it uses bigger buffers
instead. Previously dmake was explicitly passing "-DSOLAR" to the C compiler
but I missed it when porting main/rsc to gbuild. When added back,
main/sfx2 builds languages successfully."

On Fri, Sep 7, 2018 at 10:23 PM Matthias Seidel 
wrote:

> Am 07.09.2018 um 20:45 schrieb Damjan Jovanovic:
>
> My successful builds used:
>
> configure:22632: checking which languages to be built
> configure:22636: result: en-US
>
> The Windows buildbot:
>
> checking which languages to be built... en-US de fr it pt ja
>
> It's probably only reproducible with a certain language selection?
>
>
> It is more probably building in en-US only?
>
> That is why the buildbots always build different languages, to catch such
> situations...
>
>
>
> On Fri, Sep 7, 2018 at 5:55 PM Matthias Seidel  
> 
> wrote:
>
>
> Nothing changed at the buildbots configuration...
>
> It began to break with 
> r1839782:https://ci.apache.org/builders/aoo-win7https://ci.apache.org/builders/openoffice-linux64-nightlyhttps://ci.apache.org/builders/openoffice-linux32-nightly
>
> Confirmed with my personal Windows builds.
>
>
> Am 07.09.2018 um 17:45 schrieb Damjan Jovanovic:
>
> Windows, Linux and FreeBSD all build for me.
>
> Something must be different with the options to ./configure.
>
> On Fri, Sep 7, 2018 at 4:13 PM Matthias Seidel <
>
> matthias.sei...@hamburg.de>
>
> wrote:
>
>
> Hi Damjan,
>
> Am 05.09.2018 um 04:48 schrieb Damjan Jovanovic:
>
> On Tue, Sep 4, 2018 at 9:27 PM Matthias Seidel <
>
> matthias.sei...@hamburg.de>
>
> wrote:
>
>
> Am 04.09.2018 um 18:56 schrieb Damjan Jovanovic:
>
> On Tue, Sep 4, 2018 at 11:16 AM Matthias Seidel <
>
> matthias.sei...@hamburg.de>
>
> wrote:
>
>
> Hi Damjan,
>
> Am 04.09.2018 um 07:43 schrieb Damjan Jovanovic:
>
> I don't get it, main/sfx2 builds for me on both FreeBSD and
>
> Windows.
>
> main/salhelper fails to build on Windows, and it looks like a
>
> mission
>
> to
>
> fix it :(.
>
> It *is* now in salhelper:
>
>
>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/salhelper/wntmsci12.pro/misc/logs/prj.txt
>
> I just committed a patch to salhelper that should fix building on
>
> Windows.
>
> And starting a clean rebuild to check for other errors.
>
> Hi Damjan,
>
> I also started a new Windows build...
>
> But the Linux builds still fail in sfx2:
>
>
>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/sfx2/unxlngx6.pro/misc/logs/prj.txt
>
> Looks like a syntax error in a resource file?
>
>
>
> I had to make a few more changes in r1840081 to get Windows to build,
>
> but
>
> it does build now.
>
> It's possible that porting rsc (our resource compiler) to gbuild, and
>
> the
>
> Bison support I had to add to gbuild, broke parsing some resource
>
> files.
>
> But I don't understand how Windows and FreeBSD build, but Linux
>
> doesn't?
>
> At least Windows doesn't build either:
>
>
>
> https://ci.apache.org/projects/openoffice/buildlogs/win/main/sfx2/wntmsci12.pro/misc/logs/prj.txt
>
> Regards,
>Matthias
>
>
>
>
>
>

Re: svn commit: r1826059 - /openoffice/trunk/main/solenv/win64/win64.patch

[Damjan Jovanovic]

Why is it in Bugzilla? Merge it! :)

Mac users can either test regularly, or deal with the consequences later.

On Wed, Mar 7, 2018 at 2:55 AM, Don Lewis  wrote:

> On  7 Mar, dam...@apache.org wrote:
> > Author: damjan
> > Date: Wed Mar  7 00:39:35 2018
> > New Revision: 1826059
> >
> > URL: http://svn.apache.org/viewvc?rev=1826059=rev
> > Log:
> > Add a missing .ENDIF
> >
> > Patch by: me
> >
> >
> > Modified:
> > openoffice/trunk/main/solenv/win64/win64.patch
> >
> > Modified: openoffice/trunk/main/solenv/win64/win64.patch
> > URL: http://svn.apache.org/viewvc/openoffice/trunk/main/solenv/
> win64/win64.patch?rev=1826059=1826058=1826059=diff
> > 
> ==
> > --- openoffice/trunk/main/solenv/win64/win64.patch (original)
> > +++ openoffice/trunk/main/solenv/win64/win64.patch Wed Mar  7 00:39:35
> 2018
> > @@ -261,7 +261,7 @@ Index: solenv/inc/tg_compv.mk
> >  ===
> >  --- solenv/inc/tg_compv.mk   (revision 1826001)
> >  +++ solenv/inc/tg_compv.mk   (working copy)
> > -@@ -72,7 +72,10 @@
> > +@@ -72,9 +72,13 @@
> >   .IF "$(COM)"=="MSC"
> >   .IF "$(CCNUMVER)">="0012"
> >   COMID=MSC
> > @@ -271,6 +271,9 @@ Index: solenv/inc/tg_compv.mk
> >  +COMNAME=mscx
> >   .ENDIF
> >   .ENDIF
> > ++.ENDIF
> > +
> > + .IF "$(COM)"=="GCC"
> >
> >  Index: odk/settings/settings.mk
> >  ===
>
> I wish my patch in https://bz.apache.org/ooo/show_bug.cgi?id=127664
> since it is now bit-rotting.  It's been waiting for testing on Mac for
> the last six weeks ...
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: patch to move $CCNUMVER from dmake to configure

[Damjan Jovanovic]

Hi Don

Please commit this patch ASAP.

I think you're waited enough for Mac testers, and it's now holding up other
changes I want to make.

I can even commit it for you.

Thank you
Damjan


On Thu, Jan 18, 2018 at 9:17 AM, Don Lewis  wrote:

> On 16 Jan, Kay Schenk wrote:
> >
> >
> > On 01/11/2018 11:24 PM, Don Lewis wrote:
> >> The patch below moves the calculation of $CCNUMVER and some other
> >> variables from main/solenv/inc/tg_compv.mk, where it is only usable by
> >> dmake, to configure, where it can be used by both dmake and gbuild. This
> >> is a requirement for me upstream some compiler bug workaround patches
> >> from the FreeBSD port.
> >>
> >> A bit of logic from set_soenv is also moved into configure.  A bunch
> >> more should probably be moved so that the configuration logic is not
> >> spread across so many different places, but that can wait.  Something
> >> else to consider is that it would be nice to use a different value of
> >> $COM for Apple's clang, maybe "ACLANG" or "APPLECLANG" since it  has a
> >> different version numbering scheme that the open-source version of clang
> >> and having a unique identifier would simplify version checking when
> >> applying compiler bug workarounds.
> >>
> >> I've tested this patch on Windows, CentOS 6, and FreeBSD.  It really
> >> needs some testing on Mac and OS/2.
> >>
> >> If you have an existing, populated build tree, then the most important
> >> tests can be done without even doing a build.  Start off by copying the
> >> *env.set.sh script and solver/420/*/inc/comp_ver.mk to a safe location.
> >> Next apply the patch below, run autoconf, and then run configure.
> >> Compare the values of $COMNAME, $COMID, $CCNUMVER, and $CCVER from the
> >> new *.env.set.sh with the values of those variables from the saved copy
> >> of comp_ver.mk.  Also compare the values of $COM in the new and saved
> >> versions of *.env.set.sh.
> >>
> >> Note: I think the old value of $CCNUMVER on the Mac is wrong.  It should
> >> look something like 00080001 or 00070003, depending on the
> >> installed version.
> >>
> >> Note that I changed -DCPPU_ENV on the Mac from $(COMID) to $(COMNAME)
> >> for consistency with the dmake side.  It shouldn't make a difference in
> >> practice since both have the same value on the Mac.
> >>
> >> If things look good, then please try a build with this patch.
> >
> > I'm having problems applying these patches. :(
> > Can you add a new issue and attach all this as a text file.
>
> https://bz.apache.org/ooo/show_bug.cgi?id=127664
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Win64 port started, and how building 32 bit AOO on Win64 could break soon

[Damjan Jovanovic]

Hi

Now I prefer the idea of still continuing to support cross-building of
AOO32 on Win64. AOO64 would be built opt-in (at least for now), by passing
an --enable-win64 flag to ./configure that enables building AOO64 on Win64,
but without that flag the traditional AOO32 would still be cross-built.
This will make testing AOO64 by others easier, testing AOO32 by me easier,
and lead to less conflicts with other changes on affected build files.

I almost have a patch ready that does this, and when I commit it, I'll use
it to work on fixing the currently broken AOO32.

Damjan


On Mon, Mar 5, 2018 at 10:19 PM, Damjan Jovanovic <dam...@apache.org> wrote:

>
>
> On Mon, Mar 5, 2018 at 3:29 PM, Patricia Shanahan <p...@acm.org> wrote:
>
>>
>>
>> On 3/4/2018 11:27 PM, Damjan Jovanovic wrote:
>> ...
>>
>>> But there is a simple way to both keep the 64->32 bit building working
>>> while making the 64 bit changes in trunk, and still get the benefits of
>>> testing. The changes involved to enable the 64 bit build environment
>>> amount
>>> to 1 relatively small patch affecting only 5 files, and without this
>>> patch
>>> it will still build 32 bit binaries on 64 bit Windows. Thus this patch
>>> can
>>> be maintained out-of-tree while patching modules to build on Win64, and
>>> those building without this patch will end up automatically testing
>>> whether
>>> any of the (small and relatively safe) module changes broke the Win32
>>> build.
>>>
>> ...
>>
>> In general, I favor keeping things checked in, but in keep the patch that
>> breaks 64->32 in its own branch. The remaining changes can go in the trunk.
>>
>>
> The patch affects 4 files and is only 254 lines long in total, so I've
> just placed it into main/solenv/win64/win64.patch together with a readme
> file referring people to the wiki page (https://wiki.openoffice.org/
> wiki/Win64_port) where I've described how to apply it and start the Win64
> build.
>
>
>

Re: Openoffice and unsupported gstreamer 0.10 branch (for openoffice libavmediagst.so library)

[Damjan Jovanovic]

Thank you. The video plays, but in a separate window instead of being
embedded in the document. I'll continue trying.

Distributing the library separately from the rest of AOO would be
difficult. Binary compatibility between Ubuntu and Gentoo, bitness, trunk
vs 4.1.5. New UNO components also have to be registered in AOO somehow; I
only know how to do it with .component files at compile time.

It will likely only end up in SVN trunk, possibly version 4.2.0.


On Thu, Mar 1, 2018 at 2:01 AM, Torokhov Sergey <torokhov-...@yandex.ru>
wrote:

> Hello,
>
> I created simple presentation file with title and video frame
> ("Agent 237:operation barbershop" from Blender Animation Studio).
>
> https://yadi.sk/d/shOKuCcS3StDk
>
> The archive contains 327.odp and 327.webm files that must be placed in
> the same directory before presentation file .odp is opening.
>
> The video is playing automatically after pressing F5 key (fullscreen
> presentation mode). Or after pressing "Play" button on the bar that
> usually appears at the bottom then video-frame of presentation is
> selected.
> I't work for me in current Apache OpenOffice 4.1.5 and
> gstreamer-plugins:0.10.
>
> As I use Gentoo I installed "gst-plugins-meta:0.10" with next options:
>
> USE="ffmpeg quicktime http wavpack dv dvb vcd musepack vpx oss libass
> lame theora v4l" emerge gst-plugins-meta:0.10
>
> Also I installed "gst-plugins-ivorbis:0.10" and
> "gst-plugins-pango:0.10".
>
>
> Could you also share rebuilded library for testing? Is it compatible
> with current AOO 4.1.5 build?
>
> Thank yo in advance.
>
> --
> Sergey
>
>
>
> On Wed, 28 Feb 2018 19:56:42 +0200
> Damjan Jovanovic <dam...@apache.org> wrote:
>
> > I've successfully patched our gstreamer plugin to build with
> > gstreamer-1.0, but how do I test it? Does someone have a sample
> > document that uses gstreamer?
> >
> > The patch is attached for anyone interested. Parts may still be
> > wrong, eg. filter names. Changes between GStreamer 0.1 and 1.0 are
> > documented here:
> > https://gstreamer.freedesktop.org/documentation/application-
> development/appendix/porting-1-0.html
> > https://cgit.freedesktop.org/gstreamer/gstreamer/plain/
> docs/random/porting-to-1.0.txt
> >
> >
> >
> > On Wed, Feb 28, 2018 at 10:22 AM, Damjan Jovanovic <dam...@apache.org>
> > wrote:
> >
> > > Hi
> > >
> > > I've begun having a look.
> > >
> > > We currently test for gstreamer in configure.ac but don't use the
> > > result, re-running pkg-config in a main/avmedia's makefile.
> > >
> > > Changing the version number to 1.0 breaks the build due a missing
> > > header file. Removing that "#include" gets it a little further, but
> > > it breaks due to changed gstreamer API functions. There is also
> > > lots of warnings about deprecated GDK functions. I'll continue
> > > trying later.
> > >
> > > We should really get rid of gstreamer 0.1 ASAP one way or the
> > > other: given how it's been unmaintained since 2013, it may well
> > > have security vulnerabilities. We can't ship it to users since its
> > > license is incompatible, but having users install it separately
> > > still invites trouble.
> > >
> > > Damjan
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Openoffice and unsupported gstreamer 0.10 branch (for openoffice libavmediagst.so library)

[Damjan Jovanovic]

Unfortunately it looks like the problem is harder than just getting it to
build. Even after fixing some more APIs and getting it to play, a separate
player window is created. To get the player window to embed like it should,
we need to set the X window id on the GstVideoOverlay using
gst_video_overlay_set_window_handle() when a "prepare-window-handle" event
is delivered for which gst_is_video_overlay_prepare_window_handle_message()
returns true. But for some mysterious reason
gst_is_video_overlay_prepare_window_handle_message() never returns true.
Forcefully setting the X window id on all events does get it to embed,
badly, with lots of warnings, and the window gets distorted when scrolling
and doesn't respond to mouse clicks .

Damjan


On Thu, Mar 1, 2018 at 4:53 AM, Damjan Jovanovic <dam...@apache.org> wrote:

> Thank you. The video plays, but in a separate window instead of being
> embedded in the document. I'll continue trying.
>
> Distributing the library separately from the rest of AOO would be
> difficult. Binary compatibility between Ubuntu and Gentoo, bitness, trunk
> vs 4.1.5. New UNO components also have to be registered in AOO somehow; I
> only know how to do it with .component files at compile time.
>
> It will likely only end up in SVN trunk, possibly version 4.2.0.
>
>
> On Thu, Mar 1, 2018 at 2:01 AM, Torokhov Sergey <torokhov-...@yandex.ru>
> wrote:
>
>> Hello,
>>
>> I created simple presentation file with title and video frame
>> ("Agent 237:operation barbershop" from Blender Animation Studio).
>>
>> https://yadi.sk/d/shOKuCcS3StDk
>>
>> The archive contains 327.odp and 327.webm files that must be placed in
>> the same directory before presentation file .odp is opening.
>>
>> The video is playing automatically after pressing F5 key (fullscreen
>> presentation mode). Or after pressing "Play" button on the bar that
>> usually appears at the bottom then video-frame of presentation is
>> selected.
>> I't work for me in current Apache OpenOffice 4.1.5 and
>> gstreamer-plugins:0.10.
>>
>> As I use Gentoo I installed "gst-plugins-meta:0.10" with next options:
>>
>> USE="ffmpeg quicktime http wavpack dv dvb vcd musepack vpx oss libass
>> lame theora v4l" emerge gst-plugins-meta:0.10
>>
>> Also I installed "gst-plugins-ivorbis:0.10" and
>> "gst-plugins-pango:0.10".
>>
>>
>> Could you also share rebuilded library for testing? Is it compatible
>> with current AOO 4.1.5 build?
>>
>> Thank yo in advance.
>>
>> --
>> Sergey
>>
>>
>>
>> On Wed, 28 Feb 2018 19:56:42 +0200
>> Damjan Jovanovic <dam...@apache.org> wrote:
>>
>> > I've successfully patched our gstreamer plugin to build with
>> > gstreamer-1.0, but how do I test it? Does someone have a sample
>> > document that uses gstreamer?
>> >
>> > The patch is attached for anyone interested. Parts may still be
>> > wrong, eg. filter names. Changes between GStreamer 0.1 and 1.0 are
>> > documented here:
>> > https://gstreamer.freedesktop.org/documentation/application-
>> development/appendix/porting-1-0.html
>> > https://cgit.freedesktop.org/gstreamer/gstreamer/plain/docs/
>> random/porting-to-1.0.txt
>> >
>> >
>> >
>> > On Wed, Feb 28, 2018 at 10:22 AM, Damjan Jovanovic <dam...@apache.org>
>> > wrote:
>> >
>> > > Hi
>> > >
>> > > I've begun having a look.
>> > >
>> > > We currently test for gstreamer in configure.ac but don't use the
>> > > result, re-running pkg-config in a main/avmedia's makefile.
>> > >
>> > > Changing the version number to 1.0 breaks the build due a missing
>> > > header file. Removing that "#include" gets it a little further, but
>> > > it breaks due to changed gstreamer API functions. There is also
>> > > lots of warnings about deprecated GDK functions. I'll continue
>> > > trying later.
>> > >
>> > > We should really get rid of gstreamer 0.1 ASAP one way or the
>> > > other: given how it's been unmaintained since 2013, it may well
>> > > have security vulnerabilities. We can't ship it to users since its
>> > > license is incompatible, but having users install it separately
>> > > still invites trouble.
>> > >
>> > > Damjan
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>

Re: Win64 port started, and how building 32 bit AOO on Win64 could break soon

[Damjan Jovanovic]

Hi

Thank you.

Fiddling with the main/cppuhelper/source/makefile.mk to reintroduce the map
file while keeping the other changes did not help, so it doesn't seem like
a case of exporting a symbol that wasn't exported before.

I've reverted all the changes to main/cppuhelper in r1826602 while I
investigate further. This should hopefully get AOO building again.

Oddly I think only the Windows build was affected by this.

Damjan


On Sun, Mar 11, 2018 at 10:01 PM, Matthias Seidel <
matthias.sei...@hamburg.de> wrote:

> Hi Damjan,
>
> Maybe you already have seen it (buildbot revision 1826428):
>
> "ERROR: error 65280 occurred while making
> /cygdrive/e/slave14/aoo-win7/build/main/svtools/prj"
>
> https://ci.apache.org/projects/openoffice/buildlogs/
> win/main/svtools/wntmsci12.pro/misc/logs/prj.txt
>
> Regards,
>
>Matthias
>
>
> Am 10.03.2018 um 19:18 schrieb Matthias Seidel:
> > Hi Damjan,
> >
> > I think your last commit [1] breaks the Win32 build:
> >
> > "ERROR: error 65280 occurred while making
> > /cygdrive/c/Source/aoo/main/cppuhelper/source" in my local build.
> >
> > See a more detailed log from our buildbot:
> >
> > https://ci.apache.org/projects/openoffice/buildlogs/
> win/main/cppuhelper/wntmsci12.pro/misc/logs/source.txt
> >
> > Regards,
> >
> >   Matthias
> >
> > [1] https://svn.apache.org/viewvc?view=revision=1826398
> >
> >
> > Am 05.03.2018 um 21:19 schrieb Damjan Jovanovic:
> >> On Mon, Mar 5, 2018 at 3:29 PM, Patricia Shanahan <p...@acm.org> wrote:
> >>
> >>> On 3/4/2018 11:27 PM, Damjan Jovanovic wrote:
> >>> ...
> >>>
> >>>> But there is a simple way to both keep the 64->32 bit building working
> >>>> while making the 64 bit changes in trunk, and still get the benefits
> of
> >>>> testing. The changes involved to enable the 64 bit build environment
> >>>> amount
> >>>> to 1 relatively small patch affecting only 5 files, and without this
> patch
> >>>> it will still build 32 bit binaries on 64 bit Windows. Thus this
> patch can
> >>>> be maintained out-of-tree while patching modules to build on Win64,
> and
> >>>> those building without this patch will end up automatically testing
> >>>> whether
> >>>> any of the (small and relatively safe) module changes broke the Win32
> >>>> build.
> >>>>
> >>> ...
> >>>
> >>> In general, I favor keeping things checked in, but in keep the patch
> that
> >>> breaks 64->32 in its own branch. The remaining changes can go in the
> trunk.
> >>>
> >>>
> >> The patch affects 4 files and is only 254 lines long in total, so I've
> just
> >> placed it into main/solenv/win64/win64.patch together with a readme file
> >> referring people to the wiki page (
> >> https://wiki.openoffice.org/wiki/Win64_port) where I've described how
> to
> >> apply it and start the Win64 build.
> >>
> >
>
>
>

Re: Win64 port started, and how building 32 bit AOO on Win64 could break soon

[Damjan Jovanovic]

I've added back the deleted map file I forgot to revert, and have forced a
rebuild on the Windows bot.

On Tue, Mar 13, 2018 at 3:52 PM, Matthias Seidel <matthias.sei...@hamburg.de
> wrote:

> Am 13.03.2018 um 04:19 schrieb Damjan Jovanovic:
> > Hi
> >
> > Thank you.
> >
> > Fiddling with the main/cppuhelper/source/makefile.mk to reintroduce the
> map
> > file while keeping the other changes did not help, so it doesn't seem
> like
> > a case of exporting a symbol that wasn't exported before.
> >
> > I've reverted all the changes to main/cppuhelper in r1826602 while I
> > investigate further. This should hopefully get AOO building again.
>
> Unfortunately not:
>
> ERROR: error 65280 occurred while making
> /cygdrive/e/slave14/aoo-win7/build/main/cppuhelper/source
>
> https://ci.apache.org/projects/openoffice/buildlogs/
> win/main/svtools/wntmsci12.pro/misc/logs/prj.txt
>
> >
> > Oddly I think only the Windows build was affected by this.
>
> Yes, it seems to be Windows only.
>
> Regards,
>Matthias
>
> >
> > Damjan
> >
> >
> > On Sun, Mar 11, 2018 at 10:01 PM, Matthias Seidel <
> > matthias.sei...@hamburg.de> wrote:
> >
> >> Hi Damjan,
> >>
> >> Maybe you already have seen it (buildbot revision 1826428):
> >>
> >> "ERROR: error 65280 occurred while making
> >> /cygdrive/e/slave14/aoo-win7/build/main/svtools/prj"
> >>
> >> https://ci.apache.org/projects/openoffice/buildlogs/
> >> win/main/svtools/wntmsci12.pro/misc/logs/prj.txt
> >>
> >> Regards,
> >>
> >>Matthias
> >>
> >>
> >> Am 10.03.2018 um 19:18 schrieb Matthias Seidel:
> >>> Hi Damjan,
> >>>
> >>> I think your last commit [1] breaks the Win32 build:
> >>>
> >>> "ERROR: error 65280 occurred while making
> >>> /cygdrive/c/Source/aoo/main/cppuhelper/source" in my local build.
> >>>
> >>> See a more detailed log from our buildbot:
> >>>
> >>> https://ci.apache.org/projects/openoffice/buildlogs/
> >> win/main/cppuhelper/wntmsci12.pro/misc/logs/source.txt
> >>> Regards,
> >>>
> >>>   Matthias
> >>>
> >>> [1] https://svn.apache.org/viewvc?view=revision=1826398
> >>>
> >>>
> >>> Am 05.03.2018 um 21:19 schrieb Damjan Jovanovic:
> >>>> On Mon, Mar 5, 2018 at 3:29 PM, Patricia Shanahan <p...@acm.org>
> wrote:
> >>>>
> >>>>> On 3/4/2018 11:27 PM, Damjan Jovanovic wrote:
> >>>>> ...
> >>>>>
> >>>>>> But there is a simple way to both keep the 64->32 bit building
> working
> >>>>>> while making the 64 bit changes in trunk, and still get the benefits
> >> of
> >>>>>> testing. The changes involved to enable the 64 bit build environment
> >>>>>> amount
> >>>>>> to 1 relatively small patch affecting only 5 files, and without this
> >> patch
> >>>>>> it will still build 32 bit binaries on 64 bit Windows. Thus this
> >> patch can
> >>>>>> be maintained out-of-tree while patching modules to build on Win64,
> >> and
> >>>>>> those building without this patch will end up automatically testing
> >>>>>> whether
> >>>>>> any of the (small and relatively safe) module changes broke the
> Win32
> >>>>>> build.
> >>>>>>
> >>>>> ...
> >>>>>
> >>>>> In general, I favor keeping things checked in, but in keep the patch
> >> that
> >>>>> breaks 64->32 in its own branch. The remaining changes can go in the
> >> trunk.
> >>>>>
> >>>> The patch affects 4 files and is only 254 lines long in total, so I've
> >> just
> >>>> placed it into main/solenv/win64/win64.patch together with a readme
> file
> >>>> referring people to the wiki page (
> >>>> https://wiki.openoffice.org/wiki/Win64_port) where I've described how
> >> to
> >>>> apply it and start the Win64 build.
> >>>>
> >>
> >>
>
>
>

First steps in building with MSVC 14 / Visual Studio 2015

[Damjan Jovanovic]

Hi

I am not just working on the Win64 port, but also had a brief look at
building AOO with the newer MSVC 14 in Visual Studio 2015.

I used Cygwin64 but did a 32 bit AOO build. (You can do that now; my 64 bit
patches fixed the issues we had with Cygwin64 before.)

First step was patching oowintool to detect the new MSVC, by adding its
registry keys, but that wasn't sufficient and I had to use
--with-frame-home, --with-psdk-home, and co. I discovered I have different
MSVC registry keys for 32 bit and 64 bit; oowintool currently looks at the
current bitness keys first and on Cygwin64 falls back to 32 bit keys if
missing, but I think it needs to only look at keys in the AOO bitness.

Then oowintool is called to copy CRT files from MSVC, and needed more
patching copy the right files, with the new version numbers.

It turns out as of MSVC 14, Microsoft requires us link each binary with a
total of 4 C/C++ runtime libraries (https://docs.microsoft.com/en
-us/cpp/c-runtime-library/crt-library-features): the old MSVCRT.LIB which
has now become a CRT initialization library, the old MSVCPRT.LIB which
implements the C++ standard library, the new UCRT.LIB which is their new
C99 standard library, and the new VCRUNTIME.LIB which deals with exception
handling, RTTI and debugging. I guess the small mercy is that we would only
gain runtime dependencies on UCRTBASE.DLL and VCRUNTIME.DLL, the
other 2 are statically linked. I hacked our dmake makefiles to link with
the new libraries by default. We'll also need to update our installer to
install the redistributable versions of these DLLs.

It also turns out that there is now this new Windows development component,
the "Windows Kit" under C:\Program Files (x86)\Windows Kits\, that
you have to use, which contains the C standard header files and UCRT.LIB. I
had to hack SOLARINC and ILIB in my winenv.set.sh to add those, but we
should do that better somehow.

Anyway with those changes the build started. It successfully built a few
modules including ext_libraries/apr, then broke in main/solenv due to
PATH_MAX no longer existing in limits.h, but when I patched that, it
compiled and linked the solenv tools successfully. It broke further, in
ext_libraries/gtest, due to C++ template issues that don't seem easy to
fix. Maybe a newer version of Google Test would help; for now
--disable-unit-tests got me further, then it broke in main/python, which I
am now stuck at.

I don't think porting our code to use MSVC 14 will be that difficult. It
looks like just a few issues at the module level. Python may be hard to
fix, as it is fussy about the CRT libraries (the Python documentation says
it requires MSVCP90).

The patches need refinement before being committed. These "Windows Kits"
needs further research. Also would anyone be interested in helping?

Damjan

Re: Win64 port started, and how building 32 bit AOO on Win64 could break soon

[Damjan Jovanovic]

That's good :).

I tried to look at 127731, but in the process discovered a far worse issue:
https://bz.apache.org/ooo/show_bug.cgi?id=127732

Damjan


On Tue, Mar 13, 2018 at 11:15 PM, Matthias Seidel <
matthias.sei...@hamburg.de> wrote:

> Am 13.03.2018 um 17:54 schrieb Damjan Jovanovic:
> > I've added back the deleted map file I forgot to revert, and have forced
> a
> > rebuild on the Windows bot.
>
> Thanks!
> Looks good so far, my local build is far beyond the point where the
> error occurred. ;-)
>
> I know you are very busy at the moment, but could you have a quick look at:
> https://bz.apache.org/ooo/show_bug.cgi?id=127731
>
> Regards,
>Matthias
>
> > On Tue, Mar 13, 2018 at 3:52 PM, Matthias Seidel <
> matthias.sei...@hamburg.de
> >> wrote:
> >> Am 13.03.2018 um 04:19 schrieb Damjan Jovanovic:
> >>> Hi
> >>>
> >>> Thank you.
> >>>
> >>> Fiddling with the main/cppuhelper/source/makefile.mk to reintroduce
> the
> >> map
> >>> file while keeping the other changes did not help, so it doesn't seem
> >> like
> >>> a case of exporting a symbol that wasn't exported before.
> >>>
> >>> I've reverted all the changes to main/cppuhelper in r1826602 while I
> >>> investigate further. This should hopefully get AOO building again.
> >> Unfortunately not:
> >>
> >> ERROR: error 65280 occurred while making
> >> /cygdrive/e/slave14/aoo-win7/build/main/cppuhelper/source
> >>
> >> https://ci.apache.org/projects/openoffice/buildlogs/
> >> win/main/svtools/wntmsci12.pro/misc/logs/prj.txt
> >>
> >>> Oddly I think only the Windows build was affected by this.
> >> Yes, it seems to be Windows only.
> >>
> >> Regards,
> >>Matthias
> >>
> >>> Damjan
> >>>
> >>>
> >>> On Sun, Mar 11, 2018 at 10:01 PM, Matthias Seidel <
> >>> matthias.sei...@hamburg.de> wrote:
> >>>
> >>>> Hi Damjan,
> >>>>
> >>>> Maybe you already have seen it (buildbot revision 1826428):
> >>>>
> >>>> "ERROR: error 65280 occurred while making
> >>>> /cygdrive/e/slave14/aoo-win7/build/main/svtools/prj"
> >>>>
> >>>> https://ci.apache.org/projects/openoffice/buildlogs/
> >>>> win/main/svtools/wntmsci12.pro/misc/logs/prj.txt
> >>>>
> >>>> Regards,
> >>>>
> >>>>Matthias
> >>>>
> >>>>
> >>>> Am 10.03.2018 um 19:18 schrieb Matthias Seidel:
> >>>>> Hi Damjan,
> >>>>>
> >>>>> I think your last commit [1] breaks the Win32 build:
> >>>>>
> >>>>> "ERROR: error 65280 occurred while making
> >>>>> /cygdrive/c/Source/aoo/main/cppuhelper/source" in my local build.
> >>>>>
> >>>>> See a more detailed log from our buildbot:
> >>>>>
> >>>>> https://ci.apache.org/projects/openoffice/buildlogs/
> >>>> win/main/cppuhelper/wntmsci12.pro/misc/logs/source.txt
> >>>>> Regards,
> >>>>>
> >>>>>   Matthias
> >>>>>
> >>>>> [1] https://svn.apache.org/viewvc?view=revision=1826398
> >>>>>
> >>>>>
> >>>>> Am 05.03.2018 um 21:19 schrieb Damjan Jovanovic:
> >>>>>> On Mon, Mar 5, 2018 at 3:29 PM, Patricia Shanahan <p...@acm.org>
> >> wrote:
> >>>>>>> On 3/4/2018 11:27 PM, Damjan Jovanovic wrote:
> >>>>>>> ...
> >>>>>>>
> >>>>>>>> But there is a simple way to both keep the 64->32 bit building
> >> working
> >>>>>>>> while making the 64 bit changes in trunk, and still get the
> benefits
> >>>> of
> >>>>>>>> testing. The changes involved to enable the 64 bit build
> environment
> >>>>>>>> amount
> >>>>>>>> to 1 relatively small patch affecting only 5 files, and without
> this
> >>>> patch
> >>>>>>>> it will still build 32 bit binaries on 64 bit Windows. Thus this
> >>>> patch can
> >>>>>>>> be maintained out-of-tree while patching modules to build on
> Win64,
> >>>> and
> >>>>>>>> those building without this patch will end up automatically
> testing
> >>>>>>>> whether
> >>>>>>>> any of the (small and relatively safe) module changes broke the
> >> Win32
> >>>>>>>> build.
> >>>>>>>>
> >>>>>>> ...
> >>>>>>>
> >>>>>>> In general, I favor keeping things checked in, but in keep the
> patch
> >>>> that
> >>>>>>> breaks 64->32 in its own branch. The remaining changes can go in
> the
> >>>> trunk.
> >>>>>> The patch affects 4 files and is only 254 lines long in total, so
> I've
> >>>> just
> >>>>>> placed it into main/solenv/win64/win64.patch together with a readme
> >> file
> >>>>>> referring people to the wiki page (
> >>>>>> https://wiki.openoffice.org/wiki/Win64_port) where I've described
> how
> >>>> to
> >>>>>> apply it and start the Win64 build.
> >>>>>>
> >>>>
> >>
> >>
>
>
>

Re: OS/2 drag writer only issue

[Damjan Jovanovic]

Hi Yuri

I am not sure how AOO's implementation works, but I do have a lot of drag
and drop experience on Windows, X11, .NET and Java,
using/implementing/porting.

Examine the action and data flavor negotiations: move vs copy, rich text vs
plain text.

I know there are special data flavors for internal drag and drop which
short-circuit within AOO, data doesn't (fully?) travel through the
platform's drag and drop mechanism like it would to other applications.

Failing everything, trace through the code on the drop target and see where
it's getting rejected and why.

Good luck
Damjan

On Thu, Mar 15, 2018 at 5:48 PM, Yuri Dario  wrote:

> Hi,
>
> I have implemented d on OS/2 platform. The framework is almost
> complete and also basic operations are supported.
>
> I only face a very strange issue: while d works well for calc and
> calc to writer or writer to calc, it does not work from writer to
> writer.
>
> if I select a word in  a writer document I can't move it using d, I
> immediately get the rejectDrag() event immediately called. Dropping
> into a different writer window is ok.
>
> Ideas? I have no clue at all for this.
>
> thanks,
>
> Yuri
>
>
> --
> Bye,
>
> Yuri Dario
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Openoffice and unsupported gstreamer 0.10 branch (for openoffice libavmediagst.so library)

[Damjan Jovanovic]

I've made a preliminary patch that does run-time dynamic linking to the
GStreamer libraries, only linking to $(GTK_LIBS) at build time. This should
ultimately allow you to build on CentOS 6.

The patch is attached. It's pretty ugly: lots of GStreamer macros expand to
functions and thus had to be inlined and hacked to use our function
pointers. GStreamer clearly wasn't designed for run-time dynamic linking.
It builds but I haven't tested it and won't be able to for a while.

Currently, even though GStreamer libraries are not used during the build,
you still need GStreamer installed, so pkg-config can detect
$(GSTREAMER_CFLAGS) for the header files we need. Our configure.ac thus
needs some patching too. That can be an exercise for the reader ;).

Damjan


On Thu, Mar 15, 2018 at 9:09 AM, Peter kovacs <pe...@apache.org> wrote:

> +1
>
> Am 15. März 2018 03:22:20 MEZ schrieb Damjan Jovanovic <dam...@apache.org
> >:
> >If GStreamer is that problematic to obtain, we could import these 30
> >symbols that we use from it via run-time dynamic linking. That way we
> >don't
> >need the GStreamer libraries to link against at compile time, only the
> >header files:
> >
> >  DF *UND*0060
> >gst_video_overlay_get_type
> >  DF *UND*0196
> >gst_bus_set_sync_handler
> >  DF *UND*003b
> >gst_message_get_structure
> >  DF *UND*00b1
> >gst_element_query_duration
> >  DF *UND*0136
> >gst_pad_get_current_caps
> >  DF *UND*000a
> >gst_pipeline_get_bus
> >  DF *UND*007f
> >gst_bus_get_type
> >  DF *UND*0174
> >gst_object_unref
> >  DF *UND*00fc
> >gst_element_get_state
> >  DF *UND*00af
> >gst_pipeline_get_type
> >  DF *UND*00dc
> >gst_element_set_state
> >  DF *UND*00b4
> >gst_structure_has_field
> >  DF *UND*00da
> >gst_bus_have_pending
> >  DF *UND*00b1
> >gst_element_query_position
> >  DF *UND*002f
> >gst_structure_get_name
> >  DF *UND*0090
> >gst_structure_get_value
> >  DF *UND*00c2
> >gst_structure_get_int
> >  DF *UND*003e
> >gst_caps_get_size
> >  DF *UND*0059
> >gst_structure_nth_field_name
> >  DF *UND*003a
> >gst_is_video_overlay_prepare_window_handle_message
> >  DF *UND*00ca
> >gst_bin_get_type
> >  DF *UND*0365
> >gst_mini_object_unref
> >  DF *UND*00b4
> >gst_message_parse_error
> >  DF *UND*005f
> >gst_init
> >  DF *UND*00da
> >gst_bus_pop
> >  DF *UND*0065
> >gst_caps_get_structure
> >  DF *UND*00b4
> >gst_element_seek_simple
> >  DF *UND*01ea
> >gst_element_factory_make
> >0000  DF *UND*0148
> >gst_video_overlay_set_window_handle
> >  DF *UND*002f
> >gst_structure_n_fields
> >
> >We already do with ODBC for example, where we will link against either
> >iODBC or unixODBC depending on which is installed at run-time.
> >
> >
> >On Thu, Mar 15, 2018 at 12:17 AM, Andrea Pescetti <pesce...@apache.org>
> >wrote:
> >
> >> Damjan Jovanovic wrote:
> >>
> >>> GStreamer 1.0.0 requires glib 2.32.0.
> >>>
> >>
> >> CentOS 6 ships with glib (package name: glib2) 2.28 as per
> >> http://mirror.centos.org/centos/6/os/x86_64/Packages/
> >>
> >> So this is indeed an issue: we would need a distribution that ships
> >with
> >> glib >= 2.32 (without considering other possible dependencies at the
> >> moment) to build.
> >>
> >> On the other hand, we want something as old as possible since builds
> >done
> >>

Re: Openoffice and unsupported gstreamer 0.10 branch (for openoffice libavmediagst.so library)

[Damjan Jovanovic]

If GStreamer is that problematic to obtain, we could import these 30
symbols that we use from it via run-time dynamic linking. That way we don't
need the GStreamer libraries to link against at compile time, only the
header files:

  DF *UND*0060
gst_video_overlay_get_type
  DF *UND*0196
gst_bus_set_sync_handler
  DF *UND*003b
gst_message_get_structure
  DF *UND*00b1
gst_element_query_duration
  DF *UND*0136
gst_pad_get_current_caps
  DF *UND*000a
gst_pipeline_get_bus
  DF *UND*007f
gst_bus_get_type
  DF *UND*0174
gst_object_unref
  DF *UND*00fc
gst_element_get_state
  DF *UND*00af
gst_pipeline_get_type
  DF *UND*00dc
gst_element_set_state
  DF *UND*00b4
gst_structure_has_field
  DF *UND*00da
gst_bus_have_pending
  DF *UND*00b1
gst_element_query_position
  DF *UND*002f
gst_structure_get_name
  DF *UND*0090
gst_structure_get_value
  DF *UND*00c2
gst_structure_get_int
  DF *UND*003e
gst_caps_get_size
  DF *UND*0059
gst_structure_nth_field_name
  DF *UND*003a
gst_is_video_overlay_prepare_window_handle_message
  DF *UND*00ca
gst_bin_get_type
  DF *UND*0365
gst_mini_object_unref
  DF *UND*00b4
gst_message_parse_error
  DF *UND*005f  gst_init
  DF *UND*00da  gst_bus_pop
  DF *UND*0065
gst_caps_get_structure
  DF *UND*00b4
gst_element_seek_simple
  DF *UND*01ea
gst_element_factory_make
  DF *UND*0148
gst_video_overlay_set_window_handle
  DF *UND*002f
gst_structure_n_fields

We already do with ODBC for example, where we will link against either
iODBC or unixODBC depending on which is installed at run-time.


On Thu, Mar 15, 2018 at 12:17 AM, Andrea Pescetti <pesce...@apache.org>
wrote:

> Damjan Jovanovic wrote:
>
>> GStreamer 1.0.0 requires glib 2.32.0.
>>
>
> CentOS 6 ships with glib (package name: glib2) 2.28 as per
> http://mirror.centos.org/centos/6/os/x86_64/Packages/
>
> So this is indeed an issue: we would need a distribution that ships with
> glib >= 2.32 (without considering other possible dependencies at the
> moment) to build.
>
> On the other hand, we want something as old as possible since builds done
> with too recent versions of glibc (not to confuse with the above, and set
> at 2.12 in CentOS 6) won't work for users of old Linux-based systems.
>
>
> Regards,
>   Andrea.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: gstreamer

[Damjan Jovanovic]

I thought the "external download dependency" you were talking about, meant
distribution of GStreamer with an AOO release, which is not allowed.

Building against GStreamer header files, and then only linking to the
GStreamer libraries on the end user's system, if present, sounds allowed
("Can Apache projects rely on components under prohibited licenses" on
https://www.apache.org/legal/resolved.html)



On Wed, Mar 14, 2018 at 7:22 PM, Jim Jagielski <j...@jagunet.com> wrote:

> All this was discussed in:
>
>  https://lists.apache.org/thread.html/83231a4ff938cdd14c19a01d4ae4f8
> d185ff7a94e0fc7d47a3b1b7f6@%3Cdev.openoffice.apache.org%3E
>
> I don't recall you bringing all this up there.
>
> > On Mar 14, 2018, at 12:03 PM, Damjan Jovanovic <dam...@apache.org>
> wrote:
> >
> > Why? The licence for GStreamer is LGPL, which is Category X.
> >
> > Damjan
> >
> >
> > On Wed, Mar 14, 2018 at 4:25 PM, Jim Jagielski <j...@jagunet.com> wrote:
> >
> >> I think there was general consensus to make gstreamer
> >> a external download dependency. As of this date, this
> >> has not yet been folded in. Who can take point on that?
> >>
> >> -
> >> 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: Openoffice and unsupported gstreamer 0.10 branch (for openoffice libavmediagst.so library)

[Damjan Jovanovic]

GStreamer 1.0.0 requires glib 2.32.0.

Regards
Damjan

On Wed, Mar 14, 2018 at 8:27 PM, Andrea Pescetti 
wrote:

> Jim Jagielski wrote:
>
>> Either we make gstreamer 1.0 an external download dependency,
>> so we can continue to build on CentOS6, or else we decide that
>> we switch to Ubuntu as our "official" build platform for our
>> community releases.
>>
>
> Can we define the problem better?
>
> I assume the gstreamer license hasn't changed. So the licensing issues
> holds the same whether we use 0.10 or 1.x.
>
> On CentOS 5 we used to install it in the system as described here:
> https://wiki.openoffice.org/wiki/Documentation/Building_Guid
> e_AOO/Step_by_step#CentOS_5_for_AOO_4.1.x
> (packages gstreamer-devel and gstreamer-plugins-base-devel)
>
> CentOS 6 indeed still ships with 0.10
> http://mirror.centos.org/centos/6/os/x86_64/Packages/
> and it seems that EPEL (a semi-official extra repository with additional
> packages) does not ship it either.
>
> The reason for using CentOS 6 is "we use a Linux system that is old enough
> for any user system to be the same or more recent"; this is to prevent
> glibc conflicts.
>
> So the real question is: does gstreamer 1.0 (or its dependencies) require
> a glibc version that is higher than 2.12 (as found in CentOS 6), or other
> dependencies that have the same problem? Otherwise we can probably look
> into building it.
>
> Regards,
>   Andrea.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: gstreamer

[Damjan Jovanovic]

Why? The licence for GStreamer is LGPL, which is Category X.

Damjan


On Wed, Mar 14, 2018 at 4:25 PM, Jim Jagielski  wrote:

> I think there was general consensus to make gstreamer
> a external download dependency. As of this date, this
> has not yet been folded in. Who can take point on that?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Minimum Ant version is now 1.9.1

[Damjan Jovanovic]

I've also updated our Java policy wiki page with the new requirements:
https://wiki.openoffice.org/wiki/Policies/Java_Usage

On Tue, Apr 10, 2018 at 1:20 PM, Matthias Seidel <matthias.sei...@hamburg.de
> wrote:

> Hi,
>
> Maybe we should set:
>
>   ant_minver=1.7.0
>
> in main/configure.ac to the new minimum version?
>
> Regards,
>
>Matthias
>
>
> Am 08.04.2018 um 14:59 schrieb Damjan Jovanovic:
> > Hi
> >
> > In porting main/jurt to gbuild in commits 1828636 and 1828638, I've ended
> > up doing considerable development in Ant, adding the ability to call IDL
> > tools (idlc, regmerge, javamaker) from Ant, and with the features I've
> > used, the minimum Ant version is now 1.9.1.
> >
> > Please let me know if you have any problems.
> >
> > Regards
> > Damjan
> >
>
>
>

Minimum Ant version is now 1.9.1

[Damjan Jovanovic]

Hi

In porting main/jurt to gbuild in commits 1828636 and 1828638, I've ended
up doing considerable development in Ant, adding the ability to call IDL
tools (idlc, regmerge, javamaker) from Ant, and with the features I've
used, the minimum Ant version is now 1.9.1.

Please let me know if you have any problems.

Regards
Damjan

Re: buildbot failure in on openoffice-linux64-nightly

[Damjan Jovanovic]

Thank you. Windows worked for me too, probably because I used
--without-junit and skipped the tests that way.

In 1828829 I committed a check for whether tests are present before trying
to compile them. I think it should fix this problem.

On Tue, Apr 10, 2018 at 4:31 PM, Matthias Seidel  wrote:

> This time it seems to be Linux failing, while Windows builds fine...
>
> 1 module(s):
>   ridljar
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making 
> /home/buildslave/slave/openoffice-linux64-nightly/build/main/ridljar/prj
>
>
>
>  Weitergeleitete Nachricht 
> Betreff: buildbot failure in on openoffice-linux64-nightly
> Datum: Tue, 10 Apr 2018 11:01:59 +
> Von: build...@apache.org
> Antwort an: dev@openoffice.apache.org
> An: comm...@openoffice.apache.org
>
> The Buildbot has detected a new failure on builder openoffice-linux64-nightly 
> while building . Full details are available at:
> https://ci.apache.org/builders/openoffice-linux64-nightly/builds/414
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: bb_slave4_ubuntu
>
> Build Reason: forced: by IRC user  (privmsg): None
> Build Source Stamp: HEAD
> Blamelist:
>
> BUILD FAILED: failed build --all
>
> Sincerely,
>  -The Buildbot
>
>
>
>
>

Re: buildbot failure in on openoffice-linux64-nightly

[Damjan Jovanovic]

On Tue, Apr 10, 2018 at 6:24 PM, Matthias Seidel <matthias.sei...@hamburg.de
> wrote:

> Am 10.04.2018 um 18:02 schrieb Damjan Jovanovic:
> > Thank you. Windows worked for me too, probably because I used
> > --without-junit and skipped the tests that way.
>
> That is also in my configure...
> (Should it be enabled?)
>

If you want the Java unit tests to run, then enable JUnit.

Unit tests should always run, IMO. Testing during the build catches
problems as early as possible, and isolates bugs at a much finer level than
integration tests and graphical tests.


>
> >
> > In 1828829 I committed a check for whether tests are present before
> trying
> > to compile them. I think it should fix this problem.
>
> Great!
>

Thank you :).

Re: buildbot failure in on openoffice-linux64-nightly

[Damjan Jovanovic]

Am I the only one seeing the Windows build crash on startup? :(

On Tue, Apr 10, 2018 at 7:03 PM, Matthias Seidel <matthias.sei...@hamburg.de
> wrote:

> Am 10.04.2018 um 18:58 schrieb Damjan Jovanovic:
> > On Tue, Apr 10, 2018 at 6:24 PM, Matthias Seidel <
> matthias.sei...@hamburg.de
> >> wrote:
> >> Am 10.04.2018 um 18:02 schrieb Damjan Jovanovic:
> >>> Thank you. Windows worked for me too, probably because I used
> >>> --without-junit and skipped the tests that way.
> >> That is also in my configure...
> >> (Should it be enabled?)
> >>
> > If you want the Java unit tests to run, then enable JUnit.
> >
> > Unit tests should always run, IMO. Testing during the build catches
> > problems as early as possible, and isolates bugs at a much finer level
> than
> > integration tests and graphical tests.
>
> Makes sense!
> I will now enable it for my test builds...
>
> For release versions we built without it.
>
> >
> >
> >>> In 1828829 I committed a check for whether tests are present before
> >> trying
> >>> to compile them. I think it should fix this problem.
> >> Great!
> >>
> > Thank you :).
>
> Buildbot is running right now. ;-)
>
> >
>
>
>

Re: gbuild migration (Was: Re: Building module store error on macOS)

[Damjan Jovanovic]

Thank you, I appreciate it.

The list of gbuild modules is in main/Module_ooo.mk. The rest are using
dmake. The next one I expect to port is main/jurt, and that will be a
substantial patch.

Will our release process keep testing trunk until it's ready, then make a
branch of it to use for the release?

If necessary I can work on modules offline or in another branch, then
commit or merge them back when the release is over.


On Wed, Apr 4, 2018 at 3:06 PM, Jim Jagielski  wrote:

>
>
> > On Apr 4, 2018, at 9:01 AM, Jim Jagielski  wrote:
> >
> >
> > I will start another thread on the gbuild topic...
> >
>
> First and foremost, I am incredibly impressed with the work
> being done on the gbuild migration. I really am.
>
> However, and there's always a "however", there must come
> a time where we "hold the line" on migration in hopes of getting
> a 4.2.0 out. As such, I think some sort of plan might be due
> (and apologies if we have such a documented plan already
> in place)...
>
> Does it make sense to spend time to list modules that still
> need that migration and then prioritize them? As well as
> create a policy such that all "new and updated" modules
> must use gbuild but for existing modules, "if it ain't broke,
> don't fix it"?
>
> I'm not trying to stifle the migration, it's just that it appears
> to me that we need better management about it.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

SVN trunk: Windows build crashes on startup

[Damjan Jovanovic]

Hi

First I thought it was a patch I was developing, but even with a clean
rebuild, the Windows binaries reproducibly crash during startup.

It's not a debug build so I can't debug further.

Can anyone provide the SVN revision of a Windows build that works for them,
so I have a starting point for a regression test?

Damjan

Re: Time to push on for 4.2.0

[Damjan Jovanovic]

I think it would take about 2 weeks for the most essential items.

But sadly my Windows build is crashing on startup and my FreeBSD build is
crashing during the build in main/offapi due to some kind of memory bug in
idlc (either due to changes in FreeBSD or corruption of my system files),
so sadly I first need a few days to investigate and possibly reinstall my
setups.

I'll keep you updated.



On Thu, Apr 12, 2018 at 4:11 PM, Jim Jagielski <j...@jagunet.com> wrote:

> +1 from me. After the below would be a good time to create
> the 4.2.0-dev branch from trunk.
>
> Do you have a timeframe for the below?
>
> > On Apr 10, 2018, at 9:26 PM, Damjan Jovanovic <dam...@apache.org> wrote:
> >
> > Hi
> >
> > Before we start on 4.2.0 I would like to finish off porting one final
> > module, main/jvmfwk, to gbuild. Then I'll take a break from the build
> > changes, and would like to contribute these improvements:
> >
> > * Overhaul our Java support. Support newer Java versions. Enhance Java
> > detection on *nix, adding OpenJDK and matching on prefixes (like openjdk*
> > for FreeBSD, eg. /usr/local/openjdk7, /usr/local/openjdk8) instead of
> fixed
> > strings such as "jdk". Look in /usr/lib too on 64 bit Linux instead of
> the
> > RedHat-only /usr/lib64. Accelerate Java autodetection by resolving
> symbolic
> > links and caching results to avoid the slowness of multiple unnecessary
> > checks of the same Java directory through different symlinks.
> > * GStreamer 0.1 and 1.0.
> > * Audit the new SDBC-JDBC bridge and ensure it's 100% compatible with the
> > old one.
> > * Library naming and symbol versioning audit of all libraries against
> 4.1.x.
> > * Run all tests against 4.1.x and trunk, and fix the regressions.
> > * Full PostgreSQL support (views, indexes, users, groups, GUI dialogs) if
> > there is time.
> > * Get the Mediawiki plugin working again, if there is time.
> >
> >
> > On Tue, Apr 10, 2018 at 2:54 PM, Jim Jagielski <j...@jagunet.com> wrote:
> >
> >> We have still not yet made any strategic determination... We have
> >> a possible scenario where gstreamer can be built regardless of
> >> what version the build system has in place, but, afaict, that has
> >> not yet been folded in.
> >>
> >> My suggestion would be that that gets committed ASAP so we
> >> can test it. We then svn copy trunk to a AOO420 branch and
> >> start focusing on getting a 4.2.0 GA release out.
> >>
> >> -
> >> 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
>
>

Upstreaming FreeBSD ports patches before 4.2.0?

[Damjan Jovanovic]

Hi

Can we please upstream the patches from FreeBSD ports, before the 4.2.0
release?

That idlc memory alignment SIGBUS crash from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216206 is Clang specific,
not FreeBSD specific, and could happen on other operating systems.

Thank you
Damjan

Re: Time to push on for 4.2.0

[Damjan Jovanovic]

Hi

Before we start on 4.2.0 I would like to finish off porting one final
module, main/jvmfwk, to gbuild. Then I'll take a break from the build
changes, and would like to contribute these improvements:

* Overhaul our Java support. Support newer Java versions. Enhance Java
detection on *nix, adding OpenJDK and matching on prefixes (like openjdk*
for FreeBSD, eg. /usr/local/openjdk7, /usr/local/openjdk8) instead of fixed
strings such as "jdk". Look in /usr/lib too on 64 bit Linux instead of the
RedHat-only /usr/lib64. Accelerate Java autodetection by resolving symbolic
links and caching results to avoid the slowness of multiple unnecessary
checks of the same Java directory through different symlinks.
* GStreamer 0.1 and 1.0.
* Audit the new SDBC-JDBC bridge and ensure it's 100% compatible with the
old one.
* Library naming and symbol versioning audit of all libraries against 4.1.x.
* Run all tests against 4.1.x and trunk, and fix the regressions.
* Full PostgreSQL support (views, indexes, users, groups, GUI dialogs) if
there is time.
* Get the Mediawiki plugin working again, if there is time.


On Tue, Apr 10, 2018 at 2:54 PM, Jim Jagielski  wrote:

> We have still not yet made any strategic determination... We have
> a possible scenario where gstreamer can be built regardless of
> what version the build system has in place, but, afaict, that has
> not yet been folded in.
>
> My suggestion would be that that gets committed ASAP so we
> can test it. We then svn copy trunk to a AOO420 branch and
> start focusing on getting a 4.2.0 GA release out.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>