Re: compiler warnings when building OpenOffice

[Don Lewis]

On 29 Aug, Don Lewis wrote:
> When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
> FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
> I'm mostly interested in the OpenOffice code and not the bundled
> external code, so I specifically built the FreeBSD port it uses
> --with-system-foo extensively which minimizes the compilation of third
> party code.  The total number of warnings is 5105.
> 
> 1175 -Wtautological-undefined-compare
>  949 -Wunused-private-field
>  660 -Wshift-negative-value
>  391 -Wunused-parameter
>  362 -Wunused-const-variable
>  312 -Woverloaded-virtual
>  177 -Wunused-variable
>  116 -Winfinite-recursion
>  109 -Wlogical-op-parentheses
>   93 -Wsign-compare
>   76 -Wdelete-non-virtual-dtor
>   72 -Wint-to-void-pointer-cast
>   63 -Wshadow
>   55 -Wunused-function
>   41 -Wformat
>   36 -Wreturn-type-c-linkage
>   30 -Wchar-subscripts
>   27 -Wdeprecated-declarations
>   26 -Wundefined-bool-conversion
>   26 -Wsizeof-pointer-memaccess
>   26 -Wformat-security
>   24 -Wunused-local-typedef
>   22 -Wmacro-redefined
>   21 -Wswitch
>   20 -Wbitwise-op-parentheses
>   18 -Winvalid-source-encoding
>   13 -Wuninitialized
>   11 -Wtautological-compare
>   11 -Wlogical-not-parentheses
>   11 -Wdangling-else
>9 -Wmismatched-new-delete
>8 -Wimplicit-function-declaration
>8 -Wheader-guard
>8 -Wcomment
>7 -Wtautological-constant-out-of-range-compare
>7 -Wself-assign
>6 -Wunused-value
>6 -Wunneeded-internal-declaration
>6 -Wtautological-pointer-compare
>6 -Wpointer-bool-conversion
>6 -Wparentheses-equality
>6 -Wdynamic-class-memaccess
>6 -Wconstant-conversion
>5 -Wpointer-sign
>4 -Wnull-conversion
>3 -Wunsequenced
>3 -Wreorder
>3 -Wknr-promoted-parameter
>3 -Wint-to-pointer-cast
>2 -Wstrncat-size
>2 -Wstring-compare
>2 -Wsometimes-uninitialized
>2 -Wconstant-logical-operand
>2 -Warray-bounds
>1 -Wunused-comparison
>1 -Wunknown-pragmas
>1 -Wstring-plus-int
>1 -Wpotentially-evaluated-expression
>1 -Wnon-literal-null-conversion
>1 -Wmismatched-tags
>1 -Wincompatible-pointer-types-discards-qualifiers
>1 -Wimplicit-int
>1 -Wignored-qualifiers
>1 -Wformat-extra-args
>1 -Wcompare-distinct-pointer-types
>1 -Wc++11-compat-deprecated-writable-strings
> 
> 
> A couple -Wtautological-undefined-compare warnings:
> 
> warning: reference cannot be bound to dereferenced null pointer in 
> well-defined C++ code; comparison may be assumed to always evaluate to false 
> [-Wtautologica
> l-undefined-compare]
> if ( == NULL) {
>  ^
> 
> warning: 'this' pointer cannot be null in well-defined C++ code; comparison 
> may be assumed to always evaluate to false [-Wtautological-undefin
> ed-compare]
>   if(this == 0 || this == ) {
>  ^~~~~
> 
> I'd like to just nuke these comparisions.

It looks like all the noise actually just stems from 26 instances of the
first of these and three of the second.


> To fix the -Wunused-private-field private field warnings, I'd prefer to
> delete them, but that would have the side effect of breaking the ABI if
> an extensions use the class constructor.  The alternative would be to
> mark them unused.  I don't think there are actually many cases of this.
> The same warning gets generated anytime the header is included.

There seem to be a lot more of these than I expected.

> In the case of -Wshift-negative-value, result of shifting negative
> values is undefined.  This is generally fixable by using unsigned values
> instead.
> 
> 
> I'm not sure what to about -Wunused-parameter.  It's probably a case by
> case situation where it may sometimes make sense to have a variant
> function that doesn't have that parameter and modify the callers.  The
> alternative is to mark the argument as unused.  I haven't really
> examined any of these in detail.

I've seen a mixture of causes.  Some are due to conditional
compiliation, some are class methods where the parameter is only
sometimes used.



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

compiler warnings when building OpenOffice

[Don Lewis]

When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
I'm mostly interested in the OpenOffice code and not the bundled
external code, so I specifically built the FreeBSD port it uses
--with-system-foo extensively which minimizes the compilation of third
party code.  The total number of warnings is 5105.

1175 -Wtautological-undefined-compare
 949 -Wunused-private-field
 660 -Wshift-negative-value
 391 -Wunused-parameter
 362 -Wunused-const-variable
 312 -Woverloaded-virtual
 177 -Wunused-variable
 116 -Winfinite-recursion
 109 -Wlogical-op-parentheses
  93 -Wsign-compare
  76 -Wdelete-non-virtual-dtor
  72 -Wint-to-void-pointer-cast
  63 -Wshadow
  55 -Wunused-function
  41 -Wformat
  36 -Wreturn-type-c-linkage
  30 -Wchar-subscripts
  27 -Wdeprecated-declarations
  26 -Wundefined-bool-conversion
  26 -Wsizeof-pointer-memaccess
  26 -Wformat-security
  24 -Wunused-local-typedef
  22 -Wmacro-redefined
  21 -Wswitch
  20 -Wbitwise-op-parentheses
  18 -Winvalid-source-encoding
  13 -Wuninitialized
  11 -Wtautological-compare
  11 -Wlogical-not-parentheses
  11 -Wdangling-else
   9 -Wmismatched-new-delete
   8 -Wimplicit-function-declaration
   8 -Wheader-guard
   8 -Wcomment
   7 -Wtautological-constant-out-of-range-compare
   7 -Wself-assign
   6 -Wunused-value
   6 -Wunneeded-internal-declaration
   6 -Wtautological-pointer-compare
   6 -Wpointer-bool-conversion
   6 -Wparentheses-equality
   6 -Wdynamic-class-memaccess
   6 -Wconstant-conversion
   5 -Wpointer-sign
   4 -Wnull-conversion
   3 -Wunsequenced
   3 -Wreorder
   3 -Wknr-promoted-parameter
   3 -Wint-to-pointer-cast
   2 -Wstrncat-size
   2 -Wstring-compare
   2 -Wsometimes-uninitialized
   2 -Wconstant-logical-operand
   2 -Warray-bounds
   1 -Wunused-comparison
   1 -Wunknown-pragmas
   1 -Wstring-plus-int
   1 -Wpotentially-evaluated-expression
   1 -Wnon-literal-null-conversion
   1 -Wmismatched-tags
   1 -Wincompatible-pointer-types-discards-qualifiers
   1 -Wimplicit-int
   1 -Wignored-qualifiers
   1 -Wformat-extra-args
   1 -Wcompare-distinct-pointer-types
   1 -Wc++11-compat-deprecated-writable-strings


A couple -Wtautological-undefined-compare warnings:

warning: reference cannot be bound to dereferenced null pointer in well-defined 
C++ code; comparison may be assumed to always evaluate to false [-Wtautologica
l-undefined-compare]
if ( == NULL) {
 ^

warning: 'this' pointer cannot be null in well-defined C++ code; comparison may 
be assumed to always evaluate to false [-Wtautological-undefin
ed-compare]
  if(this == 0 || this == ) {
 ^~~~~

I'd like to just nuke these comparisions.


To fix the -Wunused-private-field private field warnings, I'd prefer to
delete them, but that would have the side effect of breaking the ABI if
an extensions use the class constructor.  The alternative would be to
mark them unused.  I don't think there are actually many cases of this.
The same warning gets generated anytime the header is included.


In the case of -Wshift-negative-value, result of shifting negative
values is undefined.  This is generally fixable by using unsigned values
instead.


I'm not sure what to about -Wunused-parameter.  It's probably a case by
case situation where it may sometimes make sense to have a variant
function that doesn't have that parameter and modify the callers.  The
alternative is to mark the argument as unused.  I haven't really
examined any of these in detail.


For -Wunused-const-variable and -Wunused-variable, I propose just
deleting them unless they are referenced by conditionally compiled code,
in which case I would make the variable declaration conditional as well.


I fixed one other case of -Winfinite-recursion.  I'm pretty sure this is
just one error, but it is contained in a header.


I think -Wshadow warnings should be fixed by renaming the variable.


I don't recall ever seeing -Wunused-function scroll by, but if functions
are totally unused, they should be deleted.


The parentheses warnings should just get fixed.


This is an example -Wdelete-non-virtual-dtor warning:

warning: delete called on non-final 'RscError' that has virtual functions but 
non-virtual destructor [-Wdelete-non-virtual-dtor]
delete pErrHdl;

My C++ book says that non-virtual destructors are bad generally bad.  We
also compile with -Wno-non-virtual-dtor to suppress even more warnings.
Does anyone know why?


The -Wformat-security warnings should definitely be fixed.


The -Wformat warnings should also be fixed, though care must be taken
for both 32-bit and 64-bit builds.


I haven't really looked at the other warnings in any detail.


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

Re: Fwd: Re: Questions about buildbot internals

[Don Lewis]

On 28 Aug, Kay Schenk wrote:
> 
> 
> On 08/27/2016 06:22 PM, Gav wrote:
>> Hi.
>> 
>> On Sun, Aug 28, 2016 at 11:01 AM, Don Lewis <truck...@apache.org> wrote:
>> 
>>> On 28 Aug, Gav wrote:
>>>> On Sun, Aug 28, 2016 at 10:47 AM, Don Lewis <truck...@apache.org> wrote:
>>>>
>>>>> On 28 Aug, Gav wrote:
>>>>>> Hi Don,
>>>>>>
>>>>>> On Sun, Aug 28, 2016 at 10:31 AM, Don Lewis <truck...@apache.org>
>>> wrote:
>>>>>>
>>>>>>> On 28 Aug, Gav wrote:
>>>>>>>> junit 4.11 is installed on the new buildbots we are prepping for
>>> use
>>>>> fwiw
>>>>>>>
>>>>>>> We'll also need hamcrest version 1.3.
>>>>>>>
>>>>>>
>>>>>> Ubuntu 14.04 LTS python-hamcrest is version 1.8 , is that too new?
>>>>>> I'd like to try and stick to what the Ubuntu apt-get packages provide,
>>>>>> if not possible, alternate uris where we can get other versions from.
>>>>>
>>>>> We don't want python-hamcrest.  We just want the hamcrest1.3.jar file.
>>>>> I think this is it:
>>>>> <http://repo1.maven.org/maven2/org/hamcrest/hamcrest-
>>>>> all/1.3/hamcrest-all-1.3.jar>
>>>>>
>>>>>
>>>> ok, in that case should we just not add it as a buildbot buildstep to
>>>> download it during a build ?
>>>
>>> That was something that Damjan suggested as a possibility, but the
>>> question was whether ext_sources was an appropriate place to stash it as
>>> it is a compiled artifact.
>>>
>>> Based on this old bug report:
>>> <https://bugs.launchpad.net/ubuntu/+source/junit/+bug/784631>, you might
>>> want to investigate whether the junit package actually include hamcrest
>>> as well.
>>>
>>>
>> I expanded the install /usr/share/java/junit4.jar and saw no evidence of
>> hamcrest - and
>> the bug you reference is still open, so not fixed I guess :/
>> 
>> I found where it is being actively developed (junit4 and junit5) on GitHub.
>> 
>> https://github.com/junit-team/junit4/blob/master/pom.xml
>> 
>>  Shows that it pulls in hamcrest as a dependency - does that mean it makes
>> it available
>> for use ? I don't know.
> 
> First of all, thank you for all this work, Gav!
> 
> If you've got information on the complete pack for Junit4 (4.11), can
> you see if ANY hamcrest jar is included? I personally just manually
> downloaded hamcrest-core-1.3.jar, put into /usr/share/java and made a
> sym link called just  hamcrest.jar to it.

I don't have a Ubuntu 14 VM handy, but I just got my Ubuntu 16 VM
working again.  Junit doesn't install hamcrest, and python-hamcrest
doesn't either.  The package that does install hamcrest-all.jar is
libhamcrest-java.


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

Re: dmake

[Don Lewis]

On 27 Aug, Pedro Giffuni wrote:
>> On 28 Aug, Gav wrote:
>>> when did you try that last Don?
>>>
>>> That url comes up oops 404
>>
>> I last tried that in the last few weeks, but have been using a cached
>> copy since then.
>>
>> This page lists lots of mirrored copies:
>> 
>>
>> It looks like development has moved to GitHub:
>> 
> 
> and this is exactly what I was going to say ...
> 
> With the demise of Google code the project moved to github and is under 
> a new maintainer (FreeBSD uses the new github version).
> 
> Perhaps we should mirror dmake-4.12.2, which was the last version 
> released on apache-extras, on sourceforge and update the build link.

That seems like the easiest thing to do.  I tried downloading from
GitHub and ran into a complication.  The tarfile name downloaded from
github is DMAKE_4_12_2_2.tar.gz, but it unpacks into the directory
dmake-DMAKE_4_12_2_2 and bootstrap can't cope with that.  I could fix
bootstrap, but that only helps trunk.  Nothing could be done to fix
4.1.2 other than re-rolling the tarball.

At least for now, the new dmake download URL is:



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

Re: Fwd: Re: Questions about buildbot internals

[Don Lewis]

On 28 Aug, Gav wrote:
> Hi Don,
> 
> On Sun, Aug 28, 2016 at 10:31 AM, Don Lewis <truck...@apache.org> wrote:
> 
>> On 28 Aug, Gav wrote:
>> > junit 4.11 is installed on the new buildbots we are prepping for use fwiw
>>
>> We'll also need hamcrest version 1.3.
>>
> 
> Ubuntu 14.04 LTS python-hamcrest is version 1.8 , is that too new?
> I'd like to try and stick to what the Ubuntu apt-get packages provide,
> if not possible, alternate uris where we can get other versions from.

We don't want python-hamcrest.  We just want the hamcrest1.3.jar file.
I think this is it:
<http://repo1.maven.org/maven2/org/hamcrest/hamcrest-all/1.3/hamcrest-all-1.3.jar>


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

Re: dmake

[Don Lewis]

On 28 Aug, Gav wrote:
> when did you try that last Don?
> 
> That url comes up oops 404

I last tried that in the last few weeks, but have been using a cached
copy since then.

This page lists lots of mirrored copies:


It looks like development has moved to GitHub:



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

Re: Fwd: Re: Questions about buildbot internals

[Don Lewis]

On 28 Aug, Gav wrote:
> junit 4.11 is installed on the new buildbots we are prepping for use fwiw

We'll also need hamcrest version 1.3.


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

Re: dmake

[Don Lewis]

On 28 Aug, Gav wrote:
> Hi Guys,
> 
> We have set up a new 14.04 LTS 64 bit VM and are in the process of testing.
> 
> Can you tell me what you intend to do with 'dmake' please - we cant build
> without it currently. Is there an alternative uri we get it from?

The bootstrap script can build dmake and epm on the fly if these flags
are passed to configure:


--with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2

--with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz

I don't know if that is what we really want to do, but it does work.


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

Re: branches/gbuild-reintegration merged

[Don Lewis]

On 17 Aug, To: dev@openoffice.apache.org wrote:
> On 16 Aug, Don Lewis wrote:
>> On  7 Aug, Damjan Jovanovic wrote:
>>> Hi
>>> 
>>> branches/gbuild-reintegration has been merged to trunk. It has > 136
>>> patches and makes many changes throughout the code, so you probably need to
>>> "dmake clean" before rebuilding.
>>> 
>>> I haven't fixed the Windows build performance regression caused by issue
>>> #117845, so if you're building on Windows use --disable-pch which only
>>> extends your build time by around 2 hours instead of 6. If you aren't happy
>>> with this, please help me figure out the problem.
>> 
>> I did some sleuthing ...
>> 
>> I compared build logs between --enable-pch and --disable-pch builds. The
>> compiler command line for the --enable-pch build has the additional
>> option
>>  -DPRECOMPILED_HEADERS
>> which causes precompiled_foo.hxx to pull in a whole wad of headers even
>> if they aren't needed to compile an individual .cxx file.  That's why
>> the build is taking longer.  A precompiled version of
>> precompiled_foo.hxx is build beforehand by passing
>> -Ycprecompiled_foo.hxx to the compiler, but gbuild neglects to tell the
>> compiler to use it when building all the .cxx files because it never
>> passes -Yuprecompiled_foo.hxx to the compiler.
>> 
>> That option is supposed to come from
>> gb_PrecompiledHeader_get_enableflags or
>> gb_NoexPrecompiledHeader_get_enableflags in LinkTarget.mk, but for some
>> reason that isn't getting activated.
>> 
>> I don't see any obvious recent changes that might have broken this.
> 
> More digging ...
> 
> LinkTarget.mk contains some logic to that only enables the use of
> precompiled headers when the compiler flags that were used to build the
> precompiled header match the flags used to compile the target source
> file.  If I compare the compiler flags used to build the precompiled
> header with the flags used to compile one of the source files, I see
> these differences:
> 
> @@ -33,7 +33,6 @@
>  -D_DLL_
>  -DPRECOMPILED_HEADERS
>  -DSW_DLLIMPLEMENTATION
> --DSW_DLLIMPLEMENTATION
>  -Gd
>  -GR
>  -Gs
> @@ -78,13 +77,13 @@
>  -wd4826
>  -Zc:wchar_t-
>  -Zm500
> +-DEXCEPTIONS_ON
> +-EHa
>  -Ob1
>  -Oxs
>  -Oy-
> --DEXCEPTIONS_ON
> --EHa
> --Fd$W/LinkTarget/pdb/Library/isw.lib.pdb
> --I$S/sw/inc/pch/
> +-Fd
> +-I$S/sw/source/core/access/
>  -IC:/aoo/aoo-trunk/main/solver/420/wntmsci12.pro/inc/stl
>  -I$S/sw/source/core/inc
>  -I$S/sw/source/filter/inc
> @@ -108,7 +107,5 @@
>  -I$O/inc/udkapi
>  -I$O/inc/offapi
>  -c
> -$S/sw/inc/pch/precompiled_sw.cxx
> --Ycprecompiled_sw.hxx
> --Fp$W/PrecompiledHeader/nodebug/precompiled_sw.hxx.pch
> --Fo$W/PrecompiledHeader/nodebug/precompiled_sw.hxx.pch.obj
> +$S/sw/source/core/access/acccell.cxx
> +-Fo$W/CxxObject/sw/source/core/access/acccell.o
> 
> The potentially important differences are:
> 
>   * When building the precompiled header, -DSW_DLLIMPLEMENTATION is
> repeated
> 
>   * These flags are used when building the precompiled header:
> -Fd$W/LinkTarget/pdb/Library/isw.lib.pdb -I$S/sw/inc/pch/
> whereas these flags are used when building the target:
> -Fd -I$S/sw/source/core/access/
> 
> Another observation is that if an override of the compiler flags for
> a particular target disables the use of precompiled headers, then
> -DPRECOMPILED_HEADERS should not be passed to the compiler if -Yu is
> not.  That would avoid the pessimization of including all of those extra
> headers that are not used.

The answer turns out to be none of the above.  I didn't find the cause
for the duplication of -DSW_DLLIMPLEMENTATION, but it doesn't matter
because the duplicate is squashed by the comparison which uses
$(sort ...).  I don't think the latter difference is part of the
comparison.

The cause turns out to be that $(PCH_NAME) is not inherited by the
compile, so the -Yu compile flag is not used.  I've fixed this in
r1758061.

Doing "build --all -P2 -- -P2" on a two-core machine now takes:
377 minutes with --disable-pch
278 minutes with --enable-pch


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

Re: Googletest download failures

[Don Lewis]

On 26 Aug, Kay Schenk wrote:
> All our buildbots are currently failing trying to download
> http://googletest.googlecode.com/files/gtest-1.7.0.zip
> 
> Does anyone know if this is now the correct download location?
> https://github.com/google/googletest/archive/master.zip
> 
> I didn't have any problems about a week ago so I'm wondering if this is
> recent.

I don't have any problems here with wget:

%wget http://googletest.googlecode.com/files/gtest-1.7.0.zip
--2016-08-26 22:44:15--  http://googletest.googlecode.com/files/gtest-1.7.0.zip
Resolving googletest.googlecode.com (googletest.googlecode.com)... 
2607:f8b0:400e:c03::52, 74.125.25.82
Connecting to googletest.googlecode.com 
(googletest.googlecode.com)|2607:f8b0:400e:c03::52|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1164254 (1.1M) [application/zip]
Saving to: 'gtest-1.7.0.zip'

gtest-1.7.0.zip 100%[===>]   1.11M   484KB/sin 2.3s

2016-08-26 22:44:17 (484 KB/s) - 'gtest-1.7.0.zip' saved [1164254/1164254]


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

Re: svn commit: r1757861 - /openoffice/trunk/main/configure.ac

[Don Lewis]

... and hamcrest wasn't removed from set_soenv.in:

[snip]
configure: writing config.status
configure: creating ./config.status
config.status: creating set_soenv
config.status: creating Makefile
Possible unintended interpolation of @HAMCREST_CORE_JAR in string at 
./set_soenv line 1653.
Global symbol "@HAMCREST_CORE_JAR" requires explicit package name (did you 
forget to declare "my @HAMCREST_CORE_JAR"?) at ./set_soenv line 1653.
Execution of ./set_soenv aborted due to compilation errors.


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

Re: svn commit: r1757861 - /openoffice/trunk/main/configure.ac

[Don Lewis]

On 26 Aug, ksch...@apache.org wrote:
> Author: kschenk
> Date: Fri Aug 26 14:49:44 2016
> New Revision: 1757861
> 
> URL: http://svn.apache.org/viewvc?rev=1757861=rev
> Log:
> Put configure.ac back to r1755455 before junit, hamcrest vesion checks.
> Newere versions have not been reverted.
> 
> 
> Modified:
> openoffice/trunk/main/configure.ac
> 
> Modified: openoffice/trunk/main/configure.ac
> URL: 
> http://svn.apache.org/viewvc/openoffice/trunk/main/configure.ac?rev=1757861=1757860=1757861=diff
> ==
> --- openoffice/trunk/main/configure.ac (original)
> +++ openoffice/trunk/main/configure.ac Fri Aug 26 14:49:44 2016
> @@ -680,17 +680,10 @@ AC_ARG_WITH(ant-home,
>  AC_ARG_WITH(junit,
>  [  --with-junitSpecifies the JUnit 4 jar file to use for 
> JUnit-based
>tests.  --without-junit disables those tests.  Not
> -  relevant in the --without-java case. The 
> --with-hamcrest-core
> -  option is also necessary.
> +  relevant in the --without-java case.
>  
>Usage: --with-junit=
>  ],,with_junit=yes)
> -AC_ARG_WITH(hamcrest-core,
> -[  --with-hamcrest-coreSpecifies the hamcrest-core 1.3 jar file to use 
> for
> -  JUnit-based tests.  --without-junit disables those
> -  tests.  Not relevant in the --without-java or
> -  --without-junit cases.
> -],,with_hamcrest_core=yes)
>  AC_ARG_WITH(perl-home,
>  [  --with-perl-homeIf you have installed the Perl 5 Distribution, on 
> your
>system, please supply the path here.
> @@ -870,12 +863,6 @@ AC_ARG_WITH(asm-home,
>  
>Usage: --with-asm-home=
>  ],,)
> -AC_ARG_WITH(nasm-home,
> -[  --with-nasm-homeFor Windows users, please supply the path for the
> -  nasm.exe assembler.
> -
> -  Usage: --with-nasm-home= directory>
> -],,)


The nasm stuff is needed is now needed for Windows builds ...


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

On 25 Aug, To: Don Lewis wrote:
> On 26 Aug, Andrea Pescetti wrote:
>> On 24/08/2016 Don Lewis wrote:
>>>* Updated bundled serf to fix a CVE and a WebDAV issue.  The FreeBSD
>>>  port has been using the system version of the latest and greatest.
>> 
>> We've been discussing this separately. This will make the build system 
>> even more complex, but it does have advantages and brings to completion 
>> work started with 4.1.2.
>> 
>>>* Handle the Wiki Publisher and PDF Import extensions as integrated
>>>  extensions:
>>>  <https://wiki.openoffice.org/wiki/Setup_-_Bundled_Extensions>
>>>  I've done some work on this in the FreeBSD port, but I haven't
>>>  tackled the installer part for other platforms.
>> 
>> Can you elaborate on this? For example the fact that they shouldn't ping 
>> for updates looks problematic (not so bad, but it will require a 
>> reasonable release pace). And actually the document suggests that 
>> bundled dictionaries are handled as integrated extensions, which is not 
>> the case at the moment - and this allows users to get, for example, a 
>> fresh English dictionary when they wish.
> 
> The versions of these that are online are really old.  The version
> of Wiki Publisher online only works with 3.x, and the PDF importer
> is listed as only being compatible with 4.0.
> 
> Since these can get built as part of the OpenOffice build and seem to
> be version specific, it seems like looking for updates could cause
> problems.  If a user sees and installs an update, the extension gets
> stored as part of that user's profile.  If the user is running an
> older version of OpenOffice and installs an update intended for a newer
> version of OpenOffice, that could cause the application to crash.
> Similarly, if a user has a copy of the extension in his profile and
> upgrades OpenOffice, that could also cause a crash.

I forgot to mention that the PDF Import extension is somewhat
problematic to distribute.  It relies on poppler, which has a GPLv2
license.  We depend on poppler being installed on the system and there
is no option to to bundle it.


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

On 25 Aug, Andrea Pescetti wrote:

>>> 2. Update Java requirement from Java 1.5 to *at least* Java 1.7
>>> I am rather adamant that we change our building requirement to Java 1.7
>>> for all platforms. I will be changing that in our Building Guide today.
>>
>> Is there a real reason for it? I see this like saying (this is just an
>> example, not to be taken literally) "we drop support for Windows XP
>> since it's old and unsupported". In short: if we need work to drop Java
>> 1.5 then we have clear advantages in raising our requirement to 1.7,
>> otherwise we can simply drop the requirement saying "we won't explicitly
>> test compatibility with Java < 1.7"; but in that case we must provide
>> ways to obtain a compatible JRE for all the 4 supported platforms.

In the experiments that I've done, it seems like if you build with a
certain Java version, the resulting executables won't work with an older
Java version on the machine where the installation is done.


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

On 26 Aug, Andrea Pescetti wrote:
> On 24/08/2016 Don Lewis wrote:
>>* Updated bundled serf to fix a CVE and a WebDAV issue.  The FreeBSD
>>  port has been using the system version of the latest and greatest.
> 
> We've been discussing this separately. This will make the build system 
> even more complex, but it does have advantages and brings to completion 
> work started with 4.1.2.
> 
>>* Handle the Wiki Publisher and PDF Import extensions as integrated
>>  extensions:
>>  <https://wiki.openoffice.org/wiki/Setup_-_Bundled_Extensions>
>>  I've done some work on this in the FreeBSD port, but I haven't
>>  tackled the installer part for other platforms.
> 
> Can you elaborate on this? For example the fact that they shouldn't ping 
> for updates looks problematic (not so bad, but it will require a 
> reasonable release pace). And actually the document suggests that 
> bundled dictionaries are handled as integrated extensions, which is not 
> the case at the moment - and this allows users to get, for example, a 
> fresh English dictionary when they wish.

The versions of these that are online are really old.  The version
of Wiki Publisher online only works with 3.x, and the PDF importer
is listed as only being compatible with 4.0.

Since these can get built as part of the OpenOffice build and seem to
be version specific, it seems like looking for updates could cause
problems.  If a user sees and installs an update, the extension gets
stored as part of that user's profile.  If the user is running an
older version of OpenOffice and installs an update intended for a newer
version of OpenOffice, that could cause the application to crash.
Similarly, if a user has a copy of the extension in his profile and
upgrades OpenOffice, that could also cause a crash.

I'm not sure why dictionaries should be handled as integrated.

One thing that I don't like about integrated extensions is that while
they show up in the extension manager, there is no way to disable them.


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

On 24 Aug, Pedro Giffuni wrote:
> Hi Don;
> 
>> On 24 Aug, Pedro Giffuni wrote:
>>>
>>>
>>> On 08/24/16 10:34, Pedro Giffuni wrote:
 Hello;

>>> ...
>>>

>   * [low priority] Updated bundled CoinMP.  There has been an API
> change, which prevents the FreeBSD port from using the system
> version.  Difficulty unknown ...
>

 This is important, I was unaware of it. Sadly, I don't think I will
 have time for it before the release.

>>>
>>> A quick look at this ... FreeBSD is using version 1.8.3 which appears
>>> to be the latest.
>>>
>>> AOO could use the same version by default, it's just a matter of getting
>>> the new version to build on all platforms. I think.
>>
>> Unfortunately it is not that easy.  When I was cleaning up the the
>> FreeBSD port a while back, I went through all of the --with-system knobs
>> and CoinMP was one that did not work and broke the build.  My memory is
>> fuzzy, but I think there was an incompatible API change.
>>
> 
> Hmm ... I just looked and the openoffice-devel FreeBSD port is using
> the system coinmp. Actually CoinMP is only a wrapper around the core
> Coin libraries. I have always considered using the core libraries 
> directly as that provides more powerful options but I haven't found
> the time and motivation to work on it.

Hey, you're right.  It was a long time ago when I last worked on the
--with system stuff.

> I did try updating the CoinMP patches and it was not easy/fun. The Mac
> changes are likely to be troublesome.
> 
>> There are some other bundled bits that have the same problem, but CoinMP
>> is big and takes a while to build, which is my main motivation in this
>> case.  ICU also falls into this category, but I already know that it is
>> too difficult.
>>
> 
> Yes, that one is difficult and while Symphony has a most of what we may 
> need, the problem is that it has to be tested "multilingually".

I think even that stuff is pretty far behind the latest ICU.

> I did update most of the components you mention and even gave a talk 
> about it ;).
> 
>> It looks like the others are:
>>  ucpp
> 
> We are using the latest version.

Hmn, I wonder why the FreeBSD port is using the bundled one.

>>  mdds
> 
> The developer behind it broke compatibility with the AOO code (on
> purpose, for all I know). The code is actually calling for a replacement 
> but since it works we are leaving it untouched.
> 
>>  hsqldb
> 
> SUN had a branch with the required changes. I have some WIP patch for 
> that but there are other issues, like the database format is 
> incompatible. I have to spend more time on that but the change is
> worth the rescue.
> 
>>  libxmlsec
> 
> AOO uses a heavily modified version. Updating it requires a lot of 
> effort, basically forking libxmlsec.
> 
>>  stax
> 
> This is actually unused and can be thrown away, unless you are still
> using something older than Java 5.
> 
>>  rhino
> 
> Oh yes, we updated this once but it's category B so there's not a lot of 
> motivation to work on it. Newer java has functionality that can replace it.
> 
>>  xsltml
> 
> I don't remember well this one. I think it depended on something else 
> and ultimately I was just happy about using the system version.
> 
>>  saxon
> 
> The latest versions (saxon-he) lack the functionality AOO requires.
> We need to use saxon-B, and there is indeed a newer version but the
> packaging is different to what AOO carries. FreeBSD was using the system 
> one but we stopped using it due to conflicts with the saxon
> from another important package (Scilab),
> 
>>  icc
> 
> I think Giuseppe Castagno said it wasn't worth the effort and since
> he did the OOo related stuff I didn't look further. I like excuses to
> be lazy :).
> 
>> I do know that saxon is sort of funny case.
> 
> It is only used for very old MS-Office formats. It is probably not worth 
> the effort anyways. LibreOffice replaced it with C code and the author 
> actually offered to relicense it for us but I lost trace of him
> afterwards.
> 
> Hope that helps,
> 
> 
> 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: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

Add another libxml2 update to the list.  There is a new batch of CVEs.


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

On 24 Aug, Kay Schenk wrote:
> 
> 
> On 08/24/2016 11:56 AM, Don Lewis wrote:
>> On 24 Aug, Pedro Giffuni wrote:
>>>
>>>
>>> On 08/24/16 10:34, Pedro Giffuni wrote:
>>>> Hello;
>>>>
>>> ...
>>>
>>>>
>>>>>   * [low priority] Updated bundled CoinMP.  There has been an API
>>>>> change, which prevents the FreeBSD port from using the system
>>>>> version.  Difficulty unknown ...
>>>>>
>>>>
>>>> This is important, I was unaware of it. Sadly, I don't think I will
>>>> have time for it before the release.
>>>>
>>>
>>> A quick look at this ... FreeBSD is using version 1.8.3 which appears
>>> to be the latest.
>>>
>>> AOO could use the same version by default, it's just a matter of getting 
>>> the new version to build on all platforms. I think.
>> 
>> Unfortunately it is not that easy.  When I was cleaning up the the
>> FreeBSD port a while back, I went through all of the --with-system knobs
>> and CoinMP was one that did not work and broke the build.  My memory is
>> fuzzy, but I think there was an incompatible API change.
>> 
>> There are some other bundled bits that have the same problem, but CoinMP
>> is big and takes a while to build, which is my main motivation in this
>> case.  ICU also falls into this category, but I already know that it is
>> too difficult.
>> 
>> It looks like the others are:
>>  ucpp
>>  mdds
>>  hsqldb
>>  libxmlsec
>>  stax
>>  rhino
>>  xsltml
>>  saxon
>>  icc
>> I do know that saxon is sort of funny case.
> 
> Right now we don't have a Mac buildbot. We shouldn't risk updating
> anything that will cause other problems, unless, of course, it's a
> security issue. Yes, many of the newer versions of our external items
> would likely necessitate API changes. That is definitely a big issue.

Yeah, I was going to mention that we really need some testing on the
Mac.  We need more than just a buildbot, we also need someone to
actually exercise the code.


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

On 24 Aug, Pedro Giffuni wrote:
> 
> 
> On 08/24/16 10:34, Pedro Giffuni wrote:
>> Hello;
>>
> ...
> 
>>
>>>   * [low priority] Updated bundled CoinMP.  There has been an API
>>> change, which prevents the FreeBSD port from using the system
>>> version.  Difficulty unknown ...
>>>
>>
>> This is important, I was unaware of it. Sadly, I don't think I will
>> have time for it before the release.
>>
> 
> A quick look at this ... FreeBSD is using version 1.8.3 which appears
> to be the latest.
> 
> AOO could use the same version by default, it's just a matter of getting 
> the new version to build on all platforms. I think.

Unfortunately it is not that easy.  When I was cleaning up the the
FreeBSD port a while back, I went through all of the --with-system knobs
and CoinMP was one that did not work and broke the build.  My memory is
fuzzy, but I think there was an incompatible API change.

There are some other bundled bits that have the same problem, but CoinMP
is big and takes a while to build, which is my main motivation in this
case.  ICU also falls into this category, but I already know that it is
too difficult.

It looks like the others are:
ucpp
mdds
hsqldb
libxmlsec
stax
rhino
xsltml
saxon
icc
I do know that saxon is sort of funny case.


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

On 24 Aug, Pedro Giffuni wrote:
> Hello;
> 
>> Here is my list:
>>
>>   * Update bundled redland / rasqal / raptor to fix a CVE.  This is
>> currently in progress.  The FreeBSD port has been using the system
>> versions of the latest and greatest.
>>
> 
> 
> This is difficult because of dependencies between the three and the way
> the configure scripts are tied together :(.

Yes, I can confirm that it is a huge PITA.

>>   * Updated bundled serf to fix a CVE and a WebDAV issue.  The FreeBSD
>> port has been using the system version of the latest and greatest.
>>
> 
> Agreed, this is important.
> 
>>   * [low priority] Update bundled vigra.  This version is no longer
>> available upstream.  It is used by the basebmp module, but I don't
>> know what it is used for or how to test it.  I believe only the
>> headers are used.  The FreeBSD port uses the latest and greatest
>> version and I haven't heard of any problems.
>>
> 
> We are using the latest version that does NOT use CMake. TBH, the
> update is probably not worth it.

We do't actually build it.  We just unpack it and grab the headers from
the source.  This is what we've got in its makefile.mk:

CONFIGURE_DIR=
CONFIGURE_ACTION=

BUILD_DIR=
BUILD_ACTION=
BUILD_FLAGS=

>>   * [low priority] Updated bundled CoinMP.  There has been an API
>> change, which prevents the FreeBSD port from using the system
>> version.  Difficulty unknown ...
>>
> 
> This is important, I was unaware of it. Sadly, I don't think I will
> have time for it before the release.
> 
> While here ... In Kay's list there is BZ 123975, an update to Python 3.
> As stated in the BZ issue, this is not convenient at this time: we
> have tried hard to keep compatibility with OpenOffice.org and updating
> further would put that at risk.
> 
> Also the new Python versions upgraded the build scripts for Windows,
> which may require more work for our build system.
> 
> Somewhere in the distant future... we should also update ICU.

Yes.  I've looked at that and it looks difficult.  Something else that
falls in that category is silgraphite -> graphite2.


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

On 24 Aug, Rory O'Farrell wrote:
> On Wed, 24 Aug 2016 00:01:22 -0700 (PDT)
> Don Lewis <truck...@apache.org> wrote:

>> Someone should fix the broken spellcheck problem.  It generates a lot of
>> complaints from our users.
>> 
> 
> The "broken spellcheck problem" seems largely to be caused by over hasty 
> close-down of the computer before cached files (both hardware and software 
> caches) are properly written to disk.  User education is the answer - educate 
> them to be patient in closedown and wait for disk activity to finish before 
> power-off.

Maybe using fsync() to flush things out faster when shutting down the
app and keeping a backup copy of the config would help avoid the
problem.   We shouldn't just silently fail when something is corrupt.

I've even experienced this myself on my FreeBSD desktop which stays on
24x7 and has an UPS.  It took me quite a while to notice spellcheck
wasn't working.  I just thought my spelling was unusually good ;-)


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

Re: [DISCUSS] Release 4.2: General Topics

[Don Lewis]

Here is my list:

  * Update bundled redland / rasqal / raptor to fix a CVE.  This is
currently in progress.  The FreeBSD port has been using the system
versions of the latest and greatest.

  * Updated bundled serf to fix a CVE and a WebDAV issue.  The FreeBSD
port has been using the system version of the latest and greatest.

  * [low priority] Update bundled vigra.  This version is no longer
available upstream.  It is used by the basebmp module, but I don't
know what it is used for or how to test it.  I believe only the
headers are used.  The FreeBSD port uses the latest and greatest
version and I haven't heard of any problems.

  * [low priority] Updated bundled CoinMP.  There has been an API
change, which prevents the FreeBSD port from using the system
version.  Difficulty unknown ...

  * Fix the easy to fix compiler warnings.  In the case of unused
private class member variables, deleting them would cause an ABI
change because the object size would shrink.  If that is a problem
the alternate would be to mark them unused.  I think there are only
a small number of these, but they get reported many times.

  * Handle the Wiki Publisher and PDF Import extensions as integrated
extensions:

I've done some work on this in the FreeBSD port, but I haven't
tackled the installer part for other platforms.

  * Fix a problem that I stumbled across involving extensions that can
cause an infinite crash / recover loop.  I think I can generate an
alert when I detect the problem.  I'm not sure if I can use an
existing alert message or will need a new one.  If the latter, then
there will be some translation work required.

  * Give network connection failures a more informative error message.
I stumbled across this when tracking down a problem that was
confined to FreeBSD.


Someone should fix the broken spellcheck problem.  It generates a lot of
complaints from our users.


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

Re: upgrading bundled openssl

[Don Lewis]

On 21 Aug, Andrea Pescetti wrote:
> On 19/08/2016 Don Lewis wrote:
>> The upcoming serf upgrade also has a new dependency issue.  It has
>> changed to using scons as its build system, which has its own
>> dependencies, python and m4.  I haven't yet decided what to do about
>> that.
> 
> I may have already given this information elsewhere, but 
> https://bz.apache.org/ooo/show_bug.cgi?id=126312 is the reference issue 
> for the serf upgrade and I know there was more than what is written in 
> the issue, so you can ask for clarifications directly there in the comments.
> 
> Also, since serf is an Apache project and OpenOffice is a prominent user 
> of serf, the serf project may be able to advise on a possible 
> "lightweight" build process - even though I don't think there is one 
> different from scons.

I think I'm going to attempt to build with scons.  Windows is likely to
be the most problematic, but even there it it looks like it could be
feasible.  Cygwin comes with m4 and we build a bundled version of
python.  We wouldn't be able to build scons as part of bootstrap like we
do with dmake, but we should be able to build it as part of the main
build between python and serf.  On the other platforms, we could use the
system scons if it is available, or build it like in the Windows port,
but with either system python or bundled python.  We would just add m4
as a prerequisite and have configure check for its presence.


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

Re: configure error

[Don Lewis]

On 19 Aug, Patricia Shanahan wrote:
> 
> 
> On 8/19/2016 12:51 PM, Don Lewis wrote:
>> On 19 Aug, Patricia Shanahan wrote:
>>> I did an "svn update". Now configure is failing:
>>>
>>> 
>>> *  *
>>> *   Setting up the build environment variables.*
>>> *  *
>>> 
>>> checking solver path... default
>>> configure: writing config.status
>>> configure: creating ./config.status
>>> config.status: creating set_soenv
>>> config.status: creating Makefile
>>> Possible unintended interpolation of @HAMCREST_CORE_JAR in string at
>>> ./set_soenv line 1644.
>>> Global symbol "@HAMCREST_CORE_JAR" requires explicit package name (did
>>> you forget to declare "my @HAMCREST_CORE_JAR"?) at ./set_soenv line 1644.
>>> Execution of ./set_soenv aborted due to compilation errors.
>>
>> Either disable junit or add --with-hamcrest-core.
>>
>> This is why the Linux buildbots have been failing recently.
> 
> I tried adding the hamcrest option, and it just causes an additional 
> message:
> 
> configure: WARNING: unrecognized options: --with-hamcrest-core
> 
> Maybe I need a different configure version from the one checked in under 
> https://svn.apache.org/repos/asf/openoffice/trunk
> 
> Here are my full configure parameters:
> 
> Patricia@Jan2014Desktop /cygdrive/c/OpenOfficeDev/Trunk/main
> $ more run_configure.sh
> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
> ./configure \
>  --with-frame-home="$SDK_PATH" \
>  --with-psdk-home="$SDK_PATH" \
>  --with-midl-path="$SDK_PATH/bin" \
>  --disable-directx \
>  --with-ant-home="/cygdrive/c/ant" \
>  
> --with-dmake-url="http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2;
>  
> \
>  
> --with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz; 
> \
>  --enable-pch \
>  --disable-atl \
>  --disable-activex \
>  --without-junit \
>  --with-hamcrest-core \
>  --with-jdk-home="/cygdrive/c/Program Files (x86)/Java/jdk1.7.0_79"

Strange ...

I haven't played with it, but --with-hamcrest-core should specify the
location of the hamcrest-core .jar file unless you have it installed in
one of the places that configure looks for it.  You shouldn't need
hamcrest since you are specifying --without-junit.

I ran into configure problems when I updated after the junit/hamcrest
change and all I did was remove -with-junit from my configure command
line.

Hmn, I see that the error that you are seeing is coming from set_soenv
and not configure.  Did you rerun autoconf to regenerate configure after
the update?




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

Re: svn commit: r1756954 [1/2] - in /openoffice/trunk/main: ./ openssl/

[Don Lewis]

On 19 Aug, To: dev@openoffice.apache.org wrote:
> On 19 Aug, Dennis E. Hamilton wrote:
>> Great commit messages!
>> 
>>> -Original Message-
>>> From: truck...@apache.org [mailto:truck...@apache.org]
>>> Sent: Friday, August 19, 2016 11:28
>>> To: comm...@openoffice.apache.org
>>> Subject: svn commit: r1756954 [1/2] - in /openoffice/trunk/main: ./
>>> openssl/
>>> 
>>> Author: truckman
>>> Date: Fri Aug 19 18:28:06 2016
>>> New Revision: 1756954
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1756954=rev
>>> Log:
>>> Update the bundled version of OpenSSL from 0.9.8zh to 1.0.2h which
>>> fixes many vulnerabiliies and adds support for newer, more secure
>>> ciphers and versions of the protocol.
>>> 
>>> Note: OpenSSL version 1.0.2h contains two known minor vulnerabilites,
>>> CVE-2016-2177 and CVE-2016-2178, which will be fixed in the next
>>> OpenSSL release.  Their potential impact is low enough that that
>>> various Linux distros have chosen not to apply the upstream patches
>>> to the versions that they distribute.
>>> 
>>> On Windows, there is an optional new dependency on NASM,
>>> .  If NASM is not available, then the C
>>> implementations of the low-level crypto code will be used instead
>>> of the optimized assembly language versions.  Since OpenOffice is
>>> not a heavy user of this code, the impact should be minor.  If NASM
>>> is installed, but its location is not in $PATH, the directory
>>> containing nasm.exe should be passed to configure using --with-nasm-
>>> home.
>>> 
>> [ ... ]
>> [orcmid] 
>> 
>> Does the NASM code do the right thing with regard to CPU model
>> detection?  It sounds like there may be dependencies on instructions
>> that may not be on all processors for which Apache OpenOffice is
>> supported.  I am thinking in particular about processors on which
>> Windows XP will run but Windows 7 and later will not because of
>> hardware protection requirements and, I suspect, extended instruction
>> sets.
> 
> It is supposed to select the appropriate version of the code at runtime
> based on the CPU feature bits that tell whether the machine supports the
> newer SSE* and AVX instructions.  I should be able to give this a try in
> the next few days.

I'm pretty sure the old version of OpenSSL also had optimized assembly
language code as well.  What's interesting is that the VS 7 assembler
wasn't choking on any of the newer instructions but on a couple of
ordinary looking MOV instructions.


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

Re: svn commit: r1756954 [1/2] - in /openoffice/trunk/main: ./ openssl/

[Don Lewis]

On 19 Aug, Dennis E. Hamilton wrote:
> Great commit messages!
> 
>> -Original Message-
>> From: truck...@apache.org [mailto:truck...@apache.org]
>> Sent: Friday, August 19, 2016 11:28
>> To: comm...@openoffice.apache.org
>> Subject: svn commit: r1756954 [1/2] - in /openoffice/trunk/main: ./
>> openssl/
>> 
>> Author: truckman
>> Date: Fri Aug 19 18:28:06 2016
>> New Revision: 1756954
>> 
>> URL: http://svn.apache.org/viewvc?rev=1756954=rev
>> Log:
>> Update the bundled version of OpenSSL from 0.9.8zh to 1.0.2h which
>> fixes many vulnerabiliies and adds support for newer, more secure
>> ciphers and versions of the protocol.
>> 
>> Note: OpenSSL version 1.0.2h contains two known minor vulnerabilites,
>> CVE-2016-2177 and CVE-2016-2178, which will be fixed in the next
>> OpenSSL release.  Their potential impact is low enough that that
>> various Linux distros have chosen not to apply the upstream patches
>> to the versions that they distribute.
>> 
>> On Windows, there is an optional new dependency on NASM,
>> .  If NASM is not available, then the C
>> implementations of the low-level crypto code will be used instead
>> of the optimized assembly language versions.  Since OpenOffice is
>> not a heavy user of this code, the impact should be minor.  If NASM
>> is installed, but its location is not in $PATH, the directory
>> containing nasm.exe should be passed to configure using --with-nasm-
>> home.
>> 
> [ ... ]
> [orcmid] 
> 
> Does the NASM code do the right thing with regard to CPU model
> detection?  It sounds like there may be dependencies on instructions
> that may not be on all processors for which Apache OpenOffice is
> supported.  I am thinking in particular about processors on which
> Windows XP will run but Windows 7 and later will not because of
> hardware protection requirements and, I suspect, extended instruction
> sets.

It is supposed to select the appropriate version of the code at runtime
based on the CPU feature bits that tell whether the machine supports the
newer SSE* and AVX instructions.  I should be able to give this a try in
the next few days.


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

Re: configure error

[Don Lewis]

On 19 Aug, Patricia Shanahan wrote:
> I did an "svn update". Now configure is failing:
> 
> 
> *  *
> *   Setting up the build environment variables.*
> *  *
> 
> checking solver path... default
> configure: writing config.status
> configure: creating ./config.status
> config.status: creating set_soenv
> config.status: creating Makefile
> Possible unintended interpolation of @HAMCREST_CORE_JAR in string at 
> ./set_soenv line 1644.
> Global symbol "@HAMCREST_CORE_JAR" requires explicit package name (did 
> you forget to declare "my @HAMCREST_CORE_JAR"?) at ./set_soenv line 1644.
> Execution of ./set_soenv aborted due to compilation errors.

Either disable junit or add --with-hamcrest-core.

This is why the Linux buildbots have been failing recently.


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

Re: upgrading bundled openssl

[Don Lewis]

On 15 Aug, Marcus wrote:
> Am 08/15/2016 10:16 PM, schrieb Don Lewis:
>> I started working on upgrading the bundled version of openssl to 1.0.2h.
>> So far I've discovered that building in on Windows requires nasm.  That
>> will need to be documented in the build requirements / procedures.  I
>> think I need to add a check to configure to look for it and bail out if
>> nasm isn't installed, but I haven't gotten that far yet.  The Windows
>> buildbot will need to have nasm installed.
> 
> puh, so many dependencis and it's still increasing. ;-)
> 
> Thanks for working this out.

I figured out how to make nasm an optional dependency, so the openssl
update commit I just made won't immediately break our Windows buildbot.

The upcoming serf upgrade also has a new dependency issue.  It has
changed to using scons as its build system, which has its own
dependencies, python and m4.  I haven't yet decided what to do about
that.



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

Re: Download Junit and Hamcrest in ./bootstrap?

[Don Lewis]

On 12 Aug, Damjan Jovanovic wrote:
> Sadly it's not that simple: Junit builds with Maven, and Hamcrest with
> Gradle.
> 
> Is it ok to download the binaries, or is only source code allowed under
> ext_sources?

I think it would be misleading because of the directory name.  Dragging
in extra dependencies just to build the .jar files seems like a waste.
Downloading everything to one directory would make life easier, so it is
too bad about the name.

The description for OOO Extras on Sourceforge says this:

  A space to store classic OOo dependencies that cannot be easily
  redistributed in Apache OpenOffice's SVN tree,

  Initially this was meant for copyleft tarballs only but it is also
  pretty handy to mirror other file dependencies.

Since ext_sources isn't distributed in the source archives for
releases, checking even non-copyleft source tarballs into svn under that
directory only helps people who are building from sources checkout out
via svn.


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

Re: branches/gbuild-reintegration merged

[Don Lewis]

On  7 Aug, Damjan Jovanovic wrote:
> Hi
> 
> branches/gbuild-reintegration has been merged to trunk. It has > 136
> patches and makes many changes throughout the code, so you probably need to
> "dmake clean" before rebuilding.
> 
> I haven't fixed the Windows build performance regression caused by issue
> #117845, so if you're building on Windows use --disable-pch which only
> extends your build time by around 2 hours instead of 6. If you aren't happy
> with this, please help me figure out the problem.

I did some sleuthing ...

I compared build logs between --enable-pch and --disable-pch builds. The
compiler command line for the --enable-pch build has the additional
option
-DPRECOMPILED_HEADERS
which causes precompiled_foo.hxx to pull in a whole wad of headers even
if they aren't needed to compile an individual .cxx file.  That's why
the build is taking longer.  A precompiled version of
precompiled_foo.hxx is build beforehand by passing
-Ycprecompiled_foo.hxx to the compiler, but gbuild neglects to tell the
compiler to use it when building all the .cxx files because it never
passes -Yuprecompiled_foo.hxx to the compiler.

That option is supposed to come from
gb_PrecompiledHeader_get_enableflags or
gb_NoexPrecompiledHeader_get_enableflags in LinkTarget.mk, but for some
reason that isn't getting activated.

I don't see any obvious recent changes that might have broken this.


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

Re: upgrading bundled openssl

[Don Lewis]

On 15 Aug, Pedro Giffuni wrote:
> Hi Don;
> 
> Thanks for working on this!
> 
> Two crazy ideas here:
> 
> 1) Perhaps bundling libressl instead of openssl make sense?

I thought about that, but it seemed like a bigger step.  Also I don't
think curl is compatible.  When I tried building a set of FreeBSD
packages with libressl, I didn't get to OpenOffice because curl didn't
build.

> 2) It would be really nice if we were able to use encryption in other 
> components: apr-utils and curl, for example.

I'll look into that.

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

Re: Officially releasing a patch for CVE-2016-1513

[Don Lewis]

On 12 Aug, Dennis E. Hamilton wrote:
> Don,
> 
> Having worked through the 4.1.2-patch1 (CVE-2016-1513 remediation) for
> Windows, I learned a few more things about what can be done.
> 
> 
>> -Original Message-
>> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
>> Sent: Sunday, July 24, 2016 15:45
>> To: dev@openoffice.apache.org
>> Subject: RE: Officially releasing a patch for CVE-2016-1513
>> 
>> The patched DLL is shipped with an external digital signature.  I
>> guess we could ask that to be installed alongside it.  That would be
>> a good tell-tale.
>> 
>> The web site where the patch is downloadable from will have hashes
>> for the archive containing the patched library and will also have an
>> external signature for that.  These are on a secure AOO
>> infrastructure site, the best place to retrieve hashes and signature
>> files.  There is no reason not to have a hash of the library inside
>> the downloadable archive for those who, for some reason, cannot check
>> the signature but can verify the hash.
> [orcmid] 
> 
> There are hashes and a signature for the Zip that contains the patch
> and any procedure.
> 
> In the Windows case, the copies of the original distributed tl.dll and
> the patched one each have detached signatures inside the Zip as well. 
> No hashes have been added there, on the assumption that checking the
> Zip is good enough.

That sounds reasonable.  Checking the zip before unpacking is important
to prevent attacks against zip itself or to prevent unpacking some other
sort of malware.

This issue recently came up with FreeBSD, see:


>> 
>> In the manual procedure, we will ask users to rename the existing
>> shared-library before copying in the replacement.  This will provide
>> a means to revert to the patched library if a regression results.
> [orcmid] 
> 
> This approach is used.  If the patch is applied, the original tl.dll
> is renamed to tl.dll.old.  This is in the manual procedure and it is
> also provided by the script for the automated procedure.
> 
> The script for applying the patch can also be used to determine the
> patch is already there.  The script for reverting the patch will
> determine first whether the patch has been applied.

That also sounds reasonable.

>> 
>> There is a difference in file-creation dates and in the size of the
>> files as well.  The procedure for hotfixing with the patched library
>> should provide that information to discourage attempting to patch a
>> different release and also make it easier to tell the patch is there.
> [orcmid] 
> 
> For Windows, it turns out that dates are a problem on files because of
> how Windows distinguishes between created and modified. Some
> operations change one and not the other in unexpected ways.  There are
> also differences in this regard between versions of Windows in the
> range Windows XP to Windows 10.
> 
> There also seem to be possible issued with the Windows installer
> putting new dates on things.
> 
> Finally, it is not possible to check dates easily using a .bat script
> on Windows.
> 
> This is all resolved in the current 0.1.0 beta of the 4.1.2-patch1 for
> Windows by literally comparing files, rather than checking their dates
> and it is done without depending on signature computation tools being
> available on the machine.
> 
> That's how the procedure determines whether the patch file has already
> been applied or not.

That also sounds reasonable.  What tool do you use for the file
comparison?


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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Don Lewis]

On 12 Aug, Dennis E. Hamilton wrote:
> 
> 
>> -Original Message-----
>> From: Don Lewis [mailto:truck...@apache.org]
>> Sent: Thursday, August 11, 2016 14:41
>> To: dev@openoffice.apache.org; ksch...@apache.org
>> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
>> Applying openoffice-4.1.2-patch1 for Windows)
>> 
>> On 11 Aug, Kay sch...@apache.org wrote:
>> >
>> >
>> > On 08/11/2016 12:50 PM, Kay sch...@apache.org wrote:
>> >>
>> >>
>> >> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>> >>> [top posting]
>> >>> I'm in the process of trying to "sync" instructions for Linux32,
>> >>> Linux64, and MacOSX at the moment. As far as instructions on the
>> >>> actual HOTFIX page, we need to have just a "general" instruction
>> >>> for ALL zips that simply says -- "Unzip this package to some
>> >>> folder of your choosing and read the README that's included."
>> >>> Everything else should be in the various READMEs for each
>> >>> platform.
>> >>>
>> >>> I should be done with all edits by this evening for a final
>> >>> review before zipping and signing.
>> >>
>> >> Ok, I've now moved on to creating zip files, etc for Linux32,
>> >> Linux64 and Mac.
>> >>
>> >> My openssl version on does NOT supply digest sha256. Is it OK to
>> >> use sha1? MD5 already computed for each of these.
>> >
>> > sha1 is referenced on the ASF code signing page so I decided it was
>> OK. :)
>> 
>> I'm really surprised that ASF requires MD5 since it was broken long
>> ago. Even SHA1 is now regarded as a weak hash.
> [orcmid] 
> 
> I think it depends on shrinking the attack surface and also what the
> MD5 is being used for.  In the present case, it is extremely difficult
> to construct a Zip that has different usable content and the same
> hash.  It would require adding extra content until the correct hash is
> duplicated despite alteration of the key payload, and that should
> become rather evident.  I think the main reason for keeping it is that
> checking the MD5 is still more widely available to users.  It may not
> be foolproof but it is better than not.
> 
> And yes, collisions are possible and can be manufactured, but having
> one that accomplishes something can be rather tricky.  The
> proofs-of-concept involve alterations that aren't visible and won't be
> noticed.  Somebody will notice and it is not clear that the possible
> benefit is worth the effort to pull it off, especially against the
> risk of discovery.
> 
> Hmm, one thing we could do is add the length of the zip in the README.
>  (It takes a little work, but can be done, even when the (signed)
> README is inside the Zip.  That's another nice reason for having the
> signed README also available for independent download outside of the
> Zip and only downloadable from the ASF archive site, along with the
> different hashes and the package's signature.

Adding the length definitely raises the bar.  When downloading
third-party source tarballs to build FreeBSD packages, both the hash and
file size are checked.  Even so, FreeBSD has switched from md5, to sha1,
and now sha256 for the hash.


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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Don Lewis]

