Re: building with gcc 10 and external (system) boost

[Don Lewis]

On 20 Jun, Yury Tarasievich wrote:
> Hello Peter,
> 
> You are right on both issues, of course.
> 
> To be fair, on your (1), I didn't touch that 
> variable check, I just brute-forced the C++11 
> mode of compilation.
> 
> Which leads to your (2), but thing is, modern 
> boost sort of requires C++11. Might be other 
> external modules do, too.
> Might that switch to C++11 be overdue?
> 
> What I consider the nicest result (beyond the 
> 'fact of the pudding') is seeing that the C++11 
> build is achievable with very minimal changes to 
> the source, which wouldn't (shouldn't?) reflect 
> on builds with older versions of GCC.

I think that we still need to do release builds of 4.1.x on CentOS 5. Is
it's version of gcc new enough?

Same question about the ancient toolchain we use for Windows builds.

Since we don't use any of the boost libraries, only the include files,
there's not real penalty in using the bundled boost other than the time
it takes to download and unpack.


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

Re: [GitHub] [openoffice] ardovm edited a comment on pull request #133: graphite: remove the -Werror option from debug builds

[Don Lewis]

On 20 Jun, Pedro Lino wrote:
> Hi Arrigo, all
> 
> Development seems to be quite live at
> https://github.com/silnrsi/graphite

We are using SIL Graphite, http://silgraphite.sourceforge.net/

Looking at the Graphite technical overview page mentioned here:
  https://github.com/silnrsi/graphite/blob/master/README.md
(https://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_techAbout)
under "Graphite engine implementations":

  There are two existing implementations of the Graphite engine. The
  original engine is packaged under the name "SilGraphite"; the initial
  implementation was done in 2000. The Graphite2 engine implementation
  began in 2010.

  The  SilGraphite engine is currently used by OpenOffice, XeTeX,
  FieldWorks, and WorldPad. It includes some features not included in
  Graphite2, but is considerably slower.  Graphite2 represents a
  significant (10x) optimization in terms of speed and greatly improved
  robustness, but does not include a few features such a ligature
  component handling and cross-line-boundary contextualization.
  Graphite2 is used by LibreOffice and Firefox.

  The two engines support different APIs. The Graphite2 API was
  specifically developed to be more compatible with the approach to text
  layout used by most commercial software. See the application
  development page for API documentation.

Graphite2 would be better, is currently supported, and Libreoffice
switched to it quite a while ago, but it is not a drop-in replacement.


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

Re: epm 5 not compiling on FreeBSD 13

[Don Lewis]

BTW, FreeBSD doesn't even use epm.  It should be possible to patch
configure.ac to avoid looking for it.


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

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

[Don Lewis]

On 13 Apr, Jim Jagielski wrote:
> I am calling a VOTE on releasing the source and complimentary community 
> builds of
> Apache OpenOffice 4.1.12-RC1 as GA.
> 
> These artifacts can be found at:
> 
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.12-RC1/
> 
> Please cast your vote:
> 
The Release Candidate is good for production/GA:

[X] yes / +1

[ ] no / -1

My vote is based on

[ ] binding (member of PMC)

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

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

I tested the source tarball checksum.

Opening, editing, saving existing calc and writer docs works.


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

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

[Don Lewis]

On 26 Apr, Damjan Jovanovic wrote:
> On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski  wrote:
> 
>> I'm gonna look into the serf->(lib)curl option... Since we don't use any
>> of the fancy features of serf, I'm thinking that the easy option might be
>> best
> 
> 
> 
> Hi
> 
> I've ported our WebDAV content provider module from Serf to Curl.
> 
> While it ended well, and several other bugs were found and fixed, it
> definitely wasn't the "easy option" Jim ;). Starting with conservative
> changes, it ended up needing total restructuring, and became more of a
> rewrite. The crashes were frequent and hung connections many, and I had to
> read up on the HTTP protocol, and read Curl and Serf's source code, but
> eventually I prevailed, and a clean elegant stable Curl WebDAV module
> emerged.
> 
> The huge patch is attached for anyone wishing to review and test. Unless
> there are major objections, I'll push it in a couple of days.
> 
> STATUS
> 
> It builds and works well on FreeBSD and Windows.
> 
> Most of the code was reused, and all the operations and semantics
> previously present with Serf, should have been preserved.
> 
> Browsing WebDAV files and directories, loading files, overwriting them
> ("Save"), creating them ("Save As"), renaming and deleting them, all works.
> 
> HTTP and HTTPS proxies work. Unlike Serf, Curl could also support SOCKS
> proxies (with minimal further changes), but AOO lacks that setting in the
> proxy UI and configuration.
> 
> Authentication works, both to the destination server and to the proxy
> server. I've successfully tested Basic and Digest authentication. Curl
> supports every authentication method Serf does and more.
> 
> HTTPS works, with a custom certificate verification function, using our own
> certificate store from NSS and its API (like the Serf code used). A bug was
> discovered (which is in the Serf implementation too) where self-signed
> certificates were being unconditionally rejected; apparently NSS wants to
> see that a copy of that certificate  in its certificate chain parameter
> too. Now they work, and the user gets prompted to allow access.
> 
> HTTPS and authentication can be used together on the same connection and
> work well, both bringing up their UI dialogs as needed.
> 
> A bug was fixed where when username and password were both present in the
> URL (dav://user:pass@host/path), the code was trying to split them at the
> "@" instead of ":".
> 
> Unnecessary base64 encoding and decoding was removed, when importing the
> TLS connection's certificates into our XSecurityEnvironment. They now come
> in directly as ASN.1 DER, and still work.
> 
> The code was greatly restructured and cleaned up, as Curl's API is
> synchronous and blocking, with parameters set in advance instead of through
> many callbacks, which has allowed using short clear methods, and clean
> separation between the session and request classes. The WebDAV content
> provider has shrunk from 35 to 21 C++ files, 43 to 29 header files, and
> 19129 to 15991 lines of code. With WebDAV methods centralized and
> refactored into only 10-20 lines of code each, instead of scattered across
> 4 files, it is much more understandable and maintainable now.
> 
> Curl is vastly more portable than Serf. We should build easily now even on
> OS/2. We can remain with existing build tools instead of needing scons or
> cmake just to build Serf.
> 
> 3 now unused dependencies were removed: apr, apr-util, and serf. Serf isn't
> so bad. APR's pool idea is an ingenious way of doing resource management in
> C. However Curl has excellent documentation, guides, examples, and detailed
> explanations and even example code for each setting, while Serf has no
> documentation. Serf might be worth it in a project that already uses APR a
> lot, but we don't.
> 
> Instead of the historical, crippled forms of logging like OSL_TRACE(),
> which don't appear in release builds, I've made it use the newer
> com.sun.star.logging UNO component (wrapped in comphelper::EventLogger),
> which was inspired by java.util.logging, with configurable verbosity
> levels, handlers (file and console) and output formats (plain, csv), and
> importantly, which produces output in release builds too. I've also made it
> so that on LogLevel::FINEST, Curl's verbose mode is enabled and Curl's
> debug output is also logged through us, with descriptions of what Curl is
> doing, and logs of all HTTP traffic including headers and bodies, before
> encryption and after decryption in the case of HTTPS, giving us tremendous
> detail that can be used for troubleshooting problems.
> 
> CURL CHANGED TO USE OPENSSL AND ZLIB
> 
> Curl only supports the custom TLS certificate verification function we use
> (the CURLOPT_SSL_CTX_FUNCTION option) when built with OpenSSL, wolfSSL or
> mbedTLS providers. We currently use schannel on Windows instead, which had
> to be changed. I also made it use zlib, which generally helps, and WebDAV
> uses XML which is very verbose and bene

FreeBSD port status

[Don Lewis]

I've had some time in the last couple of weeks to work on the FreeBSD
port.  I was able to get 4.1.14 to build and updated the FreeBSD port to
that version.  I committed the upgrade to the main branch of the FreeBSD
ports tree on March 8. I merged the change to the current ports
quarterly branch a short while ago, so mainstream users should see the
new binary packages show up in the next several days.

For various reasons, I switched the FreeBSD port back to the bundled
boost.  The FreeBSD port uses -std=gnu++98 mode to compile our code. One
of the things I found is that even in that mode, our bundled boost tries
to use some c++11 features, and recent versions of clang treat that as
an error.  This can be fixed with a trivial patch, which I added to the
FreeBSD port.  I plan to commit this fix to our source tree in the near
future.

Another FreeBSD user found that our build is fragile, and can be broken
if the build environment is not clean.  The problem is that the order of
the directories in our include path is not safe.  We put the include
directories for external dependencies like the libs for gtk ahead of
internal and solver directories.  If one of the system include
directories is /usr/local/include, then the build can pick up the system
boost if it is installed on the machine.  The FreeBSD boost port has
issues with gnu++98 mode.  This breaks both gbuild and dmake module
builds of 4.1.x.  Gbuild is mostly fixed in trunk and 4.2.x, and on
those branches so much has been converted to gbuild that I haven't seen
the problem.  The modules left using dmake don't seem to both use boost
and have problematic external dependencies.  I have patches for both the
gbuild and dmake stuff, but the gbuild fix is only for the FreeBSD
platform.  The dmake framework patch is generic, but I've only tested it
on FreeBSD.

The FreeBSD port broke some time ago because of errors in some of the
API comments in the xmerge java source.  We've fixed these in trunk and
4.2.x, but they are still broken in 4.1.x.  They have been flagged as
errors during the build for a very long time, but it was only sometime
last summer when they started getting treated as a fatal error by the
FreeBSD build.  They are still flagged as errors, but they are no longer
fatal. I have no idea what caused the behavior to change in either
direction.

I also experimented a bit with c++11 mode and discovered that recent
versions of clang are much less forgiving of questionable code in that
mode as compared to the older versions of clang that I tried several
years ago.  I ran into many things that broke the build:

  reinterpret_cast< some_type*>(NULL) is a compilation error.  These are
  trivial to fix by switching to static_cast, but the modules where
  these occur seem to use reinterpret_cast excessively.  I would be
  surpised if there were more than a handful of locations in our code
  where reinterpret_cast is the right choice.

  Constructors where the width of the initialization data is wider than
  the width of the member being initialized break the build.  Recent
  clang does not want to automatically narrow the data and wants an
  explicit cast to be used.  The casts are easy to add, but the compiler
  is pointing out places in the code where there might be exploitable
  integer overflows.  Perhaps the member should be widened so that an
  overflow isn't possible, or pehaps an assert should be added or an
  exception thrown on overflow.

  The canvas, dbaccess, reportdesign, and slideshow modules use
  iterators such a ::std::find_if and ::std::count_if to repeatedly call
  functions using ::boost::bind whose args are all supposed to be
  references.  In some instances the code uses ::boost::cref() to
  convert expressions into references.  Recent clang objects if the
  argument to ::boost::cref() is not an lvalue.  A handful are
  trivivally fixable, but most are not.  In some cases it is not obvious
  if the value of the expression shouldn't be changing due to the
  actions of the function in the previous iteration, so calculating the
  expression once, storing the result in a temporary location and
  passing a reference to that location could result in stale data being
  used. In another case, a method is called that constructs a struct and
  fills it with a bunch of data from multiple class member values, and
  the struct is returned, a reference to that struct is created and that
  reference passed to the function.  It isn't obvious to me that some of
  those class members are not modified by the function, so the stale
  data issue is there, but also the memory for the struct is leaked
  because it is never destroyed.


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

Re: FreeBSD port status

[Don Lewis]

On 12 Mar, Matthias Seidel wrote:
> Hi Don,
> 
> thank you for your detailed report!
> 
> Most of the technical things are above my understanding. ;-)

Some of it is beyond mine, in particular the iterator stuff.  I'm also very
unfamiliar with that part of the code and have no idea how to test it
properly.
 
> But what I saw in the 4.1.14 development process was, that we have a big
> amount of code changes in trunk/AOO42X, that never got backported/released.

Yes.  The code and build framework in trunk/AOO42X is much better than
AOO41X.

> Normally, we should release it with AOO 4.2.0, but since that process is
> stagnating over years I would prefer to cherry-pick code into AOO41X
> (where possible).
> 
> I already made some commits (mostly optical changes):
> 
> https://github.com/apache/openoffice/compare/AOO4114-GA...AOO41X
> 
> And maybe we can get AOO42X in a stable condition in parallel?

Trying to cherry-pick a lot of this stuff back into AOO41X would be a
lot of work.  There are a lot of commits that would need to be
inventoried.  There are also a lot of interdependencies, so the
cherry-picks would have to be done in the right order.  Then there would
still likely be a bunch of merge conflicts that would need manual
intervention to resolve, with thie possibility of introducing bugs.

I see this as putting a lot of effort into something that is ultimately
a dead end.  I think it would be better in the long run to get 4.2.0 out
the door.

Something else that should be higher on the priority list is migrating
to a more modern Windows toolchain that has support for modern C.  We
spent too much effort on working around the limitations of our current
Windows compiler when importing new versions of bundled third-party
code.


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

Re: FreeBSD port status

[Don Lewis]

FYI, I do maintain a FreeBSD port of AOO42X and periodically update it
with newer snaphots of our code.  FreeBSD users can install binary
packages of it.  It was broken for quite a while, but I've gotten it
working again.



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

Re: FreeBSD port status

[Don Lewis]

On 11 Mar, Don Lewis wrote:
> I've had some time in the last couple of weeks to work on the FreeBSD
> port.  I was able to get 4.1.14 to build and updated the FreeBSD port to
> that version.  I committed the upgrade to the main branch of the FreeBSD
> ports tree on March 8. I merged the change to the current ports
> quarterly branch a short while ago, so mainstream users should see the
> new binary packages show up in the next several days.
> 
> For various reasons, I switched the FreeBSD port back to the bundled
> boost.  The FreeBSD port uses -std=gnu++98 mode to compile our code. One
> of the things I found is that even in that mode, our bundled boost tries
> to use some c++11 features, and recent versions of clang treat that as
> an error.  This can be fixed with a trivial patch, which I added to the
> FreeBSD port.  I plan to commit this fix to our source tree in the near
> future.
> 
> Another FreeBSD user found that our build is fragile, and can be broken
> if the build environment is not clean.  The problem is that the order of
> the directories in our include path is not safe.  We put the include
> directories for external dependencies like the libs for gtk ahead of
> internal and solver directories.  If one of the system include
> directories is /usr/local/include, then the build can pick up the system
> boost if it is installed on the machine.  The FreeBSD boost port has
> issues with gnu++98 mode.  This breaks both gbuild and dmake module
> builds of 4.1.x.  Gbuild is mostly fixed in trunk and 4.2.x, and on
> those branches so much has been converted to gbuild that I haven't seen
> the problem.  The modules left using dmake don't seem to both use boost
> and have problematic external dependencies.  I have patches for both the
> gbuild and dmake stuff, but the gbuild fix is only for the FreeBSD
> platform.  The dmake framework patch is generic, but I've only tested it
> on FreeBSD.
> 
> The FreeBSD port broke some time ago because of errors in some of the
> API comments in the xmerge java source.  We've fixed these in trunk and
> 4.2.x, but they are still broken in 4.1.x.  They have been flagged as
> errors during the build for a very long time, but it was only sometime
> last summer when they started getting treated as a fatal error by the
> FreeBSD build.  They are still flagged as errors, but they are no longer
> fatal. I have no idea what caused the behavior to change in either
> direction.
> 
> I also experimented a bit with c++11 mode and discovered that recent
> versions of clang are much less forgiving of questionable code in that
> mode as compared to the older versions of clang that I tried several
> years ago.  I ran into many things that broke the build:
> 
>   reinterpret_cast< some_type*>(NULL) is a compilation error.  These are
>   trivial to fix by switching to static_cast, but the modules where
>   these occur seem to use reinterpret_cast excessively.  I would be
>   surpised if there were more than a handful of locations in our code
>   where reinterpret_cast is the right choice.
> 
>   Constructors where the width of the initialization data is wider than
>   the width of the member being initialized break the build.  Recent
>   clang does not want to automatically narrow the data and wants an
>   explicit cast to be used.  The casts are easy to add, but the compiler
>   is pointing out places in the code where there might be exploitable
>   integer overflows.  Perhaps the member should be widened so that an
>   overflow isn't possible, or pehaps an assert should be added or an
>   exception thrown on overflow.

It looks like Damjan fixed a bunch of this stuff back in January in
a72d41dcd002e8c9b3d75696f0625302690e2d65 on trunk.  I was working with
AOO42X, which is why I didn't see the fixes.  The narrowing fixes were
done by adding casts, so any integer overflow issues are ignored, which
is the status quo when compiled without the casts.

>   The canvas, dbaccess, reportdesign, and slideshow modules use
>   iterators such a ::std::find_if and ::std::count_if to repeatedly call
>   functions using ::boost::bind whose args are all supposed to be
>   references.  In some instances the code uses ::boost::cref() to
>   convert expressions into references.  Recent clang objects if the
>   argument to ::boost::cref() is not an lvalue.  A handful are
>   trivivally fixable, but most are not.  In some cases it is not obvious
>   if the value of the expression shouldn't be changing due to the
>   actions of the function in the previous iteration, so calculating the
>   expression once, storing the result in a temporary location and
>   passing a reference to that location could result in stale data being
>   used. In another case

sot module build failures with recent gcc

[Don Lewis]

A FreeBSD user is trying to unbreak the ppc64 build and ran into an
issue with the sot module.  I dig into it pretty deeply and it looks to
me like a gcc bug.  It's reproducable in amd64.  It seems to affect
gcc10, gcc11, and gcc12 builds.  The build failure does not happen with
gcc9.

It is not limited to FreeBSD.  I get the same failure on Debian
bullseye:
 cc --version
cc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[ build LNK ] Library/libsot.so
/usr/bin/ld: 
/home/dl/aoo/openoffice/main/solver/4111/unxlngx6.pro/workdir/CxxObject/sot/source/sdstor/ucbstorage.o:
 in function `UCBStorage_Impl::Init()':
ucbstorage.cxx:(.text+0x72b4): undefined reference to `non-virtual thunk to 
cppu::WeakImplHelper1::acquire()'
collect2: error: ld returned 1 exit status


The problem appears to be that gcc is getting confused when compiling
line 1884 of ucbstorage.cxx.  It ends up trying to call the thunk to the
acquire() method of a non-existent class.  That thunk isn't defined, so
the linker bombs on the undefined symbol.

If I replace the-c flag with -S to get the assembler output:

Working version from gcc9:
.loc 2 1884 77 is_stmt 0 view .LVU7397
leaq48(%rsp), %rax
movq%rax, 16(%rsp)
movq16(%rsp), %rdi
leaq32(%rsp), %rax
movq%rax, 8(%rsp)
.LEHB557:
call_ZN10comphelper24getProcessServiceFactoryEv@PLT
.LVL3431:
.LEHE557:
.loc 2 1884 79 discriminator 1 view .LVU7398
movq48(%rsp), %r8


Broken version from newer gcc:
.loc 2 1884 77 view .LVU6791
leaq-176(%rbp), %r13
.LVL3116:
.LBB5707:
.LBB5706:
.LBB5705:
.loc 12 134 14 view .LVU6792
movq%rdi, -192(%rbp)
.loc 12 136 23 view .LVU6793
call_ZThn40_N4cppu15WeakImplHelper1IN3com3sun4star2io12XInputStreamE
E7acquireEv

.loc 12 xxx xxx refers to the Reference() template in
com/sun/star/uno/Reference.hxx lines 134-136, which calls acquire().


It would be nice if someone could put together a trimmed test case and
file a gcc bug report.

I don't have any good ideas about patching the source to work around the
bug while waiting for a gcc fix.


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


Also, the buildbot errors are kind of random:

<https://ci.apache.org/builders/openoffice-fbsd-nightly/builds/0/steps/build%20--all/logs/stdio>
fails coinmp.

<https://ci.apache.org/builders/openoffice-fbsd-nightly/builds/1/steps/build%20--all/logs/stdio>
fails curl.

<https://ci.apache.org/builders/openoffice-fbsd-nightly/builds/2/steps/build%20--all/logs/stdio>
fails coinmp.

<https://ci.apache.org/builders/openoffice-fbsd-nightly/builds/3/steps/build%20--all/logs/stdio>
fails coinmp.

<https://ci.apache.org/builders/openoffice-fbsd-nightly/builds/4/steps/build%20--all/logs/stdio
fails nss.

The build order seems to vary from run to run, so maybe all three are
broken and we're just seeing the first failure.


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

Just for giggles, I tried "build --from nss" and got this:

make[2]: Entering directory 
'/tmp/openoffice/aoo-4.2.0/main/nss/unxfbsdx.pro/misc/build/nss-3.14.4/mozilla/security/coreconf/nsinstall'
gcc -o out/nsinstall.o -c -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD 
-DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE 
-D_REENTRANT -DUSE_UTIL_DIRECTLY -I/usr/X11R6/include 
-I../../../dist/out/include -I../../../dist/public/coreconf 
-I../../../dist/private/coreconf  nsinstall.c
gmake[2]: gcc: Command not found
../../coreconf/rules.mk:389: recipe for target 'out/nsinstall.o' failed

It shouldn't be trying to use gcc, which isn't installed here.


I also tried "build --from curl" and it seemed to build properly.


-
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 >>>> <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 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=revision&revision=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 
  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 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=revision&revision=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
>>
>> //-
>>
>> ...
> 
>> ...
>> //-
>>
>> #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=revision&revision=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

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:

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

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 
  ^
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/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 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 
>>^
>> 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/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_P

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]

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: 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::Reference
>  
> const&, com::sun::star::uno::Reference 
> 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:



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

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

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

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

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: 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: Release Manager for 4.2.0?

[Don Lewis]

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

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.

The versions of openssl and curl badly need updating for the same
reason, and there is one CVE for serf.

There is a CVE for raptor-1.4.18, but I believe there was a cherry
picked patch commited for that.

There are likely to be vulnerabilites in the bundled version of
silgraphite, but it has been unmaintained upstream for quite some time.
Ideally we would switch to Graphite2, but the API is radically different
and this looks difficult.  The unattractive alternative is to look at
the additional sanity checks added in recent Graphite2 commits and try
to retrofit those into silgraphite.


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

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

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

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

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

Re: Buildbots update

[Don Lewis]

On 24 Jul, Damjan Jovanovic wrote:
> On Fri, Jul 22, 2016 at 9:39 PM, Don Lewis  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

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

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: 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: 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: 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: Officially releasing a patch for CVE-2016-1513

[Don Lewis]

On 24 Jul, Dennis E. Hamilton wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> You're right that different builds by others who look to just extract
> the shared library will likely end up with a different binary of that
> library.  For a binary distribution from any origin that has the patch
> compiled-in, I would think something like the static string might be
> helpful.  If we do that in the AOO4121 tag, we'll have to redo the
> patched libraries we've already built.  I was hoping we could avoid
> that and stick with ones we have done some testing on already.
> 
> Is what we're planning enough?

I think that should be OK.


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

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

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

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

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

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

upgrading bundled openssl

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

-
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: 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: branches/gbuild-reintegration merged

[Don Lewis]

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.


-
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: 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: 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: 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&view=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: 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&view=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: 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: 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: [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: [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  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]

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

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