Re: Buildbots

[Carl Marcum]

Hi Gavin,

On 11/16/21 7:15 AM, Gavin McDonald wrote:

Hi Matthias,

On Tue, Nov 16, 2021 at 12:32 PM Matthias Seidel 
wrote:


Hi Gavin,

Am 16.11.21 um 09:37 schrieb Gavin McDonald:

Hi All.

Ok so I am making progress.

The nightly x64 build is running fine. as are the rat builds.
I'll get the 41 branch added today - should we also do a 42 branch build?

Thanks!

It would be ideal to have all branches (trunk/AOO42X/AOO41X).


Yep no problem



As for the win10 builds I am working on those now.

I am at a stage in the win10 build where it wants dlls and exe files
(listed below) from an
'external' directory located on the machine but outside of the build
itself. These get copied in
during a build step.




No objection against copying these files from whatever location. They
haven't changed in the last years but it is always good when we can
access them.

If you take the files from the old buildbot everything should be the
correct version.

If you have questions about the Windows builds, feel free to contact me.


Perfect, new 'openoffice-externals' repository created, I'll put them in
there
and have the build(s) pull them in from there.




Regards,

Matthias


/

As can be seen at:


https://ci.apache.org/builders/openoffice-win7/builds/737/steps/externals/logs/stdio

On Sun, Nov 14, 2021 at 9:54 PM Carl Marcum  wrote:


Hi Gavin,

On 11/14/21 2:16 PM, Gavin McDonald wrote:

Hi All,

As the current Buildbots arent really working, nodes offline etc, I

thought

this would be the best time to migrate your builds over to our newer
replacement
buildbot 3.2 over at ci2.apache.org .

I'll do my best to get them all running as passing as best they can,

and

will update this thread with any questions or messages.

My first query is seeing as we have no more i386 or FreeBSD

agents/nodes,

I'll probably just go ahead and remove those from the new config file.

HTH


I just realized I had somehow missed your original email about migrating
andwas discussing getting with you.

Thanks for working on this.

Let us know if you have any questions.

Best regards,
Carl





Can you point me to info on the tech stack used for the linux64 
buildbots like OS platform and how it works.


I'd like to look at future changes that could be made and I'm not 
suggesting changing anything your doing now:


A couple questions:
Is it possible to use docker containers to build with?

We have a build verification test suite using JUnit but it requires a GUI.
Are there any options to add something like this to a workflow?

Thanks again for working on this!
Best regards,
Carl

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

Re: Buildbots

[Gavin McDonald]

Hi Matthias,

On Tue, Nov 16, 2021 at 12:32 PM Matthias Seidel 
wrote:

> Hi Gavin,
>
> Am 16.11.21 um 09:37 schrieb Gavin McDonald:
> > Hi All.
> >
> > Ok so I am making progress.
> >
> > The nightly x64 build is running fine. as are the rat builds.
> > I'll get the 41 branch added today - should we also do a 42 branch build?
>
> Thanks!
>
> It would be ideal to have all branches (trunk/AOO42X/AOO41X).
>

Yep no problem


> >
> > As for the win10 builds I am working on those now.
> >
> > I am at a stage in the win10 build where it wants dlls and exe files
> > (listed below) from an
> > 'external' directory located on the machine but outside of the build
> > itself. These get copied in
> > during a build step.
> >
> 
>
> No objection against copying these files from whatever location. They
> haven't changed in the last years but it is always good when we can
> access them.
>
> If you take the files from the old buildbot everything should be the
> correct version.
>
> If you have questions about the Windows builds, feel free to contact me.
>

Perfect, new 'openoffice-externals' repository created, I'll put them in
there
and have the build(s) pull them in from there.



> Regards,
>
>Matthias
>
> >
> > /
> >
> > As can be seen at:
> >
> https://ci.apache.org/builders/openoffice-win7/builds/737/steps/externals/logs/stdio
> >
> > On Sun, Nov 14, 2021 at 9:54 PM Carl Marcum  wrote:
> >
> >> Hi Gavin,
> >>
> >> On 11/14/21 2:16 PM, Gavin McDonald wrote:
> >>> Hi All,
> >>>
> >>> As the current Buildbots arent really working, nodes offline etc, I
> >> thought
> >>> this would be the best time to migrate your builds over to our newer
> >>> replacement
> >>> buildbot 3.2 over at ci2.apache.org .
> >>>
> >>> I'll do my best to get them all running as passing as best they can,
> and
> >>> will update this thread with any questions or messages.
> >>>
> >>> My first query is seeing as we have no more i386 or FreeBSD
> agents/nodes,
> >>> I'll probably just go ahead and remove those from the new config file.
> >>>
> >>> HTH
> >>>
> >> I just realized I had somehow missed your original email about migrating
> >> andwas discussing getting with you.
> >>
> >> Thanks for working on this.
> >>
> >> Let us know if you have any questions.
> >>
> >> Best regards,
> >> Carl
> >>
> >
>
>

-- 

*Gavin McDonald*
Systems Administrator
ASF Infrastructure Team

Re: Buildbots

[Matthias Seidel]

Hi Gavin,

Am 16.11.21 um 09:37 schrieb Gavin McDonald:
> Hi All.
>
> Ok so I am making progress.
>
> The nightly x64 build is running fine. as are the rat builds.
> I'll get the 41 branch added today - should we also do a 42 branch build?

Thanks!

It would be ideal to have all branches (trunk/AOO42X/AOO41X).

>
> As for the win10 builds I am working on those now.
>
> I am at a stage in the win10 build where it wants dlls and exe files
> (listed below) from an
> 'external' directory located on the machine but outside of the build
> itself. These get copied in
> during a build step.
>
> These files have been previously uploaded manually to the buildbot
> node/agent. I'd like to stop that
> practice; and change the build so that it pulls them in from a repository
> instead. We can create a new
> gitr repo called openoffice-externals and put them in there. This method
> has the added advantage that
> the project can then manage these externals themselves,
> adding/updating/deleting/whatever from the
> repo and the build will pull those in each time.
>
> Thoughts? My only query really was one of whether or not these libraries
> should not be available to the
> public, (I don't see why) in which case I would have to rethink this
> strategy. If I can get replies ASAP on
> this please so that I can continue to migrate the builds.
>
> Thanks
>
> /
>
> '/cygdrive/e/slave14/aoo-win7/external/gdiplus/gdiplus.dll'
> '/cygdrive/e/slave14/aoo-win7/external/dbghelp/dbghelp.dll'
> '/cygdrive/e/slave14/aoo-win7/external/msm90/Microsoft_VC90_CRT_x86.msm'
> '/cygdrive/e/slave14/aoo-win7/external/msm90/policy_9_0_Microsoft_VC90_CRT_x86.msm'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp100/msvcr100.dll'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp71'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp71/msvcp71.dll'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp71/msvcr71.dll'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp80'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp80/msvcp80.dll'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp80/msvcr80.dll'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp90/Microsoft.VC90.CRT.manifest'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp90/msvcm90.dll'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp90/msvcp90.dll'
> '/cygdrive/e/slave14/aoo-win7/external/msvcp90/msvcr90.dll'
> '/cygdrive/e/slave14/aoo-win7/external/vcredist/vcredist_x64.exe'
> '/cygdrive/e/slave14/aoo-win7/external/vcredist/vcredist_x86.exe'
> '/cygdrive/e/slave14/aoo-win7/external/vcredist/old'
> '/cygdrive/e/slave14/aoo-win7/external/vcredist/old/vcredist_x64.exe'
> '/cygdrive/e/slave14/aoo-win7/external/vcredist/old/vcredist_x86.exe'

No objection against copying these files from whatever location. They
haven't changed in the last years but it is always good when we can
access them.

If you take the files from the old buildbot everything should be the
correct version.

If you have questions about the Windows builds, feel free to contact me.

Regards,

   Matthias

>
> /
>
> As can be seen at:
> https://ci.apache.org/builders/openoffice-win7/builds/737/steps/externals/logs/stdio
>
> On Sun, Nov 14, 2021 at 9:54 PM Carl Marcum  wrote:
>
>> Hi Gavin,
>>
>> On 11/14/21 2:16 PM, Gavin McDonald wrote:
>>> Hi All,
>>>
>>> As the current Buildbots arent really working, nodes offline etc, I
>> thought
>>> this would be the best time to migrate your builds over to our newer
>>> replacement
>>> buildbot 3.2 over at ci2.apache.org .
>>>
>>> I'll do my best to get them all running as passing as best they can, and
>>> will update this thread with any questions or messages.
>>>
>>> My first query is seeing as we have no more i386 or FreeBSD agents/nodes,
>>> I'll probably just go ahead and remove those from the new config file.
>>>
>>> HTH
>>>
>> I just realized I had somehow missed your original email about migrating
>> andwas discussing getting with you.
>>
>> Thanks for working on this.
>>
>> Let us know if you have any questions.
>>
>> Best regards,
>> Carl
>>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Buildbots

[Gavin McDonald]

Hi All.

Ok so I am making progress.

The nightly x64 build is running fine. as are the rat builds.
I'll get the 41 branch added today - should we also do a 42 branch build?

As for the win10 builds I am working on those now.

I am at a stage in the win10 build where it wants dlls and exe files
(listed below) from an
'external' directory located on the machine but outside of the build
itself. These get copied in
during a build step.

These files have been previously uploaded manually to the buildbot
node/agent. I'd like to stop that
practice; and change the build so that it pulls them in from a repository
instead. We can create a new
gitr repo called openoffice-externals and put them in there. This method
has the added advantage that
the project can then manage these externals themselves,
adding/updating/deleting/whatever from the
repo and the build will pull those in each time.

Thoughts? My only query really was one of whether or not these libraries
should not be available to the
public, (I don't see why) in which case I would have to rethink this
strategy. If I can get replies ASAP on
this please so that I can continue to migrate the builds.

Thanks

/

'/cygdrive/e/slave14/aoo-win7/external/gdiplus/gdiplus.dll'
'/cygdrive/e/slave14/aoo-win7/external/dbghelp/dbghelp.dll'
'/cygdrive/e/slave14/aoo-win7/external/msm90/Microsoft_VC90_CRT_x86.msm'
'/cygdrive/e/slave14/aoo-win7/external/msm90/policy_9_0_Microsoft_VC90_CRT_x86.msm'
'/cygdrive/e/slave14/aoo-win7/external/msvcp100/msvcr100.dll'
'/cygdrive/e/slave14/aoo-win7/external/msvcp71'
'/cygdrive/e/slave14/aoo-win7/external/msvcp71/msvcp71.dll'
'/cygdrive/e/slave14/aoo-win7/external/msvcp71/msvcr71.dll'
'/cygdrive/e/slave14/aoo-win7/external/msvcp80'
'/cygdrive/e/slave14/aoo-win7/external/msvcp80/msvcp80.dll'
'/cygdrive/e/slave14/aoo-win7/external/msvcp80/msvcr80.dll'
'/cygdrive/e/slave14/aoo-win7/external/msvcp90/Microsoft.VC90.CRT.manifest'
'/cygdrive/e/slave14/aoo-win7/external/msvcp90/msvcm90.dll'
'/cygdrive/e/slave14/aoo-win7/external/msvcp90/msvcp90.dll'
'/cygdrive/e/slave14/aoo-win7/external/msvcp90/msvcr90.dll'
'/cygdrive/e/slave14/aoo-win7/external/vcredist/vcredist_x64.exe'
'/cygdrive/e/slave14/aoo-win7/external/vcredist/vcredist_x86.exe'
'/cygdrive/e/slave14/aoo-win7/external/vcredist/old'
'/cygdrive/e/slave14/aoo-win7/external/vcredist/old/vcredist_x64.exe'
'/cygdrive/e/slave14/aoo-win7/external/vcredist/old/vcredist_x86.exe'

/

As can be seen at:
https://ci.apache.org/builders/openoffice-win7/builds/737/steps/externals/logs/stdio

On Sun, Nov 14, 2021 at 9:54 PM Carl Marcum  wrote:

> Hi Gavin,
>
> On 11/14/21 2:16 PM, Gavin McDonald wrote:
> > Hi All,
> >
> > As the current Buildbots arent really working, nodes offline etc, I
> thought
> > this would be the best time to migrate your builds over to our newer
> > replacement
> > buildbot 3.2 over at ci2.apache.org .
> >
> > I'll do my best to get them all running as passing as best they can, and
> > will update this thread with any questions or messages.
> >
> > My first query is seeing as we have no more i386 or FreeBSD agents/nodes,
> > I'll probably just go ahead and remove those from the new config file.
> >
> > HTH
> >
> I just realized I had somehow missed your original email about migrating
> andwas discussing getting with you.
>
> Thanks for working on this.
>
> Let us know if you have any questions.
>
> Best regards,
> Carl
>


-- 

*Gavin McDonald*
Systems Administrator
ASF Infrastructure Team

Re: Buildbots

[Carl Marcum]

Hi Gavin,

On 11/14/21 2:16 PM, Gavin McDonald wrote:

Hi All,

As the current Buildbots arent really working, nodes offline etc, I thought
this would be the best time to migrate your builds over to our newer
replacement
buildbot 3.2 over at ci2.apache.org .

I'll do my best to get them all running as passing as best they can, and
will update this thread with any questions or messages.

My first query is seeing as we have no more i386 or FreeBSD agents/nodes,
I'll probably just go ahead and remove those from the new config file.

HTH

I just realized I had somehow missed your original email about migrating 
andwas discussing getting with you.


Thanks for working on this.

Let us know if you have any questions.

Best regards,
Carl

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

Re: Buildbots

[Marcus]

Am 09.11.19 um 09:28 schrieb Matthias Seidel:

Just FYI, the Windows bots are building again...

https://www.openoffice.org/download/devbuilds.html

We are now working on the Linux machines...


that's great news. Thanks for that. :-)

Marcus


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

Re: Buildbots

[Peter Kovacs]

Great!

Am 9. November 2019 09:28:40 MEZ schrieb Matthias Seidel 
:
>Hi all,
>
>Just FYI, the Windows bots are building again...
>
>https://www.openoffice.org/download/devbuilds.html
>
>We are now working on the Linux machines...
>
>Regards,
>
>   Matthias

Re: Buildbots page

[Andrea Pescetti]

Jim Jagielski wrote:

How can I upload my macOS build there??


I've answered you here:

https://lists.apache.org/thread.html/05d175d207b2bdc1ed83c8c4884630e91663a953daf12fe8612e98c5@%3Cdev.openoffice.apache.org%3E

and here:

https://lists.apache.org/thread.html/96b7085351f7ab7975ac56c5bc7c42852b8a888da53e0a67864d3396@%3Cdev.openoffice.apache.org%3E

See also

https://lists.apache.org/thread.html/fb2aa00aac961e6f04cb987721f820502ec68675f57f1ca6671b27cf@%3Cdev.openoffice.apache.org%3E

for the current Linux-64 builds.

Regards,
  Andrea.

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

Re: Buildbots page

[Matthias Seidel]

Hi Jim,

This page links only to the output area of our buildbots.
I doubt that we can upload there...

As Andrea stated in another mail:

"So we've traditionally hosted the normal dev builds (before RC) on
people.apache.org; but Infra decided to replace it with  home.apache.org
and to make it SFTP-only (no rsync); still, it is possible, while still
painful, to upload an OpenOffice development snapshot there; see
https://home.apache.org/~pescetti/openoffice-4.1.3-dev-r1761989/binaries/
as an example."

So home.apache.org would be the place to upload your mac builds.

Kind regards, Matthias


Am 03.04.2017 um 16:07 schrieb Jim Jagielski:
> How can I upload my macOS build there??
>
>> On Apr 1, 2017, at 4:52 PM, Matthias Seidel  
>> wrote:
>>
>> If no one has objections I would make :
>>
>> https://www.openoffice.org/download/devbuilds-test.html
>>
>> live tomorrow and ask Infra to remove the script, page and artefacts of:
>>
>> https://ci.apache.org/projects/openoffice/index.html
>>
>> Regards, Matthias
>>
>> FYI: I changed the schedule of the snapshot builds (414 branch) to a
>> weekly base.
>>
>>
>> Am 28.03.2017 um 21:15 schrieb Matthias Seidel:
>>> Am 28.03.2017 um 01:55 schrieb Damjan Jovanovic:
 It might have changed...
>>> Indeed (from:
>>> https://svn.apache.org/repos//infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/README_SCRIPTS.txt):
>>>
>>> Index generation scripts
>>> 
>>>
>>> Note:
>>> The shell scripts which generate the nightly and snapshot indexes have been 
>>> moved to puppet.
>>>
>>> See the directory:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=tree;f=modules/buildbot_asf/files/projects;hb=HEAD
>>>
>>> The cron jobs are defined in
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob_plain;f=modules/buildbot_asf/manifests/init.pp;hb=HEAD
>>>
>>>
>>> Unfortunately only the script has been moved, but not the header, footer
>>> and css. Therefore the page can not be updated properly.
>>> The script itself generates links to AOO 4.1.2 snapshots and needs also
>>> to be changed.
>>>
>>> Instead of trying to fix the generated page I would suggest to link
>>> directly to nightlys/snapshots from our devbuilds homepage:
>>> https://www.openoffice.org/download/devbuilds.html
>>>
>>> I created a test page as example:
>>> https://www.openoffice.org/download/devbuilds-test.html
>>>
>>> Opinions?
>>>
>>> Kind regards, Matthias
>>>
 On Mon, Mar 27, 2017 at 10:33 PM, Matthias Seidel <
 matthias.sei...@hamburg.de> wrote:

> Hi Damjan,
>
> Thanks you for the link, but in:
>
> https://svn.apache.org/repos/infra/infrastructure/buildbot/
> aegis/buildmaster/master1/public_html/projects/openoffice/
>
> I can only find header, footer and CSS but no script?
>
> Regards, Matthias
>
>
> Am 27.03.2017 um 18:25 schrieb Damjan Jovanovic:
>> It's generated from:
>> https://svn.apache.org/repos/infra/infrastructure/buildbot/
> aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-
> snapshots-index.sh
>> Regards
>> Damjan
>>
>> On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel <
> matthias.sei...@hamburg.de
>>> wrote:
>>> Hello all!
>>>
>>> Is there a way to maintain our Buildbots page?
>>>
>>> https://ci.apache.org/projects/openoffice/index.html
>>>
>>> Regards, Matthias
>>>
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Buildbots page

[Jim Jagielski]

How can I upload my macOS build there??

> On Apr 1, 2017, at 4:52 PM, Matthias Seidel  
> wrote:
> 
> If no one has objections I would make :
> 
> https://www.openoffice.org/download/devbuilds-test.html
> 
> live tomorrow and ask Infra to remove the script, page and artefacts of:
> 
> https://ci.apache.org/projects/openoffice/index.html
> 
> Regards, Matthias
> 
> FYI: I changed the schedule of the snapshot builds (414 branch) to a
> weekly base.
> 
> 
> Am 28.03.2017 um 21:15 schrieb Matthias Seidel:
>> Am 28.03.2017 um 01:55 schrieb Damjan Jovanovic:
>>> It might have changed...
>> Indeed (from:
>> https://svn.apache.org/repos//infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/README_SCRIPTS.txt):
>> 
>> Index generation scripts
>> 
>> 
>> Note:
>> The shell scripts which generate the nightly and snapshot indexes have been 
>> moved to puppet.
>> 
>> See the directory:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=tree;f=modules/buildbot_asf/files/projects;hb=HEAD
>> 
>> The cron jobs are defined in
>> 
>> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob_plain;f=modules/buildbot_asf/manifests/init.pp;hb=HEAD
>> 
>> 
>> Unfortunately only the script has been moved, but not the header, footer
>> and css. Therefore the page can not be updated properly.
>> The script itself generates links to AOO 4.1.2 snapshots and needs also
>> to be changed.
>> 
>> Instead of trying to fix the generated page I would suggest to link
>> directly to nightlys/snapshots from our devbuilds homepage:
>> https://www.openoffice.org/download/devbuilds.html
>> 
>> I created a test page as example:
>> https://www.openoffice.org/download/devbuilds-test.html
>> 
>> Opinions?
>> 
>> Kind regards, Matthias
>> 
>>> On Mon, Mar 27, 2017 at 10:33 PM, Matthias Seidel <
>>> matthias.sei...@hamburg.de> wrote:
>>> 
 Hi Damjan,
 
 Thanks you for the link, but in:
 
 https://svn.apache.org/repos/infra/infrastructure/buildbot/
 aegis/buildmaster/master1/public_html/projects/openoffice/
 
 I can only find header, footer and CSS but no script?
 
 Regards, Matthias
 
 
 Am 27.03.2017 um 18:25 schrieb Damjan Jovanovic:
> It's generated from:
> https://svn.apache.org/repos/infra/infrastructure/buildbot/
 aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-
 snapshots-index.sh
> Regards
> Damjan
> 
> On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel <
 matthias.sei...@hamburg.de
>> wrote:
>> Hello all!
>> 
>> Is there a way to maintain our Buildbots page?
>> 
>> https://ci.apache.org/projects/openoffice/index.html
>> 
>> Regards, Matthias
>> 
>> 
>> 
 
>> 
> 
> 


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

Re: Buildbots page

[Matthias Seidel]

Hi,

"All this work" took me about 30 minutes... ;-)

But the script has not been updated for years and the page is totally
outdated.
Feel free to maintain it.

Regards, Matthias


Am 02.04.2017 um 02:58 schrieb Gavin McDonald:
> I have no idea why you have been doing all this work, the old scripts have 
> been working fine 
> and can be updated in svn for the template parts and git for the sh script.
>
> Gav…
>
>> On 2 Apr 2017, at 6:52 am, Matthias Seidel  
>> wrote:
>>
>> If no one has objections I would make :
>>
>> https://www.openoffice.org/download/devbuilds-test.html
>>
>> live tomorrow and ask Infra to remove the script, page and artefacts of:
>>
>> https://ci.apache.org/projects/openoffice/index.html
>>
>> Regards, Matthias
>>
>> FYI: I changed the schedule of the snapshot builds (414 branch) to a
>> weekly base.
>>
>>
>> Am 28.03.2017 um 21:15 schrieb Matthias Seidel:
>>> Am 28.03.2017 um 01:55 schrieb Damjan Jovanovic:
 It might have changed...
>>> Indeed (from:
>>> https://svn.apache.org/repos//infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/README_SCRIPTS.txt):
>>>
>>> Index generation scripts
>>> 
>>>
>>> Note:
>>> The shell scripts which generate the nightly and snapshot indexes have been 
>>> moved to puppet.
>>>
>>> See the directory:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=tree;f=modules/buildbot_asf/files/projects;hb=HEAD
>>>
>>> The cron jobs are defined in
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob_plain;f=modules/buildbot_asf/manifests/init.pp;hb=HEAD
>>>
>>>
>>> Unfortunately only the script has been moved, but not the header, footer
>>> and css. Therefore the page can not be updated properly.
>>> The script itself generates links to AOO 4.1.2 snapshots and needs also
>>> to be changed.
>>>
>>> Instead of trying to fix the generated page I would suggest to link
>>> directly to nightlys/snapshots from our devbuilds homepage:
>>> https://www.openoffice.org/download/devbuilds.html
>>>
>>> I created a test page as example:
>>> https://www.openoffice.org/download/devbuilds-test.html
>>>
>>> Opinions?
>>>
>>> Kind regards, Matthias
>>>
 On Mon, Mar 27, 2017 at 10:33 PM, Matthias Seidel <
 matthias.sei...@hamburg.de> wrote:

> Hi Damjan,
>
> Thanks you for the link, but in:
>
> https://svn.apache.org/repos/infra/infrastructure/buildbot/
> aegis/buildmaster/master1/public_html/projects/openoffice/
>
> I can only find header, footer and CSS but no script?
>
> Regards, Matthias
>
>
> Am 27.03.2017 um 18:25 schrieb Damjan Jovanovic:
>> It's generated from:
>> https://svn.apache.org/repos/infra/infrastructure/buildbot/
> aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-
> snapshots-index.sh
>> Regards
>> Damjan
>>
>> On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel <
> matthias.sei...@hamburg.de
>>> wrote:
>>> Hello all!
>>>
>>> Is there a way to maintain our Buildbots page?
>>>
>>> https://ci.apache.org/projects/openoffice/index.html
>>>
>>> Regards, Matthias
>>>
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Buildbots page

[Gavin McDonald]

I have no idea why you have been doing all this work, the old scripts have been 
working fine 
and can be updated in svn for the template parts and git for the sh script.

Gav…

> On 2 Apr 2017, at 6:52 am, Matthias Seidel  wrote:
> 
> If no one has objections I would make :
> 
> https://www.openoffice.org/download/devbuilds-test.html
> 
> live tomorrow and ask Infra to remove the script, page and artefacts of:
> 
> https://ci.apache.org/projects/openoffice/index.html
> 
> Regards, Matthias
> 
> FYI: I changed the schedule of the snapshot builds (414 branch) to a
> weekly base.
> 
> 
> Am 28.03.2017 um 21:15 schrieb Matthias Seidel:
>> Am 28.03.2017 um 01:55 schrieb Damjan Jovanovic:
>>> It might have changed...
>> Indeed (from:
>> https://svn.apache.org/repos//infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/README_SCRIPTS.txt):
>> 
>> Index generation scripts
>> 
>> 
>> Note:
>> The shell scripts which generate the nightly and snapshot indexes have been 
>> moved to puppet.
>> 
>> See the directory:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=tree;f=modules/buildbot_asf/files/projects;hb=HEAD
>> 
>> The cron jobs are defined in
>> 
>> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob_plain;f=modules/buildbot_asf/manifests/init.pp;hb=HEAD
>> 
>> 
>> Unfortunately only the script has been moved, but not the header, footer
>> and css. Therefore the page can not be updated properly.
>> The script itself generates links to AOO 4.1.2 snapshots and needs also
>> to be changed.
>> 
>> Instead of trying to fix the generated page I would suggest to link
>> directly to nightlys/snapshots from our devbuilds homepage:
>> https://www.openoffice.org/download/devbuilds.html
>> 
>> I created a test page as example:
>> https://www.openoffice.org/download/devbuilds-test.html
>> 
>> Opinions?
>> 
>> Kind regards, Matthias
>> 
>>> On Mon, Mar 27, 2017 at 10:33 PM, Matthias Seidel <
>>> matthias.sei...@hamburg.de> wrote:
>>> 
 Hi Damjan,
 
 Thanks you for the link, but in:
 
 https://svn.apache.org/repos/infra/infrastructure/buildbot/
 aegis/buildmaster/master1/public_html/projects/openoffice/
 
 I can only find header, footer and CSS but no script?
 
 Regards, Matthias
 
 
 Am 27.03.2017 um 18:25 schrieb Damjan Jovanovic:
> It's generated from:
> https://svn.apache.org/repos/infra/infrastructure/buildbot/
 aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-
 snapshots-index.sh
> Regards
> Damjan
> 
> On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel <
 matthias.sei...@hamburg.de
>> wrote:
>> Hello all!
>> 
>> Is there a way to maintain our Buildbots page?
>> 
>> https://ci.apache.org/projects/openoffice/index.html
>> 
>> Regards, Matthias
>> 
>> 
>> 
 
>> 
> 
> 


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

Re: Buildbots page

[Matthias Seidel]

If no one has objections I would make :

https://www.openoffice.org/download/devbuilds-test.html

live tomorrow and ask Infra to remove the script, page and artefacts of:

https://ci.apache.org/projects/openoffice/index.html

Regards, Matthias

FYI: I changed the schedule of the snapshot builds (414 branch) to a
weekly base.


Am 28.03.2017 um 21:15 schrieb Matthias Seidel:
> Am 28.03.2017 um 01:55 schrieb Damjan Jovanovic:
>> It might have changed...
> Indeed (from:
> https://svn.apache.org/repos//infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/README_SCRIPTS.txt):
>
> Index generation scripts
> 
>
> Note:
> The shell scripts which generate the nightly and snapshot indexes have been 
> moved to puppet.
>
> See the directory:
>
> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=tree;f=modules/buildbot_asf/files/projects;hb=HEAD
>
> The cron jobs are defined in
>
> https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob_plain;f=modules/buildbot_asf/manifests/init.pp;hb=HEAD
>
>
> Unfortunately only the script has been moved, but not the header, footer
> and css. Therefore the page can not be updated properly.
> The script itself generates links to AOO 4.1.2 snapshots and needs also
> to be changed.
>
> Instead of trying to fix the generated page I would suggest to link
> directly to nightlys/snapshots from our devbuilds homepage:
> https://www.openoffice.org/download/devbuilds.html
>
> I created a test page as example:
> https://www.openoffice.org/download/devbuilds-test.html
>
> Opinions?
>
> Kind regards, Matthias
>
>> On Mon, Mar 27, 2017 at 10:33 PM, Matthias Seidel <
>> matthias.sei...@hamburg.de> wrote:
>>
>>> Hi Damjan,
>>>
>>> Thanks you for the link, but in:
>>>
>>> https://svn.apache.org/repos/infra/infrastructure/buildbot/
>>> aegis/buildmaster/master1/public_html/projects/openoffice/
>>>
>>> I can only find header, footer and CSS but no script?
>>>
>>> Regards, Matthias
>>>
>>>
>>> Am 27.03.2017 um 18:25 schrieb Damjan Jovanovic:
 It's generated from:
 https://svn.apache.org/repos/infra/infrastructure/buildbot/
>>> aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-
>>> snapshots-index.sh
 Regards
 Damjan

 On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel <
>>> matthias.sei...@hamburg.de
> wrote:
> Hello all!
>
> Is there a way to maintain our Buildbots page?
>
> https://ci.apache.org/projects/openoffice/index.html
>
> Regards, Matthias
>
>
>
>>>
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Buildbots page

[Matthias Seidel]

Am 28.03.2017 um 01:55 schrieb Damjan Jovanovic:
> It might have changed...

Indeed (from:
https://svn.apache.org/repos//infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/README_SCRIPTS.txt):

Index generation scripts


Note:
The shell scripts which generate the nightly and snapshot indexes have been 
moved to puppet.

See the directory:

https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=tree;f=modules/buildbot_asf/files/projects;hb=HEAD

The cron jobs are defined in

https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob_plain;f=modules/buildbot_asf/manifests/init.pp;hb=HEAD


Unfortunately only the script has been moved, but not the header, footer
and css. Therefore the page can not be updated properly.
The script itself generates links to AOO 4.1.2 snapshots and needs also
to be changed.

Instead of trying to fix the generated page I would suggest to link
directly to nightlys/snapshots from our devbuilds homepage:
https://www.openoffice.org/download/devbuilds.html

I created a test page as example:
https://www.openoffice.org/download/devbuilds-test.html

Opinions?

Kind regards, Matthias

>
> On Mon, Mar 27, 2017 at 10:33 PM, Matthias Seidel <
> matthias.sei...@hamburg.de> wrote:
>
>> Hi Damjan,
>>
>> Thanks you for the link, but in:
>>
>> https://svn.apache.org/repos/infra/infrastructure/buildbot/
>> aegis/buildmaster/master1/public_html/projects/openoffice/
>>
>> I can only find header, footer and CSS but no script?
>>
>> Regards, Matthias
>>
>>
>> Am 27.03.2017 um 18:25 schrieb Damjan Jovanovic:
>>> It's generated from:
>>> https://svn.apache.org/repos/infra/infrastructure/buildbot/
>> aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-
>> snapshots-index.sh
>>> Regards
>>> Damjan
>>>
>>> On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel <
>> matthias.sei...@hamburg.de
 wrote:
 Hello all!

 Is there a way to maintain our Buildbots page?

 https://ci.apache.org/projects/openoffice/index.html

 Regards, Matthias



>>
>>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Buildbots page

[Damjan Jovanovic]

It might have changed...

On Mon, Mar 27, 2017 at 10:33 PM, Matthias Seidel <
matthias.sei...@hamburg.de> wrote:

> Hi Damjan,
>
> Thanks you for the link, but in:
>
> https://svn.apache.org/repos/infra/infrastructure/buildbot/
> aegis/buildmaster/master1/public_html/projects/openoffice/
>
> I can only find header, footer and CSS but no script?
>
> Regards, Matthias
>
>
> Am 27.03.2017 um 18:25 schrieb Damjan Jovanovic:
> > It's generated from:
> > https://svn.apache.org/repos/infra/infrastructure/buildbot/
> aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-
> snapshots-index.sh
> >
> > Regards
> > Damjan
> >
> > On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel <
> matthias.sei...@hamburg.de
> >> wrote:
> >> Hello all!
> >>
> >> Is there a way to maintain our Buildbots page?
> >>
> >> https://ci.apache.org/projects/openoffice/index.html
> >>
> >> Regards, Matthias
> >>
> >>
> >>
>
>
>

Re: Buildbots page

[Matthias Seidel]

Hi Damjan,

Thanks you for the link, but in:

https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/projects/openoffice/

I can only find header, footer and CSS but no script?

Regards, Matthias


Am 27.03.2017 um 18:25 schrieb Damjan Jovanovic:
> It's generated from:
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-snapshots-index.sh
>
> Regards
> Damjan
>
> On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel > wrote:
>> Hello all!
>>
>> Is there a way to maintain our Buildbots page?
>>
>> https://ci.apache.org/projects/openoffice/index.html
>>
>> Regards, Matthias
>>
>>
>>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Buildbots page

[Damjan Jovanovic]

It's generated from:
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/public_html/projects/openoffice/create-ooo-snapshots-index.sh

Regards
Damjan

On Mon, Mar 27, 2017 at 5:58 PM, Matthias Seidel  wrote:

> Hello all!
>
> Is there a way to maintain our Buildbots page?
>
> https://ci.apache.org/projects/openoffice/index.html
>
> Regards, Matthias
>
>
>

Re: Buildbots are working again

[Damjan Jovanovic]

Hi Peter

If trunk is stable and I develop in branches, then buildbots will either be
equally broken as they will break on the branches, or they will build trunk
and be stable but useless to me.

I think your biggest problem is building on Arch Linux, and I am
downloading it now to try it myself. Which bitness are you using?

Damjan

On Wed, Jan 4, 2017 at 3:00 PM, Peter Kovacs  wrote:

> Hi all,
>
> I am a bit unhappy with this approach. It basicly blocks all other efforts
> on the code.
>
> Ok. I am still struggeling with the build, but since I started to change
> code itself I actually making progress. I currently do not know where to
> commit those changes, so I can check on different machines (And see if my
> changes are still compatible with all other machines).
>
> I personally like to open up a branch.
>
> I also would like to see that trunc is the most stable branch we have,
> since this is the one we advertise people to start with. It is pretty hard
> to get familiar with the code if you work on something unstable.
>
> I do not mean to offend Damjan, who is doing a fine Job! - It is just I
> have the feeling our current organization is only working for a view, and
> not for all activities we are on.
>
>
> All the best
>
> Peter
>
>
> On 04.01.2017 13:27, Damjan Jovanovic wrote:
>
>> Yes, the last problem was that main/curl needed adding to
>> RepositoryExternal.mk. I've committed a fix and am testing it on the
>> FreeBSD bot now.
>>
>> The bots will be quite unstable going forward, as I am actively porting
>> modules to gbuild. They help me a lot to test different platforms quickly,
>> with different build settings - my PC mostly uses system libraries, the
>> bots internal ones. If you don't see commits to SVN for a while, and the
>> bots are still broken, then there's a problem ;-).
>>
>> Damjan
>>
>>
>>
>> On Wed, Jan 4, 2017 at 2:16 PM, Matthias Seidel <
>> matthias.sei...@hamburg.de>
>> wrote:
>>
>> Hi Damjan,
>>>
>>> Last night the linux64-41x buildbot (and maybe others)  failed. Last
>>> successful build was 31.12.2016.
>>>
>>> Do you have any idea?
>>>
>>> Regards, Matthias
>>>
>>>
>>> Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:
>>>
 Hi

 All the buildbots are successfully building now.

 The FreeBSD bot was fixed by changing the buildbot script to use Clang
 instead of GCC. From what I've seen, on FreeBSD, loading a mixture of
 C++
 libraries built with GCC and C++ libraries built with Clang into the
 same
 process, and using more advanced C++ features like exception handling,
 causes memory corruption and crashes due to incompatible C++ ABIs;
 either
 every library has to be built with GCC or every library has to be built
 with Clang. In practice, the former requires a rebuild of the entire
 base
 system and building all ports from source, which is why the latter is
 better.

 The Linux bots were much harder to fix. The build was breaking because

>>> libc
>>>
 isn't linked to in some gbuild modules, something that was fixed by
 explicitly always linking to libc on Linux, and because Google Test

>>> wasn't
>>>
 linking to libpthread, somehow resulting in missing symbols in at least
 main/binaryurp when built without --enable-dbgutil, which was fixed by
 explicitly linking it to libpthread. I don't like these linker
 mysteries,
 which never happen on FreeBSD, and some of which can be worked around

>>> with
>>>
 the "gold" linker...

 Damjan


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

Re: Buildbots are working again

[Peter Kovacs]

Hi all,

I am a bit unhappy with this approach. It basicly blocks all other 
efforts on the code.


Ok. I am still struggeling with the build, but since I started to change 
code itself I actually making progress. I currently do not know where to 
commit those changes, so I can check on different machines (And see if 
my changes are still compatible with all other machines).


I personally like to open up a branch.

I also would like to see that trunc is the most stable branch we have, 
since this is the one we advertise people to start with. It is pretty 
hard to get familiar with the code if you work on something unstable.


I do not mean to offend Damjan, who is doing a fine Job! - It is just I 
have the feeling our current organization is only working for a view, 
and not for all activities we are on.



All the best

Peter

On 04.01.2017 13:27, Damjan Jovanovic wrote:

Yes, the last problem was that main/curl needed adding to
RepositoryExternal.mk. I've committed a fix and am testing it on the
FreeBSD bot now.

The bots will be quite unstable going forward, as I am actively porting
modules to gbuild. They help me a lot to test different platforms quickly,
with different build settings - my PC mostly uses system libraries, the
bots internal ones. If you don't see commits to SVN for a while, and the
bots are still broken, then there's a problem ;-).

Damjan



On Wed, Jan 4, 2017 at 2:16 PM, Matthias Seidel 
wrote:


Hi Damjan,

Last night the linux64-41x buildbot (and maybe others)  failed. Last
successful build was 31.12.2016.

Do you have any idea?

Regards, Matthias


Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:

Hi

All the buildbots are successfully building now.

The FreeBSD bot was fixed by changing the buildbot script to use Clang
instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
libraries built with GCC and C++ libraries built with Clang into the same
process, and using more advanced C++ features like exception handling,
causes memory corruption and crashes due to incompatible C++ ABIs; either
every library has to be built with GCC or every library has to be built
with Clang. In practice, the former requires a rebuild of the entire base
system and building all ports from source, which is why the latter is
better.

The Linux bots were much harder to fix. The build was breaking because

libc

isn't linked to in some gbuild modules, something that was fixed by
explicitly always linking to libc on Linux, and because Google Test

wasn't

linking to libpthread, somehow resulting in missing symbols in at least
main/binaryurp when built without --enable-dbgutil, which was fixed by
explicitly linking it to libpthread. I don't like these linker mysteries,
which never happen on FreeBSD, and some of which can be worked around

with

the "gold" linker...

Damjan







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

Re: Buildbots are working again

[Damjan Jovanovic]

Yes, the last problem was that main/curl needed adding to
RepositoryExternal.mk. I've committed a fix and am testing it on the
FreeBSD bot now.

The bots will be quite unstable going forward, as I am actively porting
modules to gbuild. They help me a lot to test different platforms quickly,
with different build settings - my PC mostly uses system libraries, the
bots internal ones. If you don't see commits to SVN for a while, and the
bots are still broken, then there's a problem ;-).

Damjan



On Wed, Jan 4, 2017 at 2:16 PM, Matthias Seidel 
wrote:

> Hi Damjan,
>
> Last night the linux64-41x buildbot (and maybe others)  failed. Last
> successful build was 31.12.2016.
>
> Do you have any idea?
>
> Regards, Matthias
>
>
> Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:
> > Hi
> >
> > All the buildbots are successfully building now.
> >
> > The FreeBSD bot was fixed by changing the buildbot script to use Clang
> > instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
> > libraries built with GCC and C++ libraries built with Clang into the same
> > process, and using more advanced C++ features like exception handling,
> > causes memory corruption and crashes due to incompatible C++ ABIs; either
> > every library has to be built with GCC or every library has to be built
> > with Clang. In practice, the former requires a rebuild of the entire base
> > system and building all ports from source, which is why the latter is
> > better.
> >
> > The Linux bots were much harder to fix. The build was breaking because
> libc
> > isn't linked to in some gbuild modules, something that was fixed by
> > explicitly always linking to libc on Linux, and because Google Test
> wasn't
> > linking to libpthread, somehow resulting in missing symbols in at least
> > main/binaryurp when built without --enable-dbgutil, which was fixed by
> > explicitly linking it to libpthread. I don't like these linker mysteries,
> > which never happen on FreeBSD, and some of which can be worked around
> with
> > the "gold" linker...
> >
> > Damjan
> >
>
>
>

Re: Buildbots are working again

[Matthias Seidel]

Hi Damjan,

Last night the linux64-41x buildbot (and maybe others)  failed. Last
successful build was 31.12.2016.

Do you have any idea?

Regards, Matthias


Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:
> Hi
>
> All the buildbots are successfully building now.
>
> The FreeBSD bot was fixed by changing the buildbot script to use Clang
> instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
> libraries built with GCC and C++ libraries built with Clang into the same
> process, and using more advanced C++ features like exception handling,
> causes memory corruption and crashes due to incompatible C++ ABIs; either
> every library has to be built with GCC or every library has to be built
> with Clang. In practice, the former requires a rebuild of the entire base
> system and building all ports from source, which is why the latter is
> better.
>
> The Linux bots were much harder to fix. The build was breaking because libc
> isn't linked to in some gbuild modules, something that was fixed by
> explicitly always linking to libc on Linux, and because Google Test wasn't
> linking to libpthread, somehow resulting in missing symbols in at least
> main/binaryurp when built without --enable-dbgutil, which was fixed by
> explicitly linking it to libpthread. I don't like these linker mysteries,
> which never happen on FreeBSD, and some of which can be worked around with
> the "gold" linker...
>
> Damjan
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Buildbots are working again

[Peter Kovacs]

Thanks a lot Damjan.
Sounds really great. I will update my repository and try to build open
office again. Maybe it works for me.
:)

All the best
Peter

Damjan Jovanovic  schrieb am Mo., 26. Dez. 2016, 19:46:

> Hi
>
> All the buildbots are successfully building now.
>
> The FreeBSD bot was fixed by changing the buildbot script to use Clang
> instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
> libraries built with GCC and C++ libraries built with Clang into the same
> process, and using more advanced C++ features like exception handling,
> causes memory corruption and crashes due to incompatible C++ ABIs; either
> every library has to be built with GCC or every library has to be built
> with Clang. In practice, the former requires a rebuild of the entire base
> system and building all ports from source, which is why the latter is
> better.
>
> The Linux bots were much harder to fix. The build was breaking because libc
> isn't linked to in some gbuild modules, something that was fixed by
> explicitly always linking to libc on Linux, and because Google Test wasn't
> linking to libpthread, somehow resulting in missing symbols in at least
> main/binaryurp when built without --enable-dbgutil, which was fixed by
> explicitly linking it to libpthread. I don't like these linker mysteries,
> which never happen on FreeBSD, and some of which can be worked around with
> the "gold" linker...
>
> Damjan
>
-- 

Disclaimer: Diese Nachricht stammt aus einem Google Account. Ihre Antwort
wird in der Google Cloud Gespeichert und durch Google Algorythmen zwecks
werbeanaöysen gescannt. Es ist derzeit nicht auszuschließen das ihre
Nachricht auch durch einen NSA Mitarbeiter geprüft wird. Durch
kommunikation mit diesen Account stimmen Sie zu das ihre Mail, ihre
Kontaktdaten und die Termine die Sie mit mir vereinbaren online zu Google
konditionen in der Googlecloud gespeichert wird. Sollten sie dies nicht
wünschen kontaktieren sie mich bitte Umgehend um z.B. alternativen zu
verhandeln.

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

Re: Buildbots update

[Andrea Pescetti]

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



showed 4 nmake processes, 2 from March 30, 2 from April 4, part of
orphaned trees also containing perl, sh, and dmake.


At least we could have the VM restarted to make sure we don't carry 
stale processes around for months. Infra can for sure do it with minimal 
effort. And access to the dedicated IRC channel for giving instructions 
to buildbots might be useful too (I guess you know what I am talking 
about; if not, just ask and I can look it up).


Regards,
  Andrea.

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

Re: Buildbots update

[Damjan Jovanovic]

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-

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


> > 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?
>
>
I caught AOO building ext_libraries/apr on my own setup (where the buildbot
usually fails and locks files), and quickly ran "ps -W" and "tasklist".
DEVENV wasn't running.

According to Infra, that buildbot is running "the basic Windows Defender
stuff".


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

Re: Buildbots update

[Kay Schenk]

On Fri, Jul 22, 2016 at 12:09 AM, 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.
>

​Lookin' pretty good so far! A BIG thank you again for all your work on
this!
Dealing with the buildbot configurations is quite a challenge!
​


>
> 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.
>
> 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?
>
> 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?
>
> 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.
>
> On Tue, Jul 19, 2016 at 8:17 PM, Damjan Jovanovic 
> wrote:
>
> > Hi
> >
> > I contacted Infra on HipChat and asked them to fix the buildbots I could
> > find with the Perl LWP::Protocol::https problem (aoo-w7snap,
> > openoffice-fbsd-nightly, and openoffice-linux32-nightly) or give me
> access
> > to do it myself, and @pono fixed at least the openoffice-linux32-nightly
> > bot.
> >
> > The other buildbots are either failing earlier or failing for other
> > reasons. For example openoffice-linux64-nightly was failing to download
> > openssl ("500 Can't connect to www.openssl.org:443"), but I've uploaded
> > it to ooo-extras and it's gotten further in the build I am forcing now.
> >
> > Damjan
> >
> >
>



-- 

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 

Re: Buildbots update

[Marcus]

Am 07/22/2016 09:09 AM, schrieb Damjan Jovanovic:

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.

[...]


that's great news and very valueable. Thanks a lot for not letting go 
this important stuff. :-)


Marcus


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

Re: Buildbots update

[Patricia Shanahan]

On 7/22/2016 12:09 AM, Damjan Jovanovic wrote:
...

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?

...

I don't explicitly run it, and cannot find it in any of the scripts such 
as configure that I do run. I copy pieces of Visual Studio into 
main/external/ directories, as described in 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7.2C_Windows_8.1


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

Re: Buildbots update

[Damjan Jovanovic]

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.

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.

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?

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?

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.

On Tue, Jul 19, 2016 at 8:17 PM, Damjan Jovanovic  wrote:

> Hi
>
> I contacted Infra on HipChat and asked them to fix the buildbots I could
> find with the Perl LWP::Protocol::https problem (aoo-w7snap,
> openoffice-fbsd-nightly, and openoffice-linux32-nightly) or give me access
> to do it myself, and @pono fixed at least the openoffice-linux32-nightly
> bot.
>
> The other buildbots are either failing earlier or failing for other
> reasons. For example openoffice-linux64-nightly was failing to download
> openssl ("500 Can't connect to www.openssl.org:443"), but I've uploaded
> it to ooo-extras and it's gotten further in the build I am forcing now.
>
> Damjan
>
>

Re: Buildbots update

[kaysch...@apache.org]

On 07/19/2016 11:17 AM, Damjan Jovanovic wrote:
> Hi
> 
> I contacted Infra on HipChat and asked them to fix the buildbots I could
> find with the Perl LWP::Protocol::https problem (aoo-w7snap,
> openoffice-fbsd-nightly, and openoffice-linux32-nightly) or give me access
> to do it myself, and @pono fixed at least the openoffice-linux32-nightly
> bot.
> 
> The other buildbots are either failing earlier or failing for other
> reasons. For example openoffice-linux64-nightly was failing to download
> openssl ("500 Can't connect to www.openssl.org:443"), but I've uploaded it
> to ooo-extras and it's gotten further in the build I am forcing now.
> 
> Damjan
> 

Thanks for looking into this, Damjan!

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

Re: Buildbots are back

[Pedro Giffuni]

Nice!

Thanks to everyone involved. The FreeBSD buildbot appears to need the 
same treatment BTW.


Pedro.

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

Re: Buildbots are back

[Kay Schenk]

On Tue, Mar 1, 2016 at 12:00 AM, Andrea Pescetti 
wrote:

> As you may have noticed, our buildbots are back. We now have development
> builds available.
>
> A missing package needed to be installed by Infra on the buildbots and
> they started installing it on the various VMs.
>
> The Linux buildbots already picked up the change:
> https://ci.apache.org/builders/openoffice-linux32-snapshot
> https://ci.apache.org/builders/openoffice-linux64-nightly/
>

> The Windows ones probably do not have the fix yet, but once it is deployed
> there too, we will get past this blocker and we may able to check better
> what is still in the way before getting Windows nightly builds available
> again.
>
> Reference: https://issues.apache.org/jira/browse/INFRA-11296
>
> Regards,
>   Andrea.
>


​Good news! ​
Hopefully they can get to the linux32-nightly
​ ​
​(different VM than linux32-SNAPSHOT) ​
and win7 VM soon.



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

Re: Buildbots update

[Andrea Pescetti]

Damjan Jovanovic wrote:

I've asked infra to get LWP::Protocol::https installed on all the
buildbots and they're working on it.


Thanks for debugging, this will hopefully solve it. So indeed the issue 
is on the buildbots side but it was related to SourceForge now enforcing 
HTTPS downloads. I hope Infra will fix it soon. By the way, this is 
tracked in https://issues.apache.org/jira/browse/INFRA-11296 for reference.



We also need to update our build instructions to install it when building.


Done for Fedora here:

https://wiki.openoffice.org/w/index.php?title=Fedora_Build_Instructions=237350=230515

If someone can look up at package names for Ubuntu (and at whatever is 
needed for Windows), we can update 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step 
too.


Regards,
  Andrea.

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

Re: Buildbots update

[Damjan Jovanovic]

Steps 1-4 first delete the "source" directory, do a fresh SVN checkout
(not update) into "source", delete the "build" directory, and copy
"source" to "build". The build is then run in "build". This was the
only robust way to get it working and fix all the errors and timeouts
that were happening earlier. I think that's confusing you here.

On linux64-nightly I've changed the buildbot script to cache downloads
across builds. In 9 builds, it hasn't helped one bit: all 14 missing
tarballs must have failed every single time.

The only thing that made a difference, getting it reduced from 15
missing tarballs to 14, is fixing the upstream URL for vigra in
main/external_deps.lst. This tells me it's access to SourceForge that
is the problem here.

In r1731307 I patched
main/solenv/bin/download_external_dependencies.pl to log the HTTP
status line when a download fails, and it finally showed what's really
wrong:

download from 
http://sourceforge.net/projects/oooextras.mirror/files/067201ea8b126597670b5eff72e1f66c-mythes-1.2.0.tar.gz
failed (501 Protocol scheme 'https' is not supported
(LWP::Protocol::https not installed))

I've asked infra to get LWP::Protocol::https installed on all the
buildbots and they're working on it.

We also need to update our build instructions to install it when building.

On Sat, Feb 20, 2016 at 12:06 AM, Kay Schenk  wrote:
> [top posting]
>
> hmmm...maybe I've figured out the problem?
>
> using Linux-32 nightly as the example.
>
> Take a look at the PWD variable in this listing:
>
> https://ci.apache.org/builders/openoffice-linux32-nightly/builds/191/steps/configure/logs/stdio
>
> and the corresponding TARFILE_LOCATION (which is correct for the PWD
> specified) --
>
> "The variable TARFILE_LOCATION  is set to:
> /home/buildslave20/slave20/openoffice-linux32-nightly/build/ext_sources"
>
> so conceptually NO downloads from 3rd party locations should happen
> at all in normal building with the buildbots since they have the
> correct local file info for 3rd party sources. This is the case for
> our local builds as well.
>
> However, when you look at the output for the svn update for this
> same run, look at where the update dumps --
>
> PWD=/home/buildslave20/slave20/openoffice-linux32-nightly/source
>
> so, in my mind, it's not in
> /home/buildslave20/slave20/openoffice-linux32-nightly/build/
>
> where I think it should be to make the build work correctly.
>
> What do others think?
>
>
>
> On 02/17/2016 03:40 PM, Kay Schenk wrote:
>>
>> On Tue, Feb 16, 2016 at 2:47 PM, Andrea Pescetti
>> > wrote:
>>
>> Kay Schenk wrote:
>>
>> On 02/13/2016 11:45 AM, Andrea Pescetti wrote:
>>
>> it seems that buildbots are having issues with network
>> in general
>>
>> Do we have any additional news on the download failures
>> specifically
>> from the buildbots to SourceForge downloads?
>>
>>
>> Why SourceForge? Look at
>> 
>> https://ci.apache.org/builders/openoffice-linux64-nightly/builds/243/steps/retry%20bootstrap/logs/stdio
>> to see that ALL downloads in ./bootstrap are failing; sure, most
>> of them are from SourceForge, but this is irrelevant, since
>> downloads from Mozilla and other sources are failing too.
>>
>> The problem is most likely on the buildbot side. For some
>> reason, be it a full disk or a firewall restriction, it can't
>> download stuff, and this should be checked with someone who has
>> shell access to that machine.
>>
>> The following, failed from buildbot, were OK with my test script
>>
>>
>> I confirm I've run ./boostrap without any problems too last
>> weekend. Again, the problem is on the buildbots and not elsewhere.
>>
>>
>> Regards,
>>   Andrea.
>>
>>
>> I got on HipChat a while ago and all that was suggested was we use
>> "https" instead of "http" to SourceForge. But, given that my little
>> stripped down download script worked fine without this, I doubt this
>> is it.
>> I didn't ask about filled up disk and perhaps I should have.  :(
>>
>> We COULD get around this but just using the sources already in our
>> trunk and changing the SVN call to that to just a file URL for the
>> time being, and referencing that as URL1 for these, but I guess that
>> might be considered  bad. We don't distribute these with the source
>> and we would need to remember to change this back for a release. But
>> just a thought.
>>
>> --
>> --
>> 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
>>
>>
>
> --
> 
> MzK
>
> "Though no one can go back and make a brand new start,
>  anyone can start from now and make a brand new ending."
> 

Re: Buildbots update

[Kay Schenk]

[top posting]

hmmm...maybe I've figured out the problem?

using Linux-32 nightly as the example.

Take a look at the PWD variable in this listing:

https://ci.apache.org/builders/openoffice-linux32-nightly/builds/191/steps/configure/logs/stdio

and the corresponding TARFILE_LOCATION (which is correct for the PWD
specified) --

"The variable TARFILE_LOCATION  is set to:
/home/buildslave20/slave20/openoffice-linux32-nightly/build/ext_sources"

so conceptually NO downloads from 3rd party locations should happen
at all in normal building with the buildbots since they have the
correct local file info for 3rd party sources. This is the case for
our local builds as well.

However, when you look at the output for the svn update for this
same run, look at where the update dumps --

PWD=/home/buildslave20/slave20/openoffice-linux32-nightly/source

so, in my mind, it's not in
/home/buildslave20/slave20/openoffice-linux32-nightly/build/

where I think it should be to make the build work correctly.

What do others think?



On 02/17/2016 03:40 PM, Kay Schenk wrote:
> 
> On Tue, Feb 16, 2016 at 2:47 PM, Andrea Pescetti
> > wrote:
> 
> Kay Schenk wrote:
> 
> On 02/13/2016 11:45 AM, Andrea Pescetti wrote:
> 
> it seems that buildbots are having issues with network
> in general
> 
> Do we have any additional news on the download failures
> specifically
> from the buildbots to SourceForge downloads?
> 
> 
> Why SourceForge? Look at
> 
> https://ci.apache.org/builders/openoffice-linux64-nightly/builds/243/steps/retry%20bootstrap/logs/stdio
> to see that ALL downloads in ./bootstrap are failing; sure, most
> of them are from SourceForge, but this is irrelevant, since
> downloads from Mozilla and other sources are failing too.
> 
> The problem is most likely on the buildbot side. For some
> reason, be it a full disk or a firewall restriction, it can't
> download stuff, and this should be checked with someone who has
> shell access to that machine.
> 
> The following, failed from buildbot, were OK with my test script
> 
> 
> I confirm I've run ./boostrap without any problems too last
> weekend. Again, the problem is on the buildbots and not elsewhere.
> 
> 
> Regards,
>   Andrea.
> 
> 
> ​I got on HipChat a while ago and all that was suggested was we use
> "https" instead of "http" to SourceForge. But, given that my little
> stripped down download script worked fine without this, I doubt this
> is it.
> I didn't ask about filled up disk and perhaps I should have.  :(
> 
> ​We COULD get around this but just using the sources already in our
> trunk and changing the SVN call to that to just a file URL for the
> time being, and referencing that as URL1 for these, but I guess that
> might be considered  bad.​ We don't distribute these with the source
> and we would need to remember to change this back for a release. But
> just a thought.
> 
> -- 
> --
> 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
>   
> 

-- 

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

[Kay Schenk]

On Tue, Feb 16, 2016 at 2:47 PM, Andrea Pescetti 
wrote:

> Kay Schenk wrote:
>
>> On 02/13/2016 11:45 AM, Andrea Pescetti wrote:
>>
>>> it seems that buildbots are having issues with network in general
>>>
>> Do we have any additional news on the download failures specifically
>> from the buildbots to SourceForge downloads?
>>
>
> Why SourceForge? Look at
>
> https://ci.apache.org/builders/openoffice-linux64-nightly/builds/243/steps/retry%20bootstrap/logs/stdio
> to see that ALL downloads in ./bootstrap are failing; sure, most of them
> are from SourceForge, but this is irrelevant, since downloads from Mozilla
> and other sources are failing too.
>
> The problem is most likely on the buildbot side. For some reason, be it a
> full disk or a firewall restriction, it can't download stuff, and this
> should be checked with someone who has shell access to that machine.
>
> The following, failed from buildbot, were OK with my test script
>>
>
> I confirm I've run ./boostrap without any problems too last weekend.
> Again, the problem is on the buildbots and not elsewhere.
>
>
> Regards,
>   Andrea.
>

​I got on HipChat a while ago and all that was suggested was we use "https"
instead of "http" to SourceForge. But, given that my little stripped down
download script worked fine without this, I doubt this is it.
I didn't ask about filled up disk and perhaps I should have.  :(

​We COULD get around this but just using the sources already in our trunk
and changing the SVN call to that to just a file URL for the time being,
and referencing that as URL1 for these, but I guess that might be
considered  bad.​ We don't distribute these with the source and we would
need to remember to change this back for a release. But just a thought.

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

Re: Buildbots update

[Andrea Pescetti]

Kay Schenk wrote:

On 02/13/2016 11:45 AM, Andrea Pescetti wrote:

it seems that buildbots are having issues with network in general

Do we have any additional news on the download failures specifically
from the buildbots to SourceForge downloads?


Why SourceForge? Look at
https://ci.apache.org/builders/openoffice-linux64-nightly/builds/243/steps/retry%20bootstrap/logs/stdio
to see that ALL downloads in ./bootstrap are failing; sure, most of them 
are from SourceForge, but this is irrelevant, since downloads from 
Mozilla and other sources are failing too.


The problem is most likely on the buildbot side. For some reason, be it 
a full disk or a firewall restriction, it can't download stuff, and this 
should be checked with someone who has shell access to that machine.



The following, failed from buildbot, were OK with my test script


I confirm I've run ./boostrap without any problems too last weekend. 
Again, the problem is on the buildbots and not elsewhere.


Regards,
  Andrea.

-
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/13/2016 11:45 AM, Andrea Pescetti wrote:
> Damjan Jovanovic wrote:
>> The buildbots are all failing to download 15 dependencies every night
>> now. I think something is wrong with access to SourceForge :-(.
> 
> Well, from what I see for example here
> https://ci.apache.org/builders/openoffice-linux64-nightly/builds/240/steps/retry%20bootstrap/logs/stdio
> 
> it seems that buildbots are having issues with network in general
> (or maybe it was a temporary network issue).
> 
> The failure in jpegsrc.v8d.tar.gz is expected, but URL1 is failing
> not only for cases where it is, by chance, on SourceForge, but also
> for vigra1.6.0.tar.gz and for the files from Mozilla. So it really
> seems that the buildbot was not able to download from anywhere.
> Maybe a forced re-run will fix it.
> 
> And thank you Damjan for your buildbot work! Improved error handling
> and built-in download retry in ./bootstrap will surely help in
> diagnosing build issues in general.
> 
> Regards,
>   Andrea.

Do we have any additional news on the download failures specifically
from the buildbots to SourceForge downloads?
Has anyone contacted SourceForge?

I am not experiencing these problems in my local build. And I made a
very stripped down "download_external_dependencies.pl" to just try
some out manually by just supplying the URL.

The following, failed from buildbot, were OK with my test script--

http://sourceforge.net/projects/oooextras.mirror/files/2ab442d169156f34c379c968f3f482dd-zlib-1.2.7.tar.bz2


http://sourceforge.net/projects/oooextras.mirror/files/52654eb3b2e60c35731ea8fc87f1bd29-jpeg-8d.tar.gz

http://sourceforge.net/projects/oooextras.mirror/files/dd7dab7a5fea97d2a6a43f511449b7cd-expat-2.1.0.tar.gz

I kind of gave up on boost because it was taking a very long time.

...and I didn't continue since my preliminary testing seemed to go OK.

On a related matter, we do have quite a number of download errors
with the URL1 values for some of our older external packs.



-- 

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

[Kay Schenk]

On 02/12/2016 10:43 PM, Damjan Jovanovic wrote:
> On Thu, Feb 11, 2016 at 7:42 PM, Kay Schenk  wrote:
>>
>>
>> On 02/11/2016 09:30 AM, Damjan Jovanovic wrote:
>>> On Wed, Feb 10, 2016 at 7:49 PM, Kay Schenk  wrote:

 On 02/10/2016 09:41 AM, Damjan Jovanovic wrote:
>
> All the *nix buildbots are now green and should be building 100% reliably.

 YAY!

>>>
>>> I jinxed it, many bots failed in ./bootstrap as they couldn't download
>>> dependencies. We should probably cache dependencies instead (ie. "cp
>>> external_deps/* build/ext_sources" before bootstrap and "cp
>>> build/ext_sources/* external_deps" after successful bootstrap). I'll
>>> try this on openoffice-linux64-nightly.
>>
>> oh well... yeah, I saw this.
>>
>> Yesterday, when you said you set up the builbots to fail on
>> bootstrap, I was going to say that even in my local build, the first
>> attempt at a bootstrap source sometimes fails but seems to right
>> itself the second time around usually from our  URL2 sites. This
>> said, it could be that some of our buildbots, due to time out
>> issues, will cause failure with this
>> step. We might think of putting things back the way they originally
>> were for the ./bootstrap step but increasing the time. On my local
>> builds, of course, I just sit and wait.
> 
> The buildbots are all failing to download 15 dependencies every night
> now. I think something is wrong with access to SourceForge :-(.

Well this is not good. All dependencies should download from their
"primary" (originating) site first, then try URL2 which is
SourceForge. I'll check this out later today.

> 
> I fixed the URL for Vigra so it can download it upstream instead, and
> I've tested upgrading zlib to 1.2.8 which can be downloaded upstream
> unlike 1.2.7, but there's a lot to fix.
> 


-- 

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

[Andrea Pescetti]

Damjan Jovanovic wrote:

The buildbots are all failing to download 15 dependencies every night
now. I think something is wrong with access to SourceForge :-(.


Well, from what I see for example here
https://ci.apache.org/builders/openoffice-linux64-nightly/builds/240/steps/retry%20bootstrap/logs/stdio
it seems that buildbots are having issues with network in general (or 
maybe it was a temporary network issue).


The failure in jpegsrc.v8d.tar.gz is expected, but URL1 is failing not 
only for cases where it is, by chance, on SourceForge, but also for 
vigra1.6.0.tar.gz and for the files from Mozilla. So it really seems 
that the buildbot was not able to download from anywhere. Maybe a forced 
re-run will fix it.


And thank you Damjan for your buildbot work! Improved error handling and 
built-in download retry in ./bootstrap will surely help in diagnosing 
build issues in general.


Regards,
  Andrea.

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

Re: Buildbots update

[Damjan Jovanovic]

On Thu, Feb 11, 2016 at 7:42 PM, Kay Schenk  wrote:
>
>
> On 02/11/2016 09:30 AM, Damjan Jovanovic wrote:
>> On Wed, Feb 10, 2016 at 7:49 PM, Kay Schenk  wrote:
>>>
>>> On 02/10/2016 09:41 AM, Damjan Jovanovic wrote:

 All the *nix buildbots are now green and should be building 100% reliably.
>>>
>>> YAY!
>>>
>>
>> I jinxed it, many bots failed in ./bootstrap as they couldn't download
>> dependencies. We should probably cache dependencies instead (ie. "cp
>> external_deps/* build/ext_sources" before bootstrap and "cp
>> build/ext_sources/* external_deps" after successful bootstrap). I'll
>> try this on openoffice-linux64-nightly.
>
> oh well... yeah, I saw this.
>
> Yesterday, when you said you set up the builbots to fail on
> bootstrap, I was going to say that even in my local build, the first
> attempt at a bootstrap source sometimes fails but seems to right
> itself the second time around usually from our  URL2 sites. This
> said, it could be that some of our buildbots, due to time out
> issues, will cause failure with this
> step. We might think of putting things back the way they originally
> were for the ./bootstrap step but increasing the time. On my local
> builds, of course, I just sit and wait.

The buildbots are all failing to download 15 dependencies every night
now. I think something is wrong with access to SourceForge :-(.

I fixed the URL for Vigra so it can download it upstream instead, and
I've tested upgrading zlib to 1.2.8 which can be downloaded upstream
unlike 1.2.7, but there's a lot to fix.

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

Re: Buildbots update

[Damjan Jovanovic]

On Wed, Feb 10, 2016 at 7:49 PM, Kay Schenk  wrote:
>
> On 02/10/2016 09:41 AM, Damjan Jovanovic wrote:
>>
>> All the *nix buildbots are now green and should be building 100% reliably.
>
> YAY!
>

I jinxed it, many bots failed in ./bootstrap as they couldn't download
dependencies. We should probably cache dependencies instead (ie. "cp
external_deps/* build/ext_sources" before bootstrap and "cp
build/ext_sources/* external_deps" after successful bootstrap). I'll
try this on openoffice-linux64-nightly.

-
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/11/2016 09:30 AM, Damjan Jovanovic wrote:
> On Wed, Feb 10, 2016 at 7:49 PM, Kay Schenk  wrote:
>>
>> On 02/10/2016 09:41 AM, Damjan Jovanovic wrote:
>>>
>>> All the *nix buildbots are now green and should be building 100% reliably.
>>
>> YAY!
>>
> 
> I jinxed it, many bots failed in ./bootstrap as they couldn't download
> dependencies. We should probably cache dependencies instead (ie. "cp
> external_deps/* build/ext_sources" before bootstrap and "cp
> build/ext_sources/* external_deps" after successful bootstrap). I'll
> try this on openoffice-linux64-nightly.

oh well... yeah, I saw this.

Yesterday, when you said you set up the builbots to fail on
bootstrap, I was going to say that even in my local build, the first
attempt at a bootstrap source sometimes fails but seems to right
itself the second time around usually from our  URL2 sites. This
said, it could be that some of our buildbots, due to time out
issues, will cause failure with this
step. We might think of putting things back the way they originally
were for the ./bootstrap step but increasing the time. On my local
builds, of course, I just sit and wait.





-- 

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

[Damjan Jovanovic]

On Thu, Feb 11, 2016 at 7:42 PM, Kay Schenk  wrote:
>
>
> On 02/11/2016 09:30 AM, Damjan Jovanovic wrote:
>> On Wed, Feb 10, 2016 at 7:49 PM, Kay Schenk  wrote:
>>>
>>> On 02/10/2016 09:41 AM, Damjan Jovanovic wrote:

 All the *nix buildbots are now green and should be building 100% reliably.
>>>
>>> YAY!
>>>
>>
>> I jinxed it, many bots failed in ./bootstrap as they couldn't download
>> dependencies. We should probably cache dependencies instead (ie. "cp
>> external_deps/* build/ext_sources" before bootstrap and "cp
>> build/ext_sources/* external_deps" after successful bootstrap). I'll
>> try this on openoffice-linux64-nightly.
>
> oh well... yeah, I saw this.
>
> Yesterday, when you said you set up the builbots to fail on
> bootstrap, I was going to say that even in my local build, the first
> attempt at a bootstrap source sometimes fails but seems to right
> itself the second time around usually from our  URL2 sites. This
> said, it could be that some of our buildbots, due to time out
> issues, will cause failure with this
> step. We might think of putting things back the way they originally
> were for the ./bootstrap step but increasing the time. On my local
> builds, of course, I just sit and wait.
>

What I did didn't reduce ./bootstrap's resilience. It tries to
download everything, and only when it's gone through all files, exits
with an error if something failed to download from all its URLs. The
buildbots still failed despite ./bootstrap twice. Seems like a serious
networking problem. I am trying even more caching.

-
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: buildbots -- Linux and MacOSX

[jan i]

On 18 November 2013 08:56, Jürgen Schmidt jogischm...@gmail.com wrote:

 On 11/15/13 6:54 PM, Andrew Rist wrote:
  I wanted to give an update on the buildbots, as this is a question that
  keeps coming up.

 first of all thanks for the summarized update

 
   * We've received assurances that the Mac buildbot is coming. Long
 story short, the current mac hardware is a bit long in the tooth and
 we would kill everything on it if we added our builds to the current
 machine.  We are waiting for real hardware in the form of a Mac Pro
 which will enable us to have multiple virtualized mac bots, giving
 us our own environment that can be set up for AOO.  The machine
 should be ordered by the end of the year - bot should come up early
 next year - ish...

 perfect and with the ongoing 64 bit work it will be much easier to setup
 a working env on a modern system (kudos for Herbert).

   * We are also waiting on a CentOS bot to create our standard Linux
 build.  This has been requested and is in the works, and Jan has
 agreed to bring this up in discussions with infra.  I am hoping we
 can have this for the 4.1 release timeframe.

 sounds good and I hope we can get it. I believe we can focus on a 64 bit
 system first.

   * FreeBSD bot - we have a new freebsd bot and it is slowly moving
 toward building without errors.  If anyone has suggestions for
 fixing issues on there, please post to dev and we'll move that
 forward.  We are currently stuck on Hunspell -

 FreeBSD is a port but we don't release binaries. It's fine to me to have
 a FreeBSD port but for me it don't have a high priority. If we have
 hardware or other physical limitation we should first drop such
 unreleased platforms. And please don't get me wrong we do everything to
 support this platform but I personally don't see the demand for a build
 bot at the moment

 
 
 http://ci.apache.org/builders/openoffice-fbsd-nightly/builds/91/steps/configure/logs/stdio
 
 and
 
 
 http://ci.apache.org/projects/openoffice/buildlogs/fbsdn/log/unxfbsdx.pro.build.html
 
   * The hung process issue with the windows buildbots seems to solved
 now, and has not been a problem lately.
   * Currently the Windows bots are failing - but this seems to an issue
 of svn getting out of sync, I'm cleaning up the bot and restarting
 the machine after some updates - I expect this to clean up the
 current issues.  (
   * Snapshots - both linux and windoze are currently having issues in
 terms of the size of files that the build creates.  The standard
 buildbot directory upload routine zips the directory, uploads it,
 and unzips at the destination.  Our directory of install bits has
 gotten too large and we are running into an exception on this
 step.   (On long term fix is to create our own custom directory
 upload code for build bot - but that is another discussion...)  The
 short term solution is to split the snapshot build into two builds
  (possible in a single flow) and build half the languages in each
 build - this should get us around the space issue.

 mmh, I always wondering a little bit about this physical limitations but
 that is a different story.

 Can you tell us a little bit more about the requirements for the custom
 directory and upload code.


 For a short term solution I would suggest to prepare a package lst file
 and pack only en-US + the 5 most often downloaded languages and for all
 other languages we build language packs only. What do you think?


Why not say 1 package with en-US + all released (100%) languages ?

If we dont do it as one package pr language, but one package that contain
all languages, it does not take a lot extra compile time (+8% on my vm).

rgds
jan I


 Juergen

 
  That's all for now
  A.
 
 
 
  On 11/13/2013 10:01 AM, Kay Schenk wrote:
  On Tue, Nov 12, 2013 at 6:33 PM, Glenn Harvey Liwanag 
  glennharveyliwa...@gmail.com wrote:
 
  I can try building the thing on my Mac OS X if that's what you're
  looking
  for. It's my only computer right now and I use it for school so I
  have to
  know first the average build time and the instructions to get the whole
  thing done without academics interfering with the work.
 
  Thanks for this offer! Resources used for building are dependent on your
  system, but typically it would take about 2 hours for a full build.
 
  Information on how to obtain the source and a link to the Building Guide
  can be found on the project source page:
 
http://openoffice.apache.org/source.html
 
  Please let us know how this goes for you.
 
 
  On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com
  wrote:
 
  Regarding Jürgen's comments  on a recent thread --
 
  http://markmail.org/message/v5zli2np67qv5ryz
 
  Since  CentOS 5 is our reference distribution for delivered Linux
  binaries
  (I did not know this!) -- and I am assuming this distro might remain
 as
  the
  reference going forward, 

Re: buildbots -- Linux and MacOSX

[Kay Schenk]

On Sun, Nov 17, 2013 at 11:56 PM, Jürgen Schmidt jogischm...@gmail.comwrote:

 On 11/15/13 6:54 PM, Andrew Rist wrote:
  I wanted to give an update on the buildbots, as this is a question that
  keeps coming up.

 first of all thanks for the summarized update

 
   * We've received assurances that the Mac buildbot is coming. Long
 story short, the current mac hardware is a bit long in the tooth and
 we would kill everything on it if we added our builds to the current
 machine.  We are waiting for real hardware in the form of a Mac Pro
 which will enable us to have multiple virtualized mac bots, giving
 us our own environment that can be set up for AOO.  The machine
 should be ordered by the end of the year - bot should come up early
 next year - ish...

 perfect and with the ongoing 64 bit work it will be much easier to setup
 a working env on a modern system (kudos for Herbert).

   * We are also waiting on a CentOS bot to create our standard Linux
 build.  This has been requested and is in the works, and Jan has
 agreed to bring this up in discussions with infra.  I am hoping we
 can have this for the 4.1 release timeframe.

 sounds good and I hope we can get it. I believe we can focus on a 64 bit
 system first.


and hopefully 32 bit won't be far behind...



   * FreeBSD bot - we have a new freebsd bot and it is slowly moving
 toward building without errors.  If anyone has suggestions for
 fixing issues on there, please post to dev and we'll move that
 forward.  We are currently stuck on Hunspell -

 FreeBSD is a port but we don't release binaries. It's fine to me to have
 a FreeBSD port but for me it don't have a high priority. If we have
 hardware or other physical limitation we should first drop such
 unreleased platforms. And please don't get me wrong we do everything to
 support this platform but I personally don't see the demand for a build
 bot at the moment

 
 
 http://ci.apache.org/builders/openoffice-fbsd-nightly/builds/91/steps/configure/logs/stdio
 
 and
 
 
 http://ci.apache.org/projects/openoffice/buildlogs/fbsdn/log/unxfbsdx.pro.build.html
 
   * The hung process issue with the windows buildbots seems to solved
 now, and has not been a problem lately.
   * Currently the Windows bots are failing - but this seems to an issue
 of svn getting out of sync, I'm cleaning up the bot and restarting
 the machine after some updates - I expect this to clean up the
 current issues.  (
   * Snapshots - both linux and windoze are currently having issues in
 terms of the size of files that the build creates.  The standard
 buildbot directory upload routine zips the directory, uploads it,
 and unzips at the destination.  Our directory of install bits has
 gotten too large and we are running into an exception on this
 step.   (On long term fix is to create our own custom directory
 upload code for build bot - but that is another discussion...)  The
 short term solution is to split the snapshot build into two builds
  (possible in a single flow) and build half the languages in each
 build - this should get us around the space issue.

 mmh, I always wondering a little bit about this physical limitations but
 that is a different story.

 Can you tell us a little bit more about the requirements for the custom
 directory and upload code.


 For a short term solution I would suggest to prepare a package lst file
 and pack only en-US + the 5 most often downloaded languages and for all
 other languages we build language packs only. What do you think?

 Juergen

 
  That's all for now
  A.
 
 
 
  On 11/13/2013 10:01 AM, Kay Schenk wrote:
  On Tue, Nov 12, 2013 at 6:33 PM, Glenn Harvey Liwanag 
  glennharveyliwa...@gmail.com wrote:
 
  I can try building the thing on my Mac OS X if that's what you're
  looking
  for. It's my only computer right now and I use it for school so I
  have to
  know first the average build time and the instructions to get the whole
  thing done without academics interfering with the work.
 
  Thanks for this offer! Resources used for building are dependent on your
  system, but typically it would take about 2 hours for a full build.
 
  Information on how to obtain the source and a link to the Building Guide
  can be found on the project source page:
 
http://openoffice.apache.org/source.html
 
  Please let us know how this goes for you.
 
 
  On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com
  wrote:
 
  Regarding Jürgen's comments  on a recent thread --
 
  http://markmail.org/message/v5zli2np67qv5ryz
 
  Since  CentOS 5 is our reference distribution for delivered Linux
  binaries
  (I did not know this!) -- and I am assuming this distro might remain
 as
  the
  reference going forward, does it make sense to try to move forward
  to set
  this up as a buildbot. I know wokr had already started on this. Can
  someone
  give us an update?
 
  

Re: buildbots -- Linux and MacOSX

[Jürgen Schmidt]

On 11/15/13 6:54 PM, Andrew Rist wrote:
 I wanted to give an update on the buildbots, as this is a question that
 keeps coming up.

first of all thanks for the summarized update

 
  * We've received assurances that the Mac buildbot is coming. Long
story short, the current mac hardware is a bit long in the tooth and
we would kill everything on it if we added our builds to the current
machine.  We are waiting for real hardware in the form of a Mac Pro
which will enable us to have multiple virtualized mac bots, giving
us our own environment that can be set up for AOO.  The machine
should be ordered by the end of the year - bot should come up early
next year - ish...

perfect and with the ongoing 64 bit work it will be much easier to setup
a working env on a modern system (kudos for Herbert).

  * We are also waiting on a CentOS bot to create our standard Linux
build.  This has been requested and is in the works, and Jan has
agreed to bring this up in discussions with infra.  I am hoping we
can have this for the 4.1 release timeframe.

sounds good and I hope we can get it. I believe we can focus on a 64 bit
system first.

  * FreeBSD bot - we have a new freebsd bot and it is slowly moving
toward building without errors.  If anyone has suggestions for
fixing issues on there, please post to dev and we'll move that
forward.  We are currently stuck on Hunspell -

FreeBSD is a port but we don't release binaries. It's fine to me to have
a FreeBSD port but for me it don't have a high priority. If we have
hardware or other physical limitation we should first drop such
unreleased platforms. And please don't get me wrong we do everything to
support this platform but I personally don't see the demand for a build
bot at the moment

   
 http://ci.apache.org/builders/openoffice-fbsd-nightly/builds/91/steps/configure/logs/stdio
 
and
   
 http://ci.apache.org/projects/openoffice/buildlogs/fbsdn/log/unxfbsdx.pro.build.html
 
  * The hung process issue with the windows buildbots seems to solved
now, and has not been a problem lately.
  * Currently the Windows bots are failing - but this seems to an issue
of svn getting out of sync, I'm cleaning up the bot and restarting
the machine after some updates - I expect this to clean up the
current issues.  (
  * Snapshots - both linux and windoze are currently having issues in
terms of the size of files that the build creates.  The standard
buildbot directory upload routine zips the directory, uploads it,
and unzips at the destination.  Our directory of install bits has
gotten too large and we are running into an exception on this
step.   (On long term fix is to create our own custom directory
upload code for build bot - but that is another discussion...)  The
short term solution is to split the snapshot build into two builds   
 (possible in a single flow) and build half the languages in each
build - this should get us around the space issue.

mmh, I always wondering a little bit about this physical limitations but
that is a different story.

Can you tell us a little bit more about the requirements for the custom
directory and upload code.


For a short term solution I would suggest to prepare a package lst file
and pack only en-US + the 5 most often downloaded languages and for all
other languages we build language packs only. What do you think?

Juergen

 
 That's all for now
 A.
 
 
 
 On 11/13/2013 10:01 AM, Kay Schenk wrote:
 On Tue, Nov 12, 2013 at 6:33 PM, Glenn Harvey Liwanag 
 glennharveyliwa...@gmail.com wrote:

 I can try building the thing on my Mac OS X if that's what you're
 looking
 for. It's my only computer right now and I use it for school so I
 have to
 know first the average build time and the instructions to get the whole
 thing done without academics interfering with the work.

 Thanks for this offer! Resources used for building are dependent on your
 system, but typically it would take about 2 hours for a full build.

 Information on how to obtain the source and a link to the Building Guide
 can be found on the project source page:

   http://openoffice.apache.org/source.html

 Please let us know how this goes for you.


 On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com
 wrote:

 Regarding Jürgen's comments  on a recent thread --

 http://markmail.org/message/v5zli2np67qv5ryz

 Since  CentOS 5 is our reference distribution for delivered Linux
 binaries
 (I did not know this!) -- and I am assuming this distro might remain as
 the
 reference going forward, does it make sense to try to move forward
 to set
 this up as a buildbot. I know wokr had already started on this. Can
 someone
 give us an update?

 https://issues.apache.org/jira/browse/INFRA-6217

 I don't know CentOS, but having about 18  years in various *nixes
 HP/UX,
 Solaris, RedHat, SuSE), I could probably help assuming I could work in
 command line only to deal with this.

 On the 

Re: buildbots -- Linux and MacOSX

[Glenn Harvey Liwanag]

School for the week is over. Let me just configure this SVN repo thing (I
use Git, sorry) and the whole environment.

A couple of questions

   - Am I right to presume that I need the 4 GB trunk to start building?
   - What set of details do you guys need from me?



On Thu, Nov 14, 2013 at 2:01 AM, Kay Schenk kay.sch...@gmail.com wrote:

 On Tue, Nov 12, 2013 at 6:33 PM, Glenn Harvey Liwanag 
 glennharveyliwa...@gmail.com wrote:

  I can try building the thing on my Mac OS X if that's what you're looking
  for. It's my only computer right now and I use it for school so I have to
  know first the average build time and the instructions to get the whole
  thing done without academics interfering with the work.
 

 Thanks for this offer! Resources used for building are dependent on your
 system, but typically it would take about 2 hours for a full build.

 Information on how to obtain the source and a link to the Building Guide
 can be found on the project source page:

  http://openoffice.apache.org/source.html

 Please let us know how this goes for you.


 
  On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com
 wrote:
 
   Regarding Jürgen's comments  on a recent thread --
  
   http://markmail.org/message/v5zli2np67qv5ryz
  
   Since  CentOS 5 is our reference distribution for delivered Linux
  binaries
   (I did not know this!) -- and I am assuming this distro might remain as
  the
   reference going forward, does it make sense to try to move forward to
 set
   this up as a buildbot. I know wokr had already started on this. Can
  someone
   give us an update?
  
   https://issues.apache.org/jira/browse/INFRA-6217
  
   I don't know CentOS, but having about 18  years in various *nixes
 HP/UX,
   Solaris, RedHat, SuSE), I could probably help assuming I could work in
   command line only to deal with this.
  
   On the MacOSX front, the latest update indicates we don't have hardware
  :(
  
   https://issues.apache.org/jira/browse/INFRA-4902
  
   Any suggestions? Volunteers with equipment to dedicate to this?
  
  
  
   --
  
  
 
 -
   MzK
  
   “Unless someone like you cares a whole awful lot,
Nothing is going to get better. It's not.”
 -- Dr. Seuss, The Lorax
  
 



 --

 -
 MzK

 “Unless someone like you cares a whole awful lot,
  Nothing is going to get better. It's not.”
   -- Dr. Seuss, The Lorax

Re: buildbots -- Linux and MacOSX

[Rob Weir]

On Tue, Nov 12, 2013 at 9:33 PM, Glenn Harvey Liwanag
glennharveyliwa...@gmail.com wrote:
 I can try building the thing on my Mac OS X if that's what you're looking
 for. It's my only computer right now and I use it for school so I have to
 know first the average build time and the instructions to get the whole
 thing done without academics interfering with the work.


A buildbot is a server that does automated builds for us in a secure
environment.  So it is more complicated than a build environment set
up on an developer's machine.

That said, you are welcome to set up a build environment on your own
machine if you are interested in helping with bug fixes or things like
that.

Regards,

-Rob


 On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com wrote:

 Regarding Jürgen's comments  on a recent thread --

 http://markmail.org/message/v5zli2np67qv5ryz

 Since  CentOS 5 is our reference distribution for delivered Linux binaries
 (I did not know this!) -- and I am assuming this distro might remain as the
 reference going forward, does it make sense to try to move forward to set
 this up as a buildbot. I know wokr had already started on this. Can someone
 give us an update?

 https://issues.apache.org/jira/browse/INFRA-6217

 I don't know CentOS, but having about 18  years in various *nixes HP/UX,
 Solaris, RedHat, SuSE), I could probably help assuming I could work in
 command line only to deal with this.

 On the MacOSX front, the latest update indicates we don't have hardware :(

 https://issues.apache.org/jira/browse/INFRA-4902

 Any suggestions? Volunteers with equipment to dedicate to this?



 --

 -
 MzK

 “Unless someone like you cares a whole awful lot,
  Nothing is going to get better. It's not.”
   -- Dr. Seuss, The Lorax


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

Re: buildbots -- Linux and MacOSX

[Andrew Rist]

I wanted to give an update on the buildbots, as this is a question that 
keeps coming up.


 * We've received assurances that the Mac buildbot is coming. Long
   story short, the current mac hardware is a bit long in the tooth and
   we would kill everything on it if we added our builds to the current
   machine.  We are waiting for real hardware in the form of a Mac Pro
   which will enable us to have multiple virtualized mac bots, giving
   us our own environment that can be set up for AOO.  The machine
   should be ordered by the end of the year - bot should come up early
   next year - ish...
 * We are also waiting on a CentOS bot to create our standard Linux
   build.  This has been requested and is in the works, and Jan has
   agreed to bring this up in discussions with infra.  I am hoping we
   can have this for the 4.1 release timeframe.
 * FreeBSD bot - we have a new freebsd bot and it is slowly moving
   toward building without errors.  If anyone has suggestions for
   fixing issues on there, please post to dev and we'll move that
   forward.  We are currently stuck on Hunspell -
   
http://ci.apache.org/builders/openoffice-fbsd-nightly/builds/91/steps/configure/logs/stdio
   and
   
http://ci.apache.org/projects/openoffice/buildlogs/fbsdn/log/unxfbsdx.pro.build.html
 * The hung process issue with the windows buildbots seems to solved
   now, and has not been a problem lately.
 * Currently the Windows bots are failing - but this seems to an issue
   of svn getting out of sync, I'm cleaning up the bot and restarting
   the machine after some updates - I expect this to clean up the
   current issues.  (
 * Snapshots - both linux and windoze are currently having issues in
   terms of the size of files that the build creates.  The standard
   buildbot directory upload routine zips the directory, uploads it,
   and unzips at the destination.  Our directory of install bits has
   gotten too large and we are running into an exception on this
   step.   (On long term fix is to create our own custom directory
   upload code for build bot - but that is another discussion...)  The
   short term solution is to split the snapshot build into two builds 
   (possible in a single flow) and build half the languages in each

   build - this should get us around the space issue.

That's all for now
A.



On 11/13/2013 10:01 AM, Kay Schenk wrote:

On Tue, Nov 12, 2013 at 6:33 PM, Glenn Harvey Liwanag 
glennharveyliwa...@gmail.com wrote:


I can try building the thing on my Mac OS X if that's what you're looking
for. It's my only computer right now and I use it for school so I have to
know first the average build time and the instructions to get the whole
thing done without academics interfering with the work.


Thanks for this offer! Resources used for building are dependent on your
system, but typically it would take about 2 hours for a full build.

Information on how to obtain the source and a link to the Building Guide
can be found on the project source page:

  http://openoffice.apache.org/source.html

Please let us know how this goes for you.



On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com wrote:


Regarding Jürgen's comments  on a recent thread --

http://markmail.org/message/v5zli2np67qv5ryz

Since  CentOS 5 is our reference distribution for delivered Linux

binaries

(I did not know this!) -- and I am assuming this distro might remain as

the

reference going forward, does it make sense to try to move forward to set
this up as a buildbot. I know wokr had already started on this. Can

someone

give us an update?

https://issues.apache.org/jira/browse/INFRA-6217

I don't know CentOS, but having about 18  years in various *nixes HP/UX,
Solaris, RedHat, SuSE), I could probably help assuming I could work in
command line only to deal with this.

On the MacOSX front, the latest update indicates we don't have hardware

:(

https://issues.apache.org/jira/browse/INFRA-4902

Any suggestions? Volunteers with equipment to dedicate to this?



--



-

MzK

“Unless someone like you cares a whole awful lot,
  Nothing is going to get better. It's not.”
   -- Dr. Seuss, The Lorax

Re: buildbots -- Linux and MacOSX

[Kay Schenk]

[top posting]
Thank you for this update! :)



On Fri, Nov 15, 2013 at 9:54 AM, Andrew Rist andrew.r...@oracle.com wrote:

 I wanted to give an update on the buildbots, as this is a question that
 keeps coming up.

  * We've received assurances that the Mac buildbot is coming. Long
story short, the current mac hardware is a bit long in the tooth and
we would kill everything on it if we added our builds to the current
machine.  We are waiting for real hardware in the form of a Mac Pro
which will enable us to have multiple virtualized mac bots, giving
us our own environment that can be set up for AOO.  The machine
should be ordered by the end of the year - bot should come up early
next year - ish...
  * We are also waiting on a CentOS bot to create our standard Linux
build.  This has been requested and is in the works, and Jan has
agreed to bring this up in discussions with infra.  I am hoping we
can have this for the 4.1 release timeframe.
  * FreeBSD bot - we have a new freebsd bot and it is slowly moving
toward building without errors.  If anyone has suggestions for
fixing issues on there, please post to dev and we'll move that
forward.  We are currently stuck on Hunspell -
http://ci.apache.org/builders/openoffice-fbsd-nightly/
 builds/91/steps/configure/logs/stdio
and
http://ci.apache.org/projects/openoffice/buildlogs/fbsdn/
 log/unxfbsdx.pro.build.html
  * The hung process issue with the windows buildbots seems to solved
now, and has not been a problem lately.
  * Currently the Windows bots are failing - but this seems to an issue
of svn getting out of sync, I'm cleaning up the bot and restarting
the machine after some updates - I expect this to clean up the
current issues.  (
  * Snapshots - both linux and windoze are currently having issues in
terms of the size of files that the build creates.  The standard
buildbot directory upload routine zips the directory, uploads it,
and unzips at the destination.  Our directory of install bits has
gotten too large and we are running into an exception on this
step.   (On long term fix is to create our own custom directory
upload code for build bot - but that is another discussion...)  The
short term solution is to split the snapshot build into two builds
  (possible in a single flow) and build half the languages in each
build - this should get us around the space issue.

 That's all for now
 A.



 On 11/13/2013 10:01 AM, Kay Schenk wrote:

 On Tue, Nov 12, 2013 at 6:33 PM, Glenn Harvey Liwanag 
 glennharveyliwa...@gmail.com wrote:

  I can try building the thing on my Mac OS X if that's what you're looking
 for. It's my only computer right now and I use it for school so I have to
 know first the average build time and the instructions to get the whole
 thing done without academics interfering with the work.

  Thanks for this offer! Resources used for building are dependent on your
 system, but typically it would take about 2 hours for a full build.

 Information on how to obtain the source and a link to the Building Guide
 can be found on the project source page:

   http://openoffice.apache.org/source.html

 Please let us know how this goes for you.


  On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com
 wrote:

  Regarding Jürgen's comments  on a recent thread --

 http://markmail.org/message/v5zli2np67qv5ryz

 Since  CentOS 5 is our reference distribution for delivered Linux

 binaries

 (I did not know this!) -- and I am assuming this distro might remain as

 the

 reference going forward, does it make sense to try to move forward to
 set
 this up as a buildbot. I know wokr had already started on this. Can

 someone

 give us an update?

 https://issues.apache.org/jira/browse/INFRA-6217

 I don't know CentOS, but having about 18  years in various *nixes HP/UX,
 Solaris, RedHat, SuSE), I could probably help assuming I could work in
 command line only to deal with this.

 On the MacOSX front, the latest update indicates we don't have hardware

 :(

 https://issues.apache.org/jira/browse/INFRA-4902

 Any suggestions? Volunteers with equipment to dedicate to this?



 --


  
 -

 MzK

 “Unless someone like you cares a whole awful lot,
   Nothing is going to get better. It's not.”
-- Dr. Seuss, The Lorax







-- 
-
MzK

“Unless someone like you cares a whole awful lot,
 Nothing is going to get better. It's not.”
  -- Dr. Seuss, The Lorax

Re: buildbots -- Linux and MacOSX

[Marcus (OOo)]

Really promizing and great news. Thanks for the detailed update.

Marcus



Am 11/15/2013 06:54 PM, schrieb Andrew Rist:

I wanted to give an update on the buildbots, as this is a question that
keeps coming up.

* We've received assurances that the Mac buildbot is coming. Long
story short, the current mac hardware is a bit long in the tooth and
we would kill everything on it if we added our builds to the current
machine. We are waiting for real hardware in the form of a Mac Pro
which will enable us to have multiple virtualized mac bots, giving
us our own environment that can be set up for AOO. The machine
should be ordered by the end of the year - bot should come up early
next year - ish...
* We are also waiting on a CentOS bot to create our standard Linux
build. This has been requested and is in the works, and Jan has
agreed to bring this up in discussions with infra. I am hoping we
can have this for the 4.1 release timeframe.
* FreeBSD bot - we have a new freebsd bot and it is slowly moving
toward building without errors. If anyone has suggestions for
fixing issues on there, please post to dev and we'll move that
forward. We are currently stuck on Hunspell -
http://ci.apache.org/builders/openoffice-fbsd-nightly/builds/91/steps/configure/logs/stdio

and
http://ci.apache.org/projects/openoffice/buildlogs/fbsdn/log/unxfbsdx.pro.build.html

* The hung process issue with the windows buildbots seems to solved
now, and has not been a problem lately.
* Currently the Windows bots are failing - but this seems to an issue
of svn getting out of sync, I'm cleaning up the bot and restarting
the machine after some updates - I expect this to clean up the
current issues. (
* Snapshots - both linux and windoze are currently having issues in
terms of the size of files that the build creates. The standard
buildbot directory upload routine zips the directory, uploads it,
and unzips at the destination. Our directory of install bits has
gotten too large and we are running into an exception on this
step. (On long term fix is to create our own custom directory
upload code for build bot - but that is another discussion...) The
short term solution is to split the snapshot build into two builds
(possible in a single flow) and build half the languages in each
build - this should get us around the space issue.

That's all for now
A.



On 11/13/2013 10:01 AM, Kay Schenk wrote:

On Tue, Nov 12, 2013 at 6:33 PM, Glenn Harvey Liwanag 
glennharveyliwa...@gmail.com wrote:


I can try building the thing on my Mac OS X if that's what you're
looking
for. It's my only computer right now and I use it for school so I
have to
know first the average build time and the instructions to get the whole
thing done without academics interfering with the work.


Thanks for this offer! Resources used for building are dependent on your
system, but typically it would take about 2 hours for a full build.

Information on how to obtain the source and a link to the Building Guide
can be found on the project source page:

http://openoffice.apache.org/source.html

Please let us know how this goes for you.



On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com
wrote:


Regarding Jürgen's comments on a recent thread --

http://markmail.org/message/v5zli2np67qv5ryz

Since CentOS 5 is our reference distribution for delivered Linux

binaries

(I did not know this!) -- and I am assuming this distro might remain as

the

reference going forward, does it make sense to try to move forward
to set
this up as a buildbot. I know wokr had already started on this. Can

someone

give us an update?

https://issues.apache.org/jira/browse/INFRA-6217

I don't know CentOS, but having about 18 years in various *nixes HP/UX,
Solaris, RedHat, SuSE), I could probably help assuming I could work in
command line only to deal with this.

On the MacOSX front, the latest update indicates we don't have hardware

:(

https://issues.apache.org/jira/browse/INFRA-4902

Any suggestions? Volunteers with equipment to dedicate to this?


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

Re: buildbots -- Linux and MacOSX

[Andrea Pescetti]

Andrew Rist wrote:

* We've received assurances that the Mac buildbot is coming. ...
We are waiting for real hardware in the form of a Mac Pro
which will enable us to have multiple virtualized mac bots, giving
us our own environment that can be set up for AOO. The machine
should be ordered by the end of the year - bot should come up early
next year - ish...


Thanks for the update. It's great to know that the Mac buildbot is 
coming, and many thanks should go to Infra for finding the time to deal 
with this. Looking forward to see it available.



* We are also waiting on a CentOS bot to create our standard Linux
build. This has been requested and is in the works, and Jan has
agreed to bring this up in discussions with infra. I am hoping we
can have this for the 4.1 release timeframe.


If I remember the old conversations correctly, here we already had the 
hardware, and a very powerful one, and the next step was to provide a 
CentOS 5 virtual machine. Is that correct? Building a VM is not rocket 
science, and I think several of us would be able to help with this if 
this can help move forward.


Regards,
  Andrea.

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

Re: buildbots -- Linux and MacOSX

[janI]

On 15 November 2013 20:52, Andrea Pescetti pesce...@apache.org wrote:

 Andrew Rist wrote:

 * We've received assurances that the Mac buildbot is coming. ...
 We are waiting for real hardware in the form of a Mac Pro
 which will enable us to have multiple virtualized mac bots, giving
 us our own environment that can be set up for AOO. The machine
 should be ordered by the end of the year - bot should come up early
 next year - ish...


 Thanks for the update. It's great to know that the Mac buildbot is coming,
 and many thanks should go to Infra for finding the time to deal with this.
 Looking forward to see it available.

  * We are also waiting on a CentOS bot to create our standard Linux
 build. This has been requested and is in the works, and Jan has
 agreed to bring this up in discussions with infra. I am hoping we
 can have this for the 4.1 release timeframe.


 If I remember the old conversations correctly, here we already had the
 hardware, and a very powerful one, and the next step was to provide a
 CentOS 5 virtual machine. Is that correct? Building a VM is not rocket
 science, and I think several of us would be able to help with this if this
 can help move forward.


Discussions have been whether or not it should be a vm (that was my
original suggestion) with ubuntu as base or if tethys should run centOS
directly (that was a general AOO suggestion). This discussion drifted out
in nothing, mostly because nobody made a decision and started to work the
issue 6217 is also not really clear in this respect.

It is for sure not rocket science to start a vm. The science part comes
when starting to get the standard infra utilities and e.g. ldap to work.
But all in all its just work, that needs to be done.

I have it on the agenda for next weeks infra meeting, and I suspect we
(infra) will decide how to do it and who in infra (you get 2 guesses) will
take the lead.

But of course if anybody else wants to do it, then I am sure that it can be
arranged (just wondering, why it did not happen earlier).

rgds
jan I.


 Regards,
   Andrea.

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

Re: buildbots -- Linux and MacOSX

[Glenn Harvey Liwanag]

I can try building the thing on my Mac OS X if that's what you're looking
for. It's my only computer right now and I use it for school so I have to
know first the average build time and the instructions to get the whole
thing done without academics interfering with the work.


On Wed, Nov 13, 2013 at 9:08 AM, Kay Schenk kay.sch...@gmail.com wrote:

 Regarding Jürgen's comments  on a recent thread --

 http://markmail.org/message/v5zli2np67qv5ryz

 Since  CentOS 5 is our reference distribution for delivered Linux binaries
 (I did not know this!) -- and I am assuming this distro might remain as the
 reference going forward, does it make sense to try to move forward to set
 this up as a buildbot. I know wokr had already started on this. Can someone
 give us an update?

 https://issues.apache.org/jira/browse/INFRA-6217

 I don't know CentOS, but having about 18  years in various *nixes HP/UX,
 Solaris, RedHat, SuSE), I could probably help assuming I could work in
 command line only to deal with this.

 On the MacOSX front, the latest update indicates we don't have hardware :(

 https://issues.apache.org/jira/browse/INFRA-4902

 Any suggestions? Volunteers with equipment to dedicate to this?



 --

 -
 MzK

 “Unless someone like you cares a whole awful lot,
  Nothing is going to get better. It's not.”
   -- Dr. Seuss, The Lorax