On 11 Aug, Kay sch...@apache.org wrote:
> 
> 
> On 08/11/2016 12:50 PM, Kay sch...@apache.org wrote:
>> 
>> 
>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>> [top posting]
>>> I'm in the process of trying to "sync" instructions for Linux32,
>>> Linux64, and MacOSX at the moment. As far as instructions on the
>>> actual HOTFIX page, we need to have just a "general" instruction for
>>> ALL zips that simply says -- "Unzip this package to some folder of
>>> your choosing and read the README that's included." Everything else
>>> should be in the various READMEs for each platform.
>>>
>>> I should be done with all edits by this evening for a final review
>>> before zipping and signing.
>> 
>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>> and Mac.
>> 
>> My openssl version on does NOT supply digest sha256. Is it OK to use
>> sha1? MD5 already computed for each of these.
> 
> sha1 is referenced on the ASF code signing page so I decided it was OK. :)

I'm really surprised that ASF requires MD5 since it was broken long ago.
Even SHA1 is now regarded as a weak hash.


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

Re: Download Junit and Hamcrest in ./bootstrap?

[Don Lewis]

On 11 Aug, Kay Schenk wrote:
> 
> 
> On 08/11/2016 01:05 PM, Kay Schenk wrote:
>> 
>> On 08/11/2016 09:53 AM, Don Lewis wrote:
>>> On 11 Aug, Kay sch...@apache.org wrote:
>>>>
>>>> On 08/11/2016 01:42 AM, Damjan Jovanovic wrote:
>>>>> Hi
>>>>>
>>>>> If you've been checking the buildbots you'll see that all who don't use
>>>>> --without-junit are currently broken in ./configure due to junit being too
>>>>> old. This is unlikely to change, as the buildslaves are running Ubuntu
>>>>> 10.04 which doesn't have newer versions of Junit available in apt.
>>>>>
>>>>> This is part of a bigger problem, which is that Junit's dependencies
>>>>> changed multiple times in the 4.x releases, which is why I changed
>>>>> configure.ac to need at least 4.11 (the maximum being 4.12).
>>>>>
>>>>> Instead of needing a correct system Junit version to run tests during the
>>>>> build, and having to worry about having correct system versions of 
>>>>> Hamcrest
>>>>> on the classpath, should we not rather treat them like external
>>>>> dependencies and download specific versions during ./bootstrap? It's under
>>>>> 300 kB for both, and the bvt/fvt/pvt tests already download their own 
>>>>> copy.
>>>>>
>>>>> Damjan
>>>>>
>>>>
>>>> This would be OK with me. What version of the jre does Junit 4.11
>>>> require? I can't find information about this on the junit site
>>>> --http://junit.org/junit4/
>>>>
>>>> Right now, we're still spec'd at jdk 1.6 for everything except Windows,
>>>> but IMO we should advance to 1.7 .
>>>
>>> That sounds good to me as well, but are there any issues with installing
>>> a newer jdk on older Linux distributions that we still support?
>> 
>> Andrea put out a notice for setting up a production farm of machines --
>> see:
>>  
>> http://mail-archives.apache.org/mod_mbox/openoffice-dev/201608.mbox/%3C57AA12CA.1090207%40apache.org%3E
>> 
>> We'd have to use CentOS 5.11 since this is the only 5 version that is
>> NOT deprecated. It looks like java 1.7 SDK is available for that
>> distribution.
>> 
>> http://mirror.centos.org/centos/5.11/os/i386/CentOS/
>> 
>> We also know that the older branch 4.1.2 will not work with java 1.7,
> 
> [sorry I misspoke here. 4.1.2 will NOT work with java 1.8. 4.2 works
> with either java 1.7 or java 1.8]

