There are 40 new builds jobs available, for the impatient
http://gis.linux4all.at:55032
http://gis.linux4all.at:55064
(The URLs a temporary and may change in future)
Behind http://gis.linux4all.at:55032 is a Suse 11.1 32 bit installation, behind http://gis.linux4all.at:55064 is an Ubuntu 9.10 Server 64 bit installation. Each of these two virtual machines is hosting 20 jobs, one for 32 bit sdks and the other for 64 bit sdks.
I created build jobs for geoserver-trunk,geoserver-2.0.x, geotools-trunk and geotools-2.6.x
using SUN sdk 5, SUN sdk 6, IBM sdk 5 , IBM sdk 6 and OpenJDK 6.
Time schedule (GMT+1):
Monday,Thursday is SUN day
Tuesday and Friday is IBM day
Wednesday and Saturday is OpenJDK day
Sunday is reserved for maintenance
Userid and password is the same as for the standard hudson.
There is a thrid VM hosting DB2,Oracle,mysql and postgis for online tests. At the moment these tests are NOT activated, since I think its better to get all our red problems to blue without online tests.
All the failed tests have problems which I cannot resolve alone.
There are enough resources to add additional jobs or VMs. The whole system is a CentOs (RedHat) Cluster using DRBD as a network mirror. The VMs are HA resources based on KVM and can be migrated from one cluster node to the other.
Wow! Phenomenal work Christian!
How can people help resolve the issues. Are there open patches to review? Or do we need to start looking at the build results to figure out what the issues are?
-Justin
Christian Müller wrote:
There are 40 new builds jobs available, for the impatient
http://gis.linux4all.at:55032
http://gis.linux4all.at:55064
(The URLs a temporary and may change in future)
Behind http://gis.linux4all.at:55032 is a Suse 11.1 32 bit installation, behind http://gis.linux4all.at:55064 is an Ubuntu 9.10 Server 64 bit installation. Each of these two virtual machines is hosting 20 jobs, one for 32 bit sdks and the other for 64 bit sdks.
I created build jobs for geoserver-trunk,geoserver-2.0.x, geotools-trunk and geotools-2.6.x
using SUN sdk 5, SUN sdk 6, IBM sdk 5 , IBM sdk 6 and OpenJDK 6.
Time schedule (GMT+1):
Monday,Thursday is SUN day
Tuesday and Friday is IBM day
Wednesday and Saturday is OpenJDK day
Sunday is reserved for maintenance
Userid and password is the same as for the standard hudson.
There is a thrid VM hosting DB2,Oracle,mysql and postgis for online tests. At the moment these tests are NOT activated, since I think its better to get all our red problems to blue without online tests.
All the failed tests have problems which I cannot resolve alone.
There are enough resources to add additional jobs or VMs. The whole system is a CentOs (RedHat) Cluster using DRBD as a network mirror. The VMs are HA resources based on KVM and can be migrated from one cluster node to the other.
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Christian Müller wrote:
There are 40 new builds jobs available, for the impatient
http://gis.linux4all.at:55032
http://gis.linux4all.at:55064
Wow, impressive, thanks a lot for putting this up.
There is sure lots of failing builds. I can surely
put some of my spare time in fixing the OpenJDK ones,
hoping the IBM ones will follow suite... maybe next week,
this week I'm in NY and will fly back to Italy tomorrow,
thus I'll need a few days to recover
Cheers
Andrea
I think we need a strategy for this. At the moment my mail account is bombed with notifications from the two hudsons.
As I contacted Ben, he opened GEOS-3689 with priority "Blocker". I could do the same for errors which occur more then once in the same build. Another possibility would be to forward the error notifcation to somebody acting as a coordinator.
As far as I know, I am the only one use IBM jdks. But thanks to openjdk, they have many errors in common. Fixing for OpenJdk will fix a lot for IBM. A good example for this is GEOT-2546 which is really a nasty bug.
There are also differences regarding 32 and 64 bit. A good example is the CropTest.testCropRotated which fails in the 64 Bit builds.
How should we attack this issue, I think most of us will have to contribute something 
Christian Müller wrote:
I think we need a strategy for this. At the moment my mail account is bombed with notifications from the two hudsons.
As I contacted Ben, he opened GEOS-3689 with priority "Blocker". I could do the same for errors which occur more then once in the same build. Another possibility would be to forward the error notifcation to somebody acting as a coordinator.
As far as I know, I am the only one use IBM jdks. But thanks to openjdk, they have many errors in common. Fixing for OpenJdk will fix a lot for IBM. A good example for this is GEOT-2546 which is really a nasty bug.
There are also differences regarding 32 and 64 bit. A good example is the CropTest.testCropRotated which fails in the 64 Bit builds.
How should we attack this issue, I think most of us will have to contribute something
The main issue I see is that you're the only one with a business interest on this. Unless OpenGeo starts to get customers with
IBM setups I doubt I'll get any work time to look into this, and
the deal is probably the same for anybody else.
So I can try to put some of my spare time on this, hoping the issues
are not so many and can be solved quickly.
Cheers
Andrea
On 10/12/09 18:22, Christian Müller wrote:
http://gis.linux4all.at:55032
http://gis.linux4all.at:55064
I am getting DNS failures for these. Is this a new domain?
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Andrea, the best would be to focus on SUN and OpenJDK. If we have clean builds here, I will do the IBM part.
Deal ?
Andrea Aime writes:
Christian Müller wrote:
I think we need a strategy for this. At the moment my mail account is bombed with notifications from the two hudsons.
As I contacted Ben, he opened GEOS-3689 with priority "Blocker". I could do the same for errors which occur more then once in the same build. Another possibility would be to forward the error notifcation to somebody acting as a coordinator.
As far as I know, I am the only one use IBM jdks. But thanks to openjdk, they have many errors in common. Fixing for OpenJdk will fix a lot for IBM. A good example for this is GEOT-2546 which is really a nasty bug.
There are also differences regarding 32 and 64 bit. A good example is the CropTest.testCropRotated which fails in the 64 Bit builds.
How should we attack this issue, I think most of us will have to contribute something
The main issue I see is that you're the only one with a business interest on this. Unless OpenGeo starts to get customers with
IBM setups I doubt I'll get any work time to look into this, and
the deal is probably the same for anybody else.
So I can try to put some of my spare time on this, hoping the issues
are not so many and can be solved quickly.
Cheers
Andrea
Christian Müller wrote:
Andrea, the best would be to focus on SUN and OpenJDK. If we have clean builds here, I will do the IBM part.
Deal ?
That was my plan, dedicate some of my spare time to fix builds on OpenJDK.
Cheers
Andrea
No, the domain is there since a long time, only the "gis" node is new
Try
http://212.186.218.44:55032/
http://212.186.218.44:55064/
On linux, i checked with
dig @193.81.83.2 gis.linux4all.at
and get an answer from a randomly chosen DNS Server.
Ben Caradoc-Davies writes:
On 10/12/09 18:22, Christian Müller wrote:
http://gis.linux4all.at:55032
http://gis.linux4all.at:55064
I am getting DNS failures for these. Is this a new domain?
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
OK, I am seeing them now. Just a stale DNS cache.
Excellent work! Now just to get them all working ...
Kind regards,
Ben.
On 13/12/09 14:59, Christian Müller wrote:
No, the domain is there since a long time, only the "gis" node is new
Try
http://212.186.218.44:55032/
http://212.186.218.44:55064/
On linux, i checked with
dig @193.81.83.2 gis.linux4all.at
and get an answer from a randomly chosen DNS Server.
Ben Caradoc-Davies writes:
On 10/12/09 18:22, Christian Müller wrote:
http://gis.linux4all.at:55032
http://gis.linux4all.at:55064
I am getting DNS failures for these. Is this a new domain?
--
Ben Caradoc-Davies<Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Christian,
one thing that I have found very useful for catching platform problems is to always build GeoTools and GeoServer in a path with spaces. I always build locally and on my buildbot in a path with spaces. I think Andrea does the same in his Win32 Hudson instances.
Would you consider changing the working directory for your Hudson instances to include spaces?
For example at the moment you have:
/home/hudson/jobs/geoserver-2.0.x-OPEN-JDK-6-32-Bit/workspace/src
If you changed this to:
/home/hudson/jobs/geoserver-2.0.x-OPEN-JDK-6-32-Bit/workspace with spaces/src
then we would have a great deal more coverage for the correct handling of encoded URLs such as:
file:/home/hudson/jobs/geoserver-2.0.x-OPEN-JDK-6-32-Bit/workspace%20with%20spaces/src
This comes up all the time in Windows builds and also Windows deployments under C:\Program Files or C:\Documents and Settings. I have found that, if spaces are correctly handled, most other characters are as well. These are a common cause of strange platform problems. Not all problems will be covered (Windows network shares are a problem too), but this is an easy way for us to improve coverage at little extra cost.
If you could make this change, I am sure that it would be much appreciated by all those who develop on or deploy to Windows.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
Christian,
one thing that I have found very useful for catching platform problems is to always build GeoTools and GeoServer in a path with spaces. I always build locally and on my buildbot in a path with spaces. I think Andrea does the same in his Win32 Hudson instances.
Did. The win32 hudson instance is unfortunately inoperable and due to
lack of sysadmin dedidated time we won't have it back anytime soon
I fear.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Is there any way I can help on this?
Steve
On Sun, Dec 13, 2009 at 11:50 PM, Andrea Aime <aaime@anonymised.com> wrote:
Ben Caradoc-Davies ha scritto:
Christian,
one thing that I have found very useful for catching platform problems
is to always build GeoTools and GeoServer in a path with spaces. I
always build locally and on my buildbot in a path with spaces. I think
Andrea does the same in his Win32 Hudson instances.
Did. The win32 hudson instance is unfortunately inoperable and due to
lack of sysadmin dedidated time we won’t have it back anytime soon
I fear.
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
steven citron-pousty ha scritto:
Is there any way I can help on this?
Well, the server cannot be publicly accessed, and the issue sounds
like being a KVM virtualization problem (I might be wrong on this).
One way anybody with a Windows machine could help would be to stand
up a public Hudson building with java 5 in
a path with spaces. Add a java 6 build and a SQL Server to the mix for bonus points. 
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
unfortunately I do not have a public facing windows server to do that. I do have licenses to SQLServer (MSDN) but it is all on machines behind the firewall, sorry…
Steve
On Mon, Dec 14, 2009 at 12:23 AM, Andrea Aime <aaime@anonymised.com> wrote:
steven citron-pousty ha scritto:
Is there any way I can help on this?
Well, the server cannot be publicly accessed, and the issue sounds
like being a KVM virtualization problem (I might be wrong on this).
One way anybody with a Windows machine could help would be to stand
up a public Hudson building with java 5 in
a path with spaces. Add a java 6 build and a SQL Server to the mix for bonus points.
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hmm, until now I see no possibility for changing "workspace" to "workspace with space". I think hudson creates this directory by default and I did not find a place where to reconfigure it.
I had spaces in the project names which resulted in directory names with spaces, but I removed the blanks because I have to handle 40 config.xml files and linux scripting is a lot easier without blanks in file names.
Perhaps I could change the hudson directroy from /home/hudson to "/home/hudson 32" and /home/hudson 64". Would this help ?
Andrea Aime writes:
Ben Caradoc-Davies ha scritto:
Christian,
one thing that I have found very useful for catching platform problems is to always build GeoTools and GeoServer in a path with spaces. I always build locally and on my buildbot in a path with spaces. I think Andrea does the same in his Win32 Hudson instances.
Did. The win32 hudson instance is unfortunately inoperable and due to
lack of sysadmin dedidated time we won't have it back anytime soon
I fear.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 14/12/09 20:52, Christian Müller wrote:
Hmm, until now I see no possibility for changing "workspace" to "workspace
with space". I think hudson creates this directory by default and I did not
find a place where to reconfigure it.
Spaces anywhere in the path would be fine.
I had spaces in the project names which resulted in directory names with
spaces, but I removed the blanks because I have to handle 40 config.xml
files and linux scripting is a lot easier without blanks in file names.
Paths with spaces are also a great way of testing the quality of your shell scripts. "$1" and "$@" are your friend.
Perhaps I could change the hudson directroy from /home/hudson to
"/home/hudson 32" and /home/hudson 64". Would this help ?
Or change the /home/hudson/jobs/ to home /home/hudson/jobs with spaces/ so you do not have to change the hudson user name.
Either would have the desired effect. The spaces could be introduced anywhere.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
The 32 bit builds build now with a space in the path. I changed the hudson home from /home/hudson to "/home/hudson 32".
Unfortunately, I cannot do the same on the 64 bit builds, since the hudson init script on ubunutu 9.10 cannot handle a hudson home dir with blanks.
Is it enough to have the 32 bit builds with a space in the path ?
Christian Müller ha scritto:
The 32 bit builds build now with a space in the path. I changed the hudson home from /home/hudson to "/home/hudson 32".
Unfortunately, I cannot do the same on the 64 bit builds, since the hudson init script on ubunutu 9.10 cannot handle a hudson home dir with blanks.
Is it enough to have the 32 bit builds with a space in the path ?
Imho, yes. I cannot think of a test that fails because of a combination
of path in spaces _and_ 64 bits architecture. Of course, sooner or later
the Murphy's law will prove me wrong
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Please can somebody check the following URLs
http://gis.linux4all.at/geoserver
http://www.linux4all.at/geoserver
http://ssh.linux4all.at/geoserver
Which one is working ?
If you see the geoserver start screen, you see a geoserver deployment using spring security instead of acegi security.
Cheers
Christian
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.