Re: [VOTE] Release AOO 4.1.10-RC2 as GA

2021-04-26 Thread Don Lewis
The Release Candidate is good for production/GA:

[X] yes / +1

[ ] no / -1

My vote is based on

[ ] binding (member of PMC)

[X] I have built and tested the RC from source on platform [FreeBSD]

[ ] I have tested the binary RC on platform [ ]


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



Re: Apache OpenOffice 4.1.10-RC2

2021-04-21 Thread Don Lewis
On 20 Apr, Jim Jagielski wrote:
> Before we call a vote, I'd like to ask as many people as possible to give the 
> 2nd release candidate of AOO 4.1.10 a good, solid test.
> 
> The source files and complimentary community builds for this RC can be found 
> at:
> 
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.10-RC2/

Looking good so far on FreeBSD.

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



Re: Fwd: [libexpat/libexpat] Release R_2_3_0 - 2.3.0

2021-03-26 Thread Don Lewis
On 25 Mar, Matthias Seidel wrote:
> Hi all,
> 
>> #422 #426 #447 Windows: Drop support for Visual Studio <=14.0/2015
> 
> Seems, we are out of look here due to the ancient compiler we still use
> on Windows...

Same with nss.  I suspect lack of C99 support is the issue.


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



Re: [VOTE] Release AOO 4.1.9-RC1 as GA

2021-01-18 Thread Don Lewis
 [X] yes / +1

 [ ] no / -1

My vote is based on

 [ ] binding (member of PMC)

 [X] I have built and tested the RC from source on platform [FreeBSD]

 [ ] I have tested the binary RC on platform [ ]

On 18 Jan, Jim Jagielski wrote:
> I am calling a VOTE on releasing the source and complimentary community 
> builds of
> Apache OpenOffice 4.1.9-RC1 as GA.
> 
> These artifacts can be found at:
> 
>https://dist.apache.org/repos/dist/dev/openoffice/4.1.9-RC1/
> 
> Please cast your vote:
> 
> The Release Candidate is good for production/GA:
> 
>  [ ] yes / +1
> 
>  [ ] no / -1
> 
> My vote is based on
> 
>  [ ] binding (member of PMC)
> 
>  [ ] I have built and tested the RC from source on platform [ ]
> 
>  [ ] I have tested the binary RC on platform [ ]
> 
> This vote will be open for 96hrs instead of the normal 72hrs to
> accommodate the US Holiday.
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 



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



Re: AOO 4.1.9 Info - bug 127952

2021-01-06 Thread Don Lewis
On  6 Jan, Jim Jagielski wrote:
> 
> 
>> On Jan 6, 2021, at 9:19 AM, Arrigo Marchiori  wrote:
>> 
>> Hello All,
>> 
>> 
>> - My own build of trunk on Linux can open the file.
>> 
>> Do you think that this is worth more investigation before releasing
>> 4.1.9?
>> 
> 
> AFAICT, it is not a regression (trunk and 4.1.x are very different)... So I 
> don't
> think it should hold off 4.1.9-RC1 IMO

Agreed.  Who knows how long this would take to understand, fix, and
test.   In the meantime, there are a lot of Big Sur users waiting on
4.1.9.



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



Re: issue with dmake clean

2020-12-16 Thread Don Lewis
On 16 Dec, Arrigo Marchiori wrote:
> Hello all,
> 
> On Tue, Dec 15, 2020 at 05:56:48PM -0500, Carl Marcum wrote:
> 
>> On 12/15/20 3:37 PM, Peter Kovacs wrote:
>> > 
>> > On 15.12.20 20:14, Jim Jagielski wrote:
>> > > 
>> > > > On Dec 15, 2020, at 12:57 PM, Matthias Seidel
>> > > >  wrote:
>> > > > 
>> > > > Hi Carl,
>> > > > 
>> > > > Am 13.12.20 um 23:43 schrieb Carl Marcum:
>> > > > > Hi Matthias,
>> > > > > 
>> > > > > On 12/13/20 4:29 PM, Matthias Seidel wrote:
>> > > > > > Hi Carl,
>> > > > > > 
>> > > > > > Am 13.12.20 um 19:02 schrieb Carl Marcum:
>> > > > > > > Hi all,
>> > > > > > > 
>> > > > > > > Just ran into something.
>> > > > > > > 
>> > > > > > > I ran 'dmake clean' from main probably without having ran source
>> > > > > > >  and it removed all of my directories under 
>> > > > > > > main.
>> > > > > > Tried to do that on Windows (Cygwin64), went into main,
>> > > > > > did "autoconf",
>> > > > > > "dmake clean":
>> > > > > > 
>> > > > > > $ dmake clean
>> > > > > > -bash: dmake: command not found
>> > > > > > 
>> > > > > > Only after "source winenv.set.sh" it did clean up what it should...
>> > > > > It could be because I have a built and installed dmake on my system.
>> > > > > 
>> > > > > Thanks for checking!
>> > > > If an installed dmake does have this consequence we should have
>> > > > a closer
>> > > > look at it...
>> > > > 
>> > > It must be getting those commands from a makefile somewhere
>> > > though... dmake itself has no concept of 'clean' independent of what
>> > > a makefile tells it it is AFAIK
>> > 
>> > there is a makefile on that level. However I think it is for make and
>> > not for dmake. At least when I want to reset the build for sure I do a
>> > dmake clean (from instsetoo_native)first, followed by a make clean
>> > (main).
>> > 
>> > And the make clean has this rm command and removes all sorts of stuff.
>> > Could it be that if you execute dmake clean on main folder will let
>> > dmake read the make file ment for gnumake?
> [...]
>> I've had it happen twice now and it's a pain when it happens but probably
>> not dmake's fault.
> 
> If main/makefile.mk is used by dmake, then that could be the culprit.
> 
> The clean target does:
> 
>> clean .PHONY:
>> -rm -rf */$(INPATH)
> [... the rest is uninportant ...]
> 
> The INPATH variable is set by the Env.sh script
> If the env.sh script is not set, then the command is interpreted as:
> rm -rf */
> 
> I don't know dmake, but if it was GNU Make a possible fix would be
> something like:
> 
>> clean .PHONY:
>> if [ -z "$(INPATH)" ]; then echo "Environment not set!"; exit 1; fi
>> -rm -rf */$(INPATH)
> [... the rest same as above ...]

Something like that is what I would recommend.



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



Re: Updates to ./configure(.ac)

2020-12-09 Thread Don Lewis
On  9 Dec, Jim Jagielski wrote:
> 
> 
>> On Dec 9, 2020, at 9:56 AM, Mechtilde  wrote:
>> 
>> Hello Jim,
>> 
>>> 
>>> So I was thinking we just have these 3:
>>> 
>>> --with-epm
>>> --with-dmake
>>> --with-beanshell
>> 
>> I want to differ whether we build with system version or with separate
>> version like in ext_sources.
> 
> Can you provide an example?
> 
> For example, say we want to use the system version of dmake... We could do 
> either
> 
>   --with-dmake
> 
> which would look in the user's $PATH for dmake and use that one; or they 
> could do
> 
>   --with-dmake=/opt/local/bin/dmake
> 
> which would use the system version located in /opt/local/bin
> 
> If instead, one used:
> 
>   
> --with-dmake=https://github.com/jimjag/dmake/archive/v4.13.1/dmake-4.13.1.tar.gz
> 
> It would download that distro and build and not use any local/system versions.
> 
> Does that make it more clear?

For dmake, we always need it, so --without-dmake would neve make sense.
For the path vs. url cases, we would need to add code to parse the
argument to decide whether we need need to do a download and build and
point the path at the result of the build, or whether we can just use
the argument as a full path.  In addition to https, the URL could
theoretically be ftp or a local file.  This touches both configure and
bootstrap.

I haven't looked at the beanshell stuff enough to comment.





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



Re: Configure missing gtk-plugin

2020-12-06 Thread Don Lewis
On  7 Dec, Peter Kovacs wrote:
> Hello all,
> 
> I haave an issue with configuring I am unfammiliar with.
> 
> configure: error: requirements to build the gtk-plugin not met. Use
> --disable-gtk or install the missing packages
> 
> What does this mean? I did not find this in any package.
> 
> I installed gtk2 and gst-plugin-gtk (which are the package names that 
> are given by arch.)
> 
> And I do not see any different requiremments in the guide.

configure is looking for:
gtk+-2.0 >= 2.4
gdk-pixbuf-xlib-2.0 >= 2.2
gthread-2.0

What OS are you building on?


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



Re: Help w/ bt

2020-12-02 Thread Don Lewis
On  2 Dec, 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?

I don't think I've used it recently, but it has worked in the past on
linux and FreeBSD.


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



Re: [openoffice] branch trunk updated: Huge updates to macOS UNO bridges, based on FreeBSD and Linux.

2020-12-01 Thread Don Lewis
On  1 Dec, j...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> jim 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 d73dd1d  Huge updates to macOS UNO bridges, based on FreeBSD and 
> Linux.
> d73dd1d is described below
> 
> commit d73dd1d32e12ca3b96b7bbfff854b742992ff915
> Author: Jim Jagielski 
> AuthorDate: Tue Dec 1 16:59:54 2020 -0500
> 
> Huge updates to macOS UNO bridges, based on FreeBSD and Linux.
> 
 