The FreeBSD port of OpenOffice 4.1.2 works with java 1.8.  The only
problem that I know if related to using 1.8 to build is that that after
installation it will only work with 1.8.  If you build with 1.7, then
you can use either 1.7 or 1.8 on the machine where OpenOffice is
installed.


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

Re: Download Junit and Hamcrest in ./bootstrap?

[Don Lewis]

On 11 Aug, Kay sch...@apache.org wrote:
> 
> On 08/11/2016 01:42 AM, Damjan Jovanovic wrote:
>> Hi
>> 
>> If you've been checking the buildbots you'll see that all who don't use
>> --without-junit are currently broken in ./configure due to junit being too
>> old. This is unlikely to change, as the buildslaves are running Ubuntu
>> 10.04 which doesn't have newer versions of Junit available in apt.
>> 
>> This is part of a bigger problem, which is that Junit's dependencies
>> changed multiple times in the 4.x releases, which is why I changed
>> configure.ac to need at least 4.11 (the maximum being 4.12).
>> 
>> Instead of needing a correct system Junit version to run tests during the
>> build, and having to worry about having correct system versions of Hamcrest
>> on the classpath, should we not rather treat them like external
>> dependencies and download specific versions during ./bootstrap? It's under
>> 300 kB for both, and the bvt/fvt/pvt tests already download their own copy.
>> 
>> Damjan
>> 
> 
> This would be OK with me. What version of the jre does Junit 4.11
> require? I can't find information about this on the junit site
> --http://junit.org/junit4/
> 
> Right now, we're still spec'd at jdk 1.6 for everything except Windows,
> but IMO we should advance to 1.7 .

