Re: New volunteer

[Damjan Jovanovic]

Hi Nolan

Welcome to Apache OpenOffice! We appreciate the offer and you are
welcome to help with development.

What is your previous experience? Do you need any help getting started?

Thank you
Damjan


On Sun, Jan 31, 2016 at 10:43 PM, Nolan  wrote:
> Hi I am Nolan i'm from NC and I want to help code!
>

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

Buildbots update

[Damjan Jovanovic]

Hi

Most of the common problems with the buildbots have been fixed:
* The Windows buildbots were failing to determine the SVN revision
being built, showing "UNKNOWN". This was fixed by running the "svn
info" command under Cygwin, as the Windows build bots do not have the
Windows version of SVN installed, only a Cygwin one.
* Many builds were failing because ./bootstrap couldn't download some
dependencies. Now we run it twice, and abort the build if both failed.
* SVN checkout was intermittently failing on many buildbots, because
buildbot uses hardcoded and too short 120 second timeouts when
deleting the massive previous build directory, and when copying the
checked out source to the new build directory. After much testing, I
changed all the *nix buildbots to a slower but extremely resilient
option, separately deleting the old SVN directory, doing a fresh SVN
checkout, deleting the old build directory, and copying the SVN
directory to make a new build directory, each with a very long
timeout.

All the *nix buildbots are now green and should be building 100% reliably.

BTW after committing to our buildbot script at
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/openofficeorg.conf,
you'll know the buildbot is using your changes when all the IRC bots
(one of which is ooo-bot) in #asftest on Freenode disconnect and
reconnect, which happens about 5 minutes after you commit.

Sadly Windows is more broken than ever :-(. I've been told by infra
that the apr problem happens because build.pl keeps
ext_libraries/apr/wntmsci12.pro/misc/build/apr-1.4.5/Makefile.win open
after the build is over, breaking the next build. Having read build.pl
a bit, I suspect the give_second_chance function which tries to re-run
make if the build fails on Windows, may be involved. However we now
have a new problem, where aoo-win7 hangs during the build, seemingly
while delivering sc :-(.

Otherwise:
* Infra was doing some work on the
https://ci.apache.org/projects/openoffice/index.html website but it's
still not using our changes in SVN.
* The buildbots shouldn't just be building (which just proves the code
compiles on that platform and the unit tests all pass), but also
collecting results from qa tests.

Damjan

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

./bootstrap changes

[Damjan Jovanovic]

Hi

I've recently changed main/bootstrap and main/solenv/bin/
download_external_dependencies.pl to fail, exiting with an error code and
printing an error message, if dependencies could not be downloaded from any
available URL.

This is because I observed a large number of build failures on the
buildbots where ./bootstrap failed to download a dependency, and later on
building that dependency or a module relying on that dependency fails.

Additionally, on the buildbots I've made ./bootstrap always run twice,
ignoring failures the first time so that we try to download dependencies
again, with failure the second time aborting the entire build (so we don't
waste time on a build that's doomed anyway). This retrying has already
helped in at least https://ci.apache.org/builders/aoo-win7/builds/181
(which failed later on for other reasons).

Damjan

Re: Norwegian translation for website

[Jan Høydahl]

Hi

Looks like the site builds run again?
Can someone try to re-publish the /no-test site?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 1. feb. 2016 kl. 15.59 skrev Jan Høydahl :
> 
> Any news on this? I see now a “hello” web page up for 
> http://www.openoffice.org/no-test/
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
>> 25. jan. 2016 kl. 23.06 skrev Marcus :
>> 
>> Thanks for testing. I've ping'ed Daniel again for help. Let's see if he can 
>> help us also with this.
>> 
>> Marcus
>> 
>> 
>> 
>> Am 01/25/2016 11:01 PM, schrieb Andrea Pescetti:
>>> On 23/01/2016 Marcus wrote:
 However, the new dir "no-test/" is not going to staging [1]. I can do
 changes in my CMS working directory or from the command line from my
 local PC but it's not going to the staging build - or the production
 build [2].
 The same when committing changes in already existing files and dirs.
>>> 
>>> I remember that I had problems also last time the CMS was restored.
>>> Namely, I had updated the logo but it wouldn't show up. And I had to
>>> manually change it again for the CMS to pick up the update. It seems you
>>> have already done so though.
>>> 
>>> I have just tried a forced republish and then I tried adding the
>>> templates under templates/; after doing this, I republished but with no
>>> results.
>>> 
>>> On the other side, I confirm that my previous changes to
>>> http://www.openoffice.org/eu/ (where I uploaded the new Basque
>>> translation) are not shown either. So this looks more a general CMS
>>> problem than something specific to the no-test directory.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 


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

Re: Building on Windows

[Patricia Shanahan]

I have experienced a major step backwards. My build attempts all fail:

==
$ build --All
build -- version: 275224


=
Building module instsetoo_native
=

Entering 
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages


Usage:
dmake [-P#] [-{f|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value 
...]

  [-v[cdfimrtw]] [-m[trae]] [-ABcdeEghiknpqrsStTuVxX] [target ...]
ERROR: error 65280 occurred while making 
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages

==

This persists despite a clean checkout and configure.



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

Re: Norwegian translation for website

[Marcus]

There was no fix provided so far. I've now opened a ticket for Infra [1] 
to make it more visible.


I'm very sorry for the delay. Normally this doesn't take so long to show 
up on the productions server.


[1] https://issues.apache.org/jira/browse/INFRA-11247

Marcus



Am 02/10/2016 09:40 PM, schrieb Jan Høydahl:

Hi

Looks like the site builds run again?
Can someone try to re-publish the /no-test site?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


1. feb. 2016 kl. 15.59 skrev Jan Høydahl:

Any news on this? I see now a “hello” web page up for 
http://www.openoffice.org/no-test/

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


25. jan. 2016 kl. 23.06 skrev Marcus:

Thanks for testing. I've ping'ed Daniel again for help. Let's see if he can 
help us also with this.

Marcus



Am 01/25/2016 11:01 PM, schrieb Andrea Pescetti:

On 23/01/2016 Marcus wrote:

However, the new dir "no-test/" is not going to staging [1]. I can do
changes in my CMS working directory or from the command line from my
local PC but it's not going to the staging build - or the production
build [2].
The same when committing changes in already existing files and dirs.


I remember that I had problems also last time the CMS was restored.
Namely, I had updated the logo but it wouldn't show up. And I had to
manually change it again for the CMS to pick up the update. It seems you
have already done so though.

I have just tried a forced republish and then I tried adding the
templates under templates/; after doing this, I republished but with no
results.

On the other side, I confirm that my previous changes to
http://www.openoffice.org/eu/ (where I uploaded the new Basque
translation) are not shown either. So this looks more a general CMS
problem than something specific to the no-test directory.


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