> diff --git a/main/bridges/source/cpp_uno/gcc3_freebsd_x86-64/except.cxx 
> b/main/bridges/source/cpp_uno/gcc3_freebsd_x86-64/except.cxx
> index 7902bd9..bfe18db 100644
> --- a/main/bridges/source/cpp_uno/gcc3_freebsd_x86-64/except.cxx
> +++ b/main/bridges/source/cpp_uno/gcc3_freebsd_x86-64/except.cxx
> @@ -187,7 +187,7 @@ type_info * RTTI::getRTTI( 
> typelib_CompoundTypeDescription *pTypeDescr ) SAL_THR
>  type_info * base_rtti = getRTTI(
>  (typelib_CompoundTypeDescription 
> *)pTypeDescr->pBaseTypeDescription );
>  rtti = new __si_class_type_info(
> -strdup( rttiName ), static_cast<__class_type_info 
> *>(base_rtti) );
> +strdup( rttiName ), (__class_type_info *)base_rtti );
>  }
>  else
>  {

What is the reason for this change?  static_cast is the more correct C++
way as opposed to a C-style cast.


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



Re: [OPINION VOTE] CentOS7 or Ubuntu 14.04

2020-11-10 Thread Don Lewis
On 10 Nov, Jim Jagielski wrote:
> CentOS7: glibc 2.17
> Ubuntu 14.04: glibc 2.19 
> 
> Since CentOS7 emulates the "super stable" worldview of RHEL, the
> CentOS7 version will likely always be the older one.

In that case I think a Ubuntu build is unlikely to run on CentOS 7.


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



Re: [OPINION VOTE] CentOS7 or Ubuntu 14.04

2020-11-10 Thread Don Lewis
On 10 Nov, 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?

What are the gcc/glibc versions of both?  If we build on the distro with
the newer versions, the result won't run on the older version.


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



upgrade notifications once we release 4.2.0

2020-11-09 Thread Don Lewis
For 4.2.0, we are talking about building on CentOS 7.  Therefore some of
platforms that we currently support won't support 4.2.0, in particular
CentOS 5, which is currently EOL and CentOS 6, which is still supported
upstream, at least for now the last time I looked.

If a user is running on an older platform, it would seem to be unhelpful
for them to be notified about 4.2.x releases, but we would want them to
see a possible 4.1.9 release.  Users on newer platforms should be
steered towards 4.2.x.

Thoughts?


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



Re: update NSS libraries

2020-11-07 Thread Don Lewis
On  7 Nov, John D'Orazio wrote:
> Hello all, ss I continue building and debugging the next release of my
> Writer add-on, in which I'm attempting to include the *Chrome Embedded
> Framework* in it's Java flavoured build (I'm using the builds from this
> release
> 
> ), I've stumbled upon the following situation in my Linux build:
> 
> The Chrome Embedded Framework is requiring a *libnss3.so* and
> *libnssutil3.so* version of at least *3.22*, however OpenOffice also
> utilizes these libraries and is packaging version *3.14*. Since the
> OpenOffice libraries are the first ones picked up (I believe from the
> *LD_LIBRARY_PATH* environment variable or similar), it is preventing my
> add-on from building, complaining that CEF needs at least version 3.22. As
> a test, I went and backed up the *libnss3.so* and *libnssutil3.so* found in*
> /opt/openoffice4/program/* , and I copied my system's libraries to that
> same folder. My system's libraries are at version *3.49* . After this I was
> able to build the add-on and debug->run in OpenOffice, and at least at
> first sight I didn't see any adverse effects in OpenOffice from the newer
> NSS libraries.
> 
> Would it be feasible to update the NSS libraries in a next release of
> OpenOffice, say 4.1.9? Carl Marcum was just confirming that in the current
> 4.1.8 release the packaged libraries are in fact at version 3.14.

4.1.8 was upgraded to nss 3.25.  This pull request
https://github.com/apache/openoffice/pull/100 will get us to 3.39, but it
has not even been merged to trunk because we haven't had the resources
to test it because of the push to get AOO 4.1.8 out the door.  It should
be possible to get it into 4.1.9.

It would be nice to get fully up to date, but newer versions of nss use
a lot of C99, which is not supported by the ancient Visual C++ that we
use.


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



Re: [VOTE] Release AOO 4.1.8-RC2 as GA

2020-11-03 Thread Don Lewis
On  2 Nov, Jim Jagielski wrote:
> I am calling a VOTE on releasing the source and complimentary community 
> builds of
> Apache OpenOffice 4.1.8-RC3 as GA.
> 
> These artifacts can be found at:
> 
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.8-RC3/
> 
> Please cast your vote:
 
The Release Candidate is good for production/GA:

  [X] yes / +1

  [ ] no / -1

My vote is based on

  [ ] binding (member of PMC)

  [X] I have built and tested the RC from source on platform [CentOS 5, Debian 
9, FreeBSD 10]

  [ ] I have tested the binary RC on platform [ ]


Notes:
  I did a 32-bit build on CentOS 5 and tested that build on CentOS 5 and
  Ubuntu 16.

  I did a 64-bit build on Debian 9 and tested that build on Debian 9

  I did 32-bit and 64-bit builds on FreeBSD 11, 12, and 13.  I tested
  the 64-bit FreeBSD 11 build.


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



Re: 4.1.8-RC3

2020-11-02 Thread Don Lewis
On  1 Nov, Pedro Lino wrote:
> Hi Don
> 
>> On 11/01/2020 5:55 PM Don Lewis  wrote:
> 
>> What about AOO418?
> 
> Apparently this issue only happened with my own build. It does not occur with 
> the official 418 RC3 build compiled by Jim
> (I mentioned this in a previous email)
> 
> So there is no need to worry about branch 418, only 42x and trunk.
> 
> I will test this tomorrow and report back.

I think it depends on the configure options.  Either of this will cause
the gconf library to end up in the core01 package:
  --enable-gconf --enable-gnome-vfs --enable-lockdown
  --enable-gconf --enable-gio

i think --enable-gconf and --enable-gnome-vfs are defaulted to on in
AOO418, but --enable-lockdown is not.  I haven't looked at the official
build script to see what options are set there.



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



Re: 4.1.8-RC3

2020-11-01 Thread Don Lewis
On  1 Nov, Matthias Seidel wrote:
> Hi Don,
> 
> Thanks for the update!
> 
> @Pedro: Does that solve the problem? If yes, could you set the issue to
> "RESOLVED"?

What about AOO418?


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



Re: 4.1.8-RC3

2020-10-31 Thread Don Lewis
On 31 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> Am 31.10.20 um 13:58 schrieb Don Lewis:
>> On 30 Oct, Pedro Lino wrote:
>>> Just recompiled AOO 4.1.8 on another Ubuntu 18.04.5 x64 without issues.
>>>
>>> Installing 4.1.8 over 4.1.7 end with error reported 2 years ago
>>>
>>> https://bz.apache.org/ooo/show_bug.cgi?id=127774
>> I just updated that ticket with some new information.  It is possible to
>> debug this by rebuilding just the scp2 module and looking at
>> scp2/unxlngx6.pro/bin/osl/setup_osl.ins
> 
> It would be great if we could work that out, since this is a release
> blocker for 4.2.0.

I think I have the immediate problem fixed, but there are still quite a
few mismatches between the gids defined and the gids referenced by
modules.

When building setup_osl.ins, these gids are referenced, but are not
defined:
gid_File_Share_Config_Sofficecfg_Dbubrowser_Menubar_Xml
gid_File_Extra_Urlmore_Math
gid_File_Tmp_Userinstall_Pocketpcword_Inf
gid_File_Exe_Regdeinstall
gid_File_Jar_Sandbox
gid_Brand_File_Share_Xdg_Extension
gid_File_Lib_Dfa
gid_File_Jar_Activation
gid_File_Exe_Nsplugin
gid_File_Lib_Policy_Cli_Cppuhelper_Config
gid_File_Lib_Wpft
gid_File_Lib_Hhc_Word
gid_File_Res_Tfu
gid_File_Exe_Uno
gid_File_Extra_Gallwwwanim
gid_File_Extra_Tplwizletter_ko
gid_File_Lib_Mingw_Stdcpp
gid_File_Tmp_Inf_Oldreg
gid_File_Lib_Sndfile
gid_File_Lib_AVMediaGst
gid_File_Res_Tab
gid_File_Lib_Sogpstarter
gid_File_Tmp_Userinstall_Draw_Inf
gid_File_Xsl_Export_Xhtml_Master_Document
gid_File_Lib_GdiPlusCanvas
gid_File_Xsl_Export_Xhtml_Master_Refs_Workaround
gid_File_Lib_Zip
gid_File_Kspprof_Ini
gid_File_Extra_Urltasks_Impress
gid_File_Lib_DirectX9Canvas
gid_File_Bin_Gengal
gid_File_Tabaction
gid_File_Bin_Cde_Smemo
gid_File_Dl_Policy_Cli_Ure_Assembly
gid_File_Lib_Mingw_Stdcpp_Ure
gid_File_Lib_Vclplug_Kde4
gid_File_Lib_I18n
gid_File_Lib_Qslnkmsi
gid_File_Lib_Ole
gid_File_Py_Scriptprovider
gid_File_Lib_Mingw_GccS_Ure
gid_File_Jar_Bsh
gid_File_Res_Stt
gid_File_Lib_Lprxw
gid_File_Tmp_Userinstall_Pocketpcexcel_Inf
gid_Brand_File_Lib_Dbghelp
gid_File_Lib_Reg4allmsdoc
gid_File_Sp_Jlsf_Mcd
gid_Brand_File_Res_Oirm
gid_File_Bin_Cde_Slabel
gid_File_Fnt_LiberationSans_Italic
gid_File_Bmp_Installation
gid_File_Lib_Kab_Drv_1
gid_File_Lib_Tfu
gid_File_Extra_Urltasks_Calc
gid_File_Extra_Urlnew_Math
gid_File_Lib_Gconfebe
gid_File_Lib_Pl
gid_File_Lib_Policy_Cli_Oootypes_Config
gid_File_Extra_Tplwizmemo_Lang
gid_File_Lib_Policy_Cli_Cppuhelper_Assembly
gid_File_Bin_Cde_Svcard
gid_File_Lib_Macbe
gid_File_Res_Productregistration
gid_File_Jar_Email
gid_File_Dl_Policy_Cli_Uretypes_Config
gid_File_ImagesTango_Zip
gid_File_Lib_Fop
gid_File_Server_Bonobo_Presentationstarter
gid_File_Extra_Tplwizletter_it
gid_File_Xsl_Export_Common_Styles_Style_Mapping_html32
gid_File_Lib_Hunspell
gid_File_Dl_Policy_Cli_Basetypes_Config
gid_File_Share_Config_Sofficecfg_Draw_Menubar_Xml
gid_File_Share_Config_Sofficecfg_Dburelation_Menubar_Xml
gid_File_Lib_Dtrans
gid_File_Dl_Policy_Cli_Cppuhelper_Assembly
gid_Brand_File_Bin_Crashreport_Script
gid_File_Dl_Uwinapi
gid_File_Extra_Autotextuser_Lang
gid_File_Lib_LibXMLSec_xmlsecnss
gid_File_Lib_Ado
gid_File_Lib_Mingw_GccS
gid_File_Lib_LibXMLSec_xmlseccore
gid_File_Lib_Neon
gid_File_Share_Registry_Forcedefault_Xcd
gid_File_Dl_Cli_Ure_Assembly
gid_File_Shellnew_Ods_Soffice
gid_File_Res_Tk
gid_File_Exe_Sweb
gid_File_Share_Config_Sofficecfg_Dbuapp_Menubar_Xml
gid_File_Fnt_LiberationSerif_Regular
gid_Brand_File_Bin_Unopkgcom
gid_File_Extra_Urlstart_Draw
gid_File_Extra_Urlstart_Calc
gid_File_Fnt_LiberationMono_Regular
gid_File_Lib_relnotes
gid_File_Share_Config_Sofficecfg_Dbutable_Menubar_Xml
gid_File_Sp_Adsf_Mcd
gid_File_Res_Gallery
gid_File_Dl_Cli_Uretypes_Assembly
gid_File_Dl_Policy_Cli_Cppuhelper_Config
gid_File_Lib_Bat
gid_File_Sp_Subm_Mcd
gid_File_Fnt_LiberationSans_Regular
gid_File_Shellnew_Odp_Soffice
gid_File_Exe_Userinst
gid_Brand_File_Lib_Oirm2
gid_File_Profile_Gengal
gid_File_Fnt_LiberationSerif_BoldItalic
gid_File_Dl_Cli_Uno
gid_File_Sp_Klsf_Mcd
gid_Brand_File_Lib_Npsoplugin
gid_File_Lib_Agg
gid_File_Lib_Onlinecheck
gid_File_Fnt_LibSansNarrow_Bold
gid_File_Lib_Macab_Drv_1
gid_File_Extra_Urlnew_Draw
gid_File_Extra_Urldesktop_Calc
gid_File_Dl_Policy_Cli_Ure_Config
gid_File_Lib_Sysdtrans
gid_File_Fnt_LiberationSans_BoldItalic
gid_File_Lib_Kab_1
gid_File_Exe_Adabas
gid_File_Lib_LibXMLSec_xmlsecmscrypto
gid_File_Lib_Lks
gid_File_Fn

Re: 4.1.8-RC3

2020-10-31 Thread Don Lewis
On 30 Oct, Pedro Lino wrote:
> Just recompiled AOO 4.1.8 on another Ubuntu 18.04.5 x64 without issues.
> 
> Installing 4.1.8 over 4.1.7 end with error reported 2 years ago
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=127774

I just updated that ticket with some new information.  It is possible to
debug this by rebuilding just the scp2 module and looking at
scp2/unxlngx6.pro/bin/osl/setup_osl.ins

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



Re: 4.1.8-RC3

2020-10-29 Thread Don Lewis
On 29 Oct, Jim Jagielski wrote:
> I think we are ready for 4.1.8-RC3. I'll start Linux and macOS builds.

Building on CentOS 5 and running both on CentOS 5 and Ubuntu 16 seem to
work.


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



Re: [openoffice] branch AOO418 updated: Fix redland build issues when using CentOS5 as build and later platforms as user. Squash General Error.

2020-10-29 Thread Don Lewis
trunk and AOO42X should also get this fix.

On 29 Oct, j...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> jim pushed a commit to branch AOO418
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
> 
> 
> The following commit(s) were added to refs/heads/AOO418 by this push:
>  new 18848f5  Fix redland build issues when using CentOS5 as build and 
> later platforms as user. Squash General Error.
> 18848f5 is described below
> 
> commit 18848f57b67aa11f5b2c6c4b82e9d93676d1b57a
> Author: Jim Jagielski 
> AuthorDate: Thu Oct 29 07:39:50 2020 -0400
> 
> Fix redland build issues when using CentOS5 as build and later platforms 
> as user. Squash General Error.
> ---
>  main/redland/raptor/makefile.mk | 2 +-
>  main/redland/rasqal/makefile.mk | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/main/redland/raptor/makefile.mk b/main/redland/raptor/makefile.mk
> index 51b7876..0c8b6a4 100644
> --- a/main/redland/raptor/makefile.mk
> +++ b/main/redland/raptor/makefile.mk
> @@ -128,7 +128,7 @@ XSLTLIB!:=$(XSLTLIB) # expand dmake variables for 
> xslt-config
>  CONFIGURE_DIR=
>  CONFIGURE_ACTION=.$/configure
>  # do not enable grddl parser (#i93768#)
> -CONFIGURE_FLAGS=--disable-static --disable-gtk-doc --enable-parsers="rdfxml 
> ntriples turtle trig guess rss-tag-soup" --with-www=xml 
> --prefix=$(PDW)/$(OUT) --includedir=$(PWD)/$(INCCOM) --libdir=$(PWD)/$(LB)
> +CONFIGURE_FLAGS=--with-threads --with-curl-config=no --with-icu-config=no 
> --disable-static --disable-gtk-doc --enable-parsers="rdfxml ntriples turtle 
> trig guess rss-tag-soup" --without-bdb --without-sqlite --without-mysql 
> --without-postgresql --without-threestore --with-regex-library=posix 
> --with-decimal=none --with-www=xml --prefix=$(PDW)/$(OUT) 
> --includedir=$(PWD)/$(INCCOM) --libdir=$(PWD)/$(LB)
>  .IF "$(SYSTEM_LIBXML)" == "NO"
>  
> CONFIGURE_FLAGS+=--with-xml2-config=${SOLARVERSION}/${INPATH}/bin/xml2-config 
> \
>   --with-xslt-config=${SOLARVERSION}/${INPATH}/bin/xslt-config
> diff --git a/main/redland/rasqal/makefile.mk b/main/redland/rasqal/makefile.mk
> index 72a4368..b95d8ca 100644
> --- a/main/redland/rasqal/makefile.mk
> +++ b/main/redland/rasqal/makefile.mk
> @@ -125,7 +125,7 @@ XSLTLIB!:=$(XSLTLIB) # expand dmake variables for 
> xslt-config
>  
>  CONFIGURE_DIR=
>  CONFIGURE_ACTION=.$/configure PATH="..$/..$/..$/bin:$$PATH" 
> RASQAL_CFLAGS=-I${PWD}$/..$/${INPATH}/inc 
> RASQAL_LIBS="-L${PWD}/..$/${INPATH}/lib -lrasqual" 
> RAPTOR2_CFLAGS=-I${PWD}$/..$/${INPATH}/inc 
> RAPTOR2_LIBS="-L${PWD}/..$/${INPATH}/lib -lraptor2" 
> PKG_CONFIG_PATH="../raptor2-2.0.15:../rasqal-0.9.33"
> -CONFIGURE_FLAGS=--disable-static --disable-gtk-doc 
> --with-regex-library=posix --with-decimal=none
> +CONFIGURE_FLAGS=--disable-static --disable-gtk-doc 
> --with-regex-library=posix --with-decimal=none --with-libgcrypt-config=no
>  .IF "$(SYSTEM_LIBXML)" == "NO"
>  CONFIGURE_FLAGS+=--with-xml2-config=${SOLARVERSION}/${INPATH}/bin/xml2-config
>  .ENDIF
> 


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



Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

2020-10-29 Thread Don Lewis
On 28 Oct, Don Lewis wrote:
> On 28 Oct, Don Lewis wrote:
>> On 27 Oct, Don Lewis wrote:
>>> On 27 Oct, Jim Jagielski wrote:
>>>> Maybe... but it DID WORK before. That is, before the mega patch,
>>>> configure did the "right thing". So if something is causing configure
>>>> to make a different decision, it is due to the interaction w/ the new
>>>> stuff that the RDF stuff does. The problem is with the patch or how it
>>>> is working...
>>> 
>>> I'm thinking of any configure scripts used by raptor / rasqal / redland,
>>> which would have changed by the upgrade.
>> 
>> I took a look at the configure outputs for those three.  I did see some
>> significant differences for redland.  In particular, on CentOS 5,
>> redland was picking up a system version of curl.  I think I installed a
>> newer version of curl, liked with a modern verson of openssl so a newer
>> version of git would work with github.  Thinking that librdf might have
>> been linked to the system libcurl, I uninstalled curl on the CentOS5 box
>> and did a another rebuild.  I still saw breakage when I installed the
>> packages on Ubuntu 16.
>> 
>> Digging in some more, I ran ldd on the librdf.so that we build and
>> discovered that libgcrypt was not being found.  On CentOS 5, libgcrypt
>> is version 11.5.2 and on Ubuntu 16 it is 20.0.5.  That's a problem.  I
>> wonder if redland actually needs libgcrypt for our purposes.
> 
> libraptor2 wants to link to the system icu libraries.  I haven't quite
> figured out why raptor2 wants to use icu and the older raptor library
> does not seem to need it.

>From http://librdf.org/raptor/RELEASE.html, please read the last
paragraph:

Raptor2 2.0.7 changes

CVE-2012-0037 fixed

Issues Fixed:

448: Turtle parser does not return error status from 
turtle_parse_chunk()
469: Allow rapper to bypass server SSL certs checks in libcurl

Removed Expat support since expat has not had a release in years and
libxml2 works well. This allows some code simplification. Updated
configure so that if Raptor is configured with no parser that requires
an XML parser, libxml2 will not be required.

Removed internal Unicode NFC checking code used for checking RDF/XML
literals conformance which was expensive to check and a large of
compiled-in static dataset that was rather out of date. Replaced with
optional compiled use of ICU. If ICU is not explicitly configured, no
literal checking is done.


I think I've got a patch that eliminates the ICU dependency.


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



Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

2020-10-28 Thread Don Lewis
On 28 Oct, Don Lewis wrote:
> On 27 Oct, Don Lewis wrote:
>> On 27 Oct, Jim Jagielski wrote:
>>> Maybe... but it DID WORK before. That is, before the mega patch,
>>> configure did the "right thing". So if something is causing configure
>>> to make a different decision, it is due to the interaction w/ the new
>>> stuff that the RDF stuff does. The problem is with the patch or how it
>>> is working...
>> 
>> I'm thinking of any configure scripts used by raptor / rasqal / redland,
>> which would have changed by the upgrade.
> 
> I took a look at the configure outputs for those three.  I did see some
> significant differences for redland.  In particular, on CentOS 5,
> redland was picking up a system version of curl.  I think I installed a
> newer version of curl, liked with a modern verson of openssl so a newer
> version of git would work with github.  Thinking that librdf might have
> been linked to the system libcurl, I uninstalled curl on the CentOS5 box
> and did a another rebuild.  I still saw breakage when I installed the
> packages on Ubuntu 16.
> 
> Digging in some more, I ran ldd on the librdf.so that we build and
> discovered that libgcrypt was not being found.  On CentOS 5, libgcrypt
> is version 11.5.2 and on Ubuntu 16 it is 20.0.5.  That's a problem.  I
> wonder if redland actually needs libgcrypt for our purposes.

libraptor2 wants to link to the system icu libraries.  I haven't quite
figured out why raptor2 wants to use icu and the older raptor library
does not seem to need it.


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



Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

2020-10-28 Thread Don Lewis
On 27 Oct, Don Lewis wrote:
> On 27 Oct, Jim Jagielski wrote:
>> Maybe... but it DID WORK before. That is, before the mega patch,
>> configure did the "right thing". So if something is causing configure
>> to make a different decision, it is due to the interaction w/ the new
>> stuff that the RDF stuff does. The problem is with the patch or how it
>> is working...
> 
> I'm thinking of any configure scripts used by raptor / rasqal / redland,
> which would have changed by the upgrade.

I took a look at the configure outputs for those three.  I did see some
significant differences for redland.  In particular, on CentOS 5,
redland was picking up a system version of curl.  I think I installed a
newer version of curl, liked with a modern verson of openssl so a newer
version of git would work with github.  Thinking that librdf might have
been linked to the system libcurl, I uninstalled curl on the CentOS5 box
and did a another rebuild.  I still saw breakage when I installed the
packages on Ubuntu 16.

Digging in some more, I ran ldd on the librdf.so that we build and
discovered that libgcrypt was not being found.  On CentOS 5, libgcrypt
is version 11.5.2 and on Ubuntu 16 it is 20.0.5.  That's a problem.  I
wonder if redland actually needs libgcrypt for our purposes.



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



Re: building from a source tarball

2020-10-28 Thread Don Lewis
On 28 Oct, Jim Jagielski wrote:
> In particular, this is when building from the "official" SRC_RELEASE
> tarball we provide. Is the inc/reporevision.lst file not included?

It is in one of the RCs that I looked at.


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



Re: building from a source tarball

2020-10-28 Thread Don Lewis
On 28 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> This should be working since last year?
> 
> https://github.com/apache/openoffice/commit/0c6d6194a959cb1b87417e9077dc1d8ece630b11

Item #2 here:
  
https://lists.apache.org/thread.html/r228db9ac55fc89c7286943f31cfd862d944c45264cdd6f662dc2a8f9%40%3Cdev.openoffice.apache.org%3E

> Regards,
> 
>    Matthias
> 
> Am 28.10.20 um 18:33 schrieb Don Lewis:
>> Something that we are still missing for AOO418 is a  fix for getting the
>> revision info when building from a source tarball instead of a git
>> checkout.  Someone mentioned this a couple weeks ago.
>>
>>
>> -
>> 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



building from a source tarball

2020-10-28 Thread Don Lewis
Something that we are still missing for AOO418 is a  fix for getting the
revision info when building from a source tarball instead of a git
checkout.  Someone mentioned this a couple weeks ago.


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



Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

2020-10-27 Thread Don Lewis
On 27 Oct, Jim Jagielski wrote:
> Maybe... but it DID WORK before. That is, before the mega patch,
> configure did the "right thing". So if something is causing configure
> to make a different decision, it is due to the interaction w/ the new
> stuff that the RDF stuff does. The problem is with the patch or how it
> is working...

I'm thinking of any configure scripts used by raptor / rasqal / redland,
which would have changed by the upgrade.

> In any case, iirc we did compare the config.log files between 4.1.7
> and 4.1.8-RC2 and there was no pertinent difference between the 2...
> 
>> On Oct 27, 2020, at 5:24 PM, Don Lewis  wrote:
>> 
>> On 27 Oct, Jim Jagielski wrote:
>>> For completeness, and especially for those not following the thread,
>>> what we have conclusively shown is that it is NOT an issue w/ the
>>> build server, which is the same we've been using for several 4.1.x
>>> releases, nor with the configure and build parameters (also
>>> unchanged from previous). It is this mega patch which combines
>>> several upgrades in one large patch.
>>> 
>>> My thought is that w/ the change with the RDF libs, the patch either
>>> pulls in the wrong library (maybe the system library) for something,
>>> which causes issues w/ newer distros, or else it doesn't pull in a
>>> library and the one used by newer distros causes the problem.
>> 
>> Or maybe a configure script makes a different decision about the
>> system libraries on CentOS 5 (vs when building on something newer)
>> that causes the code not to work properly on newer distros.
>> 
>>>> On Oct 27, 2020, at 5:09 PM, Jim Jagielski  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Oct 27, 2020, at 2:34 PM, Don Lewis  wrote:
>>>>> 
>>>>> On 27 Oct, Jim Jagielski wrote:
>>>>>> Thanks all... I am now building the final 'git bisect' test,
>>>>>> based on
>>>>>> 
>>>>>>  
>>>>>> https://github.com/apache/openoffice/commit/f7070ae3689d0d34bf9dab3d31f56744d0df4784
>>>>>> 
>>>>>> assuming that this is good, it seems like 99% likely that the
>>>>>> problem arose with
>>>>>> 
>>>>>>  
>>>>>> https://github.com/apache/openoffice/commit/e9fab906a0063dca04a52bfc5270c9d70ccbbb27
>>>>>> 
>>>>>> the raptor / rasqal / redland mega patch. Which of those 3 is
>>>>>> unknown, but a quick look over seems to indicate that the raptor
>>>>>> upgrade was the most significant of the 3, but the redland patch
>>>>>> also seems to have some weird things (like no longer linking
>>>>>> openssl or libltdl) so who knows :/
>>>>> 
>>>>> Questions (which may be related):
>>>>> 
>>>>> Why does this only affect AOO418 and not AOO42X and trunk?
>>>>> 
>>>>> Why does this only seem to affect builds done on CentOS 5 and run
>>>>> on a newer distro and not when run on CentOS 5 and not when
>>>>> compiled on a newer distro?
>>>> 
>>>> If I knew those answers we wouldn't be wondering what is going on
>>>> and I wouldn't have had to create >15 test builds :-)
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>>>> commands, e-mail: dev-h...@openoffice.apache.org
>>>> <mailto:dev-h...@openoffice.apache.org>
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>> commands, e-mail: dev-h...@openoffice.apache.org
>> <mailto: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: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

2020-10-27 Thread Don Lewis
On 27 Oct, Jim Jagielski wrote:
> For completeness, and especially for those not following the thread,
> what we have conclusively shown is that it is NOT an issue w/ the
> build server, which is the same we've been using for several 4.1.x
> releases, nor with the configure and build parameters (also unchanged
> from previous). It is this mega patch which combines several upgrades
> in one large patch.
> 
> My thought is that w/ the change with the RDF libs, the patch either
> pulls in the wrong library (maybe the system library) for something,
> which causes issues w/ newer distros, or else it doesn't pull in a
> library and the one used by newer distros causes the problem.

Or maybe a configure script makes a different decision about the system
libraries on CentOS 5 (vs when building on something newer) that causes
the code not to work properly on newer distros.

>> On Oct 27, 2020, at 5:09 PM, Jim Jagielski  wrote:
>> 
>> 
>> 
>>> On Oct 27, 2020, at 2:34 PM, Don Lewis  wrote:
>>> 
>>> On 27 Oct, Jim Jagielski wrote:
>>>> Thanks all... I am now building the final 'git bisect' test, based
>>>> on
>>>> 
>>>>   
>>>> https://github.com/apache/openoffice/commit/f7070ae3689d0d34bf9dab3d31f56744d0df4784
>>>> 
>>>> assuming that this is good, it seems like 99% likely that the
>>>> problem arose with
>>>> 
>>>>   
>>>> https://github.com/apache/openoffice/commit/e9fab906a0063dca04a52bfc5270c9d70ccbbb27
>>>> 
>>>> the raptor / rasqal / redland mega patch. Which of those 3 is
>>>> unknown, but a quick look over seems to indicate that the raptor
>>>> upgrade was the most significant of the 3, but the redland patch
>>>> also seems to have some weird things (like no longer linking
>>>> openssl or libltdl) so who knows :/
>>> 
>>> Questions (which may be related):
>>> 
>>> Why does this only affect AOO418 and not AOO42X and trunk?
>>> 
>>> Why does this only seem to affect builds done on CentOS 5 and run on
>>> a newer distro and not when run on CentOS 5 and not when compiled on
>>> a newer distro?
>> 
>> If I knew those answers we wouldn't be wondering what is going on and
>> I wouldn't have had to create >15 test builds :-)
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>> commands, e-mail: dev-h...@openoffice.apache.org
>> <mailto: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: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

2020-10-27 Thread Don Lewis
On 27 Oct, Jim Jagielski wrote:
> Thanks all... I am now building the final 'git bisect' test, based on
> 
> 
> https://github.com/apache/openoffice/commit/f7070ae3689d0d34bf9dab3d31f56744d0df4784
> 
> assuming that this is good, it seems like 99% likely that the problem arose 
> with
> 
> 
> https://github.com/apache/openoffice/commit/e9fab906a0063dca04a52bfc5270c9d70ccbbb27
> 
> the raptor / rasqal / redland mega patch. Which of those 3 is unknown, but a 
> quick look over seems to indicate that the raptor upgrade was the most 
> significant of the 3, but the redland patch also seems to have some weird 
> things (like no longer linking openssl or libltdl) so who knows :/

Questions (which may be related):

Why does this only affect AOO418 and not AOO42X and trunk?

Why does this only seem to affect builds done on CentOS 5 and run on a
newer distro and not when run on CentOS 5 and not when compiled on a
newer distro?


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



Re: openssl upgrade for 4.1.8

2020-10-22 Thread Don Lewis
On 22 Oct, Jim Jagielski wrote:
> Regarding this commit:
> 
>
> https://github.com/apache/openoffice/commit/8d4c92f789718b2f73ea62d487811a0c9d476739
> 
> why the change 
> 
>   - CONFIGURE_ACTION=Configure linux-generic64
>   + CONFIGURE_ACTION=Configure linux-x86_64 no-dso no-shared $(NO_ASM)
> 
> that seems a major change to how we build openssl for AOO.

That's what we do in trunk/AOO42X.  The ASM stuff my use new
instructions that aren't supported on older hardware.

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



Re: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-22 Thread Don Lewis
On 21 Oct, Don Lewis wrote:
> On 21 Oct, Don Lewis wrote:
>> On 21 Oct, Jim Jagielski wrote:
>>> 
>>> 
>>>> On Oct 21, 2020, at 4:21 PM, Andrea Pescetti 
>>>> wrote:
>>>> 
>>>> It looks like we are getting closer I mean, we have a commit that
>>>> is only relevant to CentOS 5 and we know that Jim's builds are done
>>>> on CentOS 5 and have the bug, while the others (mine on CentOS 7;
>>>> Pedro's on Ubuntu 18) do not have it.
>>>> 
>>>> Possibly some build error that goes unnoticed due to a "dirty" build?
>>>> Otherwise I can't explain why Don's CentOS 5 tests passed...
>>>> 
>>> 
>>> I don't think anyone else tested Don's CentOS5 built builds... just
>>> himself. I think.
>> 
>> I only tested my CentOS 5 build on CentOS 5.  I think the problem only
>> occurs when running a CentOS 5 build on something newer (Ubuntu only?).
>> This sort of smells like a system library incompatability of some sort.
>> Things work when the build is done using the system headers that match
>> the destination environment, but the problem crops up if the build is
>> done with the CentOS 5 headers but the runtime libraries are from a
>> newer distro. The mystery is what changed between 4.1.7 and now to
>> trigger the problem.
> 
> I only have a 32-bit CentOS 5 VM.  My bare-metal Debian stretch machine
> is 64 bits, so I wasn't able to test the CentOS 5 build on Debian.
> 
> If I take the output from the 32-bit CentOS 5 build on a 32-bit Ubuntu
> 16 VM, I can reproduce the problem.  I'm currently building the same git
> revision on Ubuntu 16.  I suspect that I won't see the problem with that
> combo.

If I build the same git revision of AOO418 on Ubuntu 16, then install
and run it there, I do *not* see the General Error problem.


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



Re: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-22 Thread Don Lewis
On 21 Oct, Don Lewis wrote:
> On 21 Oct, Jim Jagielski wrote:
>> 
>> 
>>> On Oct 21, 2020, at 4:21 PM, Andrea Pescetti 
>>> wrote:
>>> 
>>> It looks like we are getting closer I mean, we have a commit that
>>> is only relevant to CentOS 5 and we know that Jim's builds are done
>>> on CentOS 5 and have the bug, while the others (mine on CentOS 7;
>>> Pedro's on Ubuntu 18) do not have it.
>>> 
>>> Possibly some build error that goes unnoticed due to a "dirty" build?
>>> Otherwise I can't explain why Don's CentOS 5 tests passed...
>>> 
>> 
>> I don't think anyone else tested Don's CentOS5 built builds... just
>> himself. I think.
> 
> I only tested my CentOS 5 build on CentOS 5.  I think the problem only
> occurs when running a CentOS 5 build on something newer (Ubuntu only?).
> This sort of smells like a system library incompatability of some sort.
> Things work when the build is done using the system headers that match
> the destination environment, but the problem crops up if the build is
> done with the CentOS 5 headers but the runtime libraries are from a
> newer distro. The mystery is what changed between 4.1.7 and now to
> trigger the problem.

I only have a 32-bit CentOS 5 VM.  My bare-metal Debian stretch machine
is 64 bits, so I wasn't able to test the CentOS 5 build on Debian.

If I take the output from the 32-bit CentOS 5 build on a 32-bit Ubuntu
16 VM, I can reproduce the problem.  I'm currently building the same git
revision on Ubuntu 16.  I suspect that I won't see the problem with that
combo.


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



Re: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-21 Thread Don Lewis
On 22 Oct, Matthias Seidel wrote:
> Hi Jim,
> 
> Am 21.10.20 um 20:48 schrieb Jim Jagielski:
>> In the meantime, please review main/writerfilter/source/doctok/resources.xsl 
>> on trunk and AOO42X
> 
> Windows Buildbot (AOO42X) just stopped with this error:
> 
> 1 module(s): writerfilter need(s) to be rebuilt Reason(s): ERROR: error
> 65280 occurred while making
> /cygdrive/e/slave14/openoffice-win7-41x/build/main/writerfilter/prj When
> you have fixed the errors in that module you can resume the build by
> running: build --from writerfilter

Sounds like
  test="string-length($shift)!=0"
doesn't work, which is odd ...

>>
>>> On Oct 21, 2020, at 2:41 PM, Don Lewis  wrote:
>>>
>>> On 21 Oct, Jim Jagielski wrote:
>>>> OK... so $shift is a number then, or should be? But sometimes $shift
>>>> is simply blank. And we want a black $shift to be evaluated as 0. So
>>>> if all that is correct, could we use number($shift)>0 ?
>>> The input file that generates the header doesn't specifiy $shift in
>>> all cases, so I assume that $shift is treated as an empty string.
>>>
>>> Something I thought would work was test="$shift" since either an empty
>>> string or a zero in a boolean context should evaluate to false, but for
>>> some reason it did not work.
>>>
>>> I didn't stumble across number() in my reading.  I don't know what
>>> number() would do in this situation.
>>>
>>>> I'm thinking this isn't the problem though with the failures :/
>>> Yeah, I think it's probably something else that went in at the same time,
>>> and I think also that build OS vs. deployment OS is part of the mix.
>>>
>>>>> On Oct 21, 2020, at 2:15 PM, Don Lewis  wrote:
>>>>>
>>>>> On 21 Oct, Jim Jagielski wrote:
>>>>>> Should that fix be just:
>>>>>>
>>>>>>   
>>>>> That would work, but it would produce a different output.  It would
>>>>> always put ">> $shift" in the output whenever $shift is nonblank. 
>>>>> The change that I committed only puts ">> $shift" in the output if
>>>>> $shift is nonblank and greater than zero.  This is what the original
>>>>> version does with older versions of libxslt, or when building on
>>>>> anything newer than CentOS 5.
>>>>>
>>>>>>> On Oct 21, 2020, at 11:37 AM, Jim Jagielski  wrote:
>>>>>>>
>>>>>>> I don't have it, but that was around the end of Aug right? So right
>>>>>>> around the time when a bunch of stuff was included like updates to
>>>>>>> nss, libxslt, libxml2...
>>>>>>>
>>>>>>> I'm trying to get my head around the logic of
>>>>>>>
>>>>>>>  
>>>>>>> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09
>>>>>>>
>>>>>>>> On Oct 21, 2020, at 10:58 AM, Matthias Seidel
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hi Jim,
>>>>>>>>
>>>>>>>> Am 21.10.20 um 16:54 schrieb Jim Jagielski:
>>>>>>>>> Let me double check.. I am rebuilding AOO417. Lets see if that
>>>>>>>>> works.
>>>>>>>>>
>>>>>>>>> PS: The one change that DID happen is that I upgraded Vmware
>>>>>>>>> Fusion, which I use to run the CentOS5 VMs. That should NOT make
>>>>>>>>> any difference. But we will see.
>>>>>>>>>
>>>>>>>>> I'll posted when my 4.1.7 test builds are ready. TIA!
>>>>>>>> To be clear, the last version that worked for me was 4.1.8.
>>>>>>>> But it was before we built Release Candidates.
>>>>>>>>
>>>>>>>> Unfortunately, I didn't keep it, but maybe you can upload it again?
>>>>>>>>
>>>>>>>>> -
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>>>>>>
>>>>>>>
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>>>>> commands, e-mail: dev-h...@openoffice.apache.org
>>>>> <mailto:dev-h...@openoffice.apache.org>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>>> <mailto:dev-unsubscr...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>>> <mailto: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: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-21 Thread Don Lewis
On 21 Oct, Jim Jagielski wrote:
> 
> 
>> On Oct 21, 2020, at 4:21 PM, Andrea Pescetti 
>> wrote:
>> 
>> It looks like we are getting closer I mean, we have a commit that
>> is only relevant to CentOS 5 and we know that Jim's builds are done
>> on CentOS 5 and have the bug, while the others (mine on CentOS 7;
>> Pedro's on Ubuntu 18) do not have it.
>> 
>> Possibly some build error that goes unnoticed due to a "dirty" build?
>> Otherwise I can't explain why Don's CentOS 5 tests passed...
>> 
> 
> I don't think anyone else tested Don's CentOS5 built builds... just
> himself. I think.

I only tested my CentOS 5 build on CentOS 5.  I think the problem only
occurs when running a CentOS 5 build on something newer (Ubuntu only?).
This sort of smells like a system library incompatability of some sort.
Things work when the build is done using the system headers that match
the destination environment, but the problem crops up if the build is
done with the CentOS 5 headers but the runtime libraries are from a
newer distro. The mystery is what changed between 4.1.7 and now to
trigger the problem.



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



Re: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-21 Thread Don Lewis
On 21 Oct, Jim Jagielski wrote:
> never mind this... it's not a matter of building. I can build fine. It
> just crashes on Ubuntu. no idea why.

Are you building on the same version of Ubuntu?


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



Re: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-21 Thread Don Lewis
On 21 Oct, Jim Jagielski wrote:
> OK... so $shift is a number then, or should be? But sometimes $shift
> is simply blank. And we want a black $shift to be evaluated as 0. So
> if all that is correct, could we use number($shift)>0 ?

The input file that generates the header doesn't specifiy $shift in
all cases, so I assume that $shift is treated as an empty string.

Something I thought would work was test="$shift" since either an empty
string or a zero in a boolean context should evaluate to false, but for
some reason it did not work.

I didn't stumble across number() in my reading.  I don't know what
number() would do in this situation.
  
> I'm thinking this isn't the problem though with the failures :/

Yeah, I think it's probably something else that went in at the same time,
and I think also that build OS vs. deployment OS is part of the mix.
 
>> On Oct 21, 2020, at 2:15 PM, Don Lewis  wrote:
>> 
>> On 21 Oct, Jim Jagielski wrote:
>>> Should that fix be just:
>>> 
>>>
>> 
>> That would work, but it would produce a different output.  It would
>> always put ">> $shift" in the output whenever $shift is nonblank. 
>> The change that I committed only puts ">> $shift" in the output if
>> $shift is nonblank and greater than zero.  This is what the original
>> version does with older versions of libxslt, or when building on
>> anything newer than CentOS 5.
>> 
>>> 
>>>> On Oct 21, 2020, at 11:37 AM, Jim Jagielski  wrote:
>>>> 
>>>> I don't have it, but that was around the end of Aug right? So right
>>>> around the time when a bunch of stuff was included like updates to
>>>> nss, libxslt, libxml2...
>>>> 
>>>> I'm trying to get my head around the logic of
>>>> 
>>>>   
>>>> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09
>>>> 
>>>>> On Oct 21, 2020, at 10:58 AM, Matthias Seidel
>>>>>  wrote:
>>>>> 
>>>>> Hi Jim,
>>>>> 
>>>>> Am 21.10.20 um 16:54 schrieb Jim Jagielski:
>>>>>> Let me double check.. I am rebuilding AOO417. Lets see if that
>>>>>> works.
>>>>>> 
>>>>>> PS: The one change that DID happen is that I upgraded Vmware
>>>>>> Fusion, which I use to run the CentOS5 VMs. That should NOT make
>>>>>> any difference. But we will see.
>>>>>> 
>>>>>> I'll posted when my 4.1.7 test builds are ready. TIA!
>>>>> 
>>>>> To be clear, the last version that worked for me was 4.1.8.
>>>>> But it was before we built Release Candidates.
>>>>> 
>>>>> Unfortunately, I didn't keep it, but maybe you can upload it again?
>>>>> 
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>> commands, e-mail: dev-h...@openoffice.apache.org
>> <mailto: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: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-21 Thread Don Lewis
On 21 Oct, Jim Jagielski wrote:
> so are YOU able to build HEAD of AOO418 on CentOS5 ??

I haven't tried to build today's HEAD, but I've built and tested all of
my AOO418 commits on CentOS 5 before I made the commits.


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



Re: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-21 Thread Don Lewis
On 21 Oct, Matthias Seidel wrote:
> Am 21.10.20 um 17:43 schrieb Jim Jagielski:
>> Should that fix be just:
>>
>> 
> 
> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09
> 
> Really looks like a candidate...

I doubt it. Unless you are building on CentOS 5,
writerfilter/.../inc/doctok/resources.hxx is identical with or without this
commit.  On CentOS 5, resources.hxx differs, and causes a compile error
because it contains the correct C expression "something >> ".

I didn't commit this change to trunk or AOO42X because the problem only
shows up when building on CentOS 5.

Also, I believe that we've seen this problem previously on trunk and/or
AOO42X that does not have this commit but the problem has mysteriously
gone away, and it seems to be related to the combination of what OS the
build was done on and what OS the resulting binaries are run on.

I've done testing on CentOS 5, CentOS 7, Debian stretch and a bit of
testing on Ubuntu and have never run into this problem, *but* I've
always run the binaries on the same OS where they were compiled.


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



Re: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-21 Thread Don Lewis
On 21 Oct, Jim Jagielski wrote:
> Should that fix be just:
> 
> 

That would work, but it would produce a different output.  It would
always put ">> $shift" in the output whenever $shift is nonblank.  The
change that I committed only puts ">> $shift" in the output if $shift is
nonblank and greater than zero.  This is what the original version does
with older versions of libxslt, or when building on anything newer than
CentOS 5.

> 
>> On Oct 21, 2020, at 11:37 AM, Jim Jagielski  wrote:
>> 
>> I don't have it, but that was around the end of Aug right? So right around 
>> the time when a bunch of stuff was included like updates to nss, libxslt, 
>> libxml2...
>> 
>> I'm trying to get my head around the logic of
>> 
>>
>> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09
>> 
>>> On Oct 21, 2020, at 10:58 AM, Matthias Seidel  
>>> wrote:
>>> 
>>> Hi Jim,
>>> 
>>> Am 21.10.20 um 16:54 schrieb Jim Jagielski:
 Let me double check.. I am rebuilding AOO417. Lets see if that works.
 
 PS: The one change that DID happen is that I upgraded Vmware Fusion, which 
 I use to run the CentOS5 VMs. That should NOT make any difference. But we 
 will see.
 
 I'll posted when my 4.1.7 test builds are ready. TIA!
>>> 
>>> To be clear, the last version that worked for me was 4.1.8.
>>> But it was before we built Release Candidates.
>>> 
>>> Unfortunately, I didn't keep it, but maybe you can upload it again?
>>> 
 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org
 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 


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



Re: AOO418-RC2: General Error on opening files on Ubuntu

2020-10-21 Thread Don Lewis
On 21 Oct, Jim Jagielski wrote:
> I don't have it, but that was around the end of Aug right? So right around 
> the time when a bunch of stuff was included like updates to nss, libxslt, 
> libxml2...
> 
> I'm trying to get my head around the logic of
> 
> 
> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09

If $shift is blank then "$shift>0" becomes ">0", which is a malformed
expression.  For some reason, it still works correctly in most cases.
The case where it does not is with the latest libxslt when built on
CentOS 5.  In that cause, when we use the newly built xsltproc to
generate headers, one of them is corrupted and results in a build
failure when we try to compile with that header.  Adding the length
check avoids evaluating "$shift>0" when $shift is blank

This problem is only a build failure.

 

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



Re: 4.1.8 RC2 build broken when configured with --without-fonts

2020-10-11 Thread Don Lewis
On 12 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> Am 12.10.20 um 00:49 schrieb Don Lewis:
>> On 10 Oct, Don Lewis wrote:
>>> On 10 Oct, Matthias Seidel wrote:
>>>> Hi Don,
>>>>
>>>> Am 10.10.20 um 13:30 schrieb Don Lewis:
>>>>> On 10 Oct, Matthias Seidel wrote:
>>>>>> Hi Don,
>>>>>>
>>>>>> Am 10.10.20 um 13:04 schrieb Don Lewis:
>>>>>>> On  9 Oct, Dave Fisher wrote:
>>>>>>>> It’s a guess, but which Java are you using?
>>>>>>> OpenJDK 1.8.0_252
>>>>>> What happens if you build with Java 7?
>>>>>>>> Some of those look like java doc errors.
>>>>>>> Yes, this looks a lot like the --enable-odk problem with Java 8, but
>>>>>>> those fixes were merged to AOO418 and I am not using --enable-odk.
>>>>>> I don't think there is --enable-odk. What we have is --disable-odk.
>>>>> I suspect that --enable-odk is accepted and doesn't change the default.
>>>>> Regardless, I just checked and I'm passing --disable-odk to configure.
>>>> Thanks for the clarification.
>>>>
>>>> In that case Javadoc should not be involved at all?
>>> One would think, but the errors are being flagged in comments, which is
>>> what javadoc looks at.
>>>
>>> 4.1.7 builds fine with the same version of java as long as I configure
>>> with --disable-odk.
>> Digging into the logs, I see javadoc stuff happening whether or not
>> --disable-odk is specified, but the errors seem to get ignored.
>>
>> I do see another error with my FreeBSD build of 4.1.8:
>>
>> : && 
>> LD_LIBRARY_PATH=/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.
>> 8/main/solver/418/unxfbsdx.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} 
>> ../../
>> ../unxfbsdx.pro/bin/gencoll_rule dz_charset.txt 
>> ../../../unxfbsdx.pro/misc/colla
>> tor_dz_charset.cxx dz_charset
>> /wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/i18npool/unxfbsdx.
>> pro/bin/gencoll_rule: Undefined symbol "_ZN7icu_4_013UnicodeStringC1EPKt"
>> dmake:  Error code 1, while making 
>> '../../../unxfbsdx.pro/misc/collator_dz_chars
>> et.cxx'
>>
>> Hmn ... it looks like gencoll_rule rule is picking up the system icu
>> libraries rather than the bundled icu libraries.  Earlier I see some
>> linking errors that seem to get ignored:
> 
> A quick guess:
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=125371

Nope, the rpath is right.

This turns out to be a bug in the FreeBSD port.  Until recently, the
FreeBSD port used the system python.  Python 2 is now deprecated on
FreeBSD and will be removed by the end of the year, so a while back I
switched the port to use the bundled python.  When I did this, I didn't
notice that python wants to use readline, which got flagged.  When I
added the readline dependency, that caused -L/usr/local/lib to be added
to the value of LDFLAGS that gets passed to build through the
environment.  That in turn mucks up the library search order and causes
system libraries to be preferred to our bundled libraries.

I added the readline dependency at the same time as I was working on the
patch for the missing fc_local file, which is why things suddenly and
unexpectedly broke for me.

Sorry for the noise.


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



Re: 4.1.8 RC2 build broken when configured with --without-fonts

2020-10-11 Thread Don Lewis
On 10 Oct, Don Lewis wrote:
> On 10 Oct, Matthias Seidel wrote:
>> Hi Don,
>> 
>> Am 10.10.20 um 13:30 schrieb Don Lewis:
>>> On 10 Oct, Matthias Seidel wrote:
>>>> Hi Don,
>>>>
>>>> Am 10.10.20 um 13:04 schrieb Don Lewis:
>>>>> On  9 Oct, Dave Fisher wrote:
>>>>>> It’s a guess, but which Java are you using?
>>>>> OpenJDK 1.8.0_252
>>>> What happens if you build with Java 7?
>>>>>> Some of those look like java doc errors.
>>>>> Yes, this looks a lot like the --enable-odk problem with Java 8, but
>>>>> those fixes were merged to AOO418 and I am not using --enable-odk.
>>>> I don't think there is --enable-odk. What we have is --disable-odk.
>>> I suspect that --enable-odk is accepted and doesn't change the default.
>>> Regardless, I just checked and I'm passing --disable-odk to configure.
>> 
>> Thanks for the clarification.
>> 
>> In that case Javadoc should not be involved at all?
> 
> One would think, but the errors are being flagged in comments, which is
> what javadoc looks at.
> 
> 4.1.7 builds fine with the same version of java as long as I configure
> with --disable-odk.

Digging into the logs, I see javadoc stuff happening whether or not
--disable-odk is specified, but the errors seem to get ignored.

I do see another error with my FreeBSD build of 4.1.8:

: && LD_LIBRARY_PATH=/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.
8/main/solver/418/unxfbsdx.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} ../../
../unxfbsdx.pro/bin/gencoll_rule dz_charset.txt ../../../unxfbsdx.pro/misc/colla
tor_dz_charset.cxx dz_charset
/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/i18npool/unxfbsdx.
pro/bin/gencoll_rule: Undefined symbol "_ZN7icu_4_013UnicodeStringC1EPKt"
dmake:  Error code 1, while making '../../../unxfbsdx.pro/misc/collator_dz_chars
et.cxx'

Hmn ... it looks like gencoll_rule rule is picking up the system icu
libraries rather than the bundled icu libraries.  Earlier I see some
linking errors that seem to get ignored:

c++ -Wl,-z,combreloc -L/usr/local/lib -Wl,-rpath,/usr/local/lib 
-fstack-protector-strong -Wl,-z,defs -Wl,-export-dynamic -Wl,--noinhibit-exec 
-Wl,-rpath-link,../.
./unxfbsdx.pro/lib:/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/lib:/lib:/usr/lib
 -L../../unxfbsdx.pro/lib -L../lib -L/wr
kdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/solenv/unxfbsdx/lib 
-L/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/solver/418/unxfbsdx
.pro/lib 
-L/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/solenv/unxfbsdx/lib
 -L/usr/local/openjdk8/lib -L/usr/local/openjdk8/jre/lib/amd64 -L/usr/
local/openjdk8/jre/lib/amd64/server 
-L/usr/local/openjdk8/jre/lib/amd64/native_threads -L/usr/local/lib 
../../unxfbsdx.pro/obj/gencoll_rule.o \
-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive -luno_sal -licui18n 
-licuuc -licudata -Wl,--as-needed -pthread -lm -Wl,--no-as-needed  -o 
../../unxfbsdx.pro
/bin/gencoll_rule
../../unxfbsdx.pro/obj/gencoll_rule.o: In function `main':
gencoll_rule.cxx:(.text+0x355): undefined reference to 
`icu_4_0::UnicodeString::UnicodeString(unsigned short const*)'
gencoll_rule.cxx:(.text+0x36b): undefined reference to 
`icu_4_0::RuleBasedCollator::RuleBasedCollator(icu_4_0::UnicodeString const&, 
UErrorCode&)'
gencoll_rule.cxx:(.text+0x377): undefined reference to 
`icu_4_0::UnicodeString::~UnicodeString()'
gencoll_rule.cxx:(.text+0x3ac): undefined reference to 
`icu_4_0::RuleBasedCollator::cloneRuleData(int&, UErrorCode&)'
gencoll_rule.cxx:(.text+0x3f8): undefined reference to `uprv_free_4_0'
gencoll_rule.cxx:(.text+0x48e): undefined reference to 
`icu_4_0::UnicodeString::~UnicodeString()'
-rwxr-xr-x  1 nobody  wheel  18342 Oct 11 19:33 
../../unxfbsdx.pro/bin/gencoll_rule

There are differences in the compiler command line.  The working 4.1.7
version:
c++ -Wl,-z,combreloc -Wl,-rpath,/usr/local/lib -fstack-protector-strong 
-Wl,-z,defs -Wl,-export-dynamic -Wl,--noinhibit-exec 
-Wl,-rpath-link,../../unxfbsdx.pro/li
b:/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.7/main/solver/417/unxfbsdx.pro/lib:/lib:/usr/lib
 -L../../unxfbsdx.pro/lib -L../lib -L/wrkdirs/usr/ports/edi
tors/openoffice-4/work/aoo-4.1.7/main/solenv/unxfbsdx/lib 
-L/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.7/main/solver/417/unxfbsdx.pro/lib
 -L/wrkdirs/usr
/ports/editors/openoffice-4/work/aoo-4.1.7/main/solenv/unxfbsdx/lib 
-L/usr/local/openjdk8/lib -L/usr/local/openjdk8/jre/lib/amd64 
-L/usr/local/openjdk8/jre/lib/am
d64/server -L/usr/local/openjdk8/jre/lib/amd64/native_threads -L/usr/local/lib 
../../unxfbsdx.pro/obj/gencoll_rule.o \
-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive -luno_sal -licui18n 
-

Re: error in instsetoo_native module

2020-10-11 Thread Don Lewis
On 11 Oct, Matthias Seidel wrote:
> Hi Peter,
> 
> **
> ERROR: ERROR: Missing files
> in function: remove_Files_Without_Sourcedirectory
> **
> 
> That looks like the problem Don is having on FreeBSD.
> 
> What happens if you build without --without-fonts?
> 
> Regards,
> 
>    Matthias
> 
> 
> Am 11.10.20 um 23:02 schrieb Peter Kovacs:
>> I have an error on my build. I have no idea what to do. It seems like
>> the issue turns up at the packaging side.
>>
>> All info are appreciated. Maybe it is something with my build
>> environment.
>>
>> For reference my config looks like:
>>
>> ./configure \
>>     --with-dmake-path=/home/legine/workspace/dmake/bin/bin/dmake \
>>  --with-epm=/home/legine/workspace/epm/bin/bin/epm \
>>     --with-lang="${LANGS}" \
>>     --with-jdk-home=${jdkhome} \
>>     --with-package-format="installed" \
>>     --with-vendor="Petko Testbuild"\
>>     --with-build-version="aoo4ever-$(date +"%Y-%m-%d %H:%M") - `uname
>> -sm`\n ${GitHash}" \
>>     --with-system-stdlibs \
>>     --enable-crashdump=yes \
>>     --enable-category-b \
>>     --enable-beanshell \
>>     --enable-wiki-publisher \
>>     --enable-bundled-dictionaries \
>>     --enable-opengl  \
>>     --enable-dbus  \
>>     --without-junit \
>>     --without-stlport \
>>     --disable-odk \
>>     --without-fonts \
>>
>> my error output in the Log:
>>
>> build -- version: 275224
>>
>>
>> =
>> Building module instsetoo_native
>> =
>>
>> Entering
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/inc_openoffice/windows/msi_languages
>>
>>
>> Entering
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/inc_openoffice/unix
>>
>>
>> Entering /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util
>>
>> ... checking environment variables ...
>>
>> 
>> make_installer.pl, version 1.0
>> Product list file: ../util/openoffice.lst
>> Taking setup script from solver
>> Unpackpath:
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util/../unxlngx6.pro
>> Compiler: unxlngx6
>> Product: Apache_OpenOffice
>> BuildID: 9802
>> Build: AOO418
>> No minor set
>> Product version
>> Using default installpath
>> Package format: installed
>> msi templatepath:
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util/../unxlngx6.pro/misc/openoffice/msi_templates
>> msi template path will be ignored for non Windows builds!
>> msi languagepath:
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util/../unxlngx6.pro/misc/win_ulffiles
>> msi language path will be ignored for non Windows builds!
>> Calling epm
>> Stripping files
>> Unzip ARCHIVE files
>> Languages: en-US
>> 
>> ... checking required files ...
>> .. searching zip ...
>>     Found: /usr/bin/zip
>> ... analyzing ../util/openoffice.lst ...
>> ... reading include pathes ...
>> ... analyzing script:
>> /home/legine/workspace/AOO/gitbox/main/solver/418/unxlngx6.pro/bin/setup_osl.ins
>> ...
>> ... analyzing script:
>> /home/legine/workspace/AOO/gitbox/main/solver/418/unxlngx6.pro/bin/setup_osl.ins
>> ...
>> ... analyzing directories ...
>> ... analyzing files ...
>> ... analyzing scpactions ...
>> ... analyzing shortcuts ...
>> ... analyzing unix links ...
>> ... analyzing profile ...
>> ... analyzing profileitems ...
>> ... analyzing modules ...
>> 
>> ... languages en-US ...
>> ... analyzing files ...
>> preparing 1 extension blob for language en-US:
>>     dict-en.oxt
>> preparing 0 bundled extensions for language en-US:
>> ERROR: The following files could not be found:
>> ERROR: File not found: fc_local.conf
>> ... cleaning the output tree ...
>> ... removing directory /tmp/ooopackaging/i_190831602449324 ...
>> Error: ERROR: Missing files
>>
>> **
>> ERROR: ERROR: Missing files
>> in function: remove_Files_Without_Sourcedirectory
>> **
>> in function: remove_Files_Without_Sourcedirectorystopping log at Sun
>> Oct 11 22:48:45 2020
>> dmake:  Error code 255, while making 'openoffice_en-US.installed'
>>
>> 1 module(s):
>>     instsetoo_native
>> need(s) to be rebuilt
>>
>> Reason(s):
>>
>> ERROR: error 65280 occurred while making
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util
>>
>> When you have fixed the errors in that module you can resume the build
>> by running:
>>
>>     build --all:instsetoo_native

Yes sounds like the same problem.  I've got a patch and will put
together a pull request shortly.



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



Re: Building 4.1.8-RC2 - packaging issues

2020-10-11 Thread Don Lewis
On 11 Oct, Andrea Pescetti wrote:
> I've built the 4.1.8-RC2 sources from
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.8-RC2/source/
> on a new CentOS 7 VM and generated "installed" (not packaged), RPM and 
> DEB builds that I tested on a variety of Fedora and Ubuntu systems.
> 
> All good, for the most part. I'm still catching up with e-mails so I 
> didn't test anything specific to 4.1.8, just general usage. I have news 
> on the "General error" on Ubuntu too, but I'll expand on this in the 
> relevant thread.
> 
> But I'd like to highlight two issues occurring in the last stage of the 
> build, i.e., when we produce the RPM/DEB packages.
> 
> 1) Jim's EPM installed as per
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_7_for_AOO_4.2.x_and_later
> didn't work for me. I got
> 
> Error: ERROR: More than one new package in directory
> 
> Configuring with
> 
> ... 
> --with-epm-url=http://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz
> 
> did work instead, so I'd like to know if people who used the wiki 
> instructions
> 
> $ wget https://github.com/jimjag/epm/archive/epm-4.4.2.tar.gz
> $ # (extract the archive)
> $ cd epm-epm-4.4.2
> $ ./configure --prefix=/usr/local --enable-aoo; make install
> 
> had better luck. Or maybe the new EPM is to be used for 4.2.x builds only?
> 
> 2) Something seems wrong here:
> 
> https://github.com/apache/openoffice/blob/AOO418/main/solenv/bin/modules/RepoRevision.pm#L78
> 
> We populate the "Rev." section of the About dialog based on version 
> control, so for a tarball (no Git, no SVN) this should result in 
> "unknown-rev"; but it doesn't and Git is called instead, returning an 
> error message.
> 
> To my purpose I simply used a hardcoded string and completed the build, 
> but it should be checked better: the official tarball is not a git clone 
> and this will always result in a (non-blocking) error message if someone 
> builds from it.

I thought that the source tarball was supposed to include an artifact
containing the git revision info.

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



Re: 4.1.8 RC2 build broken when configured with --without-fonts

2020-10-10 Thread Don Lewis
On 10 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> Am 10.10.20 um 13:30 schrieb Don Lewis:
>> On 10 Oct, Matthias Seidel wrote:
>>> Hi Don,
>>>
>>> Am 10.10.20 um 13:04 schrieb Don Lewis:
>>>> On  9 Oct, Dave Fisher wrote:
>>>>> It’s a guess, but which Java are you using?
>>>> OpenJDK 1.8.0_252
>>> What happens if you build with Java 7?
>>>>> Some of those look like java doc errors.
>>>> Yes, this looks a lot like the --enable-odk problem with Java 8, but
>>>> those fixes were merged to AOO418 and I am not using --enable-odk.
>>> I don't think there is --enable-odk. What we have is --disable-odk.
>> I suspect that --enable-odk is accepted and doesn't change the default.
>> Regardless, I just checked and I'm passing --disable-odk to configure.
> 
> Thanks for the clarification.
> 
> In that case Javadoc should not be involved at all?

One would think, but the errors are being flagged in comments, which is
what javadoc looks at.

4.1.7 builds fine with the same version of java as long as I configure
with --disable-odk.


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



Re: 4.1.8 RC2 build broken when configured with --without-fonts

2020-10-10 Thread Don Lewis
On 10 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> Am 10.10.20 um 13:04 schrieb Don Lewis:
>> On  9 Oct, Dave Fisher wrote:
>>> It’s a guess, but which Java are you using?
>> OpenJDK 1.8.0_252
> What happens if you build with Java 7?
>>
>>> Some of those look like java doc errors.
>> Yes, this looks a lot like the --enable-odk problem with Java 8, but
>> those fixes were merged to AOO418 and I am not using --enable-odk.
> 
> I don't think there is --enable-odk. What we have is --disable-odk.

I suspect that --enable-odk is accepted and doesn't change the default.
Regardless, I just checked and I'm passing --disable-odk to configure.


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



Re: 4.1.8 RC2 build broken when configured with --without-fonts

2020-10-10 Thread Don Lewis
On  9 Oct, Dave Fisher wrote:
> It’s a guess, but which Java are you using?

OpenJDK 1.8.0_252

> Some of those look like java doc errors.

Yes, this looks a lot like the --enable-odk problem with Java 8, but
those fixes were merged to AOO418 and I am not using --enable-odk.

It acts like javadoc is being run on some files that have never been run
through javadoc before in recent history.  I have no idea what might be
triggering that and why it suddenly started happening.

> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On Oct 9, 2020, at 6:08 PM, Don Lewis  wrote:
>> 
>> I started working on the FreeBSD port for 4.1.8.  Unlike the the other
>> ports, the FreeBSD port doesn't bundle fonts with the package.  Instead
>> it uses fonts from the system, installing them separately if necessary.
>> To do this, it configures with the --without-fonts option.  This 4.1.8
>> RC2 fails with this error:
>> 
>> preparing 0 bundled extensions for language en-US:
>> ... analyzing files with flag ARCHIVE ...
>> ... reading include pathes ...
>> ... analyzing script: 
>> /home/dl/openoffice/main/solver/418/unxlngx6.pro/bin/setup_osl.ins ... 
>> ... analyzing script: 
>> /home/dl/openoffice/main/solver/418/unxlngx6.pro/bin/setup_osl.ins ... 
>> ... analyzing directories ... 
>> ... analyzing files ... 
>> ... analyzing scpactions ... 
>> ... analyzing shortcuts ... 
>> ... analyzing unix links ... 
>> ... analyzing profile ... 
>> ... analyzing profileitems ... 
>> ... analyzing modules ... 
>> 
>> ... languages en-US ... 
>> 
>> **
>> ERROR: ERROR: Missing files
>> in function: remove_Files_Without_Sourcedirectory
>> **
>> ... analyzing files ...
>> preparing 1 extension blob for language en-US:
>>dict-en.oxt
>> preparing 0 bundled extensions for language en-US:
>> ERROR: The following files could not be found:
>> ERROR: File not found: fc_local.conf
>> ... cleaning the output tree ...
>> ... removing directory /tmp/ooopackaging/i_199031602279361 ...
>> Error: ERROR: Missing files
>> in function: remove_Files_Without_Sourcedirectorystopping log at Fri Oct  9 
>> 14:36:03 2020
>> 
>> This can be reproduced on Linux.
>> 
>> 
>> 
>> I started working on a patch but then ran into another failure much
>> earlier in the build that now happens either with without my patch.
>> 
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Selection.java:94:
>>  warning: no @param for p
>>public void setActiveCell(Point p) {
>>^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:48:
>>  warning: no description for @param
>> * @param str
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:50:
>>  warning: no @throws for java.io.IOException
>>public StringValue(String str) throws IOException {
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:61:
>>  warning: no @throws for java.io.IOException
>>public StringValue(InputStream is) throws IOException {
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:109:
>>  warning: no @throws for java.io.IOException
>>public String getString() throws IOException {
>>  ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Workbook.java:361:
>>  error: invalid use of @return
>> * @return name the name of the Worksheet to be added
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Workbook.java:375:
>>  error: invalid use of @return
>> * @return the name of the Worksheet to be added
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Worksheet.ja

4.1.8 RC2 build broken when configured with --without-fonts

2020-10-09 Thread Don Lewis
I started working on the FreeBSD port for 4.1.8.  Unlike the the other
ports, the FreeBSD port doesn't bundle fonts with the package.  Instead
it uses fonts from the system, installing them separately if necessary.
To do this, it configures with the --without-fonts option.  This 4.1.8
RC2 fails with this error:

preparing 0 bundled extensions for language en-US:
... analyzing files with flag ARCHIVE ...
... reading include pathes ...
... analyzing script: 
/home/dl/openoffice/main/solver/418/unxlngx6.pro/bin/setup_osl.ins ... 
... analyzing script: 
/home/dl/openoffice/main/solver/418/unxlngx6.pro/bin/setup_osl.ins ... 
... analyzing directories ... 
... analyzing files ... 
... analyzing scpactions ... 
... analyzing shortcuts ... 
... analyzing unix links ... 
... analyzing profile ... 
... analyzing profileitems ... 
... analyzing modules ... 

... languages en-US ... 

**
ERROR: ERROR: Missing files
in function: remove_Files_Without_Sourcedirectory
**
... analyzing files ...
preparing 1 extension blob for language en-US:
dict-en.oxt
preparing 0 bundled extensions for language en-US:
ERROR: The following files could not be found: 
ERROR: File not found: fc_local.conf
... cleaning the output tree ...
... removing directory /tmp/ooopackaging/i_199031602279361 ...
Error: ERROR: Missing files
in function: remove_Files_Without_Sourcedirectorystopping log at Fri Oct  9 
14:36:03 2020

This can be reproduced on Linux.



I started working on a patch but then ran into another failure much
earlier in the build that now happens either with without my patch.

/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Selection.java:94:
 warning: no @param for p
public void setActiveCell(Point p) {
^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:48:
 warning: no description for @param
 * @param str
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:50:
 warning: no @throws for java.io.IOException
public StringValue(String str) throws IOException {
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:61:
 warning: no @throws for java.io.IOException
public StringValue(InputStream is) throws IOException {
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:109:
 warning: no @throws for java.io.IOException
public String getString() throws IOException {
  ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Workbook.java:361:
 error: invalid use of @return
 * @return name the name of the Worksheet to be added
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Workbook.java:375:
 error: invalid use of @return
 * @return the name of the Worksheet to be added
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Worksheet.java:253:
 error: invalid use of @return
 * @return an Enumeration to the ColInfo's
   ^
Building index for all the packages and classes...
Building index for all classes...
Generating 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/unxfbsdx.pro/class/javadoc/help-doc.html...
15 errors
100 warnings

main:

BUILD SUCCESSFUL
Total time: 2 seconds

Entering 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/activesync

xmerge deliver
deliver -- version: 275594
COPY: build.lst -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/inc/xmerge/build.lst
COPY: ../unxfbsdx.pro/class/xmerge.jar -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/bin/xmerge.jar
COPY: ../unxfbsdx.pro/class/pexcel.jar -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/bin/pexcel.jar
COPY: ../unxfbsdx.pro/class/htmlsoff.jar -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/bin/htmlsoff.jar
COPY: ../unxfbsdx.pro/class/aportisdoc.jar -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/bin/aportisdoc.jar
COPY: ../unxfbsdx.pro/class/XMergeBridge.jar 

how to download RC2?

2020-10-08 Thread Don Lewis
I want to download the source tarball for RC2, but this page:
  
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-fullsets
isn't helpful.


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



Re: [openoffice] branch AOO418 updated: Fix broken compile for older Linux... disable HW accel just as we used to do before

2020-10-06 Thread Don Lewis
On  6 Oct, j...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> jim pushed a commit to branch AOO418
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
> 
> 
> The following commit(s) were added to refs/heads/AOO418 by this push:
>  new 0a99449  Fix broken compile for older Linux... disable HW accel just 
> as we used to do before
> 0a99449 is described below

This is a bit misleading.  The code compiles fine and works properly on
CentOS 5.  It just won't run on older hardware that doesn't have the new
crypto instructions.  I didn't catch it since I built and tested the
code on a CentOS 5 VM running on a Ryzen.

Good catch.  The next nss upgrade probably has the same problem.

> commit 0a994498bd0b70dfacbfd49f6470cce09e547165
> Author: Jim Jagielski 
> AuthorDate: Tue Oct 6 15:42:08 2020 -0400
> 
> Fix broken compile for older Linux... disable HW accel just as we used to 
> do before
> ---
>  main/nss/nss_linux.patch | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/main/nss/nss_linux.patch b/main/nss/nss_linux.patch
> index 9d768b2..50c27a4 100644
> --- a/main/nss/nss_linux.patch
> +++ b/main/nss/nss_linux.patch
> @@ -12,3 +12,18 @@ diff -ur misc/nss-3.25/nss/lib/freebl/Makefile 
> misc/build/nss-3.25/nss/lib/freeb
>   EXTRA_SRCS += intel-gcm-wrap.c
>   ifeq ($(CLANG_CL),1)
>   INTEL_GCM_CLANG_CL = 1
> +@@ -221,10 +221,10 @@
> + DEFINES += -DMP_IS_LITTLE_ENDIAN
> + #   DEFINES += -DMPI_AMD64_ADD
> + # comment the next four lines to turn off Intel HW acceleration.
> +-DEFINES += -DUSE_HW_AES -DINTEL_GCM
> +-ASFILES += intel-aes.s intel-gcm.s
> +-EXTRA_SRCS += intel-gcm-wrap.c
> +-INTEL_GCM = 1
> ++#DEFINES += -DUSE_HW_AES -DINTEL_GCM
> ++#ASFILES += intel-aes.s intel-gcm.s
> ++#EXTRA_SRCS += intel-gcm-wrap.c
> ++#INTEL_GCM = 1
> + MPI_SRCS += mpi_amd64.c mp_comba.c
> + endif
> + ifeq ($(CPU_ARCH),x86)
> 


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



Re: AOO418 cherry picks

2020-10-06 Thread Don Lewis
On  6 Oct, Jim Jagielski wrote:
> Thanks! Since these are relatively new, I think that this can hold for 4.1.9

I'd at least like to get the nss update into trunk/AOO42X where it can
soak for a while.

>> On Oct 6, 2020, at 12:19 PM, Don Lewis  wrote:
>> 
>> On  6 Oct, Jim Jagielski wrote:
>>> OK... as expected, it fails on macOS.
>>> 
>>> 2 things I see: in the nss.patch file there is a line:
>>> 
>>>Only in misc/build/nss-3.39/nss/coreconf: Darwin.mk.rej
>>> 
>>> So I'm wondering if the patch file itself or maybe even the whole pull 
>>> request is borked.
>>> 
>>> Also, we need to force 'g++' on the macOS build to include '-std=c++11'
>> 
>> I missed that the patch to Darwin.mk was rejected when I applied the
>> pre-update version of the patch.  I regenerated nss.patch, so these
>> issues should be fixed now, or at least should be much better.
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


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



Re: AOO418 cherry picks

2020-10-06 Thread Don Lewis
On  6 Oct, Jim Jagielski wrote:
> OK... as expected, it fails on macOS.
> 
> 2 things I see: in the nss.patch file there is a line:
> 
> Only in misc/build/nss-3.39/nss/coreconf: Darwin.mk.rej
> 
> So I'm wondering if the patch file itself or maybe even the whole pull 
> request is borked.
> 
> Also, we need to force 'g++' on the macOS build to include '-std=c++11'

I missed that the patch to Darwin.mk was rejected when I applied the
pre-update version of the patch.  I regenerated nss.patch, so these
issues should be fixed now, or at least should be much better.


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



Re: AOO418 cherry picks

2020-10-05 Thread Don Lewis
Any progress on nss?

On 30 Sep, Jim Jagielski wrote:
> I'll see how the build on macOS goes, but likely won't be able to get to it 
> until Monday.
> 
>> On Sep 29, 2020, at 2:52 PM, Don Lewis  wrote:
>> 
>> On 29 Sep, Matthias Seidel wrote:
>>> Hi Don,
>>> 
>>> Am 26.09.20 um 23:47 schrieb Don Lewis:
>>>> On 26 Sep, Matthias Seidel wrote:
>>>>> Hi all,
>>>>> 
>>>>> Am 25.09.20 um 18:05 schrieb Matthias Seidel:
>>>>>> Am 25.09.20 um 14:01 schrieb Jim Jagielski:
>>>>>>> That looks quite a bit more straightforward :-)
>>>>>> Let's wait for Don's PR, this is only a minor update from Python 2.7.17
>>>>>> to 2.7.18.
>>>>> Merged now...
>>>>> 
>>>>> Unless Don wants to add something for the Java detection I would think
>>>>> we are pretty close to a release candidate?
>>>> I've got another nss upgrade in the works as well as a small serf bug
>>>> fix.
>>> 
>>> OK, if that can be done quick *and* safe?
>> 
>> nss is somewhat risky.  We've had problems with upgrading it in the
>> past, primarily with MacOS.  It does fix a fairly important CVE, though
>> I don't know if it potentially affects our usage of nss.  I just
>> submitted a pull request.
>> 
>> Serf should be fairly quick.  It's just a couple of patches
>> cherry-picked from upstream to fix a CVE.
>> 
>> There are also a few new libxml2 CVEs, but not a new release of the
>> library.  They can be fixed with some upstream cherry picks.
>> 
>>> Otherwise I doubt that we have a release in the next 2 weeks... ;-)
>>> 
>>> Regards,
>>> 
>>>Matthias
>>> 
>>>> 
>>>> -
>>>> 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 
>> <mailto:dev-unsubscr...@openoffice.apache.org>
>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>> <mailto:dev-h...@openoffice.apache.org>


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



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

2020-10-05 Thread Don Lewis
On  5 Oct, Damjan Jovanovic wrote:
> 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.

Of those two, --enable-dbgutil would be my guess, though I'm pretty sure
I've enabled that in the past and not run into this issue.


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



Re: Fwd: [libexpat/libexpat] Release R_2_2_10 - 2.2.10

2020-10-05 Thread Don Lewis
On  3 Oct, Matthias Seidel wrote:
> Hi all,
> 
> Libexpat has been updated!
> 
> Regards,
> 
>    Matthias
> 
> 
> 
>  Weitergeleitete Nachricht 
> Betreff:  [libexpat/libexpat] Release R_2_2_10 - 2.2.10
> Datum:Sat, 03 Oct 2020 11:35:44 -0700
> Von:  Sebastian Pipping 
> Antwort an:   libexpat/libexpat 
> An:   libexpat/libexpat 
> Kopie (CC):   Subscribed 
> 
> 
> 
>   2.2.10 
> 
> Repository: libexpat/libexpat  ·
> Tag: R_2_2_10  ·
> Commit: 162e16b
> 
> · Released by: hartwork 
> 
> Original changelog
> 
> 
> —
> 
> This release has 11 assets:
> 
>   * expat-2.2.10.tar.bz2
>   * expat-2.2.10.tar.bz2.asc
>   * expat-2.2.10.tar.gz
>   * expat-2.2.10.tar.gz.asc
>   * expat-2.2.10.tar.lz
>   * expat-2.2.10.tar.lz.asc
>   * expat-2.2.10.tar.xz
>   * expat-2.2.10.tar.xz.asc
>   * expat-win32bin-2.2.10.exe
>   * Source code (zip)
>   * Source code (tar.gz)
> 
> Visit the release page
>  to download
> them.

I've updated trunk and AOO42X.  Any thoughts on AOO418?


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



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

2020-10-05 Thread Don Lewis
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.


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



Re: AOO418 cherry picks

2020-09-30 Thread Don Lewis
I've got everything on my list for AOO418 in the queue:

  * Fix for old java detection when building with new java
Set java compilation target to version 1.5 #101
https://github.com/apache/openoffice/pull/101

  * Bug fixes from upstream for bundled libxml2 and serf modules
Libxml+serf 418 #102
https://github.com/apache/openoffice/pull/102

  * Upgrade to a newer bundled nss
Nssupgrade - Upgrade bundled nss to nss-3.39-with-nspr-4.20 #100
https://github.com/apache/openoffice/pull/100

The first two have been committed to trunk and AOO42X.  The AOO418
changes have been lightly tested on Debian 9, Windows 7, and CentOS 5.

The last pull request has not yet been merged to trunk.  The changes
have been tested on Debian 9, Windows 7, and CentOS 7.  Upgrades to NSS
have been problematic in the past, especially on MacOS.  This module is
used for document signing and signature checking.


 

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



Re: Building AOO under Debian9

2020-09-30 Thread Don Lewis
On 30 Sep, Dr. Michael Stehmann wrote:
> Hello Don,
> 
> in configure.sh I had this line :
> 
> --with-build-version="aoo42x-$(date +"%Y-%m-%d %H:%M") - `uname -sm`\n
> ${GitHash}"
> 
> Because I want to have the corresponding git hash I built, I need the
> output in two lines.

Instead of \n, try n.  That forces the environment variable to
contain a literal \n, which should get passed as a compiler preprocessor
symbol definition, and the compiler will turn the \n into a newline.  I
don't know how that interacts with the About dialog, though.

This is one more level of escaping than I think should be necessary, but
\\n didn't seem to help.

> Thanks for your help
> 
> Kind regards
> 
> Mechtilde
> 
> Am 30.09.20 um 08:38 schrieb Don Lewis:
>> On 30 Sep, Mechtilde wrote:
>>> Hello,
>>>
>>> I set up a recent build environment with Debian 9.
>>>
>>> I have got the same error message again:
>>>
>>> ~/openoffice/main/instsetoo_native$ build --from cui
>>> build -- version: -
>>>
>>>
>>> =
>>> Building module cui
>>> =
>>>
>>> Entering /home/mechtilde/openoffice/main/cui/prj
>>>
>>> cd .. && make -s -r -j1   && make -s -r deliverlog
>>> /home/mechtilde/openoffice/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/openoffice/main/cui/prj
>>>
>>> When you have fixed the errors in that module you can resume the build
>>> by running:
>>>
>>> I also attach my file LinuxX86-64Env.Set.sh.
>>>
>>> Can someone help me to get a proper build environment.
>>>
>>> Kind regards
>>>
>>> Mechtilde
>>>
>>> Am 10.11.19 um 22:02 schrieb Ariel Constenla-Haile:
>>>> Hi Mechtilde,
>>>>
>>>> On Sun, Nov 10, 2019 at 5:23 AM Mechtilde  wrote:
>>>>>
>>>>> Hello again,
>>>>>
>>>>> I did a recent git pull AOO42X and try to build it under Debian 9.
>>>>>
>>>>> It didn't build. it fails with error in  main/cui/Library_cui.mk:37
>>>>>
>>>>> If I patched it as before then it builds succesfully.
>>>>>
>>>>> Either we need a switch for Debian 9 and may be newer
>>>>> distribution/versions or we need another fix.
>>>>
>>>> The contents of BUILD_VER_STRING might be the problem, attach your
>>>> LinuxX86-64Env.Set.sh and someone may reproduce the error.
>> 
>> I'm building on Debian 9 and not having any problems.  I just did a
>> trunk build and in my LinuxX86-64Env.Set.sh I see:
>> 
>> $ grep BUILD_VER_STRING LinuxX86-64Env.Set.sh | head -1
>> BUILD_VER_STRING="2020-09-29 22:09:35 (Tue, 29 Sep 2020) - Linux x86_64"
>> 
>> If I look at your LinuxX86-64Env.Set.sh:
>> 
>> %grep BUILD_VER_STRING /tmp/LinuxX86-64Env.Set.sh | head -1
>> BUILD_VER_STRING="aoo42x-2020-09-29 19:11 - Linux x86_64
>> 
>> I see a critical difference.  Mine has " characters around the value,
>> but yours has the leading quote, but no trailing quote.  Looking more
>> closely at the file:
>> 
>> BUILD_VER_STRING="aoo42x-2020-09-29 19:11 - Linux x86_64
>>  "
>> 
>> It looks like a newline is getting embeded into the value somehow.  The
>> rest of the info in the string has other differences as well.
>> 
>> If I check out AOO42X and run autoconf and configure, I see:
>> BUILD_VER_STRING="2020-09-29 23:34:46 (Tue, 29 Sep 2020) - Linux x86_64"
>> 
>> Ah, I'm running configure with this option:
>> --with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b 
>> %Y)") - `uname -sm`${AOO_BUILD_VERSION}"
>> What are you doing here?
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


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



Re: Building AOO under Debian9

2020-09-30 Thread Don Lewis
On 30 Sep, Mechtilde wrote:
> Hello,
> 
> I set up a recent build environment with Debian 9.
> 
> I have got the same error message again:
> 
> ~/openoffice/main/instsetoo_native$ build --from cui
> build -- version: -
> 
> 
> =
> Building module cui
> =
> 
> Entering /home/mechtilde/openoffice/main/cui/prj
> 
> cd .. && make -s -r -j1   && make -s -r deliverlog
> /home/mechtilde/openoffice/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/openoffice/main/cui/prj
> 
> When you have fixed the errors in that module you can resume the build
> by running:
> 
> I also attach my file LinuxX86-64Env.Set.sh.
> 
> Can someone help me to get a proper build environment.
> 
> Kind regards
> 
> Mechtilde
> 
> Am 10.11.19 um 22:02 schrieb Ariel Constenla-Haile:
>> Hi Mechtilde,
>> 
>> On Sun, Nov 10, 2019 at 5:23 AM Mechtilde  wrote:
>>>
>>> Hello again,
>>>
>>> I did a recent git pull AOO42X and try to build it under Debian 9.
>>>
>>> It didn't build. it fails with error in  main/cui/Library_cui.mk:37
>>>
>>> If I patched it as before then it builds succesfully.
>>>
>>> Either we need a switch for Debian 9 and may be newer
>>> distribution/versions or we need another fix.
>> 
>> The contents of BUILD_VER_STRING might be the problem, attach your
>> LinuxX86-64Env.Set.sh and someone may reproduce the error.

I'm building on Debian 9 and not having any problems.  I just did a
trunk build and in my LinuxX86-64Env.Set.sh I see:

$ grep BUILD_VER_STRING LinuxX86-64Env.Set.sh | head -1
BUILD_VER_STRING="2020-09-29 22:09:35 (Tue, 29 Sep 2020) - Linux x86_64"

If I look at your LinuxX86-64Env.Set.sh:

%grep BUILD_VER_STRING /tmp/LinuxX86-64Env.Set.sh | head -1
BUILD_VER_STRING="aoo42x-2020-09-29 19:11 - Linux x86_64

I see a critical difference.  Mine has " characters around the value,
but yours has the leading quote, but no trailing quote.  Looking more
closely at the file:

BUILD_VER_STRING="aoo42x-2020-09-29 19:11 - Linux x86_64
 "

It looks like a newline is getting embeded into the value somehow.  The
rest of the info in the string has other differences as well.

If I check out AOO42X and run autoconf and configure, I see:
BUILD_VER_STRING="2020-09-29 23:34:46 (Tue, 29 Sep 2020) - Linux x86_64"

Ah, I'm running configure with this option:
--with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b 
%Y)") - `uname -sm`${AOO_BUILD_VERSION}"
What are you doing here?


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



Re: AOO418 cherry picks

2020-09-29 Thread Don Lewis
On 29 Sep, Matthias Seidel wrote:
> Hi Don,
> 
> Am 26.09.20 um 23:47 schrieb Don Lewis:
>> On 26 Sep, Matthias Seidel wrote:
>>> Hi all,
>>>
>>> Am 25.09.20 um 18:05 schrieb Matthias Seidel:
>>>> Am 25.09.20 um 14:01 schrieb Jim Jagielski:
>>>>> That looks quite a bit more straightforward :-)
>>>> Let's wait for Don's PR, this is only a minor update from Python 2.7.17
>>>> to 2.7.18.
>>> Merged now...
>>>
>>> Unless Don wants to add something for the Java detection I would think
>>> we are pretty close to a release candidate?
>> I've got another nss upgrade in the works as well as a small serf bug
>> fix.
> 
> OK, if that can be done quick *and* safe?

nss is somewhat risky.  We've had problems with upgrading it in the
past, primarily with MacOS.  It does fix a fairly important CVE, though
I don't know if it potentially affects our usage of nss.  I just
submitted a pull request.

Serf should be fairly quick.  It's just a couple of patches
cherry-picked from upstream to fix a CVE.

There are also a few new libxml2 CVEs, but not a new release of the
library.  They can be fixed with some upstream cherry picks.

> Otherwise I doubt that we have a release in the next 2 weeks... ;-)
> 
> Regards,
> 
>    Matthias
> 
>>
>> -
>> 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: java detection

2020-09-26 Thread Don Lewis
On 27 Sep, Matthias Seidel wrote:
> Am 26.09.20 um 23:43 schrieb Don Lewis:
>> On 26 Sep, Matthias Seidel wrote:
>>> Hi Don,
>>>
>>> Is this an easy fix?
>> Yes.  What minimum version should we target?
> 
> The same as in trunk?

Trunk currently compiles to 1.7.  For AOO418 is that old enough, or do
we need to support something older?

> I really don't know... ;-)
> 
>>
>>> Regards,
>>>
>>>    Matthias
>>>
>>> Am 25.09.20 um 22:54 schrieb Don Lewis:
>>>> On 25 Sep, Don Lewis wrote:
>>>>> On 24 Sep, Don Lewis wrote:
>>>>>> I've been looking into the problem where AOO418 can't detect older
>>>>>> versions of java when it is built with a new version of java.  This is a
>>>>>> definite puzzle because the detection is done by the jvmfwk module, and
>>>>>> the code in that module is identical between AOO418 and trunk.  The only
>>>>>> difference is that this module has been changed from dmake to gbuild in
>>>>>> trunk.
>>>>>>
>>>>>> The way that java detection works is that we scan the possible java
>>>>>> locations, and for each we run
>>>>>>   [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
>>>>>> 4\\program JREProperties
>>>>>> which is supposed to output a bunch of data about that version of java,
>>>>>> which we read and parse.  If that fails, then we decide that version of
>>>>>> java is invalid or broken.
>>>>>>
>>>>>> When I build AOO418 with Java 8 and it tries to detect Java 7, I see
>>>>>> this stack trace sent to stderr:
>>>>>>
>>>>>> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported 
>>>>>> major.minor version 52.0
>>>>>> at java.lang.ClassLoader.defineClass1(Native Method)
>>>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>>>>>> at 
>>>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>>>>>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>>>>>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>>>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>>>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>>>>>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>>>>>> at 
>>>>>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
>>>>>> Exception in thread "main"
>>>>>>
>>>>>> The problem is that the JREProperties was compiled with Java 8, which
>>>>>> Java 7 can't use:
>>>>>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 
>>>>>> 4/program/JREProperties.class
>>>>>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: 
>>>>>> compiled Java class data, version 52.0 (Java 1.8)
>>>>>>
>>>>>> If I build trunk with Java 8, I see:
>>>>>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 
>>>>>> 4/program/JREProperties.class
>>>>>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: 
>>>>>> compiled Java class data, version 51.0 (Java 1.7)
>>>>>> That's why we don't see this issue with trunk
>>>>>>
>>>>>> It is possible to use a new java compiler to build for older versions of
>>>>>> java using the --target option, but I don't see any sign that we are
>>>>>> doing so.
>>>>>>
>>>>>> Unfortunately the build is too silent for me to see what is actually
>>>>>> happening during the build.  My suspicion is that somehow the trunk
>>>>>> build is somehow using Java 7 to build.
>>>>> I finally figured out the di

Re: AOO418 cherry picks

2020-09-26 Thread Don Lewis
On 26 Sep, Matthias Seidel wrote:
> Hi all,
> 
> Am 25.09.20 um 18:05 schrieb Matthias Seidel:
>> Am 25.09.20 um 14:01 schrieb Jim Jagielski:
>>> That looks quite a bit more straightforward :-)
>> Let's wait for Don's PR, this is only a minor update from Python 2.7.17
>> to 2.7.18.
> 
> Merged now...
> 
> Unless Don wants to add something for the Java detection I would think
> we are pretty close to a release candidate?

I've got another nss upgrade in the works as well as a small serf bug
fix.

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



Re: java detection

2020-09-26 Thread Don Lewis
On 26 Sep, Matthias Seidel wrote:
> Hi Don,
> 
> Is this an easy fix?

Yes.  What minimum version should we target?

> Regards,
> 
>    Matthias
> 
> Am 25.09.20 um 22:54 schrieb Don Lewis:
>> On 25 Sep, Don Lewis wrote:
>>> On 24 Sep, Don Lewis wrote:
>>>> I've been looking into the problem where AOO418 can't detect older
>>>> versions of java when it is built with a new version of java.  This is a
>>>> definite puzzle because the detection is done by the jvmfwk module, and
>>>> the code in that module is identical between AOO418 and trunk.  The only
>>>> difference is that this module has been changed from dmake to gbuild in
>>>> trunk.
>>>>
>>>> The way that java detection works is that we scan the possible java
>>>> locations, and for each we run
>>>>   [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
>>>> 4\\program JREProperties
>>>> which is supposed to output a bunch of data about that version of java,
>>>> which we read and parse.  If that fails, then we decide that version of
>>>> java is invalid or broken.
>>>>
>>>> When I build AOO418 with Java 8 and it tries to detect Java 7, I see
>>>> this stack trace sent to stderr:
>>>>
>>>> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported 
>>>> major.minor version 52.0
>>>> at java.lang.ClassLoader.defineClass1(Native Method)
>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>>>> at 
>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>>>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>>>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>>>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>>>> at 
>>>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
>>>> Exception in thread "main"
>>>>
>>>> The problem is that the JREProperties was compiled with Java 8, which
>>>> Java 7 can't use:
>>>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
>>>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: 
>>>> compiled Java class data, version 52.0 (Java 1.8)
>>>>
>>>> If I build trunk with Java 8, I see:
>>>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
>>>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: 
>>>> compiled Java class data, version 51.0 (Java 1.7)
>>>> That's why we don't see this issue with trunk
>>>>
>>>> It is possible to use a new java compiler to build for older versions of
>>>> java using the --target option, but I don't see any sign that we are
>>>> doing so.
>>>>
>>>> Unfortunately the build is too silent for me to see what is actually
>>>> happening during the build.  My suspicion is that somehow the trunk
>>>> build is somehow using Java 7 to build.
>>> I finally figured out the difference.  The 4.1.x build uses the selected
>>> javac to build the .class file, whereas trunk and 42X use ant, and
>>> solenv/ant/aoo-ant.xml (new to trunk ant 42X) says:
>>> 
>>>
>>>> I see two paths forward.  The first is to build with the oldest version
>>>> of java that one might want to use, which is the status quo.  The second
>>>> is to somehow pass the --target option to specify an older java version
>>>> for compatibility.
>>> We could also cherry-pick the jvmfwk conversion to gbuild and the other
>>> changes for ant.
>> Even simpler, there is a JAVAFLAGS variable used by the dmake build.
>> Configure sets it:
>> JAVAFLAGS="-source 1.5 -target 1.5"
>> for Eclipse Java Compiler, but otherwise leaves it unset.
>>
>>
>> -
>> 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: java detection

2020-09-25 Thread Don Lewis
On 25 Sep, Don Lewis wrote:
> On 24 Sep, Don Lewis wrote:
>> I've been looking into the problem where AOO418 can't detect older
>> versions of java when it is built with a new version of java.  This is a
>> definite puzzle because the detection is done by the jvmfwk module, and
>> the code in that module is identical between AOO418 and trunk.  The only
>> difference is that this module has been changed from dmake to gbuild in
>> trunk.
>> 
>> The way that java detection works is that we scan the possible java
>> locations, and for each we run
>>   [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
>> 4\\program JREProperties
>> which is supposed to output a bunch of data about that version of java,
>> which we read and parse.  If that fails, then we decide that version of
>> java is invalid or broken.
>> 
>> When I build AOO418 with Java 8 and it tries to detect Java 7, I see
>> this stack trace sent to stderr:
>> 
>> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported 
>> major.minor version 52.0
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>> at 
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>> at 
>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
>> Exception in thread "main"
>> 
>> The problem is that the JREProperties was compiled with Java 8, which
>> Java 7 can't use:
>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
>> Java class data, version 52.0 (Java 1.8)
>> 
>> If I build trunk with Java 8, I see:
>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
>> Java class data, version 51.0 (Java 1.7)
>> That's why we don't see this issue with trunk
>> 
>> It is possible to use a new java compiler to build for older versions of
>> java using the --target option, but I don't see any sign that we are
>> doing so.
>> 
>> Unfortunately the build is too silent for me to see what is actually
>> happening during the build.  My suspicion is that somehow the trunk
>> build is somehow using Java 7 to build.
> 
> I finally figured out the difference.  The 4.1.x build uses the selected
> javac to build the .class file, whereas trunk and 42X use ant, and
> solenv/ant/aoo-ant.xml (new to trunk ant 42X) says:
> 
> 
>> I see two paths forward.  The first is to build with the oldest version
>> of java that one might want to use, which is the status quo.  The second
>> is to somehow pass the --target option to specify an older java version
>> for compatibility.
> 
> We could also cherry-pick the jvmfwk conversion to gbuild and the other
> changes for ant.

Even simpler, there is a JAVAFLAGS variable used by the dmake build.
Configure sets it:
JAVAFLAGS="-source 1.5 -target 1.5"
for Eclipse Java Compiler, but otherwise leaves it unset.


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



Re: java detection

2020-09-25 Thread Don Lewis
On 24 Sep, Don Lewis wrote:
> I've been looking into the problem where AOO418 can't detect older
> versions of java when it is built with a new version of java.  This is a
> definite puzzle because the detection is done by the jvmfwk module, and
> the code in that module is identical between AOO418 and trunk.  The only
> difference is that this module has been changed from dmake to gbuild in
> trunk.
> 
> The way that java detection works is that we scan the possible java
> locations, and for each we run
>   [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
> 4\\program JREProperties
> which is supposed to output a bunch of data about that version of java,
> which we read and parse.  If that fails, then we decide that version of
> java is invalid or broken.
> 
> When I build AOO418 with Java 8 and it tries to detect Java 7, I see
> this stack trace sent to stderr:
> 
> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported 
> major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at 
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
> Exception in thread "main"
> 
> The problem is that the JREProperties was compiled with Java 8, which
> Java 7 can't use:
> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
> Java class data, version 52.0 (Java 1.8)
> 
> If I build trunk with Java 8, I see:
> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
> Java class data, version 51.0 (Java 1.7)
> That's why we don't see this issue with trunk
> 
> It is possible to use a new java compiler to build for older versions of
> java using the --target option, but I don't see any sign that we are
> doing so.
> 
> Unfortunately the build is too silent for me to see what is actually
> happening during the build.  My suspicion is that somehow the trunk
> build is somehow using Java 7 to build.

I finally figured out the difference.  The 4.1.x build uses the selected
javac to build the .class file, whereas trunk and 42X use ant, and
solenv/ant/aoo-ant.xml (new to trunk ant 42X) says:


> I see two paths forward.  The first is to build with the oldest version
> of java that one might want to use, which is the status quo.  The second
> is to somehow pass the --target option to specify an older java version
> for compatibility.

We could also cherry-pick the jvmfwk conversion to gbuild and the other
changes for ant.


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



Re: AOO418 cherry picks

2020-09-24 Thread Don Lewis
On 24 Sep, Matthias Seidel wrote:
> Great!
> 
> We should also cherry-pick Don's Python update:
> 
> https://github.com/apache/openoffice/commit/26aca12f509e5c739c98db9ce5641a2c5feecea7
> 
> And update LICENSE:
> 
> https://github.com/apache/openoffice/commit/1dedf1ecff4aeffe2f7c7612cbf893530465764e

Now that the big merge is out of the way, I've started working on
testing this for a pull request.


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



Re: AOO418 cherry picks

2020-09-24 Thread Don Lewis
On 24 Sep, Jim Jagielski wrote:
> Well, gotten further but now there are packaging issues. Something with the 
> new apr/apr-util/serf stuff is getting hosed... looking into it:
> 
> ERROR: The following files could not be found: 
> ERROR: File not found: libapr-1.0.5.2.dylib
> ERROR: File not found: libaprutil-1.0.5.4.dylib
> ERROR: File not found: libserf-1.0.0.0.dylib
> ... cleaning the output tree ...
> ... removing directory 
> /var/folders/_p/nx0kp5h157197n6ssf35ft7hgn/T/ooopackaging/i_446601600974718

I don't think there were any changes to serf.


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



java detection

2020-09-24 Thread Don Lewis
I've been looking into the problem where AOO418 can't detect older
versions of java when it is built with a new version of java.  This is a
definite puzzle because the detection is done by the jvmfwk module, and
the code in that module is identical between AOO418 and trunk.  The only
difference is that this module has been changed from dmake to gbuild in
trunk.

The way that java detection works is that we scan the possible java
locations, and for each we run
  [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
4\\program JREProperties
which is supposed to output a bunch of data about that version of java,
which we read and parse.  If that fails, then we decide that version of
java is invalid or broken.

When I build AOO418 with Java 8 and it tries to detect Java 7, I see
this stack trace sent to stderr:

java.lang.UnsupportedClassVersionError: JREProperties : Unsupported major.minor 
version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
Exception in thread "main"

The problem is that the JREProperties was compiled with Java 8, which
Java 7 can't use:
$ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
/cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
Java class data, version 52.0 (Java 1.8)

If I build trunk with Java 8, I see:
$ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
/cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
Java class data, version 51.0 (Java 1.7)
That's why we don't see this issue with trunk

It is possible to use a new java compiler to build for older versions of
java using the --target option, but I don't see any sign that we are
doing so.

Unfortunately the build is too silent for me to see what is actually
happening during the build.  My suspicion is that somehow the trunk
build is somehow using Java 7 to build.

I see two paths forward.  The first is to build with the oldest version
of java that one might want to use, which is the status quo.  The second
is to somehow pass the --target option to specify an older java version
for compatibility.


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



Re: AOO418 cherry picks

2020-09-22 Thread Don Lewis
On 22 Sep, Jim Jagielski wrote:
> Just a FYI that HEAD of AOO418 builds on macOS with no issues so far...

https://github.com/apache/openoffice/pull/94 has some macOS-specific
changes from AOO42X.




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



Re: Minimum MacOS Version for trunk and 4.2.0 builds

2020-09-22 Thread Don Lewis
On 20 Sep, Peter Kovacs wrote:
> 
> Am 20.09.20 um 20:16 schrieb Dave Fisher:
>>> On Sep 20, 2020, at 9:40 AM, Marcus  wrote:
>>>
>>> Am 19.09.20 um 12:36 schrieb Peter Kovacs:
 Keep in mind that C++ Standard has changed a lot in reasoned years,
 and at least I would like to go with the new standard. If we stick
 to the old code for long time it will make maintenance or
development more difficuilt. yes, that's why I wrote:
>>>
>>> ... keeping the baseline for every OS as long as (technically)
>>>possible ... As long as a compiler exists on that platform that
>>>compiles the older language standard we should not upgrade.
>>
>> I started this thread to discuss build tools and to consider what to
>> do when it becomes difficult to build and have the result work on a
>> minimum platform.
>>
>> My original suggestion is that:
>>
>> (1) 4.1.X always keeps the current OS minimums.
> IMHO we should retire 4.1.X as soon as we have stabilized 4.2.X
>> (2) Should 4.2 branch also keep the current OS minimums or consider
>> more recent OSs as minimums? Is there anything currently on that
>> branch that is a concern?
>>
>> (3) Should we consider more recent OS minimums for trunk which may
>> become 4.5 or 5.0?
> 
> I think we should adjust 4.2.0 but keep trunk the same for now. After 
> release we will have some more fixes to do.
> 
>>
>> What should drive the choice for a more recent minimums? Unavoidable
>> incompatibilities.
> 
> 1) I think we have to work between OSes our user use and the 
> Requirements our dependencies have.
> 
> 2) We have difficulties to update some dependencies since they made a 
> change to c++11 or later standard. In a serious way it would mean we 
> would have to maintain those dependencies or we find a way to backport 
> some C++ features. (i do not have a list.)

The only requirement for C++11 that I've run into is with very recent
versions of vigra.  That's not a depenency that we've ever tried to
upgrade.  I only discovered the issue because of the FreeBSD port, which
was using the system vigra package.  When vigra was updated on FreeBSD,
the port stopped building in C++98 mode, so I switched the port to the
bundled vigra.

The biggest problem I've run into is the lack of C99 support by the old
version of Visual C++ that we use on Windows.  Recent versions of nss
use C99 pretty heavily.  Getting C99 support requires a fairly recent
version of Visual C++.  Microsoft intends that the compiler be used
primarily for compiling C++, so they let the C support lag pretty far
behind.


> 3) Then the SDKs are moved out of maintenance. On Windows our SDK used 
> in the 4.1.X is already not available. On Mac we have a useable SDK 
> 10.10 that let us keep the Lion minimum OS, but the question is how 
> long. Changeing SDKs seems to be a lot of work. We should consider to 
> move away from the verge of availability.
> 
>> Has anyone studied modern Java JDKs and if there is an impact on
>> OpenOffice?
> 
> Mechtilde reported that our build fails on recent Debian due to Java 11.
> 
> 
> My suggestion is:
> 
> Linux: Move to CentOs 7 (As we have already decided)
> 
> MacOSX: Move to 10.10 (And see how much we can move up on the SDK side.
> 
> Windows: Keep WinXP and Move up SDKs as much as possible. (I think 
> latest SDK still supports WinXP target, but I am not sure.)
> 
> 
> 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: Minimum MacOS Version for trunk and 4.2.0 builds

2020-09-22 Thread Don Lewis
On 20 Sep, Dave Fisher wrote:
> 
> 
>> On Sep 20, 2020, at 9:40 AM, Marcus  wrote:
>> 
>> Am 19.09.20 um 12:36 schrieb Peter Kovacs:
>>> Keep in mind that C++ Standard has changed a lot in reasoned years,
>>> and at least I would like to go with the new standard. If we stick
>>> to the old code for long time it will make maintenance or
>>> development more difficuilt.
>> 
>> yes, that's why I wrote:
>> 
>> ... keeping the baseline for every OS as long as (technically)
>> possible ...
> 
> As long as a compiler exists on that platform that compiles the older
> language standard we should not upgrade.
> 
> I started this thread to discuss build tools and to consider what to
> do when it becomes difficult to build and have the result work on a
> minimum platform.
> 
> My original suggestion is that:
> 
> (1) 4.1.X always keeps the current OS minimums.
> 
> (2) Should 4.2 branch also keep the current OS minimums or consider
> more recent OSs as minimums? Is there anything currently on that
> branch that is a concern?

In 4.2 and trunk we switched to supporting a newer version of gstreamer,
which is only available in CentOS 7 and above I believe.

If you want to have a working gstreamer, which is optional, 4.1.x is
stuck at CentOS 5 and 6.  CentOS 7 does not have a package for the old
gstreamer.

I don't know the situation for the other Linux distros.


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



Re: [GitHub] [openoffice] DonLewisFreeBSD opened a new pull request #94: Bundle418

2020-09-15 Thread Don Lewis
After dodging a local wildfire and potential evacuation, excessive heat
warnings and requests by the power company to conserve power, possible
rolling blackouts due to power shortages, high wind warnings with a two
day Public Safety Power Shutoff to avoid power-line caused fires, smoke
plumes from other fires within a couple of hundred miles that filled the
air with hazardous amounts of smoke, and then finally catching up on
some of my backlog ... I finally have the bundled software update for
AOO418 ready.

On 16 Sep, GitBox wrote:
> 
> DonLewisFreeBSD opened a new pull request #94:
> URL: https://github.com/apache/openoffice/pull/94
> 
> 
>Cherry pick bundled software upgrades from AOO42X:
>
>Upgrade ext_libraries:
>apr
>apr-util
>hunspell-1.3.3
>ratscan
>
>Upgrade main modules:
>apache-commons
>beanshell
>libxml2
>libxslt
>more_fonts
>nss
>python
>redland
>
>external_deps.lst cleanups
> 
> 
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


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



Re: AOO418 cherry picks

2020-09-04 Thread Don Lewis
On  4 Sep, Matthias Seidel wrote:
> Hi Jim, Don,
> 
> Am 28.08.20 um 15:17 schrieb Jim Jagielski:
>> Let's commit and work after pushed.
> 
> We should try
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=127887
> 
> again for 4.1.8.

I've included it in a large bundle of cherry-picks that I've been
testing.


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



libxslt upgrade breaks CentOS 5 build

2020-08-30 Thread Don Lewis
I've been looking at upgrading a bunch of our bundled dependencies, and
it looks like upgrading libxslt (or maybe libxml2) breaks the build on
CentOS 5.

The writerfilter module uses xsltproc to generate the header
resources.hxx, and in some cases it contains invalid C cod such as:
return (getU32(744))>>;
whereas it should be:
return (getU32(744));

The shift fragment of this expression comes from this xsl template:
...

   
  

;
If there is a nonzero shift, the it should output "foo>>shift;", and if
the shift amount is zero, then it should just output "foo;".

In the normal case, the input data looks like:
  

  0
  

  

  
for a shift amount of zero.  One example of the broken case it is:
  

  
  

  

  
so the value is missing (the tag is self-closing in this case),
so presumably the if condition in the template is 'if test=">0"'. So
this input is looking pretty questionable.

The mystery is why this behaves differently on CentOS 5 vs. everywhere
else.  Only the resources.hxx header generated by CentOS 5 is broken.

One thing I noticed is that my CentOS 5 machine has system libxml and
libxslt libraries installed and they have the same library version
numbers as the ones we build.  My CentOS 6 machine does not.  The system
xsltproc generates a valid resources.hxx header.  One thought I had was
that the xsltproc that we build might be picking up the system
librariese and there was some subtle incompatiblity, but that does not
appear to be the case.  My other thought was some sort of compiler bug
triggered by the new code, but building the libxml2 and libxslt modules
with -O0 optimization did not change anything.

Probably the best fix is to modify the template to check for blank shift
values, but the mystery remains.

--- a/main/writerfilter/source/doctok/resources.xsl
+++ b/main/writerfilter/source/doctok/resources.xsl
@@ -576,7 +576,7 @@ class 
   
 
 )
-
+

   
 




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



Re: installing git on centos 5.5

2020-08-30 Thread Don Lewis
On 30 Aug, Carl Marcum wrote:
> Hi Don,
> 
> On 8/29/20 8:02 PM, Don Lewis wrote:
>> On 29 Aug, Don Lewis wrote:
>>> On 29 Aug, Don Lewis wrote:
>>>> On 23 Aug, Carl Marcum wrote:
>>>>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>>>>>
>>>>> First hurdle was figuring out out how to point to the vault.centos.org
>>>>> archived rpms.
>>>>> Unfortunately no git was available then.
>>>> I've managed to resurrect my CentOS 5 VM.
>>>>
>>>> git builds from source out of the box, but as I suspected, the system
>>>> openssl is too old to talk to github.
>>>>
>>>> Download and unpack openssl-1.0.2u.  Build and install according to the
>>>> instructions.  At the configure step:
>>>>./config --shared
>>>>
>>>> Download and unpack curl-7.71.1. Build and install.  At the configure
>>>> step:
>>>>LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
>>>> --disable-ldap
>>>>
>>>> Download and unpack git-2.28.0.  At the configure step:
>>>>./configure --with-openssl=/usr/local/ssl
>>> Not quite ... it was only working for me because I had set
>>> $LD_LIBRARY_PATH. Instead do this:
>>> LDFLAGS=-Wl,-R/usr/local/lib ./configure --with-openssl=/usr/local/ssl
>>> 
>>>> At the build step:
>>>>make CURL_DIR=/usr/local
>> Be preparied to download the anything missing from ext_sources elsewhere
>> and copy the files to the CentOS machine manually.  Because of the old
>> system OpenSSL, bootstrap can't speak https to much of anything.  Same
>> fro trying to use wget.
> 
> Thank you for the great replies.
> 
> I'm currently trying to build it on CentOS 6 since it has support until 
> November this year.
> The build has stopped a few times but I think I'm getting close.
> 
> Then I'll go back and try 5.

I am able to build AOO418 on 32-bit 5.




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



Re: installing git on centos 5.5

2020-08-29 Thread Don Lewis
On 29 Aug, Don Lewis wrote:
> On 29 Aug, Don Lewis wrote:
>> On 23 Aug, Carl Marcum wrote:
>>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>>> 
>>> First hurdle was figuring out out how to point to the vault.centos.org 
>>> archived rpms.
>>> Unfortunately no git was available then.
>> 
>> I've managed to resurrect my CentOS 5 VM.
>> 
>> git builds from source out of the box, but as I suspected, the system
>> openssl is too old to talk to github.
>> 
>> Download and unpack openssl-1.0.2u.  Build and install according to the
>> instructions.  At the configure step:
>>   ./config --shared
>> 
>> Download and unpack curl-7.71.1. Build and install.  At the configure
>> step:
>>   LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
>> --disable-ldap
>> 
>> Download and unpack git-2.28.0.  At the configure step:
>>   ./configure --with-openssl=/usr/local/ssl
> 
> Not quite ... it was only working for me because I had set
> $LD_LIBRARY_PATH. Instead do this:
>LDFLAGS=-Wl,-R/usr/local/lib ./configure --with-openssl=/usr/local/ssl
>
>> At the build step:
>>   make CURL_DIR=/usr/local

Be preparied to download the anything missing from ext_sources elsewhere
and copy the files to the CentOS machine manually.  Because of the old
system OpenSSL, bootstrap can't speak https to much of anything.  Same
fro trying to use wget.


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



Re: installing git on centos 5.5

2020-08-29 Thread Don Lewis
On 29 Aug, Don Lewis wrote:
> On 23 Aug, Carl Marcum wrote:
>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>> 
>> First hurdle was figuring out out how to point to the vault.centos.org 
>> archived rpms.
>> Unfortunately no git was available then.
> 
> I've managed to resurrect my CentOS 5 VM.
> 
> git builds from source out of the box, but as I suspected, the system
> openssl is too old to talk to github.
> 
> Download and unpack openssl-1.0.2u.  Build and install according to the
> instructions.  At the configure step:
>   ./config --shared
> 
> Download and unpack curl-7.71.1. Build and install.  At the configure
> step:
>   LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
> --disable-ldap
> 
> Download and unpack git-2.28.0.  At the configure step:
>   ./configure --with-openssl=/usr/local/ssl

Not quite ... it was only working for me because I had set
$LD_LIBRARY_PATH. Instead do this:
   LDFLAGS=-Wl,-R/usr/local/lib ./configure --with-openssl=/usr/local/ssl
   
> At the build step:
>   make CURL_DIR=/usr/local


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



Re: installing git on centos 5.5

2020-08-29 Thread Don Lewis
On 29 Aug, Don Lewis wrote:
> On 23 Aug, Carl Marcum wrote:
>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>> 
>> First hurdle was figuring out out how to point to the vault.centos.org 
>> archived rpms.
>> Unfortunately no git was available then.
> 
> I've managed to resurrect my CentOS 5 VM.
> 
> git builds from source out of the box, but as I suspected, the system
> openssl is too old to talk to github.
> 
> Download and unpack openssl-1.0.2u.  Build and install according to the
> instructions.  At the configure step:
>   ./config --shared
> 
> Download and unpack curl-7.71.1. Build and install.  At the configure
> step:
>   LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
> --disable-ldap
> 
> Download and unpack git-2.28.0.  At the configure step:
>   ./configure --with-openssl=/usr/local/ssl
> At the build step:
>   make CURL_DIR=/usr/local

BTW, I have only tested https URLs.


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



Re: installing git on centos 5.5

2020-08-29 Thread Don Lewis
On 23 Aug, Carl Marcum wrote:
> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
> 
> First hurdle was figuring out out how to point to the vault.centos.org 
> archived rpms.
> Unfortunately no git was available then.

I've managed to resurrect my CentOS 5 VM.

git builds from source out of the box, but as I suspected, the system
openssl is too old to talk to github.

Download and unpack openssl-1.0.2u.  Build and install according to the
instructions.  At the configure step:
  ./config --shared

Download and unpack curl-7.71.1. Build and install.  At the configure
step:
  LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
--disable-ldap

Download and unpack git-2.28.0.  At the configure step:
  ./configure --with-openssl=/usr/local/ssl
At the build step:
  make CURL_DIR=/usr/local


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



Re: AOO418 cherry picks

2020-08-27 Thread Don Lewis
On 27 Aug, Matthias Seidel wrote:
> Am 27.08.20 um 19:32 schrieb Matthias Seidel:
>>
>> Hi Don,
>>
>> Am 24.08.20 um 04:04 schrieb Don Lewis:
>>> I've got a bunch of cherry picks that I'm planning to merge into AOO418.
>>> There are two categories:
>>>   * Fixes from the FreeBSD port that have been upstreamed to the trunk
>>> and AOO42X branches, but I'm still carrying around in the FreeBSD
>>> port of 4.1.7.
>>>
>>>   * Updates of a bunch of the bundled dependencies.  These have been
>>> updated in AOO42X and trunk for a while, but haven't been merged to
>>> AOO418.  The FreeBSD port mostly usees the system versions of these.
>>>
>>> I'd like to revisit:
>>>
>>>   commit 7a3beb322b74df1b6c96e03605837df34781c68f
>>>   Author: Matthias Seidel 
>>>   Date:   Thu Oct 11 16:53:51 2018 +
>>>   
>>>   Rollback to Rev. 1843088 due to build errors.
>>>   
>>>   git-svn-id: 
>>> https://svn.apache.org/repos/asf/openoffice/branches/AOO416@18438571 
>>> 13f79535-47bb-0310-9956-ffa450edef68
>>>
>>> I'm still using the patch for the FreeBSD port.  Without it, a build
>>> with --enable-odk will fail with Java 8 or newer.  I don't see how it
>>> would break the build since the changes are just to structured comments
>>> that are parsed to generate the documentation in the ODK.  When this was
>>> backed out, I thought the reason was that building with a newer version
>>> of the JDK would prevent runtime detection of older versions of the JDK.
>>> So far asa I know, that's not a problem with AOO42X and trunk, which
>>> have the changes.
>>
>> If I remember it right the Rollback included:
>>
>>  - Issue 127887 - update bundled redland/raptor/rasqal
>>  - Issue 127875 - fix a loop that visits all objects on a page so that
>> all objects get visited
>>  - Issue 127874 - fix bad potential invalid subscript bug when using
>> Microsoft Uniscribe text layout API
>>
>> We should commit all of the above again, one after the other.
>>
> Correcting myself: I had re-committed Issue 127874 and Issue 127875 to
> 4.1.6 after the Rollback.
> 
> So Issue 127887 could now be committed to 4.1.8.
> We should discuss the change in configure.in regarding MacOS with Jim.

I'm working on a fairly large update to the bundled software.  I should
be able to create a pull request in a day or so.  127887 will be
included.  I'll test it on Linux and Windows.  I'll take a stab at the
MacOS bits, but won't be able to test it.

> Regards,
> 
>    Matthias
> 
>> "Issue 127876 - unbreak ODK build with Java 8" should be double
>> checked because of the known issue with Java 7 JRE.

Since 127876 only changes comments in our Java code, it should not
affect detection.  Without this change, is the Java 7 JRE detected if we
build with Java 8?


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-27 Thread Don Lewis
On 27 Aug, Matthias Seidel wrote:
> Hi Don,
> 
> Am 26.08.20 um 03:55 schrieb Don Lewis:
>> On 25 Aug, Don Lewis wrote:
>>> On 25 Aug, Pedro Lino wrote:
>>>>> On 08/25/2020 8:35 PM Don Lewis  wrote:
>>>>> Try deleting /opt/openoffice4/program/libgcc_s.so.1
>>>>> For some reason that bogus file is getting packaged by your build.
>>>> Yep. That fixed it. It doesn't make any sense to me that an extra file
>>>> prevents the program from working... Maybe this is part of some
>>>> forgotten/abandoned code?
>>> That file is in the shared library search path.  When you try to start a
>>> program, it is being found instead of the correct shared library file
>>> under /lib, causing the runtime linker to blow a gasket.
>>>
>>>> But the file is checked during compiling. If the file is not present,
>>>> building "postprocess" will fail...
>>>>
>>>> I will try building with --with-system-stdlibs
>>>>
>>>> Thank you for the tips and fixes!
>> I dug into this a bit more.  It turns out that the bogus copy of
>> libgcc_s.so.1 is a linker script and not a shared library.   Linker 
>> scripts are a failrly new thing, which is why we haven't run into this
>> before.  The build code that is grabbing this file was removed from
>> trunk and AOO42X a few years ago, which is why you didn't see the
>> problem with those versions.  I've cherry-picked the fix and will push
>> it to AOO418 after I've had a chance to test it.
> 
> Great!
> 
> Then we can set this issue (i104495 - libstdc++ removal) to
> resolved/fixed now?

I guess so, though I haven't tested the KDE bits.
 


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-25 Thread Don Lewis
On 25 Aug, Don Lewis wrote:
> On 25 Aug, Don Lewis wrote:
>> On 25 Aug, Pedro Lino wrote:
>>> 
>>>> On 08/25/2020 8:35 PM Don Lewis  wrote:
>>> 
>>>> Try deleting /opt/openoffice4/program/libgcc_s.so.1
>>>> For some reason that bogus file is getting packaged by your build.
>>> 
>>> Yep. That fixed it. It doesn't make any sense to me that an extra file
>>> prevents the program from working... Maybe this is part of some
>>> forgotten/abandoned code?
>> 
>> That file is in the shared library search path.  When you try to start a
>> program, it is being found instead of the correct shared library file
>> under /lib, causing the runtime linker to blow a gasket.
>> 
>>> But the file is checked during compiling. If the file is not present,
>>> building "postprocess" will fail...
>>> 
>>> I will try building with --with-system-stdlibs
>>> 
>>> Thank you for the tips and fixes!
> 
> I dug into this a bit more.  It turns out that the bogus copy of
> libgcc_s.so.1 is a linker script and not a shared library.   Linker 
> scripts are a failrly new thing, which is why we haven't run into this
> before.  The build code that is grabbing this file was removed from
> trunk and AOO42X a few years ago, which is why you didn't see the
> problem with those versions.  I've cherry-picked the fix and will push
> it to AOO418 after I've had a chance to test it.

I just updated AOO418 with the fix.  You should be able to successfully
build and run --without-system-stdlibs.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-25 Thread Don Lewis
On 25 Aug, Don Lewis wrote:
> On 25 Aug, Pedro Lino wrote:
>> 
>>> On 08/25/2020 8:35 PM Don Lewis  wrote:
>> 
>>> Try deleting /opt/openoffice4/program/libgcc_s.so.1
>>> For some reason that bogus file is getting packaged by your build.
>> 
>> Yep. That fixed it. It doesn't make any sense to me that an extra file
>> prevents the program from working... Maybe this is part of some
>> forgotten/abandoned code?
> 
> That file is in the shared library search path.  When you try to start a
> program, it is being found instead of the correct shared library file
> under /lib, causing the runtime linker to blow a gasket.
> 
>> But the file is checked during compiling. If the file is not present,
>> building "postprocess" will fail...
>> 
>> I will try building with --with-system-stdlibs
>> 
>> Thank you for the tips and fixes!

I dug into this a bit more.  It turns out that the bogus copy of
libgcc_s.so.1 is a linker script and not a shared library.   Linker 
scripts are a failrly new thing, which is why we haven't run into this
before.  The build code that is grabbing this file was removed from
trunk and AOO42X a few years ago, which is why you didn't see the
problem with those versions.  I've cherry-picked the fix and will push
it to AOO418 after I've had a chance to test it.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-25 Thread Don Lewis
On 25 Aug, Pedro Lino wrote:
> 
>> On 08/25/2020 8:35 PM Don Lewis  wrote:
> 
>> Try deleting /opt/openoffice4/program/libgcc_s.so.1
>> For some reason that bogus file is getting packaged by your build.
> 
> Yep. That fixed it. It doesn't make any sense to me that an extra file
> prevents the program from working... Maybe this is part of some
> forgotten/abandoned code?

That file is in the shared library search path.  When you try to start a
program, it is being found instead of the correct shared library file
under /lib, causing the runtime linker to blow a gasket.

> But the file is checked during compiling. If the file is not present,
> building "postprocess" will fail...
> 
> I will try building with --with-system-stdlibs
> 
> Thank you for the tips and fixes!
> 
> Best,
> Pedro
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-25 Thread Don Lewis
On 25 Aug, Pedro Lino wrote:
> Hi Matthias
> 
>> On 08/25/2020 8:07 PM Matthias Seidel  wrote:
> 
>> If you start AOO in a shell with "soffice", does that give some information?
> 
> Didn't think about that :)
> 
> /opt/openoffice4/program/javaldx: error while loading shared libraries: 
> /opt/openoffice4/program/libgcc_s.so.1: invalid ELF header
> /opt/openoffice4/program/soffice.bin: error while loading shared libraries: 
> /opt/openoffice4/program/libgcc_s.so.1: invalid ELF header

I configure with --with-system-stdlibs

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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-25 Thread Don Lewis
On 25 Aug, Pedro Lino wrote:
> Hi Matthias
> 
>> On 08/25/2020 8:07 PM Matthias Seidel  wrote:
> 
>> If you start AOO in a shell with "soffice", does that give some information?
> 
> Didn't think about that :)
> 
> /opt/openoffice4/program/javaldx: error while loading shared libraries: 
> /opt/openoffice4/program/libgcc_s.so.1: invalid ELF header
> /opt/openoffice4/program/soffice.bin: error while loading shared libraries: 
> /opt/openoffice4/program/libgcc_s.so.1: invalid ELF header

Try deleting /opt/openoffice4/program/libgcc_s.so.1
For some reason that bogus file is getting packaged by your build.  I'm
not seeing that happen here:
$ ls /opt/openoffice4/program/libg*
/opt/openoffice4/program/libgcc3_uno.so
/opt/openoffice4/program/libguesslang.so


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-25 Thread Don Lewis
On 25 Aug, Matthias Seidel wrote:
> Hi Pedro,
> 
> Am 25.08.20 um 20:11 schrieb Pedro Lino:
>> Hi Don
>>
>>> On 08/25/2020 10:59 AM Don Lewis  wrote:
>>> With the latest batch of cherry-picks that I just pushed to AOO418 and
>>> using OpenJDK 8, I was able to build AOO418 on Ubuntu 18.
>> After updating with your latest changes and hacking a bit with the libgcc 
>> file mentioned in the subject, compiling ended with success. However after 
>> installing (without errors) the program doesn't run...
> 
> If you start AOO in a shell with "soffice", does that give some information?

For me, it goes through the registration process and then I can create
and save a writer document.  If I exit, I can reopen the document from
the command line.  Looks like it works.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-25 Thread Don Lewis
On 25 Aug, Pedro Lino wrote:
> Hi Don
> 
>> On 08/25/2020 10:59 AM Don Lewis  wrote:
> 
>> With the latest batch of cherry-picks that I just pushed to AOO418
>> and using OpenJDK 8, I was able to build AOO418 on Ubuntu 18.
> 
> After updating with your latest changes and hacking a bit with the
> libgcc file mentioned in the subject, compiling ended with success.
> However after installing (without errors) the program doesn't run...
> 
> Did you install (or execute the binaries)? If they work can you share
> the tar.gz file?

I haven't had a chance to install it.  Once it built, I declared victory
and went to sleep.

I didn't run into the libgcc_s.so.1 problem.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-25 Thread Don Lewis
On 25 Aug, Pedro Lino wrote:
> 
>> On 08/25/2020 3:47 AM Don Lewis  wrote:
> 
>> It's one of the bug fixes that I
>> plan to cherry-pick for AOO418 tonight.
> 
> Excellent! Thanks!
> 
>> What version of OpenJDK are you using?  I'm seeing a fair amount of
>> fallout from OpenJDK 11.
> 
> I have both 8 and 11
> 
> sudo update-alternatives --config java
> 
> There are 2 choices for the alternative java (providing /usr/bin/java).
> 
>   SelectionPathPriority   
> Status
> 
> * 0/usr/lib/jvm/java-11-openjdk-amd64/bin/java    
> auto mode
>   1/usr/lib/jvm/java-11-openjdk-amd64/bin/java    
> manual mode
>   2/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081  
> manual mode
> 
> Java 11 is
> openjdk version "11.0.8" 2020-07-14
> OpenJDK Runtime Environment (build 11.0.8+10-post-Ubuntu-0ubuntu118.04.1)
> OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Ubuntu-0ubuntu118.04.1, mixed 
> mode, sharing)

With the latest batch of cherry-picks that I just pushed to AOO418 and
using OpenJDK 8, I was able to build AOO418 on Ubuntu 18.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-24 Thread Don Lewis
On 24 Aug, Pedro Lino wrote:
> 
>> On 08/24/2020 3:18 PM Don Lewis  wrote:
> 
>> Is this a parallel build?  Has the offuh module been built and
>> delivered?  Seems oa little dd that offuh is not listed as a dependency
>> in sax/prj/build.lst, but it is listed as a dependency of cppuhelper and 
>> cppuhelper is listed as a dependency of sax.
>> 
>> When offuh is delivered, it should put a copy of UnicodeType.hpp here:
>> solver/*/unxlngx6.pro/inc/offuh/com/sun/star/i18n/UnicodeType.hpp
> 
> I build using all cores (in this case 8). This was never a problem with 42X.
> 
> There was no offuh module...