That sounds good to me as well, but are there any issues with installing
a newer jdk on older Linux distributions that we still support?


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

Re: Download Junit and Hamcrest in ./bootstrap?

[Don Lewis]

On 11 Aug, Damjan Jovanovic wrote:
> Hi
> 
> If you've been checking the buildbots you'll see that all who don't use
> --without-junit are currently broken in ./configure due to junit being too
> old. This is unlikely to change, as the buildslaves are running Ubuntu
> 10.04 which doesn't have newer versions of Junit available in apt.
> 
> This is part of a bigger problem, which is that Junit's dependencies
> changed multiple times in the 4.x releases, which is why I changed
> configure.ac to need at least 4.11 (the maximum being 4.12).
> 
> Instead of needing a correct system Junit version to run tests during the
> build, and having to worry about having correct system versions of Hamcrest
> on the classpath, should we not rather treat them like external
> dependencies and download specific versions during ./bootstrap? It's under
> 300 kB for both, and the bvt/fvt/pvt tests already download their own copy.

That's fine with me as long as it is still an option to use the system
version as long as it is recent enough.


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

Re: expat upgrade patch needs testing

[Don Lewis]

On  9 Aug, Kay Schenk wrote:
> 
> On 08/08/2016 03:22 PM, Don Lewis wrote:
>> On  8 Aug, Kay Schenk wrote:
>>>
>>>
>>> On 08/07/2016 08:03 PM, Don Lewis wrote:
>>>> On  5 Aug, To: dev@openoffice.apache.org wrote:
>>>>> I just submitted a patch to upgrade the bundled expat to version 2.2.0:
>>>>> <https://bz.apache.org/ooo/show_bug.cgi?id=127069>
>>>>>
>>>>> I've done some testing on FreeBSD and Windows.  Unfortunately I can't
>>>>> test Linux at the moment.  After a Virtualbox upgrade, both of my Linux
>>>>> VMs panic the host system when I try start them in Virtualbox.
>>>>
>>>> I found that if I set the number of processors to 1 for my Linux VMs,
>>>> then I can get them to run.  I was able to build and test this patch on
>>>> CentOS 7 and Ubuntu 12.
>>>>
>>>>
>>>
>>> I can probably do a build tomorrow to test with CentOS 6.8.
>>> Assuming I get a successful build, what else do I need to do to test?
>> 
>> If you get through the build, that's a pretty good test.  During the
>> build saxparser uses expat to read the .xml files for all of the
>> locales.
>> 
>> The other thing that expat seems to get used for is the tree view of
>> help topics.
>>  Help -> OpenOffice Help -> Contents
>> 
>> 
> ./bootstrap broke for me because
> 
> https://sourceforge.net/projects/oooextras.mirror/files/2f47841c829facb346eb6e3fab5212e2-expat-2.2.0.tar.bz2
> 
> is not available on Sourceforge. Can you upload? Thanks.

I don't have upload access, but I suggest that you just try again.

Expat isn't something that we checked into svn under ext_sources. The
expat project lives on Sourceforge, so if it was working before it
should still work, modulo transient Sourceforge mirror issues.  Expat
isn't something that we checked into svn under ext_sources, modulo
Sourceforge transient mirror issues.



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

Re: expat upgrade patch needs testing

[Don Lewis]

On  8 Aug, Kay Schenk wrote:
> 
> 
> On 08/07/2016 08:03 PM, Don Lewis wrote:
>> On  5 Aug, To: dev@openoffice.apache.org wrote:
>>> I just submitted a patch to upgrade the bundled expat to version 2.2.0:
>>> <https://bz.apache.org/ooo/show_bug.cgi?id=127069>
>>>
>>> I've done some testing on FreeBSD and Windows.  Unfortunately I can't
>>> test Linux at the moment.  After a Virtualbox upgrade, both of my Linux
>>> VMs panic the host system when I try start them in Virtualbox.
>> 
>> I found that if I set the number of processors to 1 for my Linux VMs,
>> then I can get them to run.  I was able to build and test this patch on
>> CentOS 7 and Ubuntu 12.
>> 
>> 
> 
> I can probably do a build tomorrow to test with CentOS 6.8.
> Assuming I get a successful build, what else do I need to do to test?

If you get through the build, that's a pretty good test.  During the
build saxparser uses expat to read the .xml files for all of the
locales.

The other thing that expat seems to get used for is the tree view of
help topics.
Help -> OpenOffice Help -> Contents


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

Re: expat upgrade patch needs testing

[Don Lewis]

On  5 Aug, To: dev@openoffice.apache.org wrote:
> I just submitted a patch to upgrade the bundled expat to version 2.2.0:
> 
> 
> I've done some testing on FreeBSD and Windows.  Unfortunately I can't
> test Linux at the moment.  After a Virtualbox upgrade, both of my Linux
> VMs panic the host system when I try start them in Virtualbox.

I found that if I set the number of processors to 1 for my Linux VMs,
then I can get them to run.  I was able to build and test this patch on
CentOS 7 and Ubuntu 12.


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

expat upgrade patch needs testing

[Don Lewis]

I just submitted a patch to upgrade the bundled expat to version 2.2.0:


I've done some testing on FreeBSD and Windows.  Unfortunately I can't
test Linux at the moment.  After a Virtualbox upgrade, both of my Linux
VMs panic the host system when I try start them in Virtualbox.


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

Re: disabling crash recovery

[Don Lewis]

On 27 Jul, Marcus wrote:
> Am 07/27/2016 08:00 PM, schrieb Don Lewis:
>> Is there any way of disabling the automagic crash recovery?  I'm
>> attempting to debug a crash and the crash recovery / restart seems to be
>> confusing gdb.  Just letting SIGSEGV take its natural course of action
>> would be fine.
> 
> are you looking for this [1]?
> 
> [1] https://wiki.openoffice.org/wiki/Debugging#gdb_invocation
> 
> If not, then I only know the commandline parameter for configure to 
> disable this feature when creating a new build.

The crashdump knob gave me a basic stack trace, but it wasn't really
enough information to debug the issue.  I ended up having to make the
one-line source change to that page to disable SIGSEGV interception in
order to get a core file and point gdb at that.  Unfortunately, gdb on
FreeBSD gets seems to get confused by thread switching and usually locks
up even before I can trigger the crash.  I only managed to capture the
crash once with gdb running a live process.

For fun, try configuring a build with --enable-debug and
--enable-dbgutil.  Lots of pop-up assertion failure alerts ...


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

Re: java downloader

[Don Lewis]

On 28 Jul, Damjan Jovanovic wrote:
> Yes, that site's certificate is issued by Let's Encrypt, which is only
> supported starting from Oracle Java 8u101 (
> http://stackoverflow.com/questions/34110426/does-java-support-lets-encrypt-certificates).
> AFAIK, OpenJDK doesn't come with any certificates upstream, and they're
> usually supplied by your distribution.
> 
> I've uploaded it to ooo-extras.

Thanks!

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

java downloader

[Don Lewis]

The java downloader chokes on http://curl.haxx.se, which is the location
of the curl source.  This site does a redirect from http to https.  We
currently aren't seeing the problem because we have curl-7.19.7.tar.gz
checked into svn under ext_sources, but it will be a problem once I
upgrade the bundled version of curl. The perl downloader mostly worked
with this site.  It worked on all the platforms that I tried except for
Ubuntu 12. It worked for me on FreeBSD, Windows 7, and CentOS 7.

The problem is a certificate verification error.  I suspect that the
behaviour depends on the installed certificate bundle.

Could someone download curl-7.49.1.tar.gz and upload it to OOO_EXTRAS?
I don't want to break everybody's trunk build when I commit the upgrade
patch.  The md5 hash is 2feb3767b958add6a177c6602ff21e8c.



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

Re: FW: buildbot success in on aoo-win7

[Don Lewis]

On 27 Jul, Damjan Jovanovic wrote:
> 2 successful aoo-win7 builds in a row, so I think it's safe to conclude it
> works now :-).
> 
> The build script still needs a bit of cleaning up, and we need to fix the
> snapshot buildbots. But how? Can we just randomly merge patches to that
> branch?

The build script could spam an updated copy of bootsrap over the one
that was checked out from svn.


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

Re: disabling crash recovery

[Don Lewis]

On 27 Jul, Marcus wrote:
> Am 07/27/2016 08:00 PM, schrieb Don Lewis:
>> Is there any way of disabling the automagic crash recovery?  I'm
>> attempting to debug a crash and the crash recovery / restart seems to be
>> confusing gdb.  Just letting SIGSEGV take its natural course of action
>> would be fine.
> 
> are you looking for this [1]?
> 
> [1] https://wiki.openoffice.org/wiki/Debugging#gdb_invocation

That's definitely helpful.

> If not, then I only know the commandline parameter for configure to 
> disable this feature when creating a new build.

"handle SIGSEGV stop" was sufficient for me to get start zooming in on
the crash.


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

disabling crash recovery

[Don Lewis]

Is there any way of disabling the automagic crash recovery?  I'm
attempting to debug a crash and the crash recovery / restart seems to be
confusing gdb.  Just letting SIGSEGV take its natural course of action
would be fine.


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

Re: updated curl patch

[Don Lewis]

On 24 Jul, Dennis E. Hamilton wrote:
> 
> 
>> -Original Message-----
>> From: Don Lewis [mailto:truck...@apache.org]
>> Sent: Sunday, July 24, 2016 14:51
>> To: dev@openoffice.apache.org; dennis.hamil...@acm.org
>> Subject: Re: updated curl patch
>> 
>> On 24 Jul, Dennis E. Hamilton wrote:


>> > PS: The ext_libraries folder has not been touched since 2014-07-07.
>> > It is included in -src.
>> 
>> Yes, some of the bundled software is built over their rather than under
>> main.  I've never attempted to figure out the logic.
>> 
> [orcmid] 
> 
> I *think* it has to do with (1) IP compatibility (or lack thereof) and
> perhaps (2) whether we are maintaining a patched version that cannot 
> go upstream for some reason.

(1) I don't know, but I know that nss, which is category-b, is built
under main, and apr, which is an Apache project, is built under
ext_libraries.

(2) We've got patches in both places.


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

Re: Buildbots update

[Don Lewis]

On 24 Jul, Andrea Pescetti wrote:
> On 22/07/2016 Don Lewis wrote:
>> On 22 Jul, Damjan Jovanovic wrote:
>>> I've progressed much further
> 
> Thanks Damjan for the (as usual) great progress.
> 
>>> Buildbots
>>> should immediately fail the build if ./bootstrap fails
>> Yes, there is no sense in continuing if bootstrap fails
> 
> Yes, sure.
> 
>>> 5 hours is pure waste. Alternatively we should find a more reliable
>>> ooo-extras hosting solution than SourceForge. We could also cache
>>> dependencies offline between builds, but I am guessing that has licensing
>>> issues?
> 
> No, dependencies we temporarily download on a build machine are not 
> affected by licensing issues.
> 
> Maybe an extra parameter --cache-dir=$DIR to bootstrap would work? This 
> way we could setup a dedicated cache directory on the buildbots (even if 
> we are doing a "clean build", there is really no point in re-downloading 
> a file if the checksum matches).

That's a good idea, though we should probably have another bot that
periodically checks for working downloads.  There's no need for each
buildbot to do it though, which ends up happend now multiple times per
day.


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

Re: Officially releasing a patch for CVE-2016-1513

[Don Lewis]

On 24 Jul, Don Lewis wrote:

> At a minimum, we should publish the hash values of buggy and fixed
> versions of the library.  That might not help someone who builds and
> installs from source since the build not be completely repeatable.
> For instance the library might contain a timestamp.

Adding a static string "CVE-2016-1513 Fixed" to the source is another
possibiliy.  On *nix, the user/administrator can run:
strings whatever.so | grep CVE
and look for the above to verify that the fixed library has been
installed.  Someone would have to figure out how to do the equivalent on
Windows.


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

Re: Officially releasing a patch for CVE-2016-1513

[Don Lewis]

On 24 Jul, Andrea Pescetti wrote:
> While the severity of the security bug we disclosed 
> http://www.openoffice.org/security/cves/CVE-2016-1513.html is not 
> particularly high (it is classified as "Medium" with no known exploits 
> and anti-virus software can detect malicious documents), we should 
> release an update incorporating the -already tested- patch we disclosed 
> in the announcement.
> 
> I assume we will want to keep the effort minimal.
> 
> To do so, an outline would be:
> 
> 1) We commit the patch to the AOO410 branch. This is the branch used for 
> all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our 
> reference version.
> 
> 2) We do not make any other changes to the AOO410 branch. This is really 
> meant to be a minimal update. Even the version number in the source 
> package will remain 4.1.2.
> 
> 3) We tag the release as AOO4121 and build the corresponding source 
> package, which will have 4.1.2.1 in its name (I mean the filename, 
> nowhere else).
> 
> 4) We don't prepare full end-user release binaries but we do supply 
> repaired libraries for power users - remember the circumstances above. 
> The bugfix modifies one library file, and we have binaries ready for 
> several platforms already.
> 
> 5) We vote on the source and possibly binaries. We advertise the 
> availability of the new packages on our website, but we don't send out 
> update notifications and we don't put the files on SourceForge.
> 
> Does this look OK?

Not being able to tell at a glance whether a copy of AOO has been fixed
or not is bad.

A while back Samsung fixed a hard drive firmware bug that could cause
data loss, but didn't change the firmware version number. It was
impossible to discern whether a drive had the buggy or fixed firmware
with smartctl or by looking at boot messages.  I ended up putting
stickers on drives after I updated the firmware, but there was still no
way to survey all the drives to see if they were fixed once they were
installed in boxes.

At a minimum, we should publish the hash values of buggy and fixed
versions of the library.  That might not help someone who builds and
installs from source since the build not be completely repeatable.
For instance the library might contain a timestamp.



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

Re: updated curl patch

[Don Lewis]

On 24 Jul, Dennis E. Hamilton wrote:
> 
> 
>> -Original Message-----
>> From: Don Lewis [mailto:truck...@apache.org]
>> Sent: Sunday, July 24, 2016 12:24
>> To: dev@openoffice.apache.org
>> Subject: updated curl patch
>> 
>> I've updated my curl patch here:
>> <https://bz.apache.org/ooo/show_bug.cgi?id=126896>
>> 
>> I've build tested it on FreeBSD 10, 64-bit CentOS 7, 64-bit Ubuntu 12,
>> and Windows 7.  I've run tested it on CentOS and Windows by doing a
>> File->Open and specifying a ftp:// URL.  I did the same with the
>> FreeBSD port, which uses the same curl version via
>> --with-system-curl.
>> 
>> One of the Linux platforms, Ubuntu as I recall, had problems trying
>> to download the source because of certificate validation issues
>> (hopefully that is fixed with the java download changes).  I noticed
>> that the curl 7.19.7 tarball is checked into svn under ext_sources. 
>> Should I delete that and check in the new source tarball?  What is
>> the criteria for checking stuff in under ext_sources?
> [orcmid] 
> 
> That is an interesting question.  I have the feeling that the
> ext_sources folder is obsolete.
> 
> ANALYSIS
> 
> Looking at ext_sources on trunk, this folder is mainly populated by
> files dated prior to 2012-12-23, none of which were later than the
> first Apache OpenOffice non-incubating release, the AOO 3.4.1 refresh.
>  The only subsequent additions consist of four files added *since*
> release 4.1.2.
> 
> I don't understand the relationship between these and Apache Extras. 
> And that these are binaries on the SVN trunk.

Yes, that seems to be suboptimal.
 
> Furthermore, the ext_sources folder does *not* appear in the source
> release, apache-openoffice-4.1.2-r1709696-src.

True ... anyboody building from a release source tarball is totally
reliant on bootstrap to download all of the extra sources.

> PS: The ext_libraries folder has not been touched since 2014-07-07. 
> It is included in -src.

Yes, some of the bundled software is built over their rather than under
main.  I've never attempted to figure out the logic.

> PPS: Thank you for pointing out, in an earlier post, that you do all
> FreeBSD builds while disconnected from the Internet and don't rely on
> the bootstrap to download anything and that you have what may be a
> more efficient approach that perhaps all of us should use when doing
> release-candidate build-confirmation compiles.

Bootstrap doesn't have much, if anything, to do when building the
FreeBSD port.  All of the necessary external source tarballs have
already been stashed in ext_sources/, and both dmake and epm have
already been built and installed.  The sources come from a giant tarball
that I've previously built and hosted on the FreeBSD infrastructure.
There aren't that many because of the heavy use of --with-system-foo by
the FreeBSD port.

In the general case, the necessary set of sources depends on the flags
passed to configure, and bootstrap looks at the the knobs set by
configure to figure out what to download. If the set of sources was more
dynamic, then the FreeBSD port Makefile would have to duplicate some of
the logic that resides in configure and bootstrap since networking is
turned off before configure is run.


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

updated curl patch

[Don Lewis]

I've updated my curl patch here:


I've build tested it on FreeBSD 10, 64-bit CentOS 7, 64-bit Ubuntu 12,
and Windows 7.  I've run tested it on CentOS and Windows by doing a
File->Open and specifying a ftp:// URL.  I did the same with the FreeBSD
port, which uses the same curl version via --with-system-curl.

One of the Linux platforms, Ubuntu as I recall, had problems trying to
download the source because of certificate validation issues (hopefully
that is fixed with the java download changes).  I noticed that the curl
7.19.7 tarball is checked into svn under ext_sources.  Should I delete
that and check in the new source tarball?  What is the criteria for
checking stuff in under ext_sources?



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

Re: Buildbots update

[Don Lewis]

On 24 Jul, Damjan Jovanovic wrote:
> On Fri, Jul 22, 2016 at 9:39 PM, Don Lewis <truck...@apache.org> wrote:
> 
>> On 22 Jul, Damjan Jovanovic wrote:
>> > I've progressed much further, and openoffice-fbsd-nightly,
>> > openoffice-linux32-nightly, openoffice-linux64-nightly, and
>> > openoffice-linux64-rat are now building, while
>> openoffice-linux32-snapshot
>> > is only temporarily breaking due to SourceForge issues. I've also made
>> some
>> > interesting discoveries about the Windows buildbots.
>>
>> FreeBSD still needs LWP::Protocol::https.  It's only working because of
>> the non-https fallback to a specific SourceForge mirror.
>>
>>
> No, it's only working because of --with-system-

The FreeBSD buildbot uses more --with-system stuff that the other
buildbots, but not as much as the FreeBSD port.  It was still getting
LWP::Protocol::https failures, but they weren't fatal because of the
fallback to a specific http SourceForge mirror.  Most recently it was
only succeeding while the Linux buildbots were failing to download
openssl because thate version wasn't present on the SourceForge mirror
and the FreeBSD buildbot used --with-system-openssl.

BTW, the FreeBSD port doesn't rely on bootstrap to download anything.
Bootstrap is run during the build stage, and when building FreeBSD
packages, there is no network connectivity during the build stage.
Instead, everything is downloaded and stashed in ext_sources before
configure is run.