Re: Building on Windows

[Patricia Shanahan]

Thanks. Silly typo, when I've typed "build --all" dozens of times over 
the last couple of weeks.


On 2/10/2016 2:22 PM, Damjan Jovanovic wrote:

I can reproduce that. The "--All" needs to be in lowercase, ie. "build --all".

On Wed, Feb 10, 2016 at 11:20 PM, Patricia Shanahan  wrote:

I have experienced a major step backwards. My build attempts all fail:

==
$ build --All
build -- version: 275224


=
Building module instsetoo_native
=

Entering
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages

Usage:
dmake [-P#] [-{f|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value
...]
   [-v[cdfimrtw]] [-m[trae]] [-ABcdeEghiknpqrsStTuVxX] [target ...]
ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages
==

This persists despite a clean checkout and configure.




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



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



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

Re: Building on Windows

[Damjan Jovanovic]

I can reproduce that. The "--All" needs to be in lowercase, ie. "build --all".

On Wed, Feb 10, 2016 at 11:20 PM, Patricia Shanahan  wrote:
> I have experienced a major step backwards. My build attempts all fail:
>
> ==
> $ build --All
> build -- version: 275224
>
>
> =
> Building module instsetoo_native
> =
>
> Entering
> /cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages
>
> Usage:
> dmake [-P#] [-{f|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value
> ...]
>   [-v[cdfimrtw]] [-m[trae]] [-ABcdeEghiknpqrsStTuVxX] [target ...]
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages
> ==
>
> This persists despite a clean checkout and configure.
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

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

Re: Buildbots update

[Kay Schenk]

