Re: Branch scons-build and PR #82

2021-09-08 Thread Damjan Jovanovic
Hi Arrigo

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

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

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

Damjan

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

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


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

2021-07-28 Thread Damjan Jovanovic
On Tue, Jul 27, 2021 at 10:21 PM Arrigo Marchiori 
wrote:

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

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

Good luck
Damjan


epm 5 not compiling on FreeBSD 13

2021-07-07 Thread Damjan Jovanovic
Hi

On FreeBSD 13.0 the epm module doesn't compile:

=
Building module epm
=

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

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

Stop.





There is no "relnumber" in epm.h:

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


Any ideas?
Damjan


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

2021-06-16 Thread Damjan Jovanovic
On Thu, Jun 17, 2021 at 1:34 AM Don Lewis  wrote:

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


Re: OpenOffice for Amazon Linux in aarch64 architecture

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

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

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

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

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

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


Damjan


Re: [discussion] future embedded DB in AOO

2020-12-07 Thread Damjan Jovanovic
On Mon, Dec 7, 2020 at 8:38 PM Peter Kovacs  wrote:

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

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

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

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

Damjan


Re: Help w/ bt

2020-12-03 Thread Damjan Jovanovic
Well done!

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

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

Re: Help w/ bt

2020-12-02 Thread Damjan Jovanovic
That's in main/soltools.

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

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

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

Re: Help w/ bt

2020-12-02 Thread Damjan Jovanovic
On Wed, Dec 2, 2020 at 3:35 PM Jim Jagielski  wrote:

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

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

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

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

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

Damjan


Re: [OPINION VOTE] CentOS7 or Ubuntu 14.04

2020-11-10 Thread Damjan Jovanovic
On Tue, Nov 10, 2020 at 7:58 PM Jim Jagielski  wrote:

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

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

Damjan


Re: QA Automated Test coverage

2020-10-27 Thread Damjan Jovanovic
On Sat, Oct 24, 2020 at 8:14 PM Carl Marcum  wrote:

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

Thank you for helping with the tests.

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

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

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

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

Damjan


Re: Apache Python Project

2020-10-27 Thread Damjan Jovanovic
Hi Kent

Welcome to Apache OpenOffice.

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

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

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

Regards
Damjan


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

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


Re: Writer and .docx

2020-10-17 Thread Damjan Jovanovic
On Sun, Oct 18, 2020 at 4:13 AM Dave Fisher  wrote:

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

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


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


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



> Regards,
> Dave
>
>
Regards
Damjan


Re: Writer and .docx

2020-10-17 Thread Damjan Jovanovic
On Fri, Oct 16, 2020 at 11:50 AM Bidouille  wrote:

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


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

2020-10-17 Thread Damjan Jovanovic
Hi

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

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

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

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

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

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

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

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


Re: Writer and .docx

2020-10-16 Thread Damjan Jovanovic
On Fri, Oct 16, 2020 at 4:24 PM Carl Marcum  wrote:

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

Re: Writer and .docx

2020-10-16 Thread Damjan Jovanovic
On Fri, Oct 16, 2020 at 2:05 PM Dave Fisher  wrote:

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

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

There were several major problems with using POI.

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

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

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

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

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

Regards
Damjan


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

2020-10-05 Thread Damjan Jovanovic
On Mon, Oct 5, 2020 at 8:08 AM Don Lewis  wrote:

> On  5 Oct, dam...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > damjan pushed a commit to branch trunk
> > in repository https://gitbox.apache.org/repos/asf/openoffice.git
> >
> >
> > The following commit(s) were added to refs/heads/trunk by this push:
> >  new 9b7130f  It seems we need YYDEBUG to compile main/connectivity
> now.
> > 9b7130f is described below
>
> I haven't seen that here on either Linux or Windows.
>
>
>
Possibly only happens with my --enable-dbgutil --enable-symbols or other
flags.


Re: UNO knowledge

2020-09-12 Thread Damjan Jovanovic
Hi Patricia

Please elaborate?

Which bug?


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

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


Re: file serialization entry point

2020-07-29 Thread Damjan Jovanovic
On Thu, Jul 30, 2020 at 2:30 AM Kira Tsu  wrote:

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

Hi

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

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

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

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

All the best
Damjan


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

2020-07-26 Thread Damjan Jovanovic
Hi

Thank you.

I've been testing them, they work.

Regards
Damjan


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

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


Re: Our OpenGrok server

2020-07-18 Thread Damjan Jovanovic
Can you please also see if we can set tab size to 4 spaces?

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

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


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

2020-07-05 Thread Damjan Jovanovic
On Sun, Jul 5, 2020 at 7:27 AM Peter  wrote:

> Awesome Damjan,
>
>
Thank you :)


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

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



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

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


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


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


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

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

2020-07-04 Thread Damjan Jovanovic
scripting is a dmake module with no symbols
package is a gbuild module with symbols

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

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

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

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

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

2020-07-04 Thread Damjan Jovanovic
Given how I've only developed on FreeBSD so far, anything Windows is
probably at negative infinity :).

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

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

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

Automated gbuild -> SCons convertibility now at 88.57%

2020-07-04 Thread Damjan Jovanovic
Hi

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

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

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

Where does this leave us?

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

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

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

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

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

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

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

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

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

Damjan


Re: Small regression in trunk

2020-05-18 Thread Damjan Jovanovic
On Mon, May 18, 2020 at 9:41 AM Matthias Seidel 
wrote:

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

Damjan


Re: Small regression in trunk

2020-05-11 Thread Damjan Jovanovic
On Mon, May 11, 2020 at 5:25 PM Matthias Seidel 
wrote:

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

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

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

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

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

BUILDS

Build updates by: me


Re: Remove of STAX and SAXON

2020-04-26 Thread Damjan Jovanovic
On Sun, Apr 26, 2020 at 7:30 AM Peter Kovacs  wrote:

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

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


Re: harmful code??

2020-04-25 Thread Damjan Jovanovic
On Sat, Apr 25, 2020 at 2:11 PM Peter Kovacs  wrote:

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

Re: drop ressources (stlport, maybe beanshell)

2020-04-25 Thread Damjan Jovanovic
On Sat, Apr 25, 2020 at 3:50 AM Peter Kovacs  wrote:

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


Re: Issue in vbahelper

2020-04-23 Thread Damjan Jovanovic
On Fri, Apr 24, 2020 at 5:18 AM Peter Kovacs  wrote:

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

Damjan


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

2020-04-15 Thread Damjan Jovanovic
On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:

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

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


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

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

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

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

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

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

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

Damjan


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

2020-04-15 Thread Damjan Jovanovic
On Wed, Apr 15, 2020 at 6:46 AM Peter Kovacs  wrote:

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

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


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

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

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

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


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

You've also done some scons development.

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


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

Re: Version Numbers in source code

2020-03-15 Thread Damjan Jovanovic
Hi

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

Damjan


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

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


Re: setting scons up for linux

2020-02-29 Thread Damjan Jovanovic
That's really great :).

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

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

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

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


Re: setting scons up for linux

2020-02-27 Thread Damjan Jovanovic
You need a recent Python 3:
ImportError: cannot import name ABC:

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

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


Re: Building On CentOS 8 Dependency Help

2020-02-17 Thread Damjan Jovanovic
On Sat, Feb 15, 2020 at 4:14 PM Carl Marcum  wrote:

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

We moved to 1.0 a year ago:

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

Use gstreamer 1.0 instead of the long obsolete
version 0.1.


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

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


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

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

Damjan


Re: Updated 4.2.0 build?

2020-02-16 Thread Damjan Jovanovic
On Mon, Feb 17, 2020 at 1:59 AM Andrea Pescetti  wrote:

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


Re: gotoSCons: automated gbuild to SCons conversion

2020-02-09 Thread Damjan Jovanovic
On Sun, Feb 9, 2020 at 11:47 AM Peter Kovacs  wrote:

> Sounds nice.
>
> Thank you.

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

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

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

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


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


> All the best
> Peter
>
>
Damjan


Re: gotoSCons: automated gbuild to SCons conversion

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

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

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

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

Re: gotoSCons: automated gbuild to SCons conversion

2020-02-01 Thread Damjan Jovanovic
Hi

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

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

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

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

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

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

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

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



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

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

gotoSCons: automated gbuild to SCons conversion

2020-02-01 Thread Damjan Jovanovic
Hi

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

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

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

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

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

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

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

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

Regards
Damjan


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

2020-01-31 Thread Damjan Jovanovic
On Fri, Jan 31, 2020 at 6:00 PM Pedro Lino  wrote:

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

Damjan


Re: System-provided Python 3 support now committed

2020-01-25 Thread Damjan Jovanovic
On Sat, Jan 25, 2020 at 1:38 PM Matthias Seidel 
wrote:

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


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

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

:

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

with the code involved being:

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

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




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


System-provided Python 3 support now committed

2020-01-25 Thread Damjan Jovanovic
Hi

With Python 2 EOL as of 1 January 2020, we have little choice but to move
to Python 3.

After a lot of hard work by me and Pedro, both of us relatively unfamiliar
with Python, I am happy to report that using a system-provided Python 3 in
Apache OpenOffice now works.

The UNO/Python bridge and the Python script provider have been patched to
support both Python 2 and 3, and all 3 sample Python macros that ship with
AOO work with Python 3 too. More extensive testing (eg. main/pyuno/demo)
has not been performed, but isn't in the build anyway and might be broken
with Python 2 as well.

It certainly works on FreeBSD and probably on Linux, please test other
platforms.

As I said only system-provided Python 3 works as this stage. Building an
internal Python 3, as is required on Windows, does not work yet, and is
extremely difficult to implement, as Python 3 requires a new Windows
Platform SDK with MSVC >= 14 in order to build, which will probably lead to
numerous build-related changes to all modules. This does need to happen at
some stage anyway though.

Also as per https://bz.apache.org/ooo/show_bug.cgi?id=123975#c9
we also need to release AOO 5.0 (a new major release) for an incompatible
change of this nature.

Along the way, I also looked at what it would take to improve the Python
macro dialog, which never allowed creating, renaming, deleting or editing
Python scripts, only running them (and to add them to an .odt file, you
have to edit the ZIP file and add them manually). There are at least 3
separate implementations of scripting providers: the StarBasic one, the
Java one (used for Java, BeanShell and Rhino (Javascript)), and the Python
one. It's the Python one in main/scripting/source/pyprov/pythonscript.py
that is missing features. By comparing it against the Java provider I
managed to patch DirBrowseNode to implement XPropertySet and add a
getPropertyValue() method which checks for the "Creatable" property and
returns true, and this enables the (otherwise grayed out) "Create" button
in the dialog, but then to implement the "Creatable" action in invoke()
when the button is clicked seems rather difficult, and requires a low-level
understanding of script URLs and content brokers and various other
infrastructure.

Damjan


Re: code comments and doxygen

2019-11-18 Thread Damjan Jovanovic
On Mon, Nov 18, 2019 at 10:58 PM Peter Kovacs 
wrote:

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

main/autodoc and so on?

Damjan


Re: C++ standard when building OpenOffice

2019-11-05 Thread Damjan Jovanovic
On Tue, Nov 5, 2019 at 10:05 PM Don Lewis  wrote:

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


Re: [DISCUSSION] Build environment future

2019-11-04 Thread Damjan Jovanovic
Hi

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

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

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

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

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

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



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

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


Re: C++ standard when building OpenOffice

2019-11-03 Thread Damjan Jovanovic
On Mon, Nov 4, 2019 at 3:49 AM Branko Čibej  wrote:

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

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


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

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

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

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


Re: C++ standard when building OpenOffice

2019-11-03 Thread Damjan Jovanovic
Thank you for the info. I haven't had good experiences with Boost in my
Win64 attempts either...

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

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

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


Re: New computer

2019-10-30 Thread Damjan Jovanovic
On Wed, Oct 30, 2019 at 6:16 PM Patricia Shanahan  wrote:

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

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


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

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

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

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

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

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

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

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

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

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

Re: New computer

2019-10-30 Thread Damjan Jovanovic
What do you already know? SVN?

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

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


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

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


Re: 4.2.0-dev next?

2019-10-24 Thread Damjan Jovanovic
On Fri, Oct 25, 2019 at 1:00 AM Marcus  wrote:

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


Re: OpenGrok

2019-10-18 Thread Damjan Jovanovic
Thank you so much!

It works well.


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

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


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

2019-10-04 Thread Damjan Jovanovic
On Fri, Oct 4, 2019 at 6:47 PM Don Lewis  wrote:

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

Some other downstream module probably needs them.


Re: leftover debug?

2019-10-01 Thread Damjan Jovanovic
Please delete it.