If offuh was not built and delivered then that will break sax for sure.

With the latest set of cherry-picks, I'm seeing these modules fail:
  beanshell
  hsqldb
  saxon
  apache-commons
  rhino
  lucene
  ridljar
  jvmfwk

which are most/all java, I think.

i haven't run into the libgcc_s.so.1 issue.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-24 Thread Don Lewis
On 24 Aug, Don Lewis wrote:
> On 24 Aug, Pedro Lino wrote:
>> Hi Don, all
>> 
>>> On 08/24/2020 3:18 PM Don Lewis  wrote:
>> 
>>> Is this a parallel build?
>> 
>> Switched to single thread building
>> 
>> build --all
>> 
>> when it stopped I followed the suggestion by Rigo and deleted
>> /source/openoffice/main/solver/418/unxlngx6.pro/lib/libgcc_s.so.1
>> 
>> and restarted with build --all:icu
>> 
>> Now it stopped again at
>> 
>> In file included from 
>> /source/openoffice/main/solver/418/unxlngx6.pro/inc/boost/shared_array.hpp:17:0,
>>  from ../inc/basebmp/bitmapdevice.hxx:32,
>>  from 
>> /source/openoffice/main/basebmp/source/bitmapdevice.cxx:28:
>> /source/openoffice/main/solver/418/unxlngx6.pro/inc/boost/smart_ptr/shared_array.hpp:177:37:
>>  warning: mangled name for ‘void boost::shared_array::reset(Y*, D) [with 
>> Y = unsigned char; D = void (*)(void*) throw (); T = unsigned char]’ will 
>> change in C++17 because the exception specification is part of a function 
>> type [-Wnoexcept-type]
>>  template void reset( Y * p, D d )
>>  ^
>> dmake:  Error code 1, while making '../unxlngx6.pro/slo/bitmapdevice.obj'
>> 
>> 1 module(s): 
>>  basebmp
>> need(s) to be rebuilt
>> 
>> Reason(s):
>> 
>> ERROR: error 65280 occurred while making 
>> /source/openoffice/main/basebmp/source
>> 
>> When you have fixed the errors in that module you can resume the build by 
>> running:
>> 
>>  build --all:basebmp
>> 
>> Ideas?
> 
> basebmp fails due to a bug that I patched in trunk and AOO42X a while
> back, when clang on FreeBSD found it.  I guess that the version of gcc
> in Ubuntu 18 doesn't like it either.  It's one of the bug fixes that I
> plan to cherry-pick for AOO418 tonight.