On 02/10/2016 09:41 AM, Damjan Jovanovic wrote:
> Hi
> 
> Most of the common problems with the buildbots have been fixed:
> * The Windows buildbots were failing to determine the SVN revision
> being built, showing "UNKNOWN". This was fixed by running the "svn
> info" command under Cygwin, as the Windows build bots do not have the
> Windows version of SVN installed, only a Cygwin one.
> * Many builds were failing because ./bootstrap couldn't download some
> dependencies. Now we run it twice, and abort the build if both failed.
> * SVN checkout was intermittently failing on many buildbots, because
> buildbot uses hardcoded and too short 120 second timeouts when
> deleting the massive previous build directory, and when copying the
> checked out source to the new build directory. After much testing, I
> changed all the *nix buildbots to a slower but extremely resilient
> option, separately deleting the old SVN directory, doing a fresh SVN
> checkout, deleting the old build directory, and copying the SVN
> directory to make a new build directory, each with a very long
> timeout.

Thanks again for your persistent work on the buildbots. I know
learning about the quirks was time consuming and rather frustrating.

> 
> All the *nix buildbots are now green and should be building 100% reliably.

YAY!

> 
> BTW after committing to our buildbot script at
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/openofficeorg.conf,
> you'll know the buildbot is using your changes when all the IRC bots
> (one of which is ooo-bot) in #asftest on Freenode disconnect and
> reconnect, which happens about 5 minutes after you commit.

OK, good to know.