Thank you
Damjan


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

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


Re: OpenJDK (8u222) not listed in AOO 4.1.6?

2019-08-24 Thread Damjan Jovanovic
Hi

I've done that in commit 61a4f434029376f30410cf27dbdd93c1f6011f21

Regards
Damjan


On Sat, Aug 24, 2019 at 1:32 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Maybe it would be possible to only overwrite those JDKs with vendor
> "private build" by "OpenJDK"?
>
> This would be a workaround for 4.1.7 and we could further improve it for
> the next release.
>
> Regards,
>
>    Matthias
>
>
> Am 20.08.19 um 03:58 schrieb Damjan Jovanovic:
> > On Sun, Aug 18, 2019 at 9:30 PM Matthias Seidel <
> matthias.sei...@hamburg.de>
> > wrote:
> >
> >> Thanks!
> >>
> >> Am 18.08.19 um 20:26 schrieb Damjan Jovanovic:
> >>> That's great news. Thank you for testing.
> >>>
> >>> I am busy so it will take me a few days to finalize the patch and
> commit
> >> it.
> >>
> >> Looking forward to your commit. I will then cherry-pick it for AOO42X
> >> and AOO417.
> >>
> >>
> > It's actually quite a difficult issue to fix properly.
> >
> > The vendor name is used in the user interface. The current hack of
> > overwriting it with "Oracle Corporation" hides the real vendor in the UI,
> > so we shouldn't do that.
> >
> > The whole jvmfwk API uses the vendor as an identifier. We have to change
> > identification. This could affect the public API for that module.
> >
> > The vendor is expected to match our list of vendors, to the point where
> (if
> > I understand correctly) jvmfwk searches for Java by first reading our
> known
> > Java vendors, and then searching for each one, so the search logic also
> has
> > to change.
> >
> > I'll have to understand the internals of that module in detail.
> >
>
>


Re: OpenJDK (8u222) not listed in AOO 4.1.6?

2019-08-19 Thread Damjan Jovanovic
On Sun, Aug 18, 2019 at 9:30 PM Matthias Seidel 
wrote:

> Thanks!
>
> Am 18.08.19 um 20:26 schrieb Damjan Jovanovic:
> > That's great news. Thank you for testing.
> >
> > I am busy so it will take me a few days to finalize the patch and commit
> it.
>
> Looking forward to your commit. I will then cherry-pick it for AOO42X
> and AOO417.
>
>
It's actually quite a difficult issue to fix properly.

The vendor name is used in the user interface. The current hack of
overwriting it with "Oracle Corporation" hides the real vendor in the UI,
so we shouldn't do that.

The whole jvmfwk API uses the vendor as an identifier. We have to change
identification. This could affect the public API for that module.

The vendor is expected to match our list of vendors, to the point where (if
I understand correctly) jvmfwk searches for Java by first reading our known
Java vendors, and then searching for each one, so the search logic also has
to change.

I'll have to understand the internals of that module in detail.


Re: OpenJDK (8u222) not listed in AOO 4.1.6?

2019-08-18 Thread Damjan Jovanovic
That's great news. Thank you for testing.

I am busy so it will take me a few days to finalize the patch and commit it.



On Sun, Aug 18, 2019 at 6:49 PM Mechtilde  wrote:

> Hello Damjan,
>
> I applied the patch and build it under Debian 9. The DEBs I got, worked
> under Debian 11.
>
> The detection of Java 8u222, Java 11.0.4 and Java 12.0.2 works. Java
> means OpnJDK which is shipped with Debian.
>
> The German builds I published under
>
> /home/mechtilde/public_html/NewBuild
>
> Thanks to Damjan.
>
> Mechtilde
>
> Am 18.08.19 um 12:00 schrieb Damjan Jovanovic:
> > The attached patch starts to get it working. It should detect Java >=
> 8u222
> > but will wrongly label it "Oracle Corporation", as I haven't dug into the
> > main/jvmfwk/plugins/sunmajor/pluginlib/vendorbase.cxx file yet, which
> does
> > another vendor search.
> >
> > Please test it on Java 11 if you can, as the java.vendor property change
> > may be the problem there as well. After all, the patch to 8u222 was just
> a
> > backport from some future Java version, so it definitely isn't the only
> > version this patch fixes.
> >
> > I also wonder if the entire framework for detecting Java needs to be
> > rethought, given how much the Java ecosystem has changed since the Kaffe
> /
> > GCJ / GNU Classpath days.
> >
> > Regards
> > Damjan
> >
> >
> >
> > On Sun, Aug 18, 2019 at 11:29 AM Mechtilde  wrote:
> >
> >> Hello Damjan,
> >>
> >> I figured it out under Debian >= 9 with Java 8u222.
> >>
> >> We need also a solution to detect java 11 which is used in Debian 10
> >> (buster, stable)
> >>
> >> Am 18.08.19 um 10:45 schrieb Matthias Seidel:
> >>> Hi Damjan,
> >>>
> >>> Thank you for looking into it!
> >>>
> >>> Indeed it was Ubuntu 16.04 where I could replicate the problem with
> >>> OpenJDK8u222.
> >>>
> >>> Am 18.08.19 um 03:06 schrieb Damjan Jovanovic:
> >>>> Before:
> >>>> java.vendor=Oracle Corporation
> >>>>
> >>>> After:
> >>>> java.vendor=Private Build
> >>>>
> >>>> This is apparently something Java now allows configuring when it's
> >> built:
> >>>> https://bugs.openjdk.java.net/browse/JDK-8221171
> >>>> http://hg.openjdk.java.net/jdk8u/jdk8u/rev/e0b7721459ee
> >>>>
> >>>> We probably need to relax the vendor checks, as we'll soon be flooded
> by
> >>>> different java.vendor properties on different platforms, as different
> >>>> package repositories begin setting their own...
> >>>
> >>> Definitely!
> >>>
> >>> I have this changelog for Ubuntu:
> >>>
> >>>
> >>
> https://launchpadlibrarian.net/435284148/openjdk-8_8u212-b03-0ubuntu1.19.04.2_8u222-b10-1ubuntu1~19.04.1.diff.gz
> >>>
> >>> Searching for --with-vendor-name gives several results.
> >>>
> >>> Regards,
> >>>
> >>>Matthias
> >>>
> >>>>
> >>>> On Sun, Aug 18, 2019 at 2:39 AM Damjan Jovanovic 
> >> wrote:
> >>>>
> >>>>> Found 8u222 on Ubuntu 16.04, testing...
> >>>>>
> >>>>> On Sun, Aug 18, 2019 at 2:32 AM Damjan Jovanovic 
> >>>>> wrote:
> >>>>>
> >>>>>> 8.202.8 and 8.212.4.1 work for me on FreeBSD.
> >>>>>>
> >>>>>> Let me see if I can find 8u222 somewhere.
> >>>>>>
> >>>>>> On Sat, Aug 17, 2019 at 6:23 PM Matthias Seidel <
> >>>>>> matthias.sei...@hamburg.de> wrote:
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> If nobody can confirm this it must be an error on every
> installation
> >>>>>>> that I run...
> >>>>>>>
> >>>>>>> Otherwise it would be a release blocker for 4.1.7!
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>>Matthias
> >>>>>>>
> >>>>>>>
> >>>>>>> Am 14.08.19 um 16:37 schrieb Matthias Seidel:
> >>>>>>>> Hi Damjan,
> >>>>>>>>
> >>>>>>>> A

Re: OpenJDK (8u222) not listed in AOO 4.1.6?

2019-08-18 Thread Damjan Jovanovic
The attached patch starts to get it working. It should detect Java >= 8u222
but will wrongly label it "Oracle Corporation", as I haven't dug into the
main/jvmfwk/plugins/sunmajor/pluginlib/vendorbase.cxx file yet, which does
another vendor search.

Please test it on Java 11 if you can, as the java.vendor property change
may be the problem there as well. After all, the patch to 8u222 was just a
backport from some future Java version, so it definitely isn't the only
version this patch fixes.

I also wonder if the entire framework for detecting Java needs to be
rethought, given how much the Java ecosystem has changed since the Kaffe /
GCJ / GNU Classpath days.

Regards
Damjan



On Sun, Aug 18, 2019 at 11:29 AM Mechtilde  wrote:

> Hello Damjan,
>
> I figured it out under Debian >= 9 with Java 8u222.
>
> We need also a solution to detect java 11 which is used in Debian 10
> (buster, stable)
>
> Am 18.08.19 um 10:45 schrieb Matthias Seidel:
> > Hi Damjan,
> >
> > Thank you for looking into it!
> >
> > Indeed it was Ubuntu 16.04 where I could replicate the problem with
> > OpenJDK8u222.
> >
> > Am 18.08.19 um 03:06 schrieb Damjan Jovanovic:
> >> Before:
> >> java.vendor=Oracle Corporation
> >>
> >> After:
> >> java.vendor=Private Build
> >>
> >> This is apparently something Java now allows configuring when it's
> built:
> >> https://bugs.openjdk.java.net/browse/JDK-8221171
> >> http://hg.openjdk.java.net/jdk8u/jdk8u/rev/e0b7721459ee
> >>
> >> We probably need to relax the vendor checks, as we'll soon be flooded by
> >> different java.vendor properties on different platforms, as different
> >> package repositories begin setting their own...
> >
> > Definitely!
> >
> > I have this changelog for Ubuntu:
> >
> >
> https://launchpadlibrarian.net/435284148/openjdk-8_8u212-b03-0ubuntu1.19.04.2_8u222-b10-1ubuntu1~19.04.1.diff.gz
> >
> > Searching for --with-vendor-name gives several results.
> >
> > Regards,
> >
> >Matthias
> >
> >>
> >> On Sun, Aug 18, 2019 at 2:39 AM Damjan Jovanovic 
> wrote:
> >>
> >>> Found 8u222 on Ubuntu 16.04, testing...
> >>>
> >>> On Sun, Aug 18, 2019 at 2:32 AM Damjan Jovanovic 
> >>> wrote:
> >>>
> >>>> 8.202.8 and 8.212.4.1 work for me on FreeBSD.
> >>>>
> >>>> Let me see if I can find 8u222 somewhere.
> >>>>
> >>>> On Sat, Aug 17, 2019 at 6:23 PM Matthias Seidel <
> >>>> matthias.sei...@hamburg.de> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> If nobody can confirm this it must be an error on every installation
> >>>>> that I run...
> >>>>>
> >>>>> Otherwise it would be a release blocker for 4.1.7!
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>>Matthias
> >>>>>
> >>>>>
> >>>>> Am 14.08.19 um 16:37 schrieb Matthias Seidel:
> >>>>>> Hi Damjan,
> >>>>>>
> >>>>>> Am 14.08.19 um 07:02 schrieb Damjan Jovanovic:
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> What does "java --version" give?
> >>>>>> openjdk version "1.8.0_222"
> >>>>>> OpenJDK Runtime Environment (build
> >>>>> 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
> >>>>>> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
> >>>>>>
> >>>>>>> You might need to backport the following commit to 4.1.x:
> >>>>>>>
> >>>>>>> commit 3bd2d6aed629c4323ea9e8426acfb793eb9046fd
> >>>>>>> Author: Damjan Jovanovic 
> >>>>>>> Date:   Sun Apr 15 15:00:46 2018 +
> >>>>>>>
> >>>>>>> Allow the Java version suffix (eg. the 162 in 1.8.0_162) to be
> >>>>>>> 3 digits long.
> >>>>>>>
> >>>>>>> Patch by: me
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> git-svn-id:
> >>>>> https://svn.apache.org/repos/asf/openoffice/trunk@1829211
> >>>>>>> 13f79535-47bb-0310-9956-ffa450edef68
> >>>>>> Just to clari

Re: OpenJDK (8u222) not listed in AOO 4.1.6?

2019-08-17 Thread Damjan Jovanovic
Before:
java.vendor=Oracle Corporation

After:
java.vendor=Private Build

This is apparently something Java now allows configuring when it's built:
https://bugs.openjdk.java.net/browse/JDK-8221171
http://hg.openjdk.java.net/jdk8u/jdk8u/rev/e0b7721459ee

We probably need to relax the vendor checks, as we'll soon be flooded by
different java.vendor properties on different platforms, as different
package repositories begin setting their own...


On Sun, Aug 18, 2019 at 2:39 AM Damjan Jovanovic  wrote:

> Found 8u222 on Ubuntu 16.04, testing...
>
> On Sun, Aug 18, 2019 at 2:32 AM Damjan Jovanovic 
> wrote:
>
>> 8.202.8 and 8.212.4.1 work for me on FreeBSD.
>>
>> Let me see if I can find 8u222 somewhere.
>>
>> On Sat, Aug 17, 2019 at 6:23 PM Matthias Seidel <
>> matthias.sei...@hamburg.de> wrote:
>>
>>> Hi all,
>>>
>>> If nobody can confirm this it must be an error on every installation
>>> that I run...
>>>
>>> Otherwise it would be a release blocker for 4.1.7!
>>>
>>> Regards,
>>>
>>>Matthias
>>>
>>>
>>> Am 14.08.19 um 16:37 schrieb Matthias Seidel:
>>> > Hi Damjan,
>>> >
>>> > Am 14.08.19 um 07:02 schrieb Damjan Jovanovic:
>>> >> Hi
>>> >>
>>> >> What does "java --version" give?
>>> > openjdk version "1.8.0_222"
>>> > OpenJDK Runtime Environment (build
>>> 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
>>> > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
>>> >
>>> >> You might need to backport the following commit to 4.1.x:
>>> >>
>>> >> commit 3bd2d6aed629c4323ea9e8426acfb793eb9046fd
>>> >> Author: Damjan Jovanovic 
>>> >> Date:   Sun Apr 15 15:00:46 2018 +
>>> >>
>>> >> Allow the Java version suffix (eg. the 162 in 1.8.0_162) to be
>>> >> 3 digits long.
>>> >>
>>> >> Patch by: me
>>> >>
>>> >>
>>> >>
>>> >> git-svn-id:
>>> https://svn.apache.org/repos/asf/openoffice/trunk@1829211
>>> >> 13f79535-47bb-0310-9956-ffa450edef68
>>> > Just to clarify:
>>> >
>>> > This also happens with AOO 4.2.0 (I installed Jims last build from July
>>> > on Xubuntu).
>>> > I really think that there was a change in the Java update 8u222.
>>> >
>>> > Regards,
>>> >
>>> >Matthias
>>> >
>>> >> On Tue, Aug 13, 2019 at 11:19 PM Matthias Seidel <
>>> matthias.sei...@hamburg.de>
>>> >> wrote:
>>> >>
>>> >>> Hi all,
>>> >>>
>>> >>> Today I noticed that on my Ubuntu machine OpenJDK 8u222 isn't listed
>>> in
>>> >>> AOO (4.1.6) anymore.
>>> >>> But everything works, it seems to be detected and to be used, that is
>>> >>> why I didn't notice it earlier.
>>> >>>
>>> >>> I do remember that I got the update from Java 8u212 to Java 8u222
>>> some
>>> >>> time ago.
>>> >>>
>>> >>> In my test VM with Ubuntu (32-bit) which has still Java 8u212
>>> installed
>>> >>> it is visible in AOO.
>>> >>>
>>> >>> Can anyone confirm this?
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>>Matthias
>>> >>>
>>> >>>
>>> >>>
>>>
>>>


Re: OpenJDK (8u222) not listed in AOO 4.1.6?

2019-08-17 Thread Damjan Jovanovic
Found 8u222 on Ubuntu 16.04, testing...

On Sun, Aug 18, 2019 at 2:32 AM Damjan Jovanovic  wrote:

> 8.202.8 and 8.212.4.1 work for me on FreeBSD.
>
> Let me see if I can find 8u222 somewhere.
>
> On Sat, Aug 17, 2019 at 6:23 PM Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
>
>> Hi all,
>>
>> If nobody can confirm this it must be an error on every installation
>> that I run...
>>
>> Otherwise it would be a release blocker for 4.1.7!
>>
>> Regards,
>>
>>Matthias
>>
>>
>> Am 14.08.19 um 16:37 schrieb Matthias Seidel:
>> > Hi Damjan,
>> >
>> > Am 14.08.19 um 07:02 schrieb Damjan Jovanovic:
>> >> Hi
>> >>
>> >> What does "java --version" give?
>> > openjdk version "1.8.0_222"
>> > OpenJDK Runtime Environment (build
>> 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
>> > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
>> >
>> >> You might need to backport the following commit to 4.1.x:
>> >>
>> >> commit 3bd2d6aed629c4323ea9e8426acfb793eb9046fd
>> >> Author: Damjan Jovanovic 
>> >> Date:   Sun Apr 15 15:00:46 2018 +
>> >>
>> >> Allow the Java version suffix (eg. the 162 in 1.8.0_162) to be
>> >> 3 digits long.
>> >>
>> >> Patch by: me
>> >>
>> >>
>> >>
>> >> git-svn-id:
>> https://svn.apache.org/repos/asf/openoffice/trunk@1829211
>> >> 13f79535-47bb-0310-9956-ffa450edef68
>> > Just to clarify:
>> >
>> > This also happens with AOO 4.2.0 (I installed Jims last build from July
>> > on Xubuntu).
>> > I really think that there was a change in the Java update 8u222.
>> >
>> > Regards,
>> >
>> >Matthias
>> >
>> >> On Tue, Aug 13, 2019 at 11:19 PM Matthias Seidel <
>> matthias.sei...@hamburg.de>
>> >> wrote:
>> >>
>> >>> Hi all,
>> >>>
>> >>> Today I noticed that on my Ubuntu machine OpenJDK 8u222 isn't listed
>> in
>> >>> AOO (4.1.6) anymore.
>> >>> But everything works, it seems to be detected and to be used, that is
>> >>> why I didn't notice it earlier.
>> >>>
>> >>> I do remember that I got the update from Java 8u212 to Java 8u222 some
>> >>> time ago.
>> >>>
>> >>> In my test VM with Ubuntu (32-bit) which has still Java 8u212
>> installed
>> >>> it is visible in AOO.
>> >>>
>> >>> Can anyone confirm this?
>> >>>
>> >>> Regards,
>> >>>
>> >>>Matthias
>> >>>
>> >>>
>> >>>
>>
>>


Re: OpenJDK (8u222) not listed in AOO 4.1.6?

2019-08-17 Thread Damjan Jovanovic
8.202.8 and 8.212.4.1 work for me on FreeBSD.

Let me see if I can find 8u222 somewhere.

On Sat, Aug 17, 2019 at 6:23 PM Matthias Seidel 
wrote:

> Hi all,
>
> If nobody can confirm this it must be an error on every installation
> that I run...
>
> Otherwise it would be a release blocker for 4.1.7!
>
> Regards,
>
>Matthias
>
>
> Am 14.08.19 um 16:37 schrieb Matthias Seidel:
> > Hi Damjan,
> >
> > Am 14.08.19 um 07:02 schrieb Damjan Jovanovic:
> >> Hi
> >>
> >> What does "java --version" give?
> > openjdk version "1.8.0_222"
> > OpenJDK Runtime Environment (build
> 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
> > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
> >
> >> You might need to backport the following commit to 4.1.x:
> >>
> >> commit 3bd2d6aed629c4323ea9e8426acfb793eb9046fd
> >> Author: Damjan Jovanovic 
> >> Date:   Sun Apr 15 15:00:46 2018 +
> >>
> >> Allow the Java version suffix (eg. the 162 in 1.8.0_162) to be
> >> 3 digits long.
> >>
> >> Patch by: me
> >>
> >>
> >>
> >> git-svn-id:
> https://svn.apache.org/repos/asf/openoffice/trunk@1829211
> >> 13f79535-47bb-0310-9956-ffa450edef68
> > Just to clarify:
> >
> > This also happens with AOO 4.2.0 (I installed Jims last build from July
> > on Xubuntu).
> > I really think that there was a change in the Java update 8u222.
> >
> > Regards,
> >
> >Matthias
> >
> >> On Tue, Aug 13, 2019 at 11:19 PM Matthias Seidel <
> matthias.sei...@hamburg.de>
> >> wrote:
> >>
> >>> Hi all,
> >>>
> >>> Today I noticed that on my Ubuntu machine OpenJDK 8u222 isn't listed in
> >>> AOO (4.1.6) anymore.
> >>> But everything works, it seems to be detected and to be used, that is
> >>> why I didn't notice it earlier.
> >>>
> >>> I do remember that I got the update from Java 8u212 to Java 8u222 some
> >>> time ago.
> >>>
> >>> In my test VM with Ubuntu (32-bit) which has still Java 8u212 installed
> >>> it is visible in AOO.
> >>>
> >>> Can anyone confirm this?
> >>>
> >>> Regards,
> >>>
> >>>Matthias
> >>>
> >>>
> >>>
>
>


Re: OpenJDK (8u222) not listed in AOO 4.1.6?

2019-08-13 Thread Damjan Jovanovic
Hi

What does "java --version" give?

You might need to backport the following commit to 4.1.x:

commit 3bd2d6aed629c4323ea9e8426acfb793eb9046fd
Author: Damjan Jovanovic 
Date:   Sun Apr 15 15:00:46 2018 +

Allow the Java version suffix (eg. the 162 in 1.8.0_162) to be
3 digits long.

Patch by: me



git-svn-id: https://svn.apache.org/repos/asf/openoffice/trunk@1829211
13f79535-47bb-0310-9956-ffa450edef68

On Tue, Aug 13, 2019 at 11:19 PM Matthias Seidel 
wrote:

> Hi all,
>
> Today I noticed that on my Ubuntu machine OpenJDK 8u222 isn't listed in
> AOO (4.1.6) anymore.
> But everything works, it seems to be detected and to be used, that is
> why I didn't notice it earlier.
>
> I do remember that I got the update from Java 8u212 to Java 8u222 some
> time ago.
>
> In my test VM with Ubuntu (32-bit) which has still Java 8u212 installed
> it is visible in AOO.
>
> Can anyone confirm this?
>
> Regards,
>
>Matthias
>
>
>


Re: build issue with Rhino

2019-08-11 Thread Damjan Jovanovic
Our minimum Java version has been 1.7 for a while now.

Rhino's version is set in:
main/rhino//misc/build/rhino1_7R3/build.properties

Damjan

On Sun, Aug 11, 2019 at 10:03 PM Peter Kovacs  wrote:

> I have following Issue. Does anyone know what to do?
>
> Latest Version of Rhino is 1.7.9 we use 1.7.3 maybe I can work around by
> updating?
>
> Any advises?
>
> The Error Message I recieve:
>
> compile-most:
> [javac] Compiling 209 source files to
> /home/legine/workspace/ApacheOpenOffice/gitbox/main/rhino/
> unxlngx6.pro/misc/build/rhino1_7R3/build/classes
> [javac] warning: [options] bootstrap class path not set in
> conjunction with -source 5
> [javac] error: Source option 5 is no longer supported. Use 6 or later.
> [javac] error: Target option 1.5 is no longer supported. Use 1.6 or
> later.
>
> BUILD FAILED
> /home/legine/workspace/ApacheOpenOffice/gitbox/main/rhino/
> unxlngx6.pro/misc/build/rhino1_7R3/build.xml:75:
> The following error occurred while executing this line:
> /home/legine/workspace/ApacheOpenOffice/gitbox/main/rhino/
> unxlngx6.pro/misc/build/rhino1_7R3/src/build.xml:68:
> Compile failed; see the compiler error output for details.
>
>
>
> All the Best
>
> Peter
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: [resolution] svn migration plan

2019-08-03 Thread Damjan Jovanovic
On Sat, Aug 3, 2019 at 7:47 AM Peter Kovacs  wrote:

> Hello all,
>
> I have pushed Infra a bit. We are now migrating.
>
> So migration will be finished soon.
>
>
Excellent :).


>
> I suggest we use the short hash.
>
>
For what? Why can't we "git tag" relevant commits and use the tag instead?

Damjan


Re: Java 12 not recognized by AOO

2019-07-28 Thread Damjan Jovanovic
Thank you.

That's good news.

Sure, feel free to merge it to other branches. I've also added it to
https://wiki.openoffice.org/wiki/Building_old_versions

Regards
Damjan


On Sun, Jul 28, 2019 at 12:12 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Am 28.07.19 um 07:32 schrieb Damjan Jovanovic:
> > For AdoptOpenJDK it was config files and several .cxx files that register
> > Java implementations (we really should extract that from config files
> > instead).
> >
> > For Java 11/12 it was .cxx files that specify search paths for libjvm.so
> on
> > *nix. Yes, there may still be issues on Windows/Mac/etc.
>
> Well done!
>
> I can confirm that "OpenJDK8U-jre_x86-32_windows_hotspot_8u222b10" is
> detected on Windows with your latest changes!
>
> That should be merged to AOO42X and maybe it is a candidate for AOO417?
> Opinions?
>
> Regards,
>
>Matthias
>
> >
> > On Sun, Jul 28, 2019 at 5:31 AM Peter Kovacs  wrote:
> >
> >> Should we not move this stuff in some sort of config file?Is the
> >> information in the config file you edited?
> >>
> >> On 27.07.19 21:52, Damjan Jovanovic wrote:
> >>> Thank you.
> >>>
> >>> I've added the new paths in commit 1863883.
> >>>
> >>> Regards
> >>> Damjan
> >>>
> >>>
> >>> On Sat, Jul 27, 2019 at 8:39 PM Mechtilde  wrote:
> >>>
> >>>> Hello Damjan,
> >>>>
> >>>> here you can see the paths of the different Java versions fpr
> libjvm.so
> >>>> under Debian:
> >>>>
> >>>> /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so
> >>>> /usr/lib/jvm/java-12-openjdk-amd64/lib/server/libjvm.so
> >>>> /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so
> >>>>
> >>>> Kind regards
> >>>>
> >>>>
> >>>> Am 27.07.19 um 20:18 schrieb Damjan Jovanovic:
> >>>>> The problem with AdoptOpenJDK 11 is that it has a:
> >>>>> lib/server/libjvm.so
> >>>>> instead of the expected:
> >>>>> lib/amd64/server/libjvm.so
> >>>>>
> >>>>> Patching AOO to search the new path fixes the detection problem.
> >>>>>
> >>>>> Does OpenJDK 11 / Oracle JDK 11 have the same change in path? Those
> >>>> require
> >>>>> a different patch.
> >>>>>
> >>>>> Regards
> >>>>> Damjan
> >>>>>
> >>>> --
> >>>> Mechtilde Stehmann
> >>>> ## Apache OpenOffice
> >>>> ## Freie Office Suite für Linux, MacOSX, Windows
> >>>> ## Debian Developer
> >>>> ## PGP encryption welcome
> >>>> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
> >>>>
> >>>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
>


Re: Building AOO

2019-07-27 Thread Damjan Jovanovic
ifneq ($(BUILD_VER_STRING),)
$(eval $(call
gb_Library_add_defs,cui,-DBUILD_VER_STRING="$(BUILD_VER_STRING)"))
endif

Please try fiddle with that middle line. Maybe you need $$ instead of $
and/or {} instead of (), for the BUILD_VER_STRING variable.

Regards
Damjan

On Sun, Jul 28, 2019 at 6:24 AM Mechtilde  wrote:

> Hello,
>
> I started to build AOO like the release. I use all the options of
> configure as in
>
>
> https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.2.0-Dev1/?sortby=date
>
> The build breaks with
>
> /home/mechtilde/aoo42x/main/cui/Library_cui.mk:37: *** missing
> separator.  Stop.
> dmake:  Error code 2, while making 'all'
>
> 1 module(s):
> cui
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /home/mechtilde/aoo42x/main/cui/prj
>
> When you have fixed the errors in that module you can resume the build
> by running:
>
> build --all:cui
>
> I did a dmake clean
>
> Kind regards
>
> --
> Mechtilde Stehmann
> ## Apache OpenOffice
> ## Freie Office Suite für Linux, MacOSX, Windows
> ## Debian Developer
> ## PGP encryption welcome
> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
>
>


Re: Java 12 not recognized by AOO

2019-07-27 Thread Damjan Jovanovic
For AdoptOpenJDK it was config files and several .cxx files that register
Java implementations (we really should extract that from config files
instead).

For Java 11/12 it was .cxx files that specify search paths for libjvm.so on
*nix. Yes, there may still be issues on Windows/Mac/etc.

On Sun, Jul 28, 2019 at 5:31 AM Peter Kovacs  wrote:

> Should we not move this stuff in some sort of config file?Is the
> information in the config file you edited?
>
> On 27.07.19 21:52, Damjan Jovanovic wrote:
> > Thank you.
> >
> > I've added the new paths in commit 1863883.
> >
> > Regards
> > Damjan
> >
> >
> > On Sat, Jul 27, 2019 at 8:39 PM Mechtilde  wrote:
> >
> >> Hello Damjan,
> >>
> >> here you can see the paths of the different Java versions fpr libjvm.so
> >> under Debian:
> >>
> >> /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so
> >> /usr/lib/jvm/java-12-openjdk-amd64/lib/server/libjvm.so
> >> /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so
> >>
> >> Kind regards
> >>
> >>
> >> Am 27.07.19 um 20:18 schrieb Damjan Jovanovic:
> >>> The problem with AdoptOpenJDK 11 is that it has a:
> >>> lib/server/libjvm.so
> >>> instead of the expected:
> >>> lib/amd64/server/libjvm.so
> >>>
> >>> Patching AOO to search the new path fixes the detection problem.
> >>>
> >>> Does OpenJDK 11 / Oracle JDK 11 have the same change in path? Those
> >> require
> >>> a different patch.
> >>>
> >>> Regards
> >>> Damjan
> >>>
> >> --
> >> Mechtilde Stehmann
> >> ## Apache OpenOffice
> >> ## Freie Office Suite für Linux, MacOSX, Windows
> >> ## Debian Developer
> >> ## PGP encryption welcome
> >> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: Java 12 not recognized by AOO

2019-07-27 Thread Damjan Jovanovic
Thank you.

I've added the new paths in commit 1863883.

Regards
Damjan


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

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


Re: Java 12 not recognized by AOO

2019-07-27 Thread Damjan Jovanovic
The problem with AdoptOpenJDK 11 is that it has a:
lib/server/libjvm.so
instead of the expected:
lib/amd64/server/libjvm.so

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

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

Regards
Damjan

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

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


Re: Java 12 not recognized by AOO

2019-07-27 Thread Damjan Jovanovic
AdoptOpenJDK 11 isn't detected.

I am investigating.



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

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


Re: Java 12 not recognized by AOO

2019-07-27 Thread Damjan Jovanovic
Hi Mechtilde

No idea. I'll try AdoptOpenJDK 11 now.

Regards
Damjan


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

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


Re: SHA1/MD5 in sal/rtl/source/digest.c patch license able for OO

2019-07-27 Thread Damjan Jovanovic
If you read through the LO bug report, you'll see that there are many
patches for this bug, affecting multiple modules.

Why?

The historical files that are valid but have the wrong checksum due to
having been written by the broken [OO.org-derivative] implementations when
they were created, will still be accepted as valid by future versions of LO.

I think they have quite an involved bug fix, with new UI dialogs for those
cases, etc.

On Sat, Jul 27, 2019 at 9:50 AM Peter Kovacs  wrote:

> Hi Brane,
>
> This is a very nice Idea. Maybe even beyond the immediate idea on fixing
> the SHA implementation.
>
> Thanks a lot for this Idea.
>
>
> All the Best
>
> Peter
>
> On 26.07.19 12:36, Branko Čibej wrote:
> > On 25.07.2019 00:43, Peter Kovacs wrote:
> >> Hello all,
> >>
> >>
> >> I would like to ask if I or any other from OpenOffice Development team
> >> can port the patch from LibreOffice to OpenOffice to fix this Issue
> >> under the APL2 License, so the Issue can be fixed in OpenOffice without
> >> more work then necessary.
> >
> > Would it be appropriate to use the hash code from APR
> > (https://apr.apacha.org)? The license fits, and that code has been
> > stable and well tested for ages. But I'm not sure if it fits your FIPS
> > compliance requirements.
> >
> > -- Brane
> >
> > -
> > 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: Top 3 of urgent issues

2019-07-23 Thread Damjan Jovanovic
On Tue, Jul 23, 2019 at 9:20 PM Bidouille  wrote:

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

Regards
Damjan


Re: [discussion] svn migration plan

2019-07-20 Thread Damjan Jovanovic
That's a great idea, thank you!

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

Regards
Damjan

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

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


Re: ./configuration acrobatics.

2019-07-07 Thread Damjan Jovanovic
As stated on the bug report:


Possibly a regression
from:https://svn.apache.org/repos/asf/openoffice/trunk@1852965

Please keep the discussion there.

Damjan


On Sun, Jul 7, 2019 at 2:43 PM Peter Kovacs  wrote:

> Thanks Andrea for the pointer.
>
> It does not give any reasons for the option thought. I will check for
> more pointers in the commit logs.
>
> It does not give hints why it is still excluded even the branch does not
> exist in SVN. Hopefully i find something.
>
>
> I added the Thread to the wiki and added a description to stlport there.
> I hope I got it right.
>
> On 07.07.19 12:01, Andrea Pescetti wrote:
>
> > Peter Kovacs wrote:
> >> why do you use |--without-stlport \ on
> >>
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-buildflags|
> 
> >>
> >> |This does not make any sense
> >
> > Using --without-stlport has been the default for a long time if I
> > recall correctly. I think you can read this list's archives starting
> > from https://s.apache.org/u6w21 for some context. The commit logs may
> > have more information and better links.
> >
> > Regards,
> >   Andrea.
> >
> > -
> > 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: abp.component

2019-06-03 Thread Damjan Jovanovic
Pleasure.

Press Alt+Shift+Ctrl+D and turn off assertions. See also
https://wiki.openoffice.org/wiki/Debugging

On Tue, Jun 4, 2019 at 4:47 AM Ynjiun Paul Wang  wrote:

> Hi Damjan,
>
> Thank you for the hint. I build --all again and this time it works. (I
> guess I did ctrl-C in the middle of the build and resume it creating this
> problem.)
>
> Now I run the newly compiled soffice under
> installed/install/en/openoffice4/program and get a lot of assertion failed!
> The first one is at line 874 in main/vcl/unx/gtk/a11y/atkwrapper.cxx
>
> I wonder if this means I did not compile it correctly? Or I need to turn
> off these assertions? Any hint? Thanks a lot in advance.
>
> -Paul
>
> -----Original Message-
> From: Damjan Jovanovic [mailto:dam...@apache.org]
> Sent: Sunday, June 02, 2019 10:13 PM
> To: Apache OO
> Subject: Re: abp.component
>
> Hi
>
> It should be under main/extensions/source/abpilot/abp.component but I am
> not sure why it wasn't built and delivered.
>
> Try:
> build --from extensions
>
> Regards
> Damjan
>
>
>
> On Mon, Jun 3, 2019 at 6:08 AM Ynjiun Paul Wang  wrote:
>
> > Dear,
> >
> >
> >
> > I am new in development. Today I tried to compile the aoo first time. It
> > went well until it stop at:
> >
> >
> >
> > dmake:  Error: --
> > `/home/kevin/Bible/aoo/main/solver/450/unxlngx6/xml/abp.component' not
> > found, and can't be made
> >
> > checkdeliver.pl - checking delivered binaries
> >
> > dmake:  Error: --
> >
> >
> `/home/kevin/Bible/aoo/main/solver/450/unxlngx6/xml/registry/spool/fcfg_data
> > base_filters.xcu' not found, and can't be made
> >
> > OK
> >
> > ok.
> >
> >
> >
> > 1 module(s):
> >
> > postprocess
> >
> > need(s) to be rebuilt
> >
> >
> >
> > Reason(s):
> >
> >
> >
> > ERROR: error 65280 occurred while making
> > /home/kevin/Bible/aoo/main/postprocess/packcomponents
> >
> > ERROR: error 65280 occurred while making
> > /home/kevin/Bible/aoo/main/postprocess/packregistry
> >
> >
> >
> > When you have fixed the errors in that module you can resume the build by
> > running:
> >
> >
> >
> > build --from postprocess
> >
> >
> >
> > could you please point me to where to download abp.component?
> >
> >
> >
> > I am using Ubuntu 16.04 in VirtualBox for development.
> >
> >
> >
> > Thanks a lot.
> >
> >
> >
> > -Paul
> >
> >
> >
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: abp.component

2019-06-02 Thread Damjan Jovanovic
Hi

It should be under main/extensions/source/abpilot/abp.component but I am
not sure why it wasn't built and delivered.

Try:
build --from extensions

Regards
Damjan



On Mon, Jun 3, 2019 at 6:08 AM Ynjiun Paul Wang  wrote:

> Dear,
>
>
>
> I am new in development. Today I tried to compile the aoo first time. It
> went well until it stop at:
>
>
>
> dmake:  Error: --
> `/home/kevin/Bible/aoo/main/solver/450/unxlngx6/xml/abp.component' not
> found, and can't be made
>
> checkdeliver.pl - checking delivered binaries
>
> dmake:  Error: --
>
> `/home/kevin/Bible/aoo/main/solver/450/unxlngx6/xml/registry/spool/fcfg_data
> base_filters.xcu' not found, and can't be made
>
> OK
>
> ok.
>
>
>
> 1 module(s):
>
> postprocess
>
> need(s) to be rebuilt
>
>
>
> Reason(s):
>
>
>
> ERROR: error 65280 occurred while making
> /home/kevin/Bible/aoo/main/postprocess/packcomponents
>
> ERROR: error 65280 occurred while making
> /home/kevin/Bible/aoo/main/postprocess/packregistry
>
>
>
> When you have fixed the errors in that module you can resume the build by
> running:
>
>
>
> build --from postprocess
>
>
>
> could you please point me to where to download abp.component?
>
>
>
> I am using Ubuntu 16.04 in VirtualBox for development.
>
>
>
> Thanks a lot.
>
>
>
> -Paul
>
>
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>


Re: Build on Windows

2019-05-15 Thread Damjan Jovanovic
On Thu, May 16, 2019 at 4:45 AM Patricia Shanahan  wrote:

> "Install Microsoft Windows SDK for Windows 7 and .NET Framework 3.5. SP1
> (recommended by Microsoft. Note: later versions of the Windows SDK will
> not work. AOO can not be built with MSVC 2010 or 2012 - MSVC 2008 is
> needed and is found in the Windows 7 SDK)"
>
> Both the links given for installing the software get "download no longer
> available".
>
> Since I have built many times on the machine in question that download
> cannot be necessary. Since the instructions do not specify the files, it
> is difficult to search for them.
>
>
That isn't good at all.

My 13 March 2018 email entitled "First steps in building with MSVC 14 /
Visual Studio 2015" described some of the work involved in using newer MSVC
versions to build AOO. That "Windows Kit" needs better integration into the
build and packaging, but I think it will limit us to Windows 7 and later
(the irony being that the open-source mingw[-w64] toolchain, which only
links to the primordial MSVCRT.DLL, could let us support even Windows 9x).

Hopefully we can also simplify the current situation with the many MSVCR*
versions we use in the process.

Get started and I'll catch up in a few weeks when I am more free?

Damjan


Build broken by 1858940?

2019-05-10 Thread Damjan Jovanovic
Entering /path/to/openoffice/main/extras/source/misc_config

dmake:  Error: -- `wizard/web/styles/pc_old.css' not found, and can't be
made

1 module(s):
extras
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/path/to/openoffice/main/extras/source/misc_config

When you have fixed the errors in that module you can resume the build by
running:

build --from extras


Re: Java 12 not recognized by AOO

2019-05-10 Thread Damjan Jovanovic
On Fri, May 10, 2019 at 8:35 AM FR web forum  wrote:

> @Larry,
> Strange, the xml has kept many path locations.
> Could you rename this file (quit AOO before)?
> Run AOO that re-create a new javasettings file.
> Go back in Tools > Options > AOO > Java to see if jre 12 is here.
>
> > 
> >
> file:///Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre
> >
> file:///Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
> >
> file:///Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home
> >
> file:///Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> > 
>
>
The only way I solved a Java detection issue before is to step through the
code with a debugger, and carefully check values at every step.

See commit 1829211 for an example.

We really need to beef up Java detection urgently, as Oracle has started to
limit its Java to non-commercial use, and people are migrating to
AdoptOpenJDK which we don't detect properly, even for Java 8.


Re: svn commit: r1856677 - in /openoffice/trunk/main/tools: GoogleTest_tools_pathutils.mk Module_tools.mk qa/test_pathutils.cxx

2019-04-02 Thread Damjan Jovanovic
On Tue, Apr 2, 2019 at 3:24 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Just for clarification, these tests are done automatically while
> building unless I disable them explicitly with --disable-unit-tests?
>
> Regards,
>
>Matthias
>
>
That's right.

Regards
Damjan


Re: 4.2.0-dev-m1

2019-03-30 Thread Damjan Jovanovic
>From my email on 15 February 2019:

My own release checklist would include:
1. Library audit.
1.1 Did we lose or gain any public symbols in our libraries since the
4.1.0? Gbuild requires explicit export instead of exporting everything and
then possibly controlling visibility with a .map file, so it's very
possible.
1.2 Did ELF symbol versions on *nix platforms change? The older gbuild
modules probably did, as I didn't understand the meaning of .map files back
then.
1.3 Are the same libraries with the same names available in both 4.1.0 and
4.2.0?
2. Base:
2.1 Complete the Java SDBC driver framework, used by both the new SDBC-JDBC
bridge and the Postgres SDBC driver.
2.2 Audit the new SDBC-JDBC bridge in Java against the old C++ one, fix any
differences.
2.3 Complete the Postgres SDBC driver; still needs views, users, groups,
etc.
2.4 Complete the integration of the Postgres SDBC driver into the Base UI
forms (like MySQL already is).
3. Crashreporter
3.1 Get it working again.
3.2 Bug reported in UI form (instead of submitted to some now obsolete
server), which can be copied/pasted or attached to Bugzilla.
4. Testing
4.1 Run all available tests (unit tests, smoketest, module integration
tests, bvt, fvt, etc.) against 4.1.0 and 4.2.0, find and fix any
regressions.

---

So far, my library audit revealed a lot of symbol changes in some modules
and a more detailed examination is necessary. Need to study ELF further to
understand symbol versioning better. Also the GetVersionInfo symbol in UNO
components is consistently missing when they are built by gbuild; dmake got
it in by linking main/solenv/src/version.c into every library somehow, and
gbuild should do the same.

I've started some work on the Base stuff. To understand it better and get
IDEs to play with it better, I am currently porting main/connectivity to
gbuild. Still need to develop gbuild infrastructure to handle processing
XCU/XCS configuration files with XSLT scripts, but many other modules need
that too.

Crashreporter involves complex interaction between code in main/sal and
main/crashreporter, multiple files get generated and passed around. It
shouldn't be too hard to get working though.

Nothing done regarding testing yet.

Damjan


On Sat, Mar 30, 2019 at 11:32 AM Stehmann  wrote:

> Hello
>
> Am 29. März 2019 19:40:47 MEZ schrieb Damjan Jovanovic  >:
> >I have a lot of experience with desktop integration but am too busy to
> >have
> >a look.
> >
> >Also I posted a checklist of things we should do for the release. None
> >of
> >them are done yet.
>
> Can you please post the list again
>
> Mechtilde
> >
> >
> >
> >On Fri, Mar 29, 2019 at 1:23 PM Jim Jagielski  wrote:
> >
> >> Does the lack of desktop integration in m1 mean that this dev release
> >is
> >> DOA?
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: 4.2.0-dev-m1

2019-03-29 Thread Damjan Jovanovic
I have a lot of experience with desktop integration but am too busy to have
a look.

Also I posted a checklist of things we should do for the release. None of
them are done yet.



On Fri, Mar 29, 2019 at 1:23 PM Jim Jagielski  wrote:

> Does the lack of desktop integration in m1 mean that this dev release is
> DOA?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: OS/2 error running unopkg.bin while packaging

2019-02-22 Thread Damjan Jovanovic
Hi

There were a lot of changes to UNO-related modules in the past few months,
due to both the Win64 port and the gbuild port. It's possible something
broke for OS/2 in the process.

I suggest a bisection test.

Sorry
Damjan



On Fri, Feb 22, 2019 at 12:52 PM Yuri Dario  wrote:

> Hi,
>
> I have a strange error while packaging the current AOO42X tree: I'm
> getting
>
> Error: ERROR:
> F:/rd/AOO/aoo42x/main/instsetoo_native/os2gcci.pro/Apache_OpenOffi
> ce/archive/install/en-US_inprogress/Apache_OpenOffice_4.2.0_os2gcci_in
> stall-arc_
> 
> en-US/OpenOffice 4/program/unopkg.bin sync --verbose
> -env:UNO_JAVA_JFW_ENV_JREHO
> ME=true 2>&1 | failed!
>
> in the log file I can see
>
> ERROR: cannot initialize UCB!
> Exception details:
> (com.sun.star.uno.RuntimeException) { { Message = "cannot initialize
> UCB!", Cont
> ext = (com.sun.star.uno.XInterface) @0 } }
>
>
> and debugging shows that the problem is related to file path length.
> Moving the directory to a shorter path makes unopkg.bin to work.
>
> But aside this, I wonder what does this action at package time, since
> the resulting package seems to be still working. Bundled extensions
> are loaded correctly and adding extensions works too.
>
> Ideas?
>
> 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: svn commit: r1853643 - in /openoffice/trunk/main: ./ apple_remote/ apple_remote/prj/ apple_remote/source/

2019-02-21 Thread Damjan Jovanovic
That's great :)
Well done!

On Thu, Feb 21, 2019 at 6:35 PM Jim Jagielski  wrote:

> Resolved in r 1854065


Re: svn commit: r1853643 - in /openoffice/trunk/main: ./ apple_remote/ apple_remote/prj/ apple_remote/source/

2019-02-20 Thread Damjan Jovanovic
Looks like a lot of symbols may need exporting.

For starters, try the following:
In apple_remote/inc/AppleRemote.h,
change:
@interface AppleRemote : HIDRemoteControlDevice {
to:
@interface SAL_DLLPUBLIC_EXPORT AppleRemote : HIDRemoteControlDevice {

You may also need:
#include 

See if you get this back in the AppleRemote.dylib after building:
bd80 S _OBJC_CLASS_$_AppleRemote


On Wed, Feb 20, 2019 at 7:29 PM Jim Jagielski  wrote:

> In both cases (using trunk and AOO42X) I get:
>
> nm -D solver/450/unxmaccx.pro/lib/*AppleRe*
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm:
> solver/450/unxmaccx.pro/lib/libAppleRemote.dylib: File format has no
> dynamic symbol table.
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm:
> solver/450/unxmaccx.pro/lib/libAppleRemote.jnilib: File format has no
> dynamic symbol table.
>
> Instead, looking at all symbols:
>
> nm -a solver/420/unxmaccx.pro/lib/*AppleRe*
> bfb0 D _AppleRemoteDeviceName
>  U _CFGetTypeID
>  U _CFNumberGetTypeID
>  U _CFRelease
>  U _CFRunLoopAddSource
>  U _CFRunLoopGetCurrent
>  U _CFRunLoopRemoveSource
>  U _CFUUIDGetConstantUUIDWithBytes
>  U _CFUUIDGetUUIDBytes
> 7b10 S _DEFAULT_MAXIMUM_CLICK_TIME_DIFFERENCE
>  U _DisableSecureEventInput
>  U _EnableSecureEventInput
> bfc0 D _FINISHED_USING_REMOTE_CONTROL_NOTIFICATION
>  U _GetEventDispatcherTarget
>  U _GetEventParameter
> 78f0 T _GetVersionInfo
> 7b18 S _HOLD_RECOGNITION_TIME_INTERVAL
>  U _IOCreatePlugInInterfaceForService
>  U _IOIteratorNext
>  U _IOObjectGetClass
>  U _IOObjectRelease
>  U _IOServiceGetMatchingServices
>  U _IOServiceMatching
>  U _InstallEventHandler
>  U _NSApp
>  U _NSAppKitVersionNumber
>  U _NSLog
>  U _NSZeroPoint
> bd80 S _OBJC_CLASS_$_AppleRemote
> bf60 S _OBJC_CLASS_$_AppleRemoteMainController
> be70 S _OBJC_CLASS_$_GlobalKeyboardDevice
> bec0 S _OBJC_CLASS_$_HIDRemoteControlDevice
> bf10 S _OBJC_CLASS_$_MultiClickRemoteBehavior
>  U _OBJC_CLASS_$_NSArray
>  U _OBJC_CLASS_$_NSAutoreleasePool
>  U _OBJC_CLASS_$_NSBundle
>  U _OBJC_CLASS_$_NSDate
>  U _OBJC_CLASS_$_NSDictionary
>  U _OBJC_CLASS_$_NSDistributedNotificationCenter
>  U _OBJC_CLASS_$_NSEvent
>  U _OBJC_CLASS_$_NSMutableArray
>  U _OBJC_CLASS_$_NSMutableDictionary
>  U _OBJC_CLASS_$_NSMutableString
>  U _OBJC_CLASS_$_NSNumber
>  U _OBJC_CLASS_$_NSObject
>  U _OBJC_CLASS_$_NSString
>  U _OBJC_CLASS_$_NSThread
>  U _OBJC_CLASS_$_NSUserDefaults
> bdd0 S _OBJC_CLASS_$_RemoteControl
> be20 S _OBJC_CLASS_$_RemoteControlContainer
> bd78 S _OBJC_IVAR_$_AppleRemoteMainController.remoteControl
> bcd0 S _OBJC_IVAR_$_GlobalKeyboardDevice.eventHandlerRef
> bcc8 S
> _OBJC_IVAR_$_GlobalKeyboardDevice.hotKeyRemoteEventMapping
> bd08 S _OBJC_IVAR_$_HIDRemoteControlDevice.allCookies
> bcf0 S
> _OBJC_IVAR_$_HIDRemoteControlDevice.cookieToButtonMapping
> bd18 S _OBJC_IVAR_$_HIDRemoteControlDevice.eventSource
> bd00 S
> _OBJC_IVAR_$_HIDRemoteControlDevice.fixSecureEventInputBug
> bce8 S _OBJC_IVAR_$_HIDRemoteControlDevice.hidDeviceInterface
> bcd8 S _OBJC_IVAR_$_HIDRemoteControlDevice.openInExclusiveMode
> bd10 S _OBJC_IVAR_$_HIDRemoteControlDevice.processesBacklog
> bce0 S _OBJC_IVAR_$_HIDRemoteControlDevice.queue
> bcf8 S
> _OBJC_IVAR_$_HIDRemoteControlDevice.supportedButtonEvents
> bd38 S
> _OBJC_IVAR_$_MultiClickRemoteBehavior.clickCountEnabledButtons
> bd28 S _OBJC_IVAR_$_MultiClickRemoteBehavior.delegate
> bd58 S _OBJC_IVAR_$_MultiClickRemoteBehavior.eventClickCount
> bd60 S
> _OBJC_IVAR_$_MultiClickRemoteBehavior.lastClickCountEvent
> bd68 S
> _OBJC_IVAR_$_MultiClickRemoteBehavior.lastClickCountEventTime
> bd50 S
> _OBJC_IVAR_$_MultiClickRemoteBehavior.lastEventSimulatedHold
> bd40 S _OBJC_IVAR_$_MultiClickRemoteBehavior.lastHoldEvent
> bd48 S _OBJC_IVAR_$_MultiClickRemoteBehavior.lastHoldEventTime
> bd20 S
> _OBJC_IVAR_$_MultiClickRemoteBehavior.maxClickTimeDifference
> bd30 S 

Re: svn commit: r1853643 - in /openoffice/trunk/main: ./ apple_remote/ apple_remote/prj/ apple_remote/source/

2019-02-20 Thread Damjan Jovanovic
I wonder if the problem is that gbuild's default symbol visibility is
hidden, unlike dmake's which was public.

Can you post the output of:
nm -D solver/450//lib/*AppleRemote.dylib | grep ' T '
and compare against the same from any version before the gbuild commit?

In C/C++ we have to mark functions to export with SAL_DLLPUBLIC_EXPORT in
the .c/.cxx files, or use a more complex setup with a dllapi.h file (
https://wiki.openoffice.org/wiki/Symbol_Visibility) when the functions are
declared in header files. Objective C probably needs something similar.

On Wed, Feb 20, 2019 at 7:05 PM Jim Jagielski  wrote:

> The patch is applied (as well as some other changes) and apple_remote
> builds, but it looks like even though it builds, some linking issues are
> still there:
>
> [ build RES ] vclen-GB
> Undefined symbols for architecture x86_64:
>   "_OBJC_CLASS_$_AppleRemoteMainController", referenced from:
>   objc-class-ref in salinst.o
>   "_OBJC_IVAR_$_AppleRemoteMainController.remoteControl", referenced from:
>   -[VCL_NSApplication applicationWillBecomeActive:] in vclnsapp.o
>   -[VCL_NSApplication applicationWillResignActive:] in vclnsapp.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make: *** [/Users/jim/src/asf/trunk/main/solenv/gbuild/LinkTarget.mk:330:
> /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/libvcl.dylib] Error 1
> make: *** Waiting for unfinished jobs
> dmake:  Error code 2, while making 'all'
>
>
>
> > On Feb 19, 2019, at 8:59 PM, Damjan Jovanovic  wrote:
> >
> > Yes, changes to gbuild itself are largely made by experimentation. It's
> beyond anyone's complete understanding.
> >
> > Please try this patch, with the file extensions back on *.m.
> >
> > On Tue, Feb 19, 2019 at 10:39 PM Jim Jagielski  j...@jagunet.com>> wrote:
> >
> >
> > > On Feb 19, 2019, at 12:05 PM, Damjan Jovanovic  <mailto:dam...@apache.org>> wrote:
> > >
> > >  If
> > > not, I'll have to make a gb_Library_add_objcobjects API instead.
> >
> > If I knew how, I'd do it. Looking over the add_objcxxobjects stuff it
> seems like a maze of twisty little passages
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org  dev-unsubscr...@openoffice.apache.org>
> > For additional commands, e-mail: dev-h...@openoffice.apache.org  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: r1853643 - in /openoffice/trunk/main: ./ apple_remote/ apple_remote/prj/ apple_remote/source/

2019-02-19 Thread Damjan Jovanovic
Yes, changes to gbuild itself are largely made by experimentation. It's
beyond anyone's complete understanding.

Please try this patch, with the file extensions back on *.m.

On Tue, Feb 19, 2019 at 10:39 PM Jim Jagielski  wrote:

>
>
> > On Feb 19, 2019, at 12:05 PM, Damjan Jovanovic 
> wrote:
> >
> >  If
> > not, I'll have to make a gb_Library_add_objcobjects API instead.
>
> If I knew how, I'd do it. Looking over the add_objcxxobjects stuff it
> seems like a maze of twisty little passages
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
diff --git a/main/apple_remote/Library_AppleRemote.mk b/main/apple_remote/Library_AppleRemote.mk
index 8c7aedd267..0d28cf3418 100644
--- a/main/apple_remote/Library_AppleRemote.mk
+++ b/main/apple_remote/Library_AppleRemote.mk
@@ -42,7 +42,7 @@ $(eval $(call gb_Library_add_libs,AppleRemote,\
 	-framework IOKit \
 ))
 
-$(eval $(call gb_Library_add_objcxxobjects,AppleRemote,\
+$(eval $(call gb_Library_add_objcobjects,AppleRemote,\
 	apple_remote/source/AppleRemote \
 	apple_remote/source/RemoteControl \
 	apple_remote/source/RemoteControlContainer \
diff --git a/main/solenv/gbuild/Library.mk b/main/solenv/gbuild/Library.mk
index 591b5392a0..42c78fda2b 100644
--- a/main/solenv/gbuild/Library.mk
+++ b/main/solenv/gbuild/Library.mk
@@ -113,6 +113,8 @@ $(eval $(foreach method,\
 	add_cobjects \
 	add_cxxobject \
 	add_cxxobjects \
+	add_objcobject \
+	add_objcobjects \
 	add_objcxxobject \
 	add_objcxxobjects \
 	add_exception_objects \
@@ -125,6 +127,8 @@ $(eval $(foreach method,\
 	set_cflags \
 	add_cxxflags \
 	set_cxxflags \
+	add_objcflags \
+	set_objcflags \
 	add_objcxxflags \
 	set_objcxxflags \
 	add_defs \
diff --git a/main/solenv/gbuild/LinkTarget.mk b/main/solenv/gbuild/LinkTarget.mk
index f19910e17b..c67c1c5f15 100644
--- a/main/solenv/gbuild/LinkTarget.mk
+++ b/main/solenv/gbuild/LinkTarget.mk
@@ -25,6 +25,7 @@
 # CPPFLAGS
 # CFLAGS
 # CXXFLAGS
+# OBJCFLAGS
 # OBJCXXFLAGS
 # JAVAFLAGS
 # LDFLAGS
@@ -34,11 +35,13 @@
 ifeq ($(gb_DEBUGGING),TRUE)
 CFLAGS ?= $(gb_COMPILEROPTFLAGS) $(gb_DEBUG_CFLAGS)
 CXXFLAGS ?= $(gb_COMPILEROPTFLAGS) $(gb_DEBUG_CFLAGS)
+OBJCFLAGS ?= $(gb_COMPILEROPTFLAGS) $(gb_DEBUG_CFLAGS)
 OBJCXXFLAGS ?= $(gb_COMPILEROPTFLAGS) $(gb_DEBUG_CFLAGS)
 JAVAFLAGS ?= -g
 else
 CFLAGS ?= $(gb_COMPILEROPTFLAGS)
 CXXFLAGS ?= $(gb_COMPILEROPTFLAGS)
+OBJCFLAGS ?= $(gb_COMPILEROPTFLAGS)
 OBJCXXFLAGS ?= $(gb_COMPILEROPTFLAGS)
 endif
 
@@ -206,6 +209,38 @@ endif
 gb_GenCxxObject_GenCxxObject =
 
 
+
+# ObjCObject class
+#
+gb_ObjCObject_REPOS := $(gb_REPOS)
+
+gb_ObjCObject_get_source = $(1)/$(2).m
+# defined by platform
+#  gb_ObjCObject__command
+
+define gb_ObjCObject__rules
+$$(call gb_ObjCObject_get_target,%) : $$(call gb_ObjCObject_get_source,$(1),%)
+	$$(call gb_ObjCObject__command,$$@,$$*,$$<,$$(call gb_ObjCObject_get_dep_target,$$*))
+
+ifeq ($(gb_FULLDEPS),$(true))
+$$(call gb_ObjCObject_get_dep_target,%) : $$(call gb_ObjCObject_get_target,%)
+	$$(if $$(wildcard $$@),touch $$@,\
+	  $$(call gb_Object__command_dep,$$@,$$(call gb_ObjCObject_get_target,$$*)))
+endif
+
+endef
+
+$(foreach repo,$(gb_ObjCObject_REPOS),$(eval $(call gb_ObjCObject__rules,$(repo
+
+ifeq ($(gb_FULLDEPS),$(true))
+$(call gb_ObjCObject_get_dep_target,%) :
+	$(eval $(call gb_Output_error,Unable to find Objective C file $(call gb_ObjCObject_get_source,,$*) in repositories: $(gb_ObjCObject_REPOS)))
+endif
+
+gb_ObjCObject_ObjCObject =
+
+
+
 # ObjCxxObject class
 #
 gb_ObjCxxObject_REPOS := $(gb_REPOS)
@@ -255,6 +290,8 @@ $(call gb_LinkTarget_get_clean_target,%) :
 		$(foreach object,$(COBJECTS),$(call gb_CObject_get_dep_target,$(object))) \
 		$(foreach object,$(CXXOBJECTS),$(call gb_CxxObject_get_target,$(object))) \
 		$(foreach object,$(CXXOBJECTS),$(call gb_CxxObject_get_dep_target,$(object))) \
+		$(foreach object,$(OBJCOBJECTS),$(call gb_ObjCObject_get_target,$(object))) \
+		$(foreach object,$(OBJCOBJECTS),$(call gb_ObjCObject_get_dep_target,$(object))) \
 		$(foreach object,$(OBJCXXOBJECTS),$(call gb_ObjCxxObject_get_target,$(object))) \
 		$(foreach object,$(OBJCXXOBJECTS),$(call gb_ObjCxxObject_get_dep_target,$(object))) \
 		$(foreach object,$(GENCOBJECTS),$(call gb_GenCObject_get_target,$(object))) \
@@ -279,9 +316,10 @@ $(call gb_Helper_abbreviate_dirs,\
 	RESPONSEFILE=$(call var2file,$(shell $(gb_MKTEMP)),200,\
 		$(foreach object,$(3),$(call gb_CObject_get_dep_target,$(object))) \
 		$(foreach object,$(4),$(call gb_CxxObject_get_dep_target,$(object))) \
-		$(foreach object,$(5),$(call gb_ObjCxxObject_get_dep_target,$(object)))\
-		$(foreach object,$(6),$(call gb_GenCObject_get_dep_target,$(object)))\
-		$(foreach object,$(7),$(call gb_GenCxxObject_get_dep_target,$(object)))\
+		$(foreach object,$(5),$(call gb_ObjCObject

Re: svn commit: r1853643 - in /openoffice/trunk/main: ./ apple_remote/ apple_remote/prj/ apple_remote/source/

2019-02-19 Thread Damjan Jovanovic
I think .m files are Objective C, and gb_Library_add_objcxxobjects wants
Objective C++'s .mm.

I am completely unfamiliar with both languages.

Please try renaming apple_remote/source/*.m to *.mm and see if it works? If
not, I'll have to make a gb_Library_add_objcobjects API instead.


On Tue, Feb 19, 2019 at 5:02 PM Jim Jagielski  wrote:

> Nope... that wasn't it. Even with a complete fresh-from-scratch build, I
> get the same error.
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: Time for our first 4.2.0 beta?

2019-02-15 Thread Damjan Jovanovic
Bug 125129 looks like a wild goose chase and requires considerable
understanding of the framework layer, but I'll try continue when I have
time.

My own release checklist would include:
1. Library audit.
1.1 Did we lose or gain any public symbols in our libraries since the
4.1.0? Gbuild requires explicit export instead of exporting everything and
then possibly controlling visibility with a .map file, so it's very
possible.
1.2 Did ELF symbol versions on *nix platforms change? The older gbuild
modules probably did, as I didn't understand the meaning of .map files back
then.
1.3 Are the same libraries with the same names available in both 4.1.0 and
4.2.0?
2. Base:
2.1 Complete the Java SDBC driver framework, used by both the new SDBC-JDBC
bridge and the Postgres SDBC driver.
2.2 Audit the new SDBC-JDBC bridge in Java against the old C++ one, fix any
differences.
2.3 Complete the Postgres SDBC driver; still needs views, users, groups,
etc.
2.4 Complete the integration of the Postgres SDBC driver into the Base UI
forms (like MySQL already is).
3. Crashreporter
3.1 Get it working again.
3.2 Bug reported in UI form (instead of submitted to some now obsolete
server), which can be copied/pasted or attached to Bugzilla.
4. Testing
4.1 Run all available tests (unit tests, smoketest, module integration
tests, bvt, fvt, etc.) against 4.1.0 and 4.2.0, find and fix any
regressions.

Damjan


On Fri, Feb 15, 2019 at 1:25 AM Matthias Seidel 
wrote:

> Hi Jim,
>
> IMO, the situation hasn't changed so much.
>
> We should at least fix issue 125129 [1] before we release a (public)
> beta. I have seen that Damjan is investigating...
>
> Then we need time to inform translators on l10n@ before we can export
> the latest translations from Pootle.
> At the moment most of them are at 98% for the UI but the SDF files still
> need to be updated in source.
>
> Regards,
>
>Matthias
>
> [1] https://bz.apache.org/ooo/show_bug.cgi?id=125129
>
>
> Am 14.02.19 um 17:45 schrieb Jim Jagielski:
> > Time for another ping... what does everyone think? Time?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>
>


Re: macOS on trunk broken again

2019-02-13 Thread Damjan Jovanovic
Fixed in 1853558:

Fix a regression in 1853299 caused by a path and pattern match rule
in main/packages that were wrong.

Patch by: me


On Wed, Feb 13, 2019 at 9:04 PM Damjan Jovanovic  wrote:

> Hi
>
> I can reproduce it now. In debug mode (Ctrl+Alt+Shift+D), it gives
> warnings, and when you make it crash, you get the below in the core file.
>
> I'll start a bisect immediately.
>
> #0  ImplCoreDump () at
> /openoffice-git/main/tools/source/debug/debug.cxx:303
> 303*pTemp = 0x;
> Current language:  auto; currently c++
> (gdb) bt
> #0  ImplCoreDump () at
> /openoffice-git/main/tools/source/debug/debug.cxx:303
> #1  0x000804a934aa in DbgFunc (nAction=,
> pParam=) at
> /openoffice-git/main/tools/source/debug/debug.cxx:1295
> #2  0x00080553ed84 in DbgPrintMsgBox (
> pLine=0x7fff4a30 "Error: ImageAryData::Load: failed to load image
> 'res/commandimagelist/sc_searchdialog.png'\nFrom File
> /openoffice-git/main/vcl/source/gdi/image.cxx at L"...)
> at /openoffice-git/main/vcl/source/app/dbggui.cxx:1907
> #3  0x000804a92874 in DbgOut (pMsg=,
> nDbgOut=, pFile=0x805796698
> "/openoffice-git/main/vcl/source/gdi/image.cxx", nLine= out>)
> at vector:633
> #4  0x000800a3255a in osl_assertFailedLine (pszFileName=0x805796698
> "/openoffice-git/main/vcl/source/gdi/image.cxx", nLine=554,
> pszMessage=0x80d57d348 "ImageAryData::Load: failed to load image
> 'res/commandimagelist/sc_searchdialog.png'") at diagnose.c:263
> #5  0x00080560b22e in ImageAryData::Load () at new:236
> #6  0x00080560c471 in ImageList::GetImage () at new:236
> #7  0x00080a92ca12 in framework::CmdImageList::getImageFromCommandURL
> (this=0x81c383650, nImageType=0, rCommandURL=)
> at
> /openoffice-git/main/framework/source/uiconfiguration/imagemanagerimpl.cxx:326
> #8  0x00080a92cb57 in
> framework::GlobalImageList::getImageFromCommandURL (this= out>, nImageType=, rCommandURL=)
> at
> /openoffice-git/main/framework/source/uiconfiguration/imagemanagerimpl.cxx:367
> #9  0x00080a92fcf3 in framework::ImageManagerImpl::getImages
> (this=0x81cfc0540, nImageType=,
> aCommandURLSequence=)
> at
> /openoffice-git/main/framework/source/uiconfiguration/imagemanagerimpl.cxx:963
> #10 0x00080a933519 in framework::ModuleImageManager::getImages
> (this=, nImageType=,
> aCommandURLSequence=)
> at
> /openoffice-git/main/framework/source/uiconfiguration/moduleimagemanager.cxx:148
> #11 0x00080a93353e in non-virtual thunk to
> framework::ModuleImageManager::getImages(short,
> com::sun::star::uno::Sequence const&) (this= out>, nImageType=4752, aCommandURLSequence=@0x804a934a5)
> at memory:2050
> #12 0x00080a989367 in framework::ToolBarManager::RequestImages
> (this=0x81fa3c620) at
> /openoffice-git/main/framework/source/uielement/toolbarmanager.cxx:1563
> #13 0x00080a9886f1 in framework::ToolBarManager::FillToolbar
> (this=, rItemContainer=)
> at
> /openoffice-git/main/framework/source/uielement/toolbarmanager.cxx:1508
> #14 0x00080a98f93b in framework::ToolBarWrapper::initialize
> (this=0x81fa26800, aArguments=)
> at
> /openoffice-git/main/framework/source/uielement/toolbarwrapper.cxx:194
> #15 0x00080a998931 in framework::MenuBarFactory::CreateUIElement
> (ResourceURL=, Args=,
> _pExtraMode=0x80a9b16da "PopupMode", _pAsciiName=0x80a9ab3ab
> "private:resource/toolbar/",
> _xMenuBar=@0x7fff96d0, _xModuleManager=@0x7fff9580,
> _xServiceManager=@0x81cfe7b48) at
> /openoffice-git/main/framework/source/uifactory/menubarfactory.cxx:205
> #16 0x00080a9994e9 in framework::ToolBoxFactory::createUIElement
> (this=, ResourceURL=@0x81fa26990, Args=@0x7fff96d8)
> at
> /openoffice-git/main/framework/source/uifactory/toolboxfactory.cxx:96
> #17 0x00080a99957a in non-virtual thunk to
> framework::ToolBoxFactory::createUIElement(rtl::OUString const&,
> com::sun::star::uno::Sequence const&)
> (this=,
> ResourceURL=@0x804af1290, Args=@0x804a934a5) at general.h:59
> #18 0x00080a99d856 in
> framework::UIElementFactoryManager::createUIElement (this=0x81a1a4560,
> ResourceURL=@0x81fa26990, Args=@0x7fff96d8)
> at
> /openoffice-git/main/framework/source/uifactory/uielementfactorymanager.cxx:455
> #19 0x00080a99d9c2 in non-virtual thunk to
> framework::UIElementFactoryManager::createUIElement(rtl::OUString const&,
> com::sun::star::uno::Sequence const&)
> (this=,
> ResourceURL=@0x804af1290, Args=@0x804a934a5) at new:236
> #20 0x00080a8d4e3c in
> framework::ToolbarLayoutManager::implts_createElement (this=0x8191f1090,
> aName=@0x81fa26990)
> at
> 

Re: macOS on trunk broken again

2019-02-13 Thread Damjan Jovanovic
anager/toolbarlayoutmanager.cxx:448
#24 0x00080a8dcc27 in boost::_bi::bind_t,
boost::_bi::list2,
boost::arg<1> > >::operator() (this=0x7fff9a20,
a1=) at bind_template.hpp:32
#25 0x00080a8d0655 in
framework::ToolbarLayoutManager::implts_createNonContextSensitiveToolBars
(this=0x8191f1090) at algorithm:965
#26 0x00080a8cf758 in
framework::ToolbarLayoutManager::createStaticToolbars (this=0x8191f1090) at
/openoffice-git/main/framework/source/layoutmanager/toolbarlayoutmanager.cxx:410
#27 0x00080a8c0327 in framework::LayoutManager::implts_reset
(this=0x800787010, bAttached=1 '\001') at
/openoffice-git/main/framework/source/layoutmanager/layoutmanager.cxx:407
#28 0x00080a8c90a3 in framework::LayoutManager::frameAction
(this=0x800787010, aEvent=@0x7fff9cd0) at
/openoffice-git/main/framework/source/layoutmanager/layoutmanager.cxx:2858
#29 0x00080a90b9bf in framework::Frame::implts_sendFrameActionEvent
(this=, aAction=)
at /openoffice-git/main/framework/source/services/frame.cxx:2795
#30 0x00080a90dcf7 in framework::Frame::setComponent (this=0x80f4b1830,
xComponentWindow=@0x7fff9e20, xController=@0x7fff9e18)
at /openoffice-git/main/framework/source/services/frame.cxx:1472
#31 0x00080a90ebbb in non-virtual thunk to
framework::Frame::setComponent(com::sun::star::uno::Reference
const&, com::sun::star::uno::Reference
const&) (
this=, xComponentWindow=@0x0,
xController=@0x804af1290) at typeinfo:181
#32 0x0008034f0691 in SfxFrameLoader_Impl::impl_createDocumentView
(this=, i_rModel=@0x7fff9ed8,
i_rFrame=@0x7fff9fb0, i_rViewFactoryArgs=,
i_rViewName=)
at /openoffice-git/main/sfx2/source/view/frmload.cxx:509
#33 0x0008034f0bf9 in SfxFrameLoader_Impl::load (this=, rArgs=, _rTargetFrame=@0x7fff9fb0)
at /openoffice-git/main/sfx2/source/view/frmload.cxx:629
#34 0x00080a8e18ea in framework::LoadEnv::impl_loadContent (this=) at
/openoffice-git/main/framework/source/loadenv/loadenv.cxx:1205
#35 0x00080a8df9ac in framework::LoadEnv::startLoading
(this=0x81c37d2c8) at
/openoffice-git/main/framework/source/loadenv/loadenv.cxx:433
#36 0x00080a89d1a7 in framework::LoadDispatcher::impl_dispatch
(this=, rURL=@0x81cfb4a58, lArguments=@0x81cfb4ab0,
xListener=@0x7fffa108)
at /openoffice-git/main/framework/source/dispatch/loaddispatcher.cxx:165
#37 0x00080a89d477 in framework::LoadDispatcher::dispatch (this=, aURL=, lArguments=)
at /openoffice-git/main/framework/source/dispatch/loaddispatcher.cxx:92
#38 0x00080a900f92 in implDispatchDelayed (pArg=0x81cfb4a50) at
/openoffice-git/main/framework/source/services/backingwindow.cxx:1019
#39 0x00080577abf3 in ImplHandleUserEvent (pSVEvent=0x80d5a8330) at
MouseEvent.hpp:33
#40 0x000805779336 in ImplWindowFrameProc (pWindow=0x80f4a5590,
nEvent=22, pEvent=0x80d5a8330) at
/openoffice-git/main/vcl/source/window/winproc.cxx:2568
#41 0x00080dc97713 in SalDisplay::DispatchInternalEvent
(this=0x80073ba20) at
/openoffice-git/main/vcl/unx/generic/app/saldisp.cxx:2231
#42 0x00080da26619 in GtkXLib::userEventFn (data=0x800763020) at
/openoffice-git/main/vcl/unx/gtk/app/gtkdata.cxx:817
#43 0x00080efbabc7 in g_main_context_dispatch () from
/usr/local/lib/libglib-2.0.so.0
#44 0x00080efbaf53 in g_main_context_pending () from
/usr/local/lib/libglib-2.0.so.0
#45 0x00080efbb004 in g_main_context_iteration () from
/usr/local/lib/libglib-2.0.so.0
#46 0x00080da26774 in GtkXLib::Yield (this=0x800763020, bWait=true,
bHandleAllCurrentEvents=) at
/openoffice-git/main/vcl/unx/gtk/app/gtkdata.cxx:869
#47 0x00080554da4d in ImplYield () at decoview.hxx:91
#48 0x00080554b01d in Application::Execute () at new:236
#49 0x000800e68ac6 in desktop::Desktop::Main (this=0x7fffadd8) at
app.cxx:2232
#50 0x000805550b87 in ImplSVMain () at
/openoffice-git/main/vcl/source/app/svmain.cxx:196
#51 0x000805551739 in SVMain () at
/openoffice-git/main/vcl/source/app/svmain.cxx:237
#52 0x000800eb1b88 in soffice_main () at sofficemain.cxx:45
#53 0x004011b9 in sal_main () at main.c:31
#54 0x00401197 in main (argc=1, argv=0x7fffaec8) at main.c:30



On Wed, Feb 13, 2019 at 6:05 PM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Sorry, I only see empty boxes... ;-)
>
> But a fresh Windows build from buildbot, revision 1853466 still shows no
> icons in toolbars:
>
> https://www.dropbox.com/s/33hqi8dbvxz8mt0/VirtualBox_Windows%207%20AOO-Build_13_02_2019_16_49_43.png?dl=0
>
> I will force a new build for Linux64 now and see how it looks like.
>
> Regards,
>
>Matthias
> Am 13.02.19 um 02:02 schrieb Damjan Jovanovic:
>
> Where? I see them:
> [image: image.png]
> [image: image.png]
>
> On Wed, Feb 13, 2019 at 12:47 AM Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
>
>> Hi Damjan,
>>
>> Am 12.02.19 um 18:01 schrieb Damjan Jovanovic:
>> &

Re: macOS on trunk broken again

2019-02-12 Thread Damjan Jovanovic
Ok so in main/RepositoryFixes.mk I did try to replicate what dmake was
doing, building a .so instead of a .dylib:

# pyuno.so even on Mac OS X, because it is a python module
gb_Library_FILENAMES := $(patsubst
pyuno_loader:libpyuno%,pyuno_loader:pyuno.so,$(gb_Library_FILENAMES))

but then it apparently made a symlink to itself...

We symlink in solenv/gbuild/platform/macosx.mk:
$(if $(filter Library,$(TARGETTYPE)),\
$(PERL) $(SOLARENV)/bin/macosx-change-install-names.pl
Library $(LAYER) $(1) && \
ln -shf $(1) $(patsubst %.dylib,%.jnilib,$(1)) &&) \

I think that's the problem. In that bottom line, $(1) is /path/pyuno.so,
but because it's ending in .so, the patsubst won't do a replacement, so
ends up running:
ln -shf $(1) $(1)

Maybe we should skip symlinking when it's not a .dylib?

Please try the attached patch.

On Tue, Feb 12, 2019 at 10:03 PM Jim Jagielski  wrote:

>  % ls -l solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/*py*
> -rwxr-xr-x <http://unxmaccx.pro/workdir/LinkTarget/Library/*py*-rwxr-xr-x>
> 1 jim  staff  205276 Feb 12 13:27 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.dylib*
> lrwxr-xr-x
> <http://unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.dylib*lrwxr-xr-x>
> 1 jim  staff  95 Feb 12 13:27 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.jnilib@ ->
> /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.dylib
> -rwxr-xr-x
> <http://unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.dylib-rwxr-xr-x>
> 1 jim  staff   25100 Feb 12 14:35 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.dylib*
> lrwxr-xr-x
> <http://unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.dylib*lrwxr-xr-x>
> 1 jim  staff 103 Feb 12 14:35 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.jnilib@ ->
> /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.dylib
> lrwxr-xr-x
> <http://unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.dyliblrwxr-xr-x>
> 1 jim  staff  89 Feb 12 14:35 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so@ ->
> /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so
>
>
> > On Feb 12, 2019, at 1:16 PM, Damjan Jovanovic  wrote:
> >
> > Please run:
> > ls -l /Users/jim/src/asf/trunk/main/solver/450/
> > unxmaccx.pro/workdir/LinkTarget/Library/*py*
> >
> > On Tue, Feb 12, 2019 at 8:08 PM Jim Jagielski  wrote:
> >
> >> Different issue but also affects macOS:
> >>
> >> [ build DEP ] LNK:Library/libpyuno.dylib
> >> [ build LNK ] Library/libpyuno.dylib
> >> [ build CMP ] pyuno/source/loader/pythonloader
> >> [ build CMP ] pyuno/source/loader/pythonloader
> >> [ build LNK ] Library/pyuno.so
> >> [ build CHK ] pyuno
> >> [ build CHK ] loaded modules: pyuno
> >> [ build PKG ] pyuno_py
> >> [ build PKG ] pyuno_pyuno_ini
> >> make: stat: /Users/jim/src/asf/trunk/main/solver/450/
> >> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so: Too many levels of
> >> symbolic links
> >> touch: /Users/jim/src/asf/trunk/main/solver/450/
> >> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so: Too many levels of
> >> symbolic links
> >> make: *** [/Users/jim/src/asf/trunk/main/solenv/gbuild/Package.mk:28:
> >> /Users/jim/src/asf/trunk/main/solver/450/unxmaccx.pro/lib/pyuno.so]
> Error
> >> 1
> >> make: *** Waiting for unfinished jobs
> >> dmake:  Error code 2, while making 'all'
> >>
> >> 1 module(s):
> >>pyuno
> >> need(s) to be rebuilt
> >>
> >>
> >>> On Feb 12, 2019, at 10:02 AM, Matthias Seidel <
> >> matthias.sei...@hamburg.de> wrote:
> >>>
> >>> Linux64 and Linux32 also break, but in in pyuno: <>
> >>>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/pyuno/unxlngx6.pro/misc/logs/prj.txt
> >> <>
> >>>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/linux32/main/pyuno/unxlngi6.pro/misc/logs/prj.txt
> >> <>
> >>> Maybe it is related?
> >>> <>
> >>> Regards, <>
> >>>   Matthias
> >>> <>
> >>> Am 11.02.19 um 20:56 schrieb Damjan Jovanovic:
> >>>> On Mon, Feb 11, 2019 at 8:03 PM Jim Jagielski 
> >> <mailto:j...@jagunet.com> wrote:
> >>>>
> >>>>> Uggg
> >>>>

Re: macOS on trunk broken again

2019-02-12 Thread Damjan Jovanovic
1853456 introduced a bracketing bug in main/pyuno/Library_pyuno_loader.mk.
1853457 Linux64 buildbot.
1853465 Linux32 buildbot.
1853466 fixed that bug.
Maybe we just need a rebuild?

On Wed, Feb 13, 2019 at 3:02 AM Damjan Jovanovic  wrote:

> Where? I see them:
> [image: image.png]
> [image: image.png]
>
> On Wed, Feb 13, 2019 at 12:47 AM Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
>
>> Hi Damjan,
>>
>> Am 12.02.19 um 18:01 schrieb Damjan Jovanovic:
>> > Linux should be fixed in commit 1853456.
>>
>> It builds now, but the icons in the toolbars are gone?
>>
>> I installed on Linux64 and Windows, both look the same...
>>
>> Regards,
>>
>>Matthias
>>
>> >
>> > That commit involved Mac too.
>> >
>> > On Tue, Feb 12, 2019 at 5:02 PM Matthias Seidel <
>> matthias.sei...@hamburg.de>
>> > wrote:
>> >
>> >> Linux64 and Linux32 also break, but in in pyuno:
>> >>
>> >>
>> >>
>> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/pyuno/unxlngx6.pro/misc/logs/prj.txt
>> >>
>> >>
>> >>
>> https://ci.apache.org/projects/openoffice/buildlogs/linux32/main/pyuno/unxlngi6.pro/misc/logs/prj.txt
>> >>
>> >> Maybe it is related?
>> >>
>> >> Regards,
>> >>
>> >>Matthias
>> >> Am 11.02.19 um 20:56 schrieb Damjan Jovanovic:
>> >>
>> >> On Mon, Feb 11, 2019 at 8:03 PM Jim Jagielski  <
>> j...@jagunet.com> wrote:
>> >>
>> >>
>> >> Uggg
>> >>
>> >> looks like breakage from the solenv port to gbuild???
>> >>
>> >>
>> >>
>> >> Are you sure?
>> >>
>> >> I don't see how, it's a very simple port.
>> >>
>> >>
>> >>
>>
>>


Re: macOS on trunk broken again

2019-02-12 Thread Damjan Jovanovic
Where? I see them:
[image: image.png]
[image: image.png]

On Wed, Feb 13, 2019 at 12:47 AM Matthias Seidel 
wrote:

> Hi Damjan,
>
> Am 12.02.19 um 18:01 schrieb Damjan Jovanovic:
> > Linux should be fixed in commit 1853456.
>
> It builds now, but the icons in the toolbars are gone?
>
> I installed on Linux64 and Windows, both look the same...
>
> Regards,
>
>Matthias
>
> >
> > That commit involved Mac too.
> >
> > On Tue, Feb 12, 2019 at 5:02 PM Matthias Seidel <
> matthias.sei...@hamburg.de>
> > wrote:
> >
> >> Linux64 and Linux32 also break, but in in pyuno:
> >>
> >>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/pyuno/unxlngx6.pro/misc/logs/prj.txt
> >>
> >>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/linux32/main/pyuno/unxlngi6.pro/misc/logs/prj.txt
> >>
> >> Maybe it is related?
> >>
> >> Regards,
> >>
> >>Matthias
> >> Am 11.02.19 um 20:56 schrieb Damjan Jovanovic:
> >>
> >> On Mon, Feb 11, 2019 at 8:03 PM Jim Jagielski  <
> j...@jagunet.com> wrote:
> >>
> >>
> >> Uggg
> >>
> >> looks like breakage from the solenv port to gbuild???
> >>
> >>
> >>
> >> Are you sure?
> >>
> >> I don't see how, it's a very simple port.
> >>
> >>
> >>
>
>


Re: macOS on trunk broken again

2019-02-12 Thread Damjan Jovanovic
Please run:
ls -l /Users/jim/src/asf/trunk/main/solver/450/
unxmaccx.pro/workdir/LinkTarget/Library/*py*

On Tue, Feb 12, 2019 at 8:08 PM Jim Jagielski  wrote:

> Different issue but also affects macOS:
>
> [ build DEP ] LNK:Library/libpyuno.dylib
> [ build LNK ] Library/libpyuno.dylib
> [ build CMP ] pyuno/source/loader/pythonloader
> [ build CMP ] pyuno/source/loader/pythonloader
> [ build LNK ] Library/pyuno.so
> [ build CHK ] pyuno
> [ build CHK ] loaded modules: pyuno
> [ build PKG ] pyuno_py
> [ build PKG ] pyuno_pyuno_ini
> make: stat: /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so: Too many levels of
> symbolic links
> touch: /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so: Too many levels of
> symbolic links
> make: *** [/Users/jim/src/asf/trunk/main/solenv/gbuild/Package.mk:28:
> /Users/jim/src/asf/trunk/main/solver/450/unxmaccx.pro/lib/pyuno.so] Error
> 1
> make: *** Waiting for unfinished jobs
> dmake:  Error code 2, while making 'all'
>
> 1 module(s):
> pyuno
> need(s) to be rebuilt
>
>
> > On Feb 12, 2019, at 10:02 AM, Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
> >
> > Linux64 and Linux32 also break, but in in pyuno: <>
> >
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/pyuno/unxlngx6.pro/misc/logs/prj.txt
> <>
> >
> https://ci.apache.org/projects/openoffice/buildlogs/linux32/main/pyuno/unxlngi6.pro/misc/logs/prj.txt
> <>
> > Maybe it is related?
> >  <>
> > Regards, <>
> >Matthias
> >  <>
> > Am 11.02.19 um 20:56 schrieb Damjan Jovanovic:
> >> On Mon, Feb 11, 2019 at 8:03 PM Jim Jagielski 
> <mailto:j...@jagunet.com> wrote:
> >>
> >>> Uggg
> >>>
> >>> looks like breakage from the solenv port to gbuild???
> >>>
> >>>
> >> Are you sure?
> >>
> >> I don't see how, it's a very simple port.
> >>
>
>


Re: macOS on trunk broken again

2019-02-12 Thread Damjan Jovanovic
Linux should be fixed in commit 1853456.

That commit involved Mac too.

On Tue, Feb 12, 2019 at 5:02 PM Matthias Seidel 
wrote:

> Linux64 and Linux32 also break, but in in pyuno:
>
>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/pyuno/unxlngx6.pro/misc/logs/prj.txt
>
>
> https://ci.apache.org/projects/openoffice/buildlogs/linux32/main/pyuno/unxlngi6.pro/misc/logs/prj.txt
>
> Maybe it is related?
>
> Regards,
>
>Matthias
> Am 11.02.19 um 20:56 schrieb Damjan Jovanovic:
>
> On Mon, Feb 11, 2019 at 8:03 PM Jim Jagielski  
>  wrote:
>
>
> Uggg
>
> looks like breakage from the solenv port to gbuild???
>
>
>
> Are you sure?
>
> I don't see how, it's a very simple port.
>
>
>


  1   2   3   4   5   6   >