I justt did that, but there is another change that I need to cherry-pick
for the patch to bundled boost before we are ready for the -std=gnu++98
fix for Linux.  The ancient version of boost that we bundle doesn't
really understand the features of modern gcc.  I can get away with the
-std=gnu++98 setting the FreeBSD port of 4.1.7 because it uses system
boost, which is more modern.  I need to do some more testing before I'm
ready for this.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-24 Thread Don Lewis
On 24 Aug, Pedro Lino wrote:
> Hi Don, all
> 
>> On 08/24/2020 3:18 PM Don Lewis  wrote:
> 
>> Is this a parallel build?
> 
> Switched to single thread building
> 
> build --all
> 
> when it stopped I followed the suggestion by Rigo and deleted
> /source/openoffice/main/solver/418/unxlngx6.pro/lib/libgcc_s.so.1
> 
> and restarted with build --all:icu
> 
> Now it stopped again at
> 
> In file included from 
> /source/openoffice/main/solver/418/unxlngx6.pro/inc/boost/shared_array.hpp:17:0,
>  from ../inc/basebmp/bitmapdevice.hxx:32,
>  from 
> /source/openoffice/main/basebmp/source/bitmapdevice.cxx:28:
> /source/openoffice/main/solver/418/unxlngx6.pro/inc/boost/smart_ptr/shared_array.hpp:177:37:
>  warning: mangled name for ‘void boost::shared_array::reset(Y*, D) [with Y 
> = unsigned char; D = void (*)(void*) throw (); T = unsigned char]’ will 
> change in C++17 because the exception specification is part of a function 
> type [-Wnoexcept-type]
>  template void reset( Y * p, D d )
>  ^
> dmake:  Error code 1, while making '../unxlngx6.pro/slo/bitmapdevice.obj'
> 
> 1 module(s): 
>   basebmp
> need(s) to be rebuilt
> 
> Reason(s):
> 
> ERROR: error 65280 occurred while making 
> /source/openoffice/main/basebmp/source
> 
> When you have fixed the errors in that module you can resume the build by 
> running:
> 
>   build --all:basebmp
> 
> Ideas?

