Re: Package request for Jenkins Ubuntu slaves - cmake and swig
Hi Jake Great. Thanks very much for your help. regards, Keith Wall On 20 February 2013 00:59, Jake Farrell wrote: > Hey Keith > The requested packages have been installed on ubuntu1-6 > > -Jake > > > Keith W > February 18, 2013 7:31 AM > Hello, > > Did you have time to complete the installation of cmake and swig on the > other > Ubuntu jenkins slaves? > > Thanks, Keith Wall. > Keith W > February 11, 2013 5:58 PM > Hello Jake, builds > > Did you have time to complete the installation of cmake and swig on the > other > Ubuntu jenkins slaves? > > With thanks, Keith. > Keith W > February 7, 2013 5:53 AM > Hi Jake > > I''ve tested our C-based build on ubuntu1 and confirm that we do not > need additional packages. Please go ahead and install on the other > Ubuntu slaves. > > Thanks for your help > > regards Keith. > Jake Farrell > February 6, 2013 8:35 PM > Hi Keith > I installed these packages on minerva (ubuntu1), if you can please run a > test build and make sure you do not need any other dependencies then i'll > run through and install them on the rest of the build slaves > > Thanks > Jake > > > > Keith W wrote: > Keith W > February 4, 2013 8:17 AM > Hello > > I'm working of the Apache Qpid Project. Could I request the following > two packages are installed on the Apache CI Ubuntu slaves? > > cmake > swig > > Kind regards, Keith Wall. > >
RE: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
I think we need to clarify some things here: 1. 'Jenkins Server' is generic, saying that the 'Jenkins Server' needs java 7 updating means nothing. We have many Jenkins Slaves , some Linux, some Solaris., some windows, freebsd, etc .. Each of them has individual java versions installed. There is the system default java and there are the many other different versions we install into /home/jenkins/tools/java/* 2. The 'Jenkins Server' on which your build has been running mostly is the 'Solaris1' slave machine. This 'Solaris1' slave does have an out-dated java 7 and I'll update it shortly. currently: bash-3.00$ /export/home/hudson/tools/java/latest1.7/bin/java -version java version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) 3. The many other 'jenkins slave' machines which you could have chosen to run your builds on instead all have much more upto date versions. gmcdonald@juno:~$ /home/hudson/tools/java/latest1.7/bin/java -version java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b20) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode) etc.. Conclusion: Only one of our Jenkins slaves had a really old Java 7 and you could simply choose any other slave that has more modern versions already installed. (You can force this by tying to the 'ubuntu4' label for example) I'll let you know when 'solaris1' is updated if you prefer to continue with that. HTH Gav... > -Original Message- > From: Martin Desruisseaux [mailto:martin.desruisse...@geomatys.fr] > Sent: Thursday, 21 February 2013 3:53 AM > To: builds@apache.org > Subject: Re: Apache build infrastructure or Oracle JVM problem: crash in > native JDK code > > Le 20/02/13 18:12, Jesse Glick a écrit : > > I would merely claim that loading classes from a snapshot JAR is > > _prone_ to triggering crashes when other factors come into play which > > might be difficult to predict. > I agree. We will move to a non-snapshot version when we can. The only issue > is that we need to make a release before we can do that (unless we choose > to keep permanently one of the snapshots). > > >> This snapshot JAR file is used as a plugin for other modules well > >> after the build has been completed. > > Well after the build of that plugin module has been completed I > > suppose you mean. (According to your build log, the JAR is created > > earlier in the reactor build and then loaded at the moment of the > > crash.) > Yes you are right, thank for clarifying. > > > At any rate, for many reasons it would be preferable to run on the > > latest available version of Java (7u15 as of this writing). I do not > > personally have admin permissions to help you there. > Anyway, many thanks for your efforts, > > Martin
RE: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
> -Original Message- > From: Gavin McDonald [mailto:ga...@16degrees.com.au] > Sent: Friday, 22 February 2013 1:45 PM > To: builds@apache.org > Subject: RE: Apache build infrastructure or Oracle JVM problem: crash in > native JDK code > > I think we need to clarify some things here: > > 1. 'Jenkins Server' is generic, saying that the 'Jenkins Server' needs java > 7 > updating means nothing. > We have many Jenkins Slaves , some Linux, some Solaris., some windows, > freebsd, etc .. > Each of them has individual java versions installed. There is the system > default java and there are the many other different versions we install into > /home/jenkins/tools/java/* > > 2. The 'Jenkins Server' on which your build has been running mostly is the > 'Solaris1' slave machine. > > This 'Solaris1' slave does have an out-dated java 7 and I'll update it > shortly. Ok, upgraded. Now solaris1 is as follows: bash-3.00# /home/hudson/tools/java/latest1.7/bin/java -version java version "1.7.0_15" Java(TM) SE Runtime Environment (build 1.7.0_15-b03) Java HotSpot(TM) Server VM (build 23.7-b01, mixed mode) HTH Gav... > > currently: > > bash-3.00$ /export/home/hudson/tools/java/latest1.7/bin/java -version > java version "1.7.0" > Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) > Server VM (build 21.0-b17, mixed mode) > > 3. The many other 'jenkins slave' machines which you could have chosen to > run your builds on instead all have much more upto date versions. > > gmcdonald@juno:~$ /home/hudson/tools/java/latest1.7/bin/java -version > java version "1.7.0_04" > Java(TM) SE Runtime Environment (build 1.7.0_04-b20) Java HotSpot(TM) 64- > Bit Server VM (build 23.0-b21, mixed mode) > > etc.. > > Conclusion: Only one of our Jenkins slaves had a really old Java 7 and you > could simply choose any other slave that has more modern versions already > installed. (You can force this by tying to the 'ubuntu4' label for example) > > I'll let you know when 'solaris1' is updated if you prefer to continue with > that. > > HTH > > Gav... > > > > -Original Message- > > From: Martin Desruisseaux [mailto:martin.desruisse...@geomatys.fr] > > Sent: Thursday, 21 February 2013 3:53 AM > > To: builds@apache.org > > Subject: Re: Apache build infrastructure or Oracle JVM problem: crash > > in native JDK code > > > > Le 20/02/13 18:12, Jesse Glick a écrit : > > > I would merely claim that loading classes from a snapshot JAR is > > > _prone_ to triggering crashes when other factors come into play > > > which might be difficult to predict. > > I agree. We will move to a non-snapshot version when we can. The only > > issue is that we need to make a release before we can do that (unless > > we choose to keep permanently one of the snapshots). > > > > >> This snapshot JAR file is used as a plugin for other modules well > > >> after the build has been completed. > > > Well after the build of that plugin module has been completed I > > > suppose you mean. (According to your build log, the JAR is created > > > earlier in the reactor build and then loaded at the moment of the > > > crash.) > > Yes you are right, thank for clarifying. > > > > > At any rate, for many reasons it would be preferable to run on the > > > latest available version of Java (7u15 as of this writing). I do not > > > personally have admin permissions to help you there. > > Anyway, many thanks for your efforts, > > > > Martin >
