On 26 October 2012 21:17, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
Thanks a lot igor! I love the noise of burning servers under the pressure of integration scripts. At least we achieved that part :)
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.
Stef
On Oct 26, 2012, at 2:47 AM, Igor Stasenko wrote:
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] http://pharo.gforge.inria.fr/ci/vm/cog/ [2] http://pharo.gforge.inria.fr/ci/vm/nbcog/
While you can still download VMs directly from jenkins server (https://ci.lille.inria.fr/pharo/view/Cog/), 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 (http://pharo.gforge.inria.fr/ci/) to see what else is stored there.
-- Best regards, Igor Stasenko.
On 27 October 2012 02:40, btc@openinworld.com wrote:
Igor Stasenko wrote:
On 26 October 2012 21:17, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
Thanks a lot igor! I love the noise of burning servers under the pressure of integration scripts. At least we achieved that part :)
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.
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.
Well, developers can always build these libs by themselves. But users can't :) I don't think that the number of 3rd-party libs will explode that you will need to focus on making things easy (as you proposed). There are two reasons why someone would like to bundle thirdparty library with VM: - no 'official' binary available (like with cairo on windows) , or you need to build it with custom settings.
Aside of that, the idea about virtual appliance is cool by itself :) There's one little problem, however: proprietary licenses.. Microsoft is not very happy running multiple copies of Windows registered using same serial number. So, this seems to be an issue.
That's not the case for Linux , of course.. but on linux you barely need to build libs either: they can be easily installed from distro(s), without much hassle. For Mac OS, i'm not sure, but i assume the worst (like Microsoft).
Software companies stuck in 80's and keep exploiting a business model where 'copying files' their main source of income. Hoping that with emergence of cloud computing people will slowly abandon that idea :)
just a passing thought... cheers -ben
Stef
Well, developers can always build these libs by themselves. But users can't :) I don't think that the number of 3rd-party libs will explode that you will need to focus on making things easy (as you proposed). There are two reasons why someone would like to bundle thirdparty library with VM:
- no 'official' binary available (like with cairo on windows) , or
you need to build it with custom settings.
Ahh... I mis-understood slightly. I was replying in pharo-project and thinking about community contributions to the Configuration Browser. I thought I had seen some talk of putting those through continuous integration testing and was thinking in case that turned out to require lots of cpu time, then farming it out to interested members of the community might help. At the Smalltalk level it might work to distribute only a Linux appliance doing a highly repetitive first pass, from which successes proceed with other platform testing on the central servers.
Definitely an important missing task! With the current setup (build scripts and images) we could easily use travis-ci
http://about.travis-ci.org/docs/user/getting-started/
the only part missing are some additional helper scripts to deploy the jobs. With the following lines your almost done.
#========================================================================== wget --quiet -qO - http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | bash
./vm.sh Pharo.image save $JOB_NAME
REPO=http://squeaksource.com/Mate ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfMate --install=last ./vm.sh $JOB_NAME.image test --junit-xml-output "Mate-.*" #==========================================================================
so if you have some excess energy looking into having all configurations tested would be quite nice!
vm-dev@lists.squeakfoundation.org