basebmp fails due to a bug that I patched in trunk and AOO42X a while
back, when clang on FreeBSD found it.  I guess that the version of gcc
in Ubuntu 18 doesn't like it either.  It's one of the bug fixes that I
plan to cherry-pick for AOO418 tonight.

What version of OpenJDK are you using?  I'm seeing a fair amount of
fallout from OpenJDK 11.


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



Re: installing git on centos 5.5

2020-08-24 Thread Don Lewis
On 24 Aug, Carl Marcum wrote:
> Hi Don,
> 
> On 8/23/20 2:58 PM, Don Lewis wrote:
>> On 23 Aug, Carl Marcum wrote:
>>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>>>
>>> First hurdle was figuring out out how to point to the vault.centos.org
>>> archived rpms.
>>> Unfortunately no git was available then.
>>>
>>> Was this done for the build servers or has anyone else done this and how
>>> did you do it?
>> You may have to download the source and build it yourself.
> 
> That's what I'll try next.
> Any idea if I can build the latest version or need to back up somewhat?

One problem you might run into is that the version of openssl might be
too old to connect to github.  You might need to install a newer version
in /usr/local.  You might also need to install a newer version of ssh
and/or curl to link to that as well.

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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-24 Thread Don Lewis
On 24 Aug, Pedro Lino wrote:
> Hi Don, all
> 
>> On 08/24/2020 3:18 PM Don Lewis  wrote:
> 
>> Is this a parallel build?
> 
> Switched to single thread building
> 
> build --all
> 
> when it stopped I followed the suggestion by Rigo and deleted
> /source/openoffice/main/solver/418/unxlngx6.pro/lib/libgcc_s.so.1
> 
> and restarted with build --all:icu
> 
> Now it stopped again at
> 
> In file included from 
> /source/openoffice/main/solver/418/unxlngx6.pro/inc/boost/shared_array.hpp:17:0,
>  from ../inc/basebmp/bitmapdevice.hxx:32,
>  from 
> /source/openoffice/main/basebmp/source/bitmapdevice.cxx:28:
> /source/openoffice/main/solver/418/unxlngx6.pro/inc/boost/smart_ptr/shared_array.hpp:177:37:
>  warning: mangled name for ‘void boost::shared_array::reset(Y*, D) [with Y 
> = unsigned char; D = void (*)(void*) throw (); T = unsigned char]’ will 
> change in C++17 because the exception specification is part of a function 
> type [-Wnoexcept-type]
>  template void reset( Y * p, D d )
>  ^
> dmake:  Error code 1, while making '../unxlngx6.pro/slo/bitmapdevice.obj'
> 
> 1 module(s): 
>   basebmp
> need(s) to be rebuilt
> 
> Reason(s):
> 
> ERROR: error 65280 occurred while making 
> /source/openoffice/main/basebmp/source
> 
> When you have fixed the errors in that module you can resume the build by 
> running:
> 
>   build --all:basebmp
> 
> Ideas?