> Also LWP::Protocol::https is dead now, please see my upcoming email.

Ding, dong, the witch is dead ...

>> > That buildbot is currently running out of disk space, and it doesn't help
>> > that we "svn co" and then "svn export" a second copy. Originally the
>> > buildbot script used other tricks, like "svn switch", or keeping an SVN
>> > checkout across builds that was just updated and then exported from for
>> > each build, but some time ago I switched to a full "svn co" because it
>> was
>> > too unreliable (eg. files can get locked and need "svn cleanup"). With a
>> > full checkout there is no need to export, as we get a fresh copy each
>> time.
>> > I'll overhaul that buildbot script and try make it simpler and cleaner.
>>
>> Doing an update followed by an export of that would be less resource
>> intensive, though it adds 50% (since .svn isn't copied) to the space
>> consumed by the source.  The write-locked file problem should only occur
>> if the update is interrupted, and since there is so little activity in
>> the repo, the updates should be pretty fast have a low probability of
>> failing.  A full checkout would be much more likely to fail in the
>> middle.  You could always run "svn cleanup" before "svn update".
>>
>> A checked out source tree for 4.1.2 is about 725 MB.  A second exported
>> copy would bring the total up to about 1090 MB, which is still fairly
>> small compared to the overall build size.  If space is an issue and load
>> on the svn server is not, then doing a fresh export (vs a checkout) from
>> the server each time would be the best.
>>
>>
> Space was an issue because I was using the small C: drive instead of E:.
> 
> As the buildbots run automatically and we usually don't initiate builds and
> wait for results, little is lost by doing SVN update the slowest way, and
> much is gained through the increased reliability and simplicity.

Doing svn export direct from the repo would be just as reliable as svn
co.  It would be quicker and more spece efficient because it wouldn't
create a second copy of the source under .svn that we don't use since we
aren't doing incremental updates and we are just going to delete at the
start of the next build.

Thanks for spending the time on this!  It'll be awesome having working
buildbots again.

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

Re: Buildbots update

[Don Lewis]

On 22 Jul, Damjan Jovanovic wrote:
> I've progressed much further, and openoffice-fbsd-nightly,
> openoffice-linux32-nightly, openoffice-linux64-nightly, and
> openoffice-linux64-rat are now building, while openoffice-linux32-snapshot
> is only temporarily breaking due to SourceForge issues. I've also made some
> interesting discoveries about the Windows buildbots.

FreeBSD still needs LWP::Protocol::https.  It's only working because of
the non-https fallback to a specific SourceForge mirror.

> I had to revert r1736692 (in r1753709), setting main/extensions.lst back to
> generic https:// SourceForge URLs, as the mirror-specific http:// URLs are
> now broken, which was causing all buildbots that use
> --enable-bundled-dictionaries to fail. Enough buildbots support https now
> to make this a net benefit.

The iweb mirror is out of service, but switching the main SourceForge
URL to pilotfiber (in r1752780) fixed that.

> Also had to upload openssl-0.9.8zg to ooo-extras for the
> openoffice-linux32-snapshot, but the most recent build failed because it
> couldn't download some dictionaries/languages from SourceForge, which I am
> generally finding to be too flaky.
> 
> I think we should either run ./bootstrap multiple times on the buildbots,
> or list SourceForge URLs several times in external_deps.lst and
> extensions.lst, to compensate for SourceForge's unreliability. Buildbots
> should immediately fail the build if ./bootstrap fails, as there is no
> hope: ./bootstrap only downloads dependencies needed for the build, and if
> any are missing, the build will definitely fail, and burning CPU for up to
> 5 hours is pure waste. Alternatively we should find a more reliable
> ooo-extras hosting solution than SourceForge. We could also cache
> dependencies offline between builds, but I am guessing that has licensing
> issues?

Yes, there is no sense in continuing if bootstrap fails.

> That leaves the Windows bots.
> aoo-w7snap is still missing LWP::Protocol::https.
> aoo-win7 was failing to delete the old build files (rm: cannot remove
> `build/ext_libraries/apr/wntmsci12.pro/misc/build/apr-1.4.5/Makefile.win':
> Device or resource busy).
> Something seems to be keeping that file open even after the previous builds
> are over.
> According to ext_libraries/apr/makefile.mk, the BUILD_ACTION on Windows is:
> INCLUDE="$(INCLUDE);./include"  nmake -f Makefile.win buildall
> so I suspected nmake hangs.
> 
> I patched the build script to run "ps -W" (results at
> https://ci.apache.org/builders/aoo-win7/builds/348/steps/ps/logs/stdio)
> which showed 4 nmake processes, 2 from March 30, 2 from April 4, part of
> orphaned trees also containing perl, sh, and dmake.
> Killing nmake (through hacks to the buildbot script, as I still don't have
> remote access) had no effect - deleting apr-1.4.5/Makefile.win was still
> giving the same error.
> Even killing dmake, sh and perl (which had to be done in creative ways on
> that dodgy OS - some through taskkill, some through Cygwin's kill) still
> had no effect.
> After all Cygwin processes were dead, that error was still coming up!
> 
> So I started looking at non-Cygwin processes. DEVENV.EXE and DEVENV.COM had
> the same March 30 / April 4 start times as the hung process trees, and
> killing them *finally* allowed apr-1.4.5/Makefile.win to be deleted.
> 
> I'll experiment a lot more over the weekend, but right now I think the
> problem could be that the buildbot runs VSVARS.BAT to set up the Visual
> Studio environment, which (presumably) contains the evil DEVENV that break
> the build and locks files while hung. On my own Windows VM I don't run
> VSVARS.BAT, and I can't reproduce the problem. Do the rest of you that
> build on Windows use it?

Since VSVARS.BAT was not listed in the step by step guide, I haven't
been running it.  It sounds a lot like it just sets some environment
variables to find where the various bits of VS are installed, so I would
think it would be generally harmless.  I've been running builds from the
desktop.  VSVARS.BAT might be needed when running headless ...

I did some searches and saw some mention that DEVENV.* hangs might be
caused by anti-virus software.  Is that running on the windows buildbot?
 
> That buildbot is currently running out of disk space, and it doesn't help
> that we "svn co" and then "svn export" a second copy. Originally the
> buildbot script used other tricks, like "svn switch", or keeping an SVN
> checkout across builds that was just updated and then exported from for
> each build, but some time ago I switched to a full "svn co" because it was
> too unreliable (eg. files can get locked and need "svn cleanup"). With a
> full checkout there is no need to export, as we get a fresh copy each time.
> I'll overhaul that buildbot script and try make it simpler and cleaner.

Doing an update followed by an export of that would be less resource
intensive, though it adds 50% (since .svn isn't copied) to the space
consumed by the source.  The 

openoffice-linux64-nightly

[Don Lewis]

I'm not openoffice-linux64-nightly fail in bootstrap due to
LWP::Protocol::https being missing.  I think it was before.

There is a MD5 checksum mismatch in commons-lang3-3.3-src.tar.gz.

The openssl download fails, but the error is "500 Can't connect to
www.openssl.org:443", so it looks like the http -> https redirect is
working.

There are also a bunch of connection failures to archive.apache.org port
80.


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

Re: updated nss upgrade patch

[Don Lewis]

On 15 Jun, Kay Schenk wrote:
> 
> 
> On 06/15/2016 02:12 AM, Don Lewis wrote:
>> The latest version of nss is now up to 3.24.  I've updated the patch
>> here <https://bz.apache.org/ooo/show_bug.cgi?id=126891> to update the
>> bundled nss to that version.  I also fixed a build problem on Windows.
>>
>> Because the download URL is
>> https://ftp.mozilla.org/pub/security/nss/releases/... and because the
>> buildbots choke on https URLs, the new tarball will need to be uploaded
>> to http://sourceforge.net/projects/oooextras.mirror/files/ so the
>> buildbots don't get totally broken.
> 
> OK.
> 
> For testing, I *think* what I've done in the past is to download the new 
> pack, prepend the MD5 cheksum to it seperated by a dash as is our usual 
> format, and just put it /ext_sources. Once the name is changed in 
> /main/external_deps.lst via your patch, I think this will work for 
> testing for now.

I didn't have any problem having bootstrap download it since I have the
LWP::Protocol::https perl module installed.  Unfortunately the buildbots
still don't.  Because of that, they'll fail the first download attempt
and then try OOO_EXTRAS as a fallback.  That will also fail because the
new version of the tarball isn't there.



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

updated nss upgrade patch

[Don Lewis]

The latest version of nss is now up to 3.24.  I've updated the patch
here  to update the
bundled nss to that version.  I also fixed a build problem on Windows.

Because the download URL is
https://ftp.mozilla.org/pub/security/nss/releases/... and because the
buildbots choke on https URLs, the new tarball will need to be uploaded
to http://sourceforge.net/projects/oooextras.mirror/files/ so the
buildbots don't get totally broken.

If you want to test this, you'll need to use the --enable-category-b
configure flag to enable building nss.

I've got a bunch of test builds in progress and the results look good so
far, but the builds will not be done until tomorrow.


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

Re: [QUESTION] Dependency on OpenSSL

[Don Lewis]

On  8 Jun, Dennis E. Hamilton wrote:
> I recall discussions of OpenSSL and updating our dependency on it to a 
> better/patched version.
> 
> What I don't know is whether the binaries that are built and distributed 
> directly by the project incorporate OpenSSL in any manner?
> 
> Can anyone clear that up?
> 
>  1. Do our built binaries depend on and distribute OpenSSL in some manner?

Yes.

>  2. Is this for all platforms or only some of them?

It appears that all do.  That makes sense since Windows doesn't have it,
and on Linux you don't know what version will be present on the host
where the binaries are installed (and the OpenSSL ABI changes between
major release versions).

The FreeBSD port uses the system OpenSSL.  It passes
--with-system-openssl to configure.  This works for FreeBSD because
different binary packages are generated for each FreeBSD major version,
and within a FreeBSD major version the OpenSSL ABI does not change.

The lastest OpenSSL should just drop in.  I haven't seen any problems
building on FreeBSD with the latest and greatest.



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

LWP::Protocol::https

[Don Lewis]

I realize we've implemented a workaround to get the buildbots back to a
mostly functional state, but the requirement for LWP::Protocol::https
is not documented either here:
  
or here:
  



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

Re: aoo 4.2 dev: .\bootstrap fails with failed (501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed))

[Don Lewis]

On  1 Apr, Oliver Brinzing wrote:
> Hi,
> 
> i try to build aoo 4.2 dev on win7, but i can not download the external 
> sources.
> 
> any hints?
> Oliver
> 
> downloading 22 missing tar balls to C:/build_tmp/aoo_src/ext_sources
> downloading to 
> C:/build_tmp/aoo_src/ext_sources/2d6ec8ccdf5c46b05ba54a9fd1d130d7-gtest-1.7.0.zip.part
> MD5 checksum is OK
> downloading to 
> C:/build_tmp/aoo_src/ext_sources/0dd138efff4412c707e239290fb82d4f-mdds_0.3.1.tar.bz2.part
> MD5 checksum is OK
> downloading to 
> C:/build_tmp/aoo_src/ext_sources/2ab442d169156f34c379c968f3f482dd-zlib-1.2.7.tar.bz2.part
> download from 
> http://sourceforge.net/projects/oooextras.mirror/files/2ab442d169156f34c379c968f3f482dd-zlib-1.2.7.tar.bz2
>  
> failed (501 Protocol scheme 'https' is not supported (LWP::Protocol::https 
> not installed))
>  download failed

You need to install the LWP::Protocol::https perl module.


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

upgrading serf

[Don Lewis]

I was just looking at what it would take to upgrade our bundled version
of serf.  It turns out to be a bit complicated because recent versions
of serf uses scons to build.


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

Re: Release Manager for 4.2.0?

[Don Lewis]

On 28 Mar, Kay Schenk wrote:
> 
> 
> On 03/27/2016 03:37 PM, Don Lewis wrote:
>> On 27 Mar, Andrea Pescetti wrote:
>>> On 29/01/2016 Andrea Pescetti wrote:
>>>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>>>> Release Manager for 4.2.0 since I'm finding that in this period I can
>>>> help more productively with tasks that do not require constant
>>>> interaction ...
>>>> I am surely available to have a significant role in the 4.2.0 release
>>>
>>> A few days after writing this, almost 2 months ago, sudden events left 
>>> me incapacitated to make any significant contributions until very 
>>> recently. I'm still unable to make long-term commitments.
>>>
>>> Anyway, there are some issues we need to get done as a team before 
>>> appointing a release manager makes sense:
>>>
>>> 1) Enough code. Done. The merge of the recent gbuild work totally 
>>> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny 
>>> fraction of the fixes that (at that time) were available on trunk. So 
>>> here we are already OK, and we've been OK for months.
>> 
>> Some of the external software that is bundled has security issues.  I
>> put together a patch for nss here:
>> <https://bz.apache.org/ooo/show_bug.cgi?id=126891>.
>> 
>> The version of libxml currently bundled also has a lot of known
>> vulnerabilities.  I'm currently testing a patch.
>> 
>> These both need review and testing.
> 
> Ok, I'll keep my eyes open for the libxml patch and test
> with your already supplied nss patch.

I filed a PR with the libxml patch late yesterday:
<https://bz.apache.org/ooo/show_bug.cgi?id=126893>

As an added bonus, here is the curl patch:
<https://bz.apache.org/ooo/show_bug.cgi?id=126896>


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

Re: Release Manager for 4.2.0?

[Don Lewis]

On 28 Mar, Dennis E. Hamilton wrote:
> Commenting just on document signing ...
> 
>> -Original Message-
>> From: Pedro Giffuni [mailto:p...@apache.org]
>> Sent: Monday, March 28, 2016 13:48
>> To: OOo Apache 
>> Subject: Re: Release Manager for 4.2.0?
> [ ... ]
>> 
>> [ ... ] I am unsure about what in OpenOffice
>> uses the new cyphers. I think OpenSSL is used for signing documents:
>> when we update OpenSSL will AOO automatically accept more signing
>> options? I would expect browsers will bring their own SSL
>> implementations.
> [orcmid] 
> 
> The document signature support in Apache OpenOffice is based on XML
> Digital Signatures Second Edition,
> . This has
> nothing to do with communications via secure sockets of course. 
> Granted that OpenSSL provides library functions for more than that,
> there is still very limited use for signing documents.
> 
> X.509 digital certificates are employed.  XadES extensions may be used
> (impacting metadata information mainly and only implemented by
> Microsoft in ODF as far as I know).  Depending on the platform the
> operating-system secure store for the signing key will usually be
> employed, so there is operating-system integration.  (This is
> definitely true for Windows.)

OpenSSL also provides libcrypto which contains functions for creating,
validating, and using certificates.  It uses some of this functionality
to verify that a secure socket connection is actually connected to the
desired remote endpoint.  I've used to the openssl command line tool to
produce a certificate that was used to authenticate a connection from a
local application to a remote service.

There seems to be a standard place to store certificates under a user's
home directory in the *nix world.  A while back I signed up for a
service that requires updates from me to be signed with a certificate
that they created for me and that my browser downloaded and stashed away
somewhere.  When I tried signing a document with OpenOffice, it found
this certificate and offered it as a choice for signing.

Since OpenOffice also uses curl, which is used for downloading files,
and curl uses OpenSSL, it looks like OpenOffice depends on OpenSSL for
secure downloads.  I don't know if it downloads anything other than
extensions and updates.





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

Re: Release Manager for 4.2.0?

[Don Lewis]

On 28 Mar, Pedro Giffuni wrote:
> Hi Don;
> 
>> On 28 Mar, Pedro Giffuni wrote:
>> > In reply to Don,
>>
>> >> The versions of openssl and curl badly need updating for the same
>> >> reason, and there is one CVE for serf.
>> >
>> > FreeBSD casually keeps some backported updates for the same openssl
>> > version AOO uses:
>> >
>> > https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
>> >
>> > It should be pretty straightforward to take them from there and use 
>> them
>> > into
>> > main/openssl with minor adaptions.
>>
>> That would fix only part of the problem.  The other part of the problem
>> is that the version of openssl that we currently bundle doesn't
>> implement the newer and more secure protocols and ciphers.  The older
>> and less secure ones are gradually getting disabled on the server side.
>>
>> For instance, my only copy of Windows is XP, and the last version of IE
>> released for XP can no longer connect to some web sites because they
>> have disabled all of the protocols that IE supports.
>>
> 
> That is a valid concern, however I am unsure about what in OpenOffice
> uses the new cyphers. I think OpenSSL is used for signing documents:
> when we update OpenSSL will AOO automatically accept more signing
> options? I would expect browsers will bring their own SSL
> implementations.

I don't know what OpenOffice uses it for, either, but I would expect
that it also gets used for downloading extensions.  I hadn't even
thought about signatures.  That's something I haven't exercised it at
all.

> TBH, when I updated OpenSSL in AOO, I intentionally didn't upgrade it
> further because the newer versions have more code but also more
> vulnerabilities, therefore the expected maintenance cost would be
> higher.  The FreeBSD 9.x updates are only a temporary workaround.
> Now that upstream is not maintaining the older 0.9.8 version
> it probably makes sense to reconsider upgrading.

And using FreeBSD 9.x as a patch source will not work past the end of
this year because of the FreeBSD 9 EOL.

The FreeBSD OpenOffice port uses --with-system-openssl, and when I build
it for my own use, I set WITH_OPENSSL_PORT=yes, so I am always using the
latest and greatest openssl release.  I haven't run into any problems
with it.  I just signed a document with it ;-)



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

Re: Release Manager for 4.2.0?

[Don Lewis]

On 28 Mar, Pedro Giffuni wrote:
> In reply to Don,

>> The versions of openssl and curl badly need updating for the same
>> reason, and there is one CVE for serf.
> 
> FreeBSD casually keeps some backported updates for the same openssl 
> version AOO uses:
> 
> https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
> 
> It should be pretty straightforward to take them from there and use them 
> into
> main/openssl with minor adaptions.

That would fix only part of the problem.  The other part of the problem
is that the version of openssl that we currently bundle doesn't
implement the newer and more secure protocols and ciphers.  The older
and less secure ones are gradually getting disabled on the server side.

For instance, my only copy of Windows is XP, and the last version of IE
released for XP can no longer connect to some web sites because they
have disabled all of the protocols that IE supports.


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

Re: Next release and gbuild

[Don Lewis]

On 17 Mar, Pedro Giffuni wrote:
> 
> 
> On 03/15/16 13:46, Pedro Giffuni wrote:
>> Hello;
>>
>> I have been noticing damjan's great advance in merging the gbuild stuff.
>>
> 
> It would be rather interesting to compare the buildworld timing.
> 
> Is it faster to build with gbuild? Perhaps the buildbot may give us a 
> hint but we may not know exactly as I think gbuild adds some more tests 
> (not sure).
> 
> The FreeBSD buildbot continues stuck when fetching tarballs, BTW :(.

As are the linux32 and win7 buildbots.  All three need to have
LWP::Protocol::https installed.


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

Re: Boost-related build warnings

[Don Lewis]

On 24 Mar, Kay Schenk wrote:
> 
> 
> On 03/24/2016 03:09 PM, Don Lewis wrote:
>> On 22 Mar, Kay Schenk wrote:
>>>
>>> On 03/21/2016 06:14 PM, Don Lewis wrote:
>>>> When building OpenOffice with recent versions of clang, an extreme
>>>> number of very verbose warnings are generated by the Boost headers,
>>>> which basically doubles the size of the build log.
>>>>
>>>> For the FreeBSD port, which uses the system Boost (still 1.55 for now),
>>>> I fixed this by cherry picking a number of commits from more recent
>>>> versions of Boost and and adding them as patches to the Boost port.
>>>> This greatly reduces the noise level.
>>>
>>> I like this approach as we already have a patch file for
>>> boost_1.55 in our source tree...
>>>
>>> /main/boost/boost_1_55_0.patch
>>>
>>> I would favor adding more boost patches to this existing
>>> patch file and submitting through BZ so we could test on
>>> additional platforms before permanently committing.
>> 
>> Ok, here it is: <https://bz.apache.org/ooo/show_bug.cgi?id=126888>
> 
> Super! This will give us non-BSD folks a chance to test out
> in more detail.

We haven't had any problems with gcc 4.8 on FreeBSD 9.3.  I suspect Mac
will be OK.  My biggest concern is Windows.


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

Re: Boost-related build warnings

[Don Lewis]

On 22 Mar, Kay Schenk wrote:
> 
> On 03/21/2016 06:14 PM, Don Lewis wrote:
>> When building OpenOffice with recent versions of clang, an extreme
>> number of very verbose warnings are generated by the Boost headers,
>> which basically doubles the size of the build log.
>> 
>> For the FreeBSD port, which uses the system Boost (still 1.55 for now),
>> I fixed this by cherry picking a number of commits from more recent
>> versions of Boost and and adding them as patches to the Boost port.
>> This greatly reduces the noise level.
> 
> I like this approach as we already have a patch file for
> boost_1.55 in our source tree...
> 
> /main/boost/boost_1_55_0.patch
> 
> I would favor adding more boost patches to this existing
> patch file and submitting through BZ so we could test on
> additional platforms before permanently committing.

Ok, here it is: <https://bz.apache.org/ooo/show_bug.cgi?id=126888>

>> 
>> To fix this when building with the bundled Boost, we could import these
>> same patches.  Another possibility is to upgrade bundled Boost to 1.60,
>> which contains these fixes as well as a fixes for most (or all) of the
>> other problems that we currently patch.  The only problem that I've run
>> into when building OpenOffice trunk with Boost 1.60 was with the PDF
>> Import plugin, and I commited a fix for that in r1735889.
>> 
>> Thoughts?
> 
> I remember trying to use boost 1.56 from my system once upon
> a time and ran into all kinds of problems. I've been leary
> about using a newer version of boost ever since. In general,
> I'm not opposed to an upgrade like this but we would need
> more extensive testing with our distributed platforms first.
> And, that could take *a while*.

I've been involved in updating the FreeBSD boost port from 1.55 to 1.60.
I think it broke about 44 of 300 ports that use boost.  I didn't run
into any issues with OpenOffice 4.1.2 and only one build problem with
OpenOffice 4.2.0, and that was in the PDF import plugin, which the
official Apache OpenOffice builds will not enable.  I've already
committed a fix for that problem and I now get clean builds with 1.60.


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

Boost-related build warnings

[Don Lewis]

When building OpenOffice with recent versions of clang, an extreme
number of very verbose warnings are generated by the Boost headers,
which basically doubles the size of the build log.

For the FreeBSD port, which uses the system Boost (still 1.55 for now),
I fixed this by cherry picking a number of commits from more recent
versions of Boost and and adding them as patches to the Boost port.
This greatly reduces the noise level.

To fix this when building with the bundled Boost, we could import these
same patches.  Another possibility is to upgrade bundled Boost to 1.60,
which contains these fixes as well as a fixes for most (or all) of the
other problems that we currently patch.  The only problem that I've run
into when building OpenOffice trunk with Boost 1.60 was with the PDF
Import plugin, and I commited a fix for that in r1735889.

Thoughts?



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

Re: [RISKS?] Dependability Issues with the AOO Code?

[Don Lewis]

On  1 Mar, Dennis E. Hamilton wrote:
> [BCC AOO PMC]
> 
> An interesting link came to my attention today:
> .
> 
> The analysis did not use the Apache OpenOffice code base.  Because of
> common heritage from OpenOffice.org code, I expect most of the
> analysis to be applicable.
> 
> The conclusion might not be so favorable in our case, absent a
> systematic approach to AOO maintenance, especially around
> dependability problems.

Modern compilers warn about a lot of questionable code.  Unfortunately
our build logs are currently so full of warnings from modern compilers,
I think it it easy for this signal to be obscured by the noise.  That is
something that I'm interested in tackling.


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

Re: Next release and gbuild

[Don Lewis]

On 17 Mar, Damjan Jovanovic wrote:
> On Tue, Mar 15, 2016 at 8:46 PM, Pedro Giffuni  wrote:
>> Hello;
>>
>> I have been noticing damjan's great advance in merging the gbuild stuff.
>>
>> IMO, this is a great thing that will likely be unnoticed by our users
>> as it has no real effect on the binaries but it is significant in improving
>> the build experience.
>>
>> Now, it appears the only thing holding a new release is a lack of
>> leadership within the community. Either someone steps in or we just have a
>> team of people do things. In any case I think a gbuild merge
>> forces to take some consideration.
>>
>> Given the changes will be big, if we want a new release code soonish,
>> we should branch AOO42 before the merge, avoiding any potential risk.
>> If we are still taking longer, say 1-2 months, then we have ample time to
>> sort out any eventual issue and we shouldn't worry about it.
>>
>> Of course we can merge gbuild and then fork from a past point anytime,
>> but now is a good time to decide about releases.
> 
> All the gbuild branch patches have now been ported to the
> gbuild-integration branch. Please don't start testing yet: let me fix
> the sd inconsistencies, do a RAT scan and investigate any wrongly
> licensed files, compare bvt and fvt qa test results with trunk, and
> check for other obvious bugs before we start testing other platforms.
> 
>> Thinking about gbuild and what follows ...
>>
>> First of all congratulation to Damjan, this is very cool.
> 
> Thank you, and can the rest of you please make similar contributions ;-) ?
> 
>> From my perspective, it's OK to depend on two or more build tools (we
>> do use ant, etc) as long as one of them is not DMake, so if we want
>> to use scons, I am fine with it but we will have to move Python to
>> gbuild. Things are looking fun ;).
>>
> 
> A lot of my initial enthusiasm about SCons faded after I saw it had
> problems with MSVC on Cygwin, the authors themselves admitted SCons is
> slow for large projects, and the KDE project tried using it for about
> a year and then gave up and moved to something else (CMake?).
> 
> I am not sure gbuild has the ability to run configure+make yet the way
> dmake does.
> 
> In the short term I plan some more improvements to gbuild, like fixing
> --enable-symbols to do the same thing on dmake and gbuild modules.

Have you added $(CCNUMVER) on the gbuild side?  I've been using that on
the dmake side to tweak optimization settings on individual files on
specific compiler version and architecture combinations.  There is one
particular compiler bug that affects files on both of the gbuild and
dmake sides.  In the FreeBSD port I have to detect the compiler version
and do a global optimization change because I can't do a fine-grained
tweak on the gbuild side.

It might make sense for configure to figure out CCNUMVER and just pass
it in as another environment variable.


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

Re: New Committer: Don Lewis (truckman)

[Don Lewis]

On 13 Dec, Dennis E. Hamilton wrote:
> [BCC AOO PMC]
> 
> The Project Management Committee (PMC) for Apache OpenOffice is pleased to
> announced that Don Lewis has accepted and taken the ID truckman.
> 
> A warm welcome to Don Lewis.
> 
> Regards,
> 
>  Dennis Hamilton, on behalf of the Apache OpenOffice PMC

Thanks!

By way of introduction, I've been working with various flavors of Unix
since the early 1980's.  I started working with open source software in
the mid to late 1980's and contributed code to BIND, INN, and trn, as
well as a few other odds and ends.  I started using FreeBSD in the early
1990's, became a src committer in 1998, and got my ports commit bit
early last year. I made my first contribution to the FreeBSD openoffice
port in 2003 and picked up the pace in 2012.

In terms of contributing to OpenOffice, my interests are upstreaming
patches from the FreeBSD port as appropriate, fixing bugs, and general
housekeeping.


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

Re: AOO debugging on FreeBSD

[Don Lewis]

On 18 Feb, Damjan Jovanovic wrote:
> Hi
> 
> On FreeBSD, when I try debug dmake modules in AOO with gdb, and use
> the "break :" command, I have to specify the filename
> only, without a path, otherwise it can't find it. On Linux it always
> finds the file, whether an absolute path, relative path, or filename
> only is used. Eclipse CDT's integrated debugger fails to set
> breakpoints because of this, making it useless.
> 
> On the other hand, gbuild modules with the patch at the end of my mail
> (and --enable-symbols to ./configure) work just fine using absolute
> path and relative path. However patching dmake to use similar debug
> options to gbuild didn't help:
> 
> Index: main/solenv/inc/unxfbsd.mk
> ===
> --- main/solenv/inc/unxfbsd.mk(revision 1730773)
> +++ main/solenv/inc/unxfbsd.mk(working copy)
> @@ -86,7 +86,7 @@
>  .IF "$(ENABLE_SYMBOLS)"=="SMALL"
>  CFLAGSENABLESYMBOLS=-g1
>  .ELSE
> -CFLAGSENABLESYMBOLS=-g # was temporarily commented out, reenabled before Beta
> +CFLAGSENABLESYMBOLS=-ggdb3 # was temporarily commented out, reenabled
> before Beta
> 
>  .ENDIF
> 
> 
> Is there known issues debugging clang's binaries with gdb? Any ideas?

I'm pretty sure that gdb from ports should be used instead of the base
gdb.


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

Re: Security issues with silgraphite

[Don Lewis]

On 17 Feb, Andrea Pescetti wrote:
> Pedro Giffuni wrote:
>> I looked briefly at the issues and for good or bad the version of
>> silgraphite shipping with OpenOffice is old enough that most of the
>> vulnerabilities don't apply (at least not directly).
> 
> Thank you for setting things straight. We do use silgrahpite, but not 
> the version that is confirmed to be vulnerable.
> 
> Indeed the article you linked to does not say that OpenOffice is 
> vulnerable. It says that OpenOffice uses silgraphite (correct) and that 
> Firefox used to be vulnerable (since Firefox was using the silgraphite 
> version that is confirmed to be vulnerable).
> 
>> 1) We could update silgraphite to their latest version (at least on
>> header has disappeared so this needs tweaking).
>> 2) We could patch the older silgraphite to provide some protection
>> from vulnerabilities.
> 
> I would definitely go for option 1 but indeed they broke compatibility. 
> I don't know how complex it is to update code, but it is a good moment 
> for doing so.

Option 1 would be my preference, but it looks non-trivial.

>> Independent of (1) or (2) I think it's likely we may want to stop
>> shipping libgraphite.
> 
> I don't think this is the best solution, see below.
> 
>> One one side the support from SIL for this
>> event has been unacceptable: AFAICT there was no advance notice
> 
> I confirm OpenOffice received no information in advance; on the other 
> side, the vulnerability as such does not apply to the version we use. So 
> maybe we didn't receive a notification since there was nothing to fix.
> 
>> On the other hand graphite is not very important
>> nowadays: Adobe donated a fine CFF rasterizer to the freetype
>> project which fills the hole graphite meant to cover.
> 
> We do have a niche (at least I think it's a niche) of users who love 
> Graphite-enabled fonts. So this might need some longer evaluation, at 
> least to understand if these users would be damaged. This is why I would 
> prefer to use option 1 for 4.2.0 and (unless they broke compatibility 
> too much) go for the update. Of course, if this turns out to be too 
> complex or risky, deprecating silgrahpite is an option too.

After looking at the code, it appears that the version of silgraphite
that we are using is subject to one of the four vulnerabilities
mentioned: .

The patch below is similar to the upstream graphite2 fix and I
believe it closes the hole.  I've tested it with the GentiumPlus font
and it didn't break anything obvious.

One concern that I have is that silgraphite has been deprecated upstream
and its last release was in February 2009, so there may be quite a few
old bugs lurking there.

--- engine/src/font/TtfUtil.cpp.orig2009-01-29 08:33:19 UTC
+++ engine/src/font/TtfUtil.cpp
@@ -1106,7 +1106,7 @@ size_t LocaLookup(gr::gid16 nGlyphId, 
// CheckTable verifies the index_to_loc_format is valid
if (read(pTable->index_to_loc_format) == 
Sfnt::FontHeader::ShortIndexLocFormat)
{ // loca entries are two bytes and have been divided by two
-   if (nGlyphId <= (lLocaSize >> 1) - 1) // allow sentinel value 
to be accessed
+   if (lLocaSize >= 2 && nGlyphId <= (lLocaSize >> 1) - 1) // 
allow sentinel value to be accessed
{
const uint16 * pTable = reinterpret_cast(pLoca);
return (read(pTable[nGlyphId]) << 1);
@@ -1115,7 +1115,7 @@ size_t LocaLookup(gr::gid16 nGlyphId, 

if (read(pTable->index_to_loc_format) == 
Sfnt::FontHeader::LongIndexLocFormat)
{ // loca entries are four bytes
-   if (nGlyphId <= (lLocaSize >> 2) - 1)
+   if (lLocaSize >= 4 && nGlyphId <= (lLocaSize >> 2) - 1)
{
const uint32 * pTable = reinterpret_cast(pLoca);
return read(pTable[nGlyphId]);


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

Re: OpenJDK8

[Don Lewis]

On 17 Oct, Don Lewis wrote:
> On 18 Oct, Andrea Pescetti wrote:
>> On 17/10/2015 Don Lewis wrote:
>>>> FreeBSD's ports builds, which include the latest release candidate,
>>>> were now marked broken with OpenJDK8.
>>> The AOO410 branch needs r1697228, r1697237, r1697247, r1697306, and
>>> r1697312 from trunk (which are sequential commits with no unrelated
>>> commits between the first and last).
>> 
>> Are all of these FreeBSD specific? We are not going to merge a lot of 
>> patches now that we are in the final QA phase. If you want to work on 
>> this discuss on Bugzilla (just open an issue and CC me, pescetti), but 
>> I'm willing to take a look only because building on FreeBSD is a 
>> "Release Blocker". And if anything is too risky for a proper 
>> integration, or if it may affect other systems, I'd rather not port it 
>> at this stage.
> 
> This is not FreeBSD specific.  I think it would affect anyone attempting
> to build with OpenJDK8.  Has anyone tried this on other platforms?  With
> two exceptions that I noticed, all of the changes seem to be to javadoc
> comments, which openjdk8 seems to be pickier about.
> 
> Could it be that the javadoc stuff is optional?  For some reason, the
> FreeBSD port builds and uses epm to package the SDK (which the port
> ignores when building FreeBSD packages), but the buildbot-style builds
> I've done do not. Figuring out why the port is building the SDK is on my
> TODO list.

I dug into this and found that at least the FreeBSD buildbot uses
the--disable-odk configure option, while the FreeBSD port does not use
this option.  That means that the FreeBSD port unnecessarily builds the
SDK even though it is not included in the binary FreeBSD OpenOffice
package.

When I added this configure option to the FreeBSD port (disabling the
SDK build), I was able to successfully build OpenOffice with OpenJDK8.
The only issue with OpenJDK8 seems to be building the SDK, though I
believe this will affect all platforms.
 
> I am testing a patch for the FreeBSD port, so I should be able to commit
> that and unbreak the port for OpenJDK8 in the next day.

I added this patch to the FreeBSD port and committed it yesterday, so
the SDK is now buildable on FreeBSD with OpenJDK8.


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

Re: OpenJDK8

[Don Lewis]

On 17 Oct, Pedro Giffuni wrote:
> FWIW ...
> 
> FreeBSD's ports builds, which include the latest release candidate,
> were now marked broken with OpenJDK8.
> 
> I don't have more details.

The AOO410 branch needs r1697228, r1697237, r1697247, r1697306, and
r1697312 from trunk (which are sequential commits with no unrelated
commits between the first and last).  Unfortunately there are likely to
be some merge conflicts because of the spelling correction changes in
trunk were not merged.

I'm currently testing a patch for the FreeBSD port.


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

Re: building problems with recent changes -- /sal/qa/osl module

[Don Lewis]

On 10 Oct, Damjan Jovanovic wrote:
> The FreeBSD buildbot and 1 Linux buildbot have also been getting this, yet
> 2 of us now couldn't reproduce it.
> 
> Please provide:
> * SVN revision
> * full configure options
> * the compile log from earlier on (containing the command run that produces
> that error)
> 
> Thank you
> Damjan
> 
> 
> On Fri, Oct 9, 2015 at 11:07 PM, Kay Schenk  wrote:
> 
>> Hello --
>>
>> Currently, I am having problems building due to some recent changes in
>> sal/qa/osl/
>>
>>
>> sal/qa/osl/thread/test_thread.cxx seems to be successfully compiled but on
>> making qa_osl_thread, I am getting the following errors --
>>
>> /usr/bin/ld: cannot find -lsalcpprt
>> collect2: ld returned 1 exit status
>> dmake:  Error code 1, while making '../../../
>> unxlngi6.pro/bin/qa_osl_thread'
>>
>> Any help appreciated.


The FreeBSD buildbot seems to be happy now.

I wonder if this an out of order build problem.  In my last build I
see that the sal_ut_osl_pipe, sal_ut_osl_condition, and sal_ut_test
tests are all successfully run before the qa_osl_thread test, and all of
them use -lsalcpprt.  If I'm intepreting man/sal/prj/build.lst
correctly, the first three of those are all specifying sa_cpprt.u as a
dependency:

sa sal\qa\osl\pipe nmake - all sa_qa_osl_pipe sa_util  sa_cpprt.u NULL
sa sal\qa\osl\condition nmake - all sa_qa_osl_condition sa_util sa_cpprt.u NULL
sa sal\qa\sal nmake - all sa_qa_sal sa_util  sa_cpprt.u NULL

whereas qa_osl_thread does not:
sa sal\qa\osl\thread nmake - all sa_qa_osl_thread sa_util NULL

I wonder if the failing builds are trying to run the thread test before
the libsalcpprt has been built?


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

sporadic sdext build failures

[Don Lewis]

I've occasionally seen the sdext module fail to build:

Making:minimizer.srs
: && 
LD_LIBRARY_PATH=/tmp/openoffice/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
  /tmp/openoffice/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/rsc -presponse 
-verbose @/tmp/mkZY5FmB
/usr/local/bin/bash: 
/tmp/openoffice/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/rsc: No such file or 
directory
dmake:  Error code 127, while making '../../unxfbsdx.pro/srs/minimizer.srs'

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


The latest FreeBSD buildbot run seems to have encountered this as well:



When running single-threaded builds, I've noticed that the order that
the modules are built seems to be kind of non-deterministic.  I'm
guessing that this is a property of build.pl.   In that case the failure
could be the result of a missing dependency specification, and sometimes
the ordering is such that it triggers a build failure.  Interestingly, I
don't believe I've ever seen this failure in a parallel build.

The build system is pretty mysterious to me, but my best guess is that
adding "rsc" to the first line of main/sdext/prj/build.lst will fix the
problem.

dx  sdext   :   L10N:l10n offuh comphelper unotools readlicense_oo 
cpputools cppuhelper sal javaunohelper officecfg LIBXSLT:libxslt xmlhelp NULL




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

Re: Merging some FreeBSD changes to AOO410 (was Re: AOO build system upgrades)

[Don Lewis]

Using the FreeBSD ports framework, I am able to successfully build
AOO410 branch revision r1705179 on FreeBSD 9.3, 10.1, and 11.0-CURRENT,
on both i386 and amd64.  The only required patch is a tweak to the
optimization flags to avoid a bug in clang 3.6 on i386.  I use exactly
the same patch when building trunk.  Unfortunately this can't be easily
fixed in the source because $(CCNUMVER) isn't available in gbuild.

If I merge r1690992, r1701276, and r1701344, I can successfully do a
buildbot-style build on FreeBSD 10.1 if I install the coinmp package and
pass --with-system-coinmp to configure.  The set of merges to fix the
coinmp build on FreeBSD are not directly mergeable because trunk is
using CoinMP 1.7.6, but AOO410 is still using 1.6.0.  Even if I manually
fix the problem originally encountered in the trunk build, I run into
other build failures.


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

Re: Merging some FreeBSD changes to AOO410 (was Re: AOO build system upgrades)

[Don Lewis]

On 24 Sep, Pedro Giffuni wrote:
> Hi Andrea;
> 
> It did catch me somewhat off-guard that the release is not branched from
> trunk. It basically means that some changes that have been in the tree
> for over a year won't be included into the next release.
> 
> I don't really want to spend time merging changes to the 410 branch, but 
> I will be merging the basic build fixes for FreeBSD/clang.
> 
> I am still determining exactly what should be merged but it will
> only affect FreeBSD build (bridges and makefiles) and are made to 
> diminish the maintenance costs for downstream FreeBSD (Hi Don!).

I've been meaning to bring up this subject since my name is mentioned in
the Buildbots category here:
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.2

I am able to build a version of the FreeBSD port fromt the AOO410
branch, but it requires a fairly extensive set of patches.


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

Re: build breaker/Issue 126449/ svx module

[Don Lewis]

On 30 Aug, To: dev@openoffice.apache.org wrote:
> On 29 Aug, Don Lewis wrote:
>> On 14 Aug, Andrea Pescetti wrote:

>>> Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475 
>>> (where a patch by Ariel is available, but operates at a C++ code level 
>>> and not at a Makefile level)?
>> 
>> Yes.  Early on I saw the LibreOffice folks do something similar, but I
>> was not able to get that to work reliably and switched to -O0
>> optmization for a long time.  My workaround above is fairly recent.

> There are some hooks in the build specific files with optimization
> disabled, so adding the above two files to that list is one possible
> fix, though I don't know if that hook is present in both parts of the
> build framework, but it looks like it is.

I attached another patch to
https://bz.apache.org/ooo/show_bug.cgi?id=125475 that disables
optimization of the troublesome files.  In one case the compiler version
information is available, so I only disable optimization for gcc 4.9.
Optimization of the other file is always disabled when compiling with
any version of gcc.

 

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

Re: build breaker/Issue 126449/ svx module

[Don Lewis]

On 29 Aug, Don Lewis wrote:
 On 14 Aug, Andrea Pescetti wrote:
 On 09/08/2015 Don Lewis wrote:
 Looks like you are compiling with gcc 4.9.  I ran into this same problem
 on FreeBSD and worked around it by changing the -Os optimization flag
 ... This is a gcc bug, see:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009
 
 This looks like very valuable information (I never saw this, but I build 
 with gcc 4.8.x most of the times). Could you expand on it a bit?
 
 It apparently is an optimizer bug in gcc 4.9 that has been fixed in gcc
 5 and was not present in 4.8.  It is sometimes triggered by inline
 virtual class methods.  I believe it only happens with -Os optimization.
 The workaround is to either disable optimization by using
 -O0, or disabling the problematic optimization step by using
 -fno-devirtualize -fno-devirtualize-speculatively, which I figured out
 based on comment #2 in the gcc bug report.  I didn't attempt to figure
 out if only one of the flags would be sufficient.
 
 Do I understand correctly from the above issue than anybody building 
 OpenOffice (I'm obviously particularly interested in the coming 4.1.2) 
 with GCC 4.9.0 to 4.9.3 (and possibly later 4.9.x releases, since the 
 issue is not fixed yet in 4.9.x) will have to manually edit their makefiles?
 
 Yes.
 
 If this is true, would you recommend that we either detect it at 
 configuration time, or modify the makefiles, or anything else?
 
 It would be nice to detect it at configuration time, but configure
 doesn't really look at the compiler version.  One half of the build
 framework does decipher the compiler version and that could be leveraged
 to change the optimization flags for gcc 4.9, but the other half of the
 build framework does not.  Unfortunately there are two instances where
 this is broken, and the fix needs to be done in both places.
 
 I maintain the FreeBSD port and the approach that I took for package
 building is to detect the use of gcc 4.9 in the port Makefile, and then
 patch the freebsd.mk and unxfbsdi.mk on the fly when gcc 4.9 is
 detected.  I didn't need to patch unxfbdx.mk because it uses -O2
 optimization on x86_64.
 
 Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475 
 (where a patch by Ariel is available, but operates at a C++ code level 
 and not at a Makefile level)?
 
 Yes.  Early on I saw the LibreOffice folks do something similar, but I
 was not able to get that to work reliably and switched to -O0
 optmization for a long time.  My workaround above is fairly recent.

As I recall, when I tried something similar to the patch in the bug
report, it fixed the problem on x86_64, but not intel.  The problem
potentially affects two files, fmgridif.cxx and ColumnControl.cxx.  The
out of the box build on FreeBSD builds one of those with -Os and the
other with -O2 on x86_64.  Since the gcc bug is only triggered when
using -Os, only one of the resulting .o files has the problem, and it is
fixed by the patch.   On intel, both files are built with -Os, so both
.o files have the problem.  The patch fixed one of them and the
undefined symbols were exported, but they were exported as weak symbols
and were not visible outside of the shared library that the .o file was
linked into.  The .o file that remained broken was linked into another
shared library and wasn't able to see the symbols from the fixed .o
file.

Patching the source to attempt to export these symbols is the wrong
thing to do in any case.  These are for class methods that are defined
in the class declaration, so the expectation is that the compiler will
inline them wherever they are used.

There are some hooks in the build specific files with optimization
disabled, so adding the above two files to that list is one possible
fix, though I don't know if that hook is present in both parts of the
build framework, but it looks like it is.

Another possibility is to globally change -Os to -Os
-fno-devirtualize -fno-devirtualize-speculatively when building with
gcc.  On the solenv/inc side, this would involve patching these files:
os2.mk
unxfbsdi.mk
unxfbsdppc.mk
unxlngi.mk
unxlngm68k.mk
unxlngmips.mk
unxlngppc.mk
unxlngr.mk
unxlngs.mk
Since CCUMVER is available, this could be made conditional on the
gcc version.

On the gbuild/platform side, the files to change are:
freebsd.mk
linux.mk
os2.mk
winmingw.mk
Since CCNUMBER is not available here, the optmiization change would
affect all gcc versions.


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

Re: build breaker/Issue 126449/ svx module

[Don Lewis]

On 14 Aug, Andrea Pescetti wrote:
 On 09/08/2015 Don Lewis wrote:
 Looks like you are compiling with gcc 4.9.  I ran into this same problem
 on FreeBSD and worked around it by changing the -Os optimization flag
 ... This is a gcc bug, see:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009
 
 This looks like very valuable information (I never saw this, but I build 
 with gcc 4.8.x most of the times). Could you expand on it a bit?

It apparently is an optimizer bug in gcc 4.9 that has been fixed in gcc
5 and was not present in 4.8.  It is sometimes triggered by inline
virtual class methods.  I believe it only happens with -Os optimization.
The workaround is to either disable optimization by using
-O0, or disabling the problematic optimization step by using
-fno-devirtualize -fno-devirtualize-speculatively, which I figured out
based on comment #2 in the gcc bug report.  I didn't attempt to figure
out if only one of the flags would be sufficient.

 Do I understand correctly from the above issue than anybody building 
 OpenOffice (I'm obviously particularly interested in the coming 4.1.2) 
 with GCC 4.9.0 to 4.9.3 (and possibly later 4.9.x releases, since the 
 issue is not fixed yet in 4.9.x) will have to manually edit their makefiles?

Yes.

 If this is true, would you recommend that we either detect it at 
 configuration time, or modify the makefiles, or anything else?

It would be nice to detect it at configuration time, but configure
doesn't really look at the compiler version.  One half of the build
framework does decipher the compiler version and that could be leveraged
to change the optimization flags for gcc 4.9, but the other half of the
build framework does not.  Unfortunately there are two instances where
this is broken, and the fix needs to be done in both places.

I maintain the FreeBSD port and the approach that I took for package
building is to detect the use of gcc 4.9 in the port Makefile, and then
patch the freebsd.mk and unxfbsdi.mk on the fly when gcc 4.9 is
detected.  I didn't need to patch unxfbdx.mk because it uses -O2
optimization on x86_64.

 Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475 
 (where a patch by Ariel is available, but operates at a C++ code level 
 and not at a Makefile level)?

Yes.  Early on I saw the LibreOffice folks do something similar, but I
was not able to get that to work reliably and switched to -O0
optmization for a long time.  My workaround above is fairly recent.

 Sorry for the many questions! At the bare minimum, it would be very 
 helpful if you can update the building guide at 
 https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
  
 with some specific information; I know you build on FreeBSD which is not 
 one of the platforms we provide binaries for, but you can add a whole 
 section about it if you like. If you need a wiki account, just ask here.

It would really be nice if this just worked out of the box.  For the
stuff that uses solenv/inc to build, the compiler version is available
in $(CCNUMVER), which can be tested in the target .mk files to adjust
the optimization flags.  Unfortunately $(CCNUMVER) is not available on
the solenv gbuild side.


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

Re: build breaker/Issue 126449/ svx module

[Don Lewis]

On  8 Aug, Martin Bakker wrote:
 Hi There,
 
 I'm a developer using  AOO in some of my applications.
 To debug some AOO problems I decided to build AOO with symbols to try and 
 find a solution.
 I followed the instructions on how to build  but got stuck  when trying to 
 build the svx module.
 used svn to get fresh start and tried building without debug, same problem.
 
 
 I opend an Issue  on bugzilla but was kindly directed this way.
 
 see the issue for a complete log.
 configure was run like: 
 configure --with-package-format=installed --disable-gnome-vfs
 
 trying to build fails with :
 
 [ build LNK ] Library/libsvxcore.so
 /home/martin/Downloads/aoo/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
  
 In function 
 `FmXGridControl::createPeer(com::sun::star::uno::Referencecom::sun::star::awt::XToolkit
  
 const, com::sun::star::uno::Referencecom::sun::star::awt::XWindowPeer 
 const)':
 fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to 
 WindowListenerMultiplexer::acquire()'
 /usr/bin/ld: 
 /home/martin/Downloads/aoo/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
  
 relocation R_X86_64_PC32 against undefined symbol 
 `_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when making 
 a shared object; recompile with -fPIC

Looks like you are compiling with gcc 4.9.  I ran into this same problem
on FreeBSD and worked around it by changing the -Os optimization flag
in main/solenv/gbuild/platform/freebsd.mk and
main/solenv/inc/unxfbsdi.mk to:
-Os -fno-devirtualize -fno-devirtualize-speculatively
The files controlling this on your platform will be different.

This is a gcc bug, see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009


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

Re: Are the Buildbots down?

[Don Lewis]

On 21 Jul, To: p...@apache.org wrote:
 Doing
   pkg install clang35
 
 adding this to the configure script
   CPP=clang-cpp35 CC=clang35 CXX=clang++35  export CPP CC CXX 

On FreeBSD configure still needs CPPFLAGS=-I/usr/local/include in its
environment.  Looks like that got dropped when CPP and friends were
added, which is why the configure step is now failing on the buildbot.


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

Re: Are the Buildbots down?

[Don Lewis]

On 14 Jul, Don Lewis wrote:

 At this point, I'm going to back out the patch above, and remove
 CPPFLAGS and LDFLAGS from the environment passed to build.  I'll pass
 LIBINTL_PREFIX instead to fix he hunspell issue.

This is looking real good.  This time the build got far enough to tickle
the clang 3.4 code amd64 generation bug that I previously observed while
working on the FreeBSD port.

Making:libdbase.so
c++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-z,origin -Wl,-rpath,'$ORIGIN' -shared 
-Wl,-O1 -Wl,--version-script ../../../unxfbsdx.pro/misc/component_dbase.map 
-L../../../unxfbsdx.pro/lib -L../lib 
-L/tmp/openoffice/aoo-4.2.0/main/solenv/unxfbsdx/lib 
-L/tmp/openoffice/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib 
-L/tmp/openoffice/aoo-4.2.0/main/solenv/unxfbsdx/lib -L/usr/local/openjdk7/lib 
-L/usr/local/openjdk7/jre/lib/amd64 -L/usr/local/openjdk7/jre/lib/amd64/server 
-L/usr/local/openjdk7/jre/lib/amd64/native_threads -L/usr/local/lib 
../../../unxfbsdx.pro/slo/DCode.o ../../../unxfbsdx.pro/slo/DResultSet.o 
../../../unxfbsdx.pro/slo/DStatement.o 
../../../unxfbsdx.pro/slo/DPreparedStatement.o 
../../../unxfbsdx.pro/slo/dindexnode.o ../../../unxfbsdx.pro/slo/DIndexIter.o 
../../../unxfbsdx.pro/slo/DDatabaseMetaData.o 
../../../unxfbsdx.pro/slo/DCatalog.o ../../../unxfbsdx.pro/slo/DColumns.o 
../../../unxfbsdx.pro/slo/DIndexColumns.o ../../../unxfbsdx.pro/slo/DIndex.o 
../../../unxfbsdx.pro/slo/!
 DIndexes.o ../../../unxfbsdx.pro/slo/DTable.o 
../../../unxfbsdx.pro/slo/DTables.o ../../../unxfbsdx.pro/slo/DConnection.o 
../../../unxfbsdx.pro/slo/Dservices.o ../../../unxfbsdx.pro/slo/DDriver.o 
../../../unxfbsdx.pro/slo/dbase_version.o -o 
../../../unxfbsdx.pro/lib/libdbase.so -luno_cppu -luno_cppuhelpergcc3 
-lvos3gcc3 -lsvl -ltl -lucbhelper4gcc3 -luno_sal -ldbtools -lfile -lutl 
-lcomphelpgcc3 -Wl,--as-needed -pthread -lm -Wl,--no-as-needed 
/usr/bin/ld: ../../../unxfbsdx.pro/slo/DTable.o: relocation R_X86_64_PC32 
against `_ZThn192_N12connectivity4file10OFileTable7acquireEv' can not be used 
when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
dmake:  Error code 1, while making '../../../unxfbsdx.pro/lib/libdbase.so'

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


I'll install clang35 from ports and try again.


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

Re: Are the Buildbots down?

[Don Lewis]

On 15 Jul, Don Lewis wrote:

 I'll install clang35 from ports and try again.

Success!

This is with trunk r1690992 and no additional patches.

***
Successful packaging process!
***
copying log file to 
/tmp/openoffice/aoo-4.2.0/main/instsetoo_native/unxfbsdx.pro/Apache_OpenOffice/archive/install/log/log_AOO420_en-US.log
stopping log at Wed Jul 15 13:40:58 2015


Here is my build script:

autoconf
CPP=clang-cpp35 CC=clang35 CXX=clang++35 CPPFLAGS=-I/usr/local/include 
LDFLAGS=-L/usr/local/lib ./configure  --with-jdk-home=/usr/local/openjdk7 
--with-gperf=/usr/bin/gperf --with-gnu-patch=/usr/local/bin/gpatch 
--x-includes=/usr/local/include --x-libraries=/usr/local/lib --disable-gconf 
--disable-gnome-vfs --without-junit --enable-verbose --without-stlport 
--enable-category-b --disable-odk --with-system-zlib --with-system-stdlibs 
--disable-gstreamer --with-system-libxml --with-system-openssl 
--with-package-format=archive
./bootstrap
. FreeBSDAMDEnv.Set.sh
cd instsetoo_native/util
LIBINTL_PREFIX=/usr/local build.pl --all


To get this working on the buildbot:
  1) Install the clang35 pkg
  2) Pass CPP, CC, and CXX to configure
  3) Do not pass CPPFLAGS or LDFLAGS to build
  4) Pass LIBINTL_PREFIX to build

