<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Igor Stasenko wrote:
<blockquote
cite="mid:CAEYrNzBA9Zb1wwoA44+=VFnWXbt7YNwzgfOPjTsGaPKm-a6FLg@mail.gmail.com"
type="cite">
<pre wrap="">
On 26 October 2012 21:17, Stéphane Ducasse <a class="moz-txt-link-rfc2396E" href="mailto:stephane.ducasse@inria.fr"><stephane.ducasse@inria.fr></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thanks a lot igor!
I love the noise of burning servers under the pressure of integration scripts.
At least we achieved that part :)
</pre>
</blockquote>
<pre wrap=""><!---->
Well, to build VM and all 3-rd party libs from scratch it takes 1 hour
and 5 minutes on slave..
a bit too much to my taste.. perhaps we will need to rearrange jobs to
build thirdparty libs separately,
because they don't change that often.
</pre>
</blockquote>
<br>
Perhaps a bit fanciful and wishful thinking.... but what would be cool
would be a preconfigured operating system "virtual appliance" that I
could download and run in VMWare or VirtualBox, which would download
and run build-jobs from a central server, and would push results back
to the main server. I'd be happy to contribute cycles and bandwidth to
such a task. Ideally this could be hands-off from my side once I booted
the appliance. Also from a security perspective there should be some
configuration outside the appliance at the VMWare level to restrict
appliance network access to the central server only. This would
scaling as the number of thirdparty libs grows. Developers should be
able to configure their own lib to be run more often than others.<br>
<br>
just a passing thought... cheers -ben<br>
<br>
<blockquote
cite="mid:CAEYrNzBA9Zb1wwoA44+=VFnWXbt7YNwzgfOPjTsGaPKm-a6FLg@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Stef
On Oct 26, 2012, at 2:47 AM, Igor Stasenko wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi there,
There are new updated Cog VMs built by Jenkins. The changes are mostly
related to Windows builds:
[1] Cog VM includes SSL plugin which uses OpenSSL library. (Tested
versus Zodiac , seems working fine).
[2] A new version of Cog+NativeBoost for windows also bundled with
Cairo library.
Here the list of all extra dll's which you can find in .zip file:
"freetype library + freetype plugin"
FT2Plugin.dll
libfreetype-6.dll
"FFI"
SqueakFFIPrims.dll
"openSSL library + SqueakSSL plugin"
SqueakSSL.dll
libeay32.dll
ssleay32.dll
"cairo library and its dependencies"
libcairo-2.dll
libpixman-1-0.dll
libpng-3.dll
zlib1.dll
Please, also note new downloads location:
[1] <a class="moz-txt-link-freetext" href="http://pharo.gforge.inria.fr/ci/vm/cog/">http://pharo.gforge.inria.fr/ci/vm/cog/</a>
[2] <a class="moz-txt-link-freetext" href="http://pharo.gforge.inria.fr/ci/vm/nbcog/">http://pharo.gforge.inria.fr/ci/vm/nbcog/</a>
While you can still download VMs directly from jenkins server
(<a class="moz-txt-link-freetext" href="https://ci.lille.inria.fr/pharo/view/Cog/">https://ci.lille.inria.fr/pharo/view/Cog/</a>),
the new location is _recommended_ place for downloading artefacts
built by Jenkins server:
- first, the interface is simple and straightforward
- second, it is not going to disappear with a puff of smoke (in case
of any problems related to jenkins & other build infrastructure)
The new artifacts will appear in archive, every time jenkins
successfully finish corresponding job(s).
You can look at (<a class="moz-txt-link-freetext" href="http://pharo.gforge.inria.fr/ci/">http://pharo.gforge.inria.fr/ci/</a>) to see what else is
stored there.
--
Best regards,
Igor Stasenko.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>