You might want to configure with --enable-verbose so that you can see
the compiler command line as each file is compiled.  That will show all
the options passed to the compiler.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-24 Thread Don Lewis
On 24 Aug, Pedro Lino wrote:
> Hi Don, all
> 
>> On 08/24/2020 3:18 PM Don Lewis  wrote:
> 
>> Is this a parallel build?
> 
> Switched to single thread building
> 
> build --all
> 
> when it stopped I followed the suggestion by Rigo and deleted
> /source/openoffice/main/solver/418/unxlngx6.pro/lib/libgcc_s.so.1
> 
> and restarted with build --all:icu
> 
> Now it stopped again at
> 
> In file included from 
> /source/openoffice/main/solver/418/unxlngx6.pro/inc/boost/shared_array.hpp:17:0,
>  from ../inc/basebmp/bitmapdevice.hxx:32,
>  from 
> /source/openoffice/main/basebmp/source/bitmapdevice.cxx:28:
> /source/openoffice/main/solver/418/unxlngx6.pro/inc/boost/smart_ptr/shared_array.hpp:177:37:
>  warning: mangled name for ‘void boost::shared_array::reset(Y*, D) [with Y 
> = unsigned char; D = void (*)(void*) throw (); T = unsigned char]’ will 
> change in C++17 because the exception specification is part of a function 
> type [-Wnoexcept-type]
>  template void reset( Y * p, D d )
>  ^
> dmake:  Error code 1, while making '../unxlngx6.pro/slo/bitmapdevice.obj'
> 
> 1 module(s): 
>   basebmp
> need(s) to be rebuilt
> 
> Reason(s):
> 
> ERROR: error 65280 occurred while making 
> /source/openoffice/main/basebmp/source
> 
> When you have fixed the errors in that module you can resume the build by 
> running:
> 
>   build --all:basebmp
> 
> Ideas?