The first two steps are only needed on FreeBSD 10 amd64.  The base
compiler works properly on i386.  The base compiler in FreeBSD 11 works
properly on both amd64 and i386.

Bonus points for fixing configure to add LIBINTL_PREFIX to the
environment.


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

Re: Build trouble (was Re: Are the Buildbots down?)

[Don Lewis]

On 15 Jul, Pedro Giffuni wrote:

 And here comes one of the huge can of worms in OpenOffice:
 we are using a very old version of ICU.
 
 The truth is, we have code to update ICU to a more recent
 version resting peacefully somewhere in the Symphony branch.
 The IBM (China) guys that wrote it never merged it into
 AOO (at least one of them tried and broke the Mac port,
 but I don't remember because I burned the email).

It would be really nice to see this in the tree so that I could switch
the FreeBSD port to --with-system-icu.

 Thank you very much for your help. I suggest you step away
 now and forget you ever saw this ... really.

Hey, I sometimes enjoy watching horror movies ...


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

Re: Are the Buildbots down?

[Don Lewis]

Next problem ...

libxml2 deliver
deliver -- version: 275594
Module 'libxml2' delivered successfully. 50 files copied, 2 files unchanged

=
Building module libxslt
=

[snip]

Disabling crypto support
Enabling debugger
checking for libxml libraries = 2.6.27... 2.7.8 found
checking whether shared libraries will be built (required for plugins)... yes
checking libxml2 module support... yes
configure: creating ./config.status

[snip]

/bin/sh ../libtool --tag=CC   --mode=link cc  -g -O2 -Wall  -Wl,--version-script
=./libxslt.syms -version-info 2:26:1 -Wl,-rpath,'$ORIGIN:$ORIGIN/../ure-link/lib
' -Wl,-noinhibit-exec -o libxslt.la -rpath /usr/local/lib attrvt.lo xslt.lo xslt
locale.lo xsltutils.lo pattern.lo templates.lo variables.lo keys.lo numbers.lo e
xtensions.lo extra.lo functions.lo namespaces.lo imports.lo attributes.lo docume
nts.lo preproc.lo transform.lo security.lo -L/tmp/openoffice/aoo-4.2.0/main/solv
er/420/unxfbsdx.pro/lib -lxml2 -lm
libtool: link: cc -shared  .libs/attrvt.o .libs/xslt.o .libs/xsltlocale.o .libs/
xsltutils.o .libs/pattern.o .libs/templates.o .libs/variables.o .libs/keys.o .li
bs/numbers.o .libs/extensions.o .libs/extra.o .libs/functions.o .libs/namespaces
.o .libs/imports.o .libs/attributes.o .libs/documents.o .libs/preproc.o .libs/tr
ansform.o .libs/security.o   -L/tmp/openoffice/aoo-4.2.0/main/solver/420/unxfbsd
x.pro/lib -lxml2 -lm  -Wl,--version-script=./libxslt.syms -Wl,-rpath -Wl,\$ORIGI
N:\$ORIGIN/../ure-link/lib -Wl,-noinhibit-exec   -Wl,-soname -Wl,libxslt.so.1 -o
 .libs/libxslt.so.1
/usr/bin/ld: cannot find -lxml2
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:410: recipe for target 'libxslt.la' failed


% find . -name libtextcat.so -print
./libtextcat/unxfbsdx.pro/lib/libtextcat.so
./libtextcat/unxfbsdx.pro/misc/build/libtextcat-2.2/src/.libs/libtextcat.so
./solver/420/unxfbsdx.pro/lib/libtextcat.so
% find . -name libxml2.so -print
./libxml2/unxfbsdx.pro/lib/libxml2.so
./libxml2/unxfbsdx.pro/misc/build/libxml2-2.7.8/.libs/libxml2.so


Looks like libxml2.so didn't get copied over into solver for some
reason.


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

Re: Are the Buildbots down?

[Don Lewis]

On 13 Jul, Pedro Giffuni wrote:
 
 Hmm ...
 
 Perhaps there is something wrong here:
 
 tmain/libxml2/prj/d.lst

Perhaps ... but since libxml is already installed on the system because
it is a prerequisite of some of the other dependencies, such as java,
gconf2, and gnome-vfs, I just switched to --with-system-libxml and
--with-system-libxslt.  The latter is required by configure if the
former option is enabled.

The next problem is:

cc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/usr/include -DTERMIO -O3 -Wall -c 
ui_lib.c -o ui_lib.o
cc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/usr/include -DTERMIO -O3 -Wall -c 
ui_openssl.c -o ui_openssl.o
ui_openssl.c:224:11: fatal error: 'termio.h' file not found
# include termio.h
  ^
1 error generated.
*** Error code 1

Stop.
make[2]: stopped in 
/tmp/openoffice/aoo-4.2.0/main/openssl/unxfbsdx.pro/misc/build/openssl-0.9.8o/crypto/ui
*** Error code 1


Time for --with-system-openssl ...


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

Re: Are the Buildbots down?

[Don Lewis]

Next problem:

/bin/sh ../../libtool --tag=CXX   --mode=link c++  -g -O2   -o chmorph 
chmorph.o ../parsers/libparsers.a ../hunspell/libhunspell-1.3.la 
libtool: link: c++ -g -O2 -o chmorph chmorph.o  ../parsers/libparsers.a 
../hunspell/.libs/libhunspell-1.3.a
c++ -DHAVE_CONFIG_H -I. -I../.. -I../../src/hunspell -I../../src/parsers  
-I/include -D_THREAD_SAFE -I/usr/local/include  -g -O2 -MT hunspell.o -MD -MP 
-MF .deps/hunspell.Tpo -c -o hunspell.o hunspell.cxx
hunspell.cxx:112:14: fatal error: '../../intl/libintl.h' file not found
#include ../../intl/libintl.h
 ^
1 error generated.
Makefile:524: recipe for target 'hunspell.o' failed
gmake[3]: *** [hunspell.o] Error 1
gmake[3]: Leaving directory 
'/tmp/openoffice/aoo-4.2.0/ext_libraries/hunspell/unxfbsdx.pro/misc/build/hunspell-1.3.2/src/tools'


No libintl.h around here ...
% find ext_libraries main -name libintl.h -print
%

There is one in /usr/local/include that is installed by gettext, but it
isn't under an intl/ directory.


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

Re: Are the Buildbots down?

[Don Lewis]

On 14 Jul, Pedro Giffuni wrote:
 
 
 On 07/14/15 02:32, Don Lewis wrote:
 Next problem:

 /bin/sh ../../libtool --tag=CXX   --mode=link c++  -g -O2   -o chmorph 
 chmorph.o ../parsers/libparsers.a ../hunspell/libhunspell-1.3.la
 libtool: link: c++ -g -O2 -o chmorph chmorph.o  ../parsers/libparsers.a 
 ../hunspell/.libs/libhunspell-1.3.a
 c++ -DHAVE_CONFIG_H -I. -I../.. -I../../src/hunspell -I../../src/parsers  
 -I/include -D_THREAD_SAFE -I/usr/local/include  -g -O2 -MT hunspell.o -MD 
 -MP -MF .deps/hunspell.Tpo -c -o hunspell.o hunspell.cxx
 hunspell.cxx:112:14: fatal error: '../../intl/libintl.h' file not found
 #include ../../intl/libintl.h
   ^
 1 error generated.
 Makefile:524: recipe for target 'hunspell.o' failed
 gmake[3]: *** [hunspell.o] Error 1
 gmake[3]: Leaving directory 
 '/tmp/openoffice/aoo-4.2.0/ext_libraries/hunspell/unxfbsdx.pro/misc/build/hunspell-1.3.2/src/tools'


 No libintl.h around here ...
 % find ext_libraries main -name libintl.h -print
 %

 There is one in /usr/local/include that is installed by gettext, but it
 isn't under an intl/ directory.

 gettext was included in OpenOffice before the licensing cleanup.
 
 It is expected that you have a system gettext and encoding the
 path instead of -I including it is a bad practice, IMHO. However,
 this doesn't seem to be an auto-inflicted error but something
 that upstream hunspell does. How does the FreeBSD port
 work around that?

It appears that hunspell has a way of generating that header in the that
location on systems that don't have gettext, but for whatever reason it
decided not to do so.  The real problem is this fragment of
ext_libraries/hunspell/makefile.mk:

.ELIF $(OS)==FREEBSD # $(SYSBASE)!=
CONFIGURE_FLAGS+=CPPFLAGS=-I$(LIBINTL_PREFIX)/include 
--with-libintl-prefix=$(LIBINTL_PREFIX)
.ENDIF

The problem is that $(LIBINTL_PREFIX) does not seem to be defined
anywhere, so we end up passing
  CPPFLAGS=-I/include --with-libintl-prefix=
to configure, so it does not find the header.  This is especially dumb
since we are passing CPPFLAGS=-I/usr/local/include and
LDFLAGS=-L/usr/local/lib to the build. By setting
LIBINTL_PREFIX=/usr/local in the environment, I was able to sucessfully
build hunspell.

I thought that changing the above to CPPFLAGS=$(CPPFLAGS) would do the
trick, but when I tried the build, it got expanded to CPPFLAGS=. There
were two reasons for that.  One was an error in my build script that
caused CPPFLAGS not not actually get set.  The other is this line in
solenv/inc/settings.mk:
  CPPFLAGS=
The latter doesn't seem to affect everything because fixing my build
script allowed the python build to find libintl.h, but I suspect this is
the reason for the LIBINTL_PREFIX hack.

Unfortunately this seems to break the icu build.  It looks like the icu
build is finding the headers installed by the icu FreeBSD port instead
of its own because it is appending to CPPFLAGS and thus gets the search
order wrong.  Unfortunately icu is an indirect dependency of gtk:

gtk2 - pango - harfbuzz - icu

cc -I/usr/local/include -D_REENTRANT -I. -I../i18n   -DU_COMMON_IMPLEMENTATION 
-O-fvisibility=hidden -c   -o putil.ao putil.c
In file included from putil.c:67:
./cstring.h:77:12: warning: 'uprv_stricmp' macro redefined
#   define uprv_stricmp(str1, str2) T_CString_stricmp(str1, str2)
   ^
/usr/local/include/unicode/urename.h:1349:9: note: previous definition is here
#define uprv_stricmp U_ICU_ENTRY_POINT_RENAME(uprv_stricmp)
^
In file included from putil.c:67:
./cstring.h:78:12: warning: 'uprv_strnicmp' macro redefined
#   define uprv_strnicmp(str1, str2, n) T_CString_strnicmp(str1, str2, n)
   ^
/usr/local/include/unicode/urename.h:1351:9: note: previous definition is here
#define uprv_strnicmp U_ICU_ENTRY_POINT_RENAME(uprv_strnicmp)
^
putil.c:1673:1: error: conflicting types for 'u_versionToString_55'
u_versionToString(UVersionInfo versionArray, char *versionString) {
^
/usr/local/include/unicode/urename.h:405:27: note: expanded from macro 
'u_versionToString'
#define u_versionToString U_ICU_ENTRY_POINT_RENAME(u_versionToString)
  ^
/usr/local/include/unicode/uvernum.h:112:40: note: expanded from macro 
'U_ICU_ENTRY_POINT_RENAME'
#define U_ICU_ENTRY_POINT_RENAME(x)
U_DEF2_ICU_ENTRY_POINT_RENAME(x,U_ICU_VERSION_SUFFIX)
   ^
/usr/local/include/unicode/uvernum.h:111:44: note: expanded from macro 
'U_DEF2_ICU_ENTRY_POINT_RENAME'
#define U_DEF2_ICU_ENTRY_POINT_RENAME(x,y) U_DEF_ICU_ENTRY_POINT_RENAME(x,y)
   ^
/usr/local/include/unicode/uvernum.h:110:43: note: expanded from macro 
'U_DEF_ICU_ENTRY_POINT_RENAME'
#define U_DEF_ICU_ENTRY_POINT_RENAME(x,y) x ## y
  ^
scratch space:204:1: note: expanded from here
u_versionToString_55
^
/usr/local/include/unicode/uversion.h:181:1: note: previous declaration is here
u_versionToString(const UVersionInfo

Re: Are the Buildbots down?

[Don Lewis]

On 14 Jul, Pedro Giffuni wrote:
 
 
 On 07/14/15 01:37, Don Lewis wrote:
 On 13 Jul, Pedro Giffuni wrote:
 Hmm ...

 Perhaps there is something wrong here:

 tmain/libxml2/prj/d.lst
 Perhaps ... but since libxml is already installed on the system because
 it is a prerequisite of some of the other dependencies, such as java,
 gconf2, and gnome-vfs, I just switched to --with-system-libxml and
 --with-system-libxslt.  The latter is required by configure if the
 former option is enabled.
 
 That is reasonable. perhaps that should be the default in
 configure.

Probably so.

I finally got around to looking at what arguments the buildbot passes to
configure and it includes --with-system-libxml.

 The next problem is:

 cc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/usr/include -DTERMIO -O3 -Wall -c 
 ui_lib.c -o ui_lib.o
 cc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/usr/include -DTERMIO -O3 -Wall -c 
 ui_openssl.c -o ui_openssl.o
 ui_openssl.c:224:11: fatal error: 'termio.h' file not found
 # include termio.h
^
 1 error generated.
 *** Error code 1

 Stop.
 make[2]: stopped in 
 /tmp/openoffice/aoo-4.2.0/main/openssl/unxfbsdx.pro/misc/build/openssl-0.9.8o/crypto/ui
 *** Error code 1


 Time for --with-system-openssl ...

 
 By all means, updating OpenSSL is something that should be done
 for the next release (no, I am not volunteering).
 
 It could even be risky to leave the internal OpenSSL installed in
 your system.

Yeah.  The buildbot also uses --with-system-openssl.


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

Re: Are the Buildbots down?

[Don Lewis]

On 14 Jul, Pedro Giffuni wrote:
 
 
 On 07/13/15 23:33, Don Lewis wrote:
 On 13 Jul, Pedro Giffuni wrote:

 I did notice the buildbot was failing on nss(?).
 That's what I get for taking hunks from elsewhere :-P.
 Patch below ...
 
 Committed as revision 1690992.
 Thanks!
 
 As you might have noticed I don't spend much quality time
 with AOO lately :-(.
 I've been spending too much B-(
 
 It happens frequently with AOO :(.
 
 I do appreciate this, you had no obligation to fix it
 and it's unlikely to have any effect on FreeBSD's
 own packaging.
 
 OTOH, it can save some trouble to have the extra
 checking with the Apache buildbot.

That's my motivation for working on this.


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

Re: Are the Buildbots down?

[Don Lewis]

On 13 Jul, Pedro Giffuni wrote:

 I did notice the buildbot was failing on nss(?).
 That's what I get for taking hunks from elsewhere :-P.

Patch below ...

 As you might have noticed I don't spend much quality time
 with AOO lately :-(.

I've been spending too much B-(

Index: main/nss/makefile.mk
===
--- main/nss/makefile.mk(revision 1690824)
+++ main/nss/makefile.mk(working copy)
@@ -50,6 +50,10 @@
 PATCH_FILES+=nss_macosx.patch
 .ENDIF # $(OS)==MACOSX
 
+.IF $(OS)==FREEBSD
+PATCH_FILES+=nss_freebsd.patch
+.ENDIF
+
 .IF $(debug) != 
 .ELSE
 BUILD_OPT=1
Index: main/nss/nss_freebsd.patch
===
--- main/nss/nss_freebsd.patch  (revision 0)
+++ main/nss/nss_freebsd.patch  (working copy)
@@ -0,0 +1,14 @@
+--- misc/nss-3.14.4/mozilla/security/coreconf/FreeBSD.mk   2012-05-03 
09:42:51.0 +
 misc/build/nss-3.14.4/mozilla/security/coreconf/FreeBSD.mk 2015-07-13 
23:42:44.915864000 +
+@@ -5,9 +5,8 @@
+ 
+ include $(CORE_DEPTH)/coreconf/UNIX.mk
+ 
+-DEFAULT_COMPILER  = gcc
+-CC= gcc
+-CCC   = g++
++DEFAULT_COMPILER  = $(CC)
++CCC   = $(CXX)
+ RANLIB= ranlib
+ 
+ CPU_ARCH  = $(OS_TEST)




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

Re: Are the Buildbots down?

[Don Lewis]

On 13 Jul, Pedro Giffuni wrote:

 I did notice the buildbot was failing on nss(?).
 That's what I get for taking hunks from elsewhere :-P.

Working on a patch for that ...


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

Re: Are the Buildbots down?

[Don Lewis]

On 13 Jul, Pedro Giffuni wrote:
 
 
 On 07/13/15 02:06, Don Lewis wrote:
 ...

 According to the bootstrap log, it's not a download problem.

 I'm able to reproduce the problem here.  It looks like clang doesn't
 like some of the code in CoinMP:

 In file included from ClpSolve.cpp:347:
 /tmp/openoffice/aoo-4.2.0/ext_libraries/coinmp/unxfbsdx.pro/misc/build/CoinMP-1.7.6/CoinUtils/src/CoinSignal.hpp:47:12:
  error:
extension used [-Werror,-Wlanguage-extension-token]
 typedef typeof(SIG_DFL) CoinSighandler_t;
 ^

 The code fragment in question:

 #if defined(__FreeBSD__)  defined(__GNUC__)
 typedef typeof(SIG_DFL) CoinSighandler_t;
 #  define CoinSighandler_t_defined
 #endif

 This has been changed in CoinMP-1.8.2 to:

 #if defined(__FreeBSD__)  defined(__GNUC__)
 typedef __decltype(SIG_DFL) CoinSighandler_t;
 #  define CoinSighandler_t_defined
 #endif

 
 OpenOffice has a clang patch that was not catching this.
 I hacked it for FreeBSD now:
 http://svn.apache.org/viewvc?view=revisionrevision=1690740
 
 But there is certainly something wrong as clang is not being detected.

I think clang defines __GNUC__, so with the existing clang patch we
were still using the original typedef.  If the compiler didn't croak
there, then we would have redefined the typedef again in the __clang__
section.

http://stackoverflow.com/questions/28166565/detect-gcc-as-opposed-to-msvc-clang-with-macro


#if defined(__FreeBSD__)  defined(__GNUC__)
   typedef typeof(SIG_DFL) CoinSighandler_t;
#  define CoinSighandler_t_defined
#endif

//-

#if defined(__NetBSD__)  defined(__GNUC__)
   typedef typeof(SIG_DFL) CoinSighandler_t;
#  define CoinSighandler_t_defined
#endif

//-

#if defined(_AIX)
#  if defined(__GNUC__)
  typedef typeof(SIG_DFL) CoinSighandler_t;
# define CoinSighandler_t_defined
#  endif
#endif
//-
   
#if defined (__hpux)
#  define CoinSighandler_t_defined
#  if defined(__GNUC__)
  typedef typeof(SIG_DFL) CoinSighandler_t;
#  else
  extern C {
 typedef void (*CoinSighandler_t) (int);
  }
#  endif
#endif

//-

#if defined(__sun)
#  if defined(__SUNPRO_CC)
# include signal.h
  extern C {
 typedef void (*CoinSighandler_t) (int);
  }
# define CoinSighandler_t_defined
#  endif
#  if defined(__GNUC__)
  typedef typeof(SIG_DFL) CoinSighandler_t;
# define CoinSighandler_t_defined
#  endif
#endif

//-

#if defined(__clang__)
   typedef void(*CoinSighandler_t)(int);
#  define CoinSighandler_t_defined
#elif defined(__MACH__)  defined(__GNUC__)
   typedef typeof(SIG_DFL) CoinSighandler_t;
#  define CoinSighandler_t_defined
#endif


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

Re: Are the Buildbots down?

[Don Lewis]

On 13 Jul, Pedro Giffuni wrote:
 
 
 On 07/13/15 02:06, Don Lewis wrote:
 On 12 Jul, Pedro Giffuni wrote:
 Hi Gavin;

 Let me copy Don Lewis, who maintains the FreeBSD port @FreeBSD ...

 On 07/12/15 12:59, Gavin McDonald wrote:
 On 12 Jul 2015, at 4:50 pm, Pedro Giffuni p...@apache.org
 mailto:p...@apache.org wrote:

 Hello;

 On 07/11/15 10:39, Pedro Giffuni wrote:
 Hello;

 On 07/11/15 05:39, Marcus wrote:
 Am 07/11/2015 11:31 AM, schrieb Gavin McDonald:
 The ?open office-fbsd-nightly? fails the ?build ?all? step and
 needs investigating.

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

 Reason(s):

 ERROR: error 65280 occurred while making
 /usr/home/buildslave27/slave27/openoffice-fbsd-nightly/build/ext_libraries/coinmp

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

 build --all:coinmp
 @Pedro:
 As FreeBSD is involved maybe you can give Gavin some help?

 I looked at it briefly but the buildbot offers little useful
 information.

 I have asked Don Lewis to look at it. He has been very helpful and
 is for most purposes the FreeBSD port maintainer these days.

 It may be a download error, but also the old FreeBSD version that is
 being used has a very old toolchain.
 I have no idea why you keep saying we are using a very old version, I have
 mentioned before:

 This is what the bb-fbsd2 buildbot slave is using:

 FreeBSD 10.1-RELEASE-p10 (GENERIC) #0: Wed May 13 06:54:13 UTC 2015

 Can you tell me why you think we are on an older version?

 Gav?

 https://ci.apache.org/buildslaves/bb-fbsd2_64bit

 Reports:

 FreeBSD 9.0-RELEASE 64 bit buildbot for genberal projects use.

 Have you updated the compiler as I suggested previously?

 Perhaps there is some way to give Don access to the buildbot?
 He already signed an ICLA.

 According to the bootstrap log, it's not a download problem.

 I'm able to reproduce the problem here.  It looks like clang doesn't
 like some of the code in CoinMP:

 In file included from ClpSolve.cpp:347:
 /tmp/openoffice/aoo-4.2.0/ext_libraries/coinmp/unxfbsdx.pro/misc/build/CoinMP-1.7.6/CoinUtils/src/CoinSignal.hpp:47:12:
  error:
extension used [-Werror,-Wlanguage-extension-token]
 typedef typeof(SIG_DFL) CoinSighandler_t;
 ^

 The code fragment in question:

 #if defined(__FreeBSD__)  defined(__GNUC__)
 typedef typeof(SIG_DFL) CoinSighandler_t;
 #  define CoinSighandler_t_defined
 #endif

 This has been changed in CoinMP-1.8.2 to:

 #if defined(__FreeBSD__)  defined(__GNUC__)
 typedef __decltype(SIG_DFL) CoinSighandler_t;
 #  define CoinSighandler_t_defined
 #endif

 Hmm .. that change happened six years ago in the coin trunk:
 
 https://projects.coin-or.org/CoinUtils/changeset/1126/trunk/CoinUtils/src/CoinSignal.hpp
 
 But the coinmp guys haven't updated it. We carry the change
 in our (FreeBSD) local port:
 https://svnweb.freebsd.org/ports/head/math/coinmp/files/

I looked at the PR and it appears that the FreeBSD port was patched to
revert the typeof - __decltype upstream change so that the port would
build with our ancient gcc in FreeBSD 8 and 9 base.  Since the port
successfully compiles with clang on FreeBSD 10, I suspect the difference
between the FreeBSD port and building the openoffice bundled version
must be caused by different compiler flags.


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

Re: Are the Buildbots down?

[Don Lewis]

On 13 Jul, Pedro Giffuni wrote:
 
 
 On 07/13/15 11:29, Don Lewis wrote:
 ...
 OpenOffice has a clang patch that was not catching this.
 I hacked it for FreeBSD now:
 http://svn.apache.org/viewvc?view=revisionrevision=1690740

 But there is certainly something wrong as clang is not being detected.
 I think clang defines __GNUC__, so with the existing clang patch we
 were still using the original typedef.  If the compiler didn't croak
 there, then we would have redefined the typedef again in the __clang__
 section.
 Yes, clang reports itself as gcc 4.2, so it sets __GNUC__ and
 __clang__.
 
 The patch I committed should be a no-op (except for gcc).
 http://stackoverflow.com/questions/28166565/detect-gcc-as-opposed-to-msvc-clang-with-macro


 #if defined(__FreeBSD__)  defined(__GNUC__)
 typedef typeof(SIG_DFL) CoinSighandler_t;
 #  define CoinSighandler_t_defined
 #endif

 //-

 ...
 some lines later
 ...
 //-

 #if defined(__clang__)
 typedef void(*CoinSighandler_t)(int);
 #  define CoinSighandler_t_defined
 #elif defined(__MACH__)  defined(__GNUC__)
 typedef typeof(SIG_DFL) CoinSighandler_t;
 #  define CoinSighandler_t_defined
 #endif

 Ugh.. the problem is I am only looking at diffs, not at the code so
 I missed this mess.
 
 Second try:
 
 http://svn.apache.org/viewvc?view=revisionrevision=1690755

This part doesn't look right:

 #if defined(__FreeBSD__)  defined(__GNUC__)
-   typedef __decltype(SIG_DFL) CoinSighandler_t;
+   typedef typeof(SIG_DFL) CoinSighandler_t;
 #  define CoinSighandler_t_defined
 #endif

patching file CoinMP-1.7.6/Osi/ltmain.sh
patching file CoinMP-1.7.6/CoinUtils/src/CoinSignal.hpp
/usr/local/bin/gpatch:  malformed patch at line 1230: @@ -95,7 +95,10 @@

dmake:  Error code 2, while making './unxfbsdx.pro/misc/build/so_patched_coinmp'

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

Reason(s):



I patched the patch with this patch and got a successful coinmp build:

Index: ext_libraries/coinmp/coinmp-1.7.6-clang.patch
===
--- ext_libraries/coinmp/coinmp-1.7.6-clang.patch   (revision 1690824)
+++ ext_libraries/coinmp/coinmp-1.7.6-clang.patch   (working copy)
@@ -1,22 +1,25 @@
 misc/CoinMP-1.7.6/CoinUtils/src/CoinSignal.hpp 2011-01-03 
20:31:00.0 -0300
-+++ misc/build/CoinMP-1.7.6/CoinUtils/src/CoinSignal.hpp   2014-02-01 
02:02:10.596696644 -0300
-@@ -44,7 +44,7 @@
+--- misc/CoinMP-1.7.6/CoinUtils/src/CoinSignal.hpp 2011-01-03 
23:31:00.0 +
 misc/build/CoinMP-1.7.6/CoinUtils/src/CoinSignal.hpp   2015-07-14 
00:18:26.10536 +
+@@ -43,7 +43,7 @@
+ 
  
//-
  
- #if defined(__FreeBSD__)  defined(__GNUC__)
--   typedef __decltype(SIG_DFL) CoinSighandler_t;
-+   typedef typeof(SIG_DFL) CoinSighandler_t;
+-#if defined(__FreeBSD__)  defined(__GNUC__)
++#if defined(__FreeBSD__)  defined(__GNUC__)  !defined(__clang__)
+typedef typeof(SIG_DFL) CoinSighandler_t;
  #  define CoinSighandler_t_defined
  #endif
-@@ -95,7 +95,10 @@
+@@ -100,6 +100,13 @@
+ #  define CoinSighandler_t_defined
+ #endif
  
- 
//-
++//-
++
++#if defined(__clang__)
++   typedef __decltype(SIG_DFL) CoinSighandler_t;
++#  define CoinSighandler_t_defined
++#endif
++
+ 
//#
  
--#if defined(__MACH__)  defined(__GNUC__)
-+#if !defined(__FreeBSD__)  defined(__clang__)
-+   typedef void(*CoinSighandler_t)(int);
-+#  define CoinSighandler_t_defined
-+#elif defined(__MACH__)  defined(__GNUC__)
-typedef typeof(SIG_DFL) CoinSighandler_t;
- #  define CoinSighandler_t_defined
- #endif
+ #ifndef CoinSighandler_t_defined


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