> 
> Sadly Windows is more broken than ever :-(. I've been told by infra
> that the apr problem happens because build.pl keeps
> ext_libraries/apr/wntmsci12.pro/misc/build/apr-1.4.5/Makefile.win open
> after the build is over, breaking the next build. Having read build.pl
> a bit, I suspect the give_second_chance function which tries to re-run
> make if the build fails on Windows, may be involved. However we now
> have a new problem, where aoo-win7 hangs during the build, seemingly
> while delivering sc :-(.

OK, thanks for the full story.

> 
> Otherwise:
> * Infra was doing some work on the
> https://ci.apache.org/projects/openoffice/index.html website but it's
> still not using our changes in SVN.
> * The buildbots shouldn't just be building (which just proves the code
> compiles on that platform and the unit tests all pass), but also
> collecting results from qa tests.
> 
> Damjan

Again thank you for all your wonderful work. Maybe others can help
with the Windows hanging problem.


-- 

MzK

"Though no one can go back and make a brand new start,
 anyone can start from now and make a brand new ending."
-- Carl Bard

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

Re: Building on Windows

[Patricia Shanahan]

Thanks. I'll take it for a test drive tomorrow.

On 2/10/2016 3:57 PM, Damjan Jovanovic wrote:

icu supports building on Cygwin using Cygwin's make, but for some bizarre
reason AOO builds it with MSVC's nmake using makefiles generated by a Perl
script and even completely bypassing ./configure (makefile.mk has
CONFIGURE_ACTION+= $(PERL) ..$/..$/..$/..$/..$/createmak.pl
..$/..$/..$/..$/..$/createmak.cfg .). It could not have been easy to set
that up, nor does the nmake build parallelize at all, which is why icu
wastes 5 minutes building while using only a single thread, so you have to
wonder why it was done that way.

Building with mingw or building on any other platform does use ./configure
and GNU make instead, which explains why we only see this bug with MSVC.

Anyway I think I've hacked icu into working. In allinone.sln I've made
layoutex project depend on the i18n project containing icuin.lib, and the
Perl script should convert that dependency into the makefiles it creates.
So far icu has been rebuilt 10 times with this patch (attached), succeeding
every time, so please test it and see if it works for you as well.

Damjan

On Tue, Feb 9, 2016 at 7:51 PM, Patricia Shanahan  wrote:


I have already done some of this. The key difference between failing and
non-failing is whether layoutex is built early or later in the build. See
the attached files for sample build outputs.

I believe layoutex has a dependency on icuin.lib that is not properly
declared in the makefile etc., allowing layoutex to be built too soon. If
so, the best fix would be to declare the dependency, but I don't know
enough about the dmake and configuration stuff to make that change without
some study first.

Patricia


On 2/9/2016 9:40 AM, Damjan Jovanovic wrote:


The icu module has a complicated build with scripts generating
makefiles...

I am not sure what approach to even take debugging this, but some ideas
might be:
* make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
copy of one that doesn't, then diff the files to see what's different
* compare build logs with it working and not working, to see what steps
differ (eg. build order of some files might be different)
* try and follow the makefile to understand the problem analytically; my
first try didn't get me far
* give up completely, and just hack it. Make a loop in build.pl that just
keeps cleaning and rebuilding the module. If it builds 50% of the time,
with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1 in
2^20 will fail, etc. Something like this might already have been tried in
the past, as build.pl contains the following code which is only run on
Windows:

sub give_second_chance {
  my $pid = shift;
  # A malicious hack for mysterious windows problems - try 2 times
  # to run dmake in the same directory if errors occurs
  my $child_nick = $processes_hash{$pid};
  $running_children{$folders_hashes{$child_nick}}--;
  delete $processes_hash{$pid};
  start_child($child_nick, $folders_hashes{$child_nick});
};


On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:

My next step is to try to get rid of the intermittent failure of the icu

build. It seems to be the one thing standing between me a repeatable
unattended build. If you know anything about its cause, please let me
know.

Here is a typical failure output:

Generating Code...
  link.exe @C:\cygwin32\tmp\nm2E74.tmp
 Creating library .\..\..\lib\icule.lib and object
.\..\..\lib\icule.exp
  if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
  copy ".\LEFontInstance.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEGlyphFilter.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEGlyphStorage.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEInsertionList.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LELanguages.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEScripts.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LESwaps.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LETypes.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LayoutEngine.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\loengine.h" ..\..\include\layout
  1 file(s) copied.
  cd "..\allinone"
  cd "C:\OpenOfficeDev\Trunk\main\icu\wntmsci12.pro
\misc\build\icu\source\allinone\..\layoutex"
  C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe /   /F
layoutex.mak EXCEPTIONSWITCH="-EHa -Zc:wchar_t-"

Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

  if not exist ".\Release/" mkdir ".\Release"
  rc.exe /l 0x409 /fo".\Release\layoutex.res" /i 

Chemnitzer Linux-Tage 2016

[RA Stehmann]

Hallo,

am 19. und 20. März 2016 finden im Zentralen Hörsaal- und
Seminar-Gebäude der Technischen Universität Chemnitz, Reichenhainer
Straße 90, 09125 Chemnitz, wieder die Chemnitzer Linux-Tage statt.

Auch Apache OpenOffice wird wieder mit einem Stand vertreten sein. Wir
vom Standpersonal würden uns freuen, Euch am Stand begrüßen zu dürfen.

Zugleich nehmen wir die Gelegenheit wahr, Euch und dem Publikum das neue
Apache-Logo zu präsentieren.

Wir sehen uns in Chemnitz!

Gruß
Michael



signature.asc
Description: OpenPGP digital signature

Chemnitzer Linux-Tage 2016

[RA Stehmann]

Hello,

the "Chemnitzer Linux-Tage" will be on 19th and 20th of March 2016. It's
one of the largest Free Software events in Central Europe.

Apache OpenOffice will have a booth there.

We will also present the new Apache logo.

Kind regards
Michael



signature.asc
Description: OpenPGP digital signature

Re: AOO build system upgrades

[Kay Schenk]

On 02/09/2016 03:42 PM, Patricia Shanahan wrote:
> On 2/9/2016 2:11 PM, Kay Schenk wrote:
> ...
>> == HELP, TOO MANY MAKEFILES ==
>>
>> I started looking at what's been done so far. And, due to the fact
>> that dmake also uses makefiles, what's the correct way to invoke GNU
>> make for a build? It looks like the "main" makefile for what's been
>> migrated so far is /main/Module_ooo.mk (?)
>>
>> Is there any way to test our actual make file changes on a per
>> module basis?
> ...
> 
> From
> http://www.gnu.org/software/make/manual/make.html#Makefile-Arguments
> 
> =
> 9.1 Arguments to Specify the Makefile
> 
> The way to specify the name of the makefile is with the ‘-f’ or
> ‘--file’ option (‘--makefile’ also works). For example, ‘-f altmake’
> says to use the file altmake as the makefile.
> 
> If you use the ‘-f’ flag several times and follow each ‘-f’ with an
> argument, all the specified files are used jointly as makefiles.
> 
> If you do not use the ‘-f’ or ‘--file’ flag, the default is to try
> GNUmakefile, makefile, and Makefile, in that order, and use the
> first of these three which exists or can be made (see Writing
> Makefiles).
> ==
> 
> It looks as though you can call your file "GNUmakefile" and it will
> be used even if there is also a "makefile" or "Makefile". You could
> alternatively pick a different naming convention and use "-f", but I
> recommend against it. Calling your file "GNUmakefile" will give
> subsequent developers a very useful clue.
> 
> Patricia

Thanks for the response Patricia. I know we  make use of recursive
makefiles, but I just couldn't see where the top most makefile was
for the gnu make (gbuild) scenario was for some reason.

The wiki page on build system analysis:
https://wiki.openoffice.org/wiki/Build_System_Analysis

gives  instructions for proceeding but omitted the important factor
on what the name of the topmost makefile  was. In the end, ta! da!,
it is in fact named "GNUmakefile" in trunk/main. ( I guess I'm
blind!) So, all good for now. I will update the wiki page with what
I've found so far.


-- 

MzK

"Though no one can go back and make a brand new start,
 anyone can start from now and make a brand new ending."
-- Carl Bard

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

Re: Building on Windows

[Damjan Jovanovic]

icu supports building on Cygwin using Cygwin's make, but for some bizarre
reason AOO builds it with MSVC's nmake using makefiles generated by a Perl
script and even completely bypassing ./configure (makefile.mk has
CONFIGURE_ACTION+= $(PERL) ..$/..$/..$/..$/..$/createmak.pl
..$/..$/..$/..$/..$/createmak.cfg .). It could not have been easy to set
that up, nor does the nmake build parallelize at all, which is why icu
wastes 5 minutes building while using only a single thread, so you have to
wonder why it was done that way.

Building with mingw or building on any other platform does use ./configure
and GNU make instead, which explains why we only see this bug with MSVC.

Anyway I think I've hacked icu into working. In allinone.sln I've made
layoutex project depend on the i18n project containing icuin.lib, and the
Perl script should convert that dependency into the makefiles it creates.
So far icu has been rebuilt 10 times with this patch (attached), succeeding
every time, so please test it and see if it works for you as well.

Damjan

On Tue, Feb 9, 2016 at 7:51 PM, Patricia Shanahan  wrote:

> I have already done some of this. The key difference between failing and
> non-failing is whether layoutex is built early or later in the build. See
> the attached files for sample build outputs.
>
> I believe layoutex has a dependency on icuin.lib that is not properly
> declared in the makefile etc., allowing layoutex to be built too soon. If
> so, the best fix would be to declare the dependency, but I don't know
> enough about the dmake and configuration stuff to make that change without
> some study first.
>
> Patricia
>
>
> On 2/9/2016 9:40 AM, Damjan Jovanovic wrote:
>
>> The icu module has a complicated build with scripts generating
>> makefiles...
>>
>> I am not sure what approach to even take debugging this, but some ideas
>> might be:
>> * make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
>> copy of one that doesn't, then diff the files to see what's different
>> * compare build logs with it working and not working, to see what steps
>> differ (eg. build order of some files might be different)
>> * try and follow the makefile to understand the problem analytically; my
>> first try didn't get me far
>> * give up completely, and just hack it. Make a loop in build.pl that just
>> keeps cleaning and rebuilding the module. If it builds 50% of the time,
>> with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1 in
>> 2^20 will fail, etc. Something like this might already have been tried in
>> the past, as build.pl contains the following code which is only run on
>> Windows:
>>
>> sub give_second_chance {
>>  my $pid = shift;
>>  # A malicious hack for mysterious windows problems - try 2 times
>>  # to run dmake in the same directory if errors occurs
>>  my $child_nick = $processes_hash{$pid};
>>  $running_children{$folders_hashes{$child_nick}}--;
>>  delete $processes_hash{$pid};
>>  start_child($child_nick, $folders_hashes{$child_nick});
>> };
>>
>>
>> On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:
>>
>> My next step is to try to get rid of the intermittent failure of the icu
>>> build. It seems to be the one thing standing between me a repeatable
>>> unattended build. If you know anything about its cause, please let me
>>> know.
>>>
>>> Here is a typical failure output:
>>>
>>> Generating Code...
>>>  link.exe @C:\cygwin32\tmp\nm2E74.tmp
>>> Creating library .\..\..\lib\icule.lib and object
>>> .\..\..\lib\icule.exp
>>>  if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
>>> ..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
>>>  copy ".\LEFontInstance.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LEGlyphFilter.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LEGlyphStorage.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LEInsertionList.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LELanguages.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LEScripts.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LESwaps.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LETypes.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LayoutEngine.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\loengine.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  cd "..\allinone"
>>>  cd "C:\OpenOfficeDev\Trunk\main\icu\wntmsci12.pro
>>> \misc\build\icu\source\allinone\..\layoutex"
>>>  C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe /   /F
>>> layoutex.mak EXCEPTIONSWITCH="-EHa -Zc:wchar_t-"
>>>
>>> Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
>>> Copyright (C) Microsoft Corporation.