This looks like just a warning:
77:37: warning: mangled name for ‘void boost::shared_array::reset(Y*, D)
[with Y = unsigned char; D = void (*)(void*) throw (); T = unsigned char]’
will change in C++17
and from the warning it looks like the -std=gnu++98 fix isn't taking
effect.  basebmp hasn't been converted to gbuild in AOO418, so the fix
should be in solenv/inc/unxlng.mk.

The actual error should show up as "error: " in the build output.


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



Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

2020-08-24 Thread Don Lewis
On 24 Aug, Pedro Lino wrote:
> Ciao Rigo
> 
>> > /source/openoffice/main/solver/418/unxlngx6.pro/lib/libgcc_s.so.1: invalid 
>> > ELF header
>> > 
> 
> Now it stopped at expat, but the issue was the same: libgcc_s.so.1: invalid 
> ELF header
> 
>> > I'm wondering why there is a copy of libgcc_s.so.1 here.  That should be
>> > a system library.
>> 
>> I also bumped into this very strange error.
>> 
>> The file was indeed not an ELF, but it contained a number (like "42")
>> or something like that. I cannot remember exactly.
> 
> If the file contained 42 that would be correct because 42 is the answer to 
> everything! ;)
> 
> https://duckduckgo.com/?q=the+answer+to+life+the+universe+everything
> 
>> If I recall correctly, deleting that spurious file was enough to let
>> the build proceed further.
>> 
>> Once the build succeeded, I was not able to reproduce the problem any
>> more, therefore I did not report it.
>> 
>> I hope this helps,
> 
> Yes, it did help to move one step further! Thank you for the suggestion!
> 
> Now it fails at
> 
> =
> Building module sax
> =
> 
> Entering /source/openoffice/main/sax/source/tools
> 
> mkout -- version: 1.8
> Making:all_sax.dpslo
> Compiling: sax/unxlngx6.pro/misc/sax_version.c
> Compiling: sax/source/tools/converter.cxx
> /source/openoffice/main/sax/source/tools/converter.cxx:25:10: fatal error: 
> com/sun/star/i18n/UnicodeType.hpp: No such file or directory
>  #include 
>   ^~~
> compilation terminated.
> dmake:  Error code 1, while making '../../unxlngx6.pro/slo/converter.obj'
> 
> Any ideas?

Is this a parallel build?  Has the offuh module been built and
delivered?  Seems oa little dd that offuh is not listed as a dependency
in sax/prj/build.lst, but it is listed as a dependency of cppuhelper and 
cppuhelper is listed as a dependency of sax.

When offuh is delivered, it should put a copy of UnicodeType.hpp here:
solver/*/unxlngx6.pro/inc/offuh/com/sun/star/i18n/UnicodeType.hpp

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



Re: AOO418 cherry picks

2020-08-24 Thread Don Lewis
On 24 Aug, Pedro Lino wrote:
> Hi Don, all
> 
> I'm still trying to compile 418 on Ubuntu 18.04 x64
> I updated the 418 code but I get stuck at module graphite with the following 
> error (log file at https://etherpad.wikimedia.org/p/config.log)
> 
> Any ideas?

The error is happening during the configure step for graphite.  The
config.log mentioned is this one:

main/graphite/unxlngx6.pro/misc/build/silgraphite-2.3.1/engine/config.log

I don't believe I've run across any problems here.


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



Re: installing git on centos 5.5

2020-08-24 Thread Don Lewis
On 24 Aug, Carl Marcum wrote:
> Hi Don,
> 
> On 8/23/20 2:58 PM, Don Lewis wrote:
>> On 23 Aug, Carl Marcum wrote:
>>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>>>
>>> First hurdle was figuring out out how to point to the vault.centos.org
>>> archived rpms.
>>> Unfortunately no git was available then.
>>>
>>> Was this done for the build servers or has anyone else done this and how
>>> did you do it?
>> You may have to download the source and build it yourself.
> 
> That's what I'll try next.
> Any idea if I can build the latest version or need to back up somewhat?

No idea.


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



AOO418 cherry picks

2020-08-23 Thread Don Lewis
I've got a bunch of cherry picks that I'm planning to merge into AOO418.
There are two categories:
  * Fixes from the FreeBSD port that have been upstreamed to the trunk
and AOO42X branches, but I'm still carrying around in the FreeBSD
port of 4.1.7.

  * Updates of a bunch of the bundled dependencies.  These have been
updated in AOO42X and trunk for a while, but haven't been merged to
AOO418.  The FreeBSD port mostly usees the system versions of these.

I'd like to revisit:

  commit 7a3beb322b74df1b6c96e03605837df34781c68f
  Author: Matthias Seidel 
  Date:   Thu Oct 11 16:53:51 2018 +
  
  Rollback to Rev. 1843088 due to build errors.
  
  git-svn-id: 
https://svn.apache.org/repos/asf/openoffice/branches/AOO416@18438571 
13f79535-47bb-0310-9956-ffa450edef68

I'm still using the patch for the FreeBSD port.  Without it, a build
with --enable-odk will fail with Java 8 or newer.  I don't see how it
would break the build since the changes are just to structured comments
that are parsed to generate the documentation in the ODK.  When this was
backed out, I thought the reason was that building with a newer version
of the JDK would prevent runtime detection of older versions of the JDK.
So far asa I know, that's not a problem with AOO42X and trunk, which
have the changes.



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



  1   2   3   4   >