Hi,
Since yesterday night a number of unit tests in the the rap runtime
jobs [1] fail when trying to delete files from /tmp. I've never seen
such failures before and there hasn't been any change in the code, so
I assume that some change in the environment may have triggered it?
It's always the met
The only recent change to Hudson that I am aware of is the addition of 2
extra build slots on Slave1 to help relieve the build load.
-Matt.
--
Eclipse WebMaster - webmas...@eclipse.org
Questions? Consult the WebMaster FAQ at
http://wiki.eclipse.org/index.php/Webmaster_FAQ
View my status at
Greetings folks. The IP Log submission deadline for Juno is today.
If your project has CQs that still need to be processed, please hold off
submitting until the CQs have been approved.
There are some resources to help you sort out your logs.
The Downloads Report [1] compares the contents of your
It turned out that the problem was on our side [1], sorry for
suspecting the server!
We had two similar builds scheduled at the same time and both were
accessing the same temp dir, one deleting the other's files - how
stupid :-/
Thank you anyway,
Ralf
[1] 380420: Build failures on Eclipse Hudson
Compiled 2012-05-23T12:07
build.eclipse.org
-> Usage exceeding 1GB for: Hudson master jobs and workspace (2012-05-23T10:00)
20.0G emf-emfstore-integration
3.6G skalli
3.0G cbi-pdt-2.2-helios
2.9G JUnit-win2
2.6G cbi-pdt-3.0-indigo
2.4G papyrus-0.8-EYY-maintenance
2.3G
Here it is, nearly 5 PM on +3 day, and we haven't had a green build all
day!?
I've been assuming people were tending to the issues and fixing things
up ... but ... without some quick communication here, I'm going to start
disabling projects in order to get a good build.
Please let us know if som
Hi David, all,
I am sorry, I made a change in the agregator, but it seems my new
updates sites do not have the right MD5.
And I don't understand, since I did not change my Maven-signing-plugin
configuration.
I am doing one last try, and then I was about to email you about this
(or about to res
Thanks to all the last minute fixes and getting a clean build. I've
disabled the aggregation build and assume we are ready for RC1, unless
someone comes up with a blocking problem that justifies a respin.
My main concern is that there are still two projects still disabled:
amp.b3aggrcon
riena.b
Still here, still sorting out dependency issues in my "spare" time. (This time
w/ GEF3D.) AMP hasn't changed at all since Indigo, but everything else has. :)
If I don't get them squashed by the end of this weekend I will formally
withdraw it from Juno.
On 2012-05-23, at 6:51 PM, David M Willia
> Still here, still sorting out dependency issues in my "spare" time.
> (This time w/ GEF3D.) AMP hasn't changed at all since Indigo, but
> everything else has. :) If I don't get them squashed by the end of
> this weekend I will formally withdraw it from Juno.
Ok, so, to be explicit, (I checked a
As my mother use to say. :) I never quite knew what she meant, and too
don't know what I mean when I say "I mean it", but ...
Look at these reports:
http://build.eclipse.org/juno/simrel/reporeports/
This is a release candidate!
Still scores of files without basic things like an about.html fi
Hi David,
please dont confuse me :-). We had an extensive discussion back at the
beginning of the year, that Riena does not run on top of Eclipse 4.x. It only
runs on top of 3.8.
Thats a deal breaker for participating in Juno since e4 support is a
requirement for Juno participation.
The discu
12 matches
